This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: noalias macro bug [was: Linux and aliasing?]


mark@codesourcery.com wrote:
> First, it's silly to keep saying this.  We're outside standard
> behavior, so "proof" based on standardese is not an issue.  Documented
> behavior is one issue, and the code in GCC itself is another issue.

Aren't we talking about conformant code?

I thought you were arguing from within standard behaviour -- that
`noalias' was supposed to be a clean, conformant version of the
"torvalds cast".

I had no idea we were relying on a GCC extension already! :-)

> You *are* wrong, w.r.t. GCC; the "proof" is in GCC's code.

Let's not go there.
Documentation I'll accept, undocumented compiler behaviour I won't.
We have too many problems due to that already.

>     Jamie> "The practice of reading a different union member than the
>     Jamie> one most recently written..."
> 
>     Jamie> That does not apply -- in the example, no union member was
>     Jamie> written.
> 
> Agreed, from a very language-lawyer-like point-of-view.  That is a
> flaw in the manual's wording.  Please submit a patch, if you like.
> The idea is that *all* accesses through a union type are permitted to
> access any of the unionized fields.

I still don't get the wording.
Do you mean "permitted to access *any objects with the same type* as the
unionized fields" or not?

The distinction is critical.

I might submit a patch if I knew the answer.
If it is undocumented GCC-specific behaviour that may or may not change,
only the C++ frontend maintainers know it.

> Irrelevant.  This is a struct, so x and y are not at the same address.
> Neither is `a'.  Type-based aliasing has nothing to do with this.  The
> reasons these things don't alias is that they are different objects.

Summary
-------

Is there a decent bit of freely available text explaining what
-fstrict-aliasing means?

The manual, as currently written, isn't clear.  It doesn't guarantee
`noalias' will work.  You say it does.

I believe you since you are the expert, but I can't see it from your
explanation.

I'm worried when you say `noalias' is outside standard behaviour, since
it means we're depending on undocumented GCC-specific behaviour.
Clearly we don't want to do that.

-- Jamie


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]