forked from gcc-mirror/gcc
-
-
Notifications
You must be signed in to change notification settings - Fork 6
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
Comments
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
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):
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.
The text was updated successfully, but these errors were encountered: