https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92634
--- Comment #13 from Alan Modra ---
Yes, I came to the conclusion myself that this is really nothing to do with
dereferencing. So my original claim and Andrew's replies about dereferencing
are not relevant. The standard says of unary &
"The
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92634
Jakub Jelinek changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92634
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |8.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92634
--- Comment #11 from Alan Modra ---
Oh wow, so the line of reasoning relies on what the C standard *doesn't* say in
6.5.3.2.
I also think the deductions are somewhat suspect. You say >f is the same as
&((*p).f), which is from p->f being the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92634
--- Comment #10 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #8)
> I Know there has been discussion about >f not being a NULL pointer even
> but I cannot find it right now.
Finally found it: PR30368 comment #3:
The C standard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92634
--- Comment #9 from Andrew Pinski ---
https://gcc.gnu.org/ml/gcc-patches/2005-05/msg00076.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92634
--- Comment #8 from Andrew Pinski ---
(In reply to Alan Modra from comment #7)
> Here's another example, a typical offsetof.
>
> #define offsetof(TYPE, MEMBER) ((unsigned long) &((TYPE *)0)->MEMBER)
That can never be a correct offsetof as that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92634
--- Comment #7 from Alan Modra ---
Here's another example, a typical offsetof.
#define offsetof(TYPE, MEMBER) ((unsigned long) &((TYPE *)0)->MEMBER)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92634
Jakub Jelinek changed:
What|Removed |Added
CC||jsm28 at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92634
Alan Modra changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92634
--- Comment #4 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #3)
> Dup of bug 80797.
What I mean by that is the regression is not a regression but rather a specific
change introduced in GCC 7 and that is the PR which was asking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92634
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92634
--- Comment #2 from Alan Modra ---
(In reply to Andrew Pinski from comment #1)
> No those are still officially considered a referencing.
>
> In fact all three cases:
> >field does not dereference p, just as &*p and [i] do not.
>
> Should be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92634
--- Comment #1 from Andrew Pinski ---
No those are still officially considered a referencing.
In fact all three cases:
>field does not dereference p, just as &*p and [i] do not.
Should be considered a deference even though the deference does
14 matches
Mail list logo
