https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105523
Georg-Johann Lay changed:
What|Removed |Added
Target Milestone|--- |13.3
--- Comment #37 from Georg-Joha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105523
--- Comment #36 from GCC Commits ---
The releases/gcc-13 branch has been updated by Georg-Johann Lay
:
https://gcc.gnu.org/g:83e9075ed22c0c5f27328b4be7d8eb9df5c8778b
commit r13-8319-g83e9075ed22c0c5f27328b4be7d8eb9df5c8778b
Author: Senthil Kum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105523
Georg-Johann Lay changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105523
--- Comment #34 from Georg-Johann Lay ---
@Senthil: Can this PR be closed? Or will it be backported?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105523
--- Comment #33 from CVS Commits ---
The master branch has been updated by Senthil Kumar Selvaraj
:
https://gcc.gnu.org/g:58e1bc2b1c8420773b16452d47932a6ca0d003fb
commit r14-1933-g58e1bc2b1c8420773b16452d47932a6ca0d003fb
Author: Senthil Kumar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105523
--- Comment #32 from Andrew Pinski ---
(In reply to LIU Hao from comment #31)
> (In reply to Andrew Pinski from comment #24)
> > The warning is there for the above case really (and similar ones with struct
> > offsets). Where you originally have
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105523
--- Comment #31 from LIU Hao ---
(In reply to Andrew Pinski from comment #24)
> The warning is there for the above case really (and similar ones with struct
> offsets). Where you originally have a null pointer and have an offset from
> there; by
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105523
--- Comment #30 from Konrad Rosenbaum ---
(In reply to Andrew Pinski from comment #28)
> (In reply to Wilhelm M from comment #26)
> > As you can see in my opening bug report, there is no nullptr reference nor
> > dereferencing a pointer with val
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105523
--- Comment #29 from Georg-Johann Lay ---
(In reply to David Brown from comment #20)
> This is not an AVR backend issue - it is much wider than that. It is
> perhaps reasonable to test a patch just on the AVR, but this needs to be
> fixed in th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105523
--- Comment #28 from Andrew Pinski ---
(In reply to Wilhelm M from comment #26)
> As you can see in my opening bug report, there is no nullptr reference nor
> dereferencing a pointer with value 0.
Yes but as I mentioned by the time the warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105523
--- Comment #27 from Wilhelm M ---
> I don't know if every embedded developer feels the same way. (Georg-Johann
> could chime in with his opinion.)
Indeed, limiting the warning on volatile-qualified ptr would help.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105523
--- Comment #26 from Wilhelm M ---
As you can see in my opening bug report, there is no nullptr reference nor
dereferencing a pointer with value 0.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105523
--- Comment #25 from David Brown ---
(In reply to Andrew Pinski from comment #24)
> (In reply to LIU Hao from comment #22)
> > Yes, GCC should be told to shut up about dereferencing artificial address
> > values.
>
> NO.
> Take:
> ```
> static
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105523
--- Comment #24 from Andrew Pinski ---
(In reply to LIU Hao from comment #22)
> Yes, GCC should be told to shut up about dereferencing artificial address
> values.
NO.
Take:
```
static inline int f(int *a)
{
return a[10];
}
int g()
{
retur
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105523
--- Comment #23 from David Brown ---
(In reply to LIU Hao from comment #22)
> Yes, GCC should be told to shut up about dereferencing artificial address
> values.
One possibility is to have the warnings disabled whenever you are using a
volatile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105523
--- Comment #22 from LIU Hao ---
Yes, GCC should be told to shut up about dereferencing artificial address
values.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105523
--- Comment #21 from David Brown ---
(In reply to Andrew Pinski from comment #1)
> --param=min-pagesize= should be set to 0 for avr as zero is a valid address.
Is there any convenient description of "min-pagesize" ? The user manual is
unhelpfu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105523
--- Comment #20 from David Brown ---
(In reply to Georg-Johann Lay from comment #19)
> Created attachment 54912 [details]
> pr105532.diff: Proposed patch for the AVR backend
>
> Here is a proposed, untested patch.
>
> gcc/
> PR target/10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105523
Georg-Johann Lay changed:
What|Removed |Added
CC||gjl at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105523
David Brown changed:
What|Removed |Added
CC||david at westcontrol dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105523
--- Comment #17 from Andrew Pinski ---
(In reply to David Crocker from comment #16)
> This issue is not specific to AVR target. I get the same spurious warning
> from gcc 12.2 arm-none-eabi when I compile the following code for ARM Cortex
> M0+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105523
David Crocker changed:
What|Removed |Added
CC||dcrocker at eschertech dot com
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105523
William Westfield changed:
What|Removed |Added
CC||westfw at westfw dot info
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105523
Ahmad Fatoum changed:
What|Removed |Added
CC||ahmad at a3f dot at
--- Comment #14 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105523
--- Comment #13 from LIU Hao ---
(In reply to Andrew Pinski from comment #11)
> Yes but the inline-asm is just broken. Anyways this is not related to the
> original issue reported here.
It IS related. GCC should not warn about dereferencing a c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105523
--- Comment #12 from Konrad Rosenbaum ---
It would be super helpful if the AVR target (and all its sub-architectures)
could have the min-pagesize=0 option(*) set implicitly. This architecture has
ONLY firmware - firmware is not special in that a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105523
--- Comment #11 from Andrew Pinski ---
(In reply to LIU Hao from comment #10)
> (In reply to Andrew Pinski from comment #8)
> > That inline-asm is not correct and GCC does not understand segments if you
> > don't use named address space feature.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105523
--- Comment #10 from LIU Hao ---
(In reply to Andrew Pinski from comment #8)
> That inline-asm is not correct and GCC does not understand segments if you
> don't use named address space feature.
>
Named address space is not supported unless a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105523
--- Comment #9 from Andrew Pinski ---
(In reply to rudi from comment #5)
> Compiling atf with gcc-12.1.0 for the NXP iMX8 target results in the same
> error.
>
> CFLAGS=+“ --param=min-pagesize=0” allows the build to complete.
Yes ATF needs to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105523
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105523
Georg-Johann Lay changed:
What|Removed |Added
CC||gjl at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105523
LIU Hao changed:
What|Removed |Added
CC||lh_mouse at 126 dot com
--- Comment #6 from L
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105523
rudi at heitbaum dot com changed:
What|Removed |Added
CC||rudi at heitbaum dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105523
--- Comment #4 from Wilhelm M ---
The strange thing is, that it depends on how the assignment is written:
#include
int main() {
GPIOR0 = 0x01; // no warning
(*(volatile uint8_t *)(0x001C)) = 0x01; // warning
}
The cpp replaces the G
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105523
--- Comment #3 from Wilhelm M ---
This bug is still in version 13.0.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105523
--- Comment #2 from Wilhelm M ---
Setting --param=min-pagesize=0 on the commandline does the trick. But I think
this should be set generally for avr target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105523
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
37 matches
Mail list logo