This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug c/61447] _Alignof returns incorrect results for some types/archs
- From: "bugdal at aerifal dot cx" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Sun, 08 Jun 2014 15:47:52 +0000
- Subject: [Bug c/61447] _Alignof returns incorrect results for some types/archs
- Auto-submitted: auto-generated
- References: <bug-61447-4 at http dot gcc dot gnu dot org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61447
--- Comment #4 from Rich Felker <bugdal at aerifal dot cx> ---
Indeed, I can't reproduce that aspect of the problem now. My best guess is that
I accidentally used "gcc" rather than "gcc-4.9" for the test without -std=c11.
I'll post a follow-up comment if I do find such a problem again.
Back to the issue of _Alignof(object) however, I'm not so sure that your
interpretation of the standard is correct anymore. At the very least the
standard is ambiguous. 6.3.2.1 Lvalues, arrays, and function designators,
paragraph 2, reads:
"Except when it is the operand of the sizeof operator, the _Alignof operator,
the unary & operator, the ++ operator, the -- operator, or the left operand of
the . operator or an assignment operator, an lvalue that does not have array
type is converted to the value stored in the designated object (and is no
longer an lvalue); this is called lvalue conversion."
This text does not make sense if an expression cannot be the operand of
_Alignof. It's very possible that this is just residual cruft that should have
been removed, but it would be nice to get some clarification on whether, from
the committee's standpoint, the error is the presence of the above text or the
omission of text about how _Alignof handles an argument that's not a type.