[Bug c++/96215] New: Wrong mangling for non-dependent return type involving decltype(g.x) or decltype(p->x)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96215
Bug ID: 96215
Summary: Wrong mangling for non-dependent return type involving
decltype(g.x) or decltype(p->x)
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: arthur.j.odwyer at gmail dot com
Target Milestone: ---
// https://godbolt.org/z/z4rjjq
struct S { int x; int operator*() const; };
extern const S g;
extern const S *p;
extern int S::*m;
template
decltype(g.x) foo() { return 0; }
template
decltype(p->x) bar() { return 0; }
template int foo();
template int bar();
Clang mangles these instantiations as
_Z3fooIiEiv
_Z3barIiEiv
GCC mangles them as
_Z3fooIiEDtdtL_Z1gE1xEv
_Z3barIiEDtptL_Z1pE1xEv
Weirdly, GCC doesn't seem to have this issue with any other operators --
decltype(g+1), decltype(g.*m), etc. are all handled as synonyms for `int`. Only
dot and arrow are handled as-if-they-were-dependent-even-though-they-aren't.
[Bug c++/39970] gcc accepts the . dot operator in template arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39970
Arthur O'Dwyer changed:
What|Removed |Added
CC||arthur.j.odwyer at gmail dot
com
--- Comment #9 from Arthur O'Dwyer ---
As of C++11, the original code is legitimate-ish:
struct blah { int member; };
constexpr blah global = {42};
template
class template_blah { };
template_blah<> x; // OK, param is 42
But:
(1) GCC still incorrectly accepts the template even when `global` is non-const.
So does MSVC. Clang correctly(?) rejects it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96213 might be related.
(2) I don't understand Brandon's original concern around mangling operator dot.
The value of the default argument here is just "42"; we don't have to mangle
the dot at all.
An example of name-mangling the dot operator would be like
template
decltype(T().x) foo() { return 0; }
struct S { int x; };
template int foo();
which GCC correctly mangles as `_Z3fooI1SEDtdtcvT__E1xEv`.
So I think the only remaining issue here is the incorrect acceptance of a
non-const default argument for `int param`, and that part MIGHT duplicate bug
#96213 which I just filed.
[Bug c++/96214] New: gcc warn unreached else {}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96214
Bug ID: 96214
Summary: gcc warn unreached else {}
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jg at jguk dot org
Target Milestone: ---
First posted here
https://gcc.gnu.org/pipermail/gcc-help/2020-July/139136.html
Can g++ warn where code will not get to the 'return 3;' below?
This isn't real code, this is just an example. Upon code reviews, I do come
across something like this, so a warning would be handy.
My example
int main(void)
{
const int i = 1;
if(1 == i)
{
return 1;
}
else if(1 != i)
{
return 2;
}
else
{
return 3;
}
}
Quoting Martin Sebor
-Wduplicated-branches detects a related problem. It's implemented
entirely in the front end and quite simplistic. It just looks at
the chain of expressions controlling the if statements and compares
them for equality. I think it could be enhanced with not too much
effort to detect a subset of this problem as well by considering
the operator as well as its operands.
Here's the function that does the checking and issues the warning:
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/c-family/c-warn.c#l2491
Martin
[Bug c++/87234] GCC should warn if template parameter redefines default argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87234 Arthur O'Dwyer changed: What|Removed |Added CC||arthur.j.odwyer at gmail dot com --- Comment #3 from Arthur O'Dwyer --- Duplicate of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50370
[Bug c++/82850] g++ permits redefinition of default arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82850 Arthur O'Dwyer changed: What|Removed |Added CC||arthur.j.odwyer at gmail dot com --- Comment #5 from Arthur O'Dwyer --- Duplicate of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50370
[Bug c++/96213] New: GCC doesn't complain about ill-formed non-dependent template default argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96213
Bug ID: 96213
Summary: GCC doesn't complain about ill-formed non-dependent
template default argument
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: arthur.j.odwyer at gmail dot com
Target Milestone: ---
Possibly related (although these seem to complain about the opposite of what
I'm complaining about):
- https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12672
- https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58071
// https://godbolt.org/z/EYzxx9
template int g;
template(0,1,2)>
void h() { }
int main() {
h<1>();
}
MSVC and Clang both reject template `h` as ill-formed, because `g(0,1,2)`
is nonsense -- `g` is an `int` and thus cannot be called like a function.
GCC accepts template `h` as well-formed, and in fact will treat this as a
SFINAE situation:
template int g;
template(42)> void h() {} // #1
template void h() {} // #2
int main() {
h<>(); // unambiguously calls #2, because #1 has a deduction failure
}
My guess is that MSVC and Clang are closer to correct here.
[Bug target/92488] GCC generates calls to __dpd_trunctdsd2 with -mhard-dfp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92488 --- Comment #8 from Peter Bergner --- (In reply to Peter Bergner from comment #7) > If you still want operands[2] marked early clobber, I can do that. Segher set me straight offline on why we need that early clobber too. I'll kick off testing with that change.
[Bug target/92488] GCC generates calls to __dpd_trunctdsd2 with -mhard-dfp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92488 --- Comment #7 from Peter Bergner --- (In reply to Segher Boessenkool from comment #5) > operands[2] needs an earlyclobber as well (it is written while some > operands are still read later). Everything else is fine as far as I > can see :-) I originally had that early clobber as well, but the only operand still read later is operands[3] which is already early clobber, so do we really need that? If we mark operands[2] early clobber, then we'll never be able to assign operands[1] and operands[2] to the same hw register, which they could be. If you still want operands[2] marked early clobber, I can do that.
[Bug testsuite/96212] new test case libgomp.fortran/alloc-3.F fails in r11-2101
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96212 --- Comment #2 from Tobias Burnus --- (In reply to Bill Seurer from comment #1) > After running on a few more machines this appears to be a BE only issue. alloc-1.F90 uses a proper interface (Fortran module). alloc-3.F uses a header file with the old-style Fortran 66/77 way of just having external subroutine_name or external function_name integer function_name ! <- data type the function returns. Thus, by this declaration the compiler does not know how the interface actually looks like. In principle, it could (and should?!?) deduce the interface from the first procedure call – and create the declaration from the use. However, it doesn't do this. My bet is that the actually used argument-passing of caller and callee differs on PowerPC and, hence, it fails. Solution? * XFAIL? * Changing the way in gfortran how the external-function declaration is generated?
[Bug c++/95942] [11 regression] offsetof on an array: error: 'e' is not a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95942
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4 from Jakub Jelinek ---
struct S { int a; int b[15]; };
int
foo (int n)
{
int m = n;
return __builtin_offsetof (S, b[m]);
}
has been rejected for years, while
struct S { int a; int b[15]; };
int
foo (int n)
{
return __builtin_offsetof (S, b[n]);
}
has been accepted.
The comment in cp/parser.c says:
/* ??? For offsetof, there is a question of what to allow here. If
offsetof is not being used in an integral constant expression context,
then we *could* get the right answer by computing the value at runtime.
If we are in an integral constant expression context, then we might
could accept any constant expression; hard to say without analysis.
Rather than open the barn door too wide right away, allow only integer
constant expressions here. */
[Bug target/92488] GCC generates calls to __dpd_trunctdsd2 with -mhard-dfp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92488 --- Comment #6 from Segher Boessenkool --- (So, pre-approved with that change, and with a testcase... A run test ideally, if that isn't too hard?)
[Bug target/92488] GCC generates calls to __dpd_trunctdsd2 with -mhard-dfp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92488 --- Comment #5 from Segher Boessenkool --- operands[2] needs an earlyclobber as well (it is written while some operands are still read later). Everything else is fine as far as I can see :-)
[Bug c++/95942] [11 regression] offsetof on an array: error: 'e' is not a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95942
--- Comment #3 from Sergei Trofimovich ---
Another example is edb-debugger project
https://github.com/eteran/edb-debugger/blob/070d0196227a58ce2ba15c695944ba16ce66c080/plugins/DebuggerCore/unix/linux/arch/x86-generic/PlatformThread.cpp#L331:
long PlatformThread::setDebugRegister(std::size_t n, unsigned long value) {
return ptrace(PTRACE_POKEUSER, tid_, offsetof(struct user,
u_debugreg[n]), value);
}
Fails build on gcc-11 as:
edb-debugger/plugins/DebuggerCore/unix/linux/arch/x86-generic/PlatformThread.cpp:331:72:
error: 'n' is not a constant expression
331 | return ptrace(PTRACE_POKEUSER, tid_, offsetof(struct user,
u_debugreg[n]), value);
| ^
[Bug c++/90189] Spurious "error: parameter packs not expanded" when a dependent name coincides
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90189
Aleksey Covacevice changed:
What|Removed |Added
CC||aleksey.covacevice at gmail
dot co
||m
--- Comment #1 from Aleksey Covacevice ---
Another such situation:
template
struct any;
template
using any_t = typename any::type;
template
struct str { any_t>> func(); };
Changing `type` to something else, in either `any_t` or `str`, allows the code
to compile.
5.1.0 accepts the code; 5.2.0 onward reject it.
Possibly related to #61022.
[Bug testsuite/96212] new test case libgomp.fortran/alloc-3.F fails in r11-2101
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96212 --- Comment #1 from Bill Seurer --- After running on a few more machines this appears to be a BE only issue.
[Bug target/92488] GCC generates calls to __dpd_trunctdsd2 with -mhard-dfp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92488 --- Comment #4 from Peter Bergner --- So the following pattern added to dfp.md: +(define_insn "trunctdsd2" + [(set (match_operand:SD 0 "gpc_reg_operand" "=d") + (float_truncate:SD (match_operand:TD 1 "gpc_reg_operand" "d"))) + (clobber (match_scratch:TD 2 "=d")) + (clobber (match_scratch:DF 3 "="))] + "TARGET_DFP" + "mffs %3\;mtfsfi 7,7,1\;drdpq %2,%1\;mtfsf 0xff,%3,1,0\;drsp %0,%2" + [(set_attr "type" "dfp") + (set_attr "length" "20")]) Gives me the following on Paul's test case: truncd128: .LFB0: .cfi_startproc mffs 0 mtfsfi 7,7,1 drdpq 12,2 mtfsf 0xff,0,1,0 drsp 1,12 blr Does this look like what we want?
[Bug c++/95942] [11 regression] offsetof on an array: error: 'e' is not a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95942 Patrick Palka changed: What|Removed |Added Last reconfirmed||2020-07-15 Ever confirmed|0 |1 CC||ppalka at gcc dot gnu.org Status|UNCONFIRMED |NEW
[Bug testsuite/96212] New: new test case libgomp.fortran/alloc-3.F fails in r11-2101
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96212 Bug ID: 96212 Summary: new test case libgomp.fortran/alloc-3.F fails in r11-2101 Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: seurer at linux dot vnet.ibm.com Target Milestone: --- g:fff15bad1ab571906c37b88380431768d917dcb0, r11-2101 make -k check-target-libgomp RUNTESTFLAGS=fortran.exp=libgomp.fortran/alloc-3.F FAIL: libgomp.fortran/alloc-3.F -O execution test # of expected passes1 # of unexpected failures1 spawn [open ...] STOP 4 FAIL: libgomp.fortran/alloc-3.F -O execution test testcase /home/seurer/gcc/git/gcc-test/libgomp/testsuite/libgomp.fortran/fortran.exp completed in 1 seconds
[Bug target/96189] Failure to use eflags from cmpxchg on x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96189 Uroš Bizjak changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |11.0 Status|ASSIGNED|RESOLVED --- Comment #4 from Uroš Bizjak --- Implemented for gcc-11.
[Bug target/96189] Failure to use eflags from cmpxchg on x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96189 --- Comment #3 from Uroš Bizjak --- The master branch has been updated by Uros Bizjak : https://gcc.gnu.org/g:6c2848ad02feef5ac094d1158be3861819b3bb49 commit r11-2140-g6c2848ad02feef5ac094d1158be3861819b3bb49 Author: Uros Bizjak Date: Wed Jul 15 21:27:00 2020 +0200 i386: Introduce peephole2 to use flags from CMPXCHG more [PR96189] CMPXCHG instruction sets ZF flag if the values in the destination operand and EAX register are equal; otherwise the ZF flag is cleared and value from destination operand is loaded to EAX. Following assembly: movl%esi, %eax lock cmpxchgl %edx, (%rdi) cmpl%esi, %eax sete%al can be optimized by removing the unneeded comparison, since set ZF flag signals that no update to EAX happened. 2020-15-07 UroÅ¡ Bizjak gcc/ChangeLog: PR target/95355 * config/i386/sync.md (peephole2 to remove unneded compare after CMPXCHG): New pattern. gcc/testsuite/ChangeLog: PR target/95355 * gcc.target/i386/pr96189.c: New test.
[Bug target/95355] [11 Regression] Assembler messages: Error: operand size mismatch for `vpmovzxbd' with -masm=intel since r11-485-gf6e40195ec3d3b402a5f6c58dbf359479bc4cbfa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95355 Uroš Bizjak changed: What|Removed |Added Target Milestone|11.0|10.2 Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #10 from Uroš Bizjak --- (In reply to Martin Liška from comment #5) > Can the bug be marked as resolved? Yes, this particular problem is fixed for gcc-10.2+.
[Bug target/95355] [11 Regression] Assembler messages: Error: operand size mismatch for `vpmovzxbd' with -masm=intel since r11-485-gf6e40195ec3d3b402a5f6c58dbf359479bc4cbfa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95355 --- Comment #9 from Uroš Bizjak --- (In reply to CVS Commits from comment #8) > The master branch has been updated by Uros Bizjak : Bah. Wrong PR reference, should be PR96189.
[Bug target/95355] [11 Regression] Assembler messages: Error: operand size mismatch for `vpmovzxbd' with -masm=intel since r11-485-gf6e40195ec3d3b402a5f6c58dbf359479bc4cbfa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95355 --- Comment #8 from CVS Commits --- The master branch has been updated by Uros Bizjak : https://gcc.gnu.org/g:6c2848ad02feef5ac094d1158be3861819b3bb49 commit r11-2140-g6c2848ad02feef5ac094d1158be3861819b3bb49 Author: Uros Bizjak Date: Wed Jul 15 21:27:00 2020 +0200 i386: Introduce peephole2 to use flags from CMPXCHG more [PR96189] CMPXCHG instruction sets ZF flag if the values in the destination operand and EAX register are equal; otherwise the ZF flag is cleared and value from destination operand is loaded to EAX. Following assembly: movl%esi, %eax lock cmpxchgl %edx, (%rdi) cmpl%esi, %eax sete%al can be optimized by removing the unneeded comparison, since set ZF flag signals that no update to EAX happened. 2020-15-07 Uroš Bizjak gcc/ChangeLog: PR target/95355 * config/i386/sync.md (peephole2 to remove unneded compare after CMPXCHG): New pattern. gcc/testsuite/ChangeLog: PR target/95355 * gcc.target/i386/pr96189.c: New test.
[Bug libstdc++/89417] helgrind detects a lock order violation inside std::scoped_lock
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89417
--- Comment #7 from Jonathan Wakely ---
(In reply to Federico Kircheis from comment #6)
> For what is worth, I imagined the implementation for parameters of different
> type and more or less than two to be similar to
>
>
> template
> auto sorted_indexes(Args&... args) {
> const void* addresses[] = {};
> std::array indexes{};
> std::iota(std::begin(indexes), std::end(indexes), 0);
> std::sort(std::begin(indexes), std::end(indexes), [&](int i1, int i2){
> return std::less()(addresses[i1], addresses[i2]);
> });
> return indexes;
> }
>
>
> template
> auto create_lock(Args&... args){
> auto indexes = sorted_indexes(args...);
> return std::scoped_lock(args[indexes]...); // ???
> }
>
>
> But it's probably a dead end, as args is not an array and I see no way to
> use the computed index.
args is not an array and indexes is not a pack.
You could make sorted_indexes a constexpr function that returns a
std::index_sequence holding the sorted indices, then:
template
auto create_lock_impl(std::index_sequence, T arg_tuple, ) {
return std::scoped_lock(std::get(args)...);
}
template
auto create_lock(Args&... args) {
return create_lock_impl(sorted_indexes(args...), std::tie(args...));
}
But I am still unconvinced it's worth changing anything here.
[Bug middle-end/96200] Implement __builtin_thread_pointer() and __builtin_set_thread_pointer() if TLS is supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96200 --- Comment #2 from Carlos O'Donell --- (In reply to Florian Weimer from comment #1) > __builtin_set_thread_pointer has little value from a glibc perspective > because when used in application code, it will always result in undefined > behavior. Correct, but it's useful for a C library implemetnation. In glibc the aarch64 tls.h is made quite clean by the use of __builtin_thread_pointer and __builtin_set_thread_pointer.
[Bug libstdc++/89417] helgrind detects a lock order violation inside std::scoped_lock
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89417
--- Comment #6 from Federico Kircheis ---
For what is worth, I imagined the implementation for parameters of different
type and more or less than two to be similar to
template
auto sorted_indexes(Args&... args) {
const void* addresses[] = {};
std::array indexes{};
std::iota(std::begin(indexes), std::end(indexes), 0);
std::sort(std::begin(indexes), std::end(indexes), [&](int i1, int i2){
return std::less()(addresses[i1], addresses[i2]);
});
return indexes;
}
template
auto create_lock(Args&... args){
auto indexes = sorted_indexes(args...);
return std::scoped_lock(args[indexes]...); // ???
}
But it's probably a dead end, as args is not an array and I see no way to use
the computed index.
[Bug c++/90664] [9/10/11 regression] noexcept confuses template argument deduction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90664 Jakub Jelinek changed: What|Removed |Added Summary|[7/8 regression] noexcept |[9/10/11 regression] |confuses template argument |noexcept confuses template |deduction |argument deduction CC||jakub at gcc dot gnu.org Target Milestone|--- |9.4
[Bug libstdc++/68737] FAIL: 22_locale/num_put/put/char/14220.cc execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68737 --- Comment #30 from dave.anglin at bell dot net --- I'll test when I get a chance.
[Bug c++/90664] [7/8 regression] noexcept confuses template argument deduction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90664 ofv at wanadoo dot es changed: What|Removed |Added Summary|noexcept confuses template |[7/8 regression] noexcept |argument deduction |confuses template argument ||deduction --- Comment #2 from ofv at wanadoo dot es --- The upcoming gcc 11 still shows this problem. I edited the bug title to indicate that it is a regression.
[Bug libstdc++/89417] helgrind detects a lock order violation inside std::scoped_lock
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89417
--- Comment #5 from Federico Kircheis ---
(In reply to Jonathan Wakely from comment #4)
> (In reply to Federico Kircheis from comment #3)
> > My guess, without having looked at the implementation of std::lock, is that
> > the algorithm uses try_lock to eventually lock/unlock the mutexes and see if
> > it manages to lock both, in order to avoid the deadlock.
>
> Right. So the potential deadlock helgrind complains about can't happen.
Ok, I missed that confirmation.
Mine where only suppositions, I was not sure.
I would normally use a tool to validate such claims in a code-basis (as my
expertise with mutlithreading is very limited), unfortunately it produced the
log I've attached in my first report :-)
> > But even if std::lock would be correct (and it is a false positive of
> > valgrind), wouldn't sorting by address be an optimization?
>
> Not in the uncontended case, no, because it does extra work to sort them.
> Your make_lock function doesn't work for more than two arguments so a more
> complex algorithm is needed for the general case (it doesn't even work for
> fewer than two arguments, although obviously that's trivial to support).
Well, for the generic case I though a sort based on address would suffice.
My "implementation" was just the special-case for 2 arguments.
As it would be abnormal to lock a lot (with a lot >=5) mutexes, I guessed the
overhead of sorting would be minimal compared to locking.
> > As far as I understand, if the mutexes are always locked in the same order,
> > one does not need to try_lock.
>
> That's not true. As I already said above, another thread could be locking
> the same mutexes without using std::lock (in any order), or it could be
> locking a different but overlapping set of mutexes.
>
>
> > I'm therefore not saying the current algorithm should be dismissed, just
> > asking if ordering before applying the algorithm could have any benefit.
> > Apart from the fact that helgrind would not complain anymore, which IMHO
> > would already be a big win.
>
> Changing the locking algorithm to avoid a false positive from a particular
> tool seems unwise.
Do you know other independent tools that can diagnose possible
deadlocks/race-conditions?
I'm genuinely curious (sorry if this is gettin off-topic).
It could have helped avoid creating this issue if valgrind was the only one
complaining (tools working on windows are fine too).
On the other hand, if other tools complains too, it might make more sense (at
least from my perspective) to accommodate third-party analyzers (while of
course they should be fixed too).
> > Maybe there are known drawbacks to sorting by address, but as mutexes cannot
> > be moved,
>
> std::mutex cannot be moved, but std::lock and std::scoped_lock don't only
> work with standard mutexes. You have no idea whether foo::Mutex or
> bar::Lockable can be moved. You can't even assume that the address is
> meaningful, I could write a copyable mutex where different copies share a
> lock:
>
> class CopyableMutex
> {
> std::shared_ptr m = std::make_shared();
> public:
> CopyableMutex() = default;
> CopyableMutex(const CopyableMutex&) = default;
>
> void lock() { m->lock(); }
> bool try_lock() { return m->try_lock(); }
> void unlock() { m->unlock(); }
> };
Oh, I did not realize that the locking classes works on custom types, I guess
that settles the discussion.
I could of course argue that it is possible to sort only for the standard
mutexes, but I see that it is more work than I thought with very little benefit
(especially if other tools do not complain).
[Bug ipa/96211] Segmentation fault when using "-O2 -fno-dce -fno-tree-dce" but passing at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96211 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- That is because the testcase is invalid. When the a function has two int arguments, you need to call it with 2 int arguments, calling it with no arguments is UB.
[Bug ipa/96211] New: Segmentation fault when using "-O2 -fno-dce -fno-tree-dce" but passing at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96211
Bug ID: 96211
Summary: Segmentation fault when using "-O2 -fno-dce
-fno-tree-dce" but passing at -O2
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: chenjunjie9208 at 163 dot com
CC: marxin at gcc dot gnu.org
Target Milestone: ---
Hi,
I came across a bug recently. The following simplified code is miscompiled with
current gcc trunk using "-O2 -fno-dce -fno-tree-dce" on x86_64 GNU/Linux. It
will report "Segmentation fault (core dumped)". However, when using any
optimization levels (e.g., -O2, -O3), it does not have any problems. Looking
forward to your reply, Thanks!
$ gcc --version
gcc (GCC) 11.0.0 20200715 (experimental)
$
$ gcc -O2 -fno-dce -fno-tree-dce a.c; ./a.out
Segmentation fault (core dumped)
$ gcc -O3 -fno-dce -fno-tree-dce a.c; ./a.out
Segmentation fault (core dumped)
$ gcc -Os -fno-dce -fno-tree-dce a.c; ./a.out
Segmentation fault (core dumped)
$
$ gcc -O1 -fno-dce -fno-tree-dce a.c; ./a.out
$ gcc -O3 a.c; ./a.out
$ gcc -Os a.c; ./a.out
$ gcc -O2 a.c; ./a.out
$ gcc -O1 a.c; ./a.out
$ gcc -O0 a.c; ./a.out
$
---
static int *a();
void b() { a(); }
int *a(int c, int *d) { int e = 0 >= *d; }
int main() { b(); }
[Bug c++/96210] New: Diagnostic message for using-directive in template definition should be more clear?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96210
Bug ID: 96210
Summary: Diagnostic message for using-directive in template
definition should be more clear?
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: haoxintu at gmail dot com
Target Milestone: ---
Hi, all.
Alias template is allowed since c++11 while using-directive is not. The
diagnostic message in using-directive used in template maybe not so clear in
GCC.
For example,
$cat test.cc
namespace N{ }
template using namespace N;
$g++ test.cc
test.cc:2:24: error: expected identifier before 'namespace'
2 | template using namespace N;
|^
:2:35: error: expected '{' before ';' token
2 | template using namespace N;
|
I guess users will be confused with above two error messages and may feel
hopeless to fix it according to the diagnostic information.
Clang might be better in parsing this code
$clang++ test.cc
test.cc:2:18: error: cannot template a using directive
template using namespace N;
~^
1 error generated.
I guess GCC should also recognize the using directive first and then tell users
this is not allowed in template definition.
Please understand if anything I presented is unsuitable.
Thanks,
Haoxin
[Bug c++/96209] New: Redundant error message split out when adding "typename" keyword
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96209
Bug ID: 96209
Summary: Redundant error message split out when adding
"typename" keyword
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: haoxintu at gmail dot com
Target Milestone: ---
Hi, all.
This code, test1.cc and test2.cc ( they are in the same meaning I guess), are
invalid code with a little mistake, but the compiling output is different when
I add the "typename" keyword. Here are the examples:
$cat test1.cc
template class T{};
:: T < int ... >
foo ( ... )
{ }
$cat test2.cc
template class T{};
typename :: T < int ... >
foo ( ... )
{ }
$g++ -w test1.cc
test1.cc:2:12: error: expansion pattern ‘int’ contains no parameter packs
2 | :: T < int ... >
|^~~
test1.cc:2:16: error: template argument 1 is invalid
2 | :: T < int ... >
|^
$g++ -w test2.cc
test2.cc:2:21: error: expansion pattern ‘int’ contains no parameter packs
2 | typename :: T < int ... >
| ^~~
test2.cc:2:25: error: template argument 1 is invalid
2 | typename :: T < int ... >
| ^
test2.cc:3:1: error: ‘foo’ in namespace ‘::’ does not name a type
3 | foo ( ... )
| ^~~
test2.cc:3:7: error: expected unqualified-id before ‘...’ token
3 | foo ( ... )
| ^~~
test2.cc:3:6: error: expected ‘)’ before ‘...’ token
3 | foo ( ... )
| ~^~~~
| )
The first two message are ok in test2.cc. And the following message in
unnecessary and useless.
While in clang, only one error message ("error: pack expansion does not contain
any unexpanded parameter packs") is edited in both two cases.
I guess GCC has some room to improve this diagnostic case. Every GCC version
from 5.x onwards behaves the same.
Thanks,
Haoxin
[Bug c++/96205] compile error on: #define JJWIDE(x) L#x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96205 --- Comment #3 from Jakub Jelinek --- But not in GCC, clang or ICC.
[Bug c++/96205] compile error on: #define JJWIDE(x) L#x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96205 --- Comment #2 from francis.andre.kampbell at orange dot fr --- This '#define JJWIDE(x) L#x' is workign fine with MSVC VS2017
[Bug tree-optimization/96208] New: non-power-of-2 group size can be vectorized for 2-element vectors case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96208 Bug ID: 96208 Summary: non-power-of-2 group size can be vectorized for 2-element vectors case Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: dpochepk at gmail dot com Target Milestone: --- Created attachment 48879 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48879=edit initial implementation Current loop vectorizer only vectorize loops with groups size being power-of-2 or 3 due to vector permutation generation algorithm specifics. However, in case of 2-element vectors, simple permutation schema can be used to support any group size: insert each vector element into required position, which leads to reasonable amount of operations in case of 2-element vectors. Initial version is attached.
[Bug c++/96207] New: GCC accepts "delete" function definition inside a class member function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96207
Bug ID: 96207
Summary: GCC accepts "delete" function definition inside a
class member function
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: accepts-invalid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: haoxintu at gmail dot com
Target Milestone: ---
Hi, all.
This code, test.cc, is an invalid code, GCC compiles it well, while other
mainstream compiles (clang,icc,and msvc) all reject it.
$cat test.cc
class A {
void foo1 () {
void foo2 () = delete ;
}
};
$g++ -c test.cc
test.cc: In member function ‘void A::foo1()’:
test.cc:3:20: warning: declaration of ‘void foo2()’ has ‘extern’ and is
initialized
3 | void foo2 () = delete ;
|^
GCC only emits a warning message (I also doubt that the meaning of this
message) and then accepts it.
Every Clang version from 6.x onwards behaves the same.
Thanks,
Haoxin
[Bug bootstrap/96202] --enable-cet complains about missing assembler support with GCC 7 host compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96202 H.J. Lu changed: What|Removed |Added URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2020-July/55 ||0086.html Keywords||patch --- Comment #2 from H.J. Lu --- A patch is posted at https://gcc.gnu.org/pipermail/gcc-patches/2020-July/550086.html
[Bug libgomp/96198] new test case libgomp.c/loop-21.c in r11-2077
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96198 --- Comment #4 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:79c12969ec3e9185fdbb90d3b1699d64b1cd0901 commit r11-2138-g79c12969ec3e9185fdbb90d3b1699d64b1cd0901 Author: Jakub Jelinek Date: Wed Jul 15 16:34:54 2020 +0200 openmp: Fix up loop-21.c I've missed +FAIL: libgomp.c/loop-21.c execution test during testing of the recent patch. The problem is that while for the number of iterations computation it doesn't matter if we compute min_inner_iterations as (m2 * first + n2 + (adjusted step) + m1 * first + n1) / step or (m2 * last + n2 + (adjusted step) + m1 * last + n1) / step provided that in the second case we use as factor (m1 - m2) * ostep / step rather than (m2 - m1) * ostep / step, for the logical to actual iterator values computation it does matter and in my hand written C implementations of all the cases (outer vs. inner loop with increasing vs. decreasing iterator) I'm using the same computation and it worked well for all the pseudo-random iterators testing it was doing. It also means min_inner_iterations is misnamed, because it is not really minimum number of inner iterations, whether the first or last outer iteration results in the smaller or larger value of this can be (sometimes) only determined at runtime. So this patch also renames it to first_inner_iterations. 2020-07-15 Jakub Jelinek PR libgomp/96198 * omp-general.h (struct omp_for_data): Rename min_inner_iterations member to first_inner_iterations, adjust comment. * omp-general.c (omp_extract_for_data): Adjust for the above change. Always use n1first and n2first to compute it, rather than depending on single_nonrect_cond_code. Similarly, always compute factor as (m2 - m1) * outer_step / inner_step rather than sometimes m1 - m2 depending on single_nonrect_cond_code. * omp-expand.c (expand_omp_for_init_vars): Rename min_inner_iterations to first_inner_iterations and min_inner_iterationsd to first_inner_iterationsd.
[Bug c++/96206] New: internal compiler error: in convert_move, at expr.c:218
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96206 Bug ID: 96206 Summary: internal compiler error: in convert_move, at expr.c:218 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: enrico at enricozini dot org Target Milestone: --- Created attachment 48878 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48878=edit File that causes the ICE, preprocessed Hello, thank you all for g++! I get an ICE while trying to cross-compile the attached file with -O2: $ /usr/bin/arm-linux-gnueabihf-g++-O2 -c gcc-ice.cc -o /tmp/gcc-ice.o during RTL pass: expand gcc-ice.cc: In function ‘void baseline::exec_ops(const Op*, const void**, const char*, char*, int)’: gcc-ice.cc:5142:13: internal compiler error: in convert_move, at expr.c:218 static void exec_ops(const Op* ops, const void** args, ^~~~ 0x7ff9d453c09a __libc_start_main ../csu/libc-start.c:308 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See for instructions. $ /usr/bin/arm-linux-gnueabihf-g++ --version arm-linux-gnueabihf-g++ (Debian 8.3.0-2) 8.3.0 The source compiles fine with g++ 9.2.1. Regards, Enrico
[Bug c++/96205] compile error on: #define JJWIDE(x) L#x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96205 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #1 from Jakub Jelinek --- That is not a compiler bug, but an user error. If you want the L to become the same token as "Hello World!", you need to use L###x instead of L#x.
[Bug tree-optimization/96167] fails to detect ROL pattern in simple case, but succeeds when operand goes through memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96167
--- Comment #4 from Jakub Jelinek ---
Like:
unsigned long long
foo (unsigned long long x)
{
union U { unsigned long long x; char y[8]; } u, v;
u.x = x;
v.y[0] = u.y[7];
v.y[1] = u.y[0];
v.y[2] = u.y[1];
v.y[3] = u.y[2];
v.y[4] = u.y[3];
v.y[5] = u.y[4];
v.y[6] = u.y[5];
v.y[7] = u.y[6];
return v.x;
}
unsigned long long
bar (unsigned long long x)
{
union U { unsigned long long x; char y[8]; } u;
u.x = x;
char t = u.y[7];
u.y[7] = u.y[6];
u.y[6] = u.y[5];
u.y[5] = u.y[4];
u.y[4] = u.y[3];
u.y[3] = u.y[2];
u.y[2] = u.y[1];
u.y[1] = u.y[0];
u.y[0] = t;
return u.x;
}
[Bug c++/96205] New: compile error on: #define JJWIDE(x) L#x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96205
Bug ID: 96205
Summary: compile error on: #define JJWIDE(x) L#x
Product: gcc
Version: 7.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: francis.andre.kampbell at orange dot fr
Target Milestone: ---
Hello
The following c++ source bug.cpp does not compile with: g++ -DWIDE_CHAR bug.cpp
#include
#ifndef WIDE_CHAR
#define JAVACC_CHAR_TYPE char
#define JAVACC_CHAR_TYPE_SIZEOF 1
#define JJIN std::cin
#define JJOUT std::cout
#define JJERR std::cerr
#define JJLOG std::cout
#define JJWIDE(x) #x
#else
#define JJIN std::wcin
#define JJOUT std::wcout
#define JJERR std::wcerr
#define JJLOG std::wcout
#define JJWIDE(x) L#x
#endif
int main(int argc, char**argv) {
JJOUT << JJWIDE(Hello World!) << std::endl;
return 0;
}
fandre@ubuntu-18-04:~$ g++ -DWIDE_CHAR bug.cpp
bug.cpp: In function ‘int main(int, char**)’:
bug.cpp:16:20: error: ‘L’ was not declared in this scope
#define JJWIDE(x) L#x
^
bug.cpp:20:11: note: in expansion of macro ‘JJWIDE’
JJOUT << JJWIDE(Hello World!) << std::endl;
[Bug tree-optimization/96167] fails to detect ROL pattern in simple case, but succeeds when operand goes through memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96167 --- Comment #3 from Jakub Jelinek --- Yeah. But at least if the target has corresponding mode rotate optab, there is no reason not to support any rotates by constant multiples of byte size (for bit rotates we don't have infrastructure for that).
[Bug tree-optimization/96167] fails to detect ROL pattern in simple case, but succeeds when operand goes through memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96167 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |NEW Severity|normal |enhancement Last reconfirmed||2020-07-15 Ever confirmed|0 |1 --- Comment #2 from Eric Botcazou --- store-merging certainly has the infrastructure and does it job until: /* A complete byte swap should make the symbolic number to start with the largest digit in the highest order byte. Unchanged symbolic number indicates a read with same endianness as target architecture. */ if (n.n != cmpnop && n.n != cmpxchg) return false; where it of course realizes that this is not a proper 64-bit bswap.
[Bug fortran/31593] Invariant DO loop variables and subroutines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31593 Tobias Schlüter changed: What|Removed |Added Assignee|tobi at gcc dot gnu.org|unassigned at gcc dot gnu.org --- Comment #48 from Tobias Schlüter --- Forgive me, I wasn't aware of this oversight which may have turned away people who could fix this for the past 6 years.
[Bug libgomp/95062] [10/11 Regression] libgomp.oacc-c-c++-common/pr92843-1.c:26: verify_array: Assertion `array[i] == value' failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95062 Thomas Schwinge changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |tschwinge at gcc dot gnu.org --- Comment #1 from Thomas Schwinge --- (In reply to Thomas Schwinge from comment #0) > There are patches to cure this: [...], but these have issues on their own > (cause other regressions). Instead, this issue has been fixed by commit r11-1808-ge7f3f7fe08bdd49367f682398e1d2f4e6b60ef84 "[OpenACC] Revert always-copyfrom behavior for 'GOMP_MAP_FORCE_FROM' in 'libgomp/oacc-mem.c:goacc_exit_data_internal'" (commit r10-8423-g50666d23b52794774eefbeff046d5c3235db8b99) plus commit r11-2020-g6f5b4b64d25a36f085ab90efc3d54c025a7fff49 "openacc: Adjust dynamic reference count semantics" (commit r10-8477-gb8be66d151f5dac79ca13aed33697466195dd800).
[Bug bootstrap/96202] --enable-cet complains about missing assembler support with GCC 7 host compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96202 H.J. Lu changed: What|Removed |Added Ever confirmed|0 |1 Target Milestone|--- |11.0 Last reconfirmed||2020-07-15 Assignee|unassigned at gcc dot gnu.org |hjl.tools at gmail dot com Status|UNCONFIRMED |NEW
[Bug lto/95604] LTO doesn't pick up -fcf-protection flag for the link step
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95604 --- Comment #6 from H.J. Lu --- LTO should follow GNU property spec by merging GNU_PROPERTY_X86_FEATURE_1_IBT and GNU_PROPERTY_X86_FEATURE_1_SHSTK from all IR files, just like ld. The current behavior can be retained by a new option, -fcf-protection=error.
[Bug bootstrap/96203] [11 Regression] LTO bootstrap with --enable-cet is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96203 --- Comment #6 from H.J. Lu --- By design, mixing CET and non-CET objects must be allowed. We should revisit PR 95604.
[Bug bootstrap/96203] [11 Regression] LTO bootstrap with --enable-cet is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96203 --- Comment #5 from H.J. Lu --- (In reply to Richard Biener from comment #4) > Arguably the simplest solution is to demote the error to a warning, > --enable-cet > is supposed to only enable CET instrumentation of (part of) the runtime. If > we want to keep the error we'd need to build several variants of libiberty > (in this case). Not sure why libiberty was CET enabled in the first place - > is it used in target libraries? No. It is for liblto_plugin.so. See PR 94739.
[Bug c++/95726] ICE with aarch64 __Float32x4_t as template argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95726 --- Comment #12 from CVS Commits --- The releases/gcc-10 branch has been updated by Richard Sandiford : https://gcc.gnu.org/g:932e9140d3268cf2033c1c3e93219541c53fcd29 commit r10-8501-g932e9140d3268cf2033c1c3e93219541c53fcd29 Author: Richard Sandiford Date: Wed Jul 15 11:58:04 2020 +0100 c++: Treat GNU and Advanced SIMD vectors as distinct [PR95726] This is a release branch version of r11-1741-g:31427b974ed7b7dd54e28fec595e731bf6eea8ba and r11-2022-g:efe99cca78215e339ba79f0a900a896b4c0a3d36. The trunk versions of the patch made GNU and Advanced SIMD vectors distinct (but inter-convertible) in all cases. However, the traditional behaviour is that the types are distinct in template arguments but not otherwise. Following a suggestion from Jason, this patch puts the check for different vector types under comparing_specializations. In order to keep the backport as simple as possible, the patch hard-codes the name of the attribute in the frontend rather than adding a new branch-only target hook. I didn't find a test that tripped the assert on the branch, even with the --param in the PR, so instead I tested this by forcing the hash function to only hash the tree code. That made the static assertion in the test fail without the patch but pass with it. This means that the tests pass for unmodified sources even without the patch (unless you're very unlucky). gcc/ PR target/95726 * config/aarch64/aarch64.c (aarch64_attribute_table): Add "Advanced SIMD type". * config/aarch64/aarch64-builtins.c: Include stringpool.h and attribs.h. (aarch64_init_simd_builtin_types): Add an "Advanced SIMD type" attribute to each Advanced SIMD type. * config/arm/arm.c (arm_attribute_table): Add "Advanced SIMD type". * config/arm/arm-builtins.c: Include stringpool.h and attribs.h. (arm_init_simd_builtin_types): Add an "Advanced SIMD type" attribute to each Advanced SIMD type. gcc/cp/ PR target/95726 * typeck.c (structural_comptypes): When comparing template specializations, differentiate between vectors that have and do not have an "Advanced SIMD type" attribute. gcc/testsuite/ PR target/95726 * g++.target/aarch64/pr95726.C: New test. * g++.target/arm/pr95726.C: Likewise.
[Bug fortran/95837] derived-type components of character kind=4 – wrong code with component access (kind=4 ignored)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95837 --- Comment #8 from CVS Commits --- The master branch has been updated by Tobias Burnus : https://gcc.gnu.org/g:e0685fadb6aa7c9cc895bc14cbbe2b9026fa3a94 commit r11-2105-ge0685fadb6aa7c9cc895bc14cbbe2b9026fa3a94 Author: Tobias Burnus Date: Wed Jul 15 12:29:44 2020 +0200 libgomp.fortran/struct-elem-map-1.f90: Add char kind=4 tests As the Fortran PR 95837 has been fixed, the test could be be added. libgomp/ChangeLog: * testsuite/libgomp.fortran/struct-elem-map-1.f90: Remove unused variables; add character(kind=4) tests; update TODO comment.
[Bug fortran/95868] Derived-type deferred-length character component handling broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95868 --- Comment #2 from Tobias Burnus --- (In reply to Dominique d'Humieres from comment #1) > Confirmed. Quite complex test case! Came up when trying to write a patch for OpenMP structure/derived-type element mapping (r11-2079). Hence: Additional testcase: libgomp/testsuite/libgomp.fortran/struct-elem-map-1.f90 look for the var%str4 and var%uni4 lines – and uncomment them.
[Bug c++/96204] gcc complains about private member access in SFINAE context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96204 --- Comment #4 from Jonathan Wakely --- The reduced example above doesn't need -std=c++17, it should compile in C++11 or later.
[Bug c++/96204] gcc complains about private member access in SFINAE context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96204
--- Comment #3 from Jonathan Wakely ---
Reduced:
template using void_t = void;
template T&& declval();
template
struct has_set_attr_method {
static constexpr bool value = false;
};
template
struct has_set_attr_method().setAttr(1))>> {
static constexpr bool value = true;
};
struct Parent
{
public:
template
static bool create(){
return has_set_attr_method::value;
}
};
struct Child : public Parent {
public:
friend class Parent;
private:
void setAttr(int) {
}
};
int main() {
Parent::create();
}
[Bug c++/96204] gcc complains about private member access in SFINAE context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96204
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2020-07-15
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Keywords||rejects-valid
--- Comment #2 from Jonathan Wakely ---
(In reply to Klaus Rudolph from comment #0)
> Full code example:
The example is incomplete, and you didn't say how you're compiling it.
This is the complete example, and requires -std=c++17
#include
#include
using std::void_t;
using std::cout;
using std::endl;
template >
struct has_set_attr_method {
static constexpr bool value = false;
};
template
struct has_set_attr_method().setAttr(1))>> {
static constexpr bool value = true;
};
struct Parent
{
public:
template
static void create(){
auto obj = T::create();
if constexpr(has_set_attr_method::value) {
cout << "has setAttr" << endl;
} else {
cout << "no setAttr" << endl;
}
}
};
struct Child : public Parent {
public:
friend class Parent;
static auto create() {
return Child();
}
private:
void setAttr(int) {
}
};
int main() {
Parent::create();
}
#include
#include
using std::void_t;
using std::cout;
using std::endl;
(In reply to Klaus Rudolph from comment #1)
> Maybe related to: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64335
I don't think so, that is "accepts-invalid" not "rejects-valid" and it was
fixed years ago.
[Bug c++/64335] decltype and access of a private member type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64335 Jonathan Wakely changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |6.0 Status|UNCONFIRMED |RESOLVED --- Comment #2 from Jonathan Wakely --- This was fixed for GCC 6 by: Fix decltype-call1.C with -std=c++1z. * parser.h (struct cp_token): Tell GTY that CPP_DECLTYPE uses tree_check_value. * parser.c (cp_parser_decltype): Use tree_check_value. (saved_checks_value): New. (cp_parser_nested_name_specifier_opt): Use it. (cp_parser_template_id): Use it. (cp_parser_simple_type_specifier): Use it. (cp_parser_pre_parsed_nested_name_specifier): Use it. From-SVN: r231353
[Bug target/96176] Failure to omit extraneous movzx in atomic compare exchange with unsigned char
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96176 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Jakub Jelinek --- Fixed for 11+.
[Bug target/96174] AVX-512 functions missing when compiled without optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96174 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Jakub Jelinek --- I've checked it in as obvious to both trunk and 10.2.
[Bug libstdc++/89417] helgrind detects a lock order violation inside std::scoped_lock
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89417
--- Comment #4 from Jonathan Wakely ---
(In reply to Federico Kircheis from comment #3)
> My guess, without having looked at the implementation of std::lock, is that
> the algorithm uses try_lock to eventually lock/unlock the mutexes and see if
> it manages to lock both, in order to avoid the deadlock.
Right. So the potential deadlock helgrind complains about can't happen.
> But even if std::lock would be correct (and it is a false positive of
> valgrind), wouldn't sorting by address be an optimization?
Not in the uncontended case, no, because it does extra work to sort them. Your
make_lock function doesn't work for more than two arguments so a more complex
algorithm is needed for the general case (it doesn't even work for fewer than
two arguments, although obviously that's trivial to support).
> As far as I understand, if the mutexes are always locked in the same order,
> one does not need to try_lock.
That's not true. As I already said above, another thread could be locking the
same mutexes without using std::lock (in any order), or it could be locking a
different but overlapping set of mutexes.
> I'm therefore not saying the current algorithm should be dismissed, just
> asking if ordering before applying the algorithm could have any benefit.
> Apart from the fact that helgrind would not complain anymore, which IMHO
> would already be a big win.
Changing the locking algorithm to avoid a false positive from a particular tool
seems unwise.
> Maybe there are known drawbacks to sorting by address, but as mutexes cannot
> be moved,
std::mutex cannot be moved, but std::lock and std::scoped_lock don't only work
with standard mutexes. You have no idea whether foo::Mutex or bar::Lockable can
be moved. You can't even assume that the address is meaningful, I could write a
copyable mutex where different copies share a lock:
class CopyableMutex
{
std::shared_ptr m = std::make_shared();
public:
CopyableMutex() = default;
CopyableMutex(const CopyableMutex&) = default;
void lock() { m->lock(); }
bool try_lock() { return m->try_lock(); }
void unlock() { m->unlock(); }
};
[Bug c++/96197] Excess memory consumption, positive correlation with the size of a constexpr array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96197 --- Comment #4 from Erich Erstu --- Intuitive logic says that even for a slow algorithm it should not be THAT slow and memory heavy. And for a constant expression, the slowness of an algorithm should not be that much of a concern in the first place, because if the compiler was optimal it would only run that "slow algorithm" once per compilation. Also, it is not intuitive to assume that a slow algorithm would cause high memory consumption. In fact, typically you get speed at the cost of memory. Bottom line is, it is not a matter of people being lazy, it's a matter of people making fair assumptions of what the compiler should reasonably be capable of doing. And in this case, the assumptions were wrong.
[Bug target/96174] AVX-512 functions missing when compiled without optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96174
--- Comment #3 from CVS Commits ---
The releases/gcc-10 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:9a9e1ed88614b96944d2e5e92e932f65dcf2d920
commit r10-8500-g9a9e1ed88614b96944d2e5e92e932f65dcf2d920
Author: Jakub Jelinek
Date: Wed Jul 15 11:34:44 2020 +0200
fix _mm512_{,mask_}cmp*_p[ds]_mask at -O0 [PR96174]
The _mm512_{,mask_}cmp_p[ds]_mask and also _mm_{,mask_}cmp_s[ds]_mask
intrinsics have an argument which must have a constant passed to it
and so use an inline version only for ifdef __OPTIMIZE__ and have
a #define for -O0. But the _mm512_{,mask_}cmp*_p[ds]_mask intrinsics
don't need a constant argument, they are essentially the first
set with the constant added to them implicitly based on the comparison
name, and so there is no #define version for them (correctly).
But their inline versions are defined in between the first and s[ds]
set and so inside of ifdef __OPTIMIZE__, which means that with -O0
they aren't defined at all.
This patch fixes that by moving those after the #ifdef __OPTIMIZE #else
use #define #endif block.
2020-07-15 Jakub Jelinek
PR target/96174
* config/i386/avx512fintrin.h (_mm512_cmpeq_pd_mask,
_mm512_mask_cmpeq_pd_mask, _mm512_cmplt_pd_mask,
_mm512_mask_cmplt_pd_mask, _mm512_cmple_pd_mask,
_mm512_mask_cmple_pd_mask, _mm512_cmpunord_pd_mask,
_mm512_mask_cmpunord_pd_mask, _mm512_cmpneq_pd_mask,
_mm512_mask_cmpneq_pd_mask, _mm512_cmpnlt_pd_mask,
_mm512_mask_cmpnlt_pd_mask, _mm512_cmpnle_pd_mask,
_mm512_mask_cmpnle_pd_mask, _mm512_cmpord_pd_mask,
_mm512_mask_cmpord_pd_mask, _mm512_cmpeq_ps_mask,
_mm512_mask_cmpeq_ps_mask, _mm512_cmplt_ps_mask,
_mm512_mask_cmplt_ps_mask, _mm512_cmple_ps_mask,
_mm512_mask_cmple_ps_mask, _mm512_cmpunord_ps_mask,
_mm512_mask_cmpunord_ps_mask, _mm512_cmpneq_ps_mask,
_mm512_mask_cmpneq_ps_mask, _mm512_cmpnlt_ps_mask,
_mm512_mask_cmpnlt_ps_mask, _mm512_cmpnle_ps_mask,
_mm512_mask_cmpnle_ps_mask, _mm512_cmpord_ps_mask,
_mm512_mask_cmpord_ps_mask): Move outside of __OPTIMIZE__ guarded
section.
* gcc.target/i386/avx512f-vcmppd-3.c: New test.
* gcc.target/i386/avx512f-vcmpps-3.c: New test.
(cherry picked from commit 12d69dbfff9dd5ad4a30b20d1636f5cab6425e8c)
[Bug target/96174] AVX-512 functions missing when compiled without optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96174
--- Comment #2 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:12d69dbfff9dd5ad4a30b20d1636f5cab6425e8c
commit r11-2104-g12d69dbfff9dd5ad4a30b20d1636f5cab6425e8c
Author: Jakub Jelinek
Date: Wed Jul 15 11:34:44 2020 +0200
fix _mm512_{,mask_}cmp*_p[ds]_mask at -O0 [PR96174]
The _mm512_{,mask_}cmp_p[ds]_mask and also _mm_{,mask_}cmp_s[ds]_mask
intrinsics have an argument which must have a constant passed to it
and so use an inline version only for ifdef __OPTIMIZE__ and have
a #define for -O0. But the _mm512_{,mask_}cmp*_p[ds]_mask intrinsics
don't need a constant argument, they are essentially the first
set with the constant added to them implicitly based on the comparison
name, and so there is no #define version for them (correctly).
But their inline versions are defined in between the first and s[ds]
set and so inside of ifdef __OPTIMIZE__, which means that with -O0
they aren't defined at all.
This patch fixes that by moving those after the #ifdef __OPTIMIZE #else
use #define #endif block.
2020-07-15 Jakub Jelinek
PR target/96174
* config/i386/avx512fintrin.h (_mm512_cmpeq_pd_mask,
_mm512_mask_cmpeq_pd_mask, _mm512_cmplt_pd_mask,
_mm512_mask_cmplt_pd_mask, _mm512_cmple_pd_mask,
_mm512_mask_cmple_pd_mask, _mm512_cmpunord_pd_mask,
_mm512_mask_cmpunord_pd_mask, _mm512_cmpneq_pd_mask,
_mm512_mask_cmpneq_pd_mask, _mm512_cmpnlt_pd_mask,
_mm512_mask_cmpnlt_pd_mask, _mm512_cmpnle_pd_mask,
_mm512_mask_cmpnle_pd_mask, _mm512_cmpord_pd_mask,
_mm512_mask_cmpord_pd_mask, _mm512_cmpeq_ps_mask,
_mm512_mask_cmpeq_ps_mask, _mm512_cmplt_ps_mask,
_mm512_mask_cmplt_ps_mask, _mm512_cmple_ps_mask,
_mm512_mask_cmple_ps_mask, _mm512_cmpunord_ps_mask,
_mm512_mask_cmpunord_ps_mask, _mm512_cmpneq_ps_mask,
_mm512_mask_cmpneq_ps_mask, _mm512_cmpnlt_ps_mask,
_mm512_mask_cmpnlt_ps_mask, _mm512_cmpnle_ps_mask,
_mm512_mask_cmpnle_ps_mask, _mm512_cmpord_ps_mask,
_mm512_mask_cmpord_ps_mask): Move outside of __OPTIMIZE__ guarded
section.
* gcc.target/i386/avx512f-vcmppd-3.c: New test.
* gcc.target/i386/avx512f-vcmpps-3.c: New test.
[Bug target/96176] Failure to omit extraneous movzx in atomic compare exchange with unsigned char
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96176 --- Comment #3 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:410675cb63466d8de9ad590521f0766b012d2475 commit r11-2103-g410675cb63466d8de9ad590521f0766b012d2475 Author: Jakub Jelinek Date: Wed Jul 15 11:26:22 2020 +0200 builtins: Avoid useless char/short -> int promotions before atomics [PR96176] As mentioned in the PR, we generate a useless movzbl insn before lock cmpxchg. The problem is that the builtin for the char/short cases has the arguments promoted to int and combine gives up, because the instructions have MEM_VOLATILE_P arguments and recog in that case doesn't recognize anything when volatile_ok is false, and nothing afterwards optimizes the (reg:SI a) = (zero_extend:SI (reg:QI a)) ... (subreg:QI (reg:SI a) 0) ... The following patch fixes it at expansion time, we already have a function that is meant to undo the promotion, so this just adds the very common case to that. 2020-07-15 Jakub Jelinek PR target/96176 * builtins.c: Include gimple-ssa.h, tree-ssa-live.h and tree-outof-ssa.h. (expand_expr_force_mode): If exp is a SSA_NAME with different mode from MODE and get_gimple_for_ssa_name is a cast from MODE, use the cast's rhs. * gcc.target/i386/pr96176.c: New test.
[Bug bootstrap/96203] [11 Regression] LTO bootstrap with --enable-cet is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96203 Richard Biener changed: What|Removed |Added Summary|LTO bootstrap with |[11 Regression] LTO |--enable-cet is broken |bootstrap with --enable-cet ||is broken Target Milestone|--- |11.0 --- Comment #4 from Richard Biener --- Arguably the simplest solution is to demote the error to a warning, --enable-cet is supposed to only enable CET instrumentation of (part of) the runtime. If we want to keep the error we'd need to build several variants of libiberty (in this case). Not sure why libiberty was CET enabled in the first place - is it used in target libraries?
[Bug c++/96197] Excess memory consumption, positive correlation with the size of a constexpr array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96197 --- Comment #3 from rguenther at suse dot de --- On Wed, 15 Jul 2020, hyena at hyena dot net.ee wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96197 > > --- Comment #2 from Erich Erstu --- > Richard Biener, you were right. I optimized the implementation of all the > problematic constant expression functions similarly to the one seen below, and > the compilation time went down to practically zero with unnoticeable memory > consumption. This is simple enough workaround that I can actually put into use > for real. constexpr shouldn't be an excuse for using slow algorithms - the compiler after all doesn't have magic ability just because you write 'constexpr' ;) In fact it's a lot slower in practice (and as you can see memory hungry though that's arguably a bug) - I guess at some point C++ compilers will have JITs just to make constexpr compile-times bearable because people are getting lazy with their algorithms... :/ I'm leaving the bug open for the memory consumption issue.
[Bug bootstrap/96203] LTO bootstrap with --enable-cet is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96203 Matthias Klose changed: What|Removed |Added CC||doko at debian dot org --- Comment #3 from Matthias Klose --- what is the proposed solution? Richard mentioned on IRC to make the error a warning, or build GCC with CET_FLAGS passed to the LDFLAGS used to build the build tools and the compiler itself? which LDFLAGS would that be?
[Bug target/94393] Powerpc suboptimal 64-bit constant comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94393 --- Comment #7 from Alan Modra --- (In reply to Peter Bergner from comment #5) > Alan, I think you pushed some changes to help with 1) above, correct? > Is there more to do for 1)? Possibly, I haven't looked at what needs to be done (if anything) for pli. > As for 2), we're in stage1 now. Do you have ideas about what must be done > there? Do we still want to do something for 2)? I wrote a series of patches in early April.
[Bug c++/96204] gcc complains about private member access in SFINAE context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96204 --- Comment #1 from Klaus Rudolph --- Maybe related to: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64335
[Bug c++/96204] New: gcc complains about private member access in SFINAE context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96204
Bug ID: 96204
Summary: gcc complains about private member access in SFINAE
context
Product: gcc
Version: 10.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lts-rudolph at gmx dot de
Target Milestone: ---
gcc complains with following error in the example code:
main.cpp:59:72: error: 'void Child::setAttr(int)' is private within this
context
59 | struct has_set_attr_method().setAttr(1))>> {
|
~^~~
main.cpp:85:14: note: declared private here
85 | void setAttr(int x) {
| ^~~
main.cpp:59:72: error: 'void Child::setAttr(int)' is private within this
context
59 | struct has_set_attr_method().setAttr(1))>> {
|
~^~~
main.cpp:85:14: note: declared private here
85 | void setAttr(int x) {
| ^~~
main.cpp:59:72: error: 'void Child::setAttr(int)' is private within this
context
59 | struct has_set_attr_method().setAttr(1))>> {
|
~^~~
main.cpp:85:14: note: declared private here
85 | void setAttr(int x) {
Full code example:
---
template >
struct has_set_attr_method {
static constexpr bool value = false;
};
template
struct has_set_attr_method().setAttr(1))>> {
static constexpr bool value = true;
};
struct Parent
{
public:
template
static void create(){
auto obj = T::create();
if constexpr(has_set_attr_method::value) {
cout << "has setAttr" << endl;
} else {
cout << "no setAttr" << endl;
}
}
};
struct Child : public Parent {
public:
friend class Parent;
static auto create() {
return Child();
}
private:
void setAttr(int x) {
}
};
int main(int argc, char const *argv[]) {
Parent::create();
return 0;
}
---
Interestingly the failure depends on "friend" declaration inside "Child".
[Bug c++/96197] Excess memory consumption, positive correlation with the size of a constexpr array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96197
--- Comment #2 from Erich Erstu ---
Richard Biener, you were right. I optimized the implementation of all the
problematic constant expression functions similarly to the one seen below, and
the compilation time went down to practically zero with unnoticeable memory
consumption. This is simple enough workaround that I can actually put into use
for real.
// I added this proxy struct for faster lookups:
constexpr const struct NOUN_INDEX_TYPE {
constexpr NOUN_INDEX_TYPE() : indices() {
for (const noun_type : noun_table) {
indices[static_cast(noun.index)] =
}
}
const noun_type *indices[1024];
} NOUN_INDEX_TABLE;
constexpr const struct noun_type (WORD index, const struct noun_type
*table_row =noun_table) {
return *NOUN_INDEX_TABLE.indices[static_cast(index)];
/*
for (;;) {
if (table_row->index == index) return *table_row;
if (table_row->index == WORD::NONE) return noun_lookup(WORD::NONE);
++table_row;
}
*/
//return table_row->index == index ? *table_row : (table_row->index ==
WORD::NONE ? noun_lookup(WORD::NONE) : NOUN(index, ++table_row));
}
[Bug libgomp/96198] new test case libgomp.c/loop-21.c in r11-2077
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96198 Thomas Schwinge changed: What|Removed |Added CC||tschwinge at gcc dot gnu.org Keywords||openmp Last reconfirmed|2020-07-14 00:00:00 |2020-7-15 --- Comment #3 from Thomas Schwinge --- > g:f418bd4b92a03ee0ec0fe4cfcd896e86e11ac2cf, r11-2077 (No patch submission email for that one, by the way?) (In reply to Jakub Jelinek from comment #2) > I think > --- gcc/omp-general.c.jj 2020-07-14 12:20:01.520110629 +0200 > +++ gcc/omp-general.c 2020-07-14 20:54:48.104237522 +0200 > [...] > should fix that ACK. (But I've only tested this one testcase.) Not sure if that's related here, but compiling with '-O2', we see: libgomp.c/loop-21.c: In function ‘main._omp_fn.11’: libgomp.c/loop-21.c:211:11: warning: ‘.count.340’ may be used uninitialized in this function [-Wmaybe-uninitialized] 211 | #pragma omp parallel for collapse(2) lastprivate (i, j, x) reduction(+:niters) | ^~~ libgomp.c/loop-21.c: In function ‘main._omp_fn.9’: libgomp.c/loop-21.c:175:11: warning: ‘.count.327’ may be used uninitialized in this function [-Wmaybe-uninitialized] 175 | #pragma omp parallel for collapse(2) lastprivate (i, j, x) reduction(+:niters) | ^~~ libgomp.c/loop-21.c: In function ‘main._omp_fn.7’: libgomp.c/loop-21.c:139:11: warning: ‘.count.314’ may be used uninitialized in this function [-Wmaybe-uninitialized] 139 | #pragma omp parallel for collapse(2) lastprivate (i, j, x) reduction(+:niters) | ^~~ libgomp.c/loop-21.c: In function ‘main._omp_fn.5’: libgomp.c/loop-21.c:103:11: warning: ‘.count.301’ may be used uninitialized in this function [-Wmaybe-uninitialized] 103 | #pragma omp parallel for collapse(2) lastprivate (i, j, x) reduction(+:niters) | ^~~ libgomp.c/loop-21.c: In function ‘main._omp_fn.3’: libgomp.c/loop-21.c:67:11: warning: ‘.count.288’ may be used uninitialized in this function [-Wmaybe-uninitialized] 67 | #pragma omp parallel for collapse(2) lastprivate (i, j, x) reduction(+:niters) | ^~~ libgomp.c/loop-21.c: In function ‘main._omp_fn.1’: libgomp.c/loop-21.c:31:11: warning: ‘.count.275’ may be used uninitialized in this function [-Wmaybe-uninitialized] 31 | #pragma omp parallel for collapse(2) lastprivate (i, j, x) reduction(+:niters) | ^~~
[Bug bootstrap/96203] LTO bootstrap with --enable-cet is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96203 --- Comment #2 from CVS Commits --- The releases/gcc-10 branch has been updated by Richard Biener : https://gcc.gnu.org/g:76641cd8b53128e1a962f1313ba75acf0855fd00 commit r10-8499-g76641cd8b53128e1a962f1313ba75acf0855fd00 Author: Richard Biener Date: Wed Jul 15 09:26:08 2020 +0200 Revert "LTO: pick up -fcf-protection flag for the link step" This reverts commit 8147c741df97ee02aa64c099c6b360e6a93384e1. 2020-07-15 Richard Biener PR bootstrap/96203 * lto-opts.c: Revert changes. * lto-wrapper.c: Likewise.
[Bug bootstrap/96203] LTO bootstrap with --enable-cet is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96203 Richard Biener changed: What|Removed |Added CC||doko at gcc dot gnu.org, ||hjl at gcc dot gnu.org --- Comment #1 from Richard Biener --- So we link CET enabled libiberty but do not build GCC itself (and thus gen*) CET enabled which blows up with commit 6a48d12475cdb7375b98277f8bc089715feeeafe Author: Matthias Klose Date: Tue Jul 14 10:12:08 2020 +0200 LTO: pick up -fcf-protection flag for the link step 2020-07-14 Matthias Klose PR lto/95604 * lto-wrapper.c (merge_and_complain): Add decoded options as parameter, error on different values for -fcf-protection. (append_compiler_options): Pass -fcf-protection option. (find_and_merge_options): Add decoded options as parameter, pass decoded_options to merge_and_complain. (run_gcc): Pass decoded options to find_and_merge_options. * lto-opts.c (lto_write_options): Pass -fcf-protection option.
[Bug bootstrap/96203] New: LTO bootstrap with --enable-cet is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96203 Bug ID: 96203 Summary: LTO bootstrap with --enable-cet is broken Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: rguenth at gcc dot gnu.org Target Milestone: --- /tmp/obj/./prev-gcc/xg++ -B/tmp/obj/./prev-gcc/ -B/usr/local/x86_64-pc-linux-gnu/bin/ -nostdinc++ -B/tmp/obj/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -B/tmp/obj/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -I/tmp/obj/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu -I/tmp/obj/prev-x86_64-pc-linux-gnu/libstdc++-v3/include -I/home/rguenther/src/gcc-10-branch/libstdc++-v3/libsupc++ -L/tmp/obj/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -L/tmp/obj/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -g -O2 -fno-checking -flto=jobserver -frandom-seed=1 -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-error=format-diag -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -DGENERATOR_FILE -fno-PIE -static-libstdc++ -static-libgcc -no-pie -o build/genchecksum \ build/genchecksum.o .././libiberty/libiberty.a lto-wrapper: fatal error: option -fcf-protection with mismatching values (none, full) compilation terminated. /usr/lib64/gcc/x86_64-suse-linux/10/../../../../x86_64-suse-linux/bin/ld: error: lto-wrapper failed collect2: error: ld returned 1 exit status make[3]: *** [Makefile:2921: build/genchecksum] Error 1
[Bug bootstrap/96202] --enable-cet complains about missing assembler support with GCC 7 host compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96202 Richard Biener changed: What|Removed |Added CC||hjl at gcc dot gnu.org Target||x86_64-*-* i?86-*-* Keywords||build --- Comment #1 from Richard Biener --- Note this prevents building a CET enabled GCC 10 on say SLES 15.
[Bug bootstrap/96202] New: --enable-cet complains about missing assembler support with GCC 7 host compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96202 Bug ID: 96202 Summary: --enable-cet complains about missing assembler support with GCC 7 host compiler Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: rguenth at gcc dot gnu.org Target Milestone: --- When configuring GCC with --enable-cet it fails during for example lto-plugin config, claiming the assembler does not support CET. But instead it is the host compiler (GCC 7) that does not support -fcf-protection. When the host compiler is used the checks need to be skipped and only the stage2/stage3 binaries need to be CET instrumented when bootstrapping. GCC 10 (and probably older releases) is affected as well.
[Bug tree-optimization/95679] [11 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in type_has_mode_precision_p, at tree.h:6231
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95679 Richard Biener changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2020-07-15 Target Milestone|--- |11.0 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Keywords||needs-bisection --- Comment #1 from Richard Biener --- Whoops, this fell through the cracks - I can't reproduce with g:7a4770f0394751860ee54520b23007938907ac33 though. Confirmed with your cited rev. where we see unit-size align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x7682d1f8 precision:64 min max > arg:0 constant arg:0 constant arg:0 t.c:8:17 start: t.c:8:17 finish: t.c:8:17>> arg:1 arg:0 nothrow def_stmt version:10 in-free-list>>> and thus a released SSA name. That's probably inconsistent SCEV cache not reset before cunroll and the issue is probably still latent. For curiosity I wonder what "fixed" it.
[Bug middle-end/95622] [11 Regression] force_output flag on a variable prevents optimization / regresses c-c++-common/goacc/kernels-alias-ipa-pta{-2,-4,}.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95622 --- Comment #7 from Tobias Burnus --- (In reply to Richard Biener from comment #6) > not sure if fixed? Not fixed – only XFAILed. The issue is that optimizations are not done with "node->force_output". As in the example in comment 0: "a = 0; c = a" will become "c[0] = 0"without force_output but "c[0] = a[0]"with force_output set. As the variable has been already used in the offload-variable table, it cannot be removed for good – but not using it is fine.
[Bug c++/96003] [11 Regression] Maybe a false positive for -Werror=nonnull
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96003 Richard Biener changed: What|Removed |Added Target Milestone|--- |11.0
[Bug middle-end/95622] [11 Regression] force_output flag on a variable prevents optimization / regresses c-c++-common/goacc/kernels-alias-ipa-pta{-2,-4,}.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95622 Richard Biener changed: What|Removed |Added Version|10.0|11.0 Target Milestone|--- |11.0 --- Comment #6 from Richard Biener --- not sure if fixed?
[Bug c++/96106] [10/11 Regression] A friend abbreviated template function denies access to private members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96106 Richard Biener changed: What|Removed |Added Target Milestone|--- |10.2
[Bug tree-optimization/96058] [10/11 Regression] ICE in c_getstr at gcc/fold-const.c:15475
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96058 Richard Biener changed: What|Removed |Added Known to fail||10.1.0 Target Milestone|--- |10.2 Priority|P3 |P2
[Bug ipa/95859] [10/11 regression] Statically true asserts not recognized as such with -O2, but with -O1, -Og, -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95859 Richard Biener changed: What|Removed |Added Status|WAITING |NEW Known to work||9.3.0 Target Milestone|--- |10.2
[Bug tree-optimization/94969] [8/10 Regression] Invalid loop distribution since r8-2390-gdfbddbeb1ca912c9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94969 Richard Biener changed: What|Removed |Added Known to fail||8.4.0 Status|ASSIGNED|RESOLVED Known to work||10.1.1, 8.4.1 Resolution|--- |FIXED --- Comment #19 from Richard Biener --- Fixed.
[Bug target/96189] Failure to use eflags from cmpxchg on x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96189 Uroš Bizjak changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2020-07-15 Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |ubizjak at gmail dot com --- Comment #2 from Uroš Bizjak --- Created attachment 48877 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48877=edit Prototype patch Introduce peephole2 pattern that removes the comparison in certain cases. Doubleword cmpxchg is not handled, the doubleword comparison sequence is just too complicated in this late stage of compilation.
[Bug c++/96199] [10/11 Regression] internal compiler error: in tsubst_copy with CTAD for alias templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96199 Richard Biener changed: What|Removed |Added Known to fail||10.1.0 Version|unknown |10.1.0 Priority|P3 |P2
[Bug c++/96197] Excess memory consumption, positive correlation with the size of a constexpr array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96197
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Last reconfirmed||2020-07-15
Known to fail||10.1.0, 11.0
Keywords||memory-hog
--- Comment #1 from Richard Biener ---
Does it help if you replace your simplistic O(n) algorithms with O(log n) ones?
That is,
constexpr const struct word_type _LOOKUP(WORD index, const struct
word_type *table_row =word_table) {
for (;;) {
if (table_row->index == index) return *table_row;
if (table_row->index == WORD::NONE) return word_lookup(WORD::NONE);
++table_row;
}
//return table_row->index == index ? *table_row : (table_row->index ==
WORD::NONE ? word_lookup(WORD::NONE) : WORD_LOOKUP(index, ++table_row));
}
replace the for (;;) loop with table_row[index] (OK, that's maybe too much
guessing into your data structure) or with a binary search over the table
which you keep sorted?
It's probably simply garbage that accumulates during constexpr evaluation.
-ftime-report shows
constant expression evaluation : 28.45 ( 92%) 1.57 ( 96%) 32.97 ( 92%)
5127882 kB (100%)
that is 5GB of GC memory from constexpr evaluation.
[Bug middle-end/96200] Implement __builtin_thread_pointer() and __builtin_set_thread_pointer() if TLS is supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96200 Florian Weimer changed: What|Removed |Added CC||fw at gcc dot gnu.org --- Comment #1 from Florian Weimer --- __builtin_set_thread_pointer has little value from a glibc perspective because when used in application code, it will always result in undefined behavior.
