[Bug c/52023] New: _Alignof (double) yields wrong value on x86

[Bug c/52023] New: _Alignof (double) yields wrong value on x86

[eggert at gnu dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52023

             Bug #: 52023
           Summary: _Alignof (double) yields wrong value on x86
    Classification: Unclassified
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Severity: major
          Priority: P3
         Component: c
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: eggert@gnu.org
              Host: x86-64
            Target: x86
             Build: x86-64


Created attachment 26482
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26482
gcc -v output

On x86, alignof (double) should be 4, since that's the alignment
requirement used for 'double' when laying out structures.  But with
GCC alignof incorrectly returns 8.  This causes some gnulib tests to fail
and (more importantly) it may cause problems with programs such as
conservative garbage collectors that use alignof to determine which
addresses might be of valid objects.

The problem also occurs with other fundamental types, such as 'long long'.

Here's a simple test case:

  #include <stddef.h>
  #include <stdalign.h>
  int a = alignof (double);
  int b = offsetof (struct { char c; double d; }, d);
  int main (void) { return a == b; }

Here's the preprocessed output:

  int a = _Alignof (double);
  int b = __builtin_offsetof (struct { char c; double d; }, d);
  int main (void) { return a == b; }

'main' should return 1, but it returns 0 due to the bug, which causes
'a' to be 8 instead of 4 as it should be.

I'm using GCC on the trunk (r183603), built on Fedora 16 x86-64 with
no special flags, and I'm compiling with 'gcc -v -m32 test.c' and
running with './a.out'.  I'm attaching the output of 'gcc -v'.

[Bug target/52023] _Alignof (double) yields wrong value on x86

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52023

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
          Component|c                           |target
         Resolution|                            |INVALID
           Severity|major                       |normal

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> 2012-01-27 18:49:01 UTC ---
I don't think this is a bug, the alignment requirements in a struct can be
different from outside of a struct.

On PowerPC-darwin (and powerpc-aix) those testcases will fails also because the
struct alignment is different dependent on the placement of the double.

Summary: Don't depend on the alignment of the field's type but rather the field
itself.

[Bug target/52023] _Alignof (double) yields wrong value on x86

[bruno at clisp dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52023

bruno at clisp dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bruno at clisp dot org

--- Comment #2 from bruno at clisp dot org 2012-01-27 21:01:11 UTC ---
I can reproduce the bug with gcc version 4.7-20120121 (snapshot) for x86.
Test program:

===================================================
#include <stdint.h>
#include <stdio.h>
#include <stddef.h>
#include <stdalign.h>
int main ()
{
  typedef struct { char slot1; int64_t slot2; } int64_t_helper;
  typedef struct { char slot1; double slot2; } double_helper;
  printf ("%d %d %d\n",
          alignof (int64_t),
          offsetof (int64_t_helper, slot2),
          alignof (int64_t) == offsetof (int64_t_helper, slot2));
  printf ("%d %d %d\n",
          alignof (double),
          offsetof (double_helper, slot2),
          alignof (double) == offsetof (double_helper, slot2));
}
===================================================
Actual output:
8 4 0
8 4 0
Expected output:
4 4 1
4 4 1

(In reply to comment #1)
> I don't think this is a bug, the alignment requirements in a struct can be
> different from outside of a struct.

You could argue like this for __alignof__ which is a GCC invention.

But since ISO C11 and since <stdalign.h> is included, we have to look what
ISO C11 says about it. Citing the latest draft of it (n1570.pdf):

6.5.3.4.(3)
  "The _Alignof operator yields the alignment requirement of its operand type.
The
   operand is not evaluated and the result is an integer constant. When applied
to
   an array type, the result is the alignment requirement of the element type."

3.2 alignment
  "requirement that objects of a particular type be located on storage
boundaries
   with addresses that are particular multiples of a byte address"

3.15 object
  "region of data storage in the execution environment, the contents of which
   can represent values"

As a consequence of these definitions, the alignment of a type inside a struct
could be a multiple of _Alignof(type), but the alignment of a type inside a
struct
cannot be less than _Alignof(type).

In other words, if
  alignof (double) == 8
then every 'double' object in memory must be on an address that is a multiple
of 8.
Then objects inside the 'double_helper' type must also always be at addresses
that
are a multiple of 8. Which by the rules for structs means that
  alignof (double_helper)
and
  offsetof (double_helper, slot2)
must both be multiples of 8.

More about structs in ISO C11:

6.7.2.1.(6)
  "a structure is a type consisting of a sequence of members, whose
   storage is allocated in an ordered sequence"

6.7.2.1.(14)
  "Each non-bit-field member of a structure or union object is aligned in an
   implementation-defined manner appropriate to its type."

Note the last part of the last sentence: "appropriate to its type". The
implementation does not have the freedom to ignore the type's alignment
when deciding about offsetof of a member in a struct.

Please reopen this bug. (I cannot find how to do this witin the bugzilla GUI.)

[Bug target/52023] _Alignof (double) yields wrong value on x86

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52023

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|INVALID                     |DUPLICATE

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> 2012-01-27 21:06:39 UTC ---
This is really a dup of the old bug 10360:
 A meaningless number.  Because "the alignment used by the compiler"
 is going to depend on the context in which it is used.

*** This bug has been marked as a duplicate of bug 10360 ***

[Bug target/52023] _Alignof (double) yields wrong value on x86

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52023

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> 2012-01-27 21:09:53 UTC ---
One more comment about _Alignof and structures.
Take the following two structures on powerpc-aix (and on powerpc-darwin):
struct
{
  double d;
  int i;
};

struct
{
  int i;
  double d;
};

They have two different alignments.  The first one is the alignment of double
and the second is alignment of int.  This is because is how the ABI documents
alignment works.

[Bug target/52023] _Alignof (double) yields wrong value on x86

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52023

--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> 2012-01-27 21:13:29 UTC ---
(In reply to comment #4)
It gets even worse with the following two structures:
struct
{
  double d;
  char i;
  double d1;
  int i1;
};

struct
{
  char i;
  double d;
  char i1;
  double d1;
};

The second one is packed into 4 byte alignment so the sizeof is 3*8 while the
first one is sizeof is 4*8.  So powerpc-aix's alignof double depends on it is a
field or not and which field of the structure is first.

[Bug target/52023] _Alignof (double) yields wrong value on x86

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52023

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |DUPLICATE

--- Comment #7 from Andrew Pinski <pinskia at gcc dot gnu.org> 2012-01-27 21:49:59 UTC ---
What happens if you have the attribute packed on the structure?  Then guess
what _Alignof should always return 1 for all types end of story according to
how you interrupt the C standard.
The alignment requirement for double is 8 end of story.  But the alignment in
structures is 4.  Those can be different as far as I can tell.  And yes it is a
dup because of the same reason why GCC's alignof and _Alignof are the same and
are supposed to be the same.

*** This bug has been marked as a duplicate of bug 10360 ***

[Bug target/52023] _Alignof (double) yields wrong value on x86

[eggert at gnu dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52023

eggert at gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|DUPLICATE                   |

--- Comment #6 from eggert at gnu dot org 2012-01-27 21:44:23 UTC ---
This is not a duplicate of Bug 10360 because that was about
__alignof__, but this one is about the C11 standard _Alignof/alignof.
GCC can assign whatever meaning it likes to __alignof__ but for
_Alignof/alignof it should conform to the standard.  I agree with
Bruno that the bug should be reopened and for now I'm taking the
liberty of doing that until the matter is thought through more
carefully.

In C11, alignof(T) does not mean "the smallest alignment that will
used for T in certain contexts".  It means "the alignment requirement
for T", period; see C11 section 6.5.3.4 paragraph 3.  This alignment
requirement applies to "every object of that type"; see section 6.2.8
paragraph 1.  Members of structures are objects; see section 6.2.5
paragraph 20; and non-bitfield members have addresses and therefore
these addresses must be multiples of their types' alignments.

In short, GCC's behavior clearly conflicts with C11 here.

Andrew gave good ABI examples, where GCC uses different alignments for
T depending on context.  There's nothing wrong with GCC doing that.
All that's required by the standard is that if objects of type T
sometimes have alignment X, and sometimes Y, then alignof(T) must
yield the minimum of X and Y.  (Otherwise, GCC could simply return,
say, 2**20 for alignof(X) regardless of X, on the theory that in
*some* contexts the alignment is 2**20. :-)

Also, this is not simply a question of the C standard.  The GCC manual
says says (about __alignof__) that it "reports the smallest alignment
that GCC will give the data type".  It does not say "the smallest
alignment that GCC will give the data type outside of a struct".  If
the intent is that __alignof__ is supposed to be useful only for some
contexts in a C program, and not others, then the intent conflicts
with GCC's documentation, and either the behavior or the documentation
should be fixed for __alignof__.

As a practical matter, what would be the point of having alignof yield
a value that's greater than the alignment that GCC actually uses for
objects?  What kind of programs would actually make use of this
behavior?  I can certainly think of programs it would *break*, e.g., a
conservative garbage collector that uses alignof to test whether a
purported pointer is actually valid.  On balance, it seems that it'd
be better to conform to the standard here, instead of having a
nonstandard interpretation of alignof.

[Bug target/52023] _Alignof (double) yields wrong value on x86

[eggert at gnu dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52023

eggert at gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|DUPLICATE                   |

--- Comment #8 from eggert at gnu dot org 2012-01-27 22:13:13 UTC ---
> What happens if you have the attribute packed on the structure?

That's not relevant to the standard conformance issue.
Any program that uses __attribute__((packed)) is not a C11 program,
and for such programs C11 does not specify what alignof(double) returns.
The most useful thing for alignof to return is the value that it would return
ignoring the presence of 'packed', as that makes its behavior
simpler and more consistent.  Most likely, if a future version of
C11 specifies structure packing, it'll specify precisely this behavior
for alignof, as it wouldn't be useful to have alignof(X) always return 1.

For strict C11 programs, though, _Alignof(double) cannot return 8 on x86 hosts,
because GCC sometimes allocate 'double' objects on boundaries that
are merely multiples of 4.  The test programs in comment#1 are strict
C11 programs and illustrate the conformance bug.

[Bug target/52023] _Alignof (double) yields wrong value on x86

[bruno at clisp dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52023

--- Comment #9 from bruno at clisp dot org 2012-01-27 22:39:01 UTC ---
(In reply to comment #7)
> What happens if you have the attribute packed on the structure?

Attribute 'packed' is outside the scope of ISO C11. We're discussing ISO C11
compliant programs here.

ISO C11 has the _Alignas keyword, with which a stricter alignment can be
requested (ISO C11 6.2.8.(1), 6.7.5.(4)), but not a less strict alignment.

GCC's __alignof__ that returns the *preferred* alignment of an object of the
given type has its uses (in memory allocators for example). But the semantics
imposed by ISO C11 on the 'alignof' and '_Alignof' operators defined through
<stdalign.h> is address boundary requirement for all "objects" of that type,
not the preferred alignment.

[Bug target/52023] _Alignof (double) yields wrong value on x86

[joseph at codesourcery dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52023

--- Comment #10 from joseph at codesourcery dot com <joseph at codesourcery dot com> 2012-01-27 23:12:38 UTC ---
I don't think the test programs here are strictly conforming - the offset 
could be bigger than the alignment, and alignments are values 
"representing the number of bytes between successive addresses at which a 
given object can be allocated" which I don't think necessarily have 
literally to count bytes (they may be some other less direct encoding of 
alignment requirements that satisfies the requirements of 6.2.8).  But I 
think the bug is correct; alignof should return the least ABI alignment 
requirement for a type, which is the biggest requirement that the compiler 
can actually rely on when given a pointer to that type.

[Bug target/52023] _Alignof (double) yields wrong value on x86

[joseph at codesourcery dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52023

--- Comment #11 from joseph at codesourcery dot com <joseph at codesourcery dot com> 2012-01-27 23:26:39 UTC ---
I should add: as a matter of ABI compatibility with programs doing what 
stddef.h does for max_align_t (double fields using 
__attribute__((__aligned__(__alignof__(double)))), etc.), it probably is 
best to distinguish between _Alignof (least ABI alignment for a type) and 
__alignof__ (greatest ABI alignment for a type) here.  C++11 will need 
examining to determine what is right for alignof there.  _Alignas(type) 
should of course match _Alignof.  _Alignof (expr) - the C11 keyword 
applied in the GNU extension of alignof (expr) - should continue to have 
the present semantics in the various special cases where the expression 
references a declaration, but otherwise should probably match _Alignof.

[Bug c/52023] [C11] _Alignof (double) yields wrong value on x86

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52023

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2012-01-30
          Component|target                      |c
            Summary|_Alignof (double) yields    |[C11] _Alignof (double)
                   |wrong value on x86          |yields wrong value on x86
     Ever Confirmed|0                           |1

--- Comment #12 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-01-30 09:42:04 UTC ---
Confirmed thus, and a C frontend issue.

[Bug c/52023] [C11] _Alignof (double) yields wrong value on x86

[jsm28 at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52023

--- Comment #13 from Joseph S. Myers <jsm28 at gcc dot gnu.org> ---
Author: jsm28
Date: Wed Dec  4 22:57:20 2013
New Revision: 205685

URL: http://gcc.gnu.org/viewcvs?rev=205685&root=gcc&view=rev
Log:
    PR c/52023
c-family:
    * c-common.c (c_sizeof_or_alignof_type): Add parameter min_alignof
    and check field alignment if set.
    * c-common.h (c_sizeof_or_alignof_type): Update prototype.
    (c_sizeof, c_alignof): Update calls to c_sizeof_or_alignof_type.

c:
    * c-parser.c (c_parser_alignas_specifier): Use
    c_sizeof_or_alignof_type instead of c_alignof.
    (c_parser_alignof_expression): Likewise, with min_alignof
    parameter depending on alignof spelling used.

cp:
    * typeck.c (cxx_sizeof_or_alignof_type): Update call to
    c_sizeof_or_alignof_type.

objc:
    * objc-act.c (objc_synthesize_getter): Update calls to
    c_sizeof_or_alignof_type.

testsuite:
    * gcc.dg/c11-align-6.c: New test.

Added:
    trunk/gcc/testsuite/gcc.dg/c11-align-6.c
Modified:
    trunk/gcc/c-family/ChangeLog
    trunk/gcc/c-family/c-common.c
    trunk/gcc/c-family/c-common.h
    trunk/gcc/c/ChangeLog
    trunk/gcc/c/c-parser.c
    trunk/gcc/cp/ChangeLog
    trunk/gcc/cp/typeck.c
    trunk/gcc/objc/ChangeLog
    trunk/gcc/objc/objc-act.c
    trunk/gcc/testsuite/ChangeLog

[Bug c/52023] [C11] _Alignof (double) yields wrong value on x86

[jsm28 at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52023

Joseph S. Myers <jsm28 at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #14 from Joseph S. Myers <jsm28 at gcc dot gnu.org> ---
Fixed for 4.9.  The semantics of __alignof__ and C++11 alignof remain,
deliberately, the alignment used outside structures.

[Bug c/52023] [C11] _Alignof (double) yields wrong value on x86

[jsm28 at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52023

Joseph S. Myers <jsm28 at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.9.0

[Bug c/52023] [C11] _Alignof (double) yields wrong value on x86

[jbglaw@lug-owl.de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52023

Jan-Benedict Glaw <jbglaw@lug-owl.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jbglaw@lug-owl.de

--- Comment #15 from Jan-Benedict Glaw <jbglaw@lug-owl.de> ---
Some fallout for an unused variable, see eg.
http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=50585 :

g++ -c  -DIN_GCC_FRONTEND -DIN_GCC_FRONTEND -g -O2 -DIN_GCC 
-DCROSS_DIRECTORY_STRUCTURE  -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common 
-DHAVE_CONFIG_H -I. -Ic-family -I../../../gcc/gcc -I../../../gcc/gcc/c-family
-I../../../gcc/gcc/../include -I../../../gcc/gcc/../libcpp/include
-I/opt/cfarm/mpc/include  -I../../../gcc/gcc/../libdecnumber
-I../../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber
-I../../../gcc/gcc/../libbacktrace    -o c-family/c-common.o -MT
c-family/c-common.o -MMD -MP -MF c-family/.deps/c-common.TPo
../../../gcc/gcc/c-family/c-common.c
../../../gcc/gcc/c-family/c-common.c: In function ‘tree_node*
c_sizeof_or_alignof_type(location_t, tree, bool, bool, int)’:
../../../gcc/gcc/c-family/c-common.c:5007:9: error: unused variable ‘field’
[-Werror=unused-variable]
    tree field = build_decl (UNKNOWN_LOCATION, FIELD_DECL, NULL_TREE,
         ^
cc1plus: all warnings being treated as errors
>From gcc-bugs-return-436716-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Dec 05 10:00:25 2013
Return-Path: <gcc-bugs-return-436716-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 10885 invoked by alias); 5 Dec 2013 10:00:24 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 10762 invoked by uid 48); 5 Dec 2013 10:00:17 -0000
From: "y.gribov at samsung dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug bootstrap/59368] [4.9 Regression] libsanitizer spec file installed in the wrong place
Date: Thu, 05 Dec 2013 10:00:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: bootstrap
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords: build
X-Bugzilla-Severity: minor
X-Bugzilla-Who: y.gribov at samsung dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.9.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-59368-4-up7u3Bp448@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-59368-4@http.gcc.gnu.org/bugzilla/>
References: <bug-59368-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-12/txt/msg00371.txt.bz2
Content-length: 163

http://gcc.gnu.org/bugzilla/show_bug.cgi?idY368

--- Comment #6 from Yury Gribov <y.gribov at samsung dot com> ---
Dmitry, please close if trunk works for you.

[Bug c/52023] [C11] _Alignof (double) yields wrong value on x86

[mpolacek at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52023

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mpolacek at gcc dot gnu.org

--- Comment #16 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
(In reply to Jan-Benedict Glaw from comment #15)
> Some fallout for an unused variable, see eg.
> http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=50585 :
> 
> g++ -c  -DIN_GCC_FRONTEND -DIN_GCC_FRONTEND -g -O2 -DIN_GCC 
> -DCROSS_DIRECTORY_STRUCTURE  -fno-exceptions -fno-rtti
> -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
> -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long
> -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common 
> -DHAVE_CONFIG_H -I. -Ic-family -I../../../gcc/gcc
> -I../../../gcc/gcc/c-family -I../../../gcc/gcc/../include
> -I../../../gcc/gcc/../libcpp/include -I/opt/cfarm/mpc/include 
> -I../../../gcc/gcc/../libdecnumber -I../../../gcc/gcc/../libdecnumber/dpd
> -I../libdecnumber -I../../../gcc/gcc/../libbacktrace    -o
> c-family/c-common.o -MT c-family/c-common.o -MMD -MP -MF
> c-family/.deps/c-common.TPo ../../../gcc/gcc/c-family/c-common.c
> ../../../gcc/gcc/c-family/c-common.c: In function ‘tree_node*
> c_sizeof_or_alignof_type(location_t, tree, bool, bool, int)’:
> ../../../gcc/gcc/c-family/c-common.c:5007:9: error: unused variable ‘field’
> [-Werror=unused-variable]
>     tree field = build_decl (UNKNOWN_LOCATION, FIELD_DECL, NULL_TREE,
>          ^
> cc1plus: all warnings being treated as errors

Should be fixed now.
>From gcc-bugs-return-436735-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Dec 05 12:30:38 2013
Return-Path: <gcc-bugs-return-436735-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 7666 invoked by alias); 5 Dec 2013 12:30:37 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 7631 invoked by uid 48); 5 Dec 2013 12:30:33 -0000
From: "dimhen at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/59350] [4.9 regression] ICE: in vt_expand_var_loc_chain, at var-tracking.c:8212
Date: Thu, 05 Dec 2013 12:30:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: middle-end
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: dimhen at gmail dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.9.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-59350-4-zfl5t1hxjq@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-59350-4@http.gcc.gnu.org/bugzilla/>
References: <bug-59350-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-12/txt/msg00390.txt.bz2
Content-length: 141

http://gcc.gnu.org/bugzilla/show_bug.cgi?idY350

--- Comment #3 from Dmitry G. Dyachenko <dimhen at gmail dot com> ---
first FAIL r205461

[Bug c/52023] [C11] _Alignof (double) yields wrong value on x86

[jbglaw@lug-owl.de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52023

--- Comment #17 from Jan-Benedict Glaw <jbglaw@lug-owl.de> ---
(In reply to Marek Polacek from comment #16)
> >     tree field = build_decl (UNKNOWN_LOCATION, FIELD_DECL, NULL_TREE,
> >          ^
> > cc1plus: all warnings being treated as errors
> 
> Should be fixed now.

No, not yet. The most recent build for powerpc64-darwin done by my build robot
still faces this warning and thus breaks:

http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=89063

-->
http://toolchain.lug-owl.de/buildbot/deliver_artifact.php?mode=view&id=733877

So what shall we do with this? The macro is called with two arguments, of which
one ("field") isn't used. Just mark it as unused or (void)-cast it away?

[Bug c/52023] [C11] _Alignof (double) yields wrong value on x86

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52023

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #18 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(void) cast it away in the Darwin macro.  But that is tracked already in
PR59496.