public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
* Question about why GCC produces the wrong-code bug
@ 2022-09-17 15:18 Haoxin Tu
  2022-09-17 21:02 ` Jakub Jelinek
  0 siblings, 1 reply; 2+ messages in thread
From: Haoxin Tu @ 2022-09-17 15:18 UTC (permalink / raw)
  To: GCC Mailing List

[-- Attachment #1: Type: text/plain, Size: 3705 bytes --]

Dear developers,

May I seek your help with some understanding of why GCC produces the
wrong-code bug? I understand that such a bug can only be reproduced in an
old GCC version, but I still want to know why GCC made mistake here.

The bug-revealing code makes GCC-4.7.0 produce miscompiled code under the
-O3 option.

$gcc-4.7.0 -O1 s.c -o s1; ./s1
Aborted (core dumped)
$gcc-4.7.0 -O3 s.c -o s2; ./s2


Please check the source code of the code (s.c) and the assembly code of the
main function below.

```
//s.c
int a = 0;
int b[10] = {0};
__attribute__((noinline))
void marker() {
  if (a)
    __builtin_abort();
}
void func1() { a++;}
int main() {
  int e;
  for (e = 0; e <= 4; e++) {
    marker();
    b[e] = 0;
    func1();
  }
}
```

The assembly code of the main function:
s1:
0000000000401156 <main>:
  401156:       55                      push   %rbp
  401157:       53                      push   %rbx
  401158:       48 83 ec 08             sub    $0x8,%rsp
  40115c:       bb 60 40 40 00          mov    $0x404060,%ebx
  401161:       bd 74 40 40 00          mov    $0x404074,%ebp
  401166:       b8 00 00 00 00          mov    $0x0,%eax
  40116b:       e8 ca ff ff ff          callq  40113a <marker>
  401170:       c7 03 00 00 00 00       movl   $0x0,(%rbx)
  401176:       b8 00 00 00 00          mov    $0x0,%eax
  40117b:       e8 ce ff ff ff          callq  40114e <func1>
  401180:       48 83 c3 04             add    $0x4,%rbx
  401184:       48 39 eb                cmp    %rbp,%rbx
  401187:       75 dd                   jne    401166 <main+0x10>
  401189:       48 83 c4 08             add    $0x8,%rsp
  40118d:       5b                      pop    %rbx
  40118e:       5d                      pop    %rbp
  40118f:       c3                      retq

s2:
0000000000401040 <main>:
  401040:       8b 05 4a 30 00 00       mov    0x304a(%rip),%eax        #
404090 <a>
  401046:       48 c7 05 0f 30 00 00    movq   $0x0,0x300f(%rip)        #
404060 <b>
  40104d:       00 00 00 00
  401051:       48 c7 05 0c 30 00 00    movq   $0x0,0x300c(%rip)        #
404068 <b+0x8>
  401058:       00 00 00 00
  40105c:       c7 05 0a 30 00 00 00    movl   $0x0,0x300a(%rip)        #
404070 <b+0x10>
  401063:       00 00 00
  401066:       83 c0 05                add    $0x5,%eax
  401069:       89 05 21 30 00 00       mov    %eax,0x3021(%rip)        #
404090 <a>
  40106f:       c3                      retq

I think s.c is well-defined and does not involve any undefined behaviors. I
have the following two main questions regarding this bug.

(1) The root cause of the bug. It seems that some live code (the code block
in the for loop) inside the main function is eliminated in the miscompiled
binary under the -O3 optimization. My best guess of the root cause is that
GCC-4.7.0 has some issues with loop optimization, which makes the dead code
elimination optimization wrongly eliminates the live code. Am I right here
or how can I check the root cause of this bug? Are there any existing bug
reports indicating this issue?
(2) About the DCE (dead code elimination). In practice, for modern
compilers, especially for GCC (and LLVM), are there any other optimization
passes apart from DCE that can eliminate dead code blocks as well? is there
any evidence that could support the claim? In other words, can I draw a
conclusion that if a live code (code blocks rather than single
instructions) is eliminated under higher optimizations, it must be directly
(DCE itself eliminates a live code) or indirectly (other optimizations
affect the decision in DCE to eliminate a live code block) caused by a DCE
issue?

Any ideas or comments are welcome! Thank you very much!


Best regards,
Haoxin

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: Question about why GCC produces the wrong-code bug
  2022-09-17 15:18 Question about why GCC produces the wrong-code bug Haoxin Tu
@ 2022-09-17 21:02 ` Jakub Jelinek
  0 siblings, 0 replies; 2+ messages in thread
From: Jakub Jelinek @ 2022-09-17 21:02 UTC (permalink / raw)
  To: Haoxin Tu; +Cc: GCC Mailing List

On Sat, Sep 17, 2022 at 11:18:56PM +0800, Haoxin Tu via Gcc wrote:
> Dear developers,
> 
> May I seek your help with some understanding of why GCC produces the
> wrong-code bug? I understand that such a bug can only be reproduced in an
> old GCC version, but I still want to know why GCC made mistake here.
> 
> The bug-revealing code makes GCC-4.7.0 produce miscompiled code under the
> -O3 option.
> 
> $gcc-4.7.0 -O1 s.c -o s1; ./s1
> Aborted (core dumped)
> $gcc-4.7.0 -O3 s.c -o s2; ./s2

From what I can see, this has been introduced in
r0-109841-g42373e0b05c26d047925387d71fa833540dad8f0
aka PR49094 fix and got fixed in
r0-118982-gf2ea3c151c65c472024cf22b2e772819578d2011
aka PR54634 fix.  But if you want to know more, you need to figure it out
yourself, nobody is going to spend time on no longer supported 10 years old
compiler.

	Jakub


^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2022-09-17 21:02 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-09-17 15:18 Question about why GCC produces the wrong-code bug Haoxin Tu
2022-09-17 21:02 ` Jakub Jelinek

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).