This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug tree-optimization/78248] [7 Regression] wrong code at -Os and above on x86_64-linux-gnu (in both 32-bit and 64-bit modes)
- From: "marxin at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Wed, 09 Nov 2016 09:39:37 +0000
- Subject: [Bug tree-optimization/78248] [7 Regression] wrong code at -Os and above on x86_64-linux-gnu (in both 32-bit and 64-bit modes)
- Auto-submitted: auto-generated
- References: <bug-78248-4@http.gcc.gnu.org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78248
--- Comment #8 from Martin Liška <marxin at gcc dot gnu.org> ---
(In reply to Uroš Bizjak from comment #7)
> (In reply to Martin Liška from comment #6)
> > Still can't reproduce. Can you please paste output of
> > gcc-trunk -Os small.c --verbose
>
> It fails for me:
>
> Program received signal SIGSEGV, Segmentation fault.
> main () at pr78248.c:16
> 16 d = b[e];
> (gdb)
>
> valgrind says:
>
> ==18918== Invalid read of size 4
> ==18918== at 0x40046C: main (pr78248.c:16)
> ==18918== Address 0x601000 is not stack'd, malloc'd or (recently) free'd
> ==18918==
> ==18918==
> ==18918== Process terminating with default action of signal 11 (SIGSEGV)
> ==18918== Access not within mapped region at address 0x601000
> ==18918== at 0x40046C: main (pr78248.c:16)
> ==18918== If you believe this happened as a result of a stack
> ==18918== overflow in your program's main thread (unlikely but
> ==18918== possible), you can try to increase the size of the
> ==18918== main thread stack using the --main-stacksize= flag.
> ==18918== The main thread stack size used in this run was 10485760.
I've already tried running the test-case in valgrind. But I can't see the
problem :) May you please paste -S file and --verbose output?