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
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
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
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
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
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
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
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
>
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
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
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
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
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
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
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
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,
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 ---
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
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:
>
>
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
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
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:
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
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
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
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
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
---
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
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
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
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
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:
>
>
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 #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
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
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
Melissa changed:
What|Removed |Added
CC||myriachan at gmail dot com
--- Comment #12
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
Marek Polacek mpolacek at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |SUSPENDED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
--- Comment #10 from Martin Sebor msebor at gcc dot gnu.org ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
--- Comment #9 from joseph at codesourcery dot com 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Keywords||alias
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
--- Comment #8 from Martin Sebor msebor at gcc dot gnu.org ---
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
Martin Sebor msebor at gcc dot gnu.org changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
--- Comment #6 from Martin Sebor msebor at gcc dot gnu.org ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
--- Comment #5 from Andrew Pinski pinskia at gcc dot gnu.org ---
(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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
Andrew Pinski pinskia at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
--- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org ---
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
--- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org ---
Some folks think that resolution is not fully correct.
63 matches
Mail list logo