[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.)
