[Bug c/61447] New: _Alignof returns incorrect results for some types/archs

[Bug c/61447] New: _Alignof returns incorrect results for some types/archs

[bugdal at aerifal dot cx]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61447

            Bug ID: 61447
           Summary: _Alignof returns incorrect results for some
                    types/archs
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: bugdal at aerifal dot cx

_Alignof is defined per C11 as the "alignment requirement of its operand type".
This is different from GCC's result for __alignof__ (and sometimes for
_Alignof) where it returns the "preferred alignment for optimization" or the
"actual alignment applied".

On i386, _Alignof(long long) returns 8, despite the correct value being 4. With
recent enough gcc (tested on 4.9.0), -std=c11 fixes _Alignof when applied to
the type name, but not when applied to an object: long long x; _Alignof(x)
still gives 8. In order to be correct:

1. _Alignof(object) should always be the same as _Alignof(__typeof__(object))

2. _Alignof(x) should always be the same as (sizeof(struct{char __a;
__typeof__(x) __b;}) - sizeof(x))

Failure of condition 2 results in observably incorrect behavior: a program can
observe the existence of a structure containing members a and b of the same
type where (char*)&foo.a-(char*)&foo.b is not a multiple of _Alignof(foo.a).

[Bug c/61447] _Alignof returns incorrect results for some types/archs

[joseph at codesourcery dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61447

--- Comment #1 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
ISO C does not define _Alignof (object), only _Alignof (type).

[Bug c/61447] _Alignof returns incorrect results for some types/archs

[bugdal at aerifal dot cx]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61447

--- Comment #2 from Rich Felker <bugdal at aerifal dot cx> ---
Indeed, you seem to be correct in that claim. However it seems desirable that
if this usage is not supported, it should be treated as a constraint violation
rather than silently producing a wrong/meaningless result that appears "right"
in most cases. In any case, I still think it's a bug that the wrong value is
being produced for _Alignof(long long) except with -std=c11. Even if earlier
versions of the standard have nothing to say about what it should produce, the
principle of least surprise says that it should produce the same result as it
does under C11 since only C11 defines _Alignof.

[Bug c/61447] _Alignof returns incorrect results for some types/archs

[joseph at codesourcery dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61447

--- Comment #3 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
What makes you think _Alignof depends on -std=c11 (other than for 
-pedantic diagnostics)?

I don't see any point in requesting alignment of an object, as opposed to 
a type, unless you want a result that can sometimes be bigger than what 
you get from _Alignof applied to the type.

[Bug c/61447] _Alignof returns incorrect results for some types/archs

[bugdal at aerifal dot cx]

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.

[Bug c/61447] _Alignof returns incorrect results for some types/archs

[schwab@linux-m68k.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61447

--- Comment #5 from Andreas Schwab <schwab@linux-m68k.org> ---
The reference to _Alignof in 6.3.2.1 does not exist in the final version of the
standard, according to Larry Jones in comp.std.c (Message-Id:
<ucvm2a-hig.ln1@jones.homeip.net> or
<https://groups.google.com/d/topic/comp.std.c/v5hsWOu5vSw/discussion>).

[Bug c/61447] _Alignof returns incorrect results for some types/archs

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61447

Marek Polacek <mpolacek at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |SUSPENDED
   Last reconfirmed|                            |2014-06-09
                 CC|                            |mpolacek at gcc dot gnu.org
     Ever confirmed|0                           |1

--- Comment #6 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
There are more references to _Alignof in the draft that are not in the final
version.  Anyway I think there isn't much to do for this PR right now, so
suspending for now until we have some conclusion about what should happen;
_Alignof (expr) is a GNU extension.  The thing is that in case of EXPR, we
always call c_alignof_expr, but that can't be told that it should produce the
least alignment required for a type of EXPR.  It wouldn't be hard to tweak it,
though.
Or should I close this one?

[Bug c/61447] _Alignof returns incorrect results for some types/archs

[joseph at codesourcery dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61447

--- Comment #7 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
I think _Alignof (expr) should, for example, return the larger alignment 
chosen with _Alignas in the case of a declaration using _Alignas, rather 
than just being based on the type.

[Bug c/61447] _Alignof returns incorrect results for some types/archs

[bugdal at aerifal dot cx]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61447

--- Comment #8 from Rich Felker <bugdal at aerifal dot cx> ---
There's already the GNU C __alignof__ which is free to do whatever GCC prefers,
so I fail to see the usefulness of making _Alignof do something nonstandard
(and IMO, utterly illogical) that might conflict with future standards. I would
prefer that __Alignof(expr) produce either an error, or
__Alignof(__typeof__(expr)).

[Bug c/61447] _Alignof returns incorrect results for some types/archs

[bugdal at aerifal dot cx]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61447

--- Comment #9 from Rich Felker <bugdal at aerifal dot cx> ---
As a related issue (let me know if I should open a new PR), the following code:

struct foo {
    char c;
    alignas(long long) long long ll;
};

is producing a wrong/nonsensical error with gcc 4.9:

error: '_Alignas' specifiers cannot reduce alignment of 'll'

Apparently (again) GCC wrongly internally thinks the alignment of long long is
8, rather than 4. With earlier gcc versions it simply gives the wrong alignment
(8 rather than 4).

[Bug c/61447] _Alignof returns incorrect results for some types/archs

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61447

--- Comment #10 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
(In reply to Rich Felker from comment #9)
> As a related issue (let me know if I should open a new PR), the following
> code:
> 
> struct foo {
>     char c;
>     alignas(long long) long long ll;
> };
> 
> is producing a wrong/nonsensical error with gcc 4.9:
> 
> error: '_Alignas' specifiers cannot reduce alignment of 'll'
> 
> Apparently (again) GCC wrongly internally thinks the alignment of long long
> is 8, rather than 4. With earlier gcc versions it simply gives the wrong
> alignment (8 rather than 4).

This should be already fixed: PR61053 (earlier this month I backported the fix
even to 4.9).