Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove altivec.h header? #2

Open
mardy opened this issue Dec 18, 2023 · 1 comment
Open

Remove altivec.h header? #2

mardy opened this issue Dec 18, 2023 · 1 comment

Comments

@mardy
Copy link

mardy commented Dec 18, 2023

Hi! I'm not sure that this is a bug in devkitPPC itself, but maybe you won't be against making a workaround in devkitPPC (or maybe you'll be able to give me a better suggestion).

As I understand from here, the powerpc processor on the Wii and Gamecube does not support the altivec instruction set. Yet, when I build libSDL2, it gets enabled, because this program compiles successfully on devkitPPC (source):

      check_c_source_compiles("
          #include <altivec.h>
          vector unsigned int vzero() {
              return vec_splat_u32(0);
          }
          int main(int argc, char **argv) { return 0; }" HAVE_ALTIVEC_H_HDR)
      check_c_source_compiles("
          vector unsigned int vzero() {
              return vec_splat_u32(0);
          }
          int main(int argc, char **argv) { return 0; }" CPU_SUPPORTS_ALTIVEC)

For the time being, I've manually disabled this check when building for the GameCube/Wii, but it would be nicer if I didn't have to do that.

@WinterMute
Copy link
Member

Linking to stuff I said 15 years ago isn't even slightly fair :P

Setting CPU_SUPPORTS_ALTIVEC purely on the existence of the altivec header seems a bit wrong tbh. I'm not averse to removing it fron devkitPPC though.

We have a few things in progress right now though so it will likely be in the new year when we look at newlib updates.

iSasuke7 pushed a commit to devkitNoob-mirrors/gcc that referenced this issue Nov 5, 2024
Here during overload resolution we have two strictly viable ambiguous
candidates devkitPro#1 and devkitPro#2, and two non-strictly viable candidates gcc-mirror#3 and devkitPro#4
which we hold on to ever since r14-6522.  These latter candidates have
an empty second arg conversion since the first arg conversion was deemed
bad, and this trips up joust when called on gcc-mirror#3 and devkitPro#4 which assumes all
arg conversions are there.

We can fix this by making joust robust to empty arg conversions, but in
this situation we shouldn't need to compare gcc-mirror#3 and devkitPro#4 at all given that
we have a strictly viable candidate.  To that end, this patch makes
tourney shortcut considering non-strictly viable candidates upon
encountering ambiguity between two strictly viable candidates (taking
advantage of the fact that the candidates list is sorted according to
viability via splice_viable).

	PR c++/115239

gcc/cp/ChangeLog:

	* call.cc (tourney): Don't consider a non-strictly viable
	candidate as the champ if there was ambiguity between two
	strictly viable candidates.

gcc/testsuite/ChangeLog:

	* g++.dg/overload/error7.C: New test.

Reviewed-by: Jason Merrill <[email protected]>
(cherry picked from commit 7fed7e9)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants