This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
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