[Bug testsuite/86519] [9 Regression] New test case gcc.dg/strcmpopt_6.c fails with its introduction in r262636
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86519 qinzhao at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #24 from qinzhao at gcc dot gnu.org --- the fix has been committed into upstream.
[Bug testsuite/86519] [9 Regression] New test case gcc.dg/strcmpopt_6.c fails with its introduction in r262636
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86519 --- Comment #23 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #21 from qinzhao at gcc dot gnu.org --- > the latest patch to this test bug has just been checked in at: > > https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=263983 There's no need for comments like this if you correctly format the PR reference in the ChangeLog: - PR 86519 + PR testsuite/86519 If so, the PR automatically gets updated with the commit message. I've fixed that now. Rainer
[Bug testsuite/86519] [9 Regression] New test case gcc.dg/strcmpopt_6.c fails with its introduction in r262636
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86519 --- Comment #22 from Rainer Orth --- Author: ro Date: Fri Aug 31 06:43:07 2018 New Revision: 264007 URL: https://gcc.gnu.org/viewcvs?rev=264007&root=gcc&view=rev Log: Fix PR testsuite/86519 reference. Modified: trunk/gcc/testsuite/ChangeLog
[Bug testsuite/86519] [9 Regression] New test case gcc.dg/strcmpopt_6.c fails with its introduction in r262636
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86519 --- Comment #21 from qinzhao at gcc dot gnu.org --- the latest patch to this test bug has just been checked in at: https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=263983
[Bug testsuite/86519] [9 Regression] New test case gcc.dg/strcmpopt_6.c fails with its introduction in r262636
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86519 --- Comment #20 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #19 from qinzhao at gcc dot gnu.org --- > which sparc machine was used to repeat the failure, and what's the configure > and make options? I just saw there are gcc210 and gcc211 in the compile farm running Solaris 10 and 11 respectively. No specific configure options should be necessary to reproduce this.
[Bug testsuite/86519] [9 Regression] New test case gcc.dg/strcmpopt_6.c fails with its introduction in r262636
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86519 --- Comment #19 from qinzhao at gcc dot gnu.org --- which sparc machine was used to repeat the failure, and what's the configure and make options?
[Bug testsuite/86519] [9 Regression] New test case gcc.dg/strcmpopt_6.c fails with its introduction in r262636
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86519 Rainer Orth changed: What|Removed |Added CC||ro at gcc dot gnu.org --- Comment #18 from Rainer Orth --- (In reply to qinzhao from comment #17) > the patch has been committed as: > > https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=263563 The commit message lacked the ChangeLog entry fragment and didns't otherwise contain the reference to PR testsuite/86519, so bugzilla didn't pick it up. What's worse, the patch caused the testcase to regress on 32-bit sparc: +FAIL: gcc.dg/strcmpopt_6.c scan-assembler-times memcmp 2 The file has sethi %hi(memcmp), %g1 jmp %g1 + %lo(memcmp) sethi %hi(memcmp), %g1 jmp %g1 + %lo(memcmp) while for sparcv9 there's only: callmemcmp, 0 callmemcmp, 0 Seems scan-assembler-times isn't reliable here. Rainer
[Bug testsuite/86519] [9 Regression] New test case gcc.dg/strcmpopt_6.c fails with its introduction in r262636
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86519 --- Comment #17 from qinzhao at gcc dot gnu.org --- the patch has been committed as: https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=263563
[Bug testsuite/86519] [9 Regression] New test case gcc.dg/strcmpopt_6.c fails with its introduction in r262636
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86519 --- Comment #16 from qinzhao at gcc dot gnu.org --- please test the proposed patch on your platform, let me know the result.
[Bug testsuite/86519] [9 Regression] New test case gcc.dg/strcmpopt_6.c fails with its introduction in r262636
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86519 --- Comment #15 from qinzhao at gcc dot gnu.org --- Created attachment 44516 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44516&action=edit proposed patch
[Bug testsuite/86519] [9 Regression] New test case gcc.dg/strcmpopt_6.c fails with its introduction in r262636
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86519 --- Comment #14 from qinzhao at gcc dot gnu.org --- reported by christophe.l...@linaro.org: After this change,(disable strcmp/strncmp inlining with O2 below and Os), I've noticed that: FAIL: gcc.dg/strcmpopt_6.c scan-rtl-dump-times expand "__builtin_memcmp" 6 on arm-none-linux-gnueabi --with-mode thumb --with-cpu cortex-a9 and forcing -march=armv5t via RUNTESTFLAGS The log says: gcc.dg/strcmpopt_6.c: pattern found 4 times FAIL: gcc.dg/strcmpopt_6.c scan-rtl-dump-times expand "__builtin_memcmp" 6 although this is NOT the exactly same bug as this PR, I listed here to fix the testcase all together with this PR.
[Bug testsuite/86519] [9 Regression] New test case gcc.dg/strcmpopt_6.c fails with its introduction in r262636
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86519 --- Comment #13 from Qing Zhao --- > --- Comment #12 from seurer at gcc dot gnu.org --- > gcc.dg/strcmpopt_6.c was recently updated in r263028 but it still fails albeit > differently: this is expected, I will provide a separate fix for this one.
[Bug testsuite/86519] [9 Regression] New test case gcc.dg/strcmpopt_6.c fails with its introduction in r262636
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86519 --- Comment #12 from seurer at gcc dot gnu.org --- gcc.dg/strcmpopt_6.c was recently updated in r263028 but it still fails albeit differently: > FAIL: gcc.dg/strcmpopt_6.c scan-rtl-dump-times expand "__builtin_memcmp" 6 < FAIL: gcc.dg/strcmpopt_6.c scan-rtl-dump-times expand "__builtin_memcmp" 4
[Bug testsuite/86519] [9 Regression] New test case gcc.dg/strcmpopt_6.c fails with its introduction in r262636
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86519 --- Comment #11 from Qing Zhao --- > to reply: Comment #10 from Martin Sebor — thanks for the details. However, I do not feel comfortable for the compiler to change an undefined buggy code. I think that it’s better to let the user to correct his/her own buggy code. What the compiler should do is just tell the user that his/her code is wrong, and why it’s wrong. the user should know better how to correct his code.
[Bug testsuite/86519] [9 Regression] New test case gcc.dg/strcmpopt_6.c fails with its introduction in r262636
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86519 --- Comment #10 from Martin Sebor --- The code is undefined so the return value doesn't really matter but conservatively, I think any non-zero value would work. What to do is a judgment call between letting the library call return some (possibly bogus and unpredictable) value or crash, and folding the call into a predictable (but possibly bogus) value and avoiding crashing. If folding into a bogus value despite the undefined behavior is a concern then folding the call to a comparison of the minimum of sizeof(string-literal) and the memcmp size would be another alternative to gain predictable results while avoiding reading past the end.
[Bug testsuite/86519] [9 Regression] New test case gcc.dg/strcmpopt_6.c fails with its introduction in r262636
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86519 --- Comment #9 from Qing Zhao --- > --- Comment #8 from Martin Sebor --- > FWIW, it would be safer and more deterministic to fold these invalid calls to > some non-zero value that it is to emit the invalid library call. could you please provide more details on this? what kind of non-zero value should be assigned to these invalid calls?
[Bug testsuite/86519] [9 Regression] New test case gcc.dg/strcmpopt_6.c fails with its introduction in r262636
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86519 Martin Sebor changed: What|Removed |Added CC||msebor at gcc dot gnu.org --- Comment #8 from Martin Sebor --- FWIW, it would be safer and more deterministic to fold these invalid calls to some non-zero value that it is to emit the invalid library call. With a small string, the risk that the call will crash is small but the result could still be different depending on how strings are laid out in memory. With larger strings, the risk is greater as will be the non-determinism.
[Bug testsuite/86519] [9 Regression] New test case gcc.dg/strcmpopt_6.c fails with its introduction in r262636
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86519 --- Comment #7 from qinzhao at gcc dot gnu.org --- the root cause for this bug is: for the following call to memcmp: __builtin_memcmp (s->s, "a", 3); the specified length 3 is larger than the length of "a", it's clearly a out-of-bound access. This new testing case is try to claim that, For such out-of-bound access, we should NOT expand this call at all. The new added in-lining expansion was prohibited under such situation, However, the expansion to hardware compare insn (old code) is NOT prohibited under such situation. on powerPC, the above call to memcmp is expanded to hardware compare insn. therefore, the testing case failed.
[Bug testsuite/86519] [9 Regression] New test case gcc.dg/strcmpopt_6.c fails with its introduction in r262636
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86519 qinzhao at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-07-17 Ever confirmed|0 |1 --- Comment #6 from qinzhao at gcc dot gnu.org --- Yes, I can repeat the failure on gcc112. will continue debugging it
[Bug testsuite/86519] [9 Regression] New test case gcc.dg/strcmpopt_6.c fails with its introduction in r262636
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86519 --- Comment #5 from Qing Zhao --- > --- Comment #4 from seurer at gcc dot gnu.org --- > I also just tried it on gcc110 and indeed it does not fail there. However, it > does fail on gcc112. thanks a lot. will try on gcc112.
[Bug testsuite/86519] [9 Regression] New test case gcc.dg/strcmpopt_6.c fails with its introduction in r262636
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86519 --- Comment #4 from seurer at gcc dot gnu.org --- I also just tried it on gcc110 and indeed it does not fail there. However, it does fail on gcc112.
[Bug testsuite/86519] [9 Regression] New test case gcc.dg/strcmpopt_6.c fails with its introduction in r262636
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86519 --- Comment #3 from Qing Zhao --- > --- Comment #2 from seurer at gcc dot gnu.org --- > What system are you testing on? I've seen the same failure on power 8 and > power 9 LE systems and power 7 and power 8 BE systems. I am using the GCC farm machine gcc110: [qinzhao@gcc1-power7 ~]$ uname -a Linux gcc1-power7.osuosl.org 3.10.0-514.26.2.el7.ppc64 #1 SMP Mon Jul 10 02:26:53 GMT 2017 ppc64 ppc64 ppc64 GNU/Linux let me know this is not the right machine to repeat the error.
[Bug testsuite/86519] [9 Regression] New test case gcc.dg/strcmpopt_6.c fails with its introduction in r262636
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86519 --- Comment #2 from seurer at gcc dot gnu.org --- What system are you testing on? I've seen the same failure on power 8 and power 9 LE systems and power 7 and power 8 BE systems.
[Bug testsuite/86519] [9 Regression] New test case gcc.dg/strcmpopt_6.c fails with its introduction in r262636
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86519 Richard Biener changed: What|Removed |Added Target Milestone|--- |9.0 Summary|New test case |[9 Regression] New test |gcc.dg/strcmpopt_6.c fails |case gcc.dg/strcmpopt_6.c |with its introduction in|fails with its introduction |r262636 |in r262636