[Bug c++/87178] Compilation failure when program contains multiple variables allocated in particular section, and at least one variable is C++17 "inline"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87178 --- Comment #13 from roland at gnu dot org --- (In reply to Jakub Jelinek from comment #7) > (In reply to Jonathan Wakely from comment #6) > > OK. > > > > FWIW Clang seems to create two different sections called foo, one COMDAT and > > one not. > > Does it? That is I think impossible unless bypassing assembler. > If I try godbolt and look at clang++ trunk generated assembly, it doesn't > honor the user sections at all, whether using inline vars or not. Please see bug 116184 for a related case where neither Clang's assembler nor (at least current) GAS is an impediment to fixing the GCC bug. Both assemblers fully support two sections in different COMDAT groups that have the same section name. (Obviously, as this is the normal case for .rodata et al from C++ template instantiations.) GCC has the bug that it doesn't emit the correct `.section` directives when the section attribute is used, as fully demonstrated in bug 116184. This can be fixed in GCC and no assembler constraints prevent that working fine.
[Bug c++/116184] section attributes in COMDAT groups use wrong group name for multiple instances in same TU
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116184 roland at gnu dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE |--- --- Comment #5 from roland at gnu dot org --- Andrew, this is NOT a duplicate of any bug that should be marked INVALID. This is a different case for which the rationale given in the bug 87178 comments DOES NOT APPLY.
[Bug c++/116184] section attributes in COMDAT groups use wrong group name for multiple instances in same TU
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116184 roland at gnu dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE |--- CC||pinskia at gcc dot gnu.org --- Comment #3 from roland at gnu dot org --- This is not unfixable. It may be true that the assembler doesn't support emitting a non-COMDAT / non-group section and a section of the same name that's in a COMDAT group. But that's not the case that I reported. If I take the .s file from my case and edit the second `.section` directive to be correct, then the assembler generates a correct ELF file containing two separate `strings` sections, each in the correct COMDAT group.
[Bug c++/116184] New: section attributes in COMDAT groups use wrong group name for multiple instances in same TU
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116184
Bug ID: 116184
Summary: section attributes in COMDAT groups use wrong group
name for multiple instances in same TU
Product: gcc
Version: 14.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: roland at gnu dot org
Target Milestone: ---
This might belong in a different component. The test case here is in C++ but
the same thing probably arises with C(>=99) `extern inline` functions (and
static variables inside them) too. It might be specific to ELF targets, but
might also manifest the same way on any non-ELF targets that support the
section attributes. It doesn't seem to be specific to any particular subset of
ELF targets AFAICT.
Previously bug 94342 prevented `[[gnu::section("name")]]` (and other spellings)
in COMDAT group contexts (C `extern inline`, C++ `inline` and templates, etc.)
from honoring the named-section attribute. That's now been fixed, but this
exposed a new bug. Things work correctly when there is only one instance of an
entity in a named section in some COMDAT group in the TU. But when there are
multiple entities in one TU, they all wind up in the same COMDAT group instead
of the proper group for each entity.
This is currently observed using commit
973097d801a30385cd39a570624eefa7547f8ff3 from the 14 branch.
```
template
struct Chars {
static inline const char storage[] = {C..., '\0'};
static inline const char* const string [[gnu::section("strings")]] {storage};
};
const char* const* foo_string = <'f','o','o'>::string;
const char* const* bar_string = <'b','a','r'>::string;
```
Compiled with `g++ -std=c++17 -S` shows the issue straightforwardly:
```
...
.section
strings,"aG",@progbits,_ZN5CharsIJLc102ELc111ELc111EEE6stringE,comdat
.align 8
.type _ZN5CharsIJLc102ELc111ELc111EEE6stringE, @object
.size _ZN5CharsIJLc102ELc111ELc111EEE6stringE, 8
_ZN5CharsIJLc102ELc111ELc111EEE6stringE:
...
.section
strings,"aG",@progbits,_ZN5CharsIJLc102ELc111ELc111EEE6stringE,comdat
.align 8
.type _ZN5CharsIJLc98ELc97ELc114EEE6stringE, @object
.size _ZN5CharsIJLc98ELc97ELc114EEE6stringE, 8
_ZN5CharsIJLc98ELc97ELc114EEE6stringE:
...
```
Everything is right about both definitions, except that the group name in the
second `.section` directive matches the first symbol rather than the second.
[Bug c++/96868] C++20 designated initializer erroneous warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96868
roland at gnu dot org changed:
What|Removed |Added
CC||roland at gnu dot org
--- Comment #9 from roland at gnu dot org ---
IMHO there's a good case to be made for never warning for designated
initializers, even for fields that have uninitialized default-construction.
When using a designated initializer, `= {.a=value}` doesn't leave any field `b`
uninitialized, it initializes it as `= {}` would, i.e. safely zero for base
types, etc. When I write `= {.a=value}` that default-or-zero-initialization of
the other fields is exactly what I intended, and I know well that omitted
fields in an initializer are different from leaving the fields uninitialized.
Clearly opinions on this vary. It seems like it merits having separable option
configuration: `-Wmissing-field-initializers`,
`-Wmissing-designated-field-initializers`. If that flexibility is available,
then it's of less concern what the default state with just
`-Wmissing-field-initializers` or `-Wextra` is.
The separate question remains whether "missing initializer" vs "missing
(explicit) initialization" should also be distinguished differently in the
available warning states than what we have today. I don't have much opinion
about that one as long as there's a way for me to say that:
```
struct s { int a, b; };
s foo = {.a=1};
```
is acceptable without warning in C++, even if it requires a different option
state than to accept:
```
struct s { int a; int b = 0; };
s foo = {.a=1};
```
[Bug middle-end/105762] New: [12 Regression] -Warray-bounds false positives for integer-to-pointer casts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105762
Bug ID: 105762
Summary: [12 Regression] -Warray-bounds false positives for
integer-to-pointer casts
Product: gcc
Version: 12.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: roland at gnu dot org
Target Milestone: ---
This code:
```
void crash(void) {
volatile int* ptr = (volatile int*)1ul;
*ptr = 1;
}
```
now gets:
```
warning: array subscript 0 is outside array bounds of 'volatile int[0]'
[-Warray-bounds]
```
This is a regression since GCC 11.
Reproduced on aarch64-elf and x86_64-elf targets as of 12 branch commit
2c11a9a380e7af333e19d6e576a889646d699b2a
[Bug target/94993] aarch64 incompatible with -mgeneral-regs-only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94993
roland at gnu dot org changed:
What|Removed |Added
CC||rearnsha at gcc dot gnu.org
--- Comment #2 from roland at gnu dot org ---
I'm still seeing this in current 11 branch. I had been using a workaround
kludge that sufficed on the 10 branch but no longer does the trick in 11. What
I did to work around it is dropped `-mgeneral-regs-only` and instead used a
`-include` file to inject:
```
#pragma GCC push_options
#pragma GCC target ("general-regs-only")
```
at the top of each translation unit. Then, I use:
```
#pragma GCC pop_options
#include
#pragma GCC push_options
#pragma GCC target ("general-regs-only")
```
This worked OK in 10. However, now in 11 I see a few functions that still use
vector registers. One example I noted was the implicitly-defined function for
running some static constructors, which might be outside any "parsing state"
where the `#pragma GCC target` state would apply. The other example I found
was in a lambda function, which ISTM should have been affected by the pragma.
Rather than debug the workaround, I'd prefer to get the real bug fixed. Is
there any hope of this? Given that C handles it OK, it seems like it shouldn't
be too hard to make C++ use matching logic, but that may be wishful thinking.
[Bug c++/103291] New: gcc 11 regression with #pragma GCC visibility vs extern inside C++ functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103291
Bug ID: 103291
Summary: gcc 11 regression with #pragma GCC visibility vs
extern inside C++ functions
Product: gcc
Version: 11.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: roland at gnu dot org
Target Milestone: ---
GCC 11 has a regression with:
```
#pragma GCC visibility push(hidden)
int hidden_fetch(void) {
extern const int hidden_global;
return hidden_global;
}
```
when compiled with -fpic. GCC 10 would always avoid the GOT for this case. GCC
11 avoids the GOT when it's compiled as C, but uses the GOT when it's compiled
as C++. Moving the extern decl outside the function makes it dtrt again in C++
as well.
Reproduced on trunk at 4cdf7db9a39d18bd536d816a5751d4d3cf23808b and on 11
branch at b52e2254b30445f3cd667ae0f0d99b183394e37b.
[Bug c++/103290] New: gcc 11 regression with C++ designated initializers, unions, anonymous struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103290
Bug ID: 103290
Summary: gcc 11 regression with C++ designated initializers,
unions, anonymous struct
Product: gcc
Version: 11.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: roland at gnu dot org
Target Milestone: ---
```
struct S {
union {
struct {
unsigned short x;
} s;
};
};
S foo() {
S x = {.s = {.x = 1}};
return x;
}
```
with g++
produces error: 'S::' has no non-static data member named 'x'
This is a regression from GCC 10. The same code compiled as C still works.
Reproduced on trunk at 4cdf7db9a39d18bd536d816a5751d4d3cf23808b and on 11
branch at b52e2254b30445f3cd667ae0f0d99b183394e37b.
[Bug target/96238] [i386] cpuid.h header needs include guards
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96238 roland at gnu dot org changed: What|Removed |Added CC||roland at gnu dot org --- Comment #4 from roland at gnu dot org --- Can at least the header guard fix be backported to 10?
[Bug c++/94342] GCC ignores attribute((section(...))) for static variables inside templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94342 roland at gnu dot org changed: What|Removed |Added CC||roland at gnu dot org --- Comment #12 from roland at gnu dot org --- I think the correct behavior here is clear for ELF targets, which is what Clang does. Using section attributes always highly target-specific semantics, so I think it would be fine for it to continue to behave as it does now for non-ELF targets or to give a diagnostic. With ELF COMDAT semantics, I think it's straightforward and obviously consistent with general use of COMDAT what you'd want here, so I don't see any controversy here. Is this difficult to implement?
[Bug target/94993] New: aarch64 incompatible with -mgeneral-regs-only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94993 Bug ID: 94993 Summary: aarch64 incompatible with -mgeneral-regs-only Product: gcc Version: 10.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: roland at gnu dot org Target Milestone: --- This is a regression from 9.3.1. Using --target=aarch64-elf built from git commit 6fedf28c7921f125be75a9f688a7b845a1b5663b. aarch64-elf-g++ -mgeneral-regs-only -S -o /dev/null -xc++ <(echo '#include ') fails with various unrecognized builtins. The target attribute/pragma doesn't accept "no-general-regs-only", so I'm not sure how to fix it.
[Bug c++/85662] [8/9 Regression] "error: non-constant condition for static assertion" from __builtin_offsetof in C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85662
roland at gnu dot org changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED |---
--- Comment #9 from roland at gnu dot org ---
Both my original test case and Jakub's smaller case do hit the bug in gcc 7.
I just tested the current gcc-7-branch: commit
c66c7f7b6f41118cef03ece0c367554eb38c3d65
On x86_64-linux-gnu:
$ ../../gcc/configure --enable-languages=c,c++,lto
$ make all-gcc
$ ./gcc/xgcc -Bgcc/ -O2 -S bar.cc
bar.cc:3:1: error: non-constant condition for static assertion
static_assert (__builtin_offsetof (T, f.x[31 - 1]) == __builtin_offsetof (T,
f.x[30]), "");
^
bar.cc:3:1: error: value ‘8’ of type ‘T*’ is not a constant expression
[Exit 1]
$ cat bar.cc
struct S { unsigned long x[31]; };
struct T { bool b; S f; };
static_assert (__builtin_offsetof (T, f.x[31 - 1]) == __builtin_offsetof (T,
f.x[30]), "");
$
[Bug c++/85662] [8/9 Regression] "error: non-constant condition for static assertion" from __builtin_offsetof in C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85662 --- Comment #6 from roland at gnu dot org --- Thanks for the fix. What's the status on backporting this to 8 and/or 7?
[Bug c++/85662] [8/9 Regression] "error: non-constant condition for static assertion" from __builtin_offsetof in C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85662 --- Comment #4 from roland at gnu dot org --- That fix (applied to trunk) works for my test case and for the original real-world case I reduced it from. Will it be backported to 7 and 8? Thanks for the quick work as usual, Jakub!
[Bug c++/85662] New: regression since 6: "error: non-constant condition for static assertion" from __builtin_offsetof in C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85662
Bug ID: 85662
Summary: regression since 6: "error: non-constant condition for
static assertion" from __builtin_offsetof in C++
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: roland at gnu dot org
CC: msebor at gcc dot gnu.org
Target Milestone: ---
This code was accepted by GCC 6 but is rejected by GCC 7, 8, and trunk.
The error message appears to complain that the result of the __builtin_offsetof
expression has pointer type rather than size_t.
$ cat foo.cc
struct foo {
unsigned long x[31];
};
struct bar {
bool b;
foo f;
};
static_assert(__builtin_offsetof(bar, f.x[31 - 1]) == 8 + ((31 - 1) * 8), "");
$ ./gcc/xgcc -Bgcc/ -O2 -S foo.cc
foo.cc:10:52: error: non-constant condition for static assertion
static_assert(__builtin_offsetof(bar, f.x[31 - 1]) == 8 + ((31 - 1) * 8), "");
~^
foo.cc:10:52: error: value ‘8’ of type ‘bar*’ is not a constant expression
[Exit 1]
The equivalent C code:
struct foo {
unsigned long x[31];
};
struct bar {
_Bool b;
struct foo f;
};
_Static_assert(__builtin_offsetof(struct bar, f.x[31 - 1]) == 8 + ((31 - 1) *
8), "");
is accepted without complaint.
bisected to r238909 (git cb7688247fdcff08df18baed1317fce5b0e9db13)
gcc/cp/ChangeLog
2016-07-30 Martin Sebor <mse...@redhat.com>
PR c++/60760
PR c++/71091
* constexpr.c (cxx_eval_binary_expression): Reject invalid expressions
involving null pointers.
(cxx_eval_component_reference): Reject null pointer dereferences.
(cxx_eval_indirect_ref): Reject indirecting through null pointers.
(cxx_eval_constant_expression): Reject invalid expressions involving
null pointers.
[Bug target/80298] incompatible with -mno-sse
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80298
--- Comment #4 from roland at gnu dot org ---
I'd assumed it would be fixed just with more #pragma push_options,
target("sse"), pop_options, sequences.
It seems like a separate issue about automagically allowing things in
always_inline cases, and I'm not at all sure that is a general case that ought
to be fixed.
[Bug target/80298] New: incompatible with -mno-sse
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80298 Bug ID: 80298 Summary: incompatible with -mno-sse Product: gcc Version: 6.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: roland at gnu dot org Target Milestone: --- For any x86_64 target, try: gcc -mno-sse -S -o - -xc <(echo '#include ') It fails with various errors about SSE being disabled. Many of the components of x86intrin.h make special efforts to ensure that they can be compiled without the associated code-generation features being enabled on the command line, but some of them fail to do so.
[Bug target/79619] New: store via pointer obtained from alternate address space offset 0 dropped
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79619
Bug ID: 79619
Summary: store via pointer obtained from alternate address
space offset 0 dropped
Product: gcc
Version: 6.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: roland at gnu dot org
CC: rth at gcc dot gnu.org
Target Milestone: ---
Target: x86_64-elf
Given this test code:
void bug(void) {
*(*(char*__seg_fs*)0) = 1;
}
void nobug(void) {
*(*(char*__seg_fs*)0) = 1;
*(*(char*__seg_fs*)8) = 1;
}
I get this:
.text
.globl bug
.type bug, @function
bug:
.LFB0:
.cfi_startproc
rep ret
.cfi_endproc
.LFE0:
.size bug, .-bug
.globl nobug
.type nobug, @function
nobug:
.LFB1:
.cfi_startproc
movq%fs:0, %rax
movb$1, (%rax)
movq%fs:8, %rax
movb$1, (%rax)
ret
.cfi_endproc
.LFE1:
.size nobug, .-nobug
.ident "GCC: (GNU) 6.2.0"
x86_64 GCC at -O1 or better silently elides the store in bug. My guess is that
it's deciding *(TYPE __seg_fs*)0 constitutes a null pointer dereference and is
therefore UB so screw everybody. But alternate-address-space 0 is not a null
pointer, it's just like any other alternate-address-space pointer value and
should not be treated specially. (Except that if you wanted to "know" that the
target ABI is that %fs:0 == %fs.base, then you can optimize
(*(char*__seg_fs*)0)[n] accesses to direct "%fs:n"; LLVM does this for x86-64
glibc-based targets. But that's a missed optimization opportunity unrelated to
this bug.)
But note how the mere presence of a different alternate-address-space reference
not at zero in the same function (nobug) makes it emit both stores! Definitely
fishy.
Maybe related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66768 but that's
beyond my ken.
[Bug target/79609] C address space qualifiers not available under -fno-asm, even for system headers and __extension__
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79609
--- Comment #1 from roland at gnu dot org ---
Note Clang uses __attribute__((address_space(N))) for this. That automagically
handles the parsing issues in a well-known fashion, and gets C++ support for
free to boot.
Unfortunately they use per-target magic integer values to select among
predefined address spaces, with no symbolic syntax (just documented magic
values). You could e.g. change the __SEG_FS predefine to be the magic number,
so that it's __attribute__((address_space(__SEG_FS))) and macroable-compatible
with Clang. Or you could be more classy and take string values
__attribute__((address_space("fs"))).
[Bug c/79609] New: C address space qualifiers not available under -fno-asm, even for system headers and __extension__
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79609 Bug ID: 79609 Summary: C address space qualifiers not available under -fno-asm, even for system headers and __extension__ Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: roland at gnu dot org CC: rth at gcc dot gnu.org Target Milestone: --- It's impossible to use __seg_fs et al under -fno-asm, which is implied by e.g. -std=c11. It's ironic that it's still possible to use __asm or __asm__ under -fno-asm, but not another feature not called "asm" that also uses an __ prefix. IMHO __seg_fs et al should be allowed in a decl/expression that uses __extension__. That's what __extension__ is for. There could also be a system header exception, but those are awful and shouldn't be added for new syntax not already wrongly used in someone's system headers. Having header writers use __extension__ judiciously is much better.
[Bug other/77609] __attribute__((section(".note.foo"))) forces SHT_PROGBITS though the assembler would use SHT_NOTE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77609 --- Comment #3 from roland at gnu dot org --- https://gcc.gnu.org/ml/gcc-patches/2016-09/msg00981.html
[Bug other/77609] __attribute__((section(".note.foo"))) forces SHT_PROGBITS though the assembler would use SHT_NOTE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77609 --- Comment #1 from roland at gnu dot org --- Created attachment 39626 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39626=edit trunk fix This is the fix that shows the behavior difference reported above.
[Bug other/77609] New: __attribute__((section(".note.foo"))) forces SHT_PROGBITS though the assembler would use SHT_NOTE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77609
Bug ID: 77609
Summary: __attribute__((section(".note.foo"))) forces
SHT_PROGBITS though the assembler would use SHT_NOTE
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: roland at gnu dot org
Target Milestone: ---
When __attribute__((section("name"))) is used, GCC insists on setting the
section type explicitly. For various special section names, the assembler
would use a special type, but GCC doesn't know about those rules and forces
SHT_PROGBITS instead. An example is section names starting with ".note",
which the assembler gives type SHT_NOTE but GCC fails to. This makes it
impossible (without heinous shenanigans) to use an initialized C variable
declaration to emit an (allocated) ELF note.
GCC already has special cases for ".init_array", ".fini_array", and
".preinit_array", but that is a small subset of the full set of names (and
name patterns) for which the assembler uses a special type. The existing
special cases already rely on the assembler to choose the actual type. The
default type of SHT_PROGBITS that GCC forces on all others is already the
assembler's default for sections whose name is not special. So just
letting the assembler choose in all cases does the right thing now and will
do so in the future if any new types or special name patterns are added to
the assembler.
I'll attach a patch that does this.
Test case:
$ cat note.c
#define VENDOR "foobar"
struct mynote {
struct Elf32_Nhdr {
unsigned int n_namesz, n_descsz, n_type;
} hdr;
char name[sizeof(VENDOR)];
_Alignas(4) struct mynote_payload {
short int x;
} payload;
};
__attribute__((used, section(".note.foo")))
static const struct mynote foonote = {
.hdr = {
.n_namesz = sizeof(VENDOR),
.n_descsz = sizeof(struct mynote_payload),
.n_type = 17,
},
.name = VENDOR,
.payload = {
.x = 23,
},
};
$ ./gcc/xgcc -Bgcc/ -c -save-temps ../../gcc/note.c
$ cat note.s
.file "note.c"
==> .section.note.foo,"a",@progbits
.align 16
.type foonote, @object
.size foonote, 24
foonote:
.long 7
.long 2
.long 17
.string "foobar"
.zero 1
.value 23
.zero 2
.ident "GCC: (GNU) 7.0.0 20160915 (experimental)"
.section.note.GNU-stack,"",@progbits
$ readelf -WSn note.o
There are 10 section headers, starting at offset 0xd8:
Section Headers:
[Nr] Name TypeAddress OffSize
ES Flg Lk Inf Al
[ 0] NULL 00 00
00 0 0 0
[ 1] .text PROGBITS 40 00
00 AX 0 0 1
[ 2] .data PROGBITS 40 00
00 WA 0 0 1
[ 3] .bss NOBITS 40 00
00 WA 0 0 1
==> [ 4] .note.foo PROGBITS 40 18
00 A 0 0 16
[ 5] .comment PROGBITS 58 2a
01 MS 0 0 1
[ 6] .note.GNU-stack PROGBITS 82 00
00 0 0 1
[ 7] .shstrtab STRTAB 82 4f
00 0 0 1
[ 8] .symtab SYMTAB 000358 d8
18 9 9 8
[ 9] .strtab STRTAB 000430 10
00 0 0 1
Key to Flags:
W (write), A (alloc), X (execute), M (merge), S (strings), l (large)
I (info), L (link order), G (group), T (TLS), E (exclude), x
(unknown)
O (extra OS processing required) o (OS specific), p (processor
specific)
$
After my fix:
$ ./gcc/xgcc -Bgcc/ -c -save-temps ../../gcc/note.c
$ cat note.s
.file "note.c"
==> .section.note.foo,"a"
.align 16
.type foonote, @object
.size foonote, 24
foonote:
.long 7
.long 2
.long 17
.string "foobar"
[Bug other/63758] New: liblto_plugin.so has undefined reference to _environ on OSX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63758 Bug ID: 63758 Summary: liblto_plugin.so has undefined reference to _environ on OSX Product: gcc Version: 4.9.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: roland at gnu dot org Host: x86_64-apple-darwin Build: x86_64-apple-darwin11.4.2 Failure mode: .../bin/../lib/gcc/.../4.9.2/../../../../.../bin/ld: .../bin/../libexec/gcc/.../4.9.2/liblto_plugin.so: error loading plugin: dlopen(.../bin/../libexec/gcc/.../4.9.2/liblto_plugin.so, 2): Symbol not found: _environ Referenced from: .../bin/../libexec/gcc/.../4.9.2/liblto_plugin.so Expected in: flat namespace in .../bin/../libexec/gcc/.../4.9.2/liblto_plugin.so collect2:error: ld returned 1 exit status The references come from libiberty code (xmalloc.c and pex-unix.c). Using environ in a main program is fine, but it's documented on OSX that you cannot use it from a shared library. Instead, you must call the _NSGetEnviron function to return its address (which also works just as well in a main program). I have a working fix which I'll attach shortly.
[Bug other/63758] liblto_plugin.so has undefined reference to _environ on OSX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63758 --- Comment #1 from roland at gnu dot org --- Created attachment 33903 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33903action=edit proposed patch This patch fixes it on OSX. I haven't verified it on a wide variety of configurations.
[Bug target/61622] internal compiler error: in simplify_const_unary_operation, at simplify-rtx.c:1508
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61622 --- Comment #5 from roland at gnu dot org --- (In reply to baoshan from comment #4) This should be a duplication to Bug 57431. That report is for 4.9.x. The bug remains on 4.8.x.
[Bug target/61622] internal compiler error: in simplify_const_unary_operation, at simplify-rtx.c:1508
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61622 --- Comment #3 from roland at gnu dot org --- Oops! Meant to paste that: gcc/cc1 -fpreprocessed ref_vld1_dup.i -quiet -dumpbase ref_vld1_dup.i -mfloat-abi=softfp -mfpu=neon -mtls-dialect=gnu -auxbase ref_vld1_dup -O1 -std=gnu99 -version -o ref_vld1_dup.s
[Bug target/61622] New: internal compiler error: in simplify_const_unary_operation, at simplify-rtx.c:1508
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61622 Bug ID: 61622 Summary: internal compiler error: in simplify_const_unary_operation, at simplify-rtx.c:1508 Product: gcc Version: 4.8.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: roland at gnu dot org Target: arm-linux-gnueabihf This is with gcc-4_8-branch tip (98985e7). It also happens with 4.8.3. It does not happen with 4.7 or 4.9. GNU C (GCC) version 4.8.4 20140626 (prerelease) (arm-linux-gnueabihf) compiled by GNU C version 4.6.3, GMP version 5.0.2, MPFR version 3.1.0-p3, MPC version 0.9 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU C (GCC) version 4.8.4 20140626 (prerelease) (arm-linux-gnueabihf) compiled by GNU C version 4.6.3, GMP version 5.0.2, MPFR version 3.1.0-p3, MPC version 0.9 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: d86a8a8674f3db3f8fa6a19eba923eb3 ref_vld1_dup.i: In function ‘exec_vld1_dup’: ref_vld1_dup.i:13233:1: internal compiler error: in simplify_const_unary_operation, at simplify-rtx.c:1508 } ^ 0x7bdf69 simplify_const_unary_operation(rtx_code, machine_mode, rtx_def*, machine_mode) ../../../gcc/gcc/simplify-rtx.c:1508 0x7bbd14 simplify_unary_operation(rtx_code, machine_mode, rtx_def*, machine_mode) ../../../gcc/gcc/simplify-rtx.c:796 0xb1f9ca fold_rtx ../../../gcc/gcc/cse.c:3287 0xb21edc cse_insn ../../../gcc/gcc/cse.c:4573 0xb26b04 cse_extended_basic_block ../../../gcc/gcc/cse.c:6418 0xb26b04 cse_main ../../../gcc/gcc/cse.c:6596 0xb26fb6 rest_of_handle_cse ../../../gcc/gcc/cse.c:7446 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions. [Exit 4]
[Bug target/61622] internal compiler error: in simplify_const_unary_operation, at simplify-rtx.c:1508
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61622 --- Comment #1 from roland at gnu dot org --- Created attachment 33013 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33013action=edit test case preprocessed source I had to gzip the file to make bugzilla accept it.
[Bug libstdc++/59392] crash on throw from unexpected exception handler with ARM EABI unwinder
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59392 roland at gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from roland at gnu dot org --- Fixed on trunk and 4.8.
[Bug libstdc++/59392] crash on throw from unexpected exception handler with ARM EABI unwinder
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59392 --- Comment #2 from roland at gnu dot org --- Fix posted: http://gcc.gnu.org/ml/gcc-patches/2013-12/msg00753.html
[Bug libstdc++/59392] New: crash on throw from unexpected exception handler with ARM EABI unwinder
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59392 Bug ID: 59392 Summary: crash on throw from unexpected exception handler with ARM EABI unwinder Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: roland at gnu dot org Target: arm-linux-gnueabihf Created attachment 31382 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31382action=edit test case I've observed this on trunk and on 4.6.3, but I think the bug has been there since the introduction of ARM EABI unwinding in 4.2. The attached test case crashes with a null pointer dereference (producing no output) on ARM/EABI targets. On other targets (I only tested x86_64-linux-gnu), it correctly crashes via abort after emitting a message (i.e. std::terminate runs). The original case was more complex and used std::set_terminate to set a handler that used longjmp, avoiding the abort. For the test suite, it's probably most convenient to do that (or just exit with an expected code in the terminate handler) rather than to detect that the default std::terminate crash happened correctly vs a different crash. The bug comes about in an obvious and straightforward way. But I don't know the libsupc++ internals well enough to suggest an appropriate fix off hand. What happens is that libstdc++-v3/libsupc++/eh_call.cc:__cxa_call_unexpected does: if (catch_type-__do_catch(bad_exc, 0, 1)) i.e., passes a null pointer as the second argument to the __do_catch method. libstdc++-v3/libsupc++/class_type_info.cc:__do_catch passes this argument on as the second argument to __do_upcast. In libstdc++-v3/libsupc++/class_type_info.cc:__do_upcast there is: __do_upcast (dst_type, *obj_ptr, result); i.e., unconditionally dereferencing OBJ_PTR (the second argument). I'd like to see this get fixed on the trunk and 4.8 at least. I'd be glad to pursue the fix myself if I had any idea what it should be.
[Bug target/58486] New: insufficient CFI generated for call-saved VFP registers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58486
Bug ID: 58486
Summary: insufficient CFI generated for call-saved VFP
registers
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: roland at gnu dot org
Target: arm-linux-gnueabi
I think this bug exists in trunk and in all past versions (seen in 4.6, at
least), but I did the detailed testing on today's gcc-4_8-branch.
The DWARF CFI generated to describe the save/restore of the call-saved VFP
registers (d8-d15) is insufficient: it covers only half of each register.
Consider this test case:
__attribute__((noinline)) void foo(void) {
struct { unsigned i[2]; } x = { 0x, 0x };
asm(vldr d8, %0; bkpt :: m (x) : d8);
}
__attribute__((noinline)) void bar(void) {
struct { unsigned i[2]; } x = { 0x, 0x };
asm(vldr d8, %0 :: m (x) : d8);
foo();
}
int main(void) {
bar();
return 0;
}
Compiled with: gcc -O2 -g -marm -mfpu=neon -mhard-float
This gdb session demonstrates the failure:
$ cat foo.x
r
i reg s17
up
i reg s17
k
q
$ gdb -x foo.x foo
GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2.1) 7.4-2012.04
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type show copying
and show warranty for details.
This GDB was configured as arm-linux-gnueabihf.
For bug reporting instructions, please see:
http://bugs.launchpad.net/gdb-linaro/...
Reading symbols from /home/user/mcgrathr/foo...done.
Program received signal SIGTRAP, Trace/breakpoint trap.
0x838c in foo () at foo.c:3
3 asm(vldr d8, %0; bkpt :: m (x) : d8);
s17-0.00572916633(raw 0x)
#1 0x83c0 in bar () at foo.c:9
9 foo();
s17-0.00572916633(raw 0x)
Kill the program being debugged? (y or n) [answered Y; input not from
terminal]
The second display of s17 should show 0x, not 0x.
Examination of the prologue code shows:
@ for foo
fstmfddsp!, {d8}
.cfi_def_cfa_offset 8
.cfi_offset 80, -8
@ for bar
fstmfddsp!, {d8}
.cfi_def_cfa_offset 12
.cfi_offset 80, -12
The detailed analysis:
The 64-bit VFP registers d0-d15 use the same space as the 32-bit VFP
registers s0-s31. Hence, d8 is the same as the pair {s16,s17}.
80 is the DWARF register number for the 32-bit register s16. So this CFI
describes restoring only s16 but not s17, i.e. only half of d8, while the
code uses the full d8 register.
The spec at:
http://infocenter.arm.com/help/topic/com.arm.doc.ihi0040b/IHI0040B_aadwarf.pdf
says 64-95 are obsolescent DWARF register numbers for 32-bit registers
s0-s31. It recommends instead using the newly-assigned numbers 256-271 for
the 64-bit registers d0-d15, and describing e.g. s16 as number 264 (d8)
with DW_OP_piece to slice it in half (not relevant in CFI).
With the GDB version I have on hand, register number 264 for d8 does work
correctly. I'm not sure if there are older GDB versions that fail to
recognize that number. To be compatible with an older debugger that
doesn't know the 264+ range of DWARF register numbers, the other option is
to emit CFI for d8 as the two registers s16 and s17, e.g. (for foo above):
.cfi_offset 80, -8
.cfi_offset 81, -4
This also works with the GDB I have on hand.
[Bug libstdc++/57740] New: C++11 std::thread not usable with static linking
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57740 Bug ID: 57740 Summary: C++11 std::thread not usable with static linking Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: roland at gnu dot org Host: x86_64-linux-gnu Created attachment 30398 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30398action=edit test case This bug goes back at least to 4.6, but I don't really care about anything older than 4.8. On x86_64-linux-gnu (and others), the attached test works when compiled with: g++ -std=c++0x -pthread std_mutex.cc -o std_mutex but when compiled with: g++ -std=c++0x -static -pthread std_mutex.cc -o std_mutex it either throws an error or just crashes. The underlying problem is excessive use of weak references in gthr-posix.h. I already have a fix and a testsuite addition in hand and will post them to gcc-patches soon.
[Bug libstdc++/57740] C++11 std::thread not usable with static linking
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57740 --- Comment #2 from roland at gnu dot org --- (In reply to Andrew Pinski from comment #1) I think it is bad form to use static linking with pthreads. Nonsense. There is code specifically to ensure it works. The additions for C++11 thread interfaces just didn't do it right.
[Bug libstdc++/57740] C++11 std::thread not usable with static linking
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57740 --- Comment #4 from roland at gnu dot org --- weakrefs are right for the conditional cases. For the functions that underlie std::thread et al, it can never be meaningful to use those interfaces and fail to link with -lpthread. The Fedora hack just masks bugs like this one. It's not the right thing to do at all. The right thing is to fix the bugs. I have a fix, demonstrating it's certainly not impossible.
[Bug libstdc++/57740] C++11 std::thread not usable with static linking
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57740 --- Comment #5 from roland at gnu dot org --- So my draft fix actually breaks the dynamic case. For the unconditional calls, weak is right in the shared library but strong is right in the static library. But unlike normal libraries, libstdc++ goes out of its way to get compiled only once, using PIC-compiled objects in the static library too. So there is no obvious way for gthr-posix.h to behave differently in the static and shared cases, which is the only correct thing for it to do.
[Bug libstdc++/57740] C++11 std::thread not usable with static linking
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57740 --- Comment #7 from roland at gnu dot org --- (In reply to Jakub Jelinek from comment #6) Note also that libstdc++.a can be used together with libpthread.so or libstdc++.so with libpthread.a (g++ -static-libstdc++ etc.). If libstdc++.a had strong references, it would work fine with libpthread.so too. That is the case that IMHO actually matters (-static-libstdc++ is important to avoid DSO dependencies specific to the GCC version, which varies across installations in incompatible ways far more than libc/libpthread versions). libstdc++.so's weak references can never work with libpthread.a unless there are other strong references elsewhere in the link. But I'm hard-pressed to think of a scenario in which someone actually wants libstdc++.so with libpthread.a.
[Bug libstdc++/57740] C++11 std::thread not usable with static linking
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57740 --- Comment #9 from roland at gnu dot org --- (In reply to Andrew Pinski from comment #8) (In reply to roland from comment #7) -static-libstdc++ is important to avoid DSO dependencies specific to the GCC version, which varies across installations in incompatible ways far more than libc/libpthread versions). No it does not. Or rather there have not been an ABI change in libstdc++ since 3.4. If you compile with the oldest distro you support, it should work across all distros just fine. Just C++11 support was not part of most older distros because they came out before 2011 :). I think I've run into actual problems of this nature. Perhaps it was with 3.4 or earlier, or perhaps I'm misremembering. The only specific scenario I can recall at the moment might not have been a version skew issue, but rather the need to have libstdc++.so.N at runtime at all.
[Bug bootstrap/54659] [4.8 Regression] Bootstrap with --disable-nls broken under Windows
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54659 --- Comment #25 from roland at gnu dot org 2013-05-07 17:06:56 UTC --- I have been using a straightforward revert of r190487 to build on mingw with --disable-nls. It works.
[Bug tree-optimization/57147] New: [4.9 Regression]: setjmp call and if body wrongly elided (function runs off early end)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57147 Bug #: 57147 Summary: [4.9 Regression]: setjmp call and if body wrongly elided (function runs off early end) Classification: Unclassified Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: rol...@gnu.org Target: arm-linux-gnueabi Created attachment 30006 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30006 preprocessed source This is with trunk@198549. It's a regression from gcc-4_8-branch@198420. Preprocessed source attached. Configured as: --target=arm-linux-gnueabi --with-arch=armv7-a Command line below. This example is not expected to be usable on an arm-linux-gnueabi system, but the problem is easily seen by examining the assembly. In the function TestSyscall, a good compilation calls _setjmp, returns normally on a nonzero result, and ends in an __assert_fail call (a noreturn function, so no epilogue/return after the call) on a zero result. In a bad compilation, the function just ends where the _setjmp call should be, no epilogue, no return (so execution just runs into the following function). gcc/cc1 -v -fpreprocessed syscall_return_regs_test.i -quiet -dumpbase syscall_return_regs_test.c -mtls-dialect=gnu -auxbase-strip scons-out/nacl_irt_test-arm-glibc/obj/tests/syscall_return_regs/syscall_return_regs_test.o -g -O2 -Wstrict-prototypes -Wall -Wundef -Wpedantic -Werror -Wno-variadic-macros -Wno-unused-local-typedefs -std=gnu99 -version -fomit-frame-pointer -fdiagnostics-show-option -o syscall_return_regs_test.s GNU C (GCC) version 4.9.0 20130502 (experimental) (arm-linux-gnueabi) compiled by GNU C version 4.6.3, GMP version 5.0.2, MPFR version 3.1.0-p3, MPC version 0.9 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 ignoring nonexistent directory /usr/local/google/home/mcgrathr/gnu/build/inst/lib/gcc/arm-linux-gnueabi/4.9.0/include ignoring nonexistent directory /usr/local/google/home/mcgrathr/gnu/build/inst/lib/gcc/arm-linux-gnueabi/4.9.0/include-fixed ignoring nonexistent directory /usr/local/google/home/mcgrathr/gnu/build/inst/arm-linux-gnueabi/include #include ... search starts here: #include ... search starts here: /usr/local/google/home/mcgrathr/gnu/build/inst/arm-linux-gnueabi/sys-include End of search list. GNU C (GCC) version 4.9.0 20130502 (experimental) (arm-linux-gnueabi) compiled by GNU C version 4.6.3, GMP version 5.0.2, MPFR version 3.1.0-p3, MPC version 0.9 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: e560f858071b4c04ef52cbbad3e21d4b
[Bug tree-optimization/57147] [4.9 Regression]: setjmp call and if body wrongly elided (function runs off early end)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57147 roland at gnu dot org changed: What|Removed |Added CC||rguenther at suse dot de --- Comment #1 from roland at gnu dot org 2013-05-02 17:31:44 UTC --- Bisected to r198096: 2013-04-19 Richard Biener rguent...@suse.de PR tree-optimization/56982 * builtins.def (BUILT_IN_LONGJMP): longjmp is not a leaf function. * gimplify.c (gimplify_call_expr): Notice special calls. (gimplify_modify_expr): Likewise. * tree-cfg.c (make_abnormal_goto_edges): Handle setjmp-like abnormal control flow receivers. (call_can_make_abnormal_goto): Handle cfun-calls_setjmp in the same way as cfun-has_nonlocal_labels. (gimple_purge_dead_abnormal_call_edges): Likewise. (stmt_starts_bb_p): Make setjmp-like abnormal control flow receivers start a basic-block. * gcc.c-torture/execute/pr56982.c: New testcase.
[Bug bootstrap/54659] [4.8 Regression] Bootstrap with --disable-nls broken under Windows
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54659 --- Comment #19 from roland at gnu dot org 2013-03-26 22:03:44 UTC --- r190487 is the breaking change. I tested reverting that (relative to 4.8 branch) and it solved the problem. Note I'm more concerned with having this fixed on the 4.8 branch than on the trunk.
[Bug bootstrap/54659] [4.8 Regression] Bootstrap with --disable-nls broken under Windows
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54659 roland at gnu dot org changed: What|Removed |Added CC||roland at gnu dot org --- Comment #15 from roland at gnu dot org 2013-03-25 21:52:59 UTC --- Confirmed still broken on MinGW with --disable-nls. Confirmed that reverting Diego's 2012-08-17 change fixes it. I don't seem to be able to reopen this bug.
[Bug c++/54055] New: spurious(?) invalid use of incomplete type warning in template definition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54055
Bug #: 54055
Summary: spurious(?) invalid use of incomplete type warning
in template definition
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rol...@gnu.org
Created attachment 27847
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27847
test case, C++ source
The attached input file is culled from Chromium sources. Past versions of
GCC do not complain about this and nor does Clang. Trunk G++ started
giving a warning fairly recently (sometime after I left for Prague).
It happens with no special options, and also with -std=gnu++98; I didn't
test other modes.
foo.cc:3:35: warning: invalid use of incomplete type ‘class scoped_ptrC’
[enabled by default]
private: struct RValue : public scoped_ptr { RValue(); ~RValue();
RValue(cons
^
foo.cc:2:7: warning: declaration of ‘class scoped_ptrC’ [enabled by default]
class scoped_ptr {
^
This code pattern comes from using the macro MOVE_ONLY_TYPE_FOR_CPP_03
as defined here:
http://src.chromium.org/viewvc/chrome/trunk/src/base/move.h?view=markup
Is this code really invalid C++? If so, was it intended to start rejecting
it without any new -std= or -Wfoo options when G++ never did before?
[Bug c++/51886] New: __alignof__ on uninstantiated template type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51886 Bug #: 51886 Summary: __alignof__ on uninstantiated template type Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: rol...@gnu.org The attached test case shows a bug when applying __alignof__ to a type that is part of a template instantiation that has not otherwise been instantiated. I noticed this on 4.4.3 but reproduced it on today's trunk (r183254). This case needs to be compiled with -std=c++0x just because it uses static_assert. As the comment in the case indicates, simply doing an unrelated instantiation of the template before the __alignof__ expression is evaluated makes the problem disappear. % gcc/g++ -Bgcc/ -S -o - -std=c++0x /tmp/template-align.cc .filetemplate-align.cc /tmp/template-align.cc:9:1: error: static assertion failed: misaligned
[Bug c++/51886] __alignof__ on uninstantiated template type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51886 --- Comment #1 from roland at gnu dot org 2012-01-17 18:59:18 UTC --- Created attachment 26357 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26357 C++ test case
