I haven't tryied gcc vanilla yet, so I don't know if this is a gcc bug, or a gentoo-patchset bug. This is the simple test-case: #include <stdio.h> int main(int arg, char *argv[]) { int j; for (j=0; j<256; j++) { signed char j2=(signed char)j; printf("%d\n", (signed int)j2); } return 0; } For gcc 3.4.6 this generates 0 to 127 and -128 to -1, as expected. But on gcc 4.1.1 with -O or -O1 or higher, it generates 0 to 255, which is wrong. This can (and does) brake some applications
4.0.3 works. 4.1.1-r1 fails. 4.1 branch svn works. i don't have a vanilla 4.1.1 available.
vanilla 4.1.1 fails. works with -fwrapv though.
well feel free to do binary diffs with the 4.1 branch to see what changed fixed things ... or we can just wait for 4.1.2 ;)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29725
you're not supposed to file PR's with gcc when they've already been fixed the "it's fixed in the 4.1 branch but not in any 4.1.x release" is not a valid argument
Just though this to be a serious issue, since you actually get a program that runs, but misbehaves.
upstream has already fixed the problem, they dont care anymore
http://gcc.gnu.org/ml/gcc-patches/2006-05/msg01032.html A bit big patch perhaps? The most vital part seems to be Index: tree-chrec.c =================================================================== --- tree-chrec.c (revision 113852) +++ tree-chrec.c (working copy) @@ -1150,7 +1150,7 @@ chrec_convert (tree type, tree chrec, tr 1, 2, ..., 127, -128, ... The result should not be {(schar)1, +, (schar)1}_x, but instead, we should keep the conversion: (schar) {(uchar)1, +, (uchar)1}_x. */ - if (scev_probably_wraps_p (type, base, step, at_stmt, loop, + if (scev_probably_wraps_p (ct, base, step, at_stmt, loop, &dummy, &dummy)) goto failed_to_convert;
Created attachment 101714 [details, diff] gcc-4.1.1-bug154079.patch that looks like the patch that went into trunk. this is what got checked into the 4.1 branch (remove changelog hunk to apply). if there's nothing specific in portage broken by this i suggest waiting for 4.1.2.
yeah, the proposed changes for the upstream PR seems more than what i'd like to try and add to gcc
the 4.1.2 release process was set into motion today, so it shouldn't be long now. http://permalink.gmane.org/gmane.comp.gcc.devel/83394
yeah, i'll just wait on 4.1.2 unless something critical comes up (and i think we would have seen it by now ...)
I hit the bug in a program not in portage. I got some wierd sound in a sound-filter :-p not hard find programs that have been broken because of this either, since it compiles and run. This doesn't need to be a crashing bug. But yeah, gcc 4.1.2 is around the corner