[Bug target/30210] Altivec builtins have inaccurate return types
--- Comment #9 from bonzini at gnu dot org 2009-05-03 14:25 --- *** Bug 40009 has been marked as a duplicate of this bug. *** -- bonzini at gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30210
[Bug target/30210] Altivec builtins have inaccurate return types
--- Comment #10 from bonzini at gnu dot org 2009-05-03 14:26 --- The wrong types in __builtin_altivec_ctu cause this: FAIL: gcc.c-torture/compile/pr39943.c -O3 -fomit-frame-pointer (internal compiler error) FAIL: gcc.c-torture/compile/pr39943.c -O3 -fomit-frame-pointer (test for excess errors) FAIL: gcc.c-torture/compile/pr39943.c -O3 -fomit-frame-pointer -funroll-loops (internal compiler error) FAIL: gcc.c-torture/compile/pr39943.c -O3 -fomit-frame-pointer -funroll-loops (test for excess errors) FAIL: gcc.c-torture/compile/pr39943.c -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (internal compiler error) FAIL: gcc.c-torture/compile/pr39943.c -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (test for excess errors) FAIL: gcc.c-torture/compile/pr39943.c -O3 -g (internal compiler error) FAIL: gcc.c-torture/compile/pr39943.c -O3 -g (test for excess errors) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30210
[Bug target/30210] Altivec builtins have inaccurate return types
--- Comment #11 from rguenth at gcc dot gnu dot org 2009-05-03 15:54 --- And as there is _builtin_altivec_cts in addition to _builtin_altivec_ctu these builtins should better have correct types from the start. In fact they look more constrained than opaque anyway - so why are they using opaque arguments / return types at all? Not an enhancement, wrong-code in the middle-end sense. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Severity|enhancement |normal Keywords||wrong-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30210
[Bug target/30210] Altivec builtins have inaccurate return types
--- Comment #12 from rguenth at gcc dot gnu dot org 2009-05-03 15:56 --- *** Bug 22372 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30210
[Bug target/30210] Altivec builtins have inaccurate return types
--- Comment #8 from irar at il dot ibm dot com 2007-01-15 10:04 --- (In reply to comment #2) I think this whole type issue is a mess and needs some improvement. Maybe next week I can get to that. Andrew, are you still planning to solve this, or should I prepare a fix for rs6000_builtin_mul_widen_even as suggested by Paolo in comment #1 to close PR 22372? Ira -- irar at il dot ibm dot com changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30210
[Bug target/30210] Altivec builtins have inaccurate return types
--- Comment #6 from bonzini at gnu dot org 2006-12-20 12:28 --- Ok, so we have an agreement on why this is bad. I've reopened the bug myself and made it block 22372. A fix for 22372 can be done independent of this PR, but it will be inefficient memory-wise. -- bonzini at gnu dot org changed: What|Removed |Added OtherBugsDependingO||22372 nThis|| Severity|normal |enhancement Status|RESOLVED|REOPENED Resolution|INVALID | Summary|Altivec builtins return |Altivec builtins have |wrong types |inaccurate return types http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30210
[Bug target/30210] Altivec builtins have inaccurate return types
--- Comment #7 from bonzini at gnu dot org 2006-12-20 15:25 --- To make it clearer, there is a fix for this PR other than The way to solve this bug could be to pass the two operands to rs6000_builtin_mul_widen_even, and get back the fully-built tree, including conversions to the appropriate return type. The solution is exactly to modify __builtin_altivec_vmuloub and friends so that it has the accurate return types and argument types (unsigned). This would be, in practice, a rewrite of the way rs6000.c defines Altivec builtins, because if you want signed/unsigned information it is not enough to look at the modes in the RTL patterns. I don't see any other way to do so, except to use a big table (possibly a subset of the huge table in rs6000-c.c). The reason I had closed the bug as invalid, was that pinskia was erroneously relating it to PR14899, and saying that this would have caused regressions with Mark Shinwell's patch for stricter conversions between vector types. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30210
