public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c/102606] New: miscompilation of a program with large array in a dead-code
@ 2021-10-05 11:48 k.even-mendoza at imperial dot ac.uk
  2021-10-05 11:52 ` [Bug middle-end/102606] large array in a dead-code is not optimized away at -O0 pinskia at gcc dot gnu.org
                   ` (4 more replies)
  0 siblings, 5 replies; 6+ messages in thread
From: k.even-mendoza at imperial dot ac.uk @ 2021-10-05 11:48 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102606

            Bug ID: 102606
           Summary: miscompilation of a program with large array in a
                    dead-code
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: k.even-mendoza at imperial dot ac.uk
  Target Milestone: ---

This program miscompiled with gcc-12 (and also older versions) with -O0:

#include "stdio.h"
void foo(int *p)
{
  if(0) // Dead-code
  {
      int *i[(3500)][(300)];
  }
}
int main()
{
  int i = 1;
  foo(&i);
  printf("1\n");
  return 0;
}

the program terminates with Segmentation fault when compiled with -O0 and GCC,
but 
with -O1,O2,O3,Os and clang (all flags), it prints "1" and return 0. 
I assume the definition of "i" is being pulled up, out side the if(0) block.
I used gcc (GCC) 12.0.0 20210811 (experimental).

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

* [Bug middle-end/102606] large array in a dead-code is not optimized away at -O0
  2021-10-05 11:48 [Bug c/102606] New: miscompilation of a program with large array in a dead-code k.even-mendoza at imperial dot ac.uk
@ 2021-10-05 11:52 ` pinskia at gcc dot gnu.org
  2021-10-05 12:08 ` rguenth at gcc dot gnu.org
                   ` (3 subsequent siblings)
  4 siblings, 0 replies; 6+ messages in thread
From: pinskia at gcc dot gnu.org @ 2021-10-05 11:52 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102606

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|c                           |middle-end
            Summary|miscompilation of a program |large array in a dead-code
                   |with large array in a       |is not optimized away at
                   |dead-code                   |-O0

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
I don't think this is miscompiled but rather you just run out of stack space
because gcc at -O0 does not remove the the otherwise unused array.

This is by design.
Yes gcc could be improved to remove it but it is not a miscompile.

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

* [Bug middle-end/102606] large array in a dead-code is not optimized away at -O0
  2021-10-05 11:48 [Bug c/102606] New: miscompilation of a program with large array in a dead-code k.even-mendoza at imperial dot ac.uk
  2021-10-05 11:52 ` [Bug middle-end/102606] large array in a dead-code is not optimized away at -O0 pinskia at gcc dot gnu.org
@ 2021-10-05 12:08 ` rguenth at gcc dot gnu.org
  2021-10-05 16:17 ` jakub at gcc dot gnu.org
                   ` (2 subsequent siblings)
  4 siblings, 0 replies; 6+ messages in thread
From: rguenth at gcc dot gnu.org @ 2021-10-05 12:08 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102606

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |WONTFIX

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
Yes, even though the variable is in a local not executed scope the allocation
of stack space happens statically at function scope.  If you want this not
to happen you can use alloca() for allocation.

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

* [Bug middle-end/102606] large array in a dead-code is not optimized away at -O0
  2021-10-05 11:48 [Bug c/102606] New: miscompilation of a program with large array in a dead-code k.even-mendoza at imperial dot ac.uk
  2021-10-05 11:52 ` [Bug middle-end/102606] large array in a dead-code is not optimized away at -O0 pinskia at gcc dot gnu.org
  2021-10-05 12:08 ` rguenth at gcc dot gnu.org
@ 2021-10-05 16:17 ` jakub at gcc dot gnu.org
  2021-10-05 18:02 ` k.even-mendoza at imperial dot ac.uk
  2021-10-08 20:47 ` pinskia at gcc dot gnu.org
  4 siblings, 0 replies; 6+ messages in thread
From: jakub at gcc dot gnu.org @ 2021-10-05 16:17 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102606

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Or VLA.
Anyway, even at -O0 we can optimize away some if (0)s, but we need assurance
that there are no labels in there and that the code really dead.  So, e.g. if
constexpr (0) can be optimized away because there is a language guarantee that
one can't jump into those bodies.

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

* [Bug middle-end/102606] large array in a dead-code is not optimized away at -O0
  2021-10-05 11:48 [Bug c/102606] New: miscompilation of a program with large array in a dead-code k.even-mendoza at imperial dot ac.uk
                   ` (2 preceding siblings ...)
  2021-10-05 16:17 ` jakub at gcc dot gnu.org
@ 2021-10-05 18:02 ` k.even-mendoza at imperial dot ac.uk
  2021-10-08 20:47 ` pinskia at gcc dot gnu.org
  4 siblings, 0 replies; 6+ messages in thread
From: k.even-mendoza at imperial dot ac.uk @ 2021-10-05 18:02 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102606

--- Comment #4 from Karine EM <k.even-mendoza at imperial dot ac.uk> ---
That would make sense, and I think it is also what happens when compiling the
example with Clang and -O0 since the compilation takes only a few seconds then.

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

* [Bug middle-end/102606] large array in a dead-code is not optimized away at -O0
  2021-10-05 11:48 [Bug c/102606] New: miscompilation of a program with large array in a dead-code k.even-mendoza at imperial dot ac.uk
                   ` (3 preceding siblings ...)
  2021-10-05 18:02 ` k.even-mendoza at imperial dot ac.uk
@ 2021-10-08 20:47 ` pinskia at gcc dot gnu.org
  4 siblings, 0 replies; 6+ messages in thread
From: pinskia at gcc dot gnu.org @ 2021-10-08 20:47 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102606

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |krzyk240 at gmail dot com

--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
*** Bug 102577 has been marked as a duplicate of this bug. ***

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

end of thread, other threads:[~2021-10-08 20:47 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-10-05 11:48 [Bug c/102606] New: miscompilation of a program with large array in a dead-code k.even-mendoza at imperial dot ac.uk
2021-10-05 11:52 ` [Bug middle-end/102606] large array in a dead-code is not optimized away at -O0 pinskia at gcc dot gnu.org
2021-10-05 12:08 ` rguenth at gcc dot gnu.org
2021-10-05 16:17 ` jakub at gcc dot gnu.org
2021-10-05 18:02 ` k.even-mendoza at imperial dot ac.uk
2021-10-08 20:47 ` pinskia at gcc dot gnu.org

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).