[Bug c++/114569] GCC accepts forming pointer to function type which is ref qualified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114569 Jens Maurer changed: What|Removed |Added CC||jens.maurer at gmx dot net --- Comment #3 from Jens Maurer --- Note that the ref-qualified function type is not directly an argument for a template type parameter (which would be allowed), but it's a function parameter type inside a function declarator. And those do decay to (possibly ill-formed) pointers.
[Bug c++/111923] default argument is not treated as a complete-class context of a class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111923 Jens Maurer changed: What|Removed |Added CC||jens.maurer at gmx dot net --- Comment #12 from Jens Maurer --- In general, we want to be rather careful that the layout of the non-static data members of a class cannot depend on properties of other non-static data members that are visible due to some "complete class" rules. Otherwise, it's way too easy to construct cycles.
[Bug libstdc++/109822] New: Converting std::experimental::simd masks yields an error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109822 Bug ID: 109822 Summary: Converting std::experimental::simd masks yields an error Product: gcc Version: 12.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: jens.maurer at gmx dot net Target Milestone: --- Reproducer: #include auto x = to_native(to_fixed_size(std::experimental::native_simd::mask_type())); This converts a native SIMD mask type to fixed-size and back. I believe this should work, but gcc disagrees: /usr/include/c++/12/experimental/bits/simd.h:3224:3: note: template argument deduction/substitution failed: x.cc:4:19: note: mismatched types ‘long unsigned int’ and ‘int’ (Also reproducible with gcc 13.1.) The issue is that the SIMD implementation of libstdc++ uses a mixture of "int" and "size_t" for the type of non-type template parameters for "number of elements in this SIMD vector", causing deduction failures when gcc tries to match template arguments with template parameters. It seems the Technical Specification uses "int" throughout.
[Bug c++/105200] user-defined operator <=> for enumerated types is ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105200 Jens Maurer changed: What|Removed |Added CC||jens.maurer at gmx dot net --- Comment #7 from Jens Maurer --- I have created core issue 2673 for this. https://cplusplus.github.io/CWG/issues/2673.html
[Bug c++/107022] error: use of deleted function 'std::unordered_map
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107022 --- Comment #8 from Jens Maurer --- I understand we're in a tangled web of partially-complete class rules here, but the standard does give you the expectation that the inner class is complete at its closing brace: [class.pre] p2 says: "A class is considered defined after the closing brace of its class-specifier has been seen even though its member functions are in general not yet defined."
[Bug c++/107340] New: std::unordered_map and completeness of nested classes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107340
Bug ID: 107340
Summary: std::unordered_map and completeness of nested classes
Product: gcc
Version: 11.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jens.maurer at gmx dot net
Target Milestone: ---
Consider:
#include
struct X
{
struct Key
{
int x = 0;
bool operator==(const Key&) const = default;
std::size_t operator()(const Key& k) const noexcept
{
return k.x;
}
};
int a[sizeof(Key)];
std::unordered_map m;
};
X x;
When compiled with "g++ -std=c++20", it yields:
a1.cc:24:3: error: use of deleted function ‘X::X()’
(plus lots of details)
since gcc 11.3 and 12.x; gcc 11.2 compiled this code fine.
Analysis: The nested class "X::Key" is complete at its closing brace, also
evidenced by the array data member declaration. Yet, "m" attains a deleted
default constructor for no apparent reason.
Moving class "Key" to namespace scope or providing a separate, but still
nested, "X::KeyHash" class works around the issue.
[Bug c++/106812] Throwing a non-copyable exception
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106812 --- Comment #1 from Jens Maurer --- Cross-reference: clang bug https://github.com/llvm/llvm-project/issues/57519
[Bug c++/106812] New: Throwing a non-copyable exception
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106812
Bug ID: 106812
Summary: Throwing a non-copyable exception
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jens.maurer at gmx dot net
Target Milestone: ---
gcc accepts the following program:
struct S
{
S() = default;
S(const S) = delete;
// int x = 0; // #3
};
int main()
{
try {
throw S(); // #1
} catch (S s) { // #2
return 1;
}
}
but it is ill-formed at #1 according to [except.throw] p5.
Curiously, if line #3 is added, gcc flags an error at #2 (but not at #1).
[Bug c++/106150] [DR 2084] union with more than one variant and non-trivial constructor is not accepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106150 --- Comment #6 from Jens Maurer --- Related clang bug: https://github.com/llvm/llvm-project/issues/56313
[Bug c++/106150] New: Incorrect error for defaulted anonymous union member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106150
Bug ID: 106150
Summary: Incorrect error for defaulted anonymous union member
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jens.maurer at gmx dot net
Target Milestone: ---
The following is valid, but yields an error with gcc 12.1:
struct A {
A() { }
};
struct V {
V() { };
~V() { }
};
struct S {
S();
~S() {}
union {
A a = {};
V v;
};
};
S::S() = default;
x.cc:22:1: note: ‘S::S()’ is implicitly deleted because the default definition
would be ill-formed:
22 | S::S() = default;
| ^
x.cc:18:8: error: union member ‘Sv’ with non-trivial
‘V::V()’
18 | V v;
|^
Replacing "= default" with "{}" makes the error go away.
None of the items in [class.default.ctor] p2 applies, in particular p2.2 does
not apply because S::a has a default member initializer.
[Bug tree-optimization/105651] bogus "may overlap" memcpy warning with std::string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105651
Jens Maurer changed:
What|Removed |Added
CC||jens.maurer at gmx dot net
--- Comment #5 from Jens Maurer ---
Here's a more compact reproducer (gcc 12.1):
#include
void f(const long long v)
{
std::string line;
line += " " + std::to_string(v);
}
$ g++ -Wall -O3 -std=c++20 -o test_warning.o -c test_warning.cxx
[...]
inlined from 'void f(long long int)' at test_warning.cxx:9:15:
/opt/crosstool/x86_64-gcc-12.1.0-glibc-2.12.2/x86_64-unknown-linux-gnu/include/c++/12.1.0/bits/char_traits.h:431:56:
warning: 'void* __builtin_memcpy(void*, const void*, long unsigned int)'
accessing 9223372036854775810 or more bytes at offsets [2,
9223372036854775807] and 1 may overlap up to 9223372036854775813 bytes
at offset -3 [-Wrestrict]
431 | return static_cast(__builtin_memcpy(__s1,
__s2, __n));
[Bug c++/103177] New: incorrect error message for ambiguous lookup
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103177
Bug ID: 103177
Summary: incorrect error message for ambiguous lookup
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jens.maurer at gmx dot net
Target Milestone: ---
This is clearly a case of ambiguous lookup:
struct B {
static int foo(int);
};
struct B2 {
int foo();
};
struct D : private B, public B2 {
};
void f()
{
D d;
d.foo();
}
Yet, gcc complains about an inaccessible member. (Note that access is checked
at the end of overload resolution, but we should never get to that point.)
g++ -Wfatal-errors x.cc
x.cc: In function ‘void f()’:
x.cc:18:5: error: ‘static int B::foo(int)’ is inaccessible within this
context
18 | d.foo();
| ^~~
compilation terminated due to -Wfatal-errors.
[Bug c++/101480] [11/12 Regression] Miscompiled code involving operator new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101480 --- Comment #10 from Jens Maurer --- I agree with Jonathan here: The difference is that "malloc" comes with the compiler/library and cannot be replaced (within the scope of the C or C++ standards), but "operator new" is expressly specified to be replaceable by the C++ standard. There is text in the standard that restricts what "operator new" can and cannot do, but otherwise it is specified as-if a regular function call. As-is, gcc 11 is non-conforming with this optimization turned on by default. I'm all for providing an extra command-line switch so that the user can assert that he's not replacing "operator new" anywhere in the program, but that switch should be off by default.
[Bug c++/101480] [11/12 Regression] Miscompiled code involving operator new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101480 --- Comment #3 from Jens Maurer --- "We treat the global operator new as not reading from global memory" If I implement my own global "operator new" afresh, certainly it'll need to access global memory, e.g. to read a global pointer to the heap or so. I have carefully reviewed [expr.new] before posting this bug report. The compiler can omit a call to an allocation function entirely (and e.g. provide the memory on the stack, if the lifetime fits), but I haven't found any wording that would allow making assumptions about the global memory behavior of the allocation function when it is, in fact, called. "we cannot do the optimization that was added" I understand this might be an important optimization to offer (similar to -ffast-float), but it would be good to have a separate command-line flag to enable or disable it.
[Bug c++/101480] New: Miscompiled code involving operator new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101480
Bug ID: 101480
Summary: Miscompiled code involving operator new
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jens.maurer at gmx dot net
Target Milestone: ---
The following test case works correctly with gcc 10.3 (with any of -O0, -O1, or
-O3) and works with gcc 11.1 with -O0, but the assertion at #2 fires with gcc
11.1 with -O1 (and above).
The problem is that setting the flag at #1 (inlined into "f" just before
calling "new") is not performed in the generated machine code, and the
assertion in "operator new" then fails.
#include
#include
static bool flag = false;
class C
{
bool prev;
public:
C() : prev(flag)
{
flag = true; // #1
}
~C() {
flag = prev;
}
};
void* operator new(unsigned long size)
{
assert(flag); // #2
return malloc(size);
}
void operator delete(void *p)
{
free(p);
}
void g(int* p)
{
delete p;
}
void f()
{
int* p;
{
C c;
p = new int;
}
g(p);
}
int main(int, char**)
{
f();
}
[Bug tree-optimization/100430] False positive for -Warray-bounds and pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100430 --- Comment #4 from Jens Maurer --- Thanks. My take-away from the discussion is that -Warray-bounds triggers when there might be a code path with bad behavior. Whether such a code path is detected depends very much on the details of optimization behavior and is thus a bit unpredictable. Please resolve.
[Bug tree-optimization/100430] False positive for -Warray-bounds and pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100430 --- Comment #2 from Jens Maurer --- Why does the warning go away with -O3, then? If it's intentional, it should be consistent once the optimization level is sufficient for the necessary static analysis.
[Bug c++/100430] New: False positive for -Warray-bounds and pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100430
Bug ID: 100430
Summary: False positive for -Warray-bounds and pointers
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jens.maurer at gmx dot net
Target Milestone: ---
This code triggers a -Warray-bounds warning in gcc 11.1 (gcc 9.3 was silent;
gcc 10 did show the warning). The test case is reduced from another case (not
shown) that only triggered the warning starting with gcc 11.
char * g();
static char c = 0;
unsigned int x = 0;
void f(char *)
{
if (x > 1)
p[1] = 0;
p = g();
}
void h()
{
char * p =
f(p);
}
$ g++ -c -O2 -Warray-bounds c.cxx
c.cxx: In function ‘void h()’:
c.cxx:9:10: warning: array subscript 1 is outside array bounds of ‘char [1]’
[-Warray-bounds]
9 | p[1] = 0;
| ~^~~
c.cxx:3:13: note: while referencing ‘c’
3 | static char c = 0;
| ^
Note: using -O3 silences the warning.
$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-pc-linux-gnu/11.1.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-11.1.0/configure --enable-languages=c,c++
--with-system-zlib --enable-lto --with-abi=m64 --disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.1.0 (GCC)
[Bug c++/52202] [C++11][DR 1376] Should not extend lifetime of temporary wrapped in static_cast to reference type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52202 --- Comment #5 from Jens Maurer --- Core issue 1299 resolved via http://wg21.link/p0727 does in fact lifetime-extend the temporary in the example. This bug report should therefore be closed without action. (If a test case is missing that lifetime-extension does happen, the example code can have its "abort" condition reversed to suit that purpose.)
[Bug c++/87223] New: -Os produces sub-optimal x86 machine code for initialization with zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87223
Bug ID: 87223
Summary: -Os produces sub-optimal x86 machine code for
initialization with zero
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jens.maurer at gmx dot net
Target Milestone: ---
My understanding of -Os is that it is aimed at reducing code size. It produces
code with suboptimal size for the constructor below (and similar cases where a
constructor needs to initialize lots of members to zero):
struct S {
char a = 0;
void * b = 0;
short c = 0;
long d = 0;
S();
};
S::S() = default;
Generated code on x86-64 using "g++ -Os -S x.cc":
movb$0, (%rdi)
movq$0, 8(%rdi)
movw$0, 16(%rdi)
movq$0, 24(%rdi)
ret
It would be more efficient space-wise to first zero a register with "xor %eax,
%eax" (should implicitly zero all of %rax) and then use %rax or a sub-register
thereof as the source for the moves. This avoids putting 0 as constants into
the machine instructions over and over again, enlarging their size (and, due to
their size, possibly clogging the CPU's instruction decoder).
[Bug c++/84699] discarded value expression of volatile class type shall materialize a temporary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84699 Jens Maurer changed: What|Removed |Added CC||jens.maurer at gmx dot net --- Comment #2 from Jens Maurer --- This is core issue 1054.
[Bug c++/84287] New: pointer to member function type with dependent parameter cannot be mangled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84287
Bug ID: 84287
Summary: pointer to member function type with dependent
parameter cannot be mangled
Product: gcc
Version: 7.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jens.maurer at gmx dot net
Target Milestone: ---
This is a (reduced) attempt at SFINAE, which fails with gcc 7.3:
struct S {
void f(const int&);
};
template
int g(T x, decltype(static_cast(::f)) * = nullptr) { }
int x = g(0);
$ g++ x.cc
x.cc: In instantiation of ‘int g(T, decltype (static_cast(& S::f))*) [with T = int]’:
x.cc:6:5: sorry, unimplemented: mangling offset_ref
int g(T x, decltype(static_cast(::f)) * = nullptr) {
}
^
[Bug c++/57728] Explicit template instantiation with defaulted method causes missing symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57728
Jens Maurer changed:
What|Removed |Added
CC||jens.maurer at gmx dot net
--- Comment #13 from Jens Maurer ---
This bug saw its last activity nearly a year ago, with patches from Jason
applied, but the issue does not seem to be fixed in its entirety (using gcc
7.2).
Specifically, this translation unit:
template
struct C {
C() = default;
void f() { }
int i = 5;
};
template class C;
causes C::f() to be defined, but the defaulted constructor of C is
not defined. (Replacing "= default" with "{}" causes definition of the C
constructor.)
$ nm -C x.o
W C::f()
The current behavior is obviously not what we want if we choose to use explicit
instantiations.
[Bug c++/80601] spurious -Wconversion warning with explicit class template arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80601
--- Comment #2 from Jens Maurer ---
(In reply to Jonathan Wakely from comment #1)
> Strictly speaking the compiler is correct that the type of sizeof(T) is not
> dependent, so for LP64 targets will always need a conversion to a narrower
> type.
Right, but I would expect -Wconversion warnings to respect the C++ narrowing
rules for brace-initialization, which (among other things) state for integer
conversions that there is no narrowing if the original constant value fits into
the target type.
In the following example, there is no error or warning; the narrowing check is
(correctly) postponed to template instantiation time:
template
void g(T)
{
unsigned int x { sizeof(T) };
}
[Bug c++/80601] New: spurious -Wconversion warning with explicit class template arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80601
Bug ID: 80601
Summary: spurious -Wconversion warning with explicit class
template arguments
Product: gcc
Version: 7.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jens.maurer at gmx dot net
Target Milestone: ---
The all-new gcc 7.1.0 has introduced a conversion warning in template
definition context when a value-dependent sizeof is used as a template argument
for a class template. (There is no warning for something like
"f<sizeof(T)>()".) Note that the program below has no instantiation of "g", and
I believe a -Wconversion warning should not trigger when a constant value is
used that fits the target type.
g++ -Wconversion -c x.cc
x.cc: In function ‘int g(T)’:
x.cc:7:11: warning: conversion to ‘unsigned int’ from ‘long unsigned int’ may
alter its value [-Wconversion]
S<sizeof(T)> s;
template
struct S { };
template
void g(T)
{
S<sizeof(T)> s;
}
[Bug c++/80599] -Wuseless-cast triggers for inherited constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80599 --- Comment #1 from Jens Maurer --- This is a duplicate of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70844 ; please close.
[Bug c++/80599] New: -Wuseless-cast triggers for inherited constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80599
Bug ID: 80599
Summary: -Wuseless-cast triggers for inherited constructor
Product: gcc
Version: 7.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jens.maurer at gmx dot net
Target Milestone: ---
All-new gcc 7.1.0 delivers a -Wuseless-cast warning for inherited constructors
involving reference parameters that the user cannot do anything about. This
did not happen with gcc 6.3.0.
struct B {
B(const int&);
};
struct D : B {
using B::B;
};
D d2 = 0;
$ g++ -Wuseless-cast -c y.cc
y.cc: In constructor ‘D::D(const int&) [inherited from B]’:
y.cc:6:12: warning: useless cast to type ‘const int&’ [-Wuseless-cast]
using B::B;
^
y.cc: At global scope:
y.cc:9:8: note: synthesized method ‘D::D(const int&) [inherited from B]’ first
required here
D d2 = 0;
^
[Bug c++/80598] New: -Wunused triggers for functions used in uninstantiated templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80598
Bug ID: 80598
Summary: -Wunused triggers for functions used in uninstantiated
templates
Product: gcc
Version: 7.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jens.maurer at gmx dot net
Target Milestone: ---
The all-new gcc 7.1.0 now shows this disturbing warning; gcc 6.3.0 didn't. It
seems unhelpful to issue an "unused function" warning for a function actually
used from an uninstantiated template. This situation might happen a lot in
#included header files. (Adding an instantiation of "g" silences the warning.)
$ g++ -Wunused x.cc
x.cc:1:13: warning: ‘void f()’ defined but not used [-Wunused-function]
static void f()
{ }
template
int g(T x)
{
f();
return 0;
}
[Bug c++/80516] New: No error for bad type-specifier-seq in template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80516
Bug ID: 80516
Summary: No error for bad type-specifier-seq in template
parameter
Product: gcc
Version: 6.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jens.maurer at gmx dot net
Target Milestone: ---
The following code violates [dcl.type] paragraph 2 "at most one type-specifier
is allowed in a type-specifier-seq" (none of the exceptions apply), yet gcc
does not issue a diagnostic unless -Wpedantic is given:
using u = unsigned int;
template
struct S { };
S s;
$ g++ -c bad.cc
$ g++ -c -Wpedantic bad.cc
bad.cc:7:10: warning: long, short, signed or unsigned used invalidly for ‘type
name’ [-Wpedantic]
S s;
^
I'd like to kindly ask that this syntax confusion be made an error instead of a
(frequently disabled) warning.
[Bug libstdc++/78420] [5/6/7 Regression] std::less<T*> is not a total order with -O2 enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78420
--- Comment #18 from Jens Maurer ---
Then you should cheat on [dcl.constexpr] p5 by carving out the nullptr case:
constexpr void less_than(int *p1, int *p2)
{
if (p1 == nullptr && p2 == nullptr)
return false;
return (size_t)p1 < (size_t)p2;
}
This should sidestep [dcl.constexpr] p5, since "less_than(0,0)" seems to be, in
fact, a constant expression.
[Bug libstdc++/78420] [5/6/7 Regression] std::less<T*> is not a total order with -O2 enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78420 Jens Maurer changed: What|Removed |Added CC||jens.maurer at gmx dot net --- Comment #16 from Jens Maurer --- I'd like to point out that there is no prohibition against writing reinterpret_cast inside a constexpr function. It's just if you call that function and actually evaluate the reinterpret_cast does the expression turn into an expression that is not a constant expression. And there is no requirement that calling a constexpr function with arbitrary arguments is, in fact, a constant expression in the sense of C++ section 5.20. There seems to be a tacit understanding that a standard library function marked as "constexpr" may, in fact, appear in a constant expression if the "obvious" operations on the arguments are suitable (copy constructor, destructor at least), but I couldn't find a statement that would make this expectation explicit. That means the standard library needs to do its homework to clearly specify under which circumstances (which argument types) it expects a constexpr function to be valid in a constant expression. Absent that, simply performing the reinterpret_cast is the right answer for std::less<T*>, and seems to be fully conforming with the letter of the current standard.
[Bug c++/79001] New: spurious "defined but not used" warning with explicit instantiation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79001
Bug ID: 79001
Summary: spurious "defined but not used" warning with explicit
instantiation
Product: gcc
Version: 6.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jens.maurer at gmx dot net
Target Milestone: ---
The following testcase gives a "defined but not used" warning for "f", but not
for "g". I agree that "f" cannot be used outside of the translation unit (due
to the use of a type from an anonymous namespace), but neither can "g".
Plus, if someone does use explicit instantiations on a class, it does not seem
helpful to produce "unused function" warnings for functions generated from an
explicit instantiation on a class in the first place, because the class (maybe
from a library) might have a lot more member functions than actually in use in
any given file.
template
class C {
void f();
void g() { }
};
template
void C::f() { }
namespace {
struct X { };
}
template class C;
V$ gcc -Wunused-function -c x.cc
x.cc:9:6: warning: ‘void C::f() [with T = {anonymous}::X]’ defined but not
used [-Wunused-function]
void C::f() { }
^~~~
[Bug target/78954] optimization: broadcast of non-constant scalar into SSE2 register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78954 --- Comment #3 from Jens Maurer --- Ok, thanks. So, this essentially says most/all AMD CPUs have bad general-reg -> xmm move performance. Oh well. Please close.
[Bug target/78954] New: optimization: broadcast of non-constant scalar into SSE2 register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78954
Bug ID: 78954
Summary: optimization: broadcast of non-constant scalar into
SSE2 register
Product: gcc
Version: 6.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jens.maurer at gmx dot net
Target Milestone: ---
The following code goes through the stack instead of directly moving from the
register for "x" into (the low part of) "v":
#pragma GCC target ("sse2")
typedef unsigned int V __attribute__((vector_size(16)));
V f(int x)
{
V v = { x, x, x, x };
return v;
}
$ gcc -v -O3 -S x.cc
Target: x86_64-pc-linux-gnu
gcc version 6.3.0 (GCC)
snippet from assembly:
movl%edi, -12(%rsp)
movd-12(%rsp), %xmm1
pshufd $0, %xmm1, %xmm0
ret
Why do we move through the stack, instead of using a simple register move?
movd%edi, %xmm1
pshufd $0, %xmm1, %xmm0
[Bug c++/78949] New: incorrect "unused variable" warning with SSE2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78949
Bug ID: 78949
Summary: incorrect "unused variable" warning with SSE2
Product: gcc
Version: 6.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jens.maurer at gmx dot net
Target Milestone: ---
The following program:
typedef unsigned char xmmb_t __attribute__((vector_size(16)));
void f()
{
xmmb_t bla = { };
xmmb_t x = { };
bla &= ~x;
}
yields an "unused variable" warning, although "x" is obviously used.
$ g++ -v -Wunused -c unused.cc
gcc version 6.2.0 (GCC)
unused.cc: In function ‘void f()’:
unused.cc:7:10: warning: variable ‘x’ set but not used
[-Wunused-but-set-variable]
xmmb_t x = { };
[Bug c++/70932] flexible array member with non-trivial destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70932
--- Comment #2 from Jens Maurer ---
The whole point of flexible array members seems to be to save an allocation for
the array, with the precondition that the array size can be determined at
initialization time and stays fixed for the entire lifetime of the enclosing
struct. In that scenario, I need to placement-new the array elements (or,
probably, the entire array) anyway, so requiring to explicitly call the
destructor(s) seems a natural duality.
In the example
S s = { 3, { 1, 2, 3 } };
it seems surprising that the destructor for the elements is not called, given
that the number of elements is "right there" in the source code. [Yes, I have
an idea about the implementation difficulties here.] I'd rather prefer this
initialization example to be ill-formed, if the element type has a non-trivial
destructor. Consider if the element type is a std::string (with dynamic
allocation) and this is inside a loop; this seems to cause a serious memory
leak.
[Bug c++/70932] New: flexible array member with non-trivial destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70932
Bug ID: 70932
Summary: flexible array member with non-trivial destructor
Product: gcc
Version: 6.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jens.maurer at gmx dot net
Target Milestone: ---
Testcase:
struct A {
~A();
};
struct S {
S() : i(0) { }
int i;
A a[];
};
$ g++ -v flex.cc
gcc version 6.1.0 (GCC)
flex.cc: In constructor ‘S::S()’:
flex.cc:6:12: error: unknown array size in delete
This used to work with gcc 5.x. (I understand the destructor of A is not
called for a[] here, because the number of elements is unknown.)
[Bug c++/70827] [6/7 regression] dubious use of deleted function in inherited constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70827 --- Comment #2 from Jens Maurer --- A prominent use case is that std::unique_ptr in the parameter list of an inherited constructor stops working.
[Bug c++/70847] exponential time in cp_fold for chained virtual function calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70847 --- Comment #1 from Jens Maurer --- This situation is similar to bug 70342, except that my testcase - involves no -fsanitize=undefined, - is shorter, - hinges on "virtual", and - is a regression vs. gcc 5.x.
[Bug c++/70847] New: exponential time in cp_fold for chained virtual function calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70847
Bug ID: 70847
Summary: exponential time in cp_fold for chained virtual
function calls
Product: gcc
Version: 6.1.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jens.maurer at gmx dot net
Target Milestone: ---
Testcase:
struct D
{
virtual D& f();
};
void g()
{
D d;
d.f().f().f().f().f().f().f().f().f().f().f().f().f().f().f()
#if 1
.f().f().f().f().f().f().f().f().f().f().f()
#endif
;
}
$ time g++ -v -c tst.cxx
gcc version 6.1.0 (GCC)
[does not end]
Changing "#if 1" to "#if 0" yields:
$ time g++ -c output-strip.cxx
real0m3.341s
"perf top" shows cp_fold, cp_fold_r, cp_walk_subtrees, and walk_tree_1
functions.
[Bug c++/60685] exception not caught by enclosing catch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60685 --- Comment #4 from Jens Maurer jens.maurer at gmx dot net --- Works with 5.1.0 and 5.2.0, so this seems to be resolved.
[Bug c++/67064] Register asm variable broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67064
--- Comment #16 from Jens Maurer jens.maurer at gmx dot net ---
(In reply to Jason Merrill from comment #14)
'-Wpedantic' does not cause warning messages for use of the
alternate keywords whose names begin and end with '__'. Pedantic
warnings are also disabled in the expression that follows
'__extension__'. However, only system header files should use
these escape routes; application programs should avoid them.
Agreed, but this:
struct s {
int i;
};
register struct s *reg asm( si );
(note: no double underscores) should issue a diagnostic for violating 7.1.1p2
when invoking
g++ -std=c++14 -Wall -Wextra -Wpedantic -c reg-asm.cc
right? It doesn't. Total silence.
Leaving off the asm part gives
reg-asm.cc:6:20: error: register name not specified for 'reg'
register struct s *reg;
[Bug c++/67064] Register asm variable broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67064 --- Comment #8 from Jens Maurer jens.maurer at gmx dot net --- In general, x and (x) have the same meaning as per 5.1.1p6. There are a few (spelled-out) exceptions, though. One exception is inside a decltype-specifier, where decltype(e) is different from decltype((e)) as per 7.1.6.2p4. (Another exception is the fact that (f)(y) suppresses argument-dependent lookup for f as per 3.4.2p1. And then, if f is a function-like macro, it doesn't get expanded for (f)(y).) Considering the issue in this ticket, and ignoring the fact that reg should be a block-scope variable, reg is the name of a variable and therefore an lvalue. However, being an lvalue doesn't mean its address is taken. reg-i is equivalent to (reg)-i; in both cases, the lvalue-to-rvalue conversion is applied to reg to determine its pointer value (see 5.3.1p1). In short, using decltype to inspect the type of an expression might be misleading if you don't consider the special case in 7.1.6.2p4. May I venture a guess that the gcc implementation somehow lets the decltype special case bleed into general expression analysis?
[Bug c++/66954] New: function multiversioning fails for target aes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66954
Bug ID: 66954
Summary: function multiversioning fails for target aes
Product: gcc
Version: 5.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jens.maurer at gmx dot net
Target Milestone: ---
I would like to switch implementations depending on whether the (Intel) CPU has
AES instructions or not. Simplified testcase:
__attribute__((target(default)))
void foo()
{ }
__attribute__((target(aes)))
void foo()
{ }
int main()
{
void (*f)() = foo;
}
yields
g++ target-aes.cc
target-aes.cc: In function 'built-in':
target-aes.cc:7:6: error: No dispatcher found for aes
void foo()
^
[Bug c++/66583] New: incorrect implicitly-defined move constructor for class with anonymous union and NSDMI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66583
Bug ID: 66583
Summary: incorrect implicitly-defined move constructor for
class with anonymous union and NSDMI
Product: gcc
Version: 5.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jens.maurer at gmx dot net
Target Milestone: ---
The following code wrongly prints 0 instead of the correct 1:
$ g++ -std=c++11 union.cc
$ ./a.out
0
(reproducible with both 4.9.2 and 5.1.0)
#include algorithm
#include iostream
struct A {
A() { };
A(const A) { }
};
struct B {
union {
int m_1 = 0;
int m_2;
};
A dummy;
};
int main()
{
B b;
b.m_1 = 1;
B c(std::move(b));
std::cout c.m_1 std::endl;
}
The assembly code for B::B(B) when compiling unoptimized has this (x86-64):
movl(%rdx), %edx
movl%edx, (%rax)
Until here, we correctly copy the object representation of the anonymous union
(12.8p16).
movq-8(%rbp), %rax
movl$0, (%rax)
And then we seem to evaluate the non-static data member initializer for m_1,
which is (obviously) wrong.
[Bug c++/60685] exception not caught by enclosing catch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60685 Jens Maurer jens.maurer at gmx dot net changed: What|Removed |Added Version|4.8.2 |4.9.2 --- Comment #3 from Jens Maurer jens.maurer at gmx dot net --- Jonathan's reduced testcase reproducibly crashes when compiled with gcc 4.9.2, too.
[Bug c++/65140] New: crash with function multiversioning and LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65140
Bug ID: 65140
Summary: crash with function multiversioning and LTO
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jens.maurer at gmx dot net
The first example for function multiversioning given at
https://gcc.gnu.org/wiki/FunctionMultiVersioning crashes when compiled with
-flto.
Reduced example:
__attribute__ ((target (default)))
void foo() { }
__attribute__ ((target (sse4.2)))
void foo() { }
int main ()
{
foo();
}
Compiler output:
$ g++ -v -flto x.cc
...
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.9.2/configure --enable-languages=c,c++
--with-system-zlib --enable-lto --with-abi=m64 --disable-multilib
Thread model: posix
gcc version 4.9.2 (GCC)
...
x.cc: In function ‘foo() [clone .resolver]’:
x.cc:11:1: internal compiler error: Segmentation fault
}
^
0x990c0f crash_signal
../../gcc-4.9.2/gcc/toplev.c:337
0x8bd90e tree_is_indexable
../../gcc-4.9.2/gcc/lto-streamer-out.c:139
0x8bf56f lto_output_tree(output_block*, tree_node*, bool, bool)
../../gcc-4.9.2/gcc/lto-streamer-out.c:1352
0x8bfc74 output_function
../../gcc-4.9.2/gcc/lto-streamer-out.c:1832
0x8bfc74 lto_output()
../../gcc-4.9.2/gcc/lto-streamer-out.c:2084
0x8f39a1 write_lto
../../gcc-4.9.2/gcc/passes.c:2298
0x8f6550 ipa_write_summaries_1
../../gcc-4.9.2/gcc/passes.c:2360
0x8f6550 ipa_write_summaries()
../../gcc-4.9.2/gcc/passes.c:2417
0x71eb2a ipa_passes
../../gcc-4.9.2/gcc/cgraphunit.c:2078
0x71eb2a compile()
../../gcc-4.9.2/gcc/cgraphunit.c:2174
0x71ece4 finalize_compilation_unit()
../../gcc-4.9.2/gcc/cgraphunit.c:2329
0x5d30a3 cp_write_global_declarations()
../../gcc-4.9.2/gcc/cp/decl2.c:4643
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.
[Bug c++/60685] New: exception not caught by enclosing catch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60685 Bug ID: 60685 Summary: exception not caught by enclosing catch Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: jens.maurer at gmx dot net Created attachment 32465 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32465action=edit source code to reproduce the issue When compiling and linking the attached two files, I get a core dump, although I expect the catch(Ex): $ g++ -v -std=c++11 x.cc y.cc ... GNU C++ (GCC) version 4.8.2 (x86_64-unknown-linux-gnu) ... $ gdb ./a.out (gdb) run Starting program: /home/jmaurer/IDMS/svn/trunk/libs/tlfr/fundamental/./a.out terminate called after throwing an instance of 'Ex' Program received signal SIGABRT, Aborted. (gdb) bt #0 0x7722bf77 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #1 0x7722f5e8 in __GI_abort () at abort.c:90 #2 0x77b376e5 in __gnu_cxx::__verbose_terminate_handler() () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 #3 0x77b35856 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 #4 0x77b34919 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 #5 0x77b354ca in __gxx_personality_v0 () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 #6 0x775cc7f3 in ?? () from /lib/x86_64-linux-gnu/libgcc_s.so.1 #7 0x775ccb8b in _Unwind_RaiseException () from /lib/x86_64-linux-gnu/libgcc_s.so.1 #8 0x77b35aa1 in __cxa_throw () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 #9 0x0040094e in B::B() () #10 0x00400978 in A::f() () #11 0x00400923 in S::S(A) () #12 0x004008ba in main () $ ld --version GNU ld (GNU Binutils for Ubuntu) 2.23.52.20130913 This is also reproducible with $ ld --version GNU gold (GNU Binutils for Ubuntu 2.23.52.20130913) 1.11
[Bug c/60412] New: superfluous arithmetic generated for uneven tail handling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60412 Bug ID: 60412 Summary: superfluous arithmetic generated for uneven tail handling Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: jens.maurer at gmx dot net Created attachment 32262 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32262action=edit Testcase showing superfluous arithmetic in assembly The attached function processes a (possibly long) memory range. If more than 7 bytes are available, those are processed using g1(), which is able to process 8 bytes in one call. The tail end is then handled by g2(), one byte at a time. (In my application, the g1 and g2 functions are the Intel built-in CRC-32C operations.) On Intel x86-64, the following superfluous assembly code is produced between the calls to g1() and g2(): $ gcc -v -O3 -Wall -Wextra -c opt-tail.c ... Target: x86_64-unknown-linux-gnu ... GNU C (GCC) version 4.8.2 (x86_64-unknown-linux-gnu) compiled by GNU C version 4.8.2, GMP version 5.1.2, MPFR version 3.1.1-p2, MPC version 1.0.1 $ objdump -C -D opt-tail.o ... 44: 4c 89 e2mov%r12,%rdx 47: 48 29 dasub%rbx,%rdx 4a: 48 83 ea 08 sub$0x8,%rdx 4e: 48 c1 ea 03 shr$0x3,%rdx 52: 48 8d 5c d3 08 lea0x8(%rbx,%rdx,8),%rbx This seems to be completely redundant.
[Bug c++/60372] New: incorrect destruction order for function parameter objects
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60372
Bug ID: 60372
Summary: incorrect destruction order for function parameter
objects
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jens.maurer at gmx dot net
Parameter objects are not destroyed when the called function returns, but later
(too late). The C++ standard says in 5.2.2p4 [expr.call]:
... The lifetime of a parameter ends when the function in which it is defined
returns. ...
However, the following program shows that S is destroyed too late, after the
call to h():
#include stdio.h
struct S {
S(int) { printf(S(int)\n); }
~S() { printf(~S\n); }
};
void f(S) { printf(f(S)\n); }
void h() { printf(h()\n); }
int main()
{
f({0}), h();
}
g++ -Wall -Wextra -std=c++11 -pedantic func-destroy.cc
./a.out
S(int)
f(S)
h()
~S
S should be destroyed before the call to h(). Note that no temporary is
involved (which would correctly be destroyed at the end of the
full-expression); the copy-list-initialization initializes the parameter
object.
[Bug c++/59248] [4.8 regression] pointless -Wconversion warning with sizeof, take 2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59248
--- Comment #2 from Jens Maurer jens.maurer at gmx dot net ---
This one:
$ cat ~/x.cc
int main()
{
int x = 2*sizeof(int);
int y { 2* sizeof(int) };
}
(sorry, forgot to attach earlier)
[Bug c++/59248] New: [4.8 regression] pointless -Wconversion warning with sizeof, take 2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59248
Bug ID: 59248
Summary: [4.8 regression] pointless -Wconversion warning with
sizeof, take 2
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jens.maurer at gmx dot net
The simple case was fixed with
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56930 (thanks, Jason), but a
slightly more involved case still warns spuriously:
$ g++ -Wconversion -std=c++11 x.cc
x.cc: In function ‘int main()’:
x.cc:3:12: warning: conversion to ‘int’ from ‘long unsigned int’ may alter its
value [-Wconversion]
int x = 2*sizeof(int);
^
x.cc:4:12: warning: conversion to ‘int’ from ‘long unsigned int’ may alter its
value [-Wconversion]
int y { 2* sizeof(int) };
^
This didn't produce any warnings with gcc 4.7.3.
[Bug c++/56930] New: regression: pointless -Wconversion warning with sizeof
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56930
Bug #: 56930
Summary: regression: pointless -Wconversion warning with sizeof
Classification: Unclassified
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jens.mau...@gmx.net
int main()
{
int x = sizeof(int);
int y { sizeof(int) };
}
$ g++ -Wconversion -std=c++11 conv.cc
conv.cc: In function ‘int main()’:
conv.cc:3:17: warning: conversion to ‘int’ from ‘long unsigned int’ may alter
its value [-Wconversion]
int x = sizeof(int);
^
gcc 4.7.x didn't warn about this case, and rightly so: There should be no
conversion warnings triggered if the compiler can detect that the value in
question is constant and no narrowing actually happens.
conv.cc:4:17: warning: conversion to ‘int’ from ‘long unsigned int’ may alter
its value [-Wconversion]
int y { sizeof(int) };
^
The warning in this case is even more confusing: The compiler should generate a
language-mandated diagnostic if narrowing a non-constant, but the warning is
just besides the point at all.
[Bug c++/55972] New: cannot access private member from lambda used in NSDMI
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55972
Bug #: 55972
Summary: cannot access private member from lambda used in NSDMI
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jens.mau...@gmx.net
The following short translation unit shows the issue:
class C
{
void f();
int j = 10;
int i = [this]() { return this-j; }();
};
$ g++ -std=c++11 x.cc
x.cc: In lambda function:
x.cc:4:11: error: ‘int C::j’ is private
x.cc:5:39: error: within this context
Non-static data member initializers (and lambdas used therein) should be able
to access private members of their class.
[Bug c++/55446] New: array new with size zero vanishes from object code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55446
Bug #: 55446
Summary: array new with size zero vanishes from object code
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jens.mau...@gmx.net
Host: x86_64-unknown-linux-gnu
Target: x86_64-unknown-linux-gnu
The following program compiles successfully and outputs nothing at all. In
fact, the generated assembly has an empty main. This happens even when
compiling with -O0.
#include iostream
struct S {
S() { }
};
int main()
{
std::cout new S[0] bla std::endl;
}
$ g++ new-opt.cc -Wall -Wextra
$ ./a.out
(no output)
The issue goes away when removing the default constructor of S. It seems gcc
believes array-new with zero size is undefined behavior and thus removes the
rest of the expression. I can't follow the undefined behavior part;
array-new with zero size should yield a non-zero pointer (see 3.7.3.1p2
[basic.stc.dynamic.allocation] and 5.3.4p7 [expr.new]).
[Bug target/39102] gcc generating multiple stack stores in optimised code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39102
--- Comment #2 from Jens Maurer jens.maurer at gmx dot net 2012-11-23
14:07:34 UTC ---
Here is another test case:
struct S {
unsigned char * p;
unsigned char * limit;
};
S g(S s);
inline __attribute__((always_inline)) S f(S s, unsigned int n);
S f(S s, unsigned int n)
{
if (__builtin_expect(s.p + n s.limit, 1)) {
s.p += n;
return s;
}
return g(s);
}
extern S sext;
int main()
{
S s = sext;
s = f(s, 4);
s = f(s, 8);
s = f(s, 2);
return (int)(unsigned long)s.p;
}
leading to
movq%rax, (%rsp)
movq%rdx, 8(%rsp)
in the code paths calling g(s), although s is kept in registers throughout.
[Bug c++/54079] New: __builtin_ia32_palignr128 can't be called
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54079
Bug #: 54079
Summary: __builtin_ia32_palignr128 can't be called
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jens.mau...@gmx.net
#pragma GCC target (ssse3)
int main()
{
long long x __attribute__((vector_size(16)));
x = __builtin_ia32_palignr128(x, x, 4);
}
yields:
$ g++ x.cc
x.cc: In function ‘int main()’:
x.cc:7:42: error: the last argument must be an 8-bit immediate
How much more immediate can you get when you pass an integer literal?
[Bug libstdc++/52689] static linking with libstdc++ fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52689 --- Comment #6 from Jens Maurer jens.maurer at gmx dot net 2012-03-27 07:03:46 UTC --- $ nm /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../lib64/libstdc++.a | grep GLIBCXX_3.4.14 B _ZSt15future_category@@GLIBCXX_3.4.14
[Bug libstdc++/52689] New: static linking with libstdc++ fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52689
Bug #: 52689
Summary: static linking with libstdc++ fails
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jens.mau...@gmx.net
$ cat x.cc
#include iostream
int main()
{
std::cout hello\n;
}
$ gcc x.cc -Wl,-Bstatic -lstdc++ -Wl,-Bdynamic
/usr/bin/ld: a.out: No symbol version section for versioned symbol
`_ZSt15future_category@@GLIBCXX_3.4.14'
/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: error: ld returned 1 exit status
or
$ g++ x.cc -static-libstdc++
/usr/bin/ld: a.out: No symbol version section for versioned symbol
`_ZSt15future_category@@GLIBCXX_3.4.14'
/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: error: ld returned 1 exit status
$ ld --version
GNU ld (GNU Binutils for Ubuntu) 2.21.53.20110810
[Bug libstdc++/52689] static linking with libstdc++ fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52689 --- Comment #2 from Jens Maurer jens.maurer at gmx dot net 2012-03-23 20:13:11 UTC --- $ find /usr/lib -name libstdc++.a /usr/lib/gcc/x86_64-linux-gnu/4.6/32/libstdc++.a /usr/lib/gcc/x86_64-linux-gnu/4.6/libstdc++.a /usr/lib/gcc/x86_64-linux-gnu/4.5/libstdc++.a However, these old libstdc++.a files are NOT used: g++ -Wl,--verbose x.cc -static-libstdc++ GNU ld (GNU Binutils for Ubuntu) 2.21.53.20110810 ... attempt to open /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/crtbegin.o succeeded /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/crtbegin.o attempt to open /home/jmaurer/tmp/cc0s7Nqc.o succeeded /home/jmaurer/tmp/cc0s7Nqc.o attempt to open /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/libstdc++.a failed attempt to open /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../lib64/libstdc++.a succeeded (/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../lib64/libstdc++.a)globals_io.o ... The libstdc++.a file used is the one installed today: $ ls -lL /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../lib64/libstdc++.a -rw-r--r-- 1 root root 16227426 2012-03-23 13:31 /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../lib64/libstdc++.a
[Bug libstdc++/52689] static linking with libstdc++ fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52689 --- Comment #3 from Jens Maurer jens.maurer at gmx dot net 2012-03-23 20:14:33 UTC --- In case it matters, here's the configure info etc: $ g++ -v Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.7.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc-4.7.0/configure -enable-languages=c,c++ --prefix=/usr/local --enable-shared --enable-linker-build-id --with-system-zlib --without-included-gettext --enable-threads=posix --enable-lto Thread model: posix gcc version 4.7.0 (GCC)
[Bug c++/52099] New: Incorrectly applying conversion when catching pointer-to-members
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52099
Bug #: 52099
Summary: Incorrectly applying conversion when catching
pointer-to-members
Classification: Unclassified
Product: gcc
Version: 4.6.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jens.mau...@gmx.net
The follwing program shows that gcc erroneously matches an exception object of
a pointer-to-member type to a handler of (slightly) different type. There is
no allowance in 15.3 [except handle] to do that. In particular, adding a
cv-qualifier on top of the pointer-to-member type (which would be allowed)
cannot morph a pointer-to-nonconst-member function into a
pointer-to-const-member function.
#include cassert
struct A
{
void foo() {}
};
int main()
{
try
{
throw A::foo;
}
catch (void (A::*)() const)
{
assert(false); // g++ currently takes this route
}
catch (...)
{
}
}
[Bug c/52057] New: dropping const in assignment gives only a warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52057 Bug #: 52057 Summary: dropping const in assignment gives only a warning Classification: Unclassified Product: gcc Version: 4.6.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: jens.mau...@gmx.net According to C99 6.5.16.1p1, the following is ill-formed: void * p = (const int *) 0; However, gcc only issues a warning, not an error: gcc -c -ansi -pedantic 1251.c 1251.c:1:12: warning: initialization discards ‘const’ qualifier from pointer target type [enabled by default] (In C++ mode, the code above results in a hard error, as it should.)
[Bug c++/48577] New: unexpected ast of kind unordered_expr using isnan()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48577
Summary: unexpected ast of kind unordered_expr using isnan()
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jens.mau...@gmx.net
extern C {
extern int isnan (double __value) throw () __attribute__ ((__const__));
}
int main()
{
double v = 0;
const bool b = isnan(v);
}
compiling with g++ -std=gnu++0x bug.cc
yields:
bug.cc: In function ‘int main()’:
bug.cc:11:27: sorry, unimplemented: unexpected ast of kind unordered_expr
bug.cc:11: confused by earlier errors, bailing out
(Using -std=c++0x avoids the issue.)
[Bug c++/48577] unexpected ast of kind unordered_expr using isnan()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48577 --- Comment #1 from Jens Maurer jens.maurer at gmx dot net 2011-04-12 16:39:03 UTC --- It works with gcc 4.5.2, so it seems to be a 4.6 regression.
[Bug c++/48453] [C++0x] Invalid reference initialization via explicit conversion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48453 Jens Maurer jens.maurer at gmx dot net changed: What|Removed |Added CC||jens.maurer at gmx dot net --- Comment #3 from Jens Maurer jens.maurer at gmx dot net 2011-04-06 21:56:51 UTC --- Agreed. The wording in the standard should be fixed.
[Bug c++/46188] -fipa-cp removes destructor call
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46188 --- Comment #3 from Jens Maurer jens.maurer at gmx dot net 2010-10-27 06:14:31 UTC --- Created attachment 22170 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22170 improved testcase The previous testcase had the problem that the compiler could legitimately assume that Array::operator= actually left the Array empty, and thus omission of the destructor calls for the nested Array was actually fine. I've now added a call to an external function do_something at the end of Array::operator= (which could change the state of the Array as it pleases); this ought to kill any ideas the compiler might retain about the state of the Array. The issue remains reproducible; assembler code essentially unchanged from above. Please excuse the confusion.
[Bug c++/46188] -fipa-cp removes destructor call
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46188 --- Comment #4 from Jens Maurer jens.maurer at gmx dot net 2010-10-27 07:55:37 UTC --- Created attachment 22171 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22171 two if conditions removed from the testcase Two if conditions increase the complexity of the assembler code. Removing them doesn't change anything in reproducibility. So I removed them.
[Bug c++/46188] -fipa-cp removes destructor call
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46188 --- Comment #6 from Jens Maurer jens.maurer at gmx dot net 2010-10-27 13:15:19 UTC --- Thanks. Yes, the testcase was reduced from preprocessed files. Unfortunately, you can't remove the #pragma interface without breaking the testcase. But the only documented effect that #pragma interface should have is that I get linker errors, i.e. undefined symbols.
[Bug c++/46188] -fipa-cp removes destructor call
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46188 --- Comment #6 from Jens Maurer jens.maurer at gmx dot net 2010-10-27 13:15:19 UTC --- Thanks. Yes, the testcase was reduced from preprocessed files. Unfortunately, you can't remove the #pragma interface without breaking the testcase. But the only documented effect that #pragma interface should have is that I get linker errors, i.e. undefined symbols.
[Bug c++/46188] New: -fipa-cp removes destructor call
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46188 Summary: -fipa-cp removes destructor call Product: gcc Version: 4.5.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: jens.mau...@gmx.net Created attachment 22164 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22164 source file to reproduce the bug In the attached source code, the destructor calls for B::char_array when destroying c2 at the end of function f are removed by the optimizer when compiling with -fipa-cp . I have removed .cfi notes in the assembly quoted below, for conciseness. bad compile: $ g++ -S playground.cxx -fverbose-asm -O2 yields (note that no operator delete[] is called on B::char_array): 159 .LEHB0: 160 callg(C const, C) # 161 .LEHE0: 162 movq24(%rsp), %rdi # c2.b_array.data, D.2822 163 testq %rdi, %rdi # D.2822 164 je .L15#, 165 calloperator delete[](void*)# 166 .L15: 167 movq16(%rsp), %rdi # c2.s.adr, D.2837 168 testq %rdi, %rdi # D.2837 169 je .L14#, 170 calloperator delete[](void*)# 171 .L14: 172 addq$48, %rsp #, 175 popq%rbx# 177 ret good compile: $ g++ -S playground.cxx -fverbose-asm -O2 -fno-ipa-cp 165 callg(C const, C) # 166 .LEHE0: 167 movq8(%rsp), %rbx # c2.b_array.data, p 168 testq %rbx, %rbx # p 169 je .L15#, 170 movq16(%rsp), %r12 # c2.b_array.size, D.2808 171 testq %r12, %r12 # D.2808 172 je .L16#, 173 xorl%ebp, %ebp # i 174 jmp .L20# 175 .p2align 4,,10 176 .p2align 3 177 .L25: 178 addq$24, %rbx #, p 179 .L20: 180 movq(%rbx), %rdi# p-char_array.data, D.2820 181 testq %rdi, %rdi # D.2820 182 je .L18#, 183 calloperator delete[](void*)# 184 .L18: 185 addq$1, %rbp#, i 186 cmpq%rbp, %r12 # i, D.2808 187 ja .L25#, 188 movq8(%rsp), %rbx # c2.b_array.data, p 189 .L16: 190 testq %rbx, %rbx # p 191 je .L15#, 192 movq%rbx, %rdi # p, 193 calloperator delete[](void*)# 194 .L15: 195 movq(%rsp), %rdi# c2.s.adr, D.2824 196 testq %rdi, %rdi # D.2824 197 je .L14#, 198 calloperator delete[](void*)# 199 .L14: 200 addq$32, %rsp #, 203 popq%rbx# 205 popq%rbp# 207 popq%r12# 209 ret Removing any one of the seemingly unrelated lines marked ##1, ##2, ##3 will produce correct compiler output. Also, messing with the Array::destruct function (e.g. use data + i instead of p, use the constants for start/end directly instead of passing via parameters) will remove the problem.
[Bug c++/46188] -fipa-cp removes destructor call
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46188 Jens Maurer jens.maurer at gmx dot net changed: What|Removed |Added Attachment #22164|0 |1 is obsolete|| --- Comment #2 from Jens Maurer jens.maurer at gmx dot net 2010-10-26 21:09:14 UTC --- Created attachment 22165 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22165 file to reproduce the bug, now with all aliasing and memory allocation removed Thanks for your comment. I've uploaded a new test file that removes all memory allocations and never ever stores something in this-data, so no aliasing issues should arise. Instead of delete[], I'm now calling an external function h. As usual, I've removed the .cfi notes from the assembly quotes below. bad compile: $ g++ -S playground2.cxx -fverbose-asm -O2 125 callg(C const, C) # 126 .LEHE0: 127 movq24(%rsp), %rdi # c2.b_array.data, D.3401 128 testq %rdi, %rdi # D.3401 129 je .L9 #, 130 .LEHB1: 131 callh(char*)# 132 .LEHE1: 133 .L9: 134 movq16(%rsp), %rdi # c2.s.adr, 135 .LEHB2: 136 callh(char*)# 137 .LEHE2: 138 addq$48, %rsp #, 141 popq%rbx# 143 ret good compile: $ g++ -S playground2.cxx -fverbose-asm -O2 -fno-ipa-cp 130 callg(C const, C) # 131 .LEHE0: 132 movq8(%rsp), %rbx # c2.b_array.data, p 133 testq %rbx, %rbx # p 134 je .L9 #, 135 movq16(%rsp), %r12 # c2.b_array.size, D.3387 136 testq %r12, %r12 # D.3387 137 je .L10#, 138 xorl%ebp, %ebp # i 139 jmp .L14# 140 .p2align 4,,10 141 .p2align 3 142 .L22: 143 addq$24, %rbx #, p 144 .L14: 145 movq(%rbx), %rdi# p-char_array.data, D.3401 146 testq %rdi, %rdi # D.3401 147 je .L12#, 148 .LEHB1: 149 callh(char*)# 150 .L12: 151 addq$1, %rbp#, i 152 cmpq%rbp, %r12 # i, D.3387 153 ja .L22#, 154 movq8(%rsp), %rbx # c2.b_array.data, p 155 .L10: 156 movq%rbx, %rdi # p, 157 callh(char*)# 158 .LEHE1: 159 .L9: 160 movq(%rsp), %rdi# c2.s.adr, 161 .LEHB2: 162 callh(char*)# 163 .LEHE2: 164 addq$32, %rsp #, 167 popq%rbx# 169 popq%rbp# 171 popq%r12# 173 ret As can be seen, the destructors on B::char_array are being called (as evidenced by the loop calling h), as opposed to the bad compile, where this does not happen. The compile turns good under the same modifications as before.
