[Bug libstdc++/100903] Bogus "zero as null pointer constant" warning

[headch at gmail dot com via Gcc-bugs]

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

--- Comment #13 from Christopher Head  ---
Could the error message be made more readable by trying to call an
undefined-but-declared non-consteval function inside the consteval context in
the error case, rather than throwing? The name of the function could then be
the error message? For example:


struct __unspec
{
  static void __comparisonCategoryComparedToNonZeroValue();

  template _Tp>
  consteval __unspec(_Tp __z) noexcept
  {
if (__z != 0) __comparisonCategoryComparedToNonZeroValue();
  }
};

You then get the error “call to non-‘constexpr’ function ‘static void
__unspec::__comparisonCategoryComparedToNonZeroValue()’”

[Bug c++/110861] Bad codegen leading to runtime segfault when mixing import and #include

[headch at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Christopher Head  ---
Note that I ran into this while trying to find a small repro case for the same
symptoms (uninitialized “this” and segfault using a string_view) in a larger
project, where I originally saw the same thing happen while only importing
stdlib headers, not including any of them, and eventually made this as a
smaller example.

[Bug c++/110861] New: Bad codegen leading to runtime segfault when mixing import and #include

[headch at gmail dot com via Gcc-bugs]

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

Bug ID: 110861
   Summary: Bad codegen leading to runtime segfault when mixing
import and #include
   Product: gcc
   Version: 13.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: headch at gmail dot com
  Target Milestone: ---

$ g++-13 --version
g++-13 (Gentoo 13.2.0 p3) 13.2.0
Copyright (C) 2023 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


$ cat hello.cpp
#include 
import ;

void f(std::string_view sv) {
std::cout << sv;
}

int main() {
f("hello\n");
}


$ g++-13 -O1 -Wall -Wextra -c -std=c++20 -x c++-system-header -fmodules-ts
-fmodule-header=system iostream


$ g++-13 -std=c++20 -O1 -Wall -Wextra -fmodules-ts -ohello hello.cpp
In file included from
/usr/lib/gcc/x86_64-pc-linux-gnu/13/include/g++-v13/bits/basic_string.h:47,
 from
/usr/lib/gcc/x86_64-pc-linux-gnu/13/include/g++-v13/string:54,
 from
/usr/lib/gcc/x86_64-pc-linux-gnu/13/include/g++-v13/bits/locale_classes.h:40,
 from
/usr/lib/gcc/x86_64-pc-linux-gnu/13/include/g++-v13/bits/ios_base.h:41,
 from
/usr/lib/gcc/x86_64-pc-linux-gnu/13/include/g++-v13/ios:44,
 from
/usr/lib/gcc/x86_64-pc-linux-gnu/13/include/g++-v13/ostream:40,
 from
/usr/lib/gcc/x86_64-pc-linux-gnu/13/include/g++-v13/iostream:41,
of module /usr/lib/gcc/x86_64-pc-linux-gnu/13/include/g++-v13/iostream,
imported at hello.cpp:2:
In member function ‘constexpr const std::basic_string_view<_CharT,
_Traits>::value_type* std::basic_string_view<_CharT, _Traits>::data() const
[with _CharT = char; _Traits = std::char_traits]’,
inlined from ‘std::basic_ostream<_CharT, _Traits>&
std::operator<<(basic_ostream<_CharT, _Traits>&, basic_string_view<_CharT,
_Traits>) [with _CharT = char; _Traits = char_traits]’ at
/usr/lib/gcc/x86_64-pc-linux-gnu/13/include/g++-v13/string_view:762:30,
inlined from ‘void f(std::string_view)’ at hello.cpp:5:15:
/usr/lib/gcc/x86_64-pc-linux-gnu/13/include/g++-v13/string_view:292:22:
warning: ‘this’ is used uninitialized [-Wuninitialized]
  292 |   { return this->_M_str; }
  |  ^~
In file included from hello.cpp:1:
/usr/lib/gcc/x86_64-pc-linux-gnu/13/include/g++-v13/string_view: In function
‘void f(std::string_view)’:
/usr/lib/gcc/x86_64-pc-linux-gnu/13/include/g++-v13/string_view:760:5: note:
‘this’ was declared here
  760 | operator<<(basic_ostream<_CharT, _Traits>& __os,
  | ^~~~


$ ./hello
Segmentation fault (core dumped)


If I use optimization level zero, the problem goes away (both the segfault and
the “uninitialized” warning). Likewise if I import both headers rather than
including one of them. But as far as I’m aware, I haven’t found any indication
that the stdlib is required to be either all-included or all-imported and not a
mix.

[Bug c++/109001] New: “no declaration matches” for complicated non-type template parameters

[headch at gmail dot com via Gcc-bugs]

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

Bug ID: 109001
   Summary: “no declaration matches” for complicated non-type
template parameters
   Product: gcc
   Version: 12.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: headch at gmail dot com
  Target Milestone: ---

I’m reasonably certain (but not completely) that this is valid code:

#include 
#include 

template
class C {
public:
template
C set();
};

template
template
C C::set() {
return {};
}

however, GCC rejects it with “error: no declaration matches ‘C(x, y)> C::set()’” on the out-of-body function definition. This
is accepted in GCC 11.3, as well as the latest versions of Clang and MSVC on
gcc.godbolt.org. Interestingly, GCC 12 also accepts the code if I change the
function definition (just the definition, not the in-body declaration) to use
trailing-return-type syntax:

#include 
#include 

template
class C {
public:
template
C set();
};

template
template
auto C::set() -> C {
return {};
}

[Bug c++/101901] "warning: statement has no effect" in a variadic template with empty parameter pack.

[headch at gmail dot com via Gcc-bugs]

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

Christopher Head  changed:

   What|Removed |Added

 CC||headch at gmail dot com

--- Comment #1 from Christopher Head  ---
I’ve seen the same warning when defining a zero-length array with no templates
involved. It doesn’t happen in all cases, but I suspect the involvement of
templates may be a red herring.

[Bug c++/99778] New: Spurious -Wzero-as-null-pointer-constant on three-way comparisons

[headch at gmail dot com via Gcc-bugs]

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

Bug ID: 99778
   Summary: Spurious -Wzero-as-null-pointer-constant on three-way
comparisons
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: headch at gmail dot com
  Target Milestone: ---

Consider the following code:

#include 
#include 

int main() {
std::strong_ordering o = 1 <=> 2;
if(o == 0) {
std::cout << "equal\n";
} else {
std::cout << "unequal\n";
}
return 0;
}

When compiled with -Wzero-as-null-pointer-constant, this generates a warning on
the “if” line.

This sounds almost the same as bug #95242, except that bug is closed as fixed
for 10.2, and I am running 10.2.0 and still get this problem; also, the code
quoted in that bug does not generate a warning for me, while this code still
does.

[Bug c++/99272] New: False positive -Wredundant-tags warning when reusing a name

[headch at gmail dot com via Gcc-bugs]

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

Bug ID: 99272
   Summary: False positive -Wredundant-tags warning when reusing a
name
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: headch at gmail dot com
  Target Milestone: ---

$ cat test.cpp
struct foo {
int x;
};

struct bar {
struct foo foo;
};

$ g++-10.2.0 -Wall -Wextra -Wredundant-tags -std=c++2a -c test.cpp
test.cpp:6:2: warning: redundant class-key ‘struct’ in reference to ‘struct
foo’ [-Wredundant-tags]
6 |  struct foo foo;
  |  ^~
  |  --

But this is not redundant. Removing the word “struct” results in a compile
error:

$ g++-10.2.0 -Wall -Wextra -Wredundant-tags -std=c++2a -c test.cpp
test.cpp:6:6: error: declaration of ‘foo bar::foo’ changes meaning of ‘foo’
[-fpermissive]
6 |  foo foo;
  |  ^~~
test.cpp:1:8: note: ‘foo’ declared here as ‘struct foo’
1 | struct foo {
  |^~~

Therefore I think -Wredundant-tags should not generate a warning in this
situation (the tag is not redundant).

[Bug c++/98947] New: Incorrect warning when using a ternary operator to select one of two volatile variables to write to

[headch at gmail dot com via Gcc-bugs]

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

Bug ID: 98947
   Summary: Incorrect warning when using a ternary operator to
select one of two volatile variables to write to
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: headch at gmail dot com
  Target Milestone: ---

Using a ternary operator to select one of two variables of the same
volatile-qualified type and then writing into the selected variable yields a
warning in C++2a mode, which I believe either it should not or it is
incorrectly worded.

$ cat test.cpp
volatile int x, y;

void f(bool b) {
(b ? x : y) = 27;
}

$ g++-10.2.0 -Wall -Wextra -std=c++2a -c test.cpp
test.cpp: In function ‘void f(bool)’:
test.cpp:4:14: warning: using value of simple assignment with
‘volatile’-qualified left operand is deprecated [-Wvolatile]
4 |  (b ? x : y) = 27;
  |  ^~~~
test.cpp:4:14: warning: using value of simple assignment with
‘volatile’-qualified left operand is deprecated [-Wvolatile]

$ g++-10.2.0 --version
g++-10.2.0 (Gentoo 10.2.0-r5 p6) 10.2.0
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

I’m not sure whether this code is even deprecated or not. Either way, though,
the warning is wrong. I am not, as the warning claims, using the return value
of the assignment operator.

The roughly equivalent form “*(b ? &x : &y) = 27;” does not generate a warning.

The even more similar, and silly, “*&(b ? x : y) = 27;” also does not generate
a warning.

[Bug c++/80078] Incorrect classification of address of volatile as not constant

[headch at gmail dot com]

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

Christopher Head  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Christopher Head  ---
Appears to be fixed in 9.1.

[Bug c++/80078] Incorrect classification of address of volatile as not constant

[headch at gmail dot com]

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

--- Comment #3 from Christopher Head  ---
I tried 9.1 at gcc.godbolt.org and it looks like this is fixed. Anyone else
care to take a look? If there are no further comments, I guess I’ll close this
ticket in a few days.

[Bug inline-asm/63900] memory constrains needlessly doing memory clobber

[headch at gmail dot com]

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

--- Comment #9 from Christopher Head  ---
I had to use slightly different code because I only have an ARM cross-compiler
version 8.2.0 installed, so I used this:

void g(unsigned char x);

struct MyStruct {
char foo[8];
};

unsigned char buffer[100], buffer2[100];

void f(void) {
buffer2[5] = 'X';
struct MyStruct *p = (void *) buffer;
asm volatile("nop" : "=m" (*p));
g(buffer2[5]);
}

No matter what I changed the size of the foo array in MyStruct to (I tried 8,
15, 13, and 257), this was always the disassembly:

 :
   0:   4a03ldr r2, [pc, #12]   ; (10 )
   2:   2058movsr0, #88 ; 0x58
   4:   4b03ldr r3, [pc, #12]   ; (14 )
   6:   7150strbr0, [r2, #5]
   8:   bf00nop
   a:   f7ff bffe   b.w 0 
a: R_ARM_THM_JUMP24 g
   e:   bf00nop

Notice that r0 is loaded at offset 2, then passed into g at offset a, and is
not reloaded from the array. If I change the asm to have a full memory clobber,
an ldrb is inserted between the nop and the b.w, as expected, since then
buffer2 is also clobbered.

So, doesn’t this mean that it *is* properly clobbering only buffer, not
buffer2, regardless of the size of foo?

[Bug inline-asm/63900] memory constrains needlessly doing memory clobber

[headch at gmail dot com]

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

Christopher Head  changed:

   What|Removed |Added

 CC||headch at gmail dot com

--- Comment #7 from Christopher Head  ---
It seems to me that this is fixed in 8.2.0?

[Bug c++/80078] Incorrect classification of address of volatile as not constant

[headch at gmail dot com]

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

Christopher Head  changed:

   What|Removed |Added

  Known to fail||8.2.0

--- Comment #2 from Christopher Head  ---
This is still broken in 8.2.0. Also, it affects struct members as well as
arrays, which have no easy workaround like “ary + N”:

struct S {
  int x;
};

volatile S s;

static_assert(&s.x, "");

[Bug c++/82294] New: Array of objects with constexpr constructors initialized from space-inefficient memory image

[headch at gmail dot com]

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

Bug ID: 82294
   Summary: Array of objects with constexpr constructors
initialized from space-inefficient memory image
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: headch at gmail dot com
  Target Milestone: ---

Consider the following code:

$ cat test.cpp
struct S {
int x;

explicit constexpr S();
};

constexpr S::S() : x{7} {}

struct T {
S objects[256];

explicit T();
};

T::T() {}


Compile it as follows:

$ g++ -Wall -Wextra -march=native -std=c++17 -Os -c test.cpp


Dumping the resulting object file reveals that T::T() is implemented by
memcpying (depending on the target architecture sometimes inline or sometimes
by an actual memcpy call) a kilobyte of data from .rodata into the array being
initialized. For two or three S objects that might be a good, efficient
solution. For 256 of them, a kilobyte of memory entirely filled with sevens to
serve as an initialization image is rather ridiculous compared to just using a
loop to store seven into the objects one by one. This is especially egregious
considering I was asking to optimize for size!

Making S::S() non-constexpr improves the situation, though it’s hardly an ideal
solution.

This might be related to any of #12245, #56671, #59659, #63728, #68399, or
#71165, but none of them describe quite the same problem. The first five are
about memory or CPU time usage during compilation (not about the generated
code), and #71165 is specifically about aggregate initialization and appears to
be an unrolled loop in code rather than a huge data blob.

[Bug target/82038] Very poor optimization of constant multiply on ARM Cortex-M7

[headch at gmail dot com]

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

--- Comment #2 from Christopher Head  ---
I think they do. Just one example, but I’m pretty sure it holds for others too
(left-shift equals multiply by power of two, even for negative integers; it’s
right-shift where the behaviour differs due to different rounding):

== On entry ==
r0 = -16 = 0xFFF0

== f ==
0:
2: r5 = r0 ASR 31 = 0x
4: r3 = r0 = 0xFFF0
6: r0 = r0 << 14 = 0xFFFC
8: r1 = r5 << 14 = 0xC000
a:
c: r1 = r1 | (r3 LSR 18)
= 0xC000 | (0xFFF0 LSR 18)
= 0xC000 | 0x3FFF
= 0x

On exit, r1:r0 = 0x : 0xFFFC = -262,144

== g ==
14: r1 = r0 = 0xFFF0
16: r0 = r0 << 14 = 0xFFFC
18: r1 = r1 ASR 18 = 0x

On exit, r1:r0 = 0x : 0xFFFC = -262,144

[Bug target/82038] New: Very poor optimization of constant multiply on ARM Cortex-M7

[headch at gmail dot com]

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

Bug ID: 82038
   Summary: Very poor optimization of constant multiply on ARM
Cortex-M7
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: headch at gmail dot com
  Target Milestone: ---

Consider the following source code:

#include 

int64_t f(int32_t x) {
return x * 16384LL;
}

int64_t g(int32_t x) {
return static_cast(x) << 14;
}

Compile it with the following command:

armv7m-none-eabihf-g++ -ffreestanding -Wall -Wextra -O2 -mcpu=cortex-m7
-std=c++17 -c test.cpp

It produces the following code:

 <_Z1fl>:
   0:   b430push{r4, r5}
   2:   17c5asrsr5, r0, #31
   4:   4603mov r3, r0
   6:   0380lslsr0, r0, #14
   8:   03a9lslsr1, r5, #14
   a:   bc30pop {r4, r5}
   c:   ea41 4193   orr.w   r1, r1, r3, lsr #18
  10:   4770bx  lr
  12:   bf00nop

0014 <_Z1gl>:
  14:   4601mov r1, r0
  16:   0380lslsr0, r0, #14
  18:   1489asrsr1, r1, #18
  1a:   4770bx  lr

The implementation of f could be the same as g, yet it’s really quite awful.

Changing -mcpu=cortex-m7 to -mcpu=cortex-m4 doesn’t affect g. It yields rather
better code for f than the M7 build, but still not as good as g.

I could just use g, but that isn’t really a good option because left-shifting a
negative number is UB.

[Bug c++/80078] New: Incorrect classification of address of volatile as not constant

[headch at gmail dot com]

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

Bug ID: 80078
   Summary: Incorrect classification of address of volatile as not
constant
   Product: gcc
   Version: 6.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: headch at gmail dot com
  Target Milestone: ---

Consider the following code:

volatile int ary[1];
static_assert(&ary[0], "");
static_assert(ary + 0, "");

The first static_assert fails, claiming that the condition is non-constant
because the expression ary[0] has side effects. The second static assert
passes. Removing the volatile qualifier also results in the code passing.

>From reading the spec, I *believe* (but could be wrong) that the &ary[0] should
meet the criteria for being a constant expression. As far as I can tell, the
evaluation of &arr[0] proceeds as follows (references are to N4296, as that is
AFAICT very close to C++14 and I don’t have the actual standard):

1. 5.2.1 says the subscripting operator takes a pointer or array, that ary[0]
is identical by definition to *(ary+0), and that because ary is an lvalue, then
so should be ary[0].

2. 5.7 says that the addition operator can take two arithmetic or unscoped enum
types, or one pointer and one arithmetic or unscoped enum type. It doesn’t say
that the addition operator can take an array. Array-to-pointer conversion
therefore happens on ary, which 4.2 says yields a prvalue of type
pointer-to-volatile-int. Then the addition operator proceeds, taking the
prvalue pointer and the prvalue integer literal and returning a (I believe)
prvalue pointer-to-volatile-int.

3. 5.3.1 paragraph 1 says that operator* returns an lvalue, in this case of
type volatile int.

4. 5.3.1 paragraph 3 says that the operand to & can be an lvalue and the result
is a prvalue, in this case of type pointer-to-volatile-int.

As far as I can tell, none of the above violates 5.20’s rules on what
constitutes a core constant expression.

https://gcc.godbolt.org/ says that GCC5 accepts the code, GCC6 and GCC7 both
reject the first static_assert but accept the second, the Microsoft compiler
rejects both, Clang 3.0 rejects both but 3.1 and above accept both, and icc
13.0.1 rejects both but 16 and 17 accept both.

[Bug target/79237] New: ARMv7-M ICE in extract_constrain_insn, insn does not satisfy its constraints

[headch at gmail dot com]

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

Bug ID: 79237
   Summary: ARMv7-M ICE in extract_constrain_insn, insn does not
satisfy its constraints
   Product: gcc
   Version: 6.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: headch at gmail dot com
  Target Milestone: ---

Created attachment 40585
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40585&action=edit
Source code reproducing the bug

$ armv7m-none-eabihf-g++ -O2 -mslow-flash-data -mcpu=cortex-m4
 -mfpu=fpv4-sp-d16 -c test.cpp test.cpp: In member function ‘void
 S2::memFun()’: test.cpp:22:1: error: insn does not satisfy its
 constraints: }
 ^
(insn 8 20 6 2 (set (reg:SI 31 s15 [orig:118 obj1.mem1 ] [118])
(mem/u/c:SI (reg/f:SI 3 r3 [116]) [5 obj1.mem1+0 S4 A32]))
 test.cpp:21 615 {*thumb2_movsi_vfp} (nil))
test.cpp:22:1: internal compiler error: in extract_constrain_insn, at
 recog.c:2190 Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

$ armv7m-none-eabihf-g++ -v
Using built-in specs.
COLLECT_GCC=armv7m-none-eabihf-g++
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/armv7m-none-eabihf/6.3.0/lto-wrapper
Target: armv7m-none-eabihf
Configured
with:
/tmp/portage/dev-embedded/armv7m-none-eabihf-gcc-6.3.0/work/gcc-6.3.0/configure
--prefix=/usr --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share
--sysconfdir=/etc --localstatedir=/var/lib
--docdir=/usr/share/doc/armv7m-none-eabihf-gcc-6.3.0
--htmldir=/usr/share/doc/armv7m-none-eabihf-gcc-6.3.0/html
--libdir=/usr/lib64 --target=armv7m-none-eabihf
--infodir=/usr/share/gcc-data/armv7m-none-eabihf/6.3.0/info
--disable-multilib --disable-threads --with-cpu=cortex-m4
--with-abi=aapcs --with-fpu=vfpv3-d16 --with-float=hard
--with-mode=thumb --enable-languages=c,c++ --disable-libstdc++-v3
--disable-libada --disable-libsanitizer --disable-libssp
--disable-libquadmath --disable-libquadmath-support --disable-libgomp
--disable-libvtv --with-dwarf2 --without-headers --with-system-zlib
--enable-nls --without-included-gettext Thread model: single gcc
version 6.3.0 (GCC) 

Note that this is a locally developed Gentoo ebuild which runs a fairly stock
ARM GCC install. I can try reproducing in a completely isolated,
non-ebuild-driven environment if necessary.

[Bug c++/48446] New: internal compiler error: in gimplify_var_or_parm_decl, at gimplify.c:1946

[headch at gmail dot com]

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

   Summary: internal compiler error: in gimplify_var_or_parm_decl,
at gimplify.c:1946
   Product: gcc
   Version: 4.4.5
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hea...@gmail.com


Created attachment 23878
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23878
The failing source file

I compile the attached file using this command:

$ g++ -std=gnu++0x -Wall -Wextra -c test.cpp

with this version of GCC:

$ gcc --version
gcc (Gentoo 4.4.5 p1.2, pie-0.4.5) 4.4.5
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

on Gentoo x86-64 and x86 (both produce identical error messages). I get this
output:

test.cpp: In member function ‘void Sender::flush()’:
test.cpp:168: internal compiler error: in gimplify_var_or_parm_decl, at
gimplify.c:1946
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

I also have access to an OpenSUSE x86-64 environment reading out this version:

$ gcc --version
gcc (SUSE Linux) 4.5.0 20100604 [gcc-4_5-branch revision 160292]
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

This gives the following output:

test.cpp: In member function ‘void Sender::flush()’:
test.cpp:175:71: internal compiler error: in gimplify_var_or_parm_decl, at
gimplify.c:1816
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

(yes, the source line number of the error in test.cpp is different for this GCC
version even though the sources are identical).

Finally, a friend using Arch Linux x86-64 tested the same code on GCC 4.6 and
also reproduced the bug, though I don't have the line numbers from that test.

I can attach preprocessed source if you want, though the source doesn't use
anything but standard headers and the problem seems quite easily reproducible
as I already described.