This is GCC Bugzilla
This is GCC Bugzilla Version 2.20+
View Bug Activity | Format For Printing | Clone This Bug
gcc-3.3/3.4 -O1/2 for sh target may miscompile the combination of zero extention and test if it's zero.
Created an attachment (id=4585) [edit] A testcase
This was found while Kaz was looking into why the test-strcspn, test-strpbrk, and test-strspn glibc-2.3.2 testcases (which share the same test harness) fail on sh4 with gcc-3.3; see http://www.kegel.com/crosstool/current/summaries/sh4-unknown-linux-gnu-gcc-3.3-glibc-2.3.2.glibc.sum for an example glibc test log showing the failure. If I had the power, I'd mark this bug 'confirmed'...
Confirmed by dank@kegel.
I verified the testcase detects the problem on both gcc-3.3.1 and on gcc-3.4-20030903, but on my system, I have to use -O2. With -O1, the testcase does not report failure. I also verified that this is a regression from both hardhat 2.0 gcc-2.97 and dodes gcc-3.0.2. I will submit a patch to add the test to the test suite.
I've prepared a patch to add a testcase for this PR to the testsuite; see http://www.kegel.com/crosstool/current/patches/gcc-3.3.1/pr11864-1-test.patch I'll submit it to gcc-patches in a couple days if nobody squawks.
Postponed until GCC 3.3.3.
I can reproduce the failure with the sh-elf-run simulator for the 3.3 branch. I've tried -m1, -m4 and -m4 -ml, and in each case -O0 and -O1 passes, and -O2 fails.
Richard, do you have any comments about this bug? Is anybody working on it? It's one of the few wrong-code regressions for 3.4, and it isn't analyzed (or I can't find a mail about it). Thanks.
reload_cse_simplify_operands changes a (mem:qi ..) source into a (reg:qi ..). The source register was set with an SImode set to 0x0000ff00, and the destination register is used in a SImode equality comparison to zero. LOAD_EXTEND_OP is SIGN_EXTEND for QImode for this target, hence only the lower 8 bits of the value should be tested. Thus, the replacement by reload_cse_simplify_operands is invalid. This bug potentially affects all targets that define LOAD_EXTEND_OP.
I have submitted a patch to gcc-patches: 2004-01-15 J"orn Rennecke <joern.rennecke@superh.com> * reload1.c (reload_cse_simplify_operands): Don't remove implicit extension from LOAD_EXTEND_OP. http://gcc.gnu.org/ml/gcc-patches/2004-01/msg01501.html
Subject: Bug 11864 CVSROOT: /cvs/gcc Module name: gcc Changes by: amylaar@gcc.gnu.org 2004-01-16 16:13:56 Modified files: gcc : ChangeLog Log message: Add bugzilla reference: PR 11864 * postreload.c (reload_cse_simplify_operands): Don't remove implicit extension from LOAD_EXTEND_OP. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.2322&r2=2.2323
Subject: Bug 11864 CVSROOT: /cvs/gcc Module name: gcc Changes by: amylaar@gcc.gnu.org 2004-01-16 18:43:05 Modified files: gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.dg: pr11864-1.c Log message: PR 11864 From Kazumoto Kojima / Dan Kegel: * gcc.dg/pr11864-1.c: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.3387&r2=1.3388 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/pr11864-1.c.diff?cvsroot=gcc&r1=NONE&r2=1.1
Now only a 3.3.3 regression.
Patch has been tested in 3.3, waiting for approval for 3.3 now.
Subject: Re: [3.3 regression] miscompiles zero extention and test "amylaar at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> writes: | Patch has been tested in 3.3, waiting for approval for 3.3 now. Where is it? -- Gaby
I assume this one: http://gcc.gnu.org/ml/gcc-patches/2004-01/msg01501.html
Subject: Re: [3.3 regression] miscompiles zero extention and test dhazeghi at yahoo dot com wrote: > > > ------- Additional Comments From dhazeghi at yahoo dot com 2004-01-17 00:32 ------- > I assume this one: http://gcc.gnu.org/ml/gcc-patches/2004-01/msg01501.html Yes, with a pinch of ().
(In reply to comment #16) > I assume this one: http://gcc.gnu.org/ml/gcc-patches/2004-01/msg01501.html I got a mail from Roger Sayle saying that patch is responsible for another regression. I'm waiting for more inputs from Roger.
The fix for this problem is here: http://gcc.gnu.org/ml/gcc-patches/2004-01/msg02043.html http://gcc.gnu.org/ml/gcc-cvs/2004-01/msg01083.html (of course the postreload patch would be applied to reload1.c), except that testing requires a one of the systems affected.
Patch submitted but would require changes to SPARC back-end. Postponed until GCC-3.3.4
(In reply to comment #19) > The fix for this problem is here: > http://gcc.gnu.org/ml/gcc-patches/2004-01/msg02043.html > http://gcc.gnu.org/ml/gcc-cvs/2004-01/msg01083.html > (of course the postreload patch would be applied to reload1.c), > except that testing requires a one of the systems affected. Eric -- In GCC-3.3.3 timeframe, you said that applying these patches would need patching the SPARC back-end so we did not take any action. Now that the branch is open again, I would like to know whether you look into this or not. It is uncomfortable that the SPARC back-end is blocking other back-end because of a bug in the SPARC back-end,.. Thanks, -- Gaby
[It might help to CC me...] If you are willing to backport 2004-01-27 Eric Botcazou <ebotcazou@libertysurf.fr> PR target/10904 PR target/13058 * config/sparc/sparc.h (CANNOT_CHANGE_MODE_CLASS): New. Forbid mode changes from SImode for lower FP regs if ARCH64. to the branch, I think Joern's patches are OK for SPARC. Beware, however, that other 64-bit ports might be affected by the same problem.
Subject: Re: [3.3 regression] miscompiles zero extention and test "ebotcazou at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> writes: | [It might help to CC me...] | | If you are willing to backport I can backport it, but I don't have access to a SPARC box here... (If you grant me access to one, it might be even better ;-)) -- Gaby
I can test the patch on the 3.3 branch.
Subject: Re: [3.3 regression] miscompiles zero extention and test "ebotcazou at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> writes: | I can test the patch on the 3.3 branch. Great! In the message http://gcc.gnu.org/ml/gcc-patches/2004-01/msg02997.html you did not give the filename of your testcases, which ones are they? thanks -- Gaby m
> Great! In the message > > http://gcc.gnu.org/ml/gcc-patches/2004-01/msg02997.html > > you did not give the filename of your testcases, which ones are they? Pardon? :-)
Subject: Re: [3.3 regression] miscompiles zero extention and test "ebotcazou at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> writes: | > Great! In the message | > | > http://gcc.gnu.org/ml/gcc-patches/2004-01/msg02997.html | > | > you did not give the filename of your testcases, which ones are they? | | Pardon? :-) I'm trying to produce a backport of your patch mentioned in the above link. -- Gaby
> I'm trying to produce a backport of your patch mentioned in the above > link. The patch applies cleanly on the 3.3 branch. And the testcases are there.
> The patch applies cleanly on the 3.3 branch. And the testcases are there. ...with their filename.
Subject: Re: [3.3 regression] miscompiles zero extention and test "ebotcazou at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> writes: | > I'm trying to produce a backport of your patch mentioned in the above | > link. | | The patch applies cleanly on the 3.3 branch. And the testcases are there. Let me rephrase the question. I know the testcases are there (in the link I gave). I can invent file names for the testcases; but it would be better if they [filenames] were the same on gcc-3_3-branch and gcc-3_4-branch. In the link I gave, they were just "inline" texts; (they don't seem to have been produced by the usual "cvs diff -p" stuff). my question was "what are the filenames of the testcases?". -- gaby
Subject: Re: [3.3 regression] miscompiles zero extention and test "ebotcazou at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> writes: | > The patch applies cleanly on the 3.3 branch. And the testcases are there. | | ...with their filename. well, then there is something unusual with that message :-) The main patch has its filename; not the testcases -- I just checked with mozilla and lynx separately, they concur. I suppose I would have to go through gcc-cvs. -- Gaby
> well, then there is something unusual with that message :-) The main > patch has its filename; not the testcases -- I just checked with > mozilla and lynx separately, they concur. I suppose I would have to > go through gcc-cvs. Then we have kind of a problem, because I distinctly see the filenames in the message linked to above. In the testsuite ChangeLog entry.
I just bootstrapped/regtested the backported patch on SPARC64 without a hitch. The 2 testcases also passed. Any reason why you didn't backport them alongside the patch (no, again, the filenames are in the message linked to above :-)?
Subject: Re: [3.3 regression] miscompiles zero extention and test > ------- Additional Comments From ebotcazou at gcc dot gnu dot org 2004-03-02 13:07 ------- > I just bootstrapped/regtested the backported patch on SPARC64 without a hitch. > The 2 testcases also passed. Any reason why you didn't backport them alongside > the patch (no, again, the filenames are in the message linked to above :-)? None in particular; I just thought that regressions are only likely to appear on the mainline.
Sorry, Joern, the message was for Gaby, who yesterday backported my patch which makes it possible to backport yours. The testcases are those commited on mainline alongside my patch. Funny Bugzilla :-)
Subject: Re: [3.3 regression] miscompiles zero extention and test "ebotcazou at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> writes: | I just bootstrapped/regtested the backported patch on SPARC64 | without a hitch. The 2 testcases also passed. Any reason why you | didn't backport them alongside the patch (no, again, the filenames | are in the message linked to above :-)? I did backport them. In the meantime, I installed GCC-3.5.e as default compiler and run into the bootstrap failure I fixed. Then I bootstrapped, regtested and everything was fine. Then I went on working on dayjob and forgot to make the commit (sitting in my local tree). Should be committed in moment. -- Gaby
Subject: Re: [3.3 regression] miscompiles zero extention and test "ebotcazou at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> writes: | Funny Bugzilla :-) Yes :-( *Bugzilla traffics should be threaded*. -- Gaby
Subject: Bug 11864 CVSROOT: /cvs/gcc Module name: gcc Branch: gcc-3_3-branch Changes by: gdr@gcc.gnu.org 2004-03-02 13:47:28 Modified files: gcc : ChangeLog dwarf2out.c reload1.c Log message: Backport from 3.4.0: 2004-02-29 Mark Mitchell <mark@codesourcery.com> PR debug/14328 * dwarf2out.c (gen_enumeration_type_die): Output all enumeration constants as signed values. 2004-01-16 J"orn Rennecke <joern.rennecke@superh.com> PR optimization/11864 * reload1.c (reload_cse_simplify_operands): Don't remove implicit extension from LOAD_EXTEND_OP. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_3-branch&r1=1.16114.2.914&r2=1.16114.2.915 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/dwarf2out.c.diff?cvsroot=gcc&only_with_tag=gcc-3_3-branch&r1=1.390.2.10&r2=1.390.2.11 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/reload1.c.diff?cvsroot=gcc&only_with_tag=gcc-3_3-branch&r1=1.366.2.7&r2=1.366.2.8
Applied patch
Gaby, > I did backport them. In the meantime, I installed GCC-3.5.e as > default compiler and run into the bootstrap failure I fixed. Then I > bootstrapped, regtested and everything was fine. Then I went on > working on dayjob and forgot to make the commit (sitting in my local > tree). Should be committed in moment. You still haven't done it, have you?