* [Bug target/108283] Problem when accessing address zero
2023-01-04 10:20 [Bug target/108283] New: Problem when accessing address zero masmiseim at gmx dot de
@ 2023-01-04 10:24 ` pinskia at gcc dot gnu.org
2023-01-04 10:28 ` pinskia at gcc dot gnu.org
` (7 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-01-04 10:24 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 10+ messages in thread* [Bug target/108283] Problem when accessing address zero
2023-01-04 10:20 [Bug target/108283] New: Problem when accessing address zero masmiseim at gmx dot de
2023-01-04 10:24 ` [Bug target/108283] " pinskia at gcc dot gnu.org
@ 2023-01-04 10:28 ` pinskia at gcc dot gnu.org
2023-01-04 10:29 ` pinskia at gcc dot gnu.org
` (6 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-01-04 10:28 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 10+ messages in thread* [Bug target/108283] Problem when accessing address zero
2023-01-04 10:20 [Bug target/108283] New: Problem when accessing address zero masmiseim at gmx dot de
2023-01-04 10:24 ` [Bug target/108283] " pinskia at gcc dot gnu.org
2023-01-04 10:28 ` pinskia at gcc dot gnu.org
@ 2023-01-04 10:29 ` pinskia at gcc dot gnu.org
2023-01-04 11:47 ` masmiseim at gmx dot de
` (5 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-01-04 10:29 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 10+ messages in thread* [Bug target/108283] Problem when accessing address zero
2023-01-04 10:20 [Bug target/108283] New: Problem when accessing address zero masmiseim at gmx dot de
` (2 preceding siblings ...)
2023-01-04 10:29 ` pinskia at gcc dot gnu.org
@ 2023-01-04 11:47 ` masmiseim at gmx dot de
2023-01-04 13:47 ` pinskia at gcc dot gnu.org
` (4 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: masmiseim at gmx dot de @ 2023-01-04 11:47 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 10+ messages in thread* [Bug target/108283] Problem when accessing address zero
2023-01-04 10:20 [Bug target/108283] New: Problem when accessing address zero masmiseim at gmx dot de
` (3 preceding siblings ...)
2023-01-04 11:47 ` masmiseim at gmx dot de
@ 2023-01-04 13:47 ` pinskia at gcc dot gnu.org
2023-01-04 13:51 ` pinskia at gcc dot gnu.org
` (3 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-01-04 13:47 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 10+ messages in thread* [Bug target/108283] Problem when accessing address zero
2023-01-04 10:20 [Bug target/108283] New: Problem when accessing address zero masmiseim at gmx dot de
` (4 preceding siblings ...)
2023-01-04 13:47 ` pinskia at gcc dot gnu.org
@ 2023-01-04 13:51 ` pinskia at gcc dot gnu.org
2023-01-04 14:33 ` jakub at gcc dot gnu.org
` (2 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: pinskia at gcc dot gnu.org @ 2023-01-04 13:51 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 10+ messages in thread* [Bug target/108283] Problem when accessing address zero
2023-01-04 10:20 [Bug target/108283] New: Problem when accessing address zero masmiseim at gmx dot de
` (5 preceding siblings ...)
2023-01-04 13:51 ` pinskia at gcc dot gnu.org
@ 2023-01-04 14:33 ` jakub at gcc dot gnu.org
2023-01-04 15:31 ` masmiseim at gmx dot de
2023-01-04 15:57 ` jakub at gcc dot gnu.org
8 siblings, 0 replies; 10+ messages in thread
From: jakub at gcc dot gnu.org @ 2023-01-04 14:33 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 10+ messages in thread* [Bug target/108283] Problem when accessing address zero
2023-01-04 10:20 [Bug target/108283] New: Problem when accessing address zero masmiseim at gmx dot de
` (6 preceding siblings ...)
2023-01-04 14:33 ` jakub at gcc dot gnu.org
@ 2023-01-04 15:31 ` masmiseim at gmx dot de
2023-01-04 15:57 ` jakub at gcc dot gnu.org
8 siblings, 0 replies; 10+ messages in thread
From: masmiseim at gmx dot de @ 2023-01-04 15:31 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 10+ messages in thread* [Bug target/108283] Problem when accessing address zero
2023-01-04 10:20 [Bug target/108283] New: Problem when accessing address zero masmiseim at gmx dot de
` (7 preceding siblings ...)
2023-01-04 15:31 ` masmiseim at gmx dot de
@ 2023-01-04 15:57 ` jakub at gcc dot gnu.org
8 siblings, 0 replies; 10+ messages in thread
From: jakub at gcc dot gnu.org @ 2023-01-04 15:57 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 10+ messages in thread