[Bug fortran/96216] Gap in interface checking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96216 Thomas Koenig changed: What|Removed |Added Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2020-07-16
[Bug fortran/96216] New: Gap in interface checking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96216 Bug ID: 96216 Summary: Gap in interface checking Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: tkoenig at gcc dot gnu.org Target Milestone: --- The following is not flagged: DOUBLE PRECISION X (1000) DOUBLE PRECISION A INTEGER NCP NCP = 10 CALL XYZ (NCP, X, X (NCP + 1)) CALL XYZ (NCP, X (NCP+1) , X) CALL XYZ (NCP, X (NCP+1) , A) END The second call is not compatible with the third one, and should be flagged.
[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 "=&d"))] + "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[] = {&args...}; > 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[] = {&args...}; 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&action=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&action=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 : noun_table) { indices[static_cast(noun.index)] = &noun; } } const noun_type *indices[1024]; } NOUN_INDEX_TABLE; constexpr const struct noun_type &NOUN(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