[Bug c++/64724] New: C++ loop with -O3 optimization produces segfault while -O2 is fine

[Bug c++/64724] New: C++ loop with -O3 optimization produces segfault while -O2 is fine

[aprokop at sandia dot gov]

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

            Bug ID: 64724
           Summary: C++ loop with -O3 optimization produces segfault while
                    -O2 is fine
           Product: gcc
           Version: 4.9.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: aprokop at sandia dot gov

$ gcc -v
Using built-in specs.
COLLECT_GCC=/home/aprokop/local/opt/gcc-4.9.2/bin/gcc
COLLECT_LTO_WRAPPER=/home/aprokop/local/opt/gcc-4.9.2/libexec/gcc/x86_64-unknown-linux-gnu/4.9.2/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.9.2/configure
--prefix=/home/aprokop/local/opt/gcc-4.9.2 --enable-gold
--enable-languages=c,c++,fortran
Thread model: posix
gcc version 4.9.2 (GCC)


I've tried 4.9.1, 4.9.2 and the trunk versions. The attached code results in
segfault. Valgrind generates "General protection fault".

[Bug c++/64724] C++ loop with -O3 optimization produces segfault while -O2 is fine

[aprokop at sandia dot gov]

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

--- Comment #1 from Andrey Prokopenko <aprokop at sandia dot gov> ---
Created attachment 34526
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34526&action=edit
.ii file

[Bug c++/64724] C++ loop with -O3 optimization produces segfault while -O2 is fine

[pinskia at gcc dot gnu.org]

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

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

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

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---

    char * a_tmp = new char[n*sizeof(double)+1];
    char * b_tmp = new char[n*sizeof(double)+1];


    double * a = reinterpret_cast<double*>(a_tmp+1);
    double * b = reinterpret_cast<double*>(b_tmp+1);


You are violating C rules dealing with alignment.  Pointer a and b are not
aligned to the alignment of double so the behavior is undefined.

[Bug c++/64724] C++ loop with -O3 optimization produces segfault while -O2 is fine

[aprokop at sandia dot gov]

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

--- Comment #3 from Andrey Prokopenko <aprokop at sandia dot gov> ---
Andrew,

Could you please point out the rule? I cannot find it. I also see that Intel
x86/64 reference manual states in section 4.1.1 that 

~~~
Words, doublewords, and quadwords do not need to be aligned in memory on
natural boundaries. The natural boundaries for words, double words, and
quadwords are even-numbered addresses, addresses evenly divisible by four, and
addresses evenly divisible by eight, respectively. However, to improve the
performance of programs, data structures (especially stacks) should be aligned
on natural boundaries whenever possible. The reason for this is that the
processor requires two memory accesses to make an unaligned memory access;
aligned accesses require only one memory access. A word or doubleword operand
that crosses a 4-byte boundary or a quadword operand that crosses an 8-byte
boundary is considered unaligned and requires two separate memory bus cycles
for access.
~~~

[Bug c++/64724] C++ loop with -O3 optimization produces segfault while -O2 is fine

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
The fact that the CPU handles it has nothing to do whether it is undefined
behavior or not.
And i?86/x86_64 hw is actually hybrid in the alignment case, some instructions
don't require strict alignment, while others do.
You can try -fsanitize=undefined and it will diagnose this at runtime:
$ g++ -fsanitize=undefined -o pr64724 pr64724.ii 
$ ./pr64724
a.cc:21:19: runtime error: load of misaligned address 0x0000025bd011 for type
'double', which requires 8 byte alignment
0x0000025bd011: note: pointer points here
 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00
00 00  00 00 00 00 00
              ^ 
a.cc:21:20: runtime error: store to misaligned address 0x0000025bd5a1 for type
'double', which requires 8 byte alignment
0x0000025bd5a1: note: pointer points here
 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00
00 00  00 00 00 00 00
              ^