[Bug c/63803] New: When GCC 4.9.2 compile with option -O2, the target is error.

[Bug c/63803] New: When GCC 4.9.2 compile with option -O2, the target is error.

[airbak.li at huawei dot com]

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

            Bug ID: 63803
           Summary: When GCC 4.9.2 compile with option -O2, the target is
                    error.
           Product: gcc
           Version: 4.9.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: airbak.li at huawei dot com

The option -fisolate-erroneous-paths-dereference in -O2 causes it.
1.file b.c:
int main()
{
    //volatile unsigned int
    //unsigned int orgin = *((int *)0);   //ok
    //unsigned int orgin = *((unsigned int *)0); //ok
    unsigned int orgin = *((volatile unsigned int *)0);   //nok
    printf("---");

    return 0;
}

2.compile:
arm-none-eabi-gcc --specs=nosys.specs -O2 b.c -o b
or
arm-none-eabi-gcc --specs=nosys.specs -O1 -fisolate-erroneous-paths-dereference
b.c -o b

3.asm
00008210 <main>:
    8210:    e3a03000     mov    r3, #0
    8214:    e5933000     ldr    r3, [r3]
    8218:    e7f000f0     udf    #0


4.question:
Why it is "udf    #0"?  
Is it a BUG?
Please help me, thanks!

[Bug c/63803] When GCC 4.9.2 compile with option -O2, the target is error.

[mpolacek at gcc dot gnu.org]

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

Marek Polacek <mpolacek at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
                 CC|                            |mpolacek at gcc dot gnu.org
         Resolution|---                         |INVALID

--- Comment #1 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
I don't know why this would be a bug.  You're dereferencin a NULL pointer.  udf
is an undefined instruction.  On x86_64 you'd get the ud2 instruction.

[Bug c/63803] When GCC 4.9.2 compile with option -O2, the target is error.

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Dereferencing a null pointer is undefined.
-fisolate-erroneous-paths-dereference changes some of them into __builtin_trap
and for arm that is udf #0.

[Bug c/63803] When GCC 4.9.2 compile with option -O2, the target is error.

[airbak.li at huawei dot com]

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

--- Comment #3 from Airbak <airbak.li at huawei dot com> ---
Thank you for your reply!
"-fisolate-erroneous-paths-dereference" is a new option in GCC-4.9.x.
When I use GCC-4.8.x, it is OK and will not have this problem.
More and more people are switching GCC4.8 to GCC4.9, I think they will meet
this problem too. Please help me and tell me how to solve it, thanks.


1.
This code run after DDR init. DDR address range is 0x0 to 0x80000000.
Some operation will get and set the address 0x0.

2.
*((unsigned int *)0) is OK
*((volatile unsigned int *)0)  is not OK.
Why the "volatile"  makes different?

3. 
If I want to use option "-O2" and not contain
"-fisolate-erroneous-paths-dereference", how should I configure to compile a
cross-toolchain with  GCC-4.9.2?
I mean when  compile a file  with command "gcc -O2 a.c",  it will not contain
option "-fisolate-erroneous-paths-dereference".
like:
$SRCDIR/$GCC/configure --target=$TARGET \
    --prefix=$INSTALLDIR_NATIVE \
    --libexecdir=$INSTALLDIR_NATIVE/lib \
    --infodir=$INSTALLDIR_NATIVE_DOC/info \
    --mandir=$INSTALLDIR_NATIVE_DOC/man \
    --htmldir=$INSTALLDIR_NATIVE_DOC/html \
    --pdfdir=$INSTALLDIR_NATIVE_DOC/pdf \
    --enable-languages=c,c++ \
    --enable-plugins \
    --disable-decimal-float \
    --disable-libffi \
    --disable-libgomp \
    --disable-libmudflap \
    --disable-libquadmath \
    --disable-libssp \
    --disable-libstdcxx-pch \
    ...

[Bug c/63803] When GCC 4.9.2 compile with option -O2, the target is error.

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

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

--- Comment #4 from ktkachov at gcc dot gnu.org ---
The problem here is that the code uses undefined behaviour according to the C
standard (dereferencing NULL pointer), therefore the compiler is free to do
whatever it wants. The user code should be fixed to not do that.

GCC 4.9 is free to change its behaviour from 4.8 in such code because it makes
(and shouldn't make) no guarantees about undefined behaviour

[Bug c/63803] When GCC 4.9.2 compile with option -O2, the target is error.

[mpolacek at gcc dot gnu.org]

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

--- Comment #5 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
(In reply to Airbak from comment #3) 
> 2.
> *((unsigned int *)0) is OK
> *((volatile unsigned int *)0)  is not OK.
> Why the "volatile"  makes different?

Because volatile prevents the compiler from optimizing that statement out.  As
stated above, dereferencing a NULL pointer is undefined, so if you do that, all
bets are off.

You can use -fno-isolate-erroneous-paths-dereference, but I think the problem
is elsewhere.

[Bug c/63803] When GCC 4.9.2 compile with option -O2, the target is error.

[glisse at gcc dot gnu.org]

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

--- Comment #6 from Marc Glisse <glisse at gcc dot gnu.org> ---
If dereferencing 0 is ok on your platform, you need at least
-fno-delete-null-pointer-checks. I don't know if the isolate pass checks that
flag though (it probably should).

[Bug c/63803] When GCC 4.9.2 compile with option -O2, the target is error.

[airbak.li at huawei dot com]

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

Airbak <airbak.li at huawei dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED

--- Comment #7 from Airbak <airbak.li at huawei dot com> ---
Thank you for all reply, it could be closed.