[Bug c++/49395] Non-class prvalues seem to have cv-qualification with GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49395 Hubert Tong changed: What|Removed |Added Status|SUSPENDED |RESOLVED Resolution|--- |FIXED --- Comment #6 from Hubert Tong --- A().i on line 8 is specified to be an xvalue of type "volatile int" nowadays.
[Bug c++/107962] GCC allows constexpr copy construction despite uninitialized member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107962 --- Comment #2 from Hubert Tong --- https://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#2264 suggests that the GCC behaviour may be the desired one because copies of partially-initialized structures are allowed in C but cause undefined behaviour in C++.
[Bug c++/108324] New: Temporary not bound to reference in default member initializer destroyed early from parenthesized expression-list initialization of aggregate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108324
Bug ID: 108324
Summary: Temporary not bound to reference in default member
initializer destroyed early from parenthesized
expression-list initialization of aggregate
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: rejects-valid, wrong-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hstong at ca dot ibm.com
Target Milestone: ---
While the lifetime-extension rules for temporaries bound to a reference member
differ between braced and parenthesized aggregate initialization, the
full-expression associated with default member initializers used in the
aggregate initialization are the same in both cases ([intro.execution]).
It seems GCC thinks that the parenthesized expression-list case causes
destruction of temporaries from the default member initializer at an earlier
point than in the braced initialization case.
ICC does not have this problem (at least when doing constant expression
evaluation).
Online compiler link: https://godbolt.org/z/aPhffr7xT
### SOURCE ():
struct A {
constexpr A(int x) : x(x) {}
constexpr ~A() { x = 13; }
int x;
constexpr A () { return *this; }
};
struct B {
const A *ap = (42).ref();
};
constexpr int f() { return B{}.ap->x; }
constexpr int g() { return B().ap->x; }
extern char q[f()];
extern char q[42];
extern char k[g()];
extern char k[42];
### COMPILER INVOCATION COMMAND:
g++ -fsyntax-only -std=c++2b -xc++ -
### ACTUAL OUTPUT:
:15:16: error: size of array 'k' is not an integral constant-expression
:16:13: error: conflicting declaration 'char k [42]'
:15:13: note: previous declaration as 'char k [1]'
### EXPECTED OUTPUT:
(Clean compile)
### COMPILER VERSION INFO (g++ -v):
Using built-in specs.
COLLECT_GCC=/opt/wandbox/gcc-head/bin/g++
COLLECT_LTO_WRAPPER=/opt/wandbox/gcc-head/libexec/gcc/x86_64-pc-linux-gnu/13.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../source/configure --prefix=/opt/wandbox/gcc-head
--enable-languages=c,c++ --disable-multilib --without-ppl --without-cloog-ppl
--enable-checking=release --disable-nls --enable-lto
LDFLAGS=-Wl,-rpath,/opt/wandbox/gcc-head/lib,-rpath,/opt/wandbox/gcc-head/lib64,-rpath,/opt/wandbox/gcc-head/lib32
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 13.0.0 20230106 (experimental) (GCC)
[Bug c++/107962] New: GCC allows constexpr copy construction despite uninitialized member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107962
Bug ID: 107962
Summary: GCC allows constexpr copy construction despite
uninitialized member
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: accepts-invalid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hstong at ca dot ibm.com
Target Milestone: ---
Lvalue-to-rvalue conversion of objects having indeterminate value is not
allowed during evaluation of a core constant expression (see N4919 subclause
7.7 [expr.const] bullet 5.11). GCC allows such lvalue-to-rvalue conversion
during the constant evaluation of trivial copy constructors.
In the case below, the `y` member of `a` has indeterminate value when the
initialization of `b` is performed. Clang and ICC correctly diagnose the issue.
Compiler Explorer link: https://godbolt.org/z/afq1h895a
### SOURCE ():
struct A {
int x, y;
constexpr A() {}
};
constexpr int f() {
A a;
a.x = 42;
A b = a;
return b.x;
}
extern constexpr int x = f();
### COMPILER INVOCATION:
g++ -xc++ -fsyntax-only -std=c++2a -
### ACTUAL OUTPUT:
(Clean compile)
### EXPECTED OUTPUT:
(Error that `x` is not initialized by a constant expression)
### COMPILER VERSION INFO (g++ -v):
Using built-in specs.
COLLECT_GCC=/opt/wandbox/gcc-head/bin/g++
COLLECT_LTO_WRAPPER=/opt/wandbox/gcc-head/libexec/gcc/x86_64-pc-linux-gnu/13.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../source/configure --prefix=/opt/wandbox/gcc-head
--enable-languages=c,c++ --disable-multilib --without-ppl --without-cloog-ppl
--enable-checking=release --disable-nls --enable-lto
LDFLAGS=-Wl,-rpath,/opt/wandbox/gcc-head/lib,-rpath,/opt/wandbox/gcc-head/lib64,-rpath,/opt/wandbox/gcc-head/lib32
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 13.0.0 20221202 (experimental) (GCC)
[Bug c++/102000] Defaulted consteval default constructor that performs no initialization is not rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102000
Hubert Tong changed:
What|Removed |Added
CC||hstong at ca dot ibm.com
--- Comment #4 from Hubert Tong ---
(In reply to Johel Ernesto Guerrero Peña from comment #3)
> https://bugs.llvm.org/show_bug.cgi?id=51560#c1 points out
> > I'm not sure what you think the problem is here. The constructor isn't
> > getting called; see http://eel.is/c++draft/dcl.init.general#8 .
> It seems to me that they are right and the example above is well-formed.
That depends on what "the semantic constraints for default-initialization are
checked" means.
(In reply to Johel Ernesto Guerrero Peña from comment #0)
> ```
> An immediate invocation shall be a constant expression. --
> https://eel.is/c++draft/expr.const#13.sentence-3
>
> Lots of wording in between...
>
> 2 A variable or temporary object o is constant-initialized if
> (2.1) either it has an initializer or its default-initialization results
> in some initialization being performed, and
> -- https://eel.is/c++draft/expr.const#2
> 7 To default-initialize an object of type T means:
> (7.3) Otherwise, no initialization is performed.
> -- https://eel.is/c++draft/dcl.init.general#7
> ```
That wording would be relevant for a similar case involving `constinit`. Here,
the relevant wording is in 7.7 [expr.const] paragraph 12 (and the uninitialized
`int` is fine with the current wording). The example needs to be changed to use
pointers:
```
struct A {
consteval A() = default;
private:
int *m;
};
struct B {
consteval B() = default;
private:
int *m, *n = 0;
};
void f() {
A a; // GCC accepts this despite pointer with indeterminate value
B b; // GCC rejects this
}
```
So it seems GCC just doesn't do certain checking when the constructor is
trivial.
[Bug libstdc++/105934] New: [9/10/11/12/13 Regression] C++11 pointer versions of atomic_fetch_add missing because of P0558
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105934
Bug ID: 105934
Summary: [9/10/11/12/13 Regression] C++11 pointer versions of
atomic_fetch_add missing because of P0558
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: hstong at ca dot ibm.com
Target Milestone: ---
P0558 removed the "pointer specializations" of `atomic_fetch_add`.
The replacements are not call-compatible for calls that use explicit template
arguments to guide conversions.
https://godbolt.org/z/aTT9EdP93
### SOURCE ():
#include
struct A { template operator std::atomic *(); };
int *f(A *ap) { return std::atomic_fetch_add(*ap, 1); }
### COMPILER INVOCATION:
g++ -fsyntax-only -std=c++11 -xc++ -
### ACTUAL OUTPUT:
: In function 'int* f(A*)':
:3:50: error: no matching function for call to
'atomic_fetch_add(A&, int)'
In file included from :1:
/opt/wandbox/gcc-head/include/c++/13.0.0/atomic:1525:5: note: candidate: '_ITp
std::atomic_fetch_add(atomic<_ITp>*, __atomic_diff_t<_ITp>) [with _ITp = int;
__atomic_diff_t<_ITp> = int]'
1525 | atomic_fetch_add(atomic<_ITp>* __a,
| ^~~~
/opt/wandbox/gcc-head/include/c++/13.0.0/atomic:1525:36: note: no known
conversion for argument 1 from 'A' to 'std::atomic*'
1525 | atomic_fetch_add(atomic<_ITp>* __a,
| ~~^~~
/opt/wandbox/gcc-head/include/c++/13.0.0/atomic:1531:5: note: candidate: '_ITp
std::atomic_fetch_add(volatile atomic<_ITp>*, __atomic_diff_t<_ITp>) [with _ITp
= int; __atomic_diff_t<_ITp> = int]'
1531 | atomic_fetch_add(volatile atomic<_ITp>* __a,
| ^~~~
/opt/wandbox/gcc-head/include/c++/13.0.0/atomic:1531:45: note: no known
conversion for argument 1 from 'A' to 'volatile std::atomic*'
1531 | atomic_fetch_add(volatile atomic<_ITp>* __a,
| ~~~^~~
### EXPECTED OUTPUT:
Clean compile
### COMPILER VERSION INFO (g++ -v):
Using built-in specs.
COLLECT_GCC=/opt/wandbox/gcc-head/bin/g++
COLLECT_LTO_WRAPPER=/opt/wandbox/gcc-head/libexec/gcc/x86_64-pc-linux-gnu/13.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../source/configure --prefix=/opt/wandbox/gcc-head
--enable-languages=c,c++ --disable-multilib --without-ppl --without-cloog-ppl
--enable-checking=release --disable-nls --enable-lto
LDFLAGS=-Wl,-rpath,/opt/wandbox/gcc-head/lib,-rpath,/opt/wandbox/gcc-head/lib64,-rpath,/opt/wandbox/gcc-head/lib32
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 13.0.0 20220611 (experimental) (GCC)
[Bug c/105588] _Alignof (C) and alignof (C++) on dereference of `double *` disagree on 32-bit x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105588
--- Comment #4 from Hubert Tong ---
(In reply to Jakub Jelinek from comment #3)
> _Alignof(expression) works like __alignof__(expression) which works like
> __alignof__(__typeof(expression)), while _Alignof(type_name) is mandated by
> the standard to work differently.
Except it doesn't work that way. `__alignof__(expression)` is sensitive to what
the expression is in ways other than its type:
https://godbolt.org/z/GjETGnaGn
```
struct A {
double d;
} a;
void f() {
extern char x[__alignof__(__typeof(a.d))];
char (*y)[_Alignof(a.d)] = // warns
}
```
So, if it cares what the expression refers to, then when what is referred to is
unknown, the question becomes what `_Alignof` means: Is it the guaranteed
alignment (of what you were given) or the preferred alignment (for what you
might allocate)?
`_Alignof` already means "guaranteed alignment" in `_Alignof(type)`.
> The difference is that in the ia32 psABI, double is normally 8 byte aligned,
> except when inside of struct/union where the alignment is lowered to 4 byte
> alignment.
> Changing any of this would be a significant ABI change.
There is no request here to change the result of the actual allocation used for
layout or allocation purposes. Just a request to make GNU C's
`_Alignof(expression)` consistent with GNU C++'s `alignof(expression)` (both
being GNU extensions).
[Bug c/105588] _Alignof (C) and alignof (C++) on dereference of `double *` disagree on 32-bit x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105588 --- Comment #2 from Hubert Tong --- (In reply to Andrew Pinski from comment #1) > _Alignof(expression) is still an extension it can return what ever GCC > decides Sure, although why GCC should have corresponding C and C++ extensions that behave differently from each other is a bit of a mystery here.
[Bug c/105588] New: _Alignof (C) and alignof (C++) on dereference of `double *` disagree on 32-bit x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105588
Bug ID: 105588
Summary: _Alignof (C) and alignof (C++) on dereference of
`double *` disagree on 32-bit x86
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: hstong at ca dot ibm.com
Target Milestone: ---
Target: x86_64-pc-linux-gnu
_Alignof(expression) on a dereference of a pointer to double of unknown value
should produce the ABI-required alignment and not the preferred alignment.
The equivalent C++ program behaves as expected.
Online compiler link: https://godbolt.org/z/Tb93a6fcT
### SOURCE ():
void f(double *pd) {
extern char x[_Alignof(double)];
char (*y)[_Alignof(*pd)] =
}
### COMPILER INVOCATION COMMAND:
gcc -m32 -fsyntax-only -xc -
### ACTUAL OUTPUT:
: In function 'f':
:3:30: warning: initialization of 'char (*)[8]' from incompatible
pointer type 'char (*)[4]' [-Wincompatible-pointer-types]
### EXPECTED OUTPUT:
(No "incompatible pointer types" warning)
### COMPILER VERSION INFO (`gcc -v`):
Using built-in specs.
COLLECT_GCC=/opt/wandbox/gcc-head/bin/gcc
COLLECT_LTO_WRAPPER=/opt/wandbox/gcc-head/libexec/gcc/x86_64-pc-linux-gnu/13.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../source/configure --prefix=/opt/wandbox/gcc-head
--enable-languages=c,c++ --disable-multilib --without-ppl --without-cloog-ppl
--enable-checking=release --disable-nls --enable-lto
LDFLAGS=-Wl,-rpath,/opt/wandbox/gcc-head/lib,-rpath,/opt/wandbox/gcc-head/lib64,-rpath,/opt/wandbox/gcc-head/lib32
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 13.0.0 20220511 (experimental) (GCC)
[Bug c++/105290] New: "Purely syntactic" disambiguation but GCC applies semantic rules for constant expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105290
Bug ID: 105290
Summary: "Purely syntactic" disambiguation but GCC applies
semantic rules for constant expressions
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: accepts-invalid, rejects-valid, wrong-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hstong at ca dot ibm.com
Target Milestone: ---
As far as parsing is concerned, a _constant-expression_ is just a
_conditional-expression_. There is no statement that a _constant-expression_
has to be semantically a constant expression to be parsed as one.
Every use of _constant-expression_ in the grammar is associated with a
case-specific (semantic) statement that applies the semantic constant
expression requirements.
It looks like GCC applies the semantic rules for constant expressions while
performing vexing parse disambiguation, which the standard says is "purely
syntactic".
Compiler Explorer link: https://godbolt.org/z/Ms38PPsqh
### SOURCE (``):
typedef int *Ptr;
int idx(unsigned *) { return 0; }
constexpr int idx(short *) { return 1; }
void zip(void **p) {
int val(Ptr (*p)[idx((short *)0)]); // constant expression in array
declarator
val(nullptr);
}
void zap(void **p) {
int val(Ptr(*p)[idx((unsigned *)0)]); // non-constant expression in subscript
expression?!
val(nullptr);
}
### ACTUAL OUTPUT:
: In function 'void zap(void**)':
:10:6: error: 'val' cannot be used as a function
### EXPECTED OUTPUT:
(Clean compile)
### COMPILER INVOCATION:
g++ -fsyntax-only -Wno-vexing-parse -xc++ -
### COMPILER VERSION INFO (`g++ -v`):
Using built-in specs.
COLLECT_GCC=/opt/wandbox/gcc-head/bin/g++
COLLECT_LTO_WRAPPER=/opt/wandbox/gcc-head/libexec/gcc/x86_64-pc-linux-gnu/12.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../source/configure --prefix=/opt/wandbox/gcc-head
--enable-languages=c,c++ --disable-multilib --without-ppl --without-cloog-ppl
--enable-checking=release --disable-nls --enable-lto
LDFLAGS=-Wl,-rpath,/opt/wandbox/gcc-head/lib,-rpath,/opt/wandbox/gcc-head/lib64,-rpath,/opt/wandbox/gcc-head/lib32
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.1 20220415 (experimental) (GCC)
[Bug c++/104994] New: extern thread_local declaration rejected in constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104994
Bug ID: 104994
Summary: extern thread_local declaration rejected in constexpr
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hstong at ca dot ibm.com
Target Milestone: ---
GCC rejects block-scope extern declarations with the `thread_local` keyword in
constexpr bodies. The relevant wording (prior to removal by P2242
<https://wg21.link/p2242>) prohibits only definitions.
### SOURCE ():
constexpr void f() {
extern thread_local int x;
}
### COMPILER INVOCATION:
g++ -fsyntax-only -std=c++20 -xc++ -
### ACTUAL OUTPUT:
: In function 'constexpr void f()':
:2:27: error: 'x' declared 'thread_local' in 'constexpr' function only
available with '-std=c++2b' or '-std=gnu++2b'
### EXPECTED OUTPUT:
Clean compile.
### COMPILER VERSION INFO (g++ -v):
Using built-in specs.
COLLECT_GCC=/opt/wandbox/gcc-head/bin/g++
COLLECT_LTO_WRAPPER=/opt/wandbox/gcc-head/libexec/gcc/x86_64-pc-linux-gnu/12.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../source/configure --prefix=/opt/wandbox/gcc-head
--enable-languages=c,c++ --disable-multilib --without-ppl --without-cloog-ppl
--enable-checking=release --disable-nls --enable-lto
LDFLAGS=-Wl,-rpath,/opt/wandbox/gcc-head/lib,-rpath,/opt/wandbox/gcc-head/lib64,-rpath,/opt/wandbox/gcc-head/lib32
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.1 20220319 (experimental) (GCC)
[Bug target/100641] Link error when using extern thread_local variables on AIX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100641 Hubert Tong changed: What|Removed |Added CC||hstong at ca dot ibm.com --- Comment #2 from Hubert Tong --- This was addressed in Clang last year. The AIX linker does not have the same weak reference semantics as some other linkers. The means that the TLS init function needs to be defined by the object file containing the definition of the `thread_local` variable if the language semantics does not make it so that all potential references occur in contexts where it is known that the initialization/finalization is constant.
[Bug c++/103060] New: Argument initialization side-effects missing: delegating from base constructor to inherited constructor from virtual base
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103060
Bug ID: 103060
Summary: Argument initialization side-effects missing:
delegating from base constructor to inherited
constructor from virtual base
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hstong at ca dot ibm.com
Target Milestone: ---
The "only for the constructor of the most-derived class, virtual bases are
initialized" wording applies only to the non-delegating case. For a delegating
constructor, the target constructor is called even if it is inherited from a
virtual base and the constructor is not for the most-derived class.
### ONLINE COMPILER LINK:
https://godbolt.org/z/h7TnGxxv7
### SOURCE ():
struct NonTriv {
NonTriv(int);
~NonTriv();
};
struct V { V() = default; V(NonTriv); };
struct Q { Q(); };
int bar();
struct A : virtual V, Q {
using V::V;
A() : A(bar()) { }
};
struct B : A { };
void foo() { B b; }
### COMPILER INVOCATION:
g++ -O -S -o - -xc++ -std=c++20 -
### Assembly output (snippet):
_Z3foov:
.LFB6:
.cfi_startproc
subq$24, %rsp
.cfi_def_cfa_offset 32
leaq8(%rsp), %rdi
call_ZN1QC2Ev
addq$24, %rsp
.cfi_def_cfa_offset 8
ret
.cfi_endproc
### OBSERVATIONS:
The constructor for the direct base is being called; the wording mechanism for
that call comes from the inherited constructor invocation. That is, GCC does
invoke the inherited constructor; however, it does not process the argument.
Clang and ICC does process the argument (and also the initialization of the
corresponding parameter).
### COMPILER VERSION INFO (g++ -v):
Using built-in specs.
COLLECT_GCC=/opt/wandbox/gcc-head/bin/g++
COLLECT_LTO_WRAPPER=/opt/wandbox/gcc-head/libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../source/configure --prefix=/opt/wandbox/gcc-head
--enable-languages=c,c++ --disable-multilib --without-ppl --without-cloog-ppl
--enable-checking=release --disable-nls --enable-lto
LDFLAGS=-Wl,-rpath,/opt/wandbox/gcc-head/lib,-rpath,/opt/wandbox/gcc-head/lib64,-rpath,/opt/wandbox/gcc-head/lib32
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20210721 (experimental) (GCC)
[Bug c++/92060] Alias template as template template argument confused by GCC as other template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92060 --- Comment #3 from Hubert Tong --- (In reply to Patrick Palka from comment #2) > Hmm, I think treating A and Q as equivalent here is allowed by CWG 1286. Looks like it; CWG 1286 as not been adopted by the committee though.
[Bug c++/97219] New: Generic lambda does not find function declaration from enclosing block scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97219
Bug ID: 97219
Summary: Generic lambda does not find function declaration from
enclosing block scope
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: accepts-invalid, rejects-valid, wrong-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hstong at ca dot ibm.com
Target Milestone: ---
The unqualified lookup for `q` in the instantiation of the generic lambda
should resolve to the block-scope function declaration.
Such a lookup result should furthermore suppress argument dependent lookup.
GCC resolves `q` using argument dependent lookup at the point of instantiation
and chooses a worse candidate.
### SOURCE ():
struct B;
template
auto f(T *) {
void q(B *, void * = static_cast(0));
return [](auto *p) { q(p); };
}
void q(void *) = delete;
int main(void) {
B *bp = 0;
f(bp)(bp);
}
### COMPILER INVOCATION:
g++ -fsyntax-only -std=c++20 -Wall -Wextra -pedantic-errors -xc++ -
### ACTUAL OUTPUT:
: In instantiation of 'f:: [with auto:1 = B]':
:13:11: required from here
:6:25: error: use of deleted function 'void q(void*)'
:9:6: note: declared here
### EXPECTED OUTPUT:
(clean compile)
### COMPILER VERSION INFO (g++ -v):
Using built-in specs.
COLLECT_GCC=/opt/wandbox/gcc-head/bin/g++
COLLECT_LTO_WRAPPER=/opt/wandbox/gcc-head/libexec/gcc/x86_64-pc-linux-gnu/11.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../source/configure --prefix=/opt/wandbox/gcc-head
--enable-languages=c,c++ --disable-multilib --without-ppl --without-cloog-ppl
--enable-checking=release --disable-nls --enable-lto
LDFLAGS=-Wl,-rpath,/opt/wandbox/gcc-head/lib,-rpath,/opt/wandbox/gcc-head/lib64,-rpath,/opt/wandbox/gcc-head/lib32
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.0 20200925 (experimental) (GCC)
[Bug c++/97097] New: operator() call from lambda fails to resolve to enclosing class function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97097
Bug ID: 97097
Summary: operator() call from lambda fails to resolve to
enclosing class function
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hstong at ca dot ibm.com
Target Milestone: ---
In the code below, GCC does not appear to perform the applicable lookup in the
appropriate class scope to resolve the reference to the `operator()` in the
enclosing class.
It seems that, somehow, GCC resolved the `operator()` to the member of the
closure class, resulting in infinite recursion.
### SOURCE ():
extern "C" int printf(const char *, ...);
struct A {
void f();
void operator()(int) { printf("Hello, world!"); }
};
void A::f() {
const auto = [this](auto x) -> void {
operator()(x);
};
f(0);
}
int main(void) {
A a;
a.f();
}
### COMPILER INVOCATION:
g++ -std=c++14 -Wall -Wextra -pedantic-errors -o a.out -xc++ -
### ACTUAL RUN OUTPUT:
(program abend)
### EXPECTED RUN OUTPUT:
Hello, world!
### COMPILER VERSION INFO (g++ -v):
Using built-in specs.
COLLECT_GCC=/opt/wandbox/gcc-head/bin/g++
COLLECT_LTO_WRAPPER=/opt/wandbox/gcc-head/libexec/gcc/x86_64-pc-linux-gnu/11.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../source/configure --prefix=/opt/wandbox/gcc-head
--enable-languages=c,c++ --disable-multilib --without-ppl --without-cloog-ppl
--enable-checking=release --disable-nls --enable-lto
LDFLAGS=-Wl,-rpath,/opt/wandbox/gcc-head/lib,-rpath,/opt/wandbox/gcc-head/lib64,-rpath,/opt/wandbox/gcc-head/lib32
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.0 20200917 (experimental) (GCC)
[Bug c++/96959] New: GCC allows ill-formed explicit capture of requires-expression local parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96959
Bug ID: 96959
Summary: GCC allows ill-formed explicit capture of
requires-expression local parameter
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: accepts-invalid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hstong at ca dot ibm.com
Target Milestone: ---
A local parameter of a requires-expression is not a local entity (the name is
not introduced into a block scope and is, therefore, not a variable with
automatic storage duration). It is required that a simple-capture names a local
entity.
GCC appears to accept simple-captures that name local parameters of
requires-expressions.
Note: Even the IFNDR interpretation of this should not consider the concept to
be satisfied.
### SOURCE ():
template concept C0 = true;
template
concept C =
requires(T t) {
[t] { };
};
static_assert(C);
### COMPILER INVOCATION:
g++ -fsyntax-only -std=c++20 -Wall -Wextra -pedantic-errors -xc++ -
### ACTUAL OUTPUT:
(clean compile)
### EXPECTED OUTPUT:
(error diagnostic)
### COMPILER VERSION INFO (g++ -v):
Using built-in specs.
COLLECT_GCC=/opt/wandbox/gcc-head/bin/g++
COLLECT_LTO_WRAPPER=/opt/wandbox/gcc-head/libexec/gcc/x86_64-pc-linux-gnu/11.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../source/configure --prefix=/opt/wandbox/gcc-head
--enable-languages=c,c++ --disable-multilib --without-ppl --without-cloog-ppl
--enable-checking=release --disable-nls --enable-lto
LDFLAGS=-Wl,-rpath,/opt/wandbox/gcc-head/lib,-rpath,/opt/wandbox/gcc-head/lib64,-rpath,/opt/wandbox/gcc-head/lib32
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.0 20200906 (experimental) (GCC)
[Bug c++/96960] New: ICE in tsubst_copy_and_build, at cp/pt.c:20531 from lambda in return-type-requirement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96960
Bug ID: 96960
Summary: ICE in tsubst_copy_and_build, at cp/pt.c:20531 from
lambda in return-type-requirement
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hstong at ca dot ibm.com
Target Milestone: ---
The following program ICEs with GCC.
The ICE appears to related to the lambda expression in the
return-type-requirement
### SOURCE ():
template concept C0 = true;
template
concept C =
requires(T t) {
{ 42 } -> C0;
};
static_assert(C);
### COMPILER INVOCATION:
g++ -fsyntax-only -std=c++20 -xc++ -
### ACTUAL OUTPUT:
:6:23: internal compiler error: in tsubst_copy_and_build, at
cp/pt.c:20531
0x5c9d7a tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../source/gcc/cp/pt.c:20531
0x72c6bd tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../source/gcc/cp/pt.c:19873
0x72c6bd tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../source/gcc/cp/pt.c:19873
0x73e1e4 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../source/gcc/cp/pt.c:19266
0x73e1e4 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../source/gcc/cp/pt.c:18879
0x72f59b tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../source/gcc/cp/pt.c:17933
0x72f59b tsubst(tree_node*, tree_node*, int, tree_node*)
../../source/gcc/cp/pt.c:15349
0x72f1e3 tsubst(tree_node*, tree_node*, int, tree_node*)
../../source/gcc/cp/pt.c:15792
0x742ec2 tsubst_template_args(tree_node*, tree_node*, int, tree_node*)
../../source/gcc/cp/pt.c:13215
0x72c209 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../source/gcc/cp/pt.c:19333
0x73e1e4 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../source/gcc/cp/pt.c:19266
0x73e1e4 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../source/gcc/cp/pt.c:18879
0x647cf7 tsubst_constraint(tree_node*, tree_node*, int, tree_node*)
../../source/gcc/cp/constraint.cc:2402
0x647cf7 type_deducible_p
../../source/gcc/cp/constraint.cc:1932
0x64c23a tsubst_requires_expr(tree_node*, tree_node*, int, tree_node*)
../../source/gcc/cp/constraint.cc:2013
0x72c55e tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../source/gcc/cp/pt.c:20566
0x73e1e4 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../source/gcc/cp/pt.c:19266
0x73e1e4 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../source/gcc/cp/pt.c:18879
0x64ba61 satisfy_constraint_r
../../source/gcc/cp/constraint.cc:2610
0x64bee8 satisfy_constraint
../../source/gcc/cp/constraint.cc:2692
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
### EXPECTED OUTPUT:
(clean compile)
### COMPILER VERSION INFO (g++ -v):
Using built-in specs.
COLLECT_GCC=/opt/wandbox/gcc-head/bin/g++
COLLECT_LTO_WRAPPER=/opt/wandbox/gcc-head/libexec/gcc/x86_64-pc-linux-gnu/11.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../source/configure --prefix=/opt/wandbox/gcc-head
--enable-languages=c,c++ --disable-multilib --without-ppl --without-cloog-ppl
--enable-checking=release --disable-nls --enable-lto
LDFLAGS=-Wl,-rpath,/opt/wandbox/gcc-head/lib,-rpath,/opt/wandbox/gcc-head/lib64,-rpath,/opt/wandbox/gcc-head/lib32
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.0 20200906 (experimental) (GCC)
[Bug c++/96529] New: GCC applies C language linkage to instantiations from abbreviated function templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96529
Bug ID: 96529
Summary: GCC applies C language linkage to instantiations from
abbreviated function templates
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hstong at ca dot ibm.com
Target Milestone: ---
GCC appears to be treating the instantiated specialization of the abbreviated
function template `g` as if it is a function named `g` whose name has C
language linkage.
[dcl.link] does not appear to apply language linkage to the names of
specializations of function templates.
Note: Nor does [dcl.link] apply language linkage to the names of templates (as
opposed to the type that a specialization of the template would have).
Compiler Explorer link: https://godbolt.org/z/s5875s
### SOURCE ():
extern "C" {
void g(auto) {}
void g(void) { g(42); }
}
### COMPILER INVOCATION:
g++ -std=c++20 -Wall -Wextra -pedantic-errors -xc++ - -c -o /dev/null
### ACTUAL OUTPUT:
/tmp/cc2TjgyX.s: Assembler messages:
/tmp/cc2TjgyX.s:25: Error: symbol `g' is already defined
/tmp/cc2TjgyX.s: Error: .size expression for g does not evaluate to a constant
### EXPECTED OUTPUT:
(clean compile)
### COMPILER VERSION INFO (g++ -v):
Using built-in specs.
COLLECT_GCC=/opt/wandbox/gcc-head/bin/g++
COLLECT_LTO_WRAPPER=/opt/wandbox/gcc-head/libexec/gcc/x86_64-pc-linux-gnu/11.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../source/configure --prefix=/opt/wandbox/gcc-head
--enable-languages=c,c++ --disable-multilib --without-ppl --without-cloog-ppl
--enable-checking=release --disable-nls --enable-lto
LDFLAGS=-Wl,-rpath,/opt/wandbox/gcc-head/lib,-rpath,/opt/wandbox/gcc-head/lib64,-rpath,/opt/wandbox/gcc-head/lib32
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.0 20200805 (experimental) (GCC)
[Bug c++/96105] New: GCC not consistent on whether no_unique_address array is an empty data member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96105
Bug ID: 96105
Summary: GCC not consistent on whether no_unique_address array
is an empty data member
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: accepts-invalid, rejects-valid, wrong-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hstong at ca dot ibm.com
Target Milestone: ---
GCC treats an array marked `no_unique_address` and whose base element type is
an empty class as not an empty data member in `C` but does treat such an array
as an empty data member in `A` for the purposes of `B`. It appears that GCC's
handling of `B` is erroneous.
Compiler Explorer link: https://godbolt.org/z/XX5W3v
### SOURCE ():
struct Empty {};
struct A {
Empty emp [[no_unique_address]][3];
};
struct B : A {
float f;
};
struct C {
Empty emp [[no_unique_address]][3];
float f;
};
extern char szc[sizeof(C)];
extern char szc[sizeof(float) * 2]; // GCC likes this
extern char szb[sizeof(B)];
extern char szb[sizeof(float) * 2]; // GCC does not like this
### COMPILER INVOCATION:
g++ -fsyntax-only -std=c++2a -Wall -Wextra -pedantic-errors -xc++ -
### ACTUAL OUTPUT:
:19:13: error: conflicting declaration 'char szb [8]'
:18:13: note: previous declaration as 'char szb [4]'
### EXPECTED OUTPUT:
(clean compile)
### COMPILER VERSION INFO (g++ -v):
Using built-in specs.
COLLECT_GCC=/opt/wandbox/gcc-head/bin/g++
COLLECT_LTO_WRAPPER=/opt/wandbox/gcc-head/libexec/gcc/x86_64-pc-linux-gnu/11.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../source/configure --prefix=/opt/wandbox/gcc-head
--enable-languages=c,c++ --disable-multilib --without-ppl --without-cloog-ppl
--enable-checking=release --disable-nls --enable-lto
LDFLAGS=-Wl,-rpath,/opt/wandbox/gcc-head/lib,-rpath,/opt/wandbox/gcc-head/lib64,-rpath,/opt/wandbox/gcc-head/lib32
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.0 20200706 (experimental) (GCC)
[Bug c++/96052] New: Unlike Clang, alignment specifier is ignored on empty no_unique_address members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96052
Bug ID: 96052
Summary: Unlike Clang, alignment specifier is ignored on empty
no_unique_address members
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: accepts-invalid, rejects-valid, wrong-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hstong at ca dot ibm.com
Target Milestone: ---
Target: x86_64-pc-linux-gnu
The following fully standard (if not portable) C++ source fails to compile with
GCC and does compile with Clang when targeting the same platform. This is
indicative of an ABI incompatibility that is presumably unintended.
Compiler Explorer link: https://godbolt.org/z/RG_QKE
### SOURCE ():
struct Q {
struct {
} emp alignas(8) [[no_unique_address]];
char x;
};
struct QQ {
char x;
Q q;
};
struct Z {
char x alignas(8) [[no_unique_address]];
};
struct ZZ {
char x;
Z z;
};
extern char qx[sizeof(QQ)];
extern char qx[16];
extern char qz[sizeof(ZZ)];
extern char qz[16];
### COMPILER INVOCATION:
g++ -fsyntax-only -std=c++20 -Wall -Wextra -pedantic-errors -xc++ -
### ACTUAL OUTPUT:
:20:13: error: conflicting declaration 'char qx [16]'
:19:13: note: previous declaration as 'char qx [2]'
### EXPECTED OUTPUT:
(clean compile)
### COMPILER VERSION INFO (g++ -v):
Using built-in specs.
COLLECT_GCC=/opt/wandbox/gcc-head/bin/g++
COLLECT_LTO_WRAPPER=/opt/wandbox/gcc-head/libexec/gcc/x86_64-pc-linux-gnu/11.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../source/configure --prefix=/opt/wandbox/gcc-head
--enable-languages=c,c++ --disable-multilib --without-ppl --without-cloog-ppl
--enable-checking=release --disable-nls --enable-lto
LDFLAGS=-Wl,-rpath,/opt/wandbox/gcc-head/lib,-rpath,/opt/wandbox/gcc-head/lib64,-rpath,/opt/wandbox/gcc-head/lib32
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.0 20200702 (experimental) (GCC)
[Bug c++/94100] ICE: tree check: accessed elt 1 of 'tree_vec' with 0 elts in tsubst_pack_expansion, at cp/pt.c:12765
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94100
--- Comment #2 from Hubert Tong ---
The following ICEs in a similar fashion:
internal compiler error: tree check: accessed elt 2 of 'tree_vec' with 1 elts
in tsubst, at cp/pt.c:15334
### SOURCE:
template struct ValListWithTypes {
template struct WithVals {
using TypeList = ValListWithTypes;
};
};
template
struct Widget;
template
struct Widget> {
template struct Impl {};
};
template
template
struct Widget>::Impl<
typename ValListWithTypes::template WithVals> {};
int main(void) { Widget::WithVals<0>>::Impl<> impl; }
[Bug c++/96039] New: Missing diagnostic: C++11 alignment specifier on bit-fields
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96039
Bug ID: 96039
Summary: Missing diagnostic: C++11 alignment specifier on
bit-fields
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hstong at ca dot ibm.com
Target Milestone: ---
According to [dcl.align] in the 2020 DIS for C++, an alignment-specifier shall
not be applied to a bit-field. GCC allows such alignment-specifiers with no
diagnostic.
### SOURCE ():
struct A {
int x alignas(long long) : 32;
};
### COMPILER INVOCATION:
g++ -fsyntax-only -std=c++11 -Wall -Wextra -pedantic-errors -xc++ -
### ACTUAL OUTPUT:
(rc=0)
### EXPECTED OUTPUT:
Diagnostic message; likely an error.
### COMPILER VERSION INFO (g++ -v):
Using built-in specs.
COLLECT_GCC=/opt/wandbox/gcc-head/bin/g++
COLLECT_LTO_WRAPPER=/opt/wandbox/gcc-head/libexec/gcc/x86_64-pc-linux-gnu/11.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../source/configure --prefix=/opt/wandbox/gcc-head
--enable-languages=c,c++ --disable-multilib --without-ppl --without-cloog-ppl
--enable-checking=release --disable-nls --enable-lto
LDFLAGS=-Wl,-rpath,/opt/wandbox/gcc-head/lib,-rpath,/opt/wandbox/gcc-head/lib64,-rpath,/opt/wandbox/gcc-head/lib32
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.0 20200701 (experimental) (GCC)
[Bug c++/83138] ICE: Segfault expanding function parameter pack in subsequent sibling pack declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83138 Hubert Tong changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Hubert Tong --- Seems fixed in some GCC 8.x release.
[Bug c++/94066] [8/9/10 Regression] ICE (starting/ending union member lifetime) in cxx_eval_bare_aggregate, at cp/constexpr.c:3790 since r6-7592
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94066 --- Comment #7 from Hubert Tong --- (In reply to Jakub Jelinek from comment #6) > The standard seems to say a union member becomes active when the constructor > finishes, not when it starts, so what wording prevents changing the active > member during the construction? I do not believe there is such wording. Especially in the case presented, the actual construction of the `a` member can be considered to occur while `y` is the active member. The lack of such wording may well be unintentional.
[Bug c++/94066] New: ICE (starting/ending union member lifetime) in cxx_eval_bare_aggregate, at cp/constexpr.c:3790
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94066
Bug ID: 94066
Summary: ICE (starting/ending union member lifetime) in
cxx_eval_bare_aggregate, at cp/constexpr.c:3790
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hstong at ca dot ibm.com
Target Milestone: ---
The following case, which (during constant expression evaluation) starts the
lifetime of a union member while evaluating a function whose return value would
become the other union member leads to an ICE.
### SOURCE ():
struct A { long x; };
union U;
constexpr A foo(U *up);
union U {
A a = foo(this); int y;
};
constexpr A foo(U *up) {
up->y = 11;
return {42};
}
extern constexpr U u = {};
### COMPILER INVOCATION:
g++ -fsyntax-only -xc++ -std=c++2a -
### COMPILER OUTPUT:
:15:25: internal compiler error: in cxx_eval_bare_aggregate, at
cp/constexpr.c:3790
0x5bac9e cxx_eval_bare_aggregate
../../source/gcc/cp/constexpr.c:3790
0x6305d4 cxx_eval_constant_expression
../../source/gcc/cp/constexpr.c:5853
0x632610 cxx_eval_outermost_constant_expr
../../source/gcc/cp/constexpr.c:6409
0x635c14 maybe_constant_init_1
../../source/gcc/cp/constexpr.c:6866
0x78167c store_init_value(tree_node*, tree_node*, vec**, int)
../../source/gcc/cp/typeck2.c:889
0x66480d check_initializer
../../source/gcc/cp/decl.c:6820
0x67863c cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
../../source/gcc/cp/decl.c:7746
0x6fad51 cp_parser_init_declarator
../../source/gcc/cp/parser.c:20839
0x6ddc72 cp_parser_simple_declaration
../../source/gcc/cp/parser.c:13689
0x7030c2 cp_parser_declaration
../../source/gcc/cp/parser.c:13388
0x7037e4 cp_parser_translation_unit
../../source/gcc/cp/parser.c:4731
0x7037e4 c_parse_file()
../../source/gcc/cp/parser.c:43760
0x7cb39b c_common_parse_file()
../../source/gcc/c-family/c-opts.c:1186
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
### COMPILER VERSION INFO (g++ -v):
Using built-in specs.
COLLECT_GCC=/opt/wandbox/gcc-head/bin/g++
COLLECT_LTO_WRAPPER=/opt/wandbox/gcc-head/libexec/gcc/x86_64-pc-linux-gnu/10.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../source/configure --prefix=/opt/wandbox/gcc-head
--enable-languages=c,c++ --disable-multilib --without-ppl --without-cloog-ppl
--enable-checking=release --disable-nls --enable-lto
LDFLAGS=-Wl,-rpath,/opt/wandbox/gcc-head/lib,-rpath,/opt/wandbox/gcc-head/lib64,-rpath,/opt/wandbox/gcc-head/lib32
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.0.1 20200304 (experimental) (GCC)
[Bug c++/94034] New: Broken diagnostic: 'result_decl' not supported by dump_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94034
Bug ID: 94034
Summary: Broken diagnostic: 'result_decl' not supported by
dump_expr
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hstong at ca dot ibm.com
Target Milestone: ---
The following produces substitution text in an error message that is indicative
of missing format-for-message handling.
### SOURCE ():
struct A { A *ap = this; };
constexpr A foo() {
return {};
}
void g() {
constexpr A a = foo();
}
### COMPILER INVOCATION:
g++ -fsyntax-only -xc++ -
### COMPILER OUTPUT:
: In function 'void g()':
:6:23: error: 'A{(&'result_decl' not supported by dump_expr)}' is not a constant expression
### COMPILER VERSION INFO (g++ -v):
Using built-in specs.
COLLECT_GCC=/opt/wandbox/gcc-head/bin/g++
COLLECT_LTO_WRAPPER=/opt/wandbox/gcc-head/libexec/gcc/x86_64-pc-linux-gnu/10.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../source/configure --prefix=/opt/wandbox/gcc-head
--enable-languages=c,c++ --disable-multilib --without-ppl --without-cloog-ppl
--enable-checking=release --disable-nls --enable-lto
LDFLAGS=-Wl,-rpath,/opt/wandbox/gcc-head/lib,-rpath,/opt/wandbox/gcc-head/lib64,-rpath,/opt/wandbox/gcc-head/lib32
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.0.1 20200302 (experimental) (GCC)
[Bug c++/86009] [Concepts] Placeholder as argument to partial-concept-id forms extra constrained parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86009
--- Comment #2 from Hubert Tong ---
After adding "auto" for "Concept auto":
template concept C0 = true;
template concept C1 = true;
void f(C0 auto *) { }
template void f(wchar_t *);
We now get:
:5:15: error: template-id 'f' for 'void
f(wchar_t*)' does not match any template declaration
:3:6: note: candidate is: 'template
requires (C1) && (C0) void f(auto:2*)'
So, we no longer get extra parameters, just the parameters in the reverse order
of "the order of appearance".
The issue being described by this bug report is fixed, and the remaining case
is likely to be invalid anyway. The wording that allows the `C1 auto`
placeholder is likely a wording mistake in the context of C++2a.
[Bug c++/92060] New: Alias template as template template argument confused by GCC as other template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92060
Bug ID: 92060
Summary: Alias template as template template argument confused
by GCC as other template
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hstong at ca dot ibm.com
Target Milestone: ---
In the following, the alias template `Q` merely acts as a deducible template
([dcl.type.simple]) that behaves similarly to the class template `A`, it is not
the same template as `A`. GCC treats `Q` as `A` for the purposes of declaration
matching when used as a template template argument.
### SOURCE ():
template class TT> struct AA;
template struct A;
template using Q = A;
void f(AA *) { }
void f(AA *) { } // GCC claims this is a redefinition of f(AA *).
### COMPILER INVOCATION:
g++ -fsyntax-only -std=c++2a -pedantic -Wall -Wextra -xc++ -
### EXPECTED OUTPUT:
(Clean compile).
### ACTUAL OUTPUT:
:7:6: error: redefinition of 'void f(AA*)'
:6:6: note: 'void f(AA*)' previously defined here
### COMPILER VERSION INFO (g++ -v):
Using built-in specs.
COLLECT_GCC=/opt/wandbox/gcc-9.2.0/bin/g++
COLLECT_LTO_WRAPPER=/opt/wandbox/gcc-9.2.0/libexec/gcc/x86_64-pc-linux-gnu/9.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-9.2.0/configure --prefix=/opt/wandbox/gcc-9.2.0
--enable-languages=c,c++ --disable-multilib --without-ppl --without-cloog-ppl
--enable-checking=release --disable-nls
LDFLAGS=-Wl,-rpath,/opt/wandbox/gcc-9.2.0/lib,-rpath,/opt/wandbox/gcc-9.2.0/lib64,-rpath,/opt/wandbox/gcc-9.2.0/lib32
--enable-lto
Thread model: posix
gcc version 9.2.0 (GCC)
[Bug c++/92052] New: No message for adding the noreturn attribute only after the first declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92052 Bug ID: 92052 Summary: No message for adding the noreturn attribute only after the first declaration Product: gcc Version: 9.2.0 Status: UNCONFIRMED Keywords: accepts-invalid Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: hstong at ca dot ibm.com Target Milestone: --- Given the following: void f(void), f [[noreturn]](void); GCC does not produce any message (even with -std=c++11 -pedantic -Wall -Wextra) with respect to C++11 subclause 7.6.3 [dcl.attr.noreturn] paragraph 1: The first declaration of a function shall specify the `noreturn` attribute if any declaration of that function specifies the `noreturn` attribute. ### COMPILER INVOCATION COMMAND: g++ -fsyntax-only -std=c++11 -pedantic -Wall -Wextra -xc++ - ### ACTUAL OUTPUT: (No messages; rc=0). ### EXPECTED OUTPUT: (Warning or error). ### COMPILER VERSION INFO (g++ -v): Using built-in specs. COLLECT_GCC=/opt/wandbox/gcc-9.2.0/bin/g++ COLLECT_LTO_WRAPPER=/opt/wandbox/gcc-9.2.0/libexec/gcc/x86_64-pc-linux-gnu/9.2.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../gcc-9.2.0/configure --prefix=/opt/wandbox/gcc-9.2.0 --enable-languages=c,c++ --disable-multilib --without-ppl --without-cloog-ppl --enable-checking=release --disable-nls LDFLAGS=-Wl,-rpath,/opt/wandbox/gcc-9.2.0/lib,-rpath,/opt/wandbox/gcc-9.2.0/lib64,-rpath,/opt/wandbox/gcc-9.2.0/lib32 --enable-lto Thread model: posix gcc version 9.2.0 (GCC)
[Bug c++/87638] New: [C++14] lambda init-capture fails for const references still
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87638
Bug ID: 87638
Summary: [C++14] lambda init-capture fails for const references
still
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hstong at ca dot ibm.com
Target Milestone: ---
The issue reported by PR 66735 still exists. GCC would not bind const-reference
init-captures to prvalues or xvalues.
### SOURCE ():
const int &();
void g() { [ = f()] { }(); }
### COMPILER INVOCATION COMMAND:
g++ -fsyntax-only -x c++ -std=c++14 -
### ACTUAL COMPILER OUTPUT:
: In function 'void g()':
:2:20: error: cannot capture 'f()' by reference
### EXPECTED COMPILER OUTPUT:
(Clean compile).
### COMPILER VERSION INFO (g++ -v):
Using built-in specs.
COLLECT_GCC=/opt/wandbox/gcc-head/bin/g++
COLLECT_LTO_WRAPPER=/opt/wandbox/gcc-head/libexec/gcc/x86_64-pc-linux-gnu/9.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../source/configure --prefix=/opt/wandbox/gcc-head
--enable-languages=c,c++ --disable-multilib --without-ppl --without-cloog-ppl
--enable-checking=release --disable-nls --enable-lto
LDFLAGS=-Wl,-rpath,/opt/wandbox/gcc-head/lib,-rpath,/opt/wandbox/gcc-head/lib64,-rpath,/opt/wandbox/gcc-head/lib32
Thread model: posix
gcc version 9.0.0 20181016 (experimental) (GCC)
[Bug c++/87637] Unwinding does not destroy constructed subobject of brace-initialized temporary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87637 --- Comment #2 from Hubert Tong --- (In reply to Jonathan Wakely from comment #1) > Dup of PR 57510 ? Looks like this could be the same as the return statement in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57510#c9. The scope of PR 57510 looks a bit unwieldy. I can't say that the summary of PR 57510 is indicative of the issue either.
[Bug c++/87637] New: Unwinding does not destroy constructed subobject of brace-initialized temporary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87637
Bug ID: 87637
Summary: Unwinding does not destroy constructed subobject of
brace-initialized temporary
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hstong at ca dot ibm.com
Target Milestone: ---
In the following program, the initialization of the A subobject of the B
temporary associated with the brace-initializing cast expression is complete
when an exception is thrown during the further initialization of the B
temporary.
When compiled with GCC, stack unwinding for the exception fails to invoke the
destructor of the A subobject.
### SOURCE ():
extern "C" int printf(const char *, ...);
struct A {
A() { printf("%s\n", __PRETTY_FUNCTION__); }
A(const A &) = delete;
~A() { printf("%s\n", __PRETTY_FUNCTION__); }
};
struct B { A a; int q; };
int foo() { throw 0; }
int main(void) {
try {
(void) B{{}, foo()};
}
catch (...) { }
}
### COMPILER INVOCATION:
g++ -x c++ -std=c++11 -o prog -
### RUN INVOCATION:
./prog
### ACTUAL RUN OUTPUT:
A::A()
### EXPECTED RUN OUTPUT:
A::A()
A::~A()
### COMPILER VERSION INFO (g++ -v):
Using built-in specs.
COLLECT_GCC=/opt/wandbox/gcc-head/bin/g++
COLLECT_LTO_WRAPPER=/opt/wandbox/gcc-head/libexec/gcc/x86_64-pc-linux-gnu/9.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../source/configure --prefix=/opt/wandbox/gcc-head
--enable-languages=c,c++ --disable-multilib --without-ppl --without-cloog-ppl
--enable-checking=release --disable-nls --enable-lto
LDFLAGS=-Wl,-rpath,/opt/wandbox/gcc-head/lib,-rpath,/opt/wandbox/gcc-head/lib64,-rpath,/opt/wandbox/gcc-head/lib32
Thread model: posix
gcc version 9.0.0 20181016 (experimental) (GCC)
[Bug libstdc++/86880] New: Incorrect mersenne_twister_engine equality comparison between rotated states
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86880
Bug ID: 86880
Summary: Incorrect mersenne_twister_engine equality comparison
between rotated states
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: hstong at ca dot ibm.com
Target Milestone: ---
mersenne_twister_engines whose textual representation should be equal should
also compare equal.
The following program has two engines with initial states
|2 1 2
and
|3 1 2.
The engine with state |3 1 2 transitions to states
0 |1 2,
0 2 |2,
|0 2 1,
and
2 |2 1.
The textual representation of states |2 1 2 and 2 |2 1 are both specified to
be "2 1 2". That is, adjusted by rotation, the states are the same.
The engines are compared while in those states.
The comparison fails with libstdc++.
Online compiler: https://wandbox.org/permlink/RqdbiJZk6gVN0ici
Note: libstdc++ does not produce "2 1 2" as the textual representation
(as reported by PR 60441).
=== SOURCE ():
#include
#ifdef NDEBUG
#undef NDEBUG
#endif
#include
#ifdef TRACE
#include
#undef TRACE
#define TRACE( X ) do { X } while(0)
#else
#define TRACE( X ) //
#endif
int main(void) {
typedef unsigned int EngResType;
constexpr size_t word_size = 3u;
constexpr size_t state_size = 3u;
constexpr size_t shift_size = 1u;
constexpr size_t tempering_l = word_size;
using namespace std;
using EngineType = std::mersenne_twister_engine<
EngResType, word_size, state_size,
shift_size,
0u,
0x0,
0u, 0x0,
0u, 0x0,
0u, 0x0,
tempering_l,
0>;
EngineType mteA(0b010), mteB(0b011);
TRACE( cout << "Engine A: " << mteA << endl;
cout << "Engine B: " << mteB << "\n" << endl; );
for (int i = 0; i < 4; ++i) {
mteB();
TRACE( cout << "Engine B: " << mteB << endl; );
}
TRACE( cout << "\nEngine A: " << mteA << endl;
cout << "Engine B: " << mteB << endl; );
assert(mteA == mteB);
}
=== COMPILER INVOCATION:
g++ -std=c++17 -pedantic-errors -Wall -Wextra -Werror -xc++ - -o ./a.out
=== RUN SCRIPT:
./a.out
=== EXPECTED RUN OUTPUT:
(Exits with rc=0).
=== ACTUAL RUN OUTPUT:
a.out: :47: int main(): Assertion `mteA == mteB' failed.
=== COMPILER VERSION INFO:
Using built-in specs.
COLLECT_GCC=/opt/wandbox/gcc-head/bin/g++
COLLECT_LTO_WRAPPER=/opt/wandbox/gcc-head/libexec/gcc/x86_64-pc-linux-gnu/9.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../source/configure --prefix=/opt/wandbox/gcc-head
--enable-languages=c,c++ --disable-multilib --without-ppl --without-cloog-ppl
--enable-checking=release --disable-nls --enable-lto
LDFLAGS=-Wl,-rpath,/opt/wandbox/gcc-head/lib,-rpath,/opt/wandbox/gcc-head/lib64,-rpath,/opt/wandbox/gcc-head/lib32
Thread model: posix
gcc version 9.0.0 20180805 (experimental) (GCC)
[Bug c++/86009] New: [Concepts] Placeholder as argument to partial-concept-id forms extra constrained parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86009
Bug ID: 86009
Summary: [Concepts] Placeholder as argument to
partial-concept-id forms extra constrained parameters
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hstong at ca dot ibm.com
Target Milestone: ---
When a partial-concept-id is formed with a constrained-type-specifier as an
argument, extra parameters are invented by GCC.
### SOURCE ():
template concept bool C0 = true;
template concept bool C1 = true;
void f(C0 *) { }
template void f(wchar_t *);
### COMPILER INVOCATION COMMAND:
g++ -fsyntax-only -xc++ -fconcepts -
### ACTUAL OUTPUT:
:5:15: error: template-id 'f' for 'void f(wchar_t*)'
does not match any template declaration
:3:6: note: candidate is: 'template requires C1 and C0 and
C1 and C0 void f(auto:4*)'
### EXPECTED OUTPUT:
(Clean compile).
### COMPILER VERSION INFO (g++ -v):
Using built-in specs.
COLLECT_GCC=/opt/wandbox/gcc-head/bin/g++
COLLECT_LTO_WRAPPER=/opt/wandbox/gcc-head/libexec/gcc/x86_64-pc-linux-gnu/9.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../source/configure --prefix=/opt/wandbox/gcc-head
--enable-languages=c,c++ --disable-multilib --without-ppl --without-cloog-ppl
--enable-checking=release --disable-nls --enable-lto
LDFLAGS=-Wl,-rpath,/opt/wandbox/gcc-head/lib,-rpath,/opt/wandbox/gcc-head/lib64,-rpath,/opt/wandbox/gcc-head/lib32
Thread model: posix
gcc version 9.0.0 20180529 (experimental) (GCC)
[Bug c++/79751] Concept placeholder on another concept does not work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79751 Hubert Tong changed: What|Removed |Added CC||hstong at ca dot ibm.com --- Comment #1 from Hubert Tong --- N4674 subclause 10.1.8 [dcl.spec.concept] paragraph 3: [ ... ] nor shall a concept definition have associated constraints. It looks like the program should not compile.
[Bug c++/85991] New: [Concepts] Template placeholder: ICE cp_parser_lookup_name, at cp/parser.c:26223
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85991 Bug ID: 85991 Summary: [Concepts] Template placeholder: ICE cp_parser_lookup_name, at cp/parser.c:26223 Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: hstong at ca dot ibm.com Target Milestone: --- When a partial-concept-id is formed for a concept with a template prototype template parameter, GCC ICEs. ### SOURCE (): template class, int> concept bool TmplC = true; template class> struct A; void f(A> *); ### COMPILER INVOCATION COMMAND: g++ -fsyntax-only -xc++ -fconcepts - ### ACTUAL OUTPUT: :3:17: internal compiler error: in cp_parser_lookup_name, at cp/parser.c:26223 0x58ed8d cp_parser_lookup_name ../../source/gcc/cp/parser.c:26223 0x680e29 cp_parser_primary_expression ../../source/gcc/cp/parser.c:5528 0x6825f5 cp_parser_primary_expression ../../source/gcc/cp/parser.c:5637 0x6825f5 cp_parser_template_argument ../../source/gcc/cp/parser.c:16465 0x6825f5 cp_parser_template_argument_list ../../source/gcc/cp/parser.c:16274 0x6825f5 cp_parser_enclosed_template_argument_list ../../source/gcc/cp/parser.c:27695 0x682f4e cp_parser_template_id ../../source/gcc/cp/parser.c:15917 0x683498 cp_parser_class_name ../../source/gcc/cp/parser.c:22491 0x68e837 cp_parser_qualifying_entity ../../source/gcc/cp/parser.c:6564 0x68e837 cp_parser_nested_name_specifier_opt ../../source/gcc/cp/parser.c:6250 0x6901a6 cp_parser_simple_type_specifier ../../source/gcc/cp/parser.c:17283 0x68a9f3 cp_parser_type_specifier ../../source/gcc/cp/parser.c:16956 0x696b2b cp_parser_decl_specifier_seq ../../source/gcc/cp/parser.c:13718 0x6971bb cp_parser_parameter_declaration ../../source/gcc/cp/parser.c:21607 0x697aef cp_parser_parameter_declaration_list ../../source/gcc/cp/parser.c:21433 0x697e43 cp_parser_parameter_declaration_clause ../../source/gcc/cp/parser.c:21362 0x687148 cp_parser_direct_declarator ../../source/gcc/cp/parser.c:20121 0x687148 cp_parser_declarator ../../source/gcc/cp/parser.c:19993 0x694b91 cp_parser_init_declarator ../../source/gcc/cp/parser.c:19509 0x69be63 cp_parser_simple_declaration ../../source/gcc/cp/parser.c:13150 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. ### EXPECTED OUTPUT: (No ICE). ### COMPILER VERSION INFO (g++ -v): Using built-in specs. COLLECT_GCC=/opt/wandbox/gcc-head/bin/g++ COLLECT_LTO_WRAPPER=/opt/wandbox/gcc-head/libexec/gcc/x86_64-pc-linux-gnu/9.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../source/configure --prefix=/opt/wandbox/gcc-head --enable-languages=c,c++ --disable-multilib --without-ppl --without-cloog-ppl --enable-checking=release --disable-nls --enable-lto LDFLAGS=-Wl,-rpath,/opt/wandbox/gcc-head/lib,-rpath,/opt/wandbox/gcc-head/lib64,-rpath,/opt/wandbox/gcc-head/lib32 Thread model: posix gcc version 9.0.0 20180528 (experimental) (GCC)
[Bug c++/85940] New: Address of label breaks ISO C++ program despite non-GNU dialect and pedantic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85940
Bug ID: 85940
Summary: Address of label breaks ISO C++ program despite
non-GNU dialect and pedantic
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hstong at ca dot ibm.com
Target Milestone: ---
The address of label extension breaks well-formed C++ programs.
GCC confuses the logical AND operator for the extension in the source below.
MSVC works.
### SOURCE ():
bool f(bool x) {
x:
return (bool()) && x;
}
### COMPILER INVOCATION COMMAND:
g++ -fsyntax-only -xc++ -std=c++11 -pedantic -
### ACTUAL OUTPUT:
: In function 'bool f(bool)':
:3:22: warning: taking the address of a label is non-standard
[-Wpedantic]
:3:22: error: invalid cast to function type 'bool()'
### EXPECTED OUTPUT:
(Clean compile).
### COMPILER VERSION INFO (g++ -v):
Using built-in specs.
COLLECT_GCC=/opt/wandbox/gcc-head/bin/g++
COLLECT_LTO_WRAPPER=/opt/wandbox/gcc-head/libexec/gcc/x86_64-pc-linux-gnu/9.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../source/configure --prefix=/opt/wandbox/gcc-head
--enable-languages=c,c++ --disable-multilib --without-ppl --without-cloog-ppl
--enable-checking=release --disable-nls --enable-lto
LDFLAGS=-Wl,-rpath,/opt/wandbox/gcc-head/lib,-rpath,/opt/wandbox/gcc-head/lib64,-rpath,/opt/wandbox/gcc-head/lib32
Thread model: posix
gcc version 9.0.0 20180525 (experimental) (GCC)
[Bug c++/85846] New: [Concepts] Concept as value in initializer: bogus declared-as-implicit-template error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85846 Bug ID: 85846 Summary: [Concepts] Concept as value in initializer: bogus declared-as-implicit-template error Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: hstong at ca dot ibm.com Target Milestone: --- When a concept with a non-type prototype parameter is used as a variable template in a context where the most vexing parse would prefer interpretation of an ambiguous construct as naming a type, GCC produces a bogus message about creating an implicit non-function template. In the case below, either f is being declared as a function, or Foo<> cannot be considered a type (and therefore, it cannot cause formation of an implicit template through the abbreviated function template mechanism). ### SOURCE (): template concept bool Foo = true; bool f(Foo<>); ### COMPILER INVOCATION: g++ -fsyntax-only -xc++ -fconcepts - ### ACTUAL OUTPUT: :2:6: error: non-function 'f' declared as implicit template ### EXPECTED OUTPUT: (Clean compile). ### COMPILER VERSION INFO (g++ -v): Using built-in specs. COLLECT_GCC=/opt/wandbox/gcc-head/bin/g++ COLLECT_LTO_WRAPPER=/opt/wandbox/gcc-head/libexec/gcc/x86_64-pc-linux-gnu/9.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../source/configure --prefix=/opt/wandbox/gcc-head --enable-languages=c,c++ --disable-multilib --without-ppl --without-cloog-ppl --enable-checking=release --disable-nls --enable-lto LDFLAGS=-Wl,-rpath,/opt/wandbox/gcc-head/lib,-rpath,/opt/wandbox/gcc-head/lib64,-rpath,/opt/wandbox/gcc-head/lib32 Thread model: posix gcc version 9.0.0 20180518 (experimental) (GCC)
[Bug c++/85271] New: Trivial copy assignment operator overwrites members not being copied
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85271
Bug ID: 85271
Summary: Trivial copy assignment operator overwrites members
not being copied
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hstong at ca dot ibm.com
Target Milestone: ---
In the following, the operator= used by Q's defaulted copy assignment operator
for the "d" subobject is a copy assignment operator of B: that is, it does not
copy the "b0" member of "d".
The expected behaviour is observed when Q's copy assignment operator is
explicitly defaulted after its first declaration, but not if it is explicitly
defaulted on its first declaration.
### SOURCE ():
extern "C" void abort(void);
struct B0 { int b0; };
struct B {
B =(const B &) = default;
int x;
};
struct D : B0, B {
using B::operator=;
private:
D =(const D &) && = default;
};
struct Q {
Q =(const Q &) = default;
D d;
};
//Q ::operator=(const Q &) = default;
Q qa, qb;
int main(void) {
qb.d.b0 = 42;
qb = qa;
if (qb.d.b0 != 42) abort();
}
### COMPILER INVOCATION:
g++ -xc++ -std=c++2a -o inhtrivcpyassn -
### INVOCATION AND OUTPUT OF RESULTING EXECUTABLE:
> ./inhtrivcpyassn; printf '(rc=%d)\n' "$?"
Aborted ./inhtrivcpyassn
(rc=134)
### EXPECTED RUN OUTPUT:
(rc=0)
### COMPILER VERSION INFO:
Using built-in specs.
COLLECT_GCC=/opt/wandbox/gcc-head/bin/g++
COLLECT_LTO_WRAPPER=/opt/wandbox/gcc-head/libexec/gcc/x86_64-pc-linux-gnu/8.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../source/configure --prefix=/opt/wandbox/gcc-head
--enable-languages=c,c++ --disable-multilib --without-ppl --without-cloog-ppl
--enable-checking=release --disable-nls --enable-lto
LDFLAGS=-Wl,-rpath,/opt/wandbox/gcc-head/lib,-rpath,/opt/wandbox/gcc-head/lib64,-rpath,/opt/wandbox/gcc-head/lib32
Thread model: posix
gcc version 8.0.1 20180405 (experimental) (GCC)
[Bug c++/85270] New: Trivial assignment operator not considered such
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85270
Bug ID: 85270
Summary: Trivial assignment operator not considered such
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hstong at ca dot ibm.com
Target Milestone: ---
Trivial copy assignment operator not considered such
GCC stops considering a trivial copy assignment operator to be trivial when a
non-trivial copy assignment operator is added to the class. Works with Clang;
fails with GCC.
### SOURCE ():
struct Q {
Q =(const Q &) = default;
// defaulted on first declaration, not user-provided; trivial
Q =(Q &); // not a viable candidate at P1
};
static_assert(__is_trivially_assignable(Q &, const Q &), ""); // (P1)
// Assertion succeeds with Clang and ICC, but fails with GCC.
### COMPILER INVOCATION:
g++ -xc++ -std=c++2a -fsyntax-only -
### ACTUAL OUTPUT:
:8:15: error: static assertion failed
### EXPECTED OUTPUT:
(Clean compile)
### COMPILER VERSION INFO (g++ -v):
Using built-in specs.
COLLECT_GCC=/opt/wandbox/gcc-head/bin/g++
COLLECT_LTO_WRAPPER=/opt/wandbox/gcc-head/libexec/gcc/x86_64-pc-linux-gnu/8.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../source/configure --prefix=/opt/wandbox/gcc-head
--enable-languages=c,c++ --disable-multilib --without-ppl --without-cloog-ppl
--enable-checking=release --disable-nls --enable-lto
LDFLAGS=-Wl,-rpath,/opt/wandbox/gcc-head/lib,-rpath,/opt/wandbox/gcc-head/lib64,-rpath,/opt/wandbox/gcc-head/lib32
Thread model: posix
gcc version 8.0.1 20180405 (experimental) (GCC)
[Bug c++/79064] Cannot overload member function templates on type of literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79064 --- Comment #1 from Hubert Tong --- This appears to have been fixed on trunk.
[Bug c++/83371] New: Partial ordering ignores implicit object parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83371
Bug ID: 83371
Summary: Partial ordering ignores implicit object parameter
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Keywords: accepts-invalid, rejects-valid, wrong-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hstong at ca dot ibm.com
Target Milestone: ---
For the following case, given that the constrained and unconstrained parameters
are similar in their constrainedness between the two candidates (just with
different ordering), and the arguments provided match just as well, it seems
that GCC is ignoring the implicit object parameter in the partial ordering in
turn leading to broken behaviour.
### SOURCE ():
struct A {
template void operator<(T &) &; // #1
};
template bool operator<(T &, A &); // #2
bool g(A *ap) { return *ap < *ap; } // GCC picks #2;
// Clang and MSVC says ambiguous
### COMPILER INVOCATION:
g++ -S -o /dev/null -x c++ -
### ACTUAL OUTPUT:
(Clean compile)
### EXPECTED OUTPUT:
(Error message)
### COMPILER VERSION INFO (g++ -v):
Using built-in specs.
COLLECT_GCC=/opt/wandbox/gcc-head/bin/g++
COLLECT_LTO_WRAPPER=/opt/wandbox/gcc-head/libexec/gcc/x86_64-pc-linux-gnu/8.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../source/configure --prefix=/opt/wandbox/gcc-head
--enable-languages=c,c++ --disable-multilib --without-ppl --without-cloog-ppl
--enable-checking=release --disable-nls --enable-lto
LDFLAGS=-Wl,-rpath,/opt/wandbox/gcc-head/lib,-rpath,/opt/wandbox/gcc-head/lib64,-rpath,/opt/wandbox/gcc-head/lib32
Thread model: posix
gcc version 8.0.0 20171210 (experimental) (GCC)
[Bug c++/83138] New: ICE: Segfault expanding function parameter pack in subsequent sibling pack declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83138
Bug ID: 83138
Summary: ICE: Segfault expanding function parameter pack in
subsequent sibling pack declaration
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hstong at ca dot ibm.com
Target Milestone: ---
Given the self-contained source below, GCC ICEs with a segmentation fault.
This used to work with GCC 4.7.4.
### SOURCE ():
template void f(T ...args, char ...args2[][sizeof args]) { }
template void g(T) { }
void h() { g(); }
### ACTUAL OUTPUT:
g++: internal compiler error: Segmentation fault signal terminated program
cc1plus
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://gcc.gnu.org/bugs/> for instructions.
### EXPECTED OUTPUT:
Clean compile.
### COMPILER INVOCATION COMMAND:
g++ -fsyntax-only -x c++ -std=c++11 -
### COMPILER VERSION INFO (g++ -v):
Using built-in specs.
COLLECT_GCC=/opt/wandbox/gcc-head/bin/g++
COLLECT_LTO_WRAPPER=/opt/wandbox/gcc-head/libexec/gcc/x86_64-pc-linux-gnu/8.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../source/configure --prefix=/opt/wandbox/gcc-head
--enable-languages=c,c++ --disable-multilib --without-ppl --without-cloog-ppl
--enable-checking=release --disable-nls --enable-lto
LDFLAGS=-Wl,-rpath,/opt/wandbox/gcc-head/lib,-rpath,/opt/wandbox/gcc-head/lib64,-rpath,/opt/wandbox/gcc-head/lib32
Thread model: posix
gcc version 8.0.0 20171122 (experimental) (GCC)
[Bug c++/81547] New: Surrogate call function results in call to other conversion operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81547
Bug ID: 81547
Summary: Surrogate call function results in call to other
conversion operator
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Keywords: accepts-invalid, rejects-valid, wrong-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hstong at ca dot ibm.com
Target Milestone: ---
In the C++17 DIS subclause 16.3.1.1.2 [over.call.object] paragraph 3,
it is stated that the conversion function corresponding to the selected
surrogate call function is used to determine the function which is to be called
by the call syntax.
It appears that GCC instead chooses the function selected for the user-defined
conversion sequence formed for overload resolution.
### SOURCE ():
using ff = int (*)(int);
constexpr int ffimpl0(int x) { return x; }
constexpr int ffimpl1(int x) { return x + 1; }
struct A {
template constexpr operator T() const { return ffimpl0; }
constexpr operator ff() const volatile { return ffimpl1; }
};
char x[A()(42.f)];
extern char x[43]; // Clang accepts; GCC rejects
### COMPILER INVOCATION:
g++ -fsyntax-only -std=c++11 -x c++ -
### ACTUAL OUTPUT:
:11:17: error: conflicting declaration 'char x [43]'
:10:6: note: previous declaration as 'char x [42]'
### EXPECTED OUTPUT:
(clean compile)
### COMPILER VERSION INFO (g++ -v):
Using built-in specs.
COLLECT_GCC=/opt/wandbox/gcc-head/bin/g++
COLLECT_LTO_WRAPPER=/opt/wandbox/gcc-head/libexec/gcc/x86_64-pc-linux-gnu/8.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../source/configure --prefix=/opt/wandbox/gcc-head
--enable-languages=c,c++ --disable-multilib --without-ppl --without-cloog-ppl
--enable-checking=release --disable-nls --enable-lto
LDFLAGS=-Wl,-rpath,/opt/wandbox/gcc-head/lib,-rpath,/opt/wandbox/gcc-head/lib64,-rpath,/opt/wandbox/gcc-head/lib32
Thread model: posix
gcc version 8.0.0 20170724 (experimental) (GCC)
[Bug libstdc++/81200] New: regex classatomcollatingelement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81200
Bug ID: 81200
Summary: regex classatomcollatingelement
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: hstong at ca dot ibm.com
Target Milestone: ---
The source below attempts to compile "_[[.left-square-bracket.]]_" as a egrep
regex pattern.
The collating symbol, [.left-square-bracket.], is only valid if
"left-square-bracket" is a multi-character collating element in the locale.
"left-square-bracket" is most assuredly not a multi-character collating element
in the "POSIX" locale.
Note: WG 21 document N1429 advocates the behaviour exhibited by the
implementation; however, it appears from N1623 (relevant portion quoted below)
that the committee made corrections:
"that is a bunch of portable names for characters, which are not the same as
collating elements within the meaning of POSIX locales"
The implementation accepts the pattern (not expected), and the string
"_[_" matches (not expected).
grep -E seems to work as expected.
Online compiler: https://wandbox.org/permlink/VdEOUrcdcBqnbjLB
### SOURCE (llregex3.cc):
#include
int main(void) {
std::regex regex;
regex.imbue(std::locale("POSIX"));
try {
regex.assign("_[[.left-square-bracket.]]_", std::regex_constants::egrep);
printf("No error.\n");
bool b;
b = regex_match("_[_", regex);
printf("%s _[_.\n", b ? "Matched" : "Did not match");
}
catch (const std::regex_error ) {
if (e.code() == std::regex_constants::error_collate) {
printf("Got error_collate.\n");
}
else {
printf("Got other error.\n");
}
}
}
### COMPILER INVOCATION:
g++ -std=c++11 llregex3.cc -o llregex3
### PROGRAM INVOCATION AND OUTPUT:
> ./llregex3
No error.
Matched _[_.
Return: 0x00:0
### EXPECTED PROGRAM OUTPUT:
Got error_collate.
### REFERENCE BEHAVIOUR (POSIX locale; grep -E):
> ( export LANG=POSIX; locale && grep -E '_[[.left-square-bracket.]]_' )
LANG=POSIX
LANGUAGE=en_US:en
LC_CTYPE="POSIX"
LC_NUMERIC="POSIX"
LC_TIME="POSIX"
LC_COLLATE="POSIX"
LC_MONETARY="POSIX"
LC_MESSAGES="POSIX"
LC_PAPER="POSIX"
LC_NAME="POSIX"
LC_ADDRESS="POSIX"
LC_TELEPHONE="POSIX"
LC_MEASUREMENT="POSIX"
LC_IDENTIFICATION="POSIX"
LC_ALL=
grep: Invalid collation character
Return: 0x02:2
### COMPILER VERSION INFO (g++ -v):
Using built-in specs.
COLLECT_GCC=/opt/wandbox/gcc-head/bin/g++
COLLECT_LTO_WRAPPER=/opt/wandbox/gcc-head/libexec/gcc/x86_64-pc-linux-gnu/8.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../source/configure --prefix=/opt/wandbox/gcc-head
--enable-languages=c,c++ --disable-multilib --without-ppl --without-cloog-ppl
--enable-checking=release --disable-nls --enable-lto
LDFLAGS=-Wl,-rpath,/opt/wandbox/gcc-head/lib,-rpath,/opt/wandbox/gcc-head/lib64,-rpath,/opt/wandbox/gcc-head/lib32
Thread model: posix
gcc version 8.0.0 20170623 (experimental) (GCC)
### grep --version:
grep (GNU grep) 2.25
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Written by Mike Haertel and others, see
<http://git.sv.gnu.org/cgit/grep.git/tree/AUTHORS>.
[Bug c++/67969] [concepts] bug with overloaded function when using constraints
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67969 Hubert Tong changed: What|Removed |Added CC||hstong at ca dot ibm.com --- Comment #2 from Hubert Tong --- Reproduced on GCC 6.1. Works for me on GCC 6.2: https://wandbox.org/permlink/oLKUMUjPG7Gm2hLK
[Bug c++/81043] New: [concepts] partially specializing on differing constraints gives cryptic error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81043 Bug ID: 81043 Summary: [concepts] partially specializing on differing constraints gives cryptic error Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: hstong at ca dot ibm.com Target Milestone: --- Having more than one partial specialization with, ignoring constraints, the same arguments results in a cryptic error. ### SOURCE (): template concept bool C0 = sizeof(T) <= 4; template concept bool C1 = sizeof(T) > 4; template struct A; template struct A; template struct A; ### COMPILER INVOCATION: g++ -fsyntax-only -x c++ -std=gnu++1z -fconcepts - ### EXPECTED OUTPUT: (rc=0) ### ACTUAL OUTPUT: :5:24: error: 'A' does not match any declaration ### COMPILER VERSION INFO (g++ -v): Using built-in specs. COLLECT_GCC=/opt/wandbox/gcc-head/bin/g++ COLLECT_LTO_WRAPPER=/opt/wandbox/gcc-head/libexec/gcc/x86_64-pc-linux-gnu/8.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../source/configure --prefix=/opt/wandbox/gcc-head --enable-languages=c,c++ --disable-multilib --without-ppl --without-cloog-ppl --enable-checking=release --disable-nls --enable-lto LDFLAGS=-Wl,-rpath,/opt/wandbox/gcc-head/lib,-rpath,/opt/wandbox/gcc-head/lib64,-rpath,/opt/wandbox/gcc-head/lib32 Thread model: posix gcc version 8.0.0 20170608 (experimental) (GCC)
[Bug c++/81028] GCC miscompiles placement new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81028
Hubert Tong changed:
What|Removed |Added
Keywords||wrong-code
Version|7.0 |8.0
Summary|miscompiles placement new |GCC miscompiles placement
||new
--- Comment #1 from Hubert Tong ---
In the following program, the only iteration of the loop increments the int
object pointed-to by p, and then replaces said object via q using
placement-new.
GCC miscompiles at -O2, at least with x86_64-pc-linux-gnu.
Online compiler: https://wandbox.org/permlink/ByNZmtd6oB6SgG0g
### SOURCE ():
inline void* operator new(decltype(sizeof 0), void* __p) noexcept
{ return __p; }
extern "C" void abort();
typedef int A;
typedef float B;
B *qq;
void foo(A *p, A *q, long unk) {
for (long i = 0; i < unk; ++i) {
++*p;
qq = new (static_cast([i])) B(42);
}
}
void (*volatile fp)(A *, A *, long);
int main(void) {
union { A x; B f; } u = { 0 };
fp = foo;
fp(, , 1);
if (*qq != 42) abort();
}
### COMMANDS TO REPRODUCE:
g++ -O2 -o ./a.out -x c++ -std=c++11 -
./a.out
### EXPECTED OUTPUT:
(rc=0)
### ACTUAL OUTPUT:
Aborted
(rc=134)
### COMPILER VERSION INFO (g++ -v):
Using built-in specs.
COLLECT_GCC=/opt/wandbox/gcc-head/bin/g++
COLLECT_LTO_WRAPPER=/opt/wandbox/gcc-head/libexec/gcc/x86_64-pc-linux-gnu/8.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../source/configure --prefix=/opt/wandbox/gcc-head
--enable-languages=c,c++ --disable-multilib --without-ppl --without-cloog-ppl
--enable-checking=release --disable-nls --enable-lto
LDFLAGS=-Wl,-rpath,/opt/wandbox/gcc-head/lib,-rpath,/opt/wandbox/gcc-head/lib64,-rpath,/opt/wandbox/gcc-head/lib32
Thread model: posix
gcc version 8.0.0 20170607 (experimental) (GCC)
[Bug c++/81028] New: miscompiles placement new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81028 Bug ID: 81028 Summary: miscompiles placement new Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: hstong at ca dot ibm.com Target Milestone: ---
[Bug c++/80746] [concepts] ICE evaluating constraints for concepts with dependent template parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80746 Hubert Tong changed: What|Removed |Added CC||hstong at ca dot ibm.com --- Comment #3 from Hubert Tong --- The description matches the case in Bug 79759. The traceback for both start from the same line when I try a recent build.
[Bug c++/79759] New: [concepts] ICE in tsubst, at cp/pt.c:13509
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79759
Bug ID: 79759
Summary: [concepts] ICE in tsubst, at cp/pt.c:13509
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hstong at ca dot ibm.com
Target Milestone: ---
### Source ():
template
concept bool C0() { return true; }
void f(C0<0>);
### Compiler invocation:
g++ -x c++ -std=c++1y -fconcepts -c -o /dev/null -
### Compiler output:
:4:12: internal compiler error: in tsubst, at cp/pt.c:13509
0x5da2ec tsubst(tree_node*, tree_node*, int, tree_node*)
../../source/gcc/cp/pt.c:13509
0x5e4815 convert_template_argument
../../source/gcc/cp/pt.c:7636
0x5e5a6c coerce_template_parms
../../source/gcc/cp/pt.c:8125
0x6d9ee2 resolve_constraint_check
../../source/gcc/cp/constraint.cc:231
0x6d9ee2 resolve_constraint_check(tree_node*)
../../source/gcc/cp/constraint.cc:282
0x6da023 deduce_constrained_parameter(tree_node*, tree_node*&, tree_node*&)
../../source/gcc/cp/constraint.cc:331
0x61cd4e cp_parser_maybe_constrained_type_specifier
../../source/gcc/cp/parser.c:17079
0x630b5d cp_parser_maybe_partial_concept_id
../../source/gcc/cp/parser.c:17136
0x630b5d cp_parser_template_id
../../source/gcc/cp/parser.c:15495
0x630e0e cp_parser_class_name
../../source/gcc/cp/parser.c:21948
0x63b3a7 cp_parser_qualifying_entity
../../source/gcc/cp/parser.c:6285
0x63b3a7 cp_parser_nested_name_specifier_opt
../../source/gcc/cp/parser.c:5971
0x63e021 cp_parser_simple_type_specifier
../../source/gcc/cp/parser.c:16821
0x626fbd cp_parser_type_specifier
../../source/gcc/cp/parser.c:16494
0x627e7c cp_parser_decl_specifier_seq
../../source/gcc/cp/parser.c:13325
0x641e85 cp_parser_parameter_declaration
../../source/gcc/cp/parser.c:21178
0x6426c7 cp_parser_parameter_declaration_list
../../source/gcc/cp/parser.c:20994
0x642a2c cp_parser_parameter_declaration_clause
../../source/gcc/cp/parser.c:20917
0x633781 cp_parser_direct_declarator
../../source/gcc/cp/parser.c:19640
0x633781 cp_parser_declarator
../../source/gcc/cp/parser.c:19516
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
### Compiler version info (g++ -v):
Using built-in specs.
COLLECT_GCC=/opt/wandbox/gcc-head/bin/g++
COLLECT_LTO_WRAPPER=/opt/wandbox/gcc-head/libexec/gcc/x86_64-pc-linux-gnu/7.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../source/configure --prefix=/opt/wandbox/gcc-head
--enable-languages=c,c++ --disable-multilib --without-ppl --without-cloog-ppl
--enable-checking=release --disable-nls --enable-lto
LDFLAGS=-Wl,-rpath,/opt/wandbox/gcc-head/lib,-rpath,/opt/wandbox/gcc-head/lib64,-rpath,/opt/wandbox/gcc-head/lib32
Thread model: posix
gcc version 7.0.1 20170227 (experimental) (GCC)
[Bug c++/79711] New: [concepts] ICE in instantiate_decl, at cp/pt.c:22474
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79711
Bug ID: 79711
Summary: [concepts] ICE in instantiate_decl, at cp/pt.c:22474
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hstong at ca dot ibm.com
Target Milestone: ---
### Source ():
template
concept bool f() { return true; }
static_assert(()());
### Compiler invocation:
g++ -std=c++1z -fconcepts -c -o /dev/null -x c++ -
### Compiler output:
:4:24: internal compiler error: in instantiate_decl, at cp/pt.c:22474
0x5d463c instantiate_decl(tree_node*, bool, bool)
../../source/gcc/cp/pt.c:22474
0x6d05c5 cxx_eval_call_expression
../../source/gcc/cp/constexpr.c:1493
0x6d15f5 cxx_eval_constant_expression
../../source/gcc/cp/constexpr.c:3973
0x6d55c4 cxx_eval_outermost_constant_expr
../../source/gcc/cp/constexpr.c:4615
0x6d7296 maybe_constant_value(tree_node*, tree_node*)
../../source/gcc/cp/constexpr.c:4830
0x683231 finish_static_assert(tree_node*, tree_node*, unsigned int, bool)
../../source/gcc/cp/semantics.c:8806
0x6379b9 cp_parser_static_assert
../../source/gcc/cp/parser.c:13646
0x649d3e cp_parser_block_declaration
../../source/gcc/cp/parser.c:12617
0x628484 cp_parser_declaration
../../source/gcc/cp/parser.c:12518
0x64e00b cp_parser_declaration_seq_opt
../../source/gcc/cp/parser.c:12394
0x64e2f2 cp_parser_translation_unit
../../source/gcc/cp/parser.c:4366
0x64e2f2 c_parse_file()
../../source/gcc/cp/parser.c:38440
0x71c483 c_common_parse_file()
../../source/gcc/c-family/c-opts.c:1107
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
### Compiler version info (g++ -v):
Using built-in specs.
COLLECT_GCC=/opt/wandbox/gcc-head/bin/g++
COLLECT_LTO_WRAPPER=/opt/wandbox/gcc-head/libexec/gcc/x86_64-pc-linux-gnu/7.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../source/configure --prefix=/opt/wandbox/gcc-head
--enable-languages=c,c++ --disable-multilib --without-ppl --without-cloog-ppl
--enable-checking=release --disable-nls --enable-lto
LDFLAGS=-Wl,-rpath,/opt/wandbox/gcc-head/lib,-rpath,/opt/wandbox/gcc-head/lib64,-rpath,/opt/wandbox/gcc-head/lib32
Thread model: posix
gcc version 7.0.1 20170224 (experimental) (GCC)
[Bug c++/79682] New: [concepts] ambiguous overload with functionally equivalent predicate constraints compiles
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79682
Bug ID: 79682
Summary: [concepts] ambiguous overload with functionally
equivalent predicate constraints compiles
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hstong at ca dot ibm.com
Target Milestone: ---
Given the following source, the normalized constraints of the foo() returning
int contains predicate constraints:
N > 1
- and -
(N & 0x1) != 0
The normalized constraints of the foo() returning void contains:
(N & 0x1) != 0x0
The similar looking predicate constraints are not equivalent
([temp.over.link]).
The call in main() should therefore be ambiguous.
### Source ():
template
requires (N & 0x1) != 0 && (N > 1)
int foo() { return 0; }
template
requires (N & 0x1) != 0x0
void foo() { }
int main(void) {
return foo<0x03>();
}
### Compiler invocation:
g++ -std=c++1z -fconcepts -c -o /dev/null -x c++ -
### Actual output:
(Clean compile)
### Expected output:
: In function 'int main()':
:10:20: error: call of overloaded 'foo<3>()' is ambiguous
:3:5: note: candidate: int foo() [with unsigned int N = 3]
:7:6: note: candidate: void foo() [with unsigned int N = 3]
### Compiler version (g++ -v):
Using built-in specs.
COLLECT_GCC=/usr/local/gcc-head/bin/g++
COLLECT_LTO_WRAPPER=/usr/local/gcc-head/libexec/gcc/x86_64-pc-linux-gnu/7.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /home/heads/gcc/gcc-source/configure
--prefix=/usr/local/gcc-head --enable-languages=c,c++ --enable-lto
--disable-multilib --without-ppl --without-cloog-ppl --enable-checking=release
--disable-nls
Thread model: posix
gcc version 7.0.1 20170125 (experimental) (GCC)
[Bug c++/79419] New: Explicit specialization of constrained member template: ICE in set_constraints
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79419
Bug ID: 79419
Summary: Explicit specialization of constrained member
template: ICE in set_constraints
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hstong at ca dot ibm.com
Target Milestone: ---
### SOURCE ():
template
struct A {
template
requires U::happyA
static void foo();
//template
//requires U::happyB
//static void foo();
};
template <>
template
requires U::happyA
void A::foo() { }
### COMPILER INVOCATION:
g++ -std=c++1z -fconcepts -c -o /dev/null -x c++ -
### OUTPUT:
:15:18: internal compiler error: in set_constraints, at cp/pt.c:25605
0x60cae9 set_constraints(tree_node*, tree_node*)
/home/heads/gcc/gcc-source/gcc/cp/pt.c:25605
0x62ee9b determine_specialization
/home/heads/gcc/gcc-source/gcc/cp/pt.c:2376
0x62f1fa check_explicit_specialization(tree_node*, tree_node*, int, int)
/home/heads/gcc/gcc-source/gcc/cp/pt.c:2972
0x5b2544 grokfndecl
/home/heads/gcc/gcc-source/gcc/cp/decl.c:8833
0x6004ae grokdeclarator(cp_declarator const*, cp_decl_specifier_seq*,
decl_context, int, tree_node**)
/home/heads/gcc/gcc-source/gcc/cp/decl.c:12180
0x602576 start_function(cp_decl_specifier_seq*, cp_declarator const*,
tree_node*)
/home/heads/gcc/gcc-source/gcc/cp/decl.c:15096
0x688634 cp_parser_function_definition_from_specifiers_and_declarator
/home/heads/gcc/gcc-source/gcc/cp/parser.c:26071
0x688634 cp_parser_init_declarator
/home/heads/gcc/gcc-source/gcc/cp/parser.c:19152
0x667e7a cp_parser_single_declaration
/home/heads/gcc/gcc-source/gcc/cp/parser.c:26661
0x68399c cp_parser_template_declaration_after_parameters
/home/heads/gcc/gcc-source/gcc/cp/parser.c:26265
0x6836fb cp_parser_explicit_template_declaration
/home/heads/gcc/gcc-source/gcc/cp/parser.c:26500
0x6836fb cp_parser_template_declaration_after_export
/home/heads/gcc/gcc-source/gcc/cp/parser.c:26519
0x66806b cp_parser_explicit_specialization
/home/heads/gcc/gcc-source/gcc/cp/parser.c:16292
0x66837e cp_parser_declaration
/home/heads/gcc/gcc-source/gcc/cp/parser.c:12436
0x68dc7b cp_parser_declaration_seq_opt
/home/heads/gcc/gcc-source/gcc/cp/parser.c:12366
0x68df62 cp_parser_translation_unit
/home/heads/gcc/gcc-source/gcc/cp/parser.c:4369
0x68df62 c_parse_file()
/home/heads/gcc/gcc-source/gcc/cp/parser.c:38354
0x75b223 c_common_parse_file()
/home/heads/gcc/gcc-source/gcc/c-family/c-opts.c:1107
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.
### g++ -v output:
Using built-in specs.
COLLECT_GCC=/usr/local/gcc-head/bin/g++
COLLECT_LTO_WRAPPER=/usr/local/gcc-head/libexec/gcc/x86_64-pc-linux-gnu/7.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /home/heads/gcc/gcc-source/configure
--prefix=/usr/local/gcc-head --enable-languages=c,c++ --enable-lto
--disable-multilib --without-ppl --without-cloog-ppl --enable-checking=release
--disable-nls
Thread model: posix
gcc version 7.0.1 20170125 (experimental) (GCC)
[Bug c++/79064] New: Cannot overload member function templates on type of literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79064
Bug ID: 79064
Summary: Cannot overload member function templates on type of
literal
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hstong at ca dot ibm.com
Target Milestone: ---
In the case below, the signatures of the two member templates are distinct.
GCC appears to have a problem recognizing that the types of 1 and 1ll differ.
Neither Clang nor MSVC appears to have this issue.
### Source ():
struct A {
template
void f(char (*)[0u - 1 > (M - M) ? 42 : 47]);
template
void f(char (*)[0u - 1ll > (M - M) ? 42 : 47]);
};
void f(A a) {
char x[42], y[47];
a.f<0>();
a.f<0>();
}
### Compile command:
g++ -c -o a.o -x c++ -
### Actual output:
:5:8: error: 'template void A::f(char (*)[(((0 - 1) > (M
- M)) ? 42 : 47)])' cannot be overloaded
:3:8: error: with 'template void A::f(char (*)[(((0 - 1)
> (M - M)) ? 42 : 47)])'
: In function 'void f(A)':
:11:12: error: no matching function for call to 'A::f<0>(char (*)[47])'
:3:8: note: candidate: template void A::f(char (*)[(((0
- 1) > (M - M)) ? 42 : 47)])
:3:8: note: template argument deduction/substitution failed:
:11:10: note: cannot convert '& y' (type 'char (*)[47]') to type 'char
(*)[42]'
### Expected output:
(Clean compile)
### g++ -v:
Using built-in specs.
COLLECT_GCC=/usr/local/gcc-head/bin/g++
COLLECT_LTO_WRAPPER=/usr/local/gcc-head/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /home/heads/gcc/gcc-source/configure
--prefix=/usr/local/gcc-head --enable-languages=c,c++ --enable-lto
--disable-multilib --without-ppl --without-cloog-ppl --enable-checking=release
--disable-nls
Thread model: posix
gcc version 7.0.0 20161219 (experimental) (GCC)
[Bug c++/71968] Type with no linkage in signature: symbols for unique entities link together
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71968 --- Comment #2 from Hubert Tong --- (In reply to Markus Trippelsdorf from comment #1) > clang mangles differently and therefore avoids the issue: > > markus@x4 /tmp % clang++ -c b.cc && nm -C b.o > U abort > T bar() > W void foo(char (*) [2]) > V void foo(char (*) [2])::cnt Clang worked by accident; slightly different version reported: https://llvm.org/bugs/show_bug.cgi?id=28662
[Bug c++/71968] New: Type with no linkage in signature: symbols for unique entities link together
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71968
Bug ID: 71968
Summary: Type with no linkage in signature: symbols for unique
entities link together
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hstong at ca dot ibm.com
Target Milestone: ---
GCC produces symbols for entities which cannot possibly be referenced from
another translation unit in such a way that distinct entities link together.
In the following program, the templates in question are neither equivalent nor
functionally equivalent.
Online compiler: http://melpon.org/wandbox/permlink/YXAMmVBat8N2aXRe
### SOURCE (a.cc):
extern "C" void abort();
void bar();
namespace {
struct A { A(int); char sizer[1]; };
}
template void foo(char (*)[sizeof A(T(0))]) {
static unsigned cnt = 0;
if (cnt++) abort();
}
int main(void) { bar(); foo(0); }
### SOURCE (b.cc):
extern "C" void abort();
namespace {
struct A { A(int); char sizer[2]; };
}
template void foo(char (*)[sizeof A(T(0))]) {
static unsigned cnt = 0;
if (cnt++) abort();
}
void bar() { foo(0); }
### COMMANDS:
g++ -c -o a.o -std=c++11 a.cc
g++ -c -o b.o -std=c++11 b.cc
g++ -o a.out a.o b.o
./a.out
### EXPECTED OUTPUT:
rc=0
### ACTUAL OUTPUT:
(aborts)
### COMPILER VERSION INFO (g++ -v):
Using built-in specs.
COLLECT_GCC=/usr/local/gcc-head/bin/g++
COLLECT_LTO_WRAPPER=/usr/local/gcc-head/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /home/heads/gcc/gcc-source/configure
--prefix=/usr/local/gcc-head --enable-languages=c,c++ --enable-lto
--disable-multilib --without-ppl --without-cloog-ppl --enable-checking=release
--disable-nls
Thread model: posix
gcc version 7.0.0 20160721 (experimental) (GCC)
[Bug c++/53931] [C++11] braced function style cast to reference should be prvalue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53931 --- Comment #2 from Hubert Tong --- Needs a resolution for CWG 1521.
[Bug c++/51817] [C++11] argument deduction fails when A-type parameter-type-list has additional parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51817 Hubert Tong changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #3 from Hubert Tong --- (In reply to Martin Sebor from comment #2) > As I understand the complaint it is about rejecting what's thought to be > valid code, so the Keywords should be "rejects-valid" (not "accepts-invalid" > or "wrong-code"). Overload resolution is involved, all three tags would apply (depending on the set of candidates). > > I also note that the most recent versions of Clang and the EDG front end > both reject the example. (I haven't re-read the referenced paper or checked > the latest standard to say if the code really is valid.) Based on the notes from CWG 1763, I am cancelling this.
[Bug libstdc++/67990] New: compare() does not sort null characters in locale collation order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67990
Bug ID: 67990
Summary: compare() does not sort null characters in locale
collation order
Product: gcc
Version: 4.8.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: hstong at ca dot ibm.com
Target Milestone: ---
Created attachment 36527
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36527=edit
Script to create REVNUL locale
collate::compare() does not respect the collation order when given a locale
definition where NULL is not sorted before all other characters.
A script (suitable for Linux systems) to produce a "REVNUL" locale into the
current working directory is attached.
REVNUL collates by ASCII value ordering except that NULL is placed after DELETE
and the uppercase letters are transposed with the lowercase ones.
### SOURCE:> cat nulsort.cc
#include
#include
std::locale revnul("REVNUL");
const std::collate = std::use_facet<std::collate >(revnul);
int colcmp(const char c, const char d) {
return col.compare(, + 1, , + 1);
}
int main(void) {
const char sorted[] = { 'a', 'b', 'A', 'B', '\0' };
assert(colcmp(sorted[0], sorted[1]) < 0);
assert(colcmp(sorted[1], sorted[2]) < 0);
assert(colcmp(sorted[2], sorted[3]) < 0);
assert(colcmp(sorted[3], sorted[4]) < 0);
}
Return: 0x00:0
### COMPILER INVOCATION:> g++ nulsort.cc
Return: 0x00:0
### ACTUAL OUTPUT:> LOCPATH="$PWD" ./a.out
a.out: nulsort.cc:16: int main(): Assertion `colcmp(sorted[3], sorted[4]) < 0'
failed.
Aborted (core dumped)
Return: 0x86:134
### EXPECTED OUTPUT:
No assertion failure
### COMPILER VERSION INFO:> g++ --version
g++ (GCC) 4.8.3 20140911 (Red Hat 4.8.3-9)
Copyright (C) 2013 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.
Return: 0x00:0
[Bug c++/66659] New: Accepts invalid when undeduced context encountered deducing from a trailing parameter pack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66659
Bug ID: 66659
Summary: Accepts invalid when undeduced context encountered
deducing from a trailing parameter pack
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hstong at ca dot ibm.com
Target Milestone: ---
In the call to f from h below, the deduction for T@0 should find both
fptype and Func and fail.
### SOURCE (stdin):
template typename ...T struct A;
void g();
void g(bool);
typedef void (*fptype)();
struct Func { operator fptype(); } func;
templatetypename ...T void f(AT ... *ap, T ...b);
void h(Afptype, fptype *ap) { f(ap, func, g); }
### COMPILER INVOCATION:
g++ -std=c++11 -c -x c++ -
### ACTUAL OUTPUT:
(Clean compile).
### EXPECTED OUTPUT:
(Error message).
### COMPILER VERSION INFO:
Using built-in specs.
COLLECT_GCC=/usr/local/gcc-head/bin/g++
COLLECT_LTO_WRAPPER=/usr/local/gcc-head/libexec/gcc/x86_64-unknown-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /home/heads/gcc/gcc-source/configure
--prefix=/usr/local/gcc-head --enable-languages=c,c++ --enable-lto
--disable-multilib --without-ppl --without-cloog-ppl --enable-checking=release
--disable-nls
Thread model: posix
gcc version 6.0.0 20150623 (experimental) (GCC)
[Bug c++/65055] New: Types and variables differ in handling of multiple instances of attribute aligned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65055
Bug ID: 65055
Summary: Types and variables differ in handling of multiple
instances of attribute aligned
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hstong at ca dot ibm.com
When multiple instances of the aligned attribute are applied to the same
entity, the handling for types uses the last value whereas the handling for
variables uses the most restrictive value.
Clang uses the most restrictive value (which seems to make sense) for both
cases.
### SOURCE (stdin):
struct __attribute__ ((aligned(32), aligned(16) )) A
{
} __attribute__ ((aligned(32), aligned(16) ));
extern int x __attribute__ ((aligned(32), aligned(16) ));
extern int chk[32];
extern int chk[__alignof__(x)];
extern int chk[__alignof__(struct A)];
### COMPILER INVOCATION:
gcc -c -xc++ -
### ACTUAL OUTPUT:
stdin:9:37: error: conflicting declaration 'int chk [16]'
stdin:8:12: note: previous declaration as 'int chk [32]'
### EXPECTED OUTPUT:
(Clean compile)
### COMPILER VERSION INFO:
Using built-in specs.
COLLECT_GCC=/usr/local/gcc-head/bin/gcc
COLLECT_LTO_WRAPPER=/usr/local/gcc-head/libexec/gcc/x86_64-unknown-linux-gnu/5.0.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /home/heads/gcc/gcc-source/configure
--prefix=/usr/local/gcc-head --enable-languages=c,c++ --enable-lto
--disable-multilib --without-ppl --without-cloog-ppl --enable-checking=release
--disable-nls
Thread model: posix
gcc version 5.0.0 20150212 (experimental) (GCC)
[Bug c++/64696] New: [C++14] braced-init-list does not cause expected aggregate initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64696
Bug ID: 64696
Summary: [C++14] braced-init-list does not cause expected
aggregate initialization
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hstong at ca dot ibm.com
In the test case below, C++14 specifies that aggregate initialization is
performed in subclause 8.5.4 [dcl.init.list] paragraph 3 for the braced-init-
list containing DESIGNATOR in the source.
Said aggregate initialization should leave the x member of the temporary with
a value of 2.
GCC does not appear to understand this to be the case since the static_assert
should evaluate to false but no diagnostic appears.
If the resolution of Core Issue 1467 is taken into account, then the case with
of -std=gnu++1y -DDESIGNATED still behaves similarly. This result is rather
surprising since the natural interpretation of that designated initializer is
that it applies directly to the a member.
### SOURCE (stdin):
struct A {
const A a; int x = 2;
};
extern A a0;
#if DESIGNATED
# define DESIGNATOR .a =
#else
# define DESIGNATOR
#endif
constexpr int x = A{ DESIGNATOR A{ a0, 4 } }.x;
static_assert(x != 2, Expected diagnostic);
int main() { }
### COMPILER INVOCATION:
g++ -Wall -Wextra -pedantic -std=c++1y -x c++ -
### COMPILER OUTPUT:
No text; RC=0
### EXPECTED OUTPUT:
stdin:14:1: error: static assertion failed: Expected diagnostic
### VERSION INFO:
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/local/gcc-head/libexec/gcc/x86_64-unknown-linux-gnu/5.0.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /home/heads/gcc/gcc-source/configure
--prefix=/usr/local/gcc-head --enable-languages=c,c++ --enable-lto
--disable-multilib --without-ppl --without-cloog-ppl --enable-checking=release
--disable-nls
Thread model: posix
gcc version 5.0.0 20150120 (experimental) (GCC)
[Bug c++/62163] New: Dependent function call in constant expression produces error in template definition context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62163
Bug ID: 62163
Summary: Dependent function call in constant expression
produces error in template definition context
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hstong at ca dot ibm.com
GCC does not wait until a (dependent) function call is substituted with
arguments before reporting a hard error in the case below.
It appears that GCC tries to evaluate the constant expression with the lookup
results from the template definition context.
### SOURCE (gccSfinaeDependentConstexpr.cc):
unsigned foo(int);
template unsigned N struct Q;
template typename T void bar(T, Qfoo(T()) * = 0);
void bar(void *) { }
namespace M {
struct Z;
constexpr unsigned foo(Z *) { return 0; }
}
int main() {
M::Z *p = 0;
bar(p);
}
### COMPILER OPTIONS:
-std=c++11
### COMPILER OUTPUT:
gccSfinaeDependentConstexpr.cc:5:44: error: call to non-constexpr function
'unsigned int foo(int)'
template typename T void bar(T, Qfoo(T()) * = 0);
^
### COMPILER VERSION INFO:
Using built-in specs.
COLLECT_GCC=/opt/gcc-4.9.0/bin/g++
Target: x86_64-unknown-linux-gnu
Configured with: ./configure --prefix=/home/matthew/gcc-4.9.0-prefix
Thread model: posix
gcc version 4.9.0 (GCC)
[Bug c++/61163] New: Placement arguments shared between allocation and deallocation even when copies prohibited
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61163
Bug ID: 61163
Summary: Placement arguments shared between allocation and
deallocation even when copies prohibited
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hstong at ca dot ibm.com
In N3290 subclause 5.3.4 [expr.new] paragraph 21, the leeway to reuse the same
copy of the initialized parameter for both the call to the allocation function
and the call to the deallocation function is prefaced with [i]f the
implementation is allowed to make a copy.
Since, in the case below, list initialization does not involve copying
following the call to the converting constructor, there is no copying to speak
of and the leeway is not given.
GCC performs the reuse anyway.
### SOURCE: cat gccListInitNewPlacement.cc
extern C int printf(const char *, ...);
struct A {
A(const A ) = delete;
A(A ) = delete;
A(int) : x(0) { printf(%s\n, __PRETTY_FUNCTION__); }
~A() { printf(%s\n, __PRETTY_FUNCTION__); }
int x;
};
struct B {
static void *operator new(decltype(sizeof(0)) sz, A a) {
printf(%d %s\n, a.x++, __PRETTY_FUNCTION__);
return ::operator new(sz);
}
static void operator delete(void *ptr, A a) {
printf(%d %s\n, a.x++, __PRETTY_FUNCTION__);
return ::operator delete(ptr);
}
B() { throw 0; }
};
int main() {
try { new ({0}) B; } catch(...) { }
}
### COMPILER INVOCATION: g++ -std=c++11 -pedantic-errors -Wall -Wextra
gccListInitNewPlacement.cc -o gccListInitNewPlacement
### OUTPUT FROM RESULTING BINARY: ./gccListInitNewPlacement
A::A(int)
0 static void* B::operator new(long unsigned int, A)
1 static void B::operator delete(void*, A)
A::~A()
### EXPECTED OUTPUT:
A::A(int)
0 static void* B::operator new(long unsigned int, A)
A::A(int)
0 static void B::operator delete(void*, A)
A::~A()
A::~A()
### VERSION INFO: g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-cygwin/4.8.2/lto-wrapper.exe
Target: x86_64-pc-cygwin
Configured with:
/cygdrive/i/szsz/tmpp/cygwin64/gcc/gcc-4.8.2-3/src/gcc-4.8.2/configure
--srcdir=/cygdrive/i/szsz/tmpp/cygwin64/gcc/gcc-4.8.2-3/src/gcc-4.8.2
--prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin
--libexecdir=/usr/libexec --datadir=/usr/share --localstatedir=/var
--sysconfdir=/etc --libdir=/usr/lib --datarootdir=/usr/share
--docdir=/usr/share/doc/gcc --htmldir=/usr/share/doc/gcc/html -C
--build=x86_64-pc-cygwin --host=x86_64-pc-cygwin --target=x86_64-pc-cygwin
--without-libiconv-prefix --without-libintl-prefix --enable-shared
--enable-shared-libgcc --enable-static --enable-version-specific-runtime-libs
--enable-bootstrap --disable-__cxa_atexit --with-dwarf2 --with-tune=generic
--enable-languages=ada,c,c++,fortran,lto,objc,obj-c++ --enable-graphite
--enable-threads=posix --enable-libatomic --enable-libgomp --disable-libitm
--enable-libquadmath --enable-libquadmath-support --enable-libssp
--enable-libada --enable-libgcj-sublibs --disable-java-awt --disable-symvers
--with-ecj-jar=/usr/share/java/ecj.jar --with-gnu-ld --with-gnu-as
--with-cloog-include=/usr/include/cloog-isl --without-libiconv-prefix
--without-libintl-prefix --with-system-zlib --libexecdir=/usr/lib
Thread model: posix
gcc version 4.8.2 (GCC)
[Bug libstdc++/61041] New: Cannot create std::tr1::variate_generator from variate_generator::engine(); engine_value_type error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61041
Bug ID: 61041
Summary: Cannot create std::tr1::variate_generator from
variate_generator::engine(); engine_value_type error
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: hstong at ca dot ibm.com
http://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html#status.iso.tr1 shows
that support for ISO/IEC DTR 19768 subclause 5.1.3 is available in libstdc++.
It seems that engine_value_type in libstdc++ is not defined such that it
matches 5.1.3 paragraph 2 (assuming the DTR is close enough to the TR):
The template argument for the parameter Engine shall be of the form U, U, or
U*, where U denotes a class that satisfies all the requirements of a uniform
random number generator. The member engine_value_type shall name U.
The following small client for tr1/random generates error messages showing
that the engine_value_type typedef is some specialization of
std::tr1::__detail::_Adaptor and not the corresponding U for U =
::EngineType.
### SOURCE: cat engine_value_type.cc
#include tr1/random
typedef std::tr1::linear_congruentialunsigned, 1, 0, 2048 EngineType;
typedef std::tr1::uniform_intunsigned DistType;
std::tr1::variate_generatorEngineType, DistType
getWithNewDist(std::tr1::variate_generatorEngineType, DistType orig,
const DistType newDist) {
return std::tr1::variate_generatorEngineType, DistType(orig.engine(),
newDist);
}
### COMPILER INVOCATION AND OUTPUT: g++ engine_value_type.cc
engine_value_type.cc: In function
‘std::tr1::variate_generatorstd::tr1::linear_congruentialunsigned int, 1u,
0u, 2048u, std::tr1::uniform_intunsigned int
getWithNewDist(std::tr1::variate_generatorstd::tr1::linear_congruentialunsigned
int, 1u, 0u, 2048u, std::tr1::uniform_intunsigned int , const
DistType)’:
engine_value_type.cc:8:83: error: no matching function for call to
‘std::tr1::variate_generatorstd::tr1::linear_congruentialunsigned int, 1u,
0u, 2048u, std::tr1::uniform_intunsigned int
::variate_generator(std::tr1::variate_generatorstd::tr1::linear_congruentialunsigned
int, 1u, 0u, 2048u, std::tr1::uniform_intunsigned int
::engine_value_type, const DistType)’
return std::tr1::variate_generatorEngineType, DistType(orig.engine(),
newDist);
^
engine_value_type.cc:8:83: note: candidates are:
In file included from
/usr/lib/gcc/x86_64-pc-cygwin/4.8.2/include/c++/tr1/random:47:0,
from engine_value_type.cc:1:
/usr/lib/gcc/x86_64-pc-cygwin/4.8.2/include/c++/tr1/random.h:252:7: note:
std::tr1::variate_generator_Engine,
_Dist::variate_generator(std::tr1::variate_generator_Engine,
_Dist::engine_type, std::tr1::variate_generator_Engine,
_Dist::distribution_type) [with _Engine =
std::tr1::linear_congruentialunsigned int, 1u, 0u, 2048u; _Dist =
std::tr1::uniform_intunsigned int; std::tr1::variate_generator_Engine,
_Dist::engine_type = std::tr1::linear_congruentialunsigned int, 1u, 0u,
2048u; std::tr1::variate_generator_Engine, _Dist::distribution_type =
std::tr1::uniform_intunsigned int]
variate_generator(engine_type __eng, distribution_type __dist)
^
/usr/lib/gcc/x86_64-pc-cygwin/4.8.2/include/c++/tr1/random.h:252:7: note: no
known conversion for argument 1 from
‘std::tr1::variate_generatorstd::tr1::linear_congruentialunsigned int, 1u,
0u, 2048u, std::tr1::uniform_intunsigned int ::engine_value_type {aka
std::tr1::__detail::_Adaptorstd::tr1::linear_congruentialunsigned int, 1u,
0u, 2048u, std::tr1::uniform_intunsigned int }’ to
‘std::tr1::variate_generatorstd::tr1::linear_congruentialunsigned int, 1u,
0u, 2048u, std::tr1::uniform_intunsigned int ::engine_type {aka
std::tr1::linear_congruentialunsigned int, 1u, 0u, 2048u}’
/usr/lib/gcc/x86_64-pc-cygwin/4.8.2/include/c++/tr1/random.h:228:11: note:
std::tr1::variate_generatorstd::tr1::linear_congruentialunsigned int, 1u, 0u,
2048u, std::tr1::uniform_intunsigned int ::variate_generator(const
std::tr1::variate_generatorstd::tr1::linear_congruentialunsigned int, 1u, 0u,
2048u, std::tr1::uniform_intunsigned int )
class variate_generator
^
/usr/lib/gcc/x86_64-pc-cygwin/4.8.2/include/c++/tr1/random.h:228:11: note:
candidate expects 1 argument, 2 provided
### VERSION INFO: g++ --version
g++ (GCC) 4.8.2
Copyright (C) 2013 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.
[Bug libstdc++/60958] Initialization of arrays in tr1/regex ill-formed or with undefined behaviour
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60958 --- Comment #2 from Hubert Tong hstong at ca dot ibm.com --- (In reply to Jonathan Wakely from comment #1) Yes, I have a patch for this somewhere, but why are you including tr1/regex anyway? It's completely useless and doesn't work. I am trying to use a code base which used a TR1 regex implementation on another platform. Your comment led me to find http://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html#status.iso.tr1, which does indicate that tr1/regex does not work. Is the recommendation (short of switching over to C++11) to use the Boost implementation? Is the TR1 implementation status of regex in libstdc++ likely to change in the future?
[Bug libstdc++/60958] New: Initialization of arrays in tr1/regex ill-formed or with undefined behaviour
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60958 Bug ID: 60958 Summary: Initialization of arrays in tr1/regex ill-formed or with undefined behaviour Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: hstong at ca dot ibm.com The header tr1/regex contains code which is either ill-formed or has undefined behaviour. Various C++ language tools choke on this file because of the code in question. In particular, C++03 subclause 8.5 [dcl.init] does not specify the semantics of the array initializations in question and they are ill-formed under C++11. /usr/lib/gcc/x86_64-pc-cygwin/4.8.2/include/c++/tr1/regex:685:22: error: array initializer must be an initializer list const char* const __wb[] = w; ^ /usr/lib/gcc/x86_64-pc-cygwin/4.8.2/include/c++/tr1/regex:695:22: error: array initializer must be an initializer list const char* const __bb[] = blank; ^ VERSION INFO: $ g++ --version g++ (GCC) 4.8.2 Copyright (C) 2013 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.
[Bug c++/59795] New: Invalid use of this in a local class not diagnosed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59795
Bug ID: 59795
Summary: Invalid use of this in a local class not diagnosed
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hstong at ca dot ibm.com
The following is reduced from the example in N3290 subclause 5.1.1
[expr.prim.general] paragraph 5:
class Outer {
void f() {
struct Inner {
int c[sizeof(*this)]; // error: not inside a member function of Inner
};
}
};
GCC does not provide a diagnostic for this although, the declaration in
question runs afoul of the constraint in paragraph 4 for the subclause by using
this elsewhere in the member-declarator.
## Compile command:
g++-4.8 -std=c++11 nestedClassThisNonStaticDataMemDiag.cc
## Actual output:
(No diagnostics; clean compile).
## Expected output:
(Error message).
## g++ -v:
Using built-in specs.
COLLECT_GCC=/usr/bin/g++-4.8
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
4.8.1-2ubuntu1~12.04' --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.8 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin
--with-system-zlib --disable-browser-plugin --enable-java-awt=gtk
--enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64/jre
--enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64 --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.8.1 (Ubuntu 4.8.1-2ubuntu1~12.04)
[Bug c++/58337] Mangling of nullptr_t values do not follow ABI
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58337 Hubert Tong hstong at ca dot ibm.com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Hubert Tong hstong at ca dot ibm.com --- There are indications that the ABI will be updated to clarify this case. A resolved template argument value will use LDn0E while a nullptr literal in other contexts will use LDnE.
[Bug c++/58337] New: Mangling of nullptr_t values do not follow ABI
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58337
Bug ID: 58337
Summary: Mangling of nullptr_t values do not follow ABI
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hstong at ca dot ibm.com
The C++ ABI document (available at
http://mentorembedded.github.io/cxx-abi/abi.html#mangle.expr-primary) specifies
a mangling for the nullptr literal.
The mangling that GCC produces is not consistent with the form specified by the
ABI; namely, LDn0E is generated by GCC instead of LDnE.
ICC mangles using the ABI-specified form: LDnE.
Note that nullptr_t is not an integer type. It is contrary to the specification
to apply the production for integer literals to a literal of type nullptr_t.
### SMALL SOURCE (main.cpp):
typedef decltype(nullptr) NullPtrType;
template NullPtrType void foo();
template void foonullptr() { }
### ACTUAL MANGLED NAME:
g++-4.8 -std=c++11 -c main.cpp -o main.o nm main.o
T _Z3fooILDn0EEvv
### EXPECTED MANGLED NAME:
_Z3fooILDnEEvv
### g++ -v:
g++-4.8 -v
Using built-in specs.
COLLECT_GCC=g++-4.8
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
4.8.1-2ubuntu1~12.04' --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.8 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin
--with-system-zlib --disable-browser-plugin --enable-java-awt=gtk
--enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64/jre
--enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64 --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.8.1 (Ubuntu 4.8.1-2ubuntu1~12.04)
[Bug c++/57610] Reference initialized with temporary instead of sub-object of conversion result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57610
Hubert Tong hstong at ca dot ibm.com changed:
What|Removed |Added
CC||hstong at ca dot ibm.com
--- Comment #8 from Hubert Tong hstong at ca dot ibm.com ---
Affects the candidate list for direct binding to a result of a conversion.
struct Z { };
struct A {
operator Z () const = delete; // GCC like this
operator Z();
};
void zip() {
Z x = A();
}
[Bug c++/57610] Reference initialized with temporary instead of sub-object of conversion result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57610 --- Comment #9 from Hubert Tong hstong at ca dot ibm.com --- CWG 1604 may address the issues with performance and slicing mentioned in CWG 1287 which led to CWG 1650.
[Bug c++/58052] Copy initialization using conversion operator does not find correct candidates for initialization of final result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58052
--- Comment #2 from Hubert Tong hstong at ca dot ibm.com ---
(In reply to Paolo Carlini from comment #1)
Not having spent a lot of time on this, I doubt it's a bug: the latest clang
and icc behave exactly like gcc.
I had a vague recollection why I found the code weird to begin with.
After consideration, I found that the MSVC behaviour made sense after all.
There is wording in 12.3 [class.conv]:
At most one user-defined conversion (constructor or conversion function) is
implicitly applied to a single value.
To poke some holes in the applicability of the above wording, I will modify the
test case:
@@ -3,7 +3,8 @@ struct A {
A();
A(const A , bool = 0);
A(const A , short = 0);
- A(B );
+
+ template typename T explicit A(T );
};
struct B : A { };
Note that explicit constructors are not converting constructors.
The modified version of the test case works fine with clang++ and icc, but not
GCC. MSVC chokes on the explicit.
[Bug c++/58062] New: [C++11] bogus __func__ lookup in lambda body
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58062
Bug ID: 58062
Summary: [C++11] bogus __func__ lookup in lambda body
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hstong at ca dot ibm.com
In the case below, the __func__ identifier appears within a lambda body at
namespace scope.
GCC seems to find __func__ from somewhere, but the behaviour does not appear to
be supported by the Standard. MSVC gives the expected error.
When we are told by C++11 subclause 5.1.2 [expr.prim.lambda] paragraph 7 that
the compound-statement yields the function-body of the function call
operator, it can be taken that it means that a function-body is produced from
the compound-statement and that the latter is not an actual function-body. We
are also told that for the purposes of name lookup, the compound-statement is
considered in the context of the lambda-expression.
We find that, in the absence of a function-body, __func__ is not a specified to
be a predefined variable (8.4.1 [dcl.fct.def.general] paragraphs 7-8). We also
note that the form of a function definition (8.4.1 paragraph 1) is not present
in the above program and that the wording in subclauses 3.3.2
[basic.scope.pdecl] and 3.3.3 [basic.scope.block] (paragraphs 8 and 2,
respectively) covers only function-local predefined variables in function
definitions.
The conclusion is that __func__ in a lambda body is bound using the context of
the lambda-expression, and not bound later to be the function-local predefined
variable which would exist in the context of the function-call operator's
compiler-generated definition.
In the case of the code below, it means that the lookup for __func__ fails and
renders the program ill-formed.
## Small test:
namespace K {
auto ff = [] { return __func__; };
}
## Actual output:
Clean compile.
## Expected output:
main.cpp: In lambda function:
main.cpp:2:26: error: ‘__func__’ was not declared in this scope
auto ff = [] { return __func__; };
^
## g++ -v:
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
4.8.1-2ubuntu1~12.04' --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.8 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin
--with-system-zlib --disable-browser-plugin --enable-java-awt=gtk
--enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64/jre
--enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64 --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.8.1 (Ubuntu 4.8.1-2ubuntu1~12.04)
[Bug c++/58062] [C++11] bogus __func__ lookup in lambda body
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58062 --- Comment #1 from Hubert Tong hstong at ca dot ibm.com --- Compiler invocation was: g++ -std='c++11' main.cpp -Wall -Wextra -pedantic -c
[Bug c++/58052] New: Copy initialization using conversion operator does not find correct candidates for initialization of final result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58052
Bug ID: 58052
Summary: Copy initialization using conversion operator does not
find correct candidates for initialization of final
result
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hstong at ca dot ibm.com
I have a reduced test case.
MSVC seems to work fine (online compiler test: http://rise4fun.com/Vcpp/2sQ).
The copy initialization of an object of type A from a class object of type
C is expected to find C::operator B () as the function selected by overload
resolution.
The result of the call, an lvalue of type B, is then used to direct-initialize
the object that is the destination of the copy-initialization.
See C++11 subclause 8.5 [dcl.init] paragraph 16.
Note that the result of the call is specified to be used, not the result of the
user-defined conversion sequence which was considered for overload resolution.
The direct initialization from the lvalue of type B has for its candidates all
of the constructors for A (13.3.1.3 [over.match.ctor]).
Note that A(B ) has a standard conversion sequence from the lvalue of type B
to
its sole argument (the identity conversion).
GCC seems to be fixated with the copy constructors for A instead of performing
the overload resolution for the direct initialization.
## Self-contained test case (main.cpp):
struct B;
struct A {
A();
A(const A , bool = 0);
A(const A , short = 0);
A(B );
};
struct B : A { };
struct C {
operator B ();
};
int main() {
C c;
A a = c;
}
## Compiler invocation:
g++ -std=c++11 -c main.cpp
## Compiler output:
main.cpp: In function 'int main()':
main.cpp:17:10: error: call of overloaded 'A(A)' is ambiguous
A a = c;
^
main.cpp:17:10: note: candidates are:
main.cpp:5:4: note: A::A(const A, short int)
A(const A , short = 0);
^
main.cpp:4:4: note: A::A(const A, bool)
A(const A , bool = 0);
^
## Expected behaviour:
Clean compile.
## g++ -v:
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
4.8.1-2ubuntu1~12.04' --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.8 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin
--with-system-zlib --disable-browser-plugin --enable-java-awt=gtk
--enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64/jre
--enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64 --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.8.1 (Ubuntu 4.8.1-2ubuntu1~12.04)
[Bug c++/57570] New: Deduction succeeds despite type mismatch of non-type template parameter and deduced argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57570
Bug ID: 57570
Summary: Deduction succeeds despite type mismatch of non-type
template parameter and deduced argument
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hstong at ca dot ibm.com
GCC does not consistently fail deduction for type mismatch of a non-type
template parameter and the corresponding deduced argument.
See N3690 subclause 14.8.2.5 [temp.deduct.type] paragraph 17.
### STANDALONE SOURCE:
template short, char struct A;
int foo(void *);
template short x int foo(Ax, x *ap)
// neither clang++ nor g++ bother to look at the second instance of x
// for deduction
{ return noGood(ap); }
int bar(void *);
template char y int bar(Ay, y *ap)
// okay; clang++ and g++ both realize that deducing from the first instance
// of y is no good
{ return noGood(ap); }
int zip(void *, void *);
template short x, char y int zip(Ax, y *ap, Ay, x *)
// clang++ does not bother to look at the second function argument
// for deduction, g++ does
{ return noGood(ap); }
A0, 0 *ap = 0;
int a = foo(ap); // clang++ and g++ both fail to fail the argument deduction
int b = bar(ap); // clang++ and g++ both successfully fail the deduction
int c = zip(ap, ap); //
// clang++ fails to fail and g++ successfully fails the argument deduction
// For all three:
// - MSVC 17.00.51025 fails to fail the argument deduction
// - ICC 13.0.1 20121010 and IBM XL C/C++ for AIX 12.1.0.3 work fine
### COMPILER INVOCATION:
g++ -std=c++11 -c main.cpp
### EXPECTED OUTPUT:
Successful compile.
### ACTUAL OUTPUT:
main.cpp: In instantiation of 'int foo(Ax, x*) [with short int x = 0]':
main.cpp:23:15: required from here
main.cpp:7:12: error: 'noGood' was not declared in this scope
### g++ -v OUTPUT:
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
4.8.1-2ubuntu1~12.04' --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.8 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin
--with-system-zlib --disable-browser-plugin --enable-java-awt=gtk
--enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64/jre
--enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64 --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.8.1 (Ubuntu 4.8.1-2ubuntu1~12.04)
[Bug c++/56039] ICE in iterative_hash_template_arg, at cp/pt.c:1606
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56039 --- Comment #7 from Hubert Tong hstong at ca dot ibm.com 2013-01-20 16:45:13 UTC --- (In reply to comment #6) I wonder why you think this would belong to the immediate context. Actually it seems to me as if the instantiation of the body of a lambda expression is similarly non-immediate as the instantiation of a class template. The body of a closure under N3290, forms a unique, singular instance which lexically eminates from the source location where the lambda expression occurs (by definition) and cannot be instantiated except by the presence of the lambda expression itself. That is, whether the body of the lambda expression is valid or not valid is not affected by unknowns such as what types it would be instantiated with or what names would be found if the lookup was moved to a different context.
[Bug c++/56039] ICE in iterative_hash_template_arg, at cp/pt.c:1606
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56039 --- Comment #8 from Hubert Tong hstong at ca dot ibm.com 2013-01-20 17:50:50 UTC --- (In reply to comment #7) That is, whether the body of the lambda expression is valid or not valid is not affected by unknowns such as what types it would be instantiated with or what names would be found if the lookup was moved to a different context. I am referring to the case where the lambda is not inside a template declaration in the above. For the case where the lambda is in a template declaration, I believe that the properties I mentioned in comment #7 translate to the body of the lambda being within the immediate context of the instantiation when an instantiation of the enclosing template occurs.
[Bug c++/56039] ICE in iterative_hash_template_arg, at cp/pt.c:1606
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56039 --- Comment #2 from Hubert Tong hstong at ca dot ibm.com 2013-01-19 16:38:31 UTC --- (In reply to comment #1) re: 5.19 p2 b8 5.19 p2 (before the referenced bullet list) reads: ..., but subexpressions of logical AND (5.14), logical OR (5.15) and conditional (5.16) operations that are not evaluated are not considered... re: 5.1.2 p2 The use of the lambda expression in the code snippet does not appear as the operand of either typeid, sizeof, noexcept or decltype.
[Bug c++/56039] ICE in iterative_hash_template_arg, at cp/pt.c:1606
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56039
--- Comment #4 from Hubert Tong hstong at ca dot ibm.com 2013-01-19 20:10:59
UTC ---
(In reply to comment #3)
I seem to find that the expression in question
false [](){}
is valid because there is a implicit conversion sequence consisting of a
user-defined conversion to pointer-to-function followed by a conversion to bool
from the pointer type.
I'm forwarding this problem to CWG. I don't think that any compiler change
will be done before that decision, because the CWG group intentionally tried
to forbid lambda expressions within template declarations because of some
known technical problems.
Sure. While I may not have a full appreciation of the difficultly for having an
implementation which works with this, I am aware that there is at least the
issue with mangling hinted at by the note in 14.5.6.1 [temp.over.link] p7 with
regards to the linking of equivalent declarations.
I am not sure, though, that implementation difficulty is a good reason to
remove the ability to have SFINAE applied on statements such as the declaration
in the IsConstructibleImpl specialization above.
[Bug c++/56039] New: ICE in iterative_hash_template_arg, at cp/pt.c:1606
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56039
Bug #: 56039
Summary: ICE in iterative_hash_template_arg, at cp/pt.c:1606
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hst...@ca.ibm.com
Host: powerpc64-suse-linux
Target: powerpc64-suse-linux
Build: powerpc64-suse-linux
I am working on a code base which implements type traits using SFINAE,
and when I try it with GCC, I get the reported ICE.
The code uses C++11 lambda expressions in a constant expression context for
the SFINAE. As far as I can tell, SFINAE should apply since the lambda occurs
lexically within the immediate context for the substitution.
I have extracted a functional portion of the code base into a standalone file
(see below).
### Self-contained source:$ cat lambdaSupportedTraits.cc
template bool struct BoolSink { typedef void type; };
template typename T, typename U
struct AddRvalueReferenceImpl { typedef T type; };
template typename T
struct AddRvalueReferenceImplT, typename BoolSinkfalse
[] {
extern T tref;
}::type {
typedef T type;
};
template typename T
struct AddRvalueReference : AddRvalueReferenceImplT, void { };
namespace ImplHelpers {
template typename T
typename AddRvalueReferenceT::type create(void) { }
}
template typename T, typename U, typename ...Args
struct IsConstructibleImpl { enum { value = 0 }; };
template typename T, typename ...Args
struct IsConstructibleImplT, typename BoolSinkfalse
[] {
T t( ::ImplHelpers::createArgs() ...);
}::type, Args ... {
enum { value = 1 };
};
template typename T, typename ...Args
struct IsConstructible : IsConstructibleImplT, void, Args ... { };
struct DestroyMe {
~DestroyMe() = delete;
};
static_assert(+IsConstructibleint::value, error);
static_assert(!IsConstructiblevoid::value, error);
static_assert(+IsConstructibleint [1]::value, error);
static_assert(!IsConstructibleDestroyMe::value, error);
static_assert(!IsConstructibleint *, char *::value, error);
static_assert(+IsConstructibleint , int::value, error);
static_assert(!IsConstructibleint , int ::value, error);
static_assert(+IsConstructibleint , int ::value, error);
### Compiler output:$ g++-4.7 -std=c++11 lambdaSupportedTraits.cc -c
lambdaSupportedTraits.cc:10:8: internal compiler error: in
iterative_hash_template_arg, at cp/pt.c:1606
Please submit a full bug report,
with preprocessed source if appropriate.
See http://bugs.opensuse.org/ for instructions.
### g++ -v output:$ g++-4.7 -v
Using built-in specs.
COLLECT_GCC=/GCC_INSTALL/bin/g++-4.7
COLLECT_LTO_WRAPPER=/GCC_INSTALL/libexec/gcc/powerpc64-suse-linux/4.7.2/lto-wrapper
Target: powerpc64-suse-linux
Configured with: ../GCC_SOURCE/gcc-4.7.2/configure --prefix=/GCC_INSTALL
--enable-languages=c,c++,fortran --enable-checking=release --enable-ssp
--disable-libssp --with-bugurl=http://bugs.opensuse.org/
--with-pkgversion='SUSE Linux' --disable-libgcj --disable-libmudflap
--enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch
--enable-version-specific-runtime-libs --program-suffix=-4.7
--enable-linux-futex --without-system-libunwind --with-cpu=power4
--enable-secureplt --with-long-double-128 --build=powerpc64-suse-linux
--with-mpc=/GCC_INSTALL/mpc1.0.1 --with-mpfr=/GCC_INSTALL/mpfr3.1.1
--with-gmp=/GCC_INSTALL/gmp5.1
--with-zlib-include=/usr/src/linux-3.0.13-0.27/include/linux
--with-zlib-lib=/lib
Thread model: posix
gcc version 4.7.2 (SUSE Linux)
[Bug c++/52597] [C++11] missing diagnostics for invalid use of non-static member function in decltype
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52597 --- Comment #4 from Hubert Tong hstong at ca dot ibm.com 2012-08-24 12:42:58 UTC --- I find the message to be confusing.
[Bug c++/53931] New: [C++11] braced function style cast to reference should be prvalue
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53931
Bug #: 53931
Summary: [C++11] braced function style cast to reference should
be prvalue
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hst...@ca.ibm.com
Host: powerpc64-unknown-linux-gnu
Target: powerpc64-unknown-linux-gnu
C++2011 5.2.3 [expr.type.conv] paragraph 3:
Similarly, a simple-type-specifier or typename-specifier followed by
a braced-init-list creates a temporary object of the specified type
direct-list-initialized (8.5.4) with the specified braced-init-list,
and its value is that temporary object as a prvalue.
In the case below, a braced function-style cast to an rvalue reference type
does not behave the same as a prvalue literal with GCC.
### Self-contained source (refBraceCast.cc): cat refBraceCast.cc
typedef int ir;
void bar(int x) { const_castint (ir{x}); }
//void zip(int x) { const_castint (0); } // fails as expected
### Compiler invocation:
g++-4.7.0 -c -std=c++11 refBraceCast.cc; echo rc=$?
### Compiler output:
rc=0
### g++ -v output: g++-4.7.0 -v
Using built-in specs.
COLLECT_GCC=g++-4.7.0
COLLECT_LTO_WRAPPER=/data/gcc/libexec/gcc/powerpc64-unknown-linux-gnu/4.7.0/lto-wrapper
Target: powerpc64-unknown-linux-gnu
Configured with: ../gcc-4.7.0/configure --prefix=/data/gcc
--program-suffix=-4.7.0 --disable-libssp --disable-libgcj
--enable-version-specific-runtime-libs --with-cpu=default32 --enable-secureplt
--with-long-double-128 --enable-shared --enable-__cxa_atexit
--enable-threads=posix --enable-languages=c,c++,fortran --with-mpfr=/usr/local/
--with-mpc=/usr/local/ --with-gmp=/usr/local/
Thread model: posix
gcc version 4.7.0 (GCC)
[Bug c++/53868] New: Temporary for indirect binding is not destroyed when destructor from initializer temp throws
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53868
Bug #: 53868
Summary: Temporary for indirect binding is not destroyed when
destructor from initializer temp throws
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hst...@ca.ibm.com
Host: powerpc64-unknown-linux-gnu
Target: powerpc64-unknown-linux-gnu
The temporary created for indirect binding should be completely constructed
(and from the output _it is_) before the destructors for temporaries in the
initializer are called.
In the following case, the destructor for a temporary in the initializer throws
an int. During stack unwinding, it seems the temporary bound to the reference
is missed.
### Self-contained source: cat tempbindIndirect_inittempDtorThrows.cpp
extern C int printf(const char *, ...);
extern C void abort();
struct SubobjectInA {
SubobjectInA();
~SubobjectInA();
};
struct A : SubobjectInA {
A() = delete;
A(const A ) = delete;
A(A ) { }
A(int);
~A();
};
#define TRACE_FUNC( ... ) \
{ printf(%s\n, __PRETTY_FUNCTION__); __VA_ARGS__ }
struct Q {
Q() : q(0) TRACE_FUNC()
~Q();
int q;
};
int main() {
try { const A a = Q().q; }
catch (...) { return 0; }
abort();
}
SubobjectInA::SubobjectInA() TRACE_FUNC()
SubobjectInA::~SubobjectInA() TRACE_FUNC()
A::A(int) TRACE_FUNC()
A::~A() TRACE_FUNC()
Q::~Q() TRACE_FUNC( throw 0; )
### Compiler invocation:
g++-4.7.0 -std='c++11' tempbindIndirect_inittempDtorThrows.cpp -o test
### Compiler output:
(return code 0)
### Output from resulting executable: ./test ; echo rc=$?
Q::Q()
SubobjectInA::SubobjectInA()
A::A(int)
Q::~Q()
rc=0
### Expected output:
Q::Q()
SubobjectInA::SubobjectInA()
A::A(int)
Q::~Q()
A::~A()
SubobjectInA::~SubobjectInA()
rc=0
### gcc -v output: g++-4.7.0 -v
Using built-in specs.
COLLECT_GCC=g++-4.7.0
COLLECT_LTO_WRAPPER=/data/gcc/libexec/gcc/powerpc64-unknown-linux-gnu/4.7.0/lto-wrapper
Target: powerpc64-unknown-linux-gnu
Configured with: ../gcc-4.7.0/configure --prefix=/data/gcc
--program-suffix=-4.7.0 --disable-libssp --disable-libgcj
--enable-version-specific-runtime-libs --with-cpu=default32 --enable-secureplt
--with-long-double-128 --enable-shared --enable-__cxa_atexit
--enable-threads=posix --enable-languages=c,c++,fortran --with-mpfr=/usr/local/
--with-mpc=/usr/local/ --with-gmp=/usr/local/
Thread model: posix
gcc version 4.7.0 (GCC)
[Bug c++/53288] [C++11] Lifetime of temporary object backing pointer-to-member expression not extended
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53288 Hubert Tong hstong at ca dot ibm.com changed: What|Removed |Added Keywords|rejects-valid |wrong-code Version|4.6.0 |4.7.0 Summary|[C++11] Reference fails to |[C++11] Lifetime of |bind directly to prvalue|temporary object backing |member access expression|pointer-to-member ||expression not extended Known to fail|4.4.0, 4.5.0, 4.6.0 |4.7.0 --- Comment #2 from Hubert Tong hstong at ca dot ibm.com 2012-06-07 21:36:54 UTC --- (In reply to comment #1) It compiles fine with 4.7 or trunk. I think this is a dup of an existing bug Jason fixed, possibly one he reported himself, about elements of rvalue arrays. Confirmed that the above works as expected under 4.7. However, replacing: const B b = A(1).b; with: const B b = A(1).*(A::b); produces an executable whose output indicates that the lifetime of the temporary is not being extended: ctor B(int) body: (this=0xffe9f7d8,_data=1) ctor A(int) body: (this=0xffe9f7d8,_data=1) dtor for A: (this=0xffe9f7d8,_data=1) dtor for B: (this=0xffe9f7d8,_data=1) main() user body begins main() user body ends ### g++ -v output: g++-4.7.0 -v Using built-in specs. COLLECT_GCC=g++-4.7.0 COLLECT_LTO_WRAPPER=/data/gcc/libexec/gcc/powerpc64-unknown-linux-gnu/4.7.0/lto-wrapper Target: powerpc64-unknown-linux-gnu Configured with: ../gcc-4.7.0/configure --prefix=/data/gcc --program-suffix=-4.7.0 --disable-libssp --disable-libgcj --enable-version-specific-runtime-libs --with-cpu=default32 --enable-secureplt --with-long-double-128 --enable-shared --enable-__cxa_atexit --enable-threads=posix --enable-languages=c,c++,fortran --with-mpfr=/usr/local/ --with-mpc=/usr/local/ --with-gmp=/usr/local/ Thread model: posix gcc version 4.7.0 (GCC)
[Bug c++/53606] New: Invalid candidate chosen; warning message claims to know better than the Standard
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53606
Bug #: 53606
Summary: Invalid candidate chosen; warning message claims to
know better than the Standard
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hst...@ca.ibm.com
Host: powerpc64-unknown-linux-gnu
Target: powerpc64-unknown-linux-gnu
GCC emits a warning stating that the template-dependent call in the type of
a parameter of a function template instantiation is ambiguous according to the
Standard.
It then fails to remove the candidate despite what should then be substitution
failure.
I am not quite sure how GCC found one of the operator+ overloads to be better
than the other, but whatever mechanism is being used, it should not interfere
with the translation of a well-formed program.
### Self-contained source (op_overload_sfinae.cpp): cat op_overload_sfinae.cpp
template typename T
struct false_ { enum : bool { value = false }; };
struct A {
template typename T
int operator +(const T ) const;
};
template typename T
int operator +(const A , const T );
const int lv_const_int();
template typename T
T lv_T();
template typename T
void foo(void *, char * = 0) { }
template typename T
void foo(int, char (*)[sizeof (lv_TT() + lv_const_int(), 0)] = 0) {
static_assert(false_T::value,
If the warning is correct, then the Standard says I should not see this.);
}
int main() {
fooA(0);
}
### Compiler invocation:
g++-4.7.0 -c op_overload_sfinae.cpp -std=c++11
### Compiler output:
op_overload_sfinae.cpp: In instantiation of 'void foo(int, char (*)[sizeof
(((lv_TT() + lv_const_int()), 0))]) [with T = A]':
op_overload_sfinae.cpp:27:12: required from here
op_overload_sfinae.cpp:21:66: warning: ISO C++ says that these are ambiguous,
even though the worst conversion for the first is better than the worst
conversion for the second: [enabled by default]
op_overload_sfinae.cpp:10:5: note: candidate 1: int operator+(const A, const
T) [with T = int]
op_overload_sfinae.cpp:6:5: note: candidate 2: int A::operator+(const T) const
[with T = int]
op_overload_sfinae.cpp:22:4: error: static assertion failed: If the warning is
correct, then the Standard says I should not see this.
### g++ -v output: g++-4.7.0 -v
Using built-in specs.
COLLECT_GCC=g++-4.7.0
COLLECT_LTO_WRAPPER=/data/gcc/libexec/gcc/powerpc64-unknown-linux-gnu/4.7.0/lto-wrapper
Target: powerpc64-unknown-linux-gnu
Configured with: ../gcc-4.7.0/configure --prefix=/data/gcc
--program-suffix=-4.7.0 --disable-libssp --disable-libgcj
--enable-version-specific-runtime-libs --with-cpu=default32 --enable-secureplt
--with-long-double-128 --
enable-shared --enable-__cxa_atexit --enable-threads=posix
--enable-languages=c,c++,fortran --with-mpfr=/usr/local/ --with-mpc=/usr/local/
--with-gmp=/usr/local/
Thread model: posix
gcc version 4.7.0 (GCC)
[Bug c++/53288] New: [C++11] Reference fails to bind directly to prvalue member access expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53288
Bug #: 53288
Summary: [C++11] Reference fails to bind directly to prvalue
member access expression
Classification: Unclassified
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hst...@ca.ibm.com
Host: powerpc64-unknown-linux-gnu
Target: powerpc64-unknown-linux-gnu
In the reference initialization,
const B b = A(1).b;
the initializer expression is a class prvalue.
The requirement to bind an lvalue reference to a non-volatile const type
directly to a reference-compatible class prvalue dates back to DR 391 which
PR 25950 intended to implement.
The error messages complaining about the private and deleted move constructor
indicate that direct binding was not done.
### Self-contained source (tempbind_expr_ref.cpp): cat tempbind_expr_ref.cpp
extern C int printf(const char *, ...);
struct B {
B(int data) : _data(data) {
printf(ctor B(int) body: (this=%p,_data=%d)\n, (void *)this, _data);
}
~B() {
printf(dtor for B: (this=%p,_data=%d)\n, (void *)this, _data);
}
int _data;
private:
B() = delete;
B(const B ) = delete;
B(B ) = delete;
};
struct A {
B b;
A(int data) : b(data) {
printf(ctor A(int) body: (this=%p,_data=%d)\n, (void *)this, b._data);
}
~A() {
printf(dtor for A: (this=%p,_data=%d)\n, (void *)this, b._data);
}
private:
A() = delete;
A(const A ) = delete;
A(A ) = delete;
};
const B b = A(1).b;
int main() {
printf(main() user body begins\n);
printf(main() user body ends\n);
}
### Compiler invocation:
g++-4.6.0 tempbind_expr_ref.cpp -std=c++0x
### Compiler output:
tempbind_expr_ref.cpp:16:4: error: 'B::B(B)' is private
tempbind_expr_ref.cpp:34:19: error: within this context
tempbind_expr_ref.cpp:34:19: error: use of deleted function 'B::B(B)'
tempbind_expr_ref.cpp:16:4: error: declared here
### g++ -v output: g++-4.6.0 -v
Using built-in specs.
COLLECT_GCC=g++-4.6.0
COLLECT_LTO_WRAPPER=/data/gcc/libexec/gcc/powerpc64-unknown-linux-gnu/4.6.0/lto-wrapper
Target: powerpc64-unknown-linux-gnu
Configured with: ./configure --prefix=/data/gcc --program-suffix=-4.6.0
--disable-libssp --disable-libgcj --enable-version-specific-runtime-libs
--with-cpu=default32 --enable-secureplt --with-long-double-128 --enable-shared
--enable-__cxa_atexit --enable-threads=posix --enable-languages=c,c++,fortran
--with-gmp=/usr/local
Thread model: posix
gcc version 4.6.0 (GCC)
[Bug c++/52597] [C++11] missing diagnostics for invalid use of non-static member function in decltype
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52597 --- Comment #2 from Hubert Tong hstong at ca dot ibm.com 2012-03-28 23:51:37 UTC --- The message from 4.7.0 does not really make sense, although it probably does fix the functional issues associated with the reported bug in contexts where SFINAE applies.
[Bug c++/52761] New: [C++11] Missing diagnostic for opaque unscoped enum declaration without base
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52761
Bug #: 52761
Summary: [C++11] Missing diagnostic for opaque unscoped enum
declaration without base
Classification: Unclassified
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hst...@ca.ibm.com
Host: powerpc64-unknown-linux-gnu
Target: powerpc64-unknown-linux-gnu
### Self-contained source:$ cat enumredecl.cc
enum E { X };
enum E; // illegal
### Analysis:
For C++2011, subclause 7.2 [dcl.enum] paragraph 2 says:
An opaque-enum-declaration declaring an unscoped enumeration shall not omit the
enum-base.
The code is also invalid under C++03.
The redeclaration does not meet the requirements in C++03 clause 7 [dcl.dcl]
paragraph 3 for the omission of the init-declarator-list in a simple-
declaration. Namely, it is not a class definition or declaration and is not a
enum definition.
It also fails to requirements in subclause 7.1.5.3 [dcl.type.elab] paragraph 1
for an elaborated-type-specifier that is the sole constituent of a declaration.
Namely, it is neither an explicit specialization, explicit instantiation, class
declaration nor friend class declaration.
### Compiler invocations:
$ g++-4.6.0 --std='c++0x' -Wall -W -pedantic enumredecl.cc -c
$ g++-4.6.0 --std='c++98' -Wall -W -pedantic enumredecl.cc -c
### Compiler output (both cases):
(return code 0)
### g++ -v output:$ g++-4.6.0 -v
Using built-in specs.
COLLECT_GCC=g++-4.6.0
COLLECT_LTO_WRAPPER=/data/gcc/libexec/gcc/powerpc64-unknown-linux-gnu/4.6.0/lto-wrapper
Target: powerpc64-unknown-linux-gnu
Configured with: ./configure --prefix=/data/gcc --program-suffix=-4.6.0
--disable-libssp --disable-libgcj --enable-version-specific-runtime-libs
--with-cpu=default32 --enable-secureplt --with-long-double-128 --enable-shared
--enable-__cxa_atexit --enable-threads=posix --enable-languages=c,c++,fortran
--with-gmp=/usr/local
Thread model: posix
gcc version 4.6.0 (GCC)
[Bug c++/52597] New: [C++11] missing diagnostics for invalid use of non-static member function in decltype
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52597
Bug #: 52597
Summary: [C++11] missing diagnostics for invalid use of
non-static member function in decltype
Classification: Unclassified
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hst...@ca.ibm.com
Host: powerpc64-unknown-linux-gnu
Target: powerpc64-unknown-linux-gnu
The following test case shows that GCC allows several ill-formed decltype
constructs with non-static member functions.
Using the last form, SFINAE can be put into play--so wrong overload resolution
and partial specialization matching can be made to occur.
In particular:
bar0 violates N3290 subclause 5.1.1 [expr.prim.general] paragraph 12 regarding
valid uses of an id-expression that denotes a non-static data member or non-
static member function.
The other decltype specifiers violate N3290 subclause 5.2.5 [expr.ref]
paragraph 4 since the non-static member function is not used as the left-hand
operand of a member function call.
### Self-contained source:$ cat illdclty.cc
struct A {
int zip();
decltype(zip) bar0; // invalid use of non-static member function name
// [expr.prim.general]
void bar1() { typedef decltype(this-A::zip) x; }
// invalid use of non-static member function name
// [expr.ref]
void bar2() { typedef decltype(A::zip) x; }
// invalid use of non-static member function name
// (same as bar1), see [class.mfct.non-static]
};
typedef decltype(A().zip) x;
// invalid use of non-static member function name
// [expr.ref]
### Compiler invocation:$ g++-4.6.0 --std=c++0x illdclty.cc -W -Wall -pedantic
-c
### Compiler output:
(return code 0)
### g++ -v output:$ g++-4.6.0 -v
Using built-in specs.
COLLECT_GCC=g++-4.6.0
COLLECT_LTO_WRAPPER=/data/gcc/libexec/gcc/powerpc64-unknown-linux-gnu/4.6.0/lto-wrapper
Target: powerpc64-unknown-linux-gnu
Configured with: ./configure --prefix=/data/gcc --program-suffix=-4.6.0
--disable-libssp --disable-libgcj --enable-version-specific-runtime-libs
--with-cpu=default32 --enable-secureplt --with-long-double-128 --enable-shared
--enable-__cxa_atexit --enable-threads=posix --enable-languages=c,c++,fortran
--with-gmp=/usr/local
Thread model: posix
gcc version 4.6.0 (GCC)
[Bug c/52291] New: __sync_fetch_and_add and friends poorly specified for pointer types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52291
Bug #: 52291
Summary: __sync_fetch_and_add and friends poorly specified for
pointer types
Classification: Unclassified
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hst...@ca.ibm.com
CC: micha...@ca.ibm.com
Host: powerpc64-unknown-linux-gnu
Target: powerpc64-unknown-linux-gnu
The documentation states, regarding the __sync_fetch_and_X builtins:
These builtins perform the operation suggested by the name, and returns the
value that had previously been in memory. That is,
{ tmp = *ptr; *ptr op= value; return tmp; }
{ tmp = *ptr; *ptr = ~(tmp value); return tmp; } // nand
For pointer types (which GCC accepts for these builtins) the operation
suggested by the name leans toward pointer arithmetic; however, the pointer
types are not suitable for these operations in C/C++.
[Bug c/52291] __sync_fetch_and_add and friends poorly specified for pointer types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52291 --- Comment #1 from Hubert Tong hstong at ca dot ibm.com 2012-02-17 00:37:12 UTC --- I mean that the pseudo-code is not consistent with valid C/C++ when the operands (`*ptr' and `value') are pointer types.
[Bug c++/51854] New: ICE in mangle.c with literal of complex floating type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51854
Bug #: 51854
Summary: ICE in mangle.c with literal of complex floating type
Classification: Unclassified
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hst...@ca.ibm.com
Host: powerpc64-unknown-linux-gnu
Target: powerpc64-unknown-linux-gnu
ICE with imaginary component in mangled expression.
## Small self-contained source (cmplxfMangle.cpp):
template unsigned N struct A;
template typename U, typename V
char foo(U, V);
template typename U
void bar(Asizeof(foo(U(), 1.0fj)) *);
int main() {
barint(0);
}
## Compiler invocation:
g++-4.6.0 cmplxfMangle.cpp -c
## Compiler output:
cmplxfMangle.cpp: In instantiation of âvoid bar(Asizeof (char foo(U(),
(__complex__ float){0.0f, 1.0e+0f}))*) [with U = int]â:
cmplxfMangle.cpp:10:15: instantiated from here
cmplxfMangle.cpp:7:6: internal compiler error: in write_template_arg_literal,
at cp/mangle.c:2772
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
## g++ -v output:
Using built-in specs.
COLLECT_GCC=g++-4.6.0
COLLECT_LTO_WRAPPER=/data/gcc/libexec/gcc/powerpc64-unknown-linux-gnu/4.6.0/lto-wrapper
Target: powerpc64-unknown-linux-gnu
Configured with: ./configure --prefix=/data/gcc --program-suffix=-4.6.0
--disable-libssp --disable-libgcj --enable-version-specific-runtime-libs
--with-cpu=default32 --enable-secureplt --with-long-double-128 --enable-shared
--enable-__cxa_atexit --enable-threads=posix --enable-languages=c,c++,fortran
--with-gmp=/usr/local
Thread model: posix
gcc version 4.6.0 (GCC)
[Bug c++/51817] New: [C++11] argument deduction fails when A-type parameter-type-list has additional parameters
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51817
Bug #: 51817
Summary: [C++11] argument deduction fails when A-type
parameter-type-list has additional parameters
Classification: Unclassified
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hst...@ca.ibm.com
Host: powerpc64-unknown-linux-gnu
Target: powerpc64-unknown-linux-gnu
The behaviour of the following test case was clarified in paper N2242 for
variadic templates.
In the 2011 FDIS subclause 14.8.2.5 [temp.deduct.type] paragraph 10,
deduction from a function type considers P/A pairs from the
parameter-type-list only where the P function type has a parameter.
Deduction is not specified to fail if there are additional parameters in the
corresponding A function type.
I use the --std=c++0x option; however, I do not believe that the C++03 wording
prohibits the C++2011 behaviour.
The second call to foo in main should be the same as the first (working) call.
If compiled and linked with -DVERBOSE, the resulting program should print:
Converting from Avoid (int, char) to Avoid (int).
foo(Avoid (int) called.
Converting from Avoid (int, char) to Avoid (int).
foo(Avoid (int) called.
### Self-contained source:
$ cat parmlistlen.cpp
template typename U
struct A {
template typename V operator AV();
};
template typename T void foo(Avoid (T));
void foo();
int main() {
Avoid (int, char) a;
fooint(a);
foo(a); // seems to fail in argument deduction
}
#ifdef VERBOSE
extern C int printf(const char *, ...);
template typename T struct tyStr { static const char str[]; };
template const char tyStrvoid (int, char)::str[] = void (int, char);
template const char tyStrvoid (int)::str[] = void (int);
template typename T
void foo(Avoid (T)) {
printf(foo(A%s called.\n, tyStrvoid (T)::str);
}
template typename U
template typename V
AU::operator AV() {
printf(Converting from A%s to A%s.\n, tyStrU::str, tyStrV::str);
return AV();
}
#endif
### Compiler Invocation:
$ g++-4.6.0 --std='c++0x' parmlistlen.cpp
parmlistlen.cpp: In function 'int main()':
parmlistlen.cpp:12:9: error: no matching function for call to 'foo(Avoid(int,
char))'
parmlistlen.cpp:12:9: note: candidates are:
parmlistlen.cpp:6:28: note: templateclass T void foo(Avoid(T))
parmlistlen.cpp:7:6: note: void foo()
parmlistlen.cpp:7:6: note: candidate expects 0 arguments, 1 provided
### g++ -v output:
$ g++-4.6.0 -v
Using built-in specs.
COLLECT_GCC=g++-4.6.0
COLLECT_LTO_WRAPPER=/data/gcc/libexec/gcc/powerpc64-unknown-linux-gnu/4.6.0/lto-wrapper
Target: powerpc64-unknown-linux-gnu
Configured with: ./configure --prefix=/data/gcc --program-suffix=-4.6.0
--disable-libssp --disable-libgcj --enable-version-specific-runtime-libs
--with-cpu=default32 --enable-secureplt --with-long-double-128 --enable-shared
--enable-__cxa_atexit --enable-threads=posix --enable-languages=c,c++,fortran
--with-gmp=/usr/local
Thread model: posix
gcc version 4.6.0 (GCC)
[Bug c++/51385] New: Unnecessary instantiation converting to pointer to template class instance
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51385
Bug #: 51385
Summary: Unnecessary instantiation converting to pointer to
template class instance
Classification: Unclassified
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hst...@ca.ibm.com
Host: powerpc64-unknown-linux-gnu
Target: powerpc64-unknown-linux-gnu
The test case below uses SFINAE to check whether pointers to certain types
can be implicitly converted.
When a template class which is expensive to instantiate is used as the type
pointed-to by the target of the conversion, GCC takes a long time to compile.
I do not believe that the instantiation of the type in question is necessary to
determine the validity of the conversion (notwithstanding the non-normative
note
in 3.2 [basic.def.odr] paragraph 4). See Core Issue 50 regarding that note.
### Self-contained source:$ cat bb2.C
#ifndef SLOW
enum { Depth = 3 };
#else
enum { Depth = 15 };
#endif
template unsigned N struct NTmpl;
template typename T, typename U, typename V = NTmplsizeof(T *)
struct PtrConvs {
enum { bad = 1 };
};
template typename Target, typename Source
struct PtrConvsTarget, Source, NTmplsizeof (*(Target **)0 = (Source *)0) ;
template unsigned N, typename T struct FastGrowingTemplate;
template typename T
struct FastGrowingTemplate0, T { };
template unsigned N, typename T
struct FastGrowingTemplate :
FastGrowingTemplateN - 1, const T *,
FastGrowingTemplateN - 1, volatile T *
{ };
struct B { };
typedef char chk[1];
typedef char chk[PtrConvsFastGrowingTemplateDepth, short, B::bad];
### Time without -DSLOW:$ time /data/gcc/bin/g++-4.6.0 bb2.C -c
real0m0.236s
user0m0.007s
sys 0m0.006s
### Time with -DSLOW:$ time /data/gcc/bin/g++-4.6.0 bb2.C -c -DSLOW
real1m45.826s
user1m42.505s
sys 0m0.312s
### g++ -v output:$ /data/gcc/bin/g++-4.6.0 -v
Using built-in specs.
COLLECT_GCC=/data/gcc/bin/g++-4.6.0
COLLECT_LTO_WRAPPER=/data/gcc/libexec/gcc/powerpc64-unknown-linux-gnu/4.6.0/lto-wrapper
Target: powerpc64-unknown-linux-gnu
Configured with: ./configure --prefix=/data/gcc --program-suffix=-4.6.0
--disable-libssp --disable-libgcj --enable-version-specific-runtime-libs
--with-cpu=default32 --enable-secureplt --with-long-double-128 --enable-shared
--enable-__cxa_atexit --enable-threads=posix --enable-languages=c,c++,fortran
--with-gmp=/usr/local
Thread model: posix
gcc version 4.6.0 (GCC)
[Bug c++/49458] New: [C++0x] Obvious candidate for conversion to function lvalue rejected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49458
Summary: [C++0x] Obvious candidate for conversion to function
lvalue rejected
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hst...@ca.ibm.com
CC: micha...@ca.ibm.com
Host: powerpc64-unknown-linux-gnu
Target: powerpc64-unknown-linux-gnu
According to the 2011 FCD, subclause 13.3.1.6 [over.match.ref] paragraph 1:
The conversion functions of S and its base classes are considered, except that
for copy-initialization, only the non-explicit conversion functions are
considered. Those that are not hidden within S and yield type lvalue reference
to cv2 T2 (when 8.5.3 requires an lvalue result) or cv2 T2 or
rvalue reference to cv2 T2 (when 8.5.3 requires an rvalue result), where
cv1 T is reference-compatible (8.5.3) with cv2 T2, are candidate functions.
Both lvalue references and rvalue references to function types require binding
to function lvalues. The following test case is expected to compile clean.
GCC still does not compile if #1 is commented out.
GCC will compile if #2 is commented out, but that behaviour is unsupported by
the referenced wording.
In particular, #2 should be a candidate and (from the wording) #1 is not for
conversion to a function lvalue.
### Self-contained source (a.cpp): cat a.cpp
typedef void ftype();
void foo() { }
struct A {
operator ftype(void); // #1
operator ftype(void) { return foo; } // #2
};
ftype frvref = A();
### Compiler invocation:
g++-4.6.0 -std=c++0x -o a.o -c a.cpp
### Compiler output:
a.cpp:9:20: error: invalid initialization of reference of type ‘void ()()’
from expression of type ‘A’
### g++ -v output: g++-4.6.0 -v
Using built-in specs.
COLLECT_GCC=g++-4.6.0
COLLECT_LTO_WRAPPER=/data/gcc/libexec/gcc/powerpc64-unknown-linux-gnu/4.6.0/lto-wrapper
Target: powerpc64-unknown-linux-gnu
Configured with: ./configure --prefix=/data/gcc --program-suffix=-4.6.0
--disable-libssp --disable-libgcj --enable-version-specific-runtime-libs
--with-cpu=default32 --enable-secureplt --with-long-double-128 --enable-shared
--enable-__cxa_atexit --enable-threads=posix --enable-languages=c,c++,fortran
--with-gmp=/usr/local
Thread model: posix
gcc version 4.6.0 (GCC)
[Bug c++/49395] New: Non-class prvalues seem to have cv-qualification with GCC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49395
Summary: Non-class prvalues seem to have cv-qualification with
GCC
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hst...@ca.ibm.com
CC: micha...@ca.ibm.com
Host: powerpc64-unknown-linux-gnu
Target: powerpc64-unknown-linux-gnu
C++03 subclause 3.10 [basic.lval] paragraph 9 says that non-class rvalues
always have cv-unqualified types. When compiling with GCC, some forms of
expressions producing non-class rvalues still act as if they have cv-qualified
type. The test case below is meant to compile clean.
### Self-contained source (a.cpp):
volatile int foo();
struct A { volatile int i; };
typedef volatile int vi;
volatile int i;
const int ir1 = foo();
const int ir2 = A().i; // line 8
const int ir3 = static_castvolatile int(i);
const int ir4 = vi(); // line 10
### Compiler Invocation:
g++-4.6.0 -c a.cpp -o a.o
### Compiler output:
a.cpp:8:22: error: invalid initialization of reference of type 'const int'
from expression of type 'volatile int'
a.cpp:10:21: error: invalid initialization of reference of type 'const int'
from expression of type 'vi'
### g++ -v output:
Using built-in specs.
Target: powerpc64-unknown-linux-gnu
Configured with: ./configure --prefix=/data/gcc --program-suffix=-4.6.0
--disable-libssp --disable-libgcj --enable-version-specific-runtime-libs
--with-cpu=default32 --enable-secureplt --with-long-double-128 --enable-shared
--enable-__cxa_atexit --enable-threads=posix --enable-languages=c,c++,fortran
--with-gmp=/usr/local
Thread model: posix
gcc version 4.6.0 (GCC)
