[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&action=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 &WORD_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.
[Bug target/96201] x86 movsd/movsq string instructions and alignment inference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96201 Hongtao.liu changed: What|Removed |Added CC||crazylht at gmail dot com --- Comment #1 from Hongtao.liu --- The issue is caused by pass_ivopt, ivopt select only one iv for f3(dn) which seems not to be optimal, and select two iv for f4(sn,dn) which seems optimal. --- loop in f3: Selected IV set for loop 1 at pr96201.c:25, 10 avg niters, 1 IVs: Candidate 8: Var befor: dn_24 Var after: dn_18 Incr POS: orig biv IV struct: Type: int * Base: (int *) _3 Step: 4 Biv:N Overflowness wrto loop niter: Overflow loop in f4: Selected IV set for loop 1 at pr96201.c:34, 10 avg niters, 2 IVs: Candidate 6: Var befor: sn_26 Var after: sn_20 Incr POS: orig biv IV struct: Type: int * Base: sn_14 Step: 4 Object: (void *) sn_14 Biv:N Overflowness wrto loop niter: Overflow Candidate 8: Var befor: dn_27 Var after: dn_21 Incr POS: orig biv IV struct: Type: int * Base: dn_16 Step: 4 Object: (void *) dn_16 Biv:N Overflowness wrto loop niter: Overflow --- then it generate more instructions for f3 which pass_combine failed to combine them. --- loop in f3: Trying 19 -> 22: 19: r83:DI=r92:DI 22: [r83:DI]=r89:SI REG_DEAD r89:SI REG_DEAD r83:DI Can't combine i2 into i3 Trying 21 -> 22: 21: r89:SI=[r93:DI] REG_DEAD r93:DI 22: [r83:DI]=r89:SI REG_DEAD r89:SI REG_DEAD r83:DI Failed to match this instruction: (set (mem:SI (reg/v/f:DI 83 [ dn ]) [1 *dn_2+0 S4 A32]) (mem:SI (reg/f:DI 93 [ _20 ]) [1 *_20+0 S4 A32])) Trying 18, 21 -> 22: 18: {r93:DI=r92:DI+r102:DI;clobber flags:CC;} REG_UNUSED flags:CC 21: r89:SI=[r93:DI] REG_DEAD r93:DI 22: [r83:DI]=r89:SI REG_DEAD r89:SI REG_DEAD r83:DI Can't combine i1 into i3 Trying 21, 19 -> 22: 21: r89:SI=[r93:DI] REG_DEAD r93:DI 19: r83:DI=r92:DI 22: [r83:DI]=r89:SI REG_DEAD r89:SI REG_DEAD r83:DI Can't combine i1 into i3 (insn 18 16 19 4 (parallel [ (set (reg/f:DI 93 [ _20 ]) (plus:DI (reg/v/f:DI 92 [ dn ]) (reg:DI 102))) (clobber (reg:CC 17 flags)) ]) 210 {*adddi_1} (expr_list:REG_UNUSED (reg:CC 17 flags) (nil))) (insn 19 18 20 4 (set (reg/v/f:DI 83 [ dn ]) (reg/v/f:DI 92 [ dn ])) 74 {*movdi_internal} (nil)) (insn 20 19 21 4 (parallel [ (set (reg/v/f:DI 92 [ dn ]) (plus:DI (reg/v/f:DI 92 [ dn ]) (const_int 4 [0x4]))) (clobber (reg:CC 17 flags)) ]) "pr96201.c":25:24 210 {*adddi_1} (expr_list:REG_UNUSED (reg:CC 17 flags) (nil))) (insn 21 20 22 4 (set (reg:SI 89 [ _9 ]) (mem:SI (reg/f:DI 93 [ _20 ]) [1 *_20+0 S4 A32])) "pr96201.c":25:29 75 {*movsi_internal} (expr_list:REG_DEAD (reg/f:DI 93 [ _20 ]) (nil))) (insn 22 21 24 4 (set (mem:SI (reg/v/f:DI 83 [ dn ]) [1 *dn_2+0 S4 A32]) (reg:SI 89 [ _9 ])) "pr96201.c":25:27 75 {*movsi_internal} (expr_list:REG_DEAD (reg:SI 89 [ _9 ]) (expr_list:REG_DEAD (reg/v/f:DI 83 [ dn ]) (nil loop in f4: Trying 16, 18, 17 -> 19: 16: {r89:DI=r89:DI+0x4;clobber flags:CC;} REG_UNUSED flags:CC 18: r88:SI=[r89:DI-0x4] 17: {r90:DI=r90:DI+0x4;clobber flags:CC;} REG_UNUSED flags:CC 19: [r90:DI-0x4]=r88:SI REG_DEAD r88:SI Successfully matched this instruction: (parallel [ (set (mem:SI (reg/v/f:DI 90 [ dn ]) [1 MEM[base: dn_21, offset: -4B]+0 S4 A32]) (mem:SI (reg/v/f:DI 89 [ sn ]) [1 MEM[base: sn_20, offset: -4B]+0 S4 A32])) (set (reg/v/f:DI 90 [ dn ]) (plus:DI (reg/v/f:DI 90 [ dn ]) (const_int 4 [0x4]))) (set (reg/v/f:DI 89 [ sn ]) (plus:DI (reg/v/f:DI 89 [ sn ]) (const_int 4 [0x4]))) ]) (insn 16 15 17 3 (parallel [ (set (reg/v/f:DI 89 [ sn ]) (plus:DI (reg/v/f:DI 89 [ sn ]) (const_int 4 [0x4]))) (clobber (reg:CC 17 flags)) ]) "pr96201.c":34:32 210 {*adddi_1} (expr_list:REG_UNUSED (reg:CC 17 flags) (nil))) (insn 17 16 18 3 (parallel [ (set (reg/v/f:DI 90 [ dn ]) (plus:DI (reg/v/f:DI 90 [ dn ]) (const_int 4 [0x4]))) (clobber (reg:CC 17 flags)) ]) "pr96201.c":34:24 210 {*adddi_1} (expr_list:REG_UNUSED (reg:CC 17 flags) (nil))) (insn 18 17 19 3 (set (reg:SI 88 [ _9 ]) (mem:SI (plus:DI (reg/v/f:DI 89 [ sn ]) (const_int -4 [0xfffc])) [1 MEM[base: sn_20, offset: -4B]+0 S4 A32])) "pr96201.c":34:29 75 {*movsi_internal} (nil))
[Bug tree-optimization/96195] aarch64: ICE during GIMPLE pass:vect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96195 --- Comment #2 from yangyang --- (In reply to Jakub Jelinek from comment #1) > Note the testcase is invalid, the loop iterator really shouldn't be changed > in the simd body (well, can change, but only if it has the same value at the > end of loop body as it has at the start of it). The testcase comes from gcc/testsuite/gcc.dg/vect/pr92347.c. > What are the different modes? vector(4) int and vector(4) int really look > the same to me... In the testcase, One of vector(4) int corresponds to VNx2SI (aarch64_sve_mode) and the other corresponds to V4SI.
[Bug target/92488] GCC generates calls to __dpd_trunctdsd2 with -mhard-dfp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92488 --- Comment #3 from Peter Bergner --- (In reply to Segher Boessenkool from comment #2) > Doing everything but the final conversion down in round-to-odd mode works > correctly always. It's magic :-) Ok, so Paul's sequence is what we want and we don't need anything for the other cases I mentioned since they're not double casting. Thanks.
[Bug target/96201] New: x86 movsd/movsq string instructions and alignment inference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96201 Bug ID: 96201 Summary: x86 movsd/movsq string instructions and alignment inference Product: gcc Version: 10.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: michaeljclark at mac dot com Target Milestone: --- Taking the time to record some observations and extract minimal test code for alignment (inference) and x86 string instruction selection. GCC9 and GCC10 are not generating x86 string instructions in cases apparently due to the compiler believing the addresses are not aligned. GCC10 appears to have an additional issue whereby x86 string instructions are not selected unless the address is aligned to twice the natural alignment. Two observations: * (GCC9/10) integer alignment is not inferred from expressions i.e. x & ~3 * (GCC10) __builtin_assume_aligned appears to require double the alignment The double alignment issue was observed with both int/movsd and long/movsq whereby GCC10 will only generate movsd or movsq if the alignment is double the type's natural alignment. The test case here is for int. --- BEGIN SAMPLE CODE --- void f1(long d, long s, unsigned n) { int *sn = (int*)( (long)(s) & ~3l ); int *dn = (int*)( (long)(d) & ~3l ); int *de = (int*)( (long)(d + n) & ~3l ); while (dn < de) *dn++ = *sn++; } void f2(long d, long s, unsigned n) { int *sn = (int*)( (long)(s) & ~7l ); int *dn = (int*)( (long)(d) & ~7l ); int *de = (int*)( (long)(d + n) & ~7l ); while (dn < de) *dn++ = *sn++; } void f3(long d, long s, unsigned n) { int *sn = __builtin_assume_aligned( (int*)( (long)(s) & ~3l ), 4 ); int *dn = __builtin_assume_aligned( (int*)( (long)(d) & ~3l ), 4 ); int *de = __builtin_assume_aligned( (int*)( (long)(d + n) & ~3l ), 4 ); while (dn < de) *dn++ = *sn++; } void f4(long d, long s, unsigned n) { int *sn = __builtin_assume_aligned( (int*)((long)(s) & ~3l ), 8 ); int *dn = __builtin_assume_aligned( (int*)((long)(d) & ~3l ), 8 ); int *de = __builtin_assume_aligned( (int*)((long)(d + n) & ~3l ), 8 ); while (dn < de) *dn++ = *sn++; } --- END SAMPLE CODE --- GCC9 generates this for f1, f2 and GCC10 generates this for f1, f2, f3 .Ln: leaq(%rax,%rsi), %rcx movq%rax, %rdx addq$4, %rax movl(%rcx), %ecx movl%ecx, (%rdx) cmpq%rax, %rdi ja .Ln GCC9 generates this for f3, f4 and GCC10 generates this only for f4 .Ln: movsl cmpq%rdi, %rdx ja .Ln
[Bug c++/95677] undefined reference to `(anonymous namespace)::xx'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95677 --- Comment #8 from liusujian --- (In reply to Nathan Sidwell from comment #6) > Ah, anonymous namespaces have internal linkage (and a program-wide unique > identifier). Their contents have the linkage they have. but because > they're within the anonumous namespace they cannot be named from elsewhere, > so they have internal linkage for implementation purposes. > > when we actually gave anonymous namespaces there would be no collisions > between TUs for '::x'. Now we give it a specific name and adjust the > linkages of their contents. > > The C++ FE should adjust the linkage of '::x' too. Hello, has there been any progress regarding the repair of this issue now?
[Bug target/87949] PowerPC saves CR registers across calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87949 Segher Boessenkool changed: What|Removed |Added Status|ASSIGNED|NEW --- Comment #14 from Segher Boessenkool --- The target hook (macro) works just fine, and it results in code that saves and restores CR fields significantly less often. Unfortunately the resulting code is lower performance, too. Not as bad as when you completely disable the non-volatile CR fields, but still pretty bad. Unassigning myself.
[Bug target/92488] GCC generates calls to __dpd_trunctdsd2 with -mhard-dfp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92488 Segher Boessenkool changed: What|Removed |Added Status|WAITING |NEW --- Comment #2 from Segher Boessenkool --- If you first round the DFP extended to DFP long and then to DFP short, it can round in the same direction twice, giving the wrong result (say, for round-to-nearest-even, you can end up with something more than 0.5ulp from what you started with). Doing everything but the final conversion down in round-to-odd mode works correctly always. It's magic :-)
[Bug c++/95789] [10/11 Regression] Const method is allowed to return non-const reference on template class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95789 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from Marek Polacek --- Fixed for 11/10.2.
[Bug c++/96104] [10/11 Regression] internal compiler error: in finish_expr_stmt, at cp/semantics.c:681
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96104 --- Comment #5 from CVS Commits --- The releases/gcc-10 branch has been updated by Marek Polacek : https://gcc.gnu.org/g:315b87f63bcde4c881e9963c39d57258da08ccb5 commit r10-8497-g315b87f63bcde4c881e9963c39d57258da08ccb5 Author: Marek Polacek Date: Mon Jun 22 21:26:49 2020 -0400 c++: Make convert_like complain about bad ck_ref_bind again [PR95789] convert_like issues errors about bad_p conversions at the beginning of the function, but in the ck_ref_bind case, it only issues them after we've called convert_like on the next conversion. This doesn't work as expected since r10-7096 because when we see a conversion from/to class type in a template, we return early, thereby missing the error, and a bad_p conversion goes by undetected. That made the attached test to compile even though it should not. I had thought that I could just move the ck_ref_bind/bad_p errors above to the rest of them, but that regressed diagnostics because expr then wasn't converted yet by the nested convert_like_real call. So, for bad_p conversions, do the normal processing, but still return the IMPLICIT_CONV_EXPR to avoid introducing trees that the template processing can't handle well. This I achieved by adding a wrapper function. gcc/cp/ChangeLog: PR c++/95789 PR c++/96104 PR c++/96179 * call.c (convert_like_real_1): Renamed from convert_like_real. (convert_like_real): New wrapper for convert_like_real_1. gcc/testsuite/ChangeLog: PR c++/95789 PR c++/96104 PR c++/96179 * g++.dg/conversion/ref4.C: New test. * g++.dg/conversion/ref5.C: New test. * g++.dg/conversion/ref6.C: New test. (cherry picked from commit 8e64d182850560dbedfabb88aac90d4fc6155067)
[Bug c++/96179] [10/11 Regression] g++-10.1 silently doesn't push_back the return of a void function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96179 --- Comment #4 from CVS Commits --- The releases/gcc-10 branch has been updated by Marek Polacek : https://gcc.gnu.org/g:315b87f63bcde4c881e9963c39d57258da08ccb5 commit r10-8497-g315b87f63bcde4c881e9963c39d57258da08ccb5 Author: Marek Polacek Date: Mon Jun 22 21:26:49 2020 -0400 c++: Make convert_like complain about bad ck_ref_bind again [PR95789] convert_like issues errors about bad_p conversions at the beginning of the function, but in the ck_ref_bind case, it only issues them after we've called convert_like on the next conversion. This doesn't work as expected since r10-7096 because when we see a conversion from/to class type in a template, we return early, thereby missing the error, and a bad_p conversion goes by undetected. That made the attached test to compile even though it should not. I had thought that I could just move the ck_ref_bind/bad_p errors above to the rest of them, but that regressed diagnostics because expr then wasn't converted yet by the nested convert_like_real call. So, for bad_p conversions, do the normal processing, but still return the IMPLICIT_CONV_EXPR to avoid introducing trees that the template processing can't handle well. This I achieved by adding a wrapper function. gcc/cp/ChangeLog: PR c++/95789 PR c++/96104 PR c++/96179 * call.c (convert_like_real_1): Renamed from convert_like_real. (convert_like_real): New wrapper for convert_like_real_1. gcc/testsuite/ChangeLog: PR c++/95789 PR c++/96104 PR c++/96179 * g++.dg/conversion/ref4.C: New test. * g++.dg/conversion/ref5.C: New test. * g++.dg/conversion/ref6.C: New test. (cherry picked from commit 8e64d182850560dbedfabb88aac90d4fc6155067)
[Bug c++/95789] [10/11 Regression] Const method is allowed to return non-const reference on template class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95789 --- Comment #9 from CVS Commits --- The releases/gcc-10 branch has been updated by Marek Polacek : https://gcc.gnu.org/g:315b87f63bcde4c881e9963c39d57258da08ccb5 commit r10-8497-g315b87f63bcde4c881e9963c39d57258da08ccb5 Author: Marek Polacek Date: Mon Jun 22 21:26:49 2020 -0400 c++: Make convert_like complain about bad ck_ref_bind again [PR95789] convert_like issues errors about bad_p conversions at the beginning of the function, but in the ck_ref_bind case, it only issues them after we've called convert_like on the next conversion. This doesn't work as expected since r10-7096 because when we see a conversion from/to class type in a template, we return early, thereby missing the error, and a bad_p conversion goes by undetected. That made the attached test to compile even though it should not. I had thought that I could just move the ck_ref_bind/bad_p errors above to the rest of them, but that regressed diagnostics because expr then wasn't converted yet by the nested convert_like_real call. So, for bad_p conversions, do the normal processing, but still return the IMPLICIT_CONV_EXPR to avoid introducing trees that the template processing can't handle well. This I achieved by adding a wrapper function. gcc/cp/ChangeLog: PR c++/95789 PR c++/96104 PR c++/96179 * call.c (convert_like_real_1): Renamed from convert_like_real. (convert_like_real): New wrapper for convert_like_real_1. gcc/testsuite/ChangeLog: PR c++/95789 PR c++/96104 PR c++/96179 * g++.dg/conversion/ref4.C: New test. * g++.dg/conversion/ref5.C: New test. * g++.dg/conversion/ref6.C: New test. (cherry picked from commit 8e64d182850560dbedfabb88aac90d4fc6155067)
[Bug target/94393] Powerpc suboptimal 64-bit constant comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94393 --- Comment #6 from Segher Boessenkool --- It certainly would be nice to improve this :-) It won't help most code very much -- how often do two-word values happen at all -- but we have to revisit how all this is decided anyway (for prefixed instructions), so now would be a good time :-)
[Bug target/96191] aarch64 stack_protect_test canary leak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96191 --- Comment #3 from Jim Wilson --- The location of the canary is not known to the attacker. You are not supposed to leak the address of the canary or the value of the canary. If you leak either, then an attacker has a chance to restore the canary after clobbering it. See the descriptions of the stack_protect_set and stack_protect_test patterns in gcc/doc/md.texi which make clear that no intermediate values should be allowed to survive past the end of the pattern.
[Bug tree-optimization/81809] missing -Wuninitialized due to alias analysis limitation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81809 Martin Sebor changed: What|Removed |Added Known to fail||10.1.0, 11.0, 8.2.0, 9.2.0 --- Comment #4 from Martin Sebor --- Another test case for the same underlying bug. $ cat z.c && gcc -O2 -S -Wall z.c void f (const int*, const int*); void g (void) { int a = 0, b; f (&a, &b); } void h (void) { int a = 0, b; f (&a, 0); f (&b, 0); } z.c: In function ‘g’: z.c:6:3: warning: ‘b’ may be used uninitialized [-Wmaybe-uninitialized] 6 | f (&a, &b); | ^~ z.c:1:6: note: by argument 2 of type ‘const int *’ to ‘f’ declared here 1 | void f (const int*, const int*); | ^ z.c:5:14: note: ‘b’ declared here 5 | int a = 0, b; | ^
[Bug c++/59978] C++11 Non-Type-Template-Parameter Pack Expansion not working according to standard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59978 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Marek Polacek --- Done.
[Bug c++/59978] C++11 Non-Type-Template-Parameter Pack Expansion not working according to standard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59978 --- Comment #3 from CVS Commits --- The master branch has been updated by Marek Polacek : https://gcc.gnu.org/g:4358099049cbb8180c5354c6754b04ff0b330835 commit r11-2099-g4358099049cbb8180c5354c6754b04ff0b330835 Author: Marek Polacek Date: Tue Jul 14 17:31:08 2020 -0400 c++: Add new test [PR59978] Fixed in r224162. That came without a test so adding this one. Previously, we issued a bogus "too few arguments to function" error. gcc/testsuite/ChangeLog: PR c++/59978 * g++.dg/cpp0x/vt-59978.C: New test.
[Bug middle-end/96200] New: Implement __builtin_thread_pointer() and __builtin_set_thread_pointer() if TLS is supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96200 Bug ID: 96200 Summary: Implement __builtin_thread_pointer() and __builtin_set_thread_pointer() if TLS is supported Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: carlos at redhat dot com Target Milestone: --- In glibc we implement the equivalent of __builtin_thread_pointer() and __builtin_set_thread_pointer() to access data that is at a constant offset from the thread pointer. For many of the architectures that have the builtins their tls.h implementation in glibc is greatly simplified because they can use the builtin. We have some ABIs that are defined as having data of a certain size and alignment at a fixed offset from the thread pointer e.g. stack_guard, pointer_guard, TM ABI, __private_ss (split stack) etc. In relation to restartable sequences in the linux kernel it was discussed that it might be interesting to have an ABI that also uses TP + offset, where glibc provides the "offset" via an API, but the user is left to do the "TP + offset" calculation on their own. https://lore.kernel.org/linux-api/2452161.11491.1594732791558.javamail.zim...@efficios.com/ "Is there an arch-agnostic way to get the thread pointer from user-space code ? That would be needed by all rseq critical section implementations." We should support these two builtins for all targets that support TLS.
[Bug fortran/89574] [8/9/10/11 Regression] internal compiler error: in conv_function_val, at fortran/trans-expr.c:3792
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89574 --- Comment #10 from anlauf at gcc dot gnu.org --- Patch: https://gcc.gnu.org/pipermail/fortran/2020-July/054744.html
[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 --- Comment #2 from Marek Polacek --- We're reaching tsubst_copy/CONST_DECL: /* We didn't find the name. That should never happen; if name-lookup found it during preliminary parsing, we should find it again here during instantiation. */ gcc_unreachable ();
[Bug fortran/89574] [8/9/10/11 Regression] internal compiler error: in conv_function_val, at fortran/trans-expr.c:3792
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89574 anlauf at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #9 from anlauf at gcc dot gnu.org --- Line 2095 should never return a match for a symbol from a different module. I have a patch that regtests cleanly.
[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 Marek Polacek changed: What|Removed |Added Summary|internal compiler error: in |[10/11 Regression] internal |tsubst_copy with CTAD for |compiler error: in |alias templates |tsubst_copy with CTAD for ||alias templates Target Milestone|--- |10.2 --- Comment #1 from Marek Polacek --- Started with r278786.
[Bug target/95443] cmpstrnqi patterns update string length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95443 H.J. Lu changed: What|Removed |Added Resolution|--- |FIXED Status|REOPENED|RESOLVED --- Comment #5 from H.J. Lu --- Fixed.
[Bug target/95151] [9/10/11 Regression] Add cmpmemM pattern for -minline-all-stringops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95151 Bug 95151 depends on bug 95443, which changed state. Bug 95443 Summary: cmpstrnqi patterns update string length https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95443 What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED
[Bug c++/96199] New: internal compiler error: in tsubst_copy with CTAD for alias templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96199 Bug ID: 96199 Summary: internal compiler error: in tsubst_copy with CTAD for alias templates Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: mpolacek at gcc dot gnu.org Target Milestone: --- template class A; template struct W { }; template class B { enum { X }; B(A) { } template using U = B; W u; }; $ ./cc1plus -quiet q.C q.C:5:3: internal compiler error: in tsubst_copy, at cp/pt.c:16379 5 | B(A) { } | ^ 0xbf58f3 tsubst_copy /home/mpolacek/src/gcc/gcc/cp/pt.c:16379 0xc0d363 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool, bool) /home/mpolacek/src/gcc/gcc/cp/pt.c:20496 0xc04ffc tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool) /home/mpolacek/src/gcc/gcc/cp/pt.c:18783 0xbdfd4f tsubst_template_arg(tree_node*, tree_node*, int, tree_node*) /home/mpolacek/src/gcc/gcc/cp/pt.c:12116 0xbe3b45 tsubst_template_args(tree_node*, tree_node*, int, tree_node*) /home/mpolacek/src/gcc/gcc/cp/pt.c:13169 0xbe48d5 tsubst_aggr_type /home/mpolacek/src/gcc/gcc/cp/pt.c:13372 0xbf1239 tsubst(tree_node*, tree_node*, int, tree_node*) /home/mpolacek/src/gcc/gcc/cp/pt.c:15267 0xbef7bc tsubst_arg_types /home/mpolacek/src/gcc/gcc/cp/pt.c:14802 0xbefdce tsubst_function_type /home/mpolacek/src/gcc/gcc/cp/pt.c:14943 0xbf2f58 tsubst(tree_node*, tree_node*, int, tree_node*) /home/mpolacek/src/gcc/gcc/cp/pt.c:15720 0xbe7642 tsubst_function_decl /home/mpolacek/src/gcc/gcc/cp/pt.c:13757 0xbec51f tsubst_decl /home/mpolacek/src/gcc/gcc/cp/pt.c:14199 0xc2fd83 alias_ctad_tweaks /home/mpolacek/src/gcc/gcc/cp/pt.c:28562 0xc30867 deduction_guides_for /home/mpolacek/src/gcc/gcc/cp/pt.c:28703 0xc31104 do_class_deduction /home/mpolacek/src/gcc/gcc/cp/pt.c:28808 0xc31d4c do_auto_deduction(tree_node*, tree_node*, tree_node*, int, auto_deduction_context, tree_node*, int) /home/mpolacek/src/gcc/gcc/cp/pt.c:28937 0xce14ca build_functional_cast_1 /home/mpolacek/src/gcc/gcc/cp/typeck2.c:2313 0xce1919 build_functional_cast(unsigned int, tree_node*, tree_node*, int) /home/mpolacek/src/gcc/gcc/cp/typeck2.c:2413 0xb744e9 cp_parser_functional_cast /home/mpolacek/src/gcc/gcc/cp/parser.c:29671 0xb46a8e cp_parser_postfix_expression /home/mpolacek/src/gcc/gcc/cp/parser.c:7212
[Bug target/95443] cmpstrnqi patterns update string length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95443 --- Comment #4 from CVS Commits --- The master branch has been updated by H.J. Lu : https://gcc.gnu.org/g:b2984e5ada65f417e8704d2e1e81ccd0272b5eb3 commit r11-2098-gb2984e5ada65f417e8704d2e1e81ccd0272b5eb3 Author: H.J. Lu Date: Tue Jul 14 14:01:51 2020 -0700 x86: Replace __glibc_unlikely with __builtin_expect Replace glibc specific __glibc_unlikely with __builtin_expect. PR target/95443 * gcc.target/i386/pr95443-1.c (simple_strstr): Replace __glibc_unlikely with __builtin_expect.
[Bug c++/95434] ICE for CTAD in generic lambda within variadic lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95434 Patrick Palka changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2020-07-14 CC||ppalka at gcc dot gnu.org --- Comment #2 from Patrick Palka --- Confirmed. Fails on trunk, too.
[Bug libstdc++/89417] helgrind detects a lock order violation inside std::scoped_lock
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89417 --- Comment #3 from Federico Kircheis --- Thank you for the analysis, explanation and references, I did not think about testing std::lock directly. I'm still unsure if that means that it is a bug in valgrind, unfortunately I do not know other 3rd party tool for doing such verifications. I also noticed that I made an error in my initial report, the second snippet should have been - int main(){ std::mutex m1; std::mutex m2; int data1{}; int data2{}; auto f1 = std::async(std::launch::async, [&](){ std::lock_guard lg1{m1};std::lock_guard lg2{m2}; ++data1; ++data2; return data1; }); auto f2 = std::async(std::launch::async, [&](){ std::lock_guard lg2{m2};std::lock_guard lg1{m1}; ++data1; ++data2; return data2; }); return f1.get() + f2.get(); // result should be 3 } - otherwise it does not generate any warning in valgrind as the order is the same. > Also, I'm not even sure what the helgrind error really means. >From helgrind manual: https://www.valgrind.org/docs/manual/hg-manual.html Helgrind monitors the order in which threads acquire locks. This allows it to detect potential deadlocks which could arise from the formation of cycles of locks. Detecting such inconsistencies is useful because, whilst actual deadlocks are fairly obvious, potential deadlocks may never be discovered during testing and could later lead to hard-to-diagnose in-service failures. > Just because they were locked in one order at one time doesn't establish an > invariant that they must always be locked in that order elsewhere in the > program. I'm not an expert, I've just made the report because I've tried out valgrind on a bigger program and then noticed it also complained about this example. In order to avoid deadlocks, shouldn't mutexes get always locked in the same order? Otherwise thread1 locks the first mutex, then thread2 locks the second, and now both thread are waiting for locking the next. 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. And I suppose that somehow this algorithm also manages to avoid livelocks. But even if std::lock would be correct (and it is a false positive of valgrind), wouldn't sorting by address be an optimization? As far as I understand, if the mutexes are always locked in the same order, one does not need to try_lock. If it does, it would at least avoid the dance of both threads trying to lock and unlock, as the first one that arrives manages to lock both. And if someone else locked them somewhere else in a different order, then the current algorithm still applies. 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. Maybe there are known drawbacks to sorting by address, but as mutexes cannot be moved, the output of sorting should always be the same, and I suppose that sorting should not cost much, especially compared to locking.
[Bug c++/95789] [10/11 Regression] Const method is allowed to return non-const reference on template class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95789 --- Comment #8 from CVS Commits --- The master branch has been updated by Marek Polacek : https://gcc.gnu.org/g:8e64d182850560dbedfabb88aac90d4fc6155067 commit r11-2097-g8e64d182850560dbedfabb88aac90d4fc6155067 Author: Marek Polacek Date: Mon Jun 22 21:26:49 2020 -0400 c++: Make convert_like complain about bad ck_ref_bind again [PR95789] convert_like issues errors about bad_p conversions at the beginning of the function, but in the ck_ref_bind case, it only issues them after we've called convert_like on the next conversion. This doesn't work as expected since r10-7096 because when we see a conversion from/to class type in a template, we return early, thereby missing the error, and a bad_p conversion goes by undetected. That made the attached test to compile even though it should not. I had thought that I could just move the ck_ref_bind/bad_p errors above to the rest of them, but that regressed diagnostics because expr then wasn't converted yet by the nested convert_like_real call. So, for bad_p conversions, do the normal processing, but still return the IMPLICIT_CONV_EXPR to avoid introducing trees that the template processing can't handle well. This I achieved by adding a wrapper function. gcc/cp/ChangeLog: PR c++/95789 PR c++/96104 PR c++/96179 * call.c (convert_like_real_1): Renamed from convert_like_real. (convert_like_real): New wrapper for convert_like_real_1. gcc/testsuite/ChangeLog: PR c++/95789 PR c++/96104 PR c++/96179 * g++.dg/conversion/ref4.C: New test. * g++.dg/conversion/ref5.C: New test. * g++.dg/conversion/ref6.C: New test.
[Bug c++/96179] [10/11 Regression] g++-10.1 silently doesn't push_back the return of a void function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96179 --- Comment #3 from CVS Commits --- The master branch has been updated by Marek Polacek : https://gcc.gnu.org/g:8e64d182850560dbedfabb88aac90d4fc6155067 commit r11-2097-g8e64d182850560dbedfabb88aac90d4fc6155067 Author: Marek Polacek Date: Mon Jun 22 21:26:49 2020 -0400 c++: Make convert_like complain about bad ck_ref_bind again [PR95789] convert_like issues errors about bad_p conversions at the beginning of the function, but in the ck_ref_bind case, it only issues them after we've called convert_like on the next conversion. This doesn't work as expected since r10-7096 because when we see a conversion from/to class type in a template, we return early, thereby missing the error, and a bad_p conversion goes by undetected. That made the attached test to compile even though it should not. I had thought that I could just move the ck_ref_bind/bad_p errors above to the rest of them, but that regressed diagnostics because expr then wasn't converted yet by the nested convert_like_real call. So, for bad_p conversions, do the normal processing, but still return the IMPLICIT_CONV_EXPR to avoid introducing trees that the template processing can't handle well. This I achieved by adding a wrapper function. gcc/cp/ChangeLog: PR c++/95789 PR c++/96104 PR c++/96179 * call.c (convert_like_real_1): Renamed from convert_like_real. (convert_like_real): New wrapper for convert_like_real_1. gcc/testsuite/ChangeLog: PR c++/95789 PR c++/96104 PR c++/96179 * g++.dg/conversion/ref4.C: New test. * g++.dg/conversion/ref5.C: New test. * g++.dg/conversion/ref6.C: New test.
[Bug c++/96104] [10/11 Regression] internal compiler error: in finish_expr_stmt, at cp/semantics.c:681
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96104 --- Comment #4 from CVS Commits --- The master branch has been updated by Marek Polacek : https://gcc.gnu.org/g:8e64d182850560dbedfabb88aac90d4fc6155067 commit r11-2097-g8e64d182850560dbedfabb88aac90d4fc6155067 Author: Marek Polacek Date: Mon Jun 22 21:26:49 2020 -0400 c++: Make convert_like complain about bad ck_ref_bind again [PR95789] convert_like issues errors about bad_p conversions at the beginning of the function, but in the ck_ref_bind case, it only issues them after we've called convert_like on the next conversion. This doesn't work as expected since r10-7096 because when we see a conversion from/to class type in a template, we return early, thereby missing the error, and a bad_p conversion goes by undetected. That made the attached test to compile even though it should not. I had thought that I could just move the ck_ref_bind/bad_p errors above to the rest of them, but that regressed diagnostics because expr then wasn't converted yet by the nested convert_like_real call. So, for bad_p conversions, do the normal processing, but still return the IMPLICIT_CONV_EXPR to avoid introducing trees that the template processing can't handle well. This I achieved by adding a wrapper function. gcc/cp/ChangeLog: PR c++/95789 PR c++/96104 PR c++/96179 * call.c (convert_like_real_1): Renamed from convert_like_real. (convert_like_real): New wrapper for convert_like_real_1. gcc/testsuite/ChangeLog: PR c++/95789 PR c++/96104 PR c++/96179 * g++.dg/conversion/ref4.C: New test. * g++.dg/conversion/ref5.C: New test. * g++.dg/conversion/ref6.C: New test.
[Bug c++/88475] -E -fdirectives-only clashes with raw strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88475 Ryan Egesdahl changed: What|Removed |Added CC||ryan.egesdahl at mongodb dot com --- Comment #6 from Ryan Egesdahl --- The actual bug here appears to be the fact that "gcc -E" (which I believe invokes "cpp"?) has different behavior than the integrated preprocessor. If you compile the code in the initial report with just "gcc", it works irrespective of passing "-fdirectives-only" to the compiler. A different way of demonstrating the problem looks like this: test.cpp: #define expand(x) x #define test(...) \ expand(_test_2(__VA_ARGS__)) #define _test_2(Expression) \ doSomething((Expression)) template inline bool doSomething( const T& testOK) { if (!testOK) { return false; } return true; } int main() { bool condition = true; return test(!condition || condition == condition); } The above compiles correctly with this: $ g++ -Wall test.cpp -o test However, this fails: $ g++ -Wall -E test.cpp -o test.ii $ g++ -fpreprocessed -fdirectives-only -Wall -c test.ii -o test test.cpp: In function ‘int main()’: test.cpp:21:49: warning: self-comparison always evaluates to true [-Wtautological-compare] return test(!condition || condition == condition); As does this: $ g++ -fdirectives-only -Wall -c test.ii -o test $ g++ -fpreprocessed -Wall -c test.ii -o test test.cpp: In function ‘int main()’: test.cpp:21:41: warning: self-comparison always evaluates to true [-Wtautological-compare] return test(!condition || condition == condition); ~~^~~~ test.cpp:21:12: error: ‘test’ was not declared in this scope return test(!condition || condition == condition); ^~~~ I understand (from testing) that not passing -fdirectives-only is the actual cause of the behavior in my test case; however, it is not immediately obvious why passing -fdirectives-only should be necessary with both the compiler and preprocessor, nor does the documentation state so. The point is that the integrated compiler and "gcc -E" (or cpp) behave differently. Most build wrappers like ccache and icecc (when ICECC_REMOTE_CPP is enabled) work by taking a gcc command and splitting it into separate preprocessing and compilation steps, which involves adding -E to the flags for preprocessing and -c for compiling, then passing the preprocessing results to the compiler. Because "gcc -E" and the integrated compiler behave differently, some builds fail with separate preprocessing and compilation steps that otherwise would have succeeded with a single step. The lack of documentation around -fdirectives-only and that it must be passed to the compiler (and that it implies -fpreprocessed to the compiler, for that matter) is making the confusion worse. To resolve this report, GCC should not behave differently depending on how you preprocess source. My personal thought is that "gcc -E" should invoke the internal preprocessor and just stop before compiling. Also, the documentation for -fdirectives-only needs to be improved (and maybe added it to the compiler documentation?) to make clear that the option needs to be passed to the compiler as well, and that passing it to the compiler with no preprocessed source is effectively a no-op.
[Bug c++/94415] Implement DR 2237: Can a template-id name a constructor?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94415 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Marek Polacek --- Fixed in r11-532-g4b38d56dbac6742b038551a36ec80200313123a1.
[Bug c++/94404] [meta-bug] C++ core issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94404 Bug 94404 depends on bug 94415, which changed state. Bug 94415 Summary: Implement DR 2237: Can a template-id name a constructor? https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94415 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug target/95443] cmpstrnqi patterns update string length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95443 Rainer Orth changed: What|Removed |Added Last reconfirmed||2020-07-14 Status|RESOLVED|REOPENED Ever confirmed|0 |1 CC||ro at gcc dot gnu.org Resolution|FIXED |--- --- Comment #3 from Rainer Orth --- One of the new tests FAILs on Solaris/x86 (and most likely all non-glibc targets): +FAIL: gcc.target/i386/pr95443-1.c (test for excess errors) +UNRESOLVED: gcc.target/i386/pr95443-1.c compilation failed to produce executable Excess errors: /vol/gcc/src/hg/master/local/gcc/testsuite/gcc.target/i386/pr95443-1.c:52:11: warning: implicit declaration of function '__glibc_unlikely' [-Wimplicit-function-declaration] Undefined first referenced symbol in file __glibc_unlikely/var/tmp//ccMfX1cc.o ld: fatal: symbol referencing errors
[Bug target/95151] [9/10/11 Regression] Add cmpmemM pattern for -minline-all-stringops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95151 Bug 95151 depends on bug 95443, which changed state. Bug 95443 Summary: cmpstrnqi patterns update string length https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95443 What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |---
[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 #2 from Jakub Jelinek --- I think --- gcc/omp-general.c.jj2020-07-14 12:20:01.520110629 +0200 +++ gcc/omp-general.c 2020-07-14 20:54:48.104237522 +0200 @@ -726,7 +726,7 @@ omp_extract_for_data (gomp_for *for_stmt if (loop->m1 || loop->m2) { gcc_assert (single_nonrect != -1); - if (single_nonrect_cond_code == LT_EXPR) + if (1 || single_nonrect_cond_code == LT_EXPR) { n1 = n1first; n2 = n2first; @@ -764,7 +764,7 @@ omp_extract_for_data (gomp_for *for_stmt m1 = fold_convert (itype, m1); m2 = fold_convert (itype, m2); tree t2; - if (single_nonrect_cond_code == LT_EXPR) + if (1 || single_nonrect_cond_code == LT_EXPR) t2 = fold_build2 (MINUS_EXPR, itype, m2, m1); else t2 = fold_build2 (MINUS_EXPR, itype, m1, m2); should fix that, but need to go back to drawing board and see if that is how we want to handle those cases. That said at least for all the testcases in the testsuite it currently computes the right number of iterations at least.
[Bug target/96191] aarch64 stack_protect_test canary leak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96191 Wilco changed: What|Removed |Added CC||wilco at gcc dot gnu.org --- Comment #2 from Wilco --- (In reply to Jim Wilson from comment #0) > Given a simple testcase > extern int sub (int); > > int > main (void) > { > sub (10); > return 0; > } > commpiling with -O -S -fstack-protector-all -mstack-protector-guard=global > in the epilogue for the canary check I see > ldr x1, [sp, 40] > ldr x0, [x19, #:lo12:__stack_chk_guard] > eor x0, x1, x0 > cbnzx0, .L4 > Both x0 and x1 have the stack protector canary loaded into them, and the eor > clobbers x0, but x1 is left alone. This means the value of the canary is > leaking from the epilogue. The canary value is never supposed to survive in > a register outside the stack protector patterns. > > A powerpc64-linux toolchain build with the same testcase and options > generates > lwz 9,28(1) > lwz 10,0(31) > xor. 9,9,10 > li 10,0 > bne- 0,.L4 > and note that it clears the second register after the xor to prevent the > canary leak. The aarch64 stack_protect_test pattern should do the same > thing. The canary value is not a secret. What would the purpose of clearing the register be given the stack slot containing the canary is not cleared as well? And register could potentially contain the address of the canary or that of a global nearby, making reading the canary value really easy.
[Bug middle-end/95114] [9/10/11 Regression] ICE in obj_type_ref_class for structural-equality types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95114 --- Comment #3 from CVS Commits --- The releases/gcc-10 branch has been updated by Richard Sandiford : https://gcc.gnu.org/g:74d4c8bda2998e32e6c3b397cc61eadb4b208f0b commit r10-8495-g74d4c8bda2998e32e6c3b397cc61eadb4b208f0b Author: Richard Sandiford Date: Tue Jul 14 19:24:57 2020 +0100 ipa-devirt: Fix crash in obj_type_ref_class [PR95114] The testcase has failed since r9-5035, because obj_type_ref_class tries to look up an ODR type when no ODR type information is available. (The information was available earlier in the compilation, but was freed during pass_ipa_free_lang_data.) We then crash dereferencing the null get_odr_type result. The test passes with -O2. However, it fails again if -fdump-tree-all is used, since obj_type_ref_class is called indirectly from the dump routines. Other code creates ODR type entries on the fly by passing âtrueâ as the insert parameter. But obj_type_ref_class can't do that unconditionally, since it should have no side-effects when used from the dumping code. Following a suggestion from Honza, this patch adds parameters to say whether the routines are being called from dump routines and uses those to derive the insert parameter. gcc/ PR middle-end/95114 * tree.h (virtual_method_call_p): Add a default-false parameter that indicates whether the function is being called from dump routines. (obj_type_ref_class): Likewise. * tree.c (virtual_method_call_p): Likewise. * ipa-devirt.c (obj_type_ref_class): Likewise. Lazily add ODR type information for the type when the parameter is false. * tree-pretty-print.c (dump_generic_node): Update calls to virtual_method_call_p and obj_type_ref_class accordingly. gcc/testsuite/ PR middle-end/95114 * g++.target/aarch64/pr95114.C: New test.
[Bug tree-optimization/96146] VRP turns a terminating loop into an infinite loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96146 --- Comment #6 from CVS Commits --- The releases/gcc-10 branch has been updated by Richard Sandiford : https://gcc.gnu.org/g:b9475357b5b180c63b3389742452a48026f073a6 commit r10-8494-gb9475357b5b180c63b3389742452a48026f073a6 Author: Richard Sandiford Date: Tue Jul 14 19:24:56 2020 +0100 value-range: Fix handling of POLY_INT_CST anti-ranges [PR96146] The range infrastructure has code to decompose POLY_INT_CST ranges to worst-case integer bounds. However, it had the fundamental flaw (obvious in hindsight) that it applied to anti-ranges too, meaning that a range 2+2X would end up with a range of ~[2, +INF], i.e. [-INF, 1]. This patch decays to varying in that case instead. I'm still a bit uneasy about this. ISTM that in terms of generality: SSA_NAME => POLY_INT_CST => INTEGER_CST => ADDR_EXPR I.e. an SSA_NAME could store a POLY_INT_CST and a POLY_INT_CST could store an INTEGER_CST (before canonicalisation). POLY_INT_CST is also âas constant asâ ADDR_EXPR (well, OK, only some ADDR_EXPRs are run-time rather than link-time constants, whereas all POLY_INT_CSTs are, but still). So it seems like we should at least be able to treat POLY_INT_CST as symbolic. On the other hand, I don't have any examples in which that would be useful. gcc/ PR tree-optimization/96146 * value-range.cc (value_range::set): Only decompose POLY_INT_CST bounds to integers for VR_RANGE. Decay to VR_VARYING for anti-ranges involving POLY_INT_CSTs. gcc/testsuite/ PR tree-optimization/96146 * gcc.target/aarch64/sve/acle/general/pr96146.c: New test.
[Bug preprocessor/49973] Column numbers count multibyte characters as multiple columns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49973 Manuel López-Ibáñez changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #24 from Manuel López-Ibáñez --- Great! (If you login into bugzilla with your @gcc.gnu.org account, you should be able to admin PRs)
[Bug c++/96193] No ADL for hidden friend in call with explicit template arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96193 --- Comment #3 from Johel Ernesto Guerrero Peña --- Yes! I left it out expecting it to be backported as an extension like Clang does.
[Bug demangler/96143] C++ demangler should not add a lambda as a substitution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96143 Ian Lance Taylor changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Ian Lance Taylor --- Fixed on trunk.
[Bug libgomp/96198] new test case libgomp.c/loop-21.c in r11-2077
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96198 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2020-07-14
[Bug demangler/96143] C++ demangler should not add a lambda as a substitution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96143 --- Comment #2 from CVS Commits --- The master branch has been updated by Ian Lance Taylor : https://gcc.gnu.org/g:bae45b8be57b2a2c22bf45f3eeb1118c328ad028 commit r11-2093-gbae45b8be57b2a2c22bf45f3eeb1118c328ad028 Author: Ian Lance Taylor Date: Fri Jul 10 09:34:28 2020 -0700 demangler: don't treat lambda as a substitution candidate libiberty/ChangeLog: PR demangler/96143 * cp-demangle.c (d_lambda): Don't add substitution candidate. * testsuite/demangle-expected: Update a few existing test cases accordingly, and add a new test case.
[Bug target/94954] Wrong code generation for vec_pack_to_short_fp32 builtin for Power
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94954 Will Schmidt changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #7 from Will Schmidt --- Fixed, Closing.
[Bug target/94954] Wrong code generation for vec_pack_to_short_fp32 builtin for Power
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94954 Will Schmidt changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #6 from Will Schmidt --- Should now be fixed in all of the right places. closing. Thanks
[Bug target/95952] [8 Regression] gcc-8 bootstrap failure on powerpc64-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95952 --- Comment #16 from Will Schmidt --- (In reply to Mikael Pettersson from comment #15) > (In reply to Will Schmidt from comment #14) > > (In reply to Will Schmidt from comment #13) > > > Created attachment 48871 [details] > > > proposed patch > > > > > > Attached patch appears sufficient to resolve the issue on the 970 based > > > box > > > I have access to. > > > > Mikael, would be appreciated if you could give that a run-through to confirm > > it fixes the problem on your system. > > thanks, > > I can confirm that this patch restores gcc-8 bootstrap with the older > binutils. Thanks :-) Patch posted to list for review.
[Bug libgomp/96198] new test case libgomp.c/loop-21.c in r11-2077
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96198 Bill Seurer changed: What|Removed |Added Build||powerpc64*-linux-gnu Host||powerpc64*-linux-gnu Target||powerpc64*-linux-gnu --- Comment #1 from Bill Seurer --- Note: failed on powerpc64 both BE and LE
[Bug libgomp/96198] New: new test case libgomp.c/loop-21.c in r11-2077
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96198 Bug ID: 96198 Summary: new test case libgomp.c/loop-21.c in r11-2077 Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp Assignee: unassigned at gcc dot gnu.org Reporter: seurer at linux dot vnet.ibm.com CC: jakub at gcc dot gnu.org Target Milestone: --- g:f418bd4b92a03ee0ec0fe4cfcd896e86e11ac2cf, r11-2077 PASS: libgomp.c/loop-21.c (test for excess errors) . . . Execution timeout is: 300 spawn [open ...] FAIL: libgomp.c/loop-21.c execution test Running it in gdb shows: (gdb) where #0 0x3fffb7c0258c in __GI_raise (sig=) at ../nptl/sysdeps/unix/sysv/linux/raise.c:55 #1 0x3fffb7c04778 in __GI_abort () at abort.c:90 #2 0x10003548 in .main._omp_fn.4 () #3 0x3fffb7e36588 in .gomp_thread_start () from /home/seurer/gcc/install/gcc-7.4.0/lib64/libgomp.so.1 #4 0x3fffb7dccafc in start_thread (arg=0x3fffad21f130) at pthread_create.c:309 #5 0x3fffb7ce6f4c in .__clone () at ../sysdeps/unix/sysv/linux/powerpc/powerpc64/clone.S:104
[Bug other/86904] Column numbers ignore tab characters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86904 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #6 from David Malcolm --- Thanks; marking as resolved.
[Bug other/86904] Column numbers ignore tab characters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86904 Lewis Hyatt changed: What|Removed |Added CC||lhyatt at gmail dot com --- Comment #5 from Lewis Hyatt --- Fixed for GCC 11, may I ask someone please to close the PR?
[Bug target/95952] [8 Regression] gcc-8 bootstrap failure on powerpc64-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95952 --- Comment #15 from Mikael Pettersson --- (In reply to Will Schmidt from comment #14) > (In reply to Will Schmidt from comment #13) > > Created attachment 48871 [details] > > proposed patch > > > > Attached patch appears sufficient to resolve the issue on the 970 based box > > I have access to. > > Mikael, would be appreciated if you could give that a run-through to confirm > it fixes the problem on your system. > thanks, I can confirm that this patch restores gcc-8 bootstrap with the older binutils.
[Bug preprocessor/49973] Column numbers count multibyte characters as multiple columns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49973 --- Comment #23 from Lewis Hyatt --- Fixed for GCC 11, may I ask someone please to close the PR?
[Bug c++/96185] Enhancement: Please add a builtin to count bindings in [dcl.struct.bind]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96185 --- Comment #9 from Will Wray --- An earlier draft had __builtin_tuple_size as the magic behind the P2141 proposed std::tuple_size automagic generalization to Case 3 class types. There was opposition to that name because it specifically doesn't apply to tuples so I left the naming open, suggesting __builtin_binding_count (and, so, requiring consensus on naming for portability...)
[Bug other/86904] Column numbers ignore tab characters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86904 --- Comment #4 from CVS Commits --- The master branch has been updated by Lewis Hyatt : https://gcc.gnu.org/g:004bb936d6d5f177af26ad4905595e843d5665a5 commit r11-2092-g004bb936d6d5f177af26ad4905595e843d5665a5 Author: Lewis Hyatt Date: Tue Jul 14 12:05:56 2020 -0400 diagnostics: Support conversion of tabs to spaces [PR49973] [PR86904] Supports conversion of tabs to spaces when outputting diagnostics. Also adds -fdiagnostics-column-unit and -fdiagnostics-column-origin options to control how the column number is output, thereby resolving the two PRs. gcc/c-family/ChangeLog: PR other/86904 * c-indentation.c (should_warn_for_misleading_indentation): Get global tabstop from the new source. * c-opts.c (c_common_handle_option): Remove handling of -ftabstop, which is now a common option. * c.opt: Likewise. gcc/ChangeLog: PR preprocessor/49973 PR other/86904 * common.opt: Handle -ftabstop here instead of in c-family options. Add -fdiagnostics-column-unit= and -fdiagnostics-column-origin= options. * opts.c (common_handle_option): Handle the new options. * diagnostic-format-json.cc (json_from_expanded_location): Add diagnostic_context argument. Use it to convert column numbers as per the new options. (json_from_location_range): Likewise. (json_from_fixit_hint): Likewise. (json_end_diagnostic): Pass the new context argument to helper functions above. Add "column-origin" field to the output. (test_unknown_location): Add the new context argument to calls to helper functions. (test_bad_endpoints): Likewise. * diagnostic-show-locus.c (exploc_with_display_col::exploc_with_display_col): Support tabstop parameter. (layout_point::layout_point): Make use of class exploc_with_display_col. (layout_range::layout_range): Likewise. (struct line_bounds): Clarify that the units are now always display columns. Rename members accordingly. Add constructor. (layout::print_source_line): Add support for tab expansion. (make_range): Adapt to class layout_range changes. (layout::maybe_add_location_range): Likewise. (layout::layout): Adapt to class exploc_with_display_col changes. (layout::calculate_x_offset_display): Support tabstop parameter. (layout::print_annotation_line): Adapt to struct line_bounds changes. (layout::print_line): Likewise. (line_label::line_label): Add diagnostic_context argument. (get_affected_range): Likewise. (get_printed_columns): Likewise. (layout::print_any_labels): Adapt to struct line_label changes. (class correction): Add m_tabstop member. (correction::correction): Add tabstop argument. (correction::compute_display_cols): Use m_tabstop. (class line_corrections): Add m_context member. (line_corrections::line_corrections): Add diagnostic_context argument. (line_corrections::add_hint): Use m_context to handle tabstops. (layout::print_trailing_fixits): Adapt to class line_corrections changes. (test_layout_x_offset_display_utf8): Support tabstop parameter. (test_layout_x_offset_display_tab): New selftest. (test_one_liner_colorized_utf8): Likewise. (test_tab_expansion): Likewise. (test_diagnostic_show_locus_one_liner_utf8): Call the new tests. (diagnostic_show_locus_c_tests): Likewise. (test_overlapped_fixit_printing): Adapt to helper class and function changes. (test_overlapped_fixit_printing_utf8): Likewise. (test_overlapped_fixit_printing_2): Likewise. * diagnostic.h (enum diagnostics_column_unit): New enum. (struct diagnostic_context): Add members for the new options. (diagnostic_converted_column): Declare. (json_from_expanded_location): Add new context argument. * diagnostic.c (diagnostic_initialize): Initialize new members. (diagnostic_converted_column): New function. (maybe_line_and_column): Be willing to output a column of 0. (diagnostic_get_location_text): Convert column number as per the new options. (diagnostic_report_current_module): Likewise. (assert_location_text): Add origin and column_unit arguments for testing the new functionality. (test_diagnostic_get_location_text): Test the new functionality. * doc/invoke.texi: Document the new options and behavior
[Bug preprocessor/49973] Column numbers count multibyte characters as multiple columns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49973 --- Comment #22 from CVS Commits --- The master branch has been updated by Lewis Hyatt : https://gcc.gnu.org/g:004bb936d6d5f177af26ad4905595e843d5665a5 commit r11-2092-g004bb936d6d5f177af26ad4905595e843d5665a5 Author: Lewis Hyatt Date: Tue Jul 14 12:05:56 2020 -0400 diagnostics: Support conversion of tabs to spaces [PR49973] [PR86904] Supports conversion of tabs to spaces when outputting diagnostics. Also adds -fdiagnostics-column-unit and -fdiagnostics-column-origin options to control how the column number is output, thereby resolving the two PRs. gcc/c-family/ChangeLog: PR other/86904 * c-indentation.c (should_warn_for_misleading_indentation): Get global tabstop from the new source. * c-opts.c (c_common_handle_option): Remove handling of -ftabstop, which is now a common option. * c.opt: Likewise. gcc/ChangeLog: PR preprocessor/49973 PR other/86904 * common.opt: Handle -ftabstop here instead of in c-family options. Add -fdiagnostics-column-unit= and -fdiagnostics-column-origin= options. * opts.c (common_handle_option): Handle the new options. * diagnostic-format-json.cc (json_from_expanded_location): Add diagnostic_context argument. Use it to convert column numbers as per the new options. (json_from_location_range): Likewise. (json_from_fixit_hint): Likewise. (json_end_diagnostic): Pass the new context argument to helper functions above. Add "column-origin" field to the output. (test_unknown_location): Add the new context argument to calls to helper functions. (test_bad_endpoints): Likewise. * diagnostic-show-locus.c (exploc_with_display_col::exploc_with_display_col): Support tabstop parameter. (layout_point::layout_point): Make use of class exploc_with_display_col. (layout_range::layout_range): Likewise. (struct line_bounds): Clarify that the units are now always display columns. Rename members accordingly. Add constructor. (layout::print_source_line): Add support for tab expansion. (make_range): Adapt to class layout_range changes. (layout::maybe_add_location_range): Likewise. (layout::layout): Adapt to class exploc_with_display_col changes. (layout::calculate_x_offset_display): Support tabstop parameter. (layout::print_annotation_line): Adapt to struct line_bounds changes. (layout::print_line): Likewise. (line_label::line_label): Add diagnostic_context argument. (get_affected_range): Likewise. (get_printed_columns): Likewise. (layout::print_any_labels): Adapt to struct line_label changes. (class correction): Add m_tabstop member. (correction::correction): Add tabstop argument. (correction::compute_display_cols): Use m_tabstop. (class line_corrections): Add m_context member. (line_corrections::line_corrections): Add diagnostic_context argument. (line_corrections::add_hint): Use m_context to handle tabstops. (layout::print_trailing_fixits): Adapt to class line_corrections changes. (test_layout_x_offset_display_utf8): Support tabstop parameter. (test_layout_x_offset_display_tab): New selftest. (test_one_liner_colorized_utf8): Likewise. (test_tab_expansion): Likewise. (test_diagnostic_show_locus_one_liner_utf8): Call the new tests. (diagnostic_show_locus_c_tests): Likewise. (test_overlapped_fixit_printing): Adapt to helper class and function changes. (test_overlapped_fixit_printing_utf8): Likewise. (test_overlapped_fixit_printing_2): Likewise. * diagnostic.h (enum diagnostics_column_unit): New enum. (struct diagnostic_context): Add members for the new options. (diagnostic_converted_column): Declare. (json_from_expanded_location): Add new context argument. * diagnostic.c (diagnostic_initialize): Initialize new members. (diagnostic_converted_column): New function. (maybe_line_and_column): Be willing to output a column of 0. (diagnostic_get_location_text): Convert column number as per the new options. (diagnostic_report_current_module): Likewise. (assert_location_text): Add origin and column_unit arguments for testing the new functionality. (test_diagnostic_get_location_text): Test the new functionality. * doc/invoke.texi: Document the new options and behavio
[Bug c++/96185] Enhancement: Please add a builtin to count bindings in [dcl.struct.bind]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96185 --- Comment #8 from Jonathan Wakely --- But __builtin_bit_cast is the compiler magic to support std::bit_cast, it's not just a non-standard extension. PR 93121 is a request for std::bit_cast in GCC.
[Bug c++/96185] Enhancement: Please add a builtin to count bindings in [dcl.struct.bind]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96185 --- Comment #7 from Will Wray --- Oops, __builtin_bit_cast available in MSVC and Clang (when in GCC?)
[Bug c++/96185] Enhancement: Please add a builtin to count bindings in [dcl.struct.bind]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96185 --- Comment #6 from Will Wray --- Thanks for the comment on approach Jonathan: I'd noticed some collaboration and agreement around previous builtins such as __builtin_bit_cast which is now available in both GCC & Clang (though with some small inevitable divergence of behaviour). Clearly Richard's suggestion to prioritize P1061, with such illustrious co-authorship, is the best solution. I can offer to help on the gcc side. This is the std way to go. This request was borne of some frustration; I miss this facility in C++20. By a hack, Clang happens to support SFINAE on structured binding since v5 - lack of any way to do it in GCC prompted this request. My thinking was that a builtin can see quicker implementation and adoption than std features. This builtin _is_ in support of a std proposal.
[Bug c++/96197] New: Excess memory consumption, positive correlation with the size of a constexpr array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96197 Bug ID: 96197 Summary: Excess memory consumption, positive correlation with the size of a constexpr array Product: gcc Version: 9.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: hyena at hyena dot net.ee Target Milestone: --- Created attachment 48876 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48876&action=edit Contains the problematic constant expression array. The memory consumption of the compiler seems to have an exponential dependency on one of the constant expression arrays that I have set up in the header. I have attached the header file. With an array of just 500 elements the memory consumption of GCC goes above 5 GiB. I have tested even with the latest 10.x version and the problem is still there. Tested also with -O1, -O2 and -O3 and none of these made any difference. If anyone is aware of any workarounds then I would much appreciate learning more about them because I need to keep developing the project I have at hand but because of this bug it has become impossible to continue without changing the architecture a lot. This only becomes noticeable at larger array sizes (several hundred elements in my case).
[Bug c++/96185] Enhancement: Please add a builtin to count bindings in [dcl.struct.bind]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96185 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- (In reply to Jonathan Wakely from comment #3) > Not as a DR, absolutely not. There is no defect. > > It could be supported in non-strict modes as an extension, if the syntax > doesn't conflict with anything a valid program would use. Yeah, usually it is something with pedwarn, i.e. accepted in -std=c++2b/-std=gnu++2b mocdx, a warning in -std=gnu++20/-std=gnu++17 etc. and an error with -std=c++20/-std=c++17.
[Bug c++/96185] Enhancement: Please add a builtin to count bindings in [dcl.struct.bind]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96185 --- Comment #4 from Jonathan Wakely --- (In reply to Will Wray from comment #0) > (Submitting simultaneous requests for each of GCC, Clang and MSVC. > Coordination between vendors will be beneficial for portability.) This seems like the wrong approach. If you want something portable that works in all implementations, propose it for the standard.
[Bug c++/96185] Enhancement: Please add a builtin to count bindings in [dcl.struct.bind]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96185 --- Comment #3 from Jonathan Wakely --- (In reply to Will Wray from comment #2) > Would an early-delivered future feature require an opt-in switch? The relevant -std switch would be the opt-in. > Can P1061 be default enabled under earlier std flags by DR or otherwise? Not as a DR, absolutely not. There is no defect. It could be supported in non-strict modes as an extension, if the syntax doesn't conflict with anything a valid program would use.
[Bug middle-end/96192] tree-inline.c(copy_decl_for_dup_finish) should preserve decl alignment in copy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96192 --- Comment #3 from Sunil Pandey --- (In reply to Richard Biener from comment #1) > Hmm, but there's no local variable to copy here? Are you refering to the > result decl from b we materialize in c? This would be the same case > as for example switch conversion adding a 'long long' variable, so the > issue would be more wide-spread as you think - for example IPA SRA might > choose to pass an aggregate by its components thus with an aggregate with > two long long members you should see similar issues. Yes, long long result decl. It's incoming alignment is 4(lowered by target hook). But copy get default alignment as 8.
[Bug c++/96185] Enhancement: Please add a builtin to count bindings in [dcl.struct.bind]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96185 --- Comment #2 from Will Wray --- On the Clang ticket, linked above, Richard Smith comments: Instead of the proposed direction, I'd suggest we (and other implementers) prioritize implementation of https://wg21.link/p1061r1 (which is on its way to standardization: https://github.com/cplusplus/papers/issues/294). My follow-on questions: Would an early-delivered future feature require an opt-in switch? Can P1061 be default enabled under earlier std flags by DR or otherwise?
[Bug c++/96196] infinite loop removed by optimizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96196 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Jakub Jelinek --- This is not a valid C++ program, see https://eel.is/c++draft/intro.progress#1
[Bug c++/96196] infinite loop removed by optimizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96196 ktkachov at gcc dot gnu.org changed: What|Removed |Added CC||ktkachov at gcc dot gnu.org --- Comment #1 from ktkachov at gcc dot gnu.org --- This is -ffinite-loops which is on by default and was added in GCC 10.1 https://gcc.gnu.org/onlinedocs/gcc-10.1.0/gcc/Optimize-Options.html#Optimize-Options
[Bug c++/96196] New: infinite loop removed by optimizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96196 Bug ID: 96196 Summary: infinite loop removed by optimizer Product: gcc Version: 10.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: ingo at hannover dot ccc.de Target Milestone: --- Created attachment 48875 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48875&action=edit Preprocessed file If compiled with any of -Ofast -Os -O3 or -O2, g++ will optimize the while loop away and exit immediately, when it should run forever. #include #include int main() { const std::vector a{1}; std::vector b; std::cout << "before loop: " << b.size() << " < " << a.size() << "\n"; while(b.size() < a.size()) { // uncommenting this fixes the loop with -O2 //std::cout << "."; } std::cout << "after loop: " << b.size() << " < " << a.size() << "\n"; } This bug occurs at least with g++ from the following debian packages: * g++-10 (version 1:10.1.0-4) * g++-10 (version 1:10.1.0-5) * gcc-snapshot (version 1:20200616-1) gcc version 9 seems fine, also clang-9 and clang-10. Output from g++-10 version 1:10.1.0-5: $ g++-10 -v -save-temps -O2 infloop.cc -o infloop Using built-in specs. COLLECT_GCC=g++-10 COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/10/lto-wrapper OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa:hsa OFFLOAD_TARGET_DEFAULT=1 Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 10.1.0-5' --with-bugurl=file:///usr/share/doc/gcc-10/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2 --prefix=/usr --with-gcc-major-version-only --program-suffix=-10 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib --enable-libphobos-checking=release --with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none=/build/gcc-10-pmMab1/gcc-10-10.1.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-10-pmMab1/gcc-10-10.1.0/debian/tmp-gcn/usr,hsa --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 10.1.1 20200713 (Debian 10.1.0-5) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O2' '-o' 'infloop' '-shared-libgcc' '-mtune=generic' '-march=x86-64' /usr/lib/gcc/x86_64-linux-gnu/10/cc1plus -E -quiet -v -imultiarch x86_64-linux-gnu -D_GNU_SOURCE infloop.cc -mtune=generic -march=x86-64 -O2 -fpch-preprocess -fasynchronous-unwind-tables -o infloop.ii ignoring duplicate directory "/usr/include/x86_64-linux-gnu/c++/10" ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu" ignoring nonexistent directory "/usr/lib/gcc/x86_64-linux-gnu/10/include-fixed" ignoring nonexistent directory "/usr/lib/gcc/x86_64-linux-gnu/10/../../../../x86_64-linux-gnu/include" #include "..." search starts here: #include <...> search starts here: /usr/include/c++/10 /usr/include/x86_64-linux-gnu/c++/10 /usr/include/c++/10/backward /usr/lib/gcc/x86_64-linux-gnu/10/include /usr/local/include /usr/include/x86_64-linux-gnu /usr/include End of search list. COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O2' '-o' 'infloop' '-shared-libgcc' '-mtune=generic' '-march=x86-64' /usr/lib/gcc/x86_64-linux-gnu/10/cc1plus -fpreprocessed infloop.ii -quiet -dumpbase infloop.cc -mtune=generic -march=x86-64 -auxbase infloop -O2 -version -fasynchronous-unwind-tables -o infloop.s GNU C++14 (Debian 10.1.0-5) version 10.1.1 20200713 (x86_64-linux-gnu) compiled by GNU C version 10.1.1 20200713, GMP version 6.2.0, MPFR version 4.0.2, MPC version 1.1.0, isl version isl-0.22.1-GMP warning: MPFR header version 4.0.2 differs from library version 4.1.0. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU C++14 (Debian 10.1.0-5) version 10.1.1 20200713 (x86_64-linux-gnu) compiled by GNU C version 10.1.1 20200713, GMP version 6.2.0, MPFR version 4.0.2, MPC version 1.1.0, isl version isl-0.22.1-GMP warning: MPFR header version 4.0.2 differs from library version 4.1.0. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 6cd36725701c85e62ce50f8955bd2a9a COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O2' '-o' 'infloop' '-shared-libgcc' '-mtune=generic' '-march=x86-64' as -v --64 -o infloop.o infloop.
[Bug c++/96162] [11 Regression] ICE in discriminator_for_local_entity, at cp/mangle.c:1910
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96162 --- Comment #1 from Haoxin Tu --- Add a more case. $cat p.cc #include int a() { for (static int & b) {} } $g++ p.cc test.cc: In function ‘int a()’: test.cc:3:24: error: expected ‘;’ before ‘)’ token 3 | for (static int & b) {} |^ |; test.cc:3:24: error: expected primary-expression before ‘)’ token test.cc:3:24: error: expected ‘;’ before ‘)’ token 3 | for (static int & b) {} |^ |; during GIMPLE pass: *build_cgraph_edges test.cc:3:23: internal compiler error: in discriminator_for_local_entity, at cp/mangle.c:1910 3 | for (static int & b) {} | ^ 0x63316d discriminator_for_local_entity ../../gcc/cp/mangle.c:1910 This time GCC emits "during GIMPLE pass: *build_cgraph_edges" first and then triggers the ICE.
[Bug middle-end/96194] [10/11 Regression] ICE in assign_temp, at function.c:984 during RTL pass: expand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96194 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Jakub Jelinek --- Fixed.
[Bug middle-end/96194] [10/11 Regression] ICE in assign_temp, at function.c:984 during RTL pass: expand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96194 --- Comment #8 from CVS Commits --- The releases/gcc-10 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:de70758207a6b2d8d3d6bbd3fc564ca736ed094f commit r10-8493-gde70758207a6b2d8d3d6bbd3fc564ca736ed094f Author: Jakub Jelinek Date: Tue Jul 14 16:01:11 2020 +0200 expr: Unbreak build of mesa [PR96194] > > The store to the whole of each volatile object was picked apart > > like there had been an individual assignment to each of the > > fields. Reads were added as part of that; see PR for details. > > The reads from volatile memory were a clear bug; individual > > stores questionable. A separate patch clarifies the docs. This breaks building of mesa on both the trunk and 10 branch. The problem is that the middle-end may never create temporaries of non-POD (TREE_ADDRESSABLE) types, those can be only created when the language says so and thus only the FE is allowed to create those. This patch just reverts the behavior to what we used to do before for the stores to volatile non-PODs. Perhaps we want to do something else, but definitely we can't create temporaries of the non-POD type. It is up to discussions on what should happen in those cases. 2020-07-14 Jakub Jelinek PR middle-end/96194 * expr.c (expand_constructor): Don't create temporary for store to volatile MEM if exp has an addressable type. * g++.dg/opt/pr96194.C: New test. (cherry picked from commit b1d389d60d1929c7528ef984925ea010e3bf2c1a)
[Bug middle-end/96194] [10/11 Regression] ICE in assign_temp, at function.c:984 during RTL pass: expand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96194 --- Comment #7 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:b1d389d60d1929c7528ef984925ea010e3bf2c1a commit r11-2086-gb1d389d60d1929c7528ef984925ea010e3bf2c1a Author: Jakub Jelinek Date: Tue Jul 14 16:01:11 2020 +0200 expr: Unbreak build of mesa [PR96194] > > The store to the whole of each volatile object was picked apart > > like there had been an individual assignment to each of the > > fields. Reads were added as part of that; see PR for details. > > The reads from volatile memory were a clear bug; individual > > stores questionable. A separate patch clarifies the docs. This breaks building of mesa on both the trunk and 10 branch. The problem is that the middle-end may never create temporaries of non-POD (TREE_ADDRESSABLE) types, those can be only created when the language says so and thus only the FE is allowed to create those. This patch just reverts the behavior to what we used to do before for the stores to volatile non-PODs. Perhaps we want to do something else, but definitely we can't create temporaries of the non-POD type. It is up to discussions on what should happen in those cases. 2020-07-14 Jakub Jelinek PR middle-end/96194 * expr.c (expand_constructor): Don't create temporary for store to volatile MEM if exp has an addressable type. * g++.dg/opt/pr96194.C: New test.
[Bug tree-optimization/96195] aarch64: ICE during GIMPLE pass:vect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96195 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||rsandifo at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Note the testcase is invalid, the loop iterator really shouldn't be changed in the simd body (well, can change, but only if it has the same value at the end of loop body as it has at the start of it). What are the different modes? vector(4) int and vector(4) int really look the same to me...
[Bug c++/95820] [10 Regression] ICE in splice_late_return_type, at cp/pt.c:29034
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95820 Marek Polacek changed: What|Removed |Added Summary|[10/11 Regression] ICE in |[10 Regression] ICE in |splice_late_return_type, at |splice_late_return_type, at |cp/pt.c:29034 |cp/pt.c:29034 Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Marek Polacek --- Fixed in GCC 11.
[Bug c++/95820] [10/11 Regression] ICE in splice_late_return_type, at cp/pt.c:29034
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95820 --- Comment #6 from CVS Commits --- The master branch has been updated by Marek Polacek : https://gcc.gnu.org/g:9eb370f19c1198e62d47eae74531e54d0b098bf1 commit r11-2085-g9eb370f19c1198e62d47eae74531e54d0b098bf1 Author: Marek Polacek Date: Wed Jun 24 17:39:21 2020 -0400 c++: Improve checking of decls with trailing return type [PR95820] This is an ICE-on-invalid but I've been seeing it when reducing various testcases, so it's more important for me than usually. splice_late_return_type now checks that if we've seen a late return type, the function return type was auto. That's a fair assumption but grokdeclarator/cdk_function wasn't giving errors for function pointers and similar. So we want to perform various checks not only when funcdecl_p || inner_declarator == NULL. But only give the !late_return_type errors when funcdecl_p, to accept e.g. auto (*fp)() = f; in C++11. Here's a diff -w to ease the review: --- a/gcc/cp/decl.c +++ b/gcc/cp/decl.c @@ -12102,14 +12102,9 @@ grokdeclarator (const cp_declarator *declarator, /* Handle a late-specified return type. */ tree late_return_type = declarator->u.function.late_return_type; - if (funcdecl_p - /* This is the case e.g. for - using T = auto () -> int. */ - || inner_declarator == NULL) - { if (tree auto_node = type_uses_auto (type)) { - if (!late_return_type) + if (!late_return_type && funcdecl_p) { if (current_class_type && LAMBDA_TYPE_P (current_class_type)) @@ -12201,7 +12196,6 @@ grokdeclarator (const cp_declarator *declarator, "type specifier", name); return error_mark_node; } - } type = splice_late_return_type (type, late_return_type); if (type == error_mark_node) return error_mark_node; gcc/cp/ChangeLog: PR c++/95820 * decl.c (grokdeclarator) : Check also pointers/references/... to functions. gcc/testsuite/ChangeLog: PR c++/95820 * g++.dg/cpp1y/auto-fn58.C: New test.
[Bug c++/92181] initializer_list & string_view result in "modification of '' is not a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92181 --- Comment #4 from Erich Erstu --- I also found out that when I try to populate a constexpr array using a trivial constexpr function that passes on the argument initializer list then I get the same error. This does not work any more within the definition of a constexpr array: constexpr room_desc_part_type make( ROOM_DESC_PART part, std::initializer_list args ) { return #if __cplusplus <= 201703L __extension__ #endif // __cplusplus room_desc_part_type{ .index = part, .arguments = args }; }
[Bug middle-end/92929] OpenACC/OpenMP 'target' 'exit data'/'update' optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92929 --- Comment #10 from Thomas Schwinge --- (In reply to Thomas Schwinge from comment #4) > The recent r279626 "OpenACC 2.6 deep copy: middle-end parts" contains > changes related to this ... some of which have now gotten reverted in recent commit g:b20097c65d2e74b1901fba1c55c77f0407e542d2 "openacc: Don't strip TO_PSET/POINTER for enter/exit data".
[Bug libfortran/93727] Fortran 2018: EX edit descriptor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93727 jvdelisle at charter dot net changed: What|Removed |Added CC||jvdelisle at charter dot net --- Comment #1 from jvdelisle at charter dot net --- I will take this one.
[Bug middle-end/96192] tree-inline.c(copy_decl_for_dup_finish) should preserve decl alignment in copy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96192 H.J. Lu changed: What|Removed |Added CC||elver at google dot com --- Comment #2 from H.J. Lu --- *** Bug 95645 has been marked as a duplicate of this bug. ***
[Bug c/95645] Linux kernel regression "during GIMPLE pass: adjust_alignment"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95645 --- Comment #2 from H.J. Lu --- *** This bug has been marked as a duplicate of bug 96192 ***
[Bug c++/92181] initializer_list & string_view result in "modification of '' is not a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92181 Erich Erstu changed: What|Removed |Added CC||hyena at hyena dot net.ee --- Comment #3 from Erich Erstu --- I started getting the same error after upgrading to GCC 9.3.0. The problem in my case is either related to the use of std::pair in constexpr or the fact that I have nested instances of std::initializer_list. The workaround was to replace std::pair with a custom struct as seen here: struct zone_name_root_variant_type { const char *name; std::initializer_list affixes; }; struct zone_name_root_type { ZONE_NAME_ROOT index; const char *region; std::initializer_list< zone_name_root_variant_type /* std::pair< const char*, std::initializer_list > */ > variants; }; static constexpr const zone_name_root_type zone_name_root_table[] = { { ZONE_NAME_ROOT::UNKNOWN, "Region", { { "", { ZONE_NAME_AFFIX::UNKNOWN } } } }, { ZONE_NAME_ROOT::NONE, "", { } } };
[Bug fortran/92311] Fortran and OpenMP use_device_ptr and OpenACC attach_ptr/dettach_ptr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92311 --- Comment #9 from Tobias Burnus --- (In reply to Nichols A. Romero from comment #0) > The error for the OpenMP is shown below: >29 |!$omp target data use_device_ptr(this_bin) > | 1 > Error: TARGET DATA must contain at least one MAP clause at (1) As mentioned, this is OpenMP 5.0 and not yet implemented (for Fortran; it is already implemented for C/C++). → This should be the only remaining issue of the discussion in this PR. > For the OpenACC program >27 |!$acc enter data attach(this_bin) > | 1 This one _works now_ with GCC 10 (or the being-developed version GCC 11 alias mainline/main/trunk). Additionally, the OpenMP 4.5 (but not OpenMP 5.0) mapping of derived-type components is now supported in GCC 11 (just committed). (For C/C++, the OpenMP 4.5 struct element mapping is supported since GCC 6.)
[Bug tree-optimization/96195] New: aarch64: ICE during GIMPLE pass:vect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96195 Bug ID: 96195 Summary: aarch64: ICE during GIMPLE pass:vect Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: yangyang305 at huawei dot com Target Milestone: --- Hi, gcc-trunk ICEs when compiling the following testcase with -ftree-vectorize -march=armv8.2-a+sve -O1 -msve-vector-bits=128 -fopenmp-simd testcase --- int by; #pragma omp declare simd int zp (int); void qh (int oh) { #pragma omp simd for (by = 0; by < oh; ++by) by = zp (by); } --- GCC version: 11.0.0 20200714 (experimental) Result: pr92347.c: In function ‘qh’: pr92347.c:13:1: error: invalid conversion in gimple call 13 | qh (int oh) | ^~ vector(4) int vector(4) int # .MEM_59 = VDEF <.MEM_13> vect__21.16_58 = zp.simdclone.2 (vect_vec_iv_.15_56); during GIMPLE pass: vect pr92347.c:13:1: internal compiler error: verify_gimple failed 0xd1dcd7 verify_gimple_in_cfg(function*, bool) ../.././gcc/tree-cfg.c:5491 0xbe415b execute_function_todo ../.././gcc/passes.c:1992 0xbe505b do_per_function ../.././gcc/passes.c:1640 0xbe505b execute_todo ../.././gcc/passes.c:2046 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. In the testcase, the following gimple call is generated: vect__21.16_58 = zp.simdclone.2 (vect_vec_iv_.15_56); The TREE_TYPE of vect__21.16_58 has a different mode with the TREE_TYPE of zp.simdclone.2 (vect_vec_iv_.15_56), leading to the crash. It seems that a type conversion is needed when the return type of the simd clone of the function has the same ABI identity but different TYPE_MODEs with the vectype analyzed. I have prepared the following patch to fix this problem, the type conversions of the arguments are added as well. diff --git a/gcc/tree-vect-stmts.c b/gcc/tree-vect-stmts.c --- a/gcc/tree-vect-stmts.c +++ b/gcc/tree-vect-stmts.c @@ -4108,7 +4108,20 @@ vectorizable_simd_clone_call (vec_info *vinfo, stmt_vec_info stmt_info, vec_oprnd0); } if (k == 1) - vargs.safe_push (vec_oprnd0); + if (!useless_type_conversion_p (TREE_TYPE (vec_oprnd0), + atype)) + { + vec_oprnd0 + = build1 (VIEW_CONVERT_EXPR, atype, vec_oprnd0); + gassign *new_stmt + = gimple_build_assign (make_ssa_name (atype), + vec_oprnd0); + vect_finish_stmt_generation (vinfo, stmt_info, +new_stmt, gsi); + vargs.safe_push (gimple_assign_lhs (new_stmt)); + } + else + vargs.safe_push (vec_oprnd0); else { vec_oprnd0 = build_constructor (atype, ctor_elts); @@ -4204,8 +4217,7 @@ vectorizable_simd_clone_call (vec_info *vinfo, stmt_vec_info stmt_info, gcc_assert (ratype || simd_clone_subparts (rtype) == nunits); if (ratype) new_temp = create_tmp_var (ratype); - else if (simd_clone_subparts (vectype) - == simd_clone_subparts (rtype)) + else if (useless_type_conversion_p (vectype, rtype)) new_temp = make_ssa_name (vec_dest, new_call); else new_temp = make_ssa_name (rtype, new_call); @@ -4293,6 +4305,12 @@ vectorizable_simd_clone_call (vec_info *vinfo, stmt_vec_info stmt_info, vect_finish_stmt_generation (vinfo, stmt_info, new_stmt, gsi); vect_clobber_variable (vinfo, stmt_info, gsi, new_temp); } + else if (!useless_type_conversion_p (vectype, rtype)) + { + vec_oprnd0 = build1 (VIEW_CONVERT_EXPR, vectype, new_temp); + new_stmt = gimple_build_assign (make_ssa_name (vec_dest), vec_oprnd0); + vect_finish_stmt_generation (vinfo, stmt_info, new_stmt, gsi); + } } if (j == 0) With this patch, gcc generates: _58 = VIEW_CONVERT_EXPR(vect_vec_iv_.15_56); _59 = zp.simdclone.2 (_58); vect__21.16_61 = VIEW_CONVERT_EXPR(_59);
[Bug fortran/93733] F2008: G0.d output editing for integer/logical/character data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93733 --- Comment #7 from Thomas Henlich --- (In reply to Dominique d'Humieres from comment #6) > > Please explain, what valid code according to Fortran 2008 does -std=f2008 > > reject? > > FAIL: gfortran.dg/fmt_g0_4.f08 -O (test for excess errors) I think there is another bug, see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36725#c8
[Bug fortran/93733] F2008: G0.d output editing for integer/logical/character data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93733 --- Comment #6 from Dominique d'Humieres --- > Please explain, what valid code according to Fortran 2008 does -std=f2008 > reject? FAIL: gfortran.dg/fmt_g0_4.f08 -O (test for excess errors)
[Bug fortran/95612] [9/10/11 Regression] ICE in gfc_check_pointer_assign, at fortran/expr.c:4274
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95612 --- Comment #3 from CVS Commits --- The master branch has been updated by Mark Eggleston : https://gcc.gnu.org/g:81072bab8d1e48ee83d9711dcb559ea1e019b351 commit r11-2080-g81072bab8d1e48ee83d9711dcb559ea1e019b351 Author: Mark Eggleston Date: Thu Jun 11 11:05:40 2020 +0100 Fortran : ICE in gfc_check_pointer_assign PR95612 Output an error if the right hand value is a zero sized array or does not have a symbol tree otherwise continue checking. 2020-07-14 Steven G. Kargl gcc/fortran/ PR fortran/95612 * expr.c (gfc_check_pointer_assigb): Output an error if rvalue is a zero sized array or output an error if rvalue doesn't have a symbol tree. 2020-07-14 Mark Eggleston gcc/testsuite/ PR fortran/95612 * gfortran.dg/pr95612.f90: New test.
[Bug middle-end/96194] [10/11 Regression] ICE in assign_temp, at function.c:984 during RTL pass: expand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96194 --- Comment #6 from Manuel Lauss --- (In reply to Jakub Jelinek from comment #5) > Created attachment 48874 [details] > gcc11-pr96194.patch > > Untested fix. It fixes the mesa build, thank you!
[Bug fortran/93733] F2008: G0.d output editing for integer/logical/character data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93733 --- Comment #5 from Thomas Henlich --- (In reply to Dominique d'Humieres from comment #4) > But reject valid too! AFAIU this cannot captured ay the format level. Please explain, what valid code according to Fortran 2008 does -std=f2008 reject?
[Bug fortran/93733] F2008: G0.d output editing for integer/logical/character data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93733 --- Comment #4 from Dominique d'Humieres --- > Agreed, that should fix the bug. But reject valid too! AFAIU this cannot captured ay the format level.
[Bug middle-end/96194] [10/11 Regression] ICE in assign_temp, at function.c:984 during RTL pass: expand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96194 --- Comment #5 from Jakub Jelinek --- Created attachment 48874 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48874&action=edit gcc11-pr96194.patch Untested fix.
[Bug fortran/67311] ICE calling subroutine with derived type as argument within OpenMP parallel region
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67311 Tobias Burnus changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #10 from Tobias Burnus --- FIXED on mainline (GCC 10). Thanks for the bugreport and sorry for taking nearly 5 years to get it fixed.