https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
--- Comment #63 from rguenther at suse dot de ---
On Wed, 2 May 2018, aph at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
>
> --- Comment #62 from Andrew Haley ---
> Just a bit of clarification:
>
> (In reply to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
--- Comment #62 from Andrew Haley ---
Just a bit of clarification:
(In reply to James Kuyper Jr. from comment #59)
>
> > 1) all type-based alias analysis is effectively impossible
>
> Alias analysis is only affected by the special guarantee if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
--- Comment #61 from Davin McCall ---
(In reply to James Kuyper Jr. from comment #59)
> (In reply to Davin McCall from comment #56)
> > (In reply to James Kuyper Jr. from comment #55)
> > > The problem is, you're using a statement that the access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
--- Comment #60 from Andrew Haley ---
(In reply to James Kuyper Jr. from comment #51)
> (In reply to Andrew Haley from comment #49)
> > (In reply to James Kuyper Jr. from comment #46)
> >
> > The principle of type-based alias analysis is that al
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
--- Comment #59 from James Kuyper Jr.
---
(In reply to Davin McCall from comment #56)
> (In reply to James Kuyper Jr. from comment #55)
> > The problem is, you're using a statement that the access must occur via a
> > union, with the implication
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
--- Comment #58 from Davin McCall ---
(In reply to Andrew Haley from comment #57)
> (In reply to Davin McCall from comment #52)
> > (In reply to Andrew Haley from comment #45)
> > > (In reply to Davin McCall from comment #44)
> > > > The "one spe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
--- Comment #57 from Andrew Haley ---
(In reply to Davin McCall from comment #52)
> (In reply to Andrew Haley from comment #45)
> > (In reply to Davin McCall from comment #44)
> > > The "one special guarantee" clause appears in the section descri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
--- Comment #56 from Davin McCall ---
(In reply to James Kuyper Jr. from comment #55)
> The problem is, you're using a statement that the access must occur via a
> union, with the implication that the code in question does not access the
> member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
--- Comment #55 from James Kuyper Jr.
---
> ou need, at a minimum, to modify "accesses via" to
> "accesses directly via", in order to convey your intended meaning.
(In reply to Davin McCall from comment #54)
> (In reply to James Kuyper Jr. from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
--- Comment #54 from Davin McCall ---
(In reply to James Kuyper Jr. from comment #53)
> [...] However, because those
> pointers are passed to f(), which does dereference them, f() does accesses
> those members, and it does so via the use of the '
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
--- Comment #53 from James Kuyper Jr.
---
(In reply to Davin McCall from comment #52)
> (In reply to James Kuyper Jr. from comment #48)
> > > The "one special guarantee" clause appears in the section describing union
> > > member access via the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
--- Comment #52 from Davin McCall ---
(In reply to James Kuyper Jr. from comment #48)
> > The "one special guarantee" clause appears in the section describing union
> > member access via the "." or "->" operators, implying that it only applies
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
--- Comment #51 from James Kuyper Jr.
---
(In reply to Andrew Haley from comment #49)
> (In reply to James Kuyper Jr. from comment #46)
> > (In reply to Andrew Haley from comment #42)
> > ...
> > > In order to use type-based alias analysis in an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
--- Comment #50 from Andrew Haley ---
(In reply to Andrew Haley from comment #49)
>
> Perhaps so, yes, but in practice it'd be pretty hard to do that.
> Functions can only be defined in the other scope,
Should be "the outer scope"
> and there'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
--- Comment #49 from Andrew Haley ---
(In reply to James Kuyper Jr. from comment #46)
> (In reply to Andrew Haley from comment #42)
> ...
> > In order to use type-based alias analysis in any LTO framework it's
> > necessary to save type informati
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
--- Comment #48 from James Kuyper Jr.
---
(In reply to Davin McCall from comment #44)
> > Well, perhaps not, but this is the language specification.
>
> The "one special guarantee" clause appears in the section describing union
> member access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
--- Comment #47 from Andrew Haley ---
(In reply to Richard Biener from comment #43)
> (In reply to Andrew Haley from comment #42)
> >
> > So, if any union types with a common initial sequence are declared
> > anywhere in a program, then their me
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
--- Comment #46 from James Kuyper Jr.
---
(In reply to Andrew Haley from comment #42)
...
> In order to use type-based alias analysis in any LTO framework it's
> necessary to save type information, and this is just more type
> information. ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
--- Comment #45 from Andrew Haley ---
(In reply to Davin McCall from comment #44)
> > Well, perhaps not, but this is the language specification.
>
> The "one special guarantee" clause appears in the section describing union
> member access via t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
--- Comment #44 from Davin McCall ---
> Well, perhaps not, but this is the language specification.
The "one special guarantee" clause appears in the section describing union
member access via the "." or "->" operators, implying that it only appl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
--- Comment #43 from Richard Biener ---
(In reply to Andrew Haley from comment #42)
> On 04/29/2018 05:42 PM, rguenther at suse dot de wrote:>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
> >
> > --- Comment #41 from rguenther at suse do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
--- Comment #42 from Andrew Haley ---
On 04/29/2018 05:42 PM, rguenther at suse dot de wrote:>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
>
> --- Comment #41 from rguenther at suse dot de ---
> On April 29, 2018 1:51:58 PM GMT+02:00, "a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
--- Comment #41 from rguenther at suse dot de ---
On April 29, 2018 1:51:58 PM GMT+02:00, "aph at gcc dot gnu.org"
wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
>
>--- Comment #40 from Andrew Haley ---
>(In reply to rguent...@suse.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
--- Comment #40 from Andrew Haley ---
(In reply to rguent...@suse.de from comment #29)
> Note I repeatedly said this part of the standard is just stupid. It makes
> most if not all type-based alias analysis useless.
I don't think so. It does
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
--- Comment #39 from joseph at codesourcery dot com ---
On Thu, 19 Apr 2018, jameskuyper at verizon dot net wrote:
> Code which relies upon this feature to implement a C-style approximation to
> inheritance has been fairly common, which is preci
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
--- Comment #38 from rguenther at suse dot de ---
On Fri, 20 Apr 2018, msebor at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
>
> --- Comment #35 from Martin Sebor ---
> Here are the proposed changes:
>
> Pointe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
--- Comment #37 from David Brown ---
(In reply to Martin Sebor from comment #35)
> Here are the proposed changes:
>
> Pointer Provenance:
> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2219.htm#proposed-technical-
> corrigendum
>
> Trap Rep
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
--- Comment #36 from David Brown ---
(In reply to Martin Sebor from comment #34)
> I think in the use case below:
>
>struct { int i; char buf[4]; } s, r;
>*(float *)s.buf = 1.;
>r = s;
>
> the aggregate copy has to be viewed as a r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
--- Comment #35 from Martin Sebor ---
Here are the proposed changes:
Pointer Provenance:
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2219.htm#proposed-technical-corrigendum
Trap Representations:
http://www.open-std.org/jtc1/sc22/wg14/www/d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
--- Comment #34 from Martin Sebor ---
The questions in N2223 and the other documents are there to provide background
and justification for the proposed changes (the questions come surveys they
sent to various forums). The proposed words are at t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
--- Comment #33 from Richard Biener ---
(In reply to Martin Sebor from comment #30)
> Richard, I offered to write a proposal (with Clark) to improve the rules.
> With the object model proposals already in the pipeline (N2223) this is a
> good ti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
--- Comment #32 from Richard Biener ---
(In reply to James Kuyper Jr. from comment #31)
> (In reply to rguent...@suse.de from comment #29)
> > On Thu, 19 Apr 2018, jameskuyper at verizon dot net wrote:
> ...
> > > The relevant wording is "anywher
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
--- Comment #31 from James Kuyper Jr. ---
(In reply to rguent...@suse.de from comment #29)
> On Thu, 19 Apr 2018, jameskuyper at verizon dot net wrote:
...
> > The relevant wording is "anywhere that a declaration of the completed type
> > of
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
--- Comment #30 from Martin Sebor ---
Richard, I offered to write a proposal (with Clark) to improve the rules. With
the object model proposals already in the pipeline (N2223) this is a good time
to review them and see if it makes sense to exten
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
--- Comment #29 from rguenther at suse dot de ---
On Thu, 19 Apr 2018, jameskuyper at verizon dot net wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
>
> James Kuyper Jr. changed:
>
>What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
James Kuyper Jr. changed:
What|Removed |Added
CC||jameskuyper at verizon dot net
--- Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
--- Comment #27 from rguenther at suse dot de ---
On Wed, 27 Sep 2017, david at westcontrol dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
>
> David Brown changed:
>
>What|Removed |Adde
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
David Brown changed:
What|Removed |Added
CC||david at westcontrol dot com
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
Davin McCall changed:
What|Removed |Added
CC||davmac at davmac dot org
--- Comment #25
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
--- Comment #24 from rguenther at suse dot de ---
On Wed, 2 Nov 2016, txr at alumni dot caltech.edu wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
>
> --- Comment #22 from Tim Rentsch ---
> [responding to comments from rguent...@s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
--- Comment #23 from joseph at codesourcery dot com ---
On Wed, 2 Nov 2016, txr at alumni dot caltech.edu wrote:
> Seven: Given that the question is now under serious debate, IMO
> someone involved with gcc development should take the initiativ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
--- Comment #22 from Tim Rentsch ---
[responding to comments from rguent...@suse.de in Comment 20]
> GCC already implements this if you specify -fno-strict-aliasing.
The main point of my comments is that the ISO C standard requires
the behavior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
--- Comment #21 from Tim Rentsch ---
[responding to comments from jos...@codesourcery.com in Comment 19]
>> Five: The answer to the question is clearly No. The example code
>> is very much on point to the "one special guarantee" clause, and
>>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
--- Comment #20 from rguenther at suse dot de ---
On November 1, 2016 7:16:06 PM GMT+01:00, "txr at alumni dot caltech.edu"
wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
>
>Tim Rentsch changed:
>
> What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
--- Comment #19 from joseph at codesourcery dot com ---
On Tue, 1 Nov 2016, txr at alumni dot caltech.edu wrote:
> Five: The answer to the question is clearly No. The example code
> is very much on point to the "one special guarantee" clause,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
Tim Rentsch changed:
What|Removed |Added
CC||txr at alumni dot caltech.edu
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
--- Comment #17 from Martin Sebor ---
The C Union Visibility rule was intended to cover that case. The trouble is
that the rule tends to be interpreted differently by different people, users
and implementers alike: Is it the union object that mu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
--- Comment #16 from Jonathan Wakely ---
Message [c++std-core-20893] on the C++ core reflector on 2011-12-14 supports
the GCC view that a C++ compiler can apply strict aliasing rules to p1->m and
p2->m unless the fact they come from the same obje
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
--- Comment #15 from Jonathan Wakely ---
(In reply to Melissa from comment #12)
> A C++ conversion of the original example is below. I asked about the word
> "read" on the C++ Standard Discussion (std-discussion) mailing list, because
> it proba
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
--- Comment #14 from joseph at codesourcery dot com ---
That C++ wording doesn't have any obvious bearing on what "it is
permitted" is intended to be an exception to - the general
implementation-defined nature of type punning (which I think was
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
--- Comment #13 from Melissa ---
As for a reason why this should be allowed, all I need is to do is mention
struct sockaddr.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
Melissa changed:
What|Removed |Added
CC||myriachan at gmail dot com
--- Comment #12 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |SUSPENDED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
--- Comment #10 from Martin Sebor ---
Thanks (again) for your comments, Joseph. I had a chance to discuss this issue
with Clark Nelson last week. Clark has worked on improving the aliasing parts
of the C specification in the past, for example i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
--- Comment #9 from joseph at codesourcery dot com ---
The rule certainly has nothing to do with whether the struct types are
defined inside the union definition, or defined outside and then used
inside via a tag or typedef.
The "it is permitt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
--- Comment #8 from Martin Sebor ---
If one of you can explain the problem with it I'm willing to write up a paper
and submit it to WG14 and request to have the standard changed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
Richard Biener changed:
What|Removed |Added
Keywords||alias
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
--- Comment #6 from Martin Sebor ---
I agree it's subtle and could be clearer but I believe the key phrase is "a
union contains several structures." Here, the term "union" refers to the type,
not the object. This is supported by the use of the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
--- Comment #5 from Andrew Pinski ---
(In reply to Martin Sebor from comment #4)
> Thanks for the pointer! I had looked for a related bug report but couldn't
> find it.
>
> There's an important difference between the test cases in pr14319 and t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
Martin Sebor changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|DUPLICATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
--- Comment #3 from Andrew Pinski ---
Also if we follow that defect resolution, basically strict aliasing does not
mean anything any more and we would have to turn off strict aliasing for all
structs.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
--- Comment #1 from Andrew Pinski ---
Some folks think that resolution is not fully correct.
63 matches
Mail list logo
