[Bug target/108283] New: Problem when accessing address zero

[Bug target/108283] New: Problem when accessing address zero

[masmiseim at gmx dot de]

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

            Bug ID: 108283
           Summary: Problem when accessing address zero
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: masmiseim at gmx dot de
  Target Milestone: ---

Created attachment 54187
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54187&action=edit
Code for reproduction (same as compiler explorer)

Hello gcc comunity,

gcc seems to create wrong code when accessing address zero on ARM Targets.
Compare this Code Example on Compiler Explorer with gcc trunk:
https://godbolt.org/z/Wxncxxo5n

On ARM Targets address zero is almost always a normal memory address.
Therefore, no special treatment should be done here.

Regards
Markus

[Bug target/108283] Problem when accessing address zero

[pinskia at gcc dot gnu.org]

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

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

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

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Use -fno-delete-null-pointer-checks as documented:
https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gcc/Optimize-Options.html#index-fdelete-null-pointer-checks

[Bug target/108283] Problem when accessing address zero

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
More over a null pointer is still an invalid pointer in C even if your bare
metal target might just happen to have a valid memory address at 0.

[Bug target/108283] Problem when accessing address zero

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
> On ARM Targets address zero is almost always a normal memory address.

That is definitely not true at all because you can run Linux on it with a mmmu
and address zero (a null pointer) is not a valid address.

[Bug target/108283] Problem when accessing address zero

[masmiseim at gmx dot de]

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

Markus <masmiseim at gmx dot de> changed:

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

--- Comment #4 from Markus <masmiseim at gmx dot de> ---
Hello Andrew, 

thanks for the feedback.
Using an mmu respectively working on application-level on an OS like Linux is
as far as I know the only exception on ARM devices where zero is not a valid
address from target point of view.
For example, compare the Technical Reference Manual of the Cortex M7
(https://developer.arm.com/documentation/ddi0489/f/programmers-model/system-address-map?lang=en)
in Chapter ‘System address map’ is defined that the complete address range from
0x0 to 0x1FFFFFFF is reserved for Code Memory.

Why not set the -fdelete-null-pointer-checks option also for ARM Targets like
it is done for AVR, MSP430? Wouldn't it be better to generate a warning
instead?

If this is not possible, why not creating a warning in addition to the
special-null-pointer handling. As a user I’m not aware of every switch and
option of the compiler. Therefore, it was not obvious that this was an
intentional behaviour of the compiler and not a bug. Especially since CLANG
worked here as I would expect it to.

Regards

[Bug target/108283] Problem when accessing address zero

[pinskia at gcc dot gnu.org]

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

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

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

--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
> As a user I’m not aware of every switch and option of the compiler.

So you are saying you don't understand the programming language you are writing
in.

Again deferencing a null pointer is undefined by the C standard.
Gcc just had an option that makes it well defined.

Also again building for arm-eabi by default is just building for a semi hosted
env. If you want something different you need to use an option.

[Bug target/108283] Problem when accessing address zero

[pinskia at gcc dot gnu.org]

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

--- Comment #6 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Clang has a similar (same?) option to disable optimization around null pointers
which is enabled for arm too. Just in the case of this source, gcc causes a
trap to happen after deferencing a null pointer.


Oh there is already a bug report opened about adding a warning too.

[Bug target/108283] Problem when accessing address zero

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
And the fact that one can access object at address 0 doesn't mean it is wise to
put there any object, because valid C/C++ can't do that, so if you really need
something to be there, special care needs to be used to hide that from the
compiler.

[Bug target/108283] Problem when accessing address zero

[masmiseim at gmx dot de]

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

Markus <masmiseim at gmx dot de> changed:

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

--- Comment #8 from Markus <masmiseim at gmx dot de> ---
Hello Andrew,

You are correct, dereferencing a null pointer is undefined in C/C++. Which
means the resulting behaviour can be specific to the target or compiler.
Undefined does not mean that it is forbitten.
But as accessing address zero is a well-defined behaviour on ARM targets I
would expect GCC to implement this behaviour when compiling for ARM. As
documented here
(https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gcc/Optimize-Options.html#index-fdelete-null-pointer-checks)
this is already done for AVR and MSP430. Why not also for ARM?

Clang may have a similar option, but it is per default disabled. Compare:
https://godbolt.org/z/hGfb4E991


@Jakub Jelinek
In many cases ARM forces you to place code here, as it expected to run from
address zero the very first instruction.

Regards

[Bug target/108283] Problem when accessing address zero

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Please read something about what is undefined behavior.
As soon as a program encounters undefined behavior, the program is meaningless
and anything can happen.
See e.g. https://blog.regehr.org/archives/213