[Bug gcov-profile/85273] New: [GCOV] return statement in else block of if(1) statement when there is an array declaration statement and a goto statement in gcov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85273 Bug ID: 85273 Summary: [GCOV] return statement in else block of if(1) statement when there is an array declaration statement and a goto statement in gcov Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: gcov-profile Assignee: unassigned at gcc dot gnu.org Reporter: yangyibiao at nju dot edu.cn CC: marxin at gcc dot gnu.org Target Milestone: --- $ cat small.c int main() { b: { int c[1]; if (1) ; else return 0; return 0; goto b; } } $ gcc -w --coverage small.c; ./a.out; gcov-8 small.c; cat small.c.gcov File 'small.c' Lines executed:100.00% of 4 Creating 'small.c.gcov' -:0:Source:small.c -:0:Graph:small.gcno -:0:Data:small.gcda -:0:Runs:1 -:0:Programs:1 1:1:int main() { 1:2:b: -:3: { -:4:int c[1]; -:5:if (1) -:6: ; -:7:else 1:8: return 0; 1:9:return 0; -: 10:goto b; -: 11: } -: 12:} ** Line #8 is wrongly marked as executed. While removing any of Line #4 or Line #10, the result is correct.
[Bug gcov-profile/85272] [GCOV] return statement in the else block of if(1) statement nested in a for(;;) statement is wrongly marked as executed in gcov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85272 --- Comment #1 from Yibiao Yang --- when we replace Line #6 from "continue;" to ";" or remove Line #3 "int e[1];", the result is correct.
[Bug gcov-profile/85272] New: [GCOV] return statement in the else block of if(1) statement nested in a for(;;) statement is wrongly marked as executed in gcov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85272 Bug ID: 85272 Summary: [GCOV] return statement in the else block of if(1) statement nested in a for(;;) statement is wrongly marked as executed in gcov Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: gcov-profile Assignee: unassigned at gcc dot gnu.org Reporter: yangyibiao at nju dot edu.cn CC: marxin at gcc dot gnu.org Target Milestone: --- $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/8/lto-wrapper OFFLOAD_TARGET_NAMES=nvptx-none OFFLOAD_TARGET_DEFAULT=1 Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 8-20170923-1ubuntu2' --with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs --enable-languages=c,c++,go,brig,fortran,objc,obj-c++ --prefix=/usr --with-gcc-major-version-only --program-suffix=-8 --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 --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie --with-system-zlib --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 --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 8.0.0 20170923 (experimental) [trunk revision 253118] (Ubuntu 8-20170923-1ubuntu2) $ cat small.c int main() { for (;;) { int e[1]; if (1) { if (0) continue; } else return 0; return 1; } return 2; } $ gcc -w --coverage small.c; ./a.out; gcov-8 small.c; cat small.c.gcov File 'small.c' Lines executed:100.00% of 3 Creating 'small.c.gcov' -:0:Source:small.c -:0:Graph:small.gcno -:0:Data:small.gcda -:0:Runs:1 -:0:Programs:1 1:1:int main() { -:2: for (;;) { -:3:int e[1]; -:4:if (1) { -:5: if (0) -:6:continue; -:7:} else 1:8: return 0; 1:9:return 1; -: 10: } -: 11: return 2; -: 12:} * Line #8 is wrongly marked as executed.
[Bug target/85142] Wrong -print-multi-os-directory & -print-multi-lib output for riscv64 + multilib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85142 --- Comment #11 from Jim Wilson --- Created attachment 43874 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43874&action=edit An unofficial patch to build one lp64d multilib.
[Bug target/85142] Wrong -print-multi-os-directory & -print-multi-lib output for riscv64 + multilib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85142 --- Comment #10 from Jim Wilson --- The main problem turns out to be your deletion of MULTILIB_REUSE. You get an error if MULTILIB_REUSE refers to directories that aren't in MULTILIB_REQUIRED, but deleting the whole thing is wrong, as this is required to handle the fact that imafdc and gc are the same architecture. Defining MULTILIB_REUSE makes MULTILIB_MATCHES unnecessary. The RISC-V port is using default options specified by configure, so MULTILIB_DEFAULTS appears to be unnecessary. Adding back to your patch MULTILIB_REUSE = \ march.rv64imafdc/mabi.lp64d=march.rv64imafd/mabi.lp64d \ march.rv64imafdc/mabi.lp64d=march.rv64gc/mabi.lp64d \ march.rv64imafdc/mabi.lp64d=march.rv64g/mabi.lp64d I get gamma05:2256$ ./xgcc -B./ --print-multi-lib .; lib64/lp64d;@march=rv64imafdc@mabi=lp64d gamma05:2257$ ./xgcc -B./ --print-multi-dir lib64/lp64d gamma05:2258$ ./xgcc -B./ --print-multi-os-directory ../lib64/lp64d gamma05:2259$ which looks mostly OK. We still have two multilibs according to print-multi-lib though. The default one will never match, because it is identical to the second one, and hence will never be used. We are wasting time building it and installing it. It will install into /usr/lib which we don't want. To get rid of the extra multilib, I need to add multilib defaults again. With that change, I now get gamma05:2331$ ./xgcc -B./ --print-multi-lib .; gamma05:2332$ ./xgcc -B./ --print-multi-dir lib64/lp64d gamma05:2333$ ./xgcc -B./ --print-multi-os-directory ../lib64/lp64d which looks right. Only one copy of the libraries are built, and they get installed in the right place, in ../lib64/lp64d. I'll attach my patch.
[Bug middle-end/85196] [6/7 regression] ICE in extract_insn, at recog.c:2311: unrecognizable insn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85196 Eric Botcazou changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Eric Botcazou --- Thanks for the reduced testcase.
[Bug middle-end/85196] [6/7 regression] ICE in extract_insn, at recog.c:2311: unrecognizable insn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85196 --- Comment #5 from Eric Botcazou --- Author: ebotcazou Date: Fri Apr 6 22:33:55 2018 New Revision: 259196 URL: https://gcc.gnu.org/viewcvs?rev=259196&root=gcc&view=rev Log: PR target/85196 * config/sparc/sparc.c (sparc_expand_move): Deal with symbolic operands based on LABEL_REF. Remove useless assertion. (pic_address_needs_scratch): Fix formatting. (sparc_legitimize_pic_address): Minor tweaks. (sparc_delegitimize_address): Adjust assertion accordingly. * config/sparc/sparc.md (movsi_pic_label_ref): Change label_ref_operand into symbolic_operand. (movsi_high_pic_label_ref): Likewise. (movsi_lo_sum_pic_label_ref): Likewise. (movdi_pic_label_ref): Likewise. (movdi_high_pic_label_ref): Likewise. (movdi_lo_sum_pic_label_ref): Likewise. Added: branches/gcc-6-branch/gcc/testsuite/g++.dg/opt/pr85196.C - copied unchanged from r259194, trunk/gcc/testsuite/g++.dg/opt/pr85196.C Modified: branches/gcc-6-branch/gcc/ChangeLog branches/gcc-6-branch/gcc/config/sparc/sparc.c branches/gcc-6-branch/gcc/config/sparc/sparc.md branches/gcc-6-branch/gcc/testsuite/ChangeLog
[Bug middle-end/85196] [6/7 regression] ICE in extract_insn, at recog.c:2311: unrecognizable insn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85196 --- Comment #4 from Eric Botcazou --- Author: ebotcazou Date: Fri Apr 6 22:32:39 2018 New Revision: 259195 URL: https://gcc.gnu.org/viewcvs?rev=259195&root=gcc&view=rev Log: PR target/85196 * config/sparc/sparc.c (sparc_expand_move): Deal with symbolic operands based on LABEL_REF. Remove useless assertion. (pic_address_needs_scratch): Fix formatting. (sparc_legitimize_pic_address): Minor tweaks. (sparc_delegitimize_address): Adjust assertion accordingly. * config/sparc/sparc.md (movsi_pic_label_ref): Change label_ref_operand into symbolic_operand. (movsi_high_pic_label_ref): Likewise. (movsi_lo_sum_pic_label_ref): Likewise. (movdi_pic_label_ref): Likewise. (movdi_high_pic_label_ref): Likewise. (movdi_lo_sum_pic_label_ref): Likewise. Added: branches/gcc-7-branch/gcc/testsuite/g++.dg/opt/pr85196.C - copied unchanged from r259194, trunk/gcc/testsuite/g++.dg/opt/pr85196.C Modified: branches/gcc-7-branch/gcc/ChangeLog branches/gcc-7-branch/gcc/config/sparc/sparc.c branches/gcc-7-branch/gcc/config/sparc/sparc.md branches/gcc-7-branch/gcc/testsuite/ChangeLog
[Bug c++/85271] New: Trivial copy assignment operator overwrites members not being copied
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85271 Bug ID: 85271 Summary: Trivial copy assignment operator overwrites members not being copied Product: gcc Version: 8.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: hstong at ca dot ibm.com Target Milestone: --- In the following, the operator= used by Q's defaulted copy assignment operator for the "d" subobject is a copy assignment operator of B: that is, it does not copy the "b0" member of "d". The expected behaviour is observed when Q's copy assignment operator is explicitly defaulted after its first declaration, but not if it is explicitly defaulted on its first declaration. ### SOURCE (): extern "C" void abort(void); struct B0 { int b0; }; struct B { B &operator=(const B &) = default; int x; }; struct D : B0, B { using B::operator=; private: D &operator=(const D &) && = default; }; struct Q { Q &operator=(const Q &) = default; D d; }; //Q &Q::operator=(const Q &) = default; Q qa, qb; int main(void) { qb.d.b0 = 42; qb = qa; if (qb.d.b0 != 42) abort(); } ### COMPILER INVOCATION: g++ -xc++ -std=c++2a -o inhtrivcpyassn - ### INVOCATION AND OUTPUT OF RESULTING EXECUTABLE: > ./inhtrivcpyassn; printf '(rc=%d)\n' "$?" Aborted ./inhtrivcpyassn (rc=134) ### EXPECTED RUN OUTPUT: (rc=0) ### COMPILER VERSION INFO: Using built-in specs. COLLECT_GCC=/opt/wandbox/gcc-head/bin/g++ COLLECT_LTO_WRAPPER=/opt/wandbox/gcc-head/libexec/gcc/x86_64-pc-linux-gnu/8.0.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../source/configure --prefix=/opt/wandbox/gcc-head --enable-languages=c,c++ --disable-multilib --without-ppl --without-cloog-ppl --enable-checking=release --disable-nls --enable-lto LDFLAGS=-Wl,-rpath,/opt/wandbox/gcc-head/lib,-rpath,/opt/wandbox/gcc-head/lib64,-rpath,/opt/wandbox/gcc-head/lib32 Thread model: posix gcc version 8.0.1 20180405 (experimental) (GCC)
[Bug middle-end/85196] [6/7 regression] ICE in extract_insn, at recog.c:2311: unrecognizable insn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85196 --- Comment #3 from Eric Botcazou --- Author: ebotcazou Date: Fri Apr 6 22:30:05 2018 New Revision: 259194 URL: https://gcc.gnu.org/viewcvs?rev=259194&root=gcc&view=rev Log: PR target/85196 * config/sparc/sparc.c (sparc_expand_move): Deal with symbolic operands based on LABEL_REF. Remove useless assertion. (pic_address_needs_scratch): Fix formatting. (sparc_legitimize_pic_address): Minor tweaks. (sparc_delegitimize_address): Adjust assertion accordingly. * config/sparc/sparc.md (movsi_pic_label_ref): Change label_ref_operand into symbolic_operand. (movsi_high_pic_label_ref): Likewise. (movsi_lo_sum_pic_label_ref): Likewise. (movdi_pic_label_ref): Likewise. (movdi_high_pic_label_ref): Likewise. (movdi_lo_sum_pic_label_ref): Likewise. Added: trunk/gcc/testsuite/g++.dg/opt/pr85196.C Modified: trunk/gcc/ChangeLog trunk/gcc/config/sparc/sparc.c trunk/gcc/config/sparc/sparc.md trunk/gcc/testsuite/ChangeLog
[Bug libfortran/85253] [8 Regression] asan detects heap-buffer-overflow in matmul_r4.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85253 --- Comment #7 from Vittorio Zecca --- You are welcome, very fast fix, keep up the good work!
[Bug c++/85269] warn for referenced standard symbols that aren't guaranteed to be declared in a header
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85269 --- Comment #1 from Martin Sebor --- LWG issues 343 has some bakckground into this problem: http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#343 It was resolved via LWG #1178 without solving the portability problem: http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1178
[Bug c++/85270] New: Trivial assignment operator not considered such
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85270 Bug ID: 85270 Summary: Trivial assignment operator not considered such Product: gcc Version: 8.0 Status: UNCONFIRMED Keywords: rejects-valid Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: hstong at ca dot ibm.com Target Milestone: --- Trivial copy assignment operator not considered such GCC stops considering a trivial copy assignment operator to be trivial when a non-trivial copy assignment operator is added to the class. Works with Clang; fails with GCC. ### SOURCE (): struct Q { Q &operator=(const Q &) = default; // defaulted on first declaration, not user-provided; trivial Q &operator=(Q &); // not a viable candidate at P1 }; static_assert(__is_trivially_assignable(Q &, const Q &), ""); // (P1) // Assertion succeeds with Clang and ICC, but fails with GCC. ### COMPILER INVOCATION: g++ -xc++ -std=c++2a -fsyntax-only - ### ACTUAL OUTPUT: :8:15: error: static assertion failed ### EXPECTED OUTPUT: (Clean compile) ### COMPILER VERSION INFO (g++ -v): Using built-in specs. COLLECT_GCC=/opt/wandbox/gcc-head/bin/g++ COLLECT_LTO_WRAPPER=/opt/wandbox/gcc-head/libexec/gcc/x86_64-pc-linux-gnu/8.0.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../source/configure --prefix=/opt/wandbox/gcc-head --enable-languages=c,c++ --disable-multilib --without-ppl --without-cloog-ppl --enable-checking=release --disable-nls --enable-lto LDFLAGS=-Wl,-rpath,/opt/wandbox/gcc-head/lib,-rpath,/opt/wandbox/gcc-head/lib64,-rpath,/opt/wandbox/gcc-head/lib32 Thread model: posix gcc version 8.0.1 20180405 (experimental) (GCC)
[Bug c++/85256] [8 Regression] ICE with capturing pointer to VLA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85256 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug middle-end/85090] [8 Regression] wrong code with -O2 -fno-tree-dominator-opts -mavx512f -fira-algorithm=priority
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85090 --- Comment #13 from Vladimir Makarov --- (In reply to Uroš Bizjak from comment #11) > (In reply to Jakub Jelinek from comment #5) > > I guess it depends on what exactly a normal subreg on lhs means. > > The documentation says: > > When used as an lvalue, 'subreg' is a word-based accessor. > > Storing to a 'subreg' modifies all the words of REG that > > overlap the 'subreg', but it leaves the other words of REG > > alone. > > > But this wording applies only to multi-word registers. We can't use the > above wording for 512bit single-word register, since we don't know how the > move will affect the bits outside the subreg. We can say that the move > "modifies all the words of REG that overlap the 'subreg', since we have only > one 512-bit word of a 512-bit register. > OK. > So, I think that the transformation in the Comment 10 is invalid for > registers that can't be decomposed to independent word-sized registers (to > use "word-based accessor"), e.g. V32HImode xmm20. Perhaps the mentioned > alter_subreg should choose correct approach based on TARGET_HARD_REGNO_NREGS? Actually I do the same things as the old reload does. It has practically the same alter_subreg code. May be the reload and LRA code is not up to date to treat correctly this situation. I don't know. What I can do is to generate (strict_low_part (subreg:DI (reg:V32HI ))) to reflect the new semantics. Something like Index: lra.c === --- lra.c (revision 258691) +++ lra.c (working copy) @@ -487,14 +487,26 @@ int lra_curr_reload_num; void lra_emit_move (rtx x, rtx y) { - int old; - + int old, regno; + machine_mode mode; + rtx reg; + if (GET_CODE (y) != PLUS) { if (rtx_equal_p (x, y)) return; old = max_reg_num (); - emit_move_insn (x, y); + if (GET_CODE (x) == SUBREG + && REG_P (reg = SUBREG_REG (x)) + && GET_MODE_SIZE (mode = GET_MODE (reg)).to_constant () > UNITS_PER_WORD + && (regno = REGNO (reg)) >= FIRST_PSEUDO_REGISTER + && ira_reg_class_max_nregs[lra_get_allocno_class (regno)][mode] == 1) + { + x = gen_rtx_STRICT_LOW_PART (VOIDmode, x); + emit_insn (gen_rtx_SET (x, y)); + } + else + emit_move_insn (x, y); if (REG_P (x)) lra_reg_info[ORIGINAL_REGNO (x)].last_reload = ++lra_curr_reload_num; /* Function emit_move can create pseudos -- so expand the pseudo But we need insn patterns for such cases which are absent in i386 md files. Without adding them, compiler will crash in LRA.
[Bug middle-end/82976] [8 Regression] Error: non-trivial conversion at assignment since r254526
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82976 Andrew Pinski changed: What|Removed |Added Component|fortran |middle-end --- Comment #12 from Andrew Pinski --- match.pd looks like it has a type bug: /* Simplify pointer equality compares using PTA. */ (for neeq (ne eq) (simplify (neeq @0 @1) (if (POINTER_TYPE_P (TREE_TYPE (@0)) && ptrs_compare_unequal (@0, @1)) { neeq == EQ_EXPR ? boolean_false_node : boolean_true_node; }))) It assumes all types of EQ_EXPR/NE_EXPR will be boolean_type_node which is not true. It should be using constant_boolean_node (neeq != EQ_EXPR, type); .
[Bug c++/85269] New: warn for referenced standard symbols that aren't guaranteed to be declared in a header
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85269 Bug ID: 85269 Summary: warn for referenced standard symbols that aren't guaranteed to be declared in a header Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: msebor at gcc dot gnu.org Target Milestone: --- Unlike C, the C++ standard lets standard library implementations structure headers in whatever way is convenient for them, which extends to having any header include any other. As a result, writing non-trivial (and sometimes even trivial) C++ programs that are guaranteed to compile with any conforming C++ compiler can be tricky. For example, the following compiles successfully with libstdc++ even though it isn't guaranteed to compile: #include void f (std::locale); The following std::locale global; on the other hand doesn't compile with libstdc++ because std::locale is only declared in and not defined. It does, however, compile with Visual C++ which must be more "promiscuous" than libstdc++ in its header dependencies. There probably are examples that go the other way around. It occurs to me that the suggestions G++ issues in response to a program using a standard symbol without #including the appropriate header could also be used to provide a warning to help users find the most appropriate header to include to get each symbol declared. That way, the snippet above would trigger a warning pointing out that to use std::locale one should #include first even if the symbol happens to be declared in the header.
[Bug tree-optimization/85259] [8 Regression] Missing -Wstringop-overflow= since r256683
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85259 --- Comment #3 from Martin Sebor --- There are actually yet another couple of bugs at play here. In the test case compiled without -D_FORTIFY_SOURCE, strcpy(buf, "hello ") is folded into a MEM_REF by gimple_fold_builtin_strcpy() without checking to see if there's room in the destination, so that's not diagnosed. If the subsequent strcat() doesn't append more characters than would fit in the destination if it were empty the strcat() also isn't diagnosed because it too is folded, this time by gimple_fold_builtin_strcat() and into __builtin_memcpy. At the time it's folded the length of the string to which it's being appended is not available. When __builtin_memcpy() is handled in tree-ssa-strlen it should be able to warn on the overflow because it should have access to the length of the destination string and it knows the length of the source. But strlen doesn't know how to deal with MEM_REF (either due to bug 77357 or one of the other strlen missing optimizations tracked under the meta bug 83819), and even if it did, handle_builtin_memcpy() in strlen doesn't do any overflow checking. Finally, at the time the overflow checking is done during expansion in builtins.c, although the length of the destination string that __builtin_memcpy is being called to append to isn't accessible anymore, the memcpy destination is &a + 4 which is too simple for compute_builtin_object_size() to handle (it handles non-constant offsets but not the trivial constant case). This works in GCC 7 where the destination is &MEM[(void *)&a + 4B] that compute_builtin_object_size() does know how to deal with. Phew! So with all these gaps the following isn't diagnosed in GCC 8 while it is caught in GCC 7. $ cat x.c && gcc -O2 -S -Wall -fdump-tree-optimized=/dev/stdout x.c char a[4]; void f (void) { __builtin_strcpy (a, "1234"); __builtin_strcat (a, "567"); } ;; Function f (f, funcdef_no=0, decl_uid=1959, cgraph_uid=0, symbol_order=1) f () { char[4] * _4; [local count: 1073741825]: MEM[(char * {ref-all})&a] = MEM[(char * {ref-all})"1234"]; _4 = &a + 4; __builtin_memcpy (_4, "567", 4); [tail call] return; }
[Bug target/80022] arc: diagnostic ending in two periods
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80022 --- Comment #1 from Andrew Pinski --- *** Bug 85268 has been marked as a duplicate of this bug. ***
[Bug target/85268] Typo in "PIC is not supported"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85268 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Andrew Pinski --- Already filed by you as bug 80022. *** This bug has been marked as a duplicate of bug 80022 ***
[Bug target/85268] Typo in "PIC is not supported"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85268 --- Comment #1 from Andrew Pinski --- Except warning should not have any.
[Bug target/85268] New: Typo in "PIC is not supported"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85268 Bug ID: 85268 Summary: Typo in "PIC is not supported" Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: roland.illig at gmx dot de Target Milestone: --- From config/arc/arc.c: warning (DK_WARNING, "PIC is not supported for %s. Generating non-PIC code only..", arc_cpu_string); There can only be one period at the end of a sentence.
[Bug tree-optimization/85267] Untranslatable strings in verify_variant_match
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85267 Roland Illig changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Roland Illig --- Resolving a bug as a duplicate requires a comment, so here it is. /* This is a comment. */ *** This bug has been marked as a duplicate of bug 80021 ***
[Bug tree-optimization/80021] untranslateable diagnostic "type variant differs by " #flag "."
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80021 --- Comment #2 from Roland Illig --- *** Bug 85267 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/85267] Untranslatable strings in verify_variant_match
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85267 --- Comment #2 from Roland Illig --- Exact duplicate of #80021, which was just missing the keyword "verify_variant_match".
[Bug tree-optimization/85267] Untranslatable strings in verify_variant_match
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85267 --- Comment #1 from Andrew Pinski --- This is another one of these error which should be an inform or sorry that only comes out when dealing with internal compiler errors. There is another bug about this case.
[Bug tree-optimization/85267] New: Untranslatable strings in verify_variant_match
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85267 Bug ID: 85267 Summary: Untranslatable strings in verify_variant_match Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: roland.illig at gmx dot de Target Milestone: --- From tree.c: #define verify_variant_match(flag) \ do { \ if (flag (tv) != flag (t)) \ { \ error ("type variant differs by " #flag "."); \ debug_tree (tv);\ return false; \ } \ } while (false) Since GNU Gettext does not expand macro parameters, it extracts the following message for translation: msgid "type variant differs by " This message ID is useless because it never occurs in practice. Proper fix: Never use error() with macro parameters.
[Bug target/85236] missing _mm256_atan2_ps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85236 --- Comment #5 from Marc Glisse --- (In reply to bking from comment #4) > I understand that is a part of SVML, but doesn't that mean using the Intel > Compiler? Which means not using GCC. Is there not a plan to add it? Or is > that the intent of glibc? As Richard said, yes, the current situation is that this would fit much better in glibc's libmvec. It already provides vector versions of sin, cos, exp, log, pow and sincos (under different names than SVML), it should be extended to more functions. Another possibility would be to link to Intel's SVML when it is present. Although gcc already has a way to use SVML for autovectorization, it isn't clear in this particular case whether it is something the compiler should provide, the library vendor (Intel), or the user.
[Bug c++/85110] Missing underlines for some bad arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85110 --- Comment #4 from David Malcolm --- Candidate patch: https://gcc.gnu.org/ml/gcc-patches/2018-04/msg00342.html
[Bug tree-optimization/85259] [8 Regression] Missing -Wstringop-overflow= since r256683
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85259 Martin Sebor changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org --- Comment #2 from Martin Sebor --- I'm testing a fix for both problems.
[Bug tree-optimization/85259] [8 Regression] Missing -Wstringop-overflow= since r256683
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85259 Martin Sebor changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |NEW Last reconfirmed||2018-04-06 Ever confirmed|0 |1 --- Comment #1 from Martin Sebor --- With -Wno-system-headers GCC 8 prints: In file included from /usr/include/string.h:635, from pr85259.c:1: In function ‘strcat’, inlined from ‘main’ at pr85259.c:8:3: /usr/include/bits/string3.h:148:10: warning: ‘__builtin___memcpy_chk’ forming offset [7, 13] is out of the bounds [0, 6] of object ‘buf’ with type ‘char[6]’ [-Warray-bounds] return __builtin___strcat_chk (__dest, __src, __bos (__dest)); ^~ pr85259.c: In function ‘main’: pr85259.c:3:6: note: ‘buf’ declared here char buf[6]; ^~~ This is better but it's a warning for the strcat call while there should be a warning for the strcpy() call first because it overflows the buffer. A bug in handle_builtin_strcpy() in tree-ssa-strlen causes GCC to miss this case. So there are two bugs in play here: the system header suppression and the detection of strcpy overflow with a string literal.
[Bug target/85236] missing _mm256_atan2_ps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85236 --- Comment #4 from bking at rtlogic dot com --- I understand that is a part of SVML, but doesn't that mean using the Intel Compiler? Which means not using GCC. Is there not a plan to add it? Or is that the intent of glibc?
[Bug c++/85265] New: [concepts] ICE with missing identifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85265 Bug ID: 85265 Summary: [concepts] ICE with missing identifier Product: gcc Version: 8.0 Status: UNCONFIRMED Keywords: error-recovery, ice-on-invalid-code Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: reichelt at gcc dot gnu.org Blocks: 67491 Target Milestone: --- The following invalid code snippet (compiled with "-fconcepts") triggers an ICE since GCC 6.1.0: = template concept bool C = true; C{} void foo(); = bug99.cc:3:3: error: expected identifier before '}' token C{} void foo(); ^ bug99.cc:3:3: internal compiler error: tree check: expected identifier_node, have error_mark in find_local_binding, at cp/name-lookup.c:143 0x78cf20 tree_check_failed(tree_node const*, char const*, int, char const*, ...) ../../gcc/gcc/tree.c:9322 0x620722 tree_check(tree_node*, char const*, int, char const*, tree_code) ../../gcc/gcc/tree.h:3135 0x620722 find_local_binding ../../gcc/gcc/cp/name-lookup.c:143 0x9085f2 do_pushdecl ../../gcc/gcc/cp/name-lookup.c:2998 0x9085f2 pushdecl(tree_node*, bool) ../../gcc/gcc/cp/name-lookup.c:3148 0x95f65a process_template_parm(tree_node*, unsigned int, tree_node*, bool, bool) ../../gcc/gcc/cp/pt.c:4432 0x86575d process_introduction_parm ../../gcc/gcc/cp/constraint.cc:1376 0x86575d finish_template_introduction(tree_node*, tree_node*) ../../gcc/gcc/cp/constraint.cc:1408 0x944368 cp_parser_template_introduction ../../gcc/gcc/cp/parser.c:27066 0x944368 cp_parser_template_declaration_after_export ../../gcc/gcc/cp/parser.c:27170 0x949714 cp_parser_declaration ../../gcc/gcc/cp/parser.c:12767 0x949b31 cp_parser_declaration_seq_opt ../../gcc/gcc/cp/parser.c:12648 0x949e24 cp_parser_translation_unit ../../gcc/gcc/cp/parser.c:4563 0x949e24 c_parse_file() ../../gcc/gcc/cp/parser.c:39029 0xa49bb6 c_common_parse_file() ../../gcc/gcc/c-family/c-opts.c:1132 Please submit a full bug report, [etc.] Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491 [Bug 67491] [meta-bug] concepts issues
[Bug c++/85266] New: Inconsistent _Pragma behavior for macro with and without arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85266 Bug ID: 85266 Summary: Inconsistent _Pragma behavior for macro with and without arguments Product: gcc Version: 7.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: sdaniel.cole at gmail dot com Target Milestone: --- I'm trying to use the _Pragma operator to disable warnings for code inside a macro. It seems to work when the macro has no arguments (without parenthesis), but doesn't work when it has arguments (even having empty parenthesis causes the change in behavior). The following works as expected (shadow warning disabled for macro only): struct RAII{ RAII(); ~RAII(); }; #define RAII_BLOCK \ _Pragma("GCC diagnostic push \"-Wshadow\"") \ _Pragma("GCC diagnostic ignored \"-Wshadow\"") \ auto a = RAII();\ _Pragma("GCC diagnostic pop") void foo() { RAII_BLOCK; { RAII_BLOCK; } } The following doesn't work as expected (a warning is still generated): struct RAII{ RAII(); ~RAII(); }; #define RAII_BLOCK()\ _Pragma("GCC diagnostic push \"-Wshadow\"") \ _Pragma("GCC diagnostic ignored \"-Wshadow\"") \ auto a = RAII();\ _Pragma("GCC diagnostic pop") void foo() { RAII_BLOCK(); { RAII_BLOCK(); } } I compile the above using: g++ -c test.cpp -Wshadow https://godbolt.org/g/D22MYu
[Bug gcov-profile/85245] [GCOV] A return statement in the if(0) block is wrongly marked as executed when they are nested in the true block of if (cond-expression) statement in gcov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85245 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-04-06 Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Target Milestone|--- |9.0 Ever confirmed|0 |1
[Bug gcov-profile/85243] [GCOV] A return statement in the if(0) block is wrongly marked as executed when prefixed with an array declaration statement and followed by a "for(;cond-expression;) return;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85243 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-04-06 Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Target Milestone|--- |9.0 Ever confirmed|0 |1
[Bug sanitizer/84428] ==7122==AddressSanitizer CHECK failed: ../../../sanitizer/asan/asan_interceptors.cc:384 "((__interception::real___cxa_throw)) != (0)" (0x0, 0x0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84428 Martin Liška changed: What|Removed |Added Keywords||needs-bisection Known to work||8.0 Known to fail||7.3.0 --- Comment #20 from Martin Liška --- It's good that it works with current trunk, so I'll bisect that..
[Bug libfortran/85253] [8 Regression] asan detects heap-buffer-overflow in matmul_r4.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85253 Thomas Koenig changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Thomas Koenig --- Fixed, closing. Thanks for the bug report!
[Bug libfortran/85253] [8 Regression] asan detects heap-buffer-overflow in matmul_r4.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85253 --- Comment #5 from Thomas Koenig --- Author: tkoenig Date: Fri Apr 6 18:49:21 2018 New Revision: 259188 URL: https://gcc.gnu.org/viewcvs?rev=259188&root=gcc&view=rev Log: 2018-04-06 Thomas Koenig PR libfortran/85253 * m4/matmul_internal.m4: If ycount == 1, add one more row to the internal buffer. * generated/matmul_c10.c: Regenerated. * generated/matmul_c16.c: Regenerated. * generated/matmul_c4.c: Regenerated. * generated/matmul_c8.c: Regenerated. * generated/matmul_i1.c: Regenerated. * generated/matmul_i16.c: Regenerated. * generated/matmul_i2.c: Regenerated. * generated/matmul_i4.c: Regenerated. * generated/matmul_i8.c: Regenerated. * generated/matmul_r10.c: Regenerated. * generated/matmul_r16.c: Regenerated. * generated/matmul_r4.c: Regenerated. * generated/matmul_r8.c: Regenerated. * generated/matmulavx128_c10.c: Regenerated. * generated/matmulavx128_c16.c: Regenerated. * generated/matmulavx128_c4.c: Regenerated. * generated/matmulavx128_c8.c: Regenerated. * generated/matmulavx128_i1.c: Regenerated. * generated/matmulavx128_i16.c: Regenerated. * generated/matmulavx128_i2.c: Regenerated. * generated/matmulavx128_i4.c: Regenerated. * generated/matmulavx128_i8.c: Regenerated. * generated/matmulavx128_r10.c: Regenerated. * generated/matmulavx128_r16.c: Regenerated. * generated/matmulavx128_r4.c: Regenerated. * generated/matmulavx128_r8.c: Regenerated. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/generated/matmul_c10.c trunk/libgfortran/generated/matmul_c16.c trunk/libgfortran/generated/matmul_c4.c trunk/libgfortran/generated/matmul_c8.c trunk/libgfortran/generated/matmul_i1.c trunk/libgfortran/generated/matmul_i16.c trunk/libgfortran/generated/matmul_i2.c trunk/libgfortran/generated/matmul_i4.c trunk/libgfortran/generated/matmul_i8.c trunk/libgfortran/generated/matmul_r10.c trunk/libgfortran/generated/matmul_r16.c trunk/libgfortran/generated/matmul_r4.c trunk/libgfortran/generated/matmul_r8.c trunk/libgfortran/generated/matmulavx128_c10.c trunk/libgfortran/generated/matmulavx128_c16.c trunk/libgfortran/generated/matmulavx128_c4.c trunk/libgfortran/generated/matmulavx128_c8.c trunk/libgfortran/generated/matmulavx128_i1.c trunk/libgfortran/generated/matmulavx128_i16.c trunk/libgfortran/generated/matmulavx128_i2.c trunk/libgfortran/generated/matmulavx128_i4.c trunk/libgfortran/generated/matmulavx128_i8.c trunk/libgfortran/generated/matmulavx128_r10.c trunk/libgfortran/generated/matmulavx128_r16.c trunk/libgfortran/generated/matmulavx128_r4.c trunk/libgfortran/generated/matmulavx128_r8.c trunk/libgfortran/m4/matmul_internal.m4
[Bug sanitizer/84428] ==7122==AddressSanitizer CHECK failed: ../../../sanitizer/asan/asan_interceptors.cc:384 "((__interception::real___cxa_throw)) != (0)" (0x0, 0x0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84428 Martin Liška changed: What|Removed |Added Status|WAITING |ASSIGNED Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org --- Comment #19 from Martin Liška --- Great job. I can confirm that and I'll work on that after upcoming weekend.
[Bug c++/85214] [7/8 Regression] ICE on valid C++17 code on x86_64-linux-gnu: in tsubst_copy, at cp/pt.c:14562
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85214 --- Comment #3 from Jason Merrill --- Author: jason Date: Fri Apr 6 18:09:53 2018 New Revision: 259185 URL: https://gcc.gnu.org/viewcvs?rev=259185&root=gcc&view=rev Log: PR c++/85214 - ICE with alias, generic lambda, constexpr if. Here, since the condition for the constexpr if depends on the type of 'j', it's still dependent when we are partially instantiating the inner lambda, so we need to defer instantiating the constexpr if. When we instantiated the inner lambda, we tried to substitute into the typename, which failed because we didn't have a declaration of 'i' available. Fixed by teaching extract_locals_r to capture local typedefs such as 'ar'; if we have the typedef handy, we don't need to substitute into its definition. * pt.c (extract_locals_r): Remember local typedefs. Added: trunk/gcc/testsuite/g++.dg/cpp1z/constexpr-if20.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c
[Bug c++/81764] [6/7/8 Regression] Visibility attributes for explicitly instantiated template class get warned if it has been implicitly instantiated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81764 --- Comment #3 from Martin Sebor --- This is another one of those cases where implementations diverge: Clang and ICC silently accept the program in comment #0 and give an error for the one in comment #1. GCC issues -Wattributes for both. MSVC silently accepts the program in comment #1 but gives a warning when the alignment specified on the specialization is different than on the primary. MSVC doesn't understand visibility attributes but it does accept __declspec dllexport and dllimport. It allows the example in comment #0 with __declspec (dllimport) and also with the primary declared dllexport and the instantiation declared dllimport. That makes sense because both declarations would typically appear this way in a library header and an explicit instantiation directive declared dllexport in some source file of the library. The C++ constraint that "no attribute-specifier-seq shall appertain to an explicit instantiation" disallows this use case (one of the main uses cases in Windows class template DLLs). GCC for i686-pc-cygwin also issues a warning for this modified test case and so is incompatible with MSVC: $ cat pr81764.C && i686-pc-cygwin-g++ -S -Wall pr81764.C template class g; template class __declspec (dllexport) g { g() = default; static int f(int x) { return g<>::yyy::u(x); // g<> instantiated here } struct yyy { static int u(int x){ return x+ sizeof...(T); } }; }; extern template class __declspec (dllimport) g<>; template class g<>; pr81764.C:22:46: warning: type attributes ignored after type is already defined [-Wattributes] extern template class __declspec (dllimport) g<>; ^~~
[Bug c++/85227] [7/8 Regression] ICE with structured binding of a forward declared variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85227 Jason Merrill changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |paolo.carlini at oracle dot com Target Milestone|--- |7.4 Summary|[7/8/ Regression] ICE with |[7/8 Regression] ICE with |structured binding of a |structured binding of a |forward declared variable |forward declared variable
[Bug c++/84269] More suggestions for missing #include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84269 David Malcolm changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #14 from David Malcolm --- r259184 should cover everything so far; closing this one out.
[Bug c++/84269] More suggestions for missing #include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84269 --- Comment #13 from David Malcolm --- Author: dmalcolm Date: Fri Apr 6 17:36:33 2018 New Revision: 259184 URL: https://gcc.gnu.org/viewcvs?rev=259184&root=gcc&view=rev Log: C++: more std header hints; filter on C++ dialect (PR c++/84269) This patch adds more suggestions as per: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84269#c10 some of which need C++14 and C++17, and some of which use headers that exist in earlier standards. For example, exists in C++98, but if the user attempts to use std::make_shared with -std=c++98, they are suggested to include , even if they've already included it. This patch adds the missing names, and fixes the nonsensical suggestions by detecting if the name isn't available yet, based on the user's dialect, and reporting things more intelligently: t.cc: In function 'void test_make_shared()': t.cc:5:8: error: 'make_shared' is not a member of 'std' std::make_shared(); ^~~ t.cc:5:8: note: 'std::make_shared' is only available from C++11 onwards gcc/cp/ChangeLog: PR c++/84269 * name-lookup.c (struct std_name_hint): Move out of get_std_name_hint; add field "min_dialect". (get_std_name_hint): Add min_dialect values to all initializers. Add , , , , , , , , , , , , , , and . Add fstream, ifstream, and ofstream to . Add istringstream, ostringstream, and stringstream to . Add basic_string to . Add tuple_element and tuple_size to . Add declval to . Fix ordering of and . Return a std_name_hint, rather than a const char *. (get_cxx_dialect_name): New function. (maybe_suggest_missing_std_header): Detect names that aren't yet available in the current dialect, and instead of suggesting a missing #include, warn about the dialect. gcc/testsuite/ChangeLog: PR c++/84269 * g++.dg/lookup/missing-std-include-6.C: Move std::array and std::tuple here since they need C++11. * g++.dg/lookup/missing-std-include-8.C: New test. * g++.dg/lookup/missing-std-include.C: Move std::array and std::tuple test to missing-std-include-6.C to avoid failures with C++98. Added: trunk/gcc/testsuite/g++.dg/lookup/missing-std-include-8.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/name-lookup.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/lookup/missing-std-include-6.C trunk/gcc/testsuite/g++.dg/lookup/missing-std-include.C
[Bug debug/85252] [6/7 Regression] ICE with -g for static zero-length array initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85252 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P2 Summary|[6/7/8 Regression] ICE with |[6/7 Regression] ICE with |-g for static zero-length |-g for static zero-length |array initialization|array initialization --- Comment #7 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug rtl-optimization/85099] [meta-bug] selective scheduling issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85099 Bug 85099 depends on bug 84872, which changed state. Bug 84872 Summary: [8 Regression] ICE in create_preheader, at cfgloopmanip.c:1536 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84872 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/85210] [7 Regression] ICE with broken structured binding in template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85210 Jakub Jelinek changed: What|Removed |Added Summary|[7/8 Regression] ICE with |[7 Regression] ICE with |broken structured binding |broken structured binding |in template |in template --- Comment #5 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug rtl-optimization/84872] [8 Regression] ICE in create_preheader, at cfgloopmanip.c:1536
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84872 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Jakub Jelinek --- Fixed.
[Bug debug/85252] [6/7/8 Regression] ICE with -g for static zero-length array initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85252 --- Comment #6 from Jakub Jelinek --- Author: jakub Date: Fri Apr 6 17:28:54 2018 New Revision: 259183 URL: https://gcc.gnu.org/viewcvs?rev=259183&root=gcc&view=rev Log: PR debug/85252 * dwarf2out.c (rtl_for_decl_init): For STRING_CST initializer only build CONST_STRING if TYPE_MAX_VALUE is non-NULL and is INTEGER_CST. * gcc.dg/debug/pr85252.c: New test. Added: trunk/gcc/testsuite/gcc.dg/debug/pr85252.c Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/84872] [8 Regression] ICE in create_preheader, at cfgloopmanip.c:1536
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84872 --- Comment #4 from Jakub Jelinek --- Author: jakub Date: Fri Apr 6 17:28:02 2018 New Revision: 259182 URL: https://gcc.gnu.org/viewcvs?rev=259182&root=gcc&view=rev Log: PR rtl-optimization/84872 * cfgloopmanip.c (create_preheader): Use make_forwarder_block even if nentry == 1 when CP_FALLTHRU_PREHEADERS and single_entry is EDGE_CROSSING edge. * gcc.dg/graphite/pr84872.c: New test. Added: trunk/gcc/testsuite/gcc.dg/graphite/pr84872.c Modified: trunk/gcc/ChangeLog trunk/gcc/cfgloopmanip.c trunk/gcc/testsuite/ChangeLog
[Bug c++/85210] [7/8 Regression] ICE with broken structured binding in template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85210 --- Comment #4 from Jakub Jelinek --- Author: jakub Date: Fri Apr 6 17:27:01 2018 New Revision: 259181 URL: https://gcc.gnu.org/viewcvs?rev=259181&root=gcc&view=rev Log: PR c++/85210 * pt.c (tsubst_decomp_names): Return error_mark_node and assert errorcount is set if tsubst doesn't return a VAR_DECL. * g++.dg/cpp1z/decomp42.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp1z/decomp42.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog
[Bug c/85260] [8 Regression] python-2.7.14 miscompiled at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85260 David Malcolm changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #3 from David Malcolm --- This is a bug in CPython: the code is assuming 16-byte alignment, but the allocator only guarantees 8-byte alignment: https://bugs.python.org/issue27987 https://bugs.python.org/issue31912 https://mail.python.org/pipermail/python-dev/2018-January/152011.html
[Bug c++/57728] Explicit template instantiation with defaulted method causes missing symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57728 Jason Merrill changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |6.3 --- Comment #16 from Jason Merrill --- Yes.
[Bug c/85260] [8 Regression] python-2.7.14 miscompiled at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85260 Jakub Jelinek changed: What|Removed |Added CC||dmalcolm at gcc dot gnu.org, ||rsandifo at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Actually, it seems to be a python bug to me. Reduced testcase: typedef struct S { long ob_refcnt; void *ob_type; void *in_class; void *in_dict; void *in_weakreflist; } PyClassObject; PyClassObject *foo (void); typedef union U { struct { union U *gc_next; union U *gc_prev; long gc_refs; } gc; long double dummy; } PyGC_Head; void * bar (void *klass, void *dict) { PyClassObject *inst = foo (); inst->in_class = klass; inst->in_dict = dict; PyGC_Head *g = (PyGC_Head *)inst - 1; g->gc.gc_prev->gc.gc_next = g; return inst; } While PyClassObject seems to have 8-byte alignment, the code assumes there is a PYGC_Head object in front of it, and that because of the long double member has 16-byte alignment. So, I believe if the function (_PyObject_GC_New in the original testcase) returns something that is not 16-byte aligned, which is what happens when it segfaults, then it is an application bug - UB because g->gc.gc_prev is then access to misaligned *g. Richard's changes derive alignment information from that access and assume that inst must be also 16-byte aligned.
[Bug c++/82152] [7 Regression] ICE on invalid code in C++17 mode if inheriting constructors are used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82152 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Jason Merrill --- Fixed.
[Bug c/85260] [8 Regression] python-2.7.14 miscompiled at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85260 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P1 Status|UNCONFIRMED |NEW Last reconfirmed||2018-04-06 CC||jakub at gcc dot gnu.org Target Milestone|--- |8.0 Summary|8.0: python-2.7.14 |[8 Regression] |miscompiled at -O3 |python-2.7.14 miscompiled ||at -O3 Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Seems to have started with r250870, it is slp2 that creates a vector store that needs 16-byte alignment, but the pointer is only 8-byte aligned. Will try to minimize a testcase.
[Bug c++/85262] [6/7/8 Regression] Trouble with constructor and -fpermissive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85262 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-04-06 CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org Target Milestone|--- |6.5 Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Started to ICE with r251438.
[Bug c++/85264] [7/8 Regression] ICE with extraneous template parameter list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85264 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-04-06 CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org Target Milestone|--- |7.4 Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Started to ICE with r235213.
[Bug target/85261] __builtin_arm_set_fpscr ICEs with constant input
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85261 Thomas Preud'homme changed: What|Removed |Added Known to fail||6.4.1, 7.3.1 --- Comment #3 from Thomas Preud'homme --- (In reply to Ramana Radhakrishnan from comment #2) > What about earlier branches ? Oh yes, forgot the previous fpscr fix was also backported.
[Bug target/85261] __builtin_arm_set_fpscr ICEs with constant input
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85261 Ramana Radhakrishnan changed: What|Removed |Added CC||ramana at gcc dot gnu.org --- Comment #2 from Ramana Radhakrishnan --- What about earlier branches ?
Your Weekly Breeze - April. 05 - April. 11
This email newsletter was sent to you in graphical HTML format. If you're seeing this version, your email program prefers plain text emails. You can read the original version online: http://ymlpsend3.com/zFW1Ci Having problems viewing Weekly Breeze Click here ( http://myoasisliving.com/weekly_breeze/weekly_breeze.php ). TOP PICS Apr 05 - Apr 11 "Never be bullied into silence. Never allow yourself to be made a victim. Accept no one's definition of your life; define yourself." — Harvey Fierstein, American actor and playwright The world at his fingertips Oasis Living chatted to Shaun Agostine, a child prodigy who made his first professional tour as a pianist at the ripe old age of eight >> ( http://myoasisliving.com/en/article/article_detail/article_id_enc/e3c360f6517bdf2a233ca8cdcd99 ) Spruce up for spring With the cooler months passing and the high heat of summer imminent, take advantage of these breezy and energised months to redecorate >> ( http://myoasisliving.com/en/news/news_detail/news_id_enc/bcbf2b3187e12154b1401ef156b ) A month to remember A recap of last month’s happenings at the Al Ain Rugby Club >> ( http://myoasisliving.com/en/news/news_detail/news_id_enc/1234bcbf2b3187e12154b1401ef156b ) Riding into the past Behind the Garden City’s frst train tour operator >> ( http://myoasisliving.com/en/news/news_detail/news_id_enc/bcbf2b3187e12154b1401ef156b ) Trailblazing success Al Ain’s finest earn places among the world >> ( http://myoasisliving.com/en/news/news_detail/news_id_enc/bcbf2b3187e12154b1401ef156b ) "AGENDA" Thursday Zip in and Out Lunch in Aloft Al Ain’s Olive Tree from 12 to 5pm: Dh61 per including two courses and soft drinks. Later, it’s Seafood Night from 7 to 11pm: Dh199 per person. An Evening Brunch is available at Al Ain Rotana’s Zest from 6:30 to 11pm: Dh187++ including soft drinks, Dh220++ including grape and hops. And it’s Moodz in the City in the hotel’s Moodz from 7pm to 3.30am: Dh100 including two drinks. Happy Hour in Danat Al Ain Resort's McGettigan’s from 5 to 8pm with 40 per cent off all house drinks, and it’s also Teacher’s Night there from 2 to 10pm with a 20 per cent discount offer. Thursday BBQ Buffet in The Palm Greens Restaurant at AESGC’s Golf Club from 6.30 to 10.30pm: Dh199 per person with free-flow of one selected beverage, Dh99 with free-flow of soft drinks - members discount also applies on total bill. Lebanese Night in Al Rikab Restaurant at AESGC’s Equestrian Club from 10pm to 3.30am: Dh100 per person with cold and hot meza; Dh150 with cold meza, mixed grills, fruits and sweets - live entertainment available. Family Dining Night in AESGC's Rugby Club's Amblers Restaurant from 5.30pm with a 20 per cent discount for families. Seafood Extravaganza at Hilton Al Ain’s Flavours from 7 to 11pm: Dh139++. It’s also Sizzling Thursday in the hotel’s Paco’s from 4pm to 2am: Dh60++. Friday Friday Brunch in Zest at Al Ain Rotana from 12.30 to 3.30pm: Dh212++ depending on drinks package. And Hinky Dinks Friday Brunch in the hotel’s Trader Vic’s featuring four starters, four main courses and dessert samples with unlimited cocktails, mocktails, reds, whites, and malt beverages: 12.30 to 4.30pm: Dh312 per. Later, it's Hi5 Night in the hotel's Moodz from 7pm to 3.30am: Dh100 including two drinks. European Brunch in Aloft Al Ain’s Olive Tree from 11am to 2pm, Dh129, and It’s a Pizza Party later on from 7 to 11pm: Dh39 per pizza including a soft drink. Friday Brunch in Danat Al Ain Resort's McGettigan’s from 12 to 4.30pm: Dh152. It’s also Happy Hour in the same venue from 5 to 8pm with 40 per cent off all house drinks, and a Drunch buffet is also available: Dh99. Friday Family Buffet in Al Rikab Restaurant at AESGC’s Equestrian Club, from 12 to 6pm: Dh95 per person, Dh45 for kids aged six to 12 with live entertainment and outdoor activities kicking off at 4pm. And in the evening, it’s Iraqui Night in the same venue from 10pm to 3.30am: free entry for all. Friday Carving Day in Amblers Restaurant, AESGC's Rugby Club, from 1 to 5pm, Dh85 with free-flow of soft drinks, Dh155 with free-flow of one selected beverage. Friday Family Brunch in Hilton Al Ain’s Flavours from 1 to 4pm: Dh109++ including soft drinks; Dh149++ including house beverages. It’s also Unlimited Fridays in the hotel’s Paco’s for Dh150++ from 9pm to 12am. Saturday Arabian Night in Al Ain Rotana's Moodz from 7pm to 3.30am: Dh100 including two drinks. Saturday SOS in Danat Al Ain Resort's McGettigan’s from 12 to 5pm: Dh78. It’s also Happy Hour in the same venue from 5 to 8pm with 40 per cent off all house drinks. Saturday Roast from 1 to 4pm in Aloft Al Ain’s The Rooftop: Dh120++. Sunday Sunday Roast in Hilton Al Ain’s Paco’s from 5pm to 2am: Dh60++, Dh100++ with two hops. Mediterra
[Bug c++/85021] "Missing #include" hints for unrecognized names that would implicitly be in "std"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85021 David Malcolm changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #4 from David Malcolm --- Implemented for trunk (gcc 8) in r259179 (v2 of patch)
[Bug c++/85021] "Missing #include" hints for unrecognized names that would implicitly be in "std"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85021 --- Comment #3 from David Malcolm --- Author: dmalcolm Date: Fri Apr 6 15:46:04 2018 New Revision: 259179 URL: https://gcc.gnu.org/viewcvs?rev=259179&root=gcc&view=rev Log: C++: suggest missing headers for implicit use of "std" (PR c++/85021) We provide fix-it hints for the most common "std" names when an explicit "std::" prefix is present, however we don't yet provide fix-it hints for this implicit case: using namespace std; void f() { cout << "test"; } for which we emit: t.cc: In function 'void f()': t.cc:2:13: error: 'cout' was not declared in this scope void f() { cout << "test"; } ^~~~ This patch detects if a "using namespace std;" directive is present in the current namespace, and if so, offers a suggestion for unrecognized names that are in our list of common "std" names: t.cc: In function 'void f()': t.cc:2:13: error: 'cout' was not declared in this scope void f() { cout << "test"; } ^~~~ t.cc:2:13: note: 'std::cout' is defined in header ''; did you forget to '#include '? +#include using namespace std; void f() { cout << "test"; } ^~~~ gcc/cp/ChangeLog: PR c++/85021 * name-lookup.c (using_directives_contain_std_p): New function. (has_using_namespace_std_directive_p): New function. (suggest_alternatives_for): Simplify if/else logic using early returns. If no candidates were found, and there's a "using namespace std;" directive, call maybe_suggest_missing_std_header. (maybe_suggest_missing_header): Split later part of the function into.. (maybe_suggest_missing_std_header): New. gcc/testsuite/ChangeLog: PR c++/85021 * g++.dg/lookup/missing-std-include-7.C: New test. Added: trunk/gcc/testsuite/g++.dg/lookup/missing-std-include-7.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/name-lookup.c trunk/gcc/testsuite/ChangeLog
[Bug c++/85264] New: [7/8 Regression] ICE with extraneous template parameter list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85264 Bug ID: 85264 Summary: [7/8 Regression] ICE with extraneous template parameter list Product: gcc Version: 8.0 Status: UNCONFIRMED Keywords: accepts-invalid, ice-on-invalid-code Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: reichelt at gcc dot gnu.org Target Milestone: --- The following invalid code snippet triggers an ICE since GCC 7.1.0: = template struct A {}; template template struct A {}; A a; = bug.cc: In substitution of 'template > template struct A [with T = ; int = {int}]': bug.cc:6:14: required from here bug.cc:6:14: internal compiler error: in tsubst_pack_expansion, at cp/pt.c:11875 A a; ^ 0x644533 tsubst_pack_expansion(tree_node*, tree_node*, int, tree_node*) ../../gcc/gcc/cp/pt.c:11875 0x96952a tsubst_arg_types ../../gcc/gcc/cp/pt.c:13549 0x96973d tsubst_function_type ../../gcc/gcc/cp/pt.c:13711 0x96a1c3 tsubst(tree_node*, tree_node*, int, tree_node*) ../../gcc/gcc/cp/pt.c:14440 0x979422 tsubst_template_args ../../gcc/gcc/cp/pt.c:12137 0x96a855 tsubst(tree_node*, tree_node*, int, tree_node*) ../../gcc/gcc/cp/pt.c:14301 0x986c57 get_partial_spec_bindings ../../gcc/gcc/cp/pt.c:22385 0x987176 most_specialized_partial_spec ../../gcc/gcc/cp/pt.c:22618 0x99107f instantiate_class_template_1 ../../gcc/gcc/cp/pt.c:10567 0x99107f instantiate_class_template(tree_node*) ../../gcc/gcc/cp/pt.c:11100 0x9d8b6d complete_type(tree_node*) ../../gcc/gcc/cp/typeck.c:136 0x885e67 start_decl_1(tree_node*, bool) ../../gcc/gcc/cp/decl.c:5275 0x8ac107 start_decl(cp_declarator const*, cp_decl_specifier_seq*, int, tree_node*, tree_node*, tree_node**) ../../gcc/gcc/cp/decl.c:5238 0x93d1b3 cp_parser_init_declarator ../../gcc/gcc/cp/parser.c:19610 0x944988 cp_parser_simple_declaration ../../gcc/gcc/cp/parser.c:13049 0x945798 cp_parser_block_declaration ../../gcc/gcc/cp/parser.c:12874 0x949722 cp_parser_declaration ../../gcc/gcc/cp/parser.c:12772 0x949b31 cp_parser_declaration_seq_opt ../../gcc/gcc/cp/parser.c:12648 0x949e24 cp_parser_translation_unit ../../gcc/gcc/cp/parser.c:4563 0x949e24 c_parse_file() ../../gcc/gcc/cp/parser.c:39029 Please submit a full bug report, [etc.] Before, the code was wrongly accepted. If I use regular template parameters instead of parameter packs, the code is also wrongly accepted (since at least GCC 3.1.1).
[Bug target/84762] GCC for PowerPC32 violates the SysV ABI spec for small struct returns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84762 --- Comment #14 from Segher Boessenkool --- -msvr4-struct-return=standard and -msvr4-struct-return=compat, perhaps?
[Bug libfortran/85253] [8 Regression] asan detects heap-buffer-overflow in matmul_r4.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85253 --- Comment #4 from Vittorio Zecca --- After applying the fix in comment #3 the asan message disappeared.
[Bug tree-optimization/85257] [6/7/8 Regression] wrong code with -O -fno-tree-ccp and reading zeroed vector member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85257 --- Comment #2 from Jakub Jelinek --- Created attachment 43873 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43873&action=edit gcc8-pr85257.patch Untested fix, actually either of the fold-const.c or tree-ssa-sccvn.c changes is enough to fix this. The fold-const.c change is needed because when using 3 argument native_encode_expr, it is assumed that we return 0 whenever it didn't fit fully, which we violated for VECTOR_CSTs if length was exactly on a boundary between two elements. And the tree-ssa-sccvn.c change is an optimization, there is no reason to compute bytes we aren't interested in, and for larger VECTOR_CSTs like this one because of that not being able to optimize at all; we can use the 4 argument form instead and just compute the bytes we want; in that case the returned length can be just partial of what were asking for, so we need to verify it is enough for what we try to decode.
[Bug c++/85242] [6/7/8 Regression] ICE with invalid template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85242 --- Comment #2 from Jason Merrill --- Author: jason Date: Fri Apr 6 15:12:34 2018 New Revision: 259178 URL: https://gcc.gnu.org/viewcvs?rev=259178&root=gcc&view=rev Log: PR c++/85242 - ICE with class definition in template parm. * cp-tree.h (PROCESSING_REAL_TEMPLATE_DECL_P): False if processing_template_parmlist. Added: trunk/gcc/testsuite/g++.dg/template/error58.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h
[Bug c++/85240] [6/7 Regression] ICE with function without deduced return type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85240 --- Comment #1 from Jason Merrill --- Author: jason Date: Fri Apr 6 15:12:28 2018 New Revision: 259177 URL: https://gcc.gnu.org/viewcvs?rev=259177&root=gcc&view=rev Log: PR c++/85240 - LTO ICE with using of undeduced auto fn. * cp-gimplify.c (cp_genericize_r): Discard using of undeduced auto. Added: trunk/gcc/testsuite/g++.dg/cpp1y/auto-fn51.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-gimplify.c
[Bug c++/85263] New: [concepts] ICE with parameter pack matching
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85263 Bug ID: 85263 Summary: [concepts] ICE with parameter pack matching Product: gcc Version: 8.0 Status: UNCONFIRMED Keywords: error-recovery, ice-on-invalid-code Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: reichelt at gcc dot gnu.org Blocks: 67491 Target Milestone: --- The following invalid code snippet (compiled with "-fconcepts") triggers an ICE since GCC 6.1.0: === template concept bool C = true; C{A, B} void foo(); === bug.cc:3:3: error: cannot match pack for introduced parameter C{A, B} void foo(); ^ bug.cc:3:7: internal compiler error: tree check: accessed elt 1 of tree_vec with 0 elts in process_introduction_parm, at cp/constraint.cc:1325 C{A, B} void foo(); ^ 0x78f405 tree_vec_elt_check_failed(int, int, char const*, int, char const*) ../../gcc/gcc/tree.c:9520 0x5e94ec tree_vec_elt_check(tree_node*, int, char const*, int, char const*) ../../gcc/gcc/tree.h:3356 0x5e94ec process_introduction_parm ../../gcc/gcc/cp/constraint.cc:1325 0x5e94ec finish_template_introduction(tree_node*, tree_node*) ../../gcc/gcc/cp/constraint.cc:1408 0x944368 cp_parser_template_introduction ../../gcc/gcc/cp/parser.c:27066 0x944368 cp_parser_template_declaration_after_export ../../gcc/gcc/cp/parser.c:27170 0x949714 cp_parser_declaration ../../gcc/gcc/cp/parser.c:12767 0x949b31 cp_parser_declaration_seq_opt ../../gcc/gcc/cp/parser.c:12648 0x949e24 cp_parser_translation_unit ../../gcc/gcc/cp/parser.c:4563 0x949e24 c_parse_file() ../../gcc/gcc/cp/parser.c:39029 0xa49bb6 c_common_parse_file() ../../gcc/gcc/c-family/c-opts.c:1132 Please submit a full bug report, [etc.] Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491 [Bug 67491] [meta-bug] concepts issues
[Bug libfortran/85253] [8 Regression] asan detects heap-buffer-overflow in matmul_r4.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85253 --- Comment #3 from Thomas Koenig --- Yep, looking at the code, it seems that in this special case, we need one more row in the temporary buffer. This seems to cure it. Index: m4/matmul_internal.m4 === --- m4/matmul_internal.m4 (Revision 259152) +++ m4/matmul_internal.m4 (Arbeitskopie) @@ -234,7 +234,7 @@ sinclude(`matmul_asm_'rtype_code`.m4')dnl /* Adjust size of t1 to what is needed. */ index_type t1_dim; - t1_dim = (a_dim1-1) * 256 + b_dim1; + t1_dim = (a_dim1- (ycount > 1)) * 256 + b_dim1; if (t1_dim > 65536) t1_dim = 65536;
[Bug c++/85262] New: [6/7/8 Regression] Trouble with constructor and -fpermissive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85262 Bug ID: 85262 Summary: [6/7/8 Regression] Trouble with constructor and -fpermissive Product: gcc Version: 8.0 Status: UNCONFIRMED Keywords: ice-on-valid-code, rejects-valid Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: reichelt at gcc dot gnu.org Target Milestone: --- The following valid code snippet (compiled with "-fpermissive") triggers an ICE on trunk: struct A {}; template struct B : A { B() { A::A(A()); } }; B<0> b; bug.cc: In constructor 'B< >::B()': bug.cc:7:13: warning: cannot call constructor 'A::A' directly [-fpermissive] A::A(A()); ^ bug.cc:7:13: note: for a function-style cast, remove the redundant '::A' bug.cc: In instantiation of 'B< >::B() [with int = 0]': bug.cc:11:6: required from here bug.cc:7:10: internal compiler error: in tsubst_copy, at cp/pt.c:15625 A::A(A()); ^~~ 0x63a8eb tsubst_copy ../../gcc/gcc/cp/pt.c:15625 0x96682b tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool, bool) ../../gcc/gcc/cp/pt.c:18658 0x967f8c tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool, bool) ../../gcc/gcc/cp/pt.c:18295 0x965a11 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool, bool) ../../gcc/gcc/cp/pt.c:17543 0x971627 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool) ../../gcc/gcc/cp/pt.c:17099 0x97092e tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool) ../../gcc/gcc/cp/pt.c:16300 0x96e71f tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool) ../../gcc/gcc/cp/pt.c:16583 0x97005c tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool) ../../gcc/gcc/cp/pt.c:16286 0x96e71f tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool) ../../gcc/gcc/cp/pt.c:16583 0x96d8b8 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool) ../../gcc/gcc/cp/pt.c:16271 0x96d8b8 instantiate_decl(tree_node*, bool, bool) ../../gcc/gcc/cp/pt.c:23682 0x99476b instantiate_pending_templates(int) ../../gcc/gcc/cp/pt.c:23798 0x8b8e3b c_parse_final_cleanups() ../../gcc/gcc/cp/decl2.c:4725 Please submit a full bug report, [etc.] In GCC 6 and GCC 7 the code is wrongly rejected (when parsing the template, the call to A::A is accepted with "-fpermissive", but at instantiation time it is rejected) while a version without template compiles: bug.cc: In constructor 'B< >::B()': bu5.cc:7:13: warning: cannot call constructor 'A::A' directly [-fpermissive] A::A(A()); ^ bug.cc:7:13: note: for a function-style cast, remove the redundant '::A' bug.cc: In instantiation of 'B< >::B() [with int = 0]': bug.cc:11:6: required from here bug.cc:7:9: error: cannot call constructor 'A::A' directly A::A(A()); ^
[Bug ipa/84149] [8 Regression] SPEC CPU2017 505.mcf/605.mcf ~10% performance regression with r256888
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84149 Martin Jambor changed: What|Removed |Added Attachment #43588|0 |1 is obsolete|| --- Comment #8 from Martin Jambor --- Created attachment 43872 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43872&action=edit Current patch This patch, which speeds up mcf and which is more consistent with the IPA-CP design and does not miscompile mcf, has passed LTO bootstrap and testing, I will try it on a few bigger applications and submit it shortly afterwards.
[Bug libfortran/85253] [8 Regression] asan detects heap-buffer-overflow in matmul_r4.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85253 Thomas Koenig changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot gnu.org --- Comment #2 from Thomas Koenig --- Probably my memory saving patch. I'll investigate.
[Bug c++/85214] [7/8 Regression] ICE on valid C++17 code on x86_64-linux-gnu: in tsubst_copy, at cp/pt.c:14562
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85214 --- Comment #2 from Jason Merrill --- Further reduced: struct g { constexpr operator int() { return true; } }; template constexpr bool m = true; template struct C { typedef double q; }; void ao() { [](auto i) { using ar = typename C::q; [](auto j) { using as = typename C::q; if constexpr (m) {} }(g()); }(g()); }
[Bug target/85261] __builtin_arm_set_fpscr ICEs with constant input
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85261 Thomas Preud'homme changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-04-06 Ever confirmed|0 |1 Known to fail||8.0.1 --- Comment #1 from Thomas Preud'homme --- Have a patch, testing it.
[Bug c++/85249] [6/7/8 Regression] ICE with invalid default parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85249 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-04-06 CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Started with r186346.
[Bug target/85261] New: __builtin_arm_set_fpscr ICEs with constant input
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85261 Bug ID: 85261 Summary: __builtin_arm_set_fpscr ICEs with constant input Product: gcc Version: 8.0.1 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: target Assignee: thopre01 at gcc dot gnu.org Reporter: thopre01 at gcc dot gnu.org Target Milestone: --- Target: arm-none-eabi The following code ICES when compiled with -mcpu=cortex-m4 -mfloat-abi=hard -mfpu=fpv4-sp-d16 on trunk: void test_fpscr (void) { __builtin_arm_set_fpscr (0); }
[Bug c/85260] New: 8.0: python-2.7.14 miscompiled at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85260 Bug ID: 85260 Summary: 8.0: python-2.7.14 miscompiled at -O3 Product: gcc Version: 8.0.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: manuel.lauss at googlemail dot com Target Milestone: --- python-2.7.14 seems to be miscompiled at -O3, while -O2 is fine. gcc-8 as of 20180405. gcc-7.3.1 -O3 is fine as well. build # LD_LIBRARY_PATH=$PWD ./python Segmentation fault (core dumped) #0 0x7f784416d43a in PyInstance_NewRaw (klass=klass@entry=0x7f78439209a8, dict=0x7f7843d66910, dict@entry=0x0) at /tmp-ram/portage/dev-lang/python-2.7.14-r1/work/Python-2.7.14/Objects/classobject.c:544 544 inst->in_dict = dict; (gdb) list 539 return NULL; 540 } 541 inst->in_weakreflist = NULL; 542 Py_INCREF(klass); 543 inst->in_class = (PyClassObject *)klass; 544 inst->in_dict = dict; 545 _PyObject_GC_TRACK(inst); 546 return (PyObject *)inst; 547 } Dump of assembler code for function PyInstance_NewRaw: 0x7f784416d3d0 <+0>: push %rbp 0x7f784416d3d1 <+1>: push %rbx 0x7f784416d3d2 <+2>: sub$0x18,%rsp 0x7f784416d3d6 <+6>: mov0x149b9b(%rip),%rax# 0x7f78442b6f78 0x7f784416d3dd <+13>:cmp%rax,0x8(%rdi) 0x7f784416d3e1 <+17>:jne0x7f784416d490 0x7f784416d3e7 <+23>:mov%rdi,%rbx 0x7f784416d3ea <+26>:mov%rsi,%rbp 0x7f784416d3ed <+29>:test %rsi,%rsi 0x7f784416d3f0 <+32>:je 0x7f784416d4b0 0x7f784416d3f6 <+38>:mov0x8(%rsi),%rax 0x7f784416d3fa <+42>:testb $0x20,0xab(%rax) 0x7f784416d401 <+49>:je 0x7f784416d4d0 0x7f784416d407 <+55>:incq (%rsi) 0x7f784416d40a <+58>:mov0x1496cf(%rip),%rdi# 0x7f78442b6ae0 0x7f784416d411 <+65>:callq 0x7f784414a390 <_PyObject_GC_New@plt> 0x7f784416d416 <+70>:test %rax,%rax 0x7f784416d419 <+73>:je 0x7f784416d4e8 0x7f784416d41f <+79>:vmovq %rbx,%xmm1 0x7f784416d424 <+84>:movq $0x0,0x20(%rax) 0x7f784416d42c <+92>:vpinsrq $0x1,%rbp,%xmm1,%xmm0 0x7f784416d432 <+98>:incq (%rbx) 0x7f784416d435 <+101>: cmpq $0xfffe,-0x10(%rax) => 0x7f784416d43a <+106>: vmovaps %xmm0,0x10(%rax) 0x7f784416d43f <+111>: lea-0x20(%rax),%rbx 0x7f784416d443 <+115>: jne0x7f784416d478 0x7f784416d445 <+117>: mov0x149834(%rip),%rdx# 0x7f78442b6c80 0x7f784416d44c <+124>: movq $0xfffd,-0x10(%rax) 0x7f784416d454 <+132>: mov(%rdx),%rcx 0x7f784416d457 <+135>: mov%rcx,-0x20(%rax) 0x7f784416d45b <+139>: mov0x8(%rcx),%rcx 0x7f784416d45f <+143>: mov%rcx,-0x18(%rax) 0x7f784416d463 <+147>: mov%rbx,(%rcx) 0x7f784416d466 <+150>: mov(%rdx),%rdx 0x7f784416d469 <+153>: mov%rbx,0x8(%rdx) 0x7f784416d46d <+157>: add$0x18,%rsp 0x7f784416d471 <+161>: pop%rbx 0x7f784416d472 <+162>: pop%rbp 0x7f784416d473 <+163>: retq 0x7f784416d474 <+164>: nopl 0x0(%rax) 0x7f784416d478 <+168>: lea0xf4d1d(%rip),%rdi# 0x7f784426219c 0x7f784416d47f <+175>: mov%rax,0x8(%rsp) 0x7f784416d484 <+180>: callq 0x7f784414b980 0x7f784416d489 <+185>: mov0x8(%rsp),%rax 0x7f784416d48e <+190>: jmp0x7f784416d445 0x7f784416d490 <+192>: mov$0x209,%esi 0x7f784416d495 <+197>: lea0xf6184(%rip),%rdi# 0x7f7844263620 0x7f784416d49c <+204>: callq 0x7f784414c090 <_PyErr_BadInternalCall@plt> 0x7f784416d4a1 <+209>: add$0x18,%rsp 0x7f784416d4a5 <+213>: xor%eax,%eax 0x7f784416d4a7 <+215>: pop%rbx 0x7f784416d4a8 <+216>: pop%rbp 0x7f784416d4a9 <+217>: retq 0x7f784416d4aa <+218>: nopw 0x0(%rax,%rax,1) 0x7f784416d4b0 <+224>: callq 0x7f784414be40 0x7f784416d4b5 <+229>: mov%rax,%rbp [...] configured with CFLAGS="-O3 -march=haswell -mtune=haswell -pipe" ./configure --prefix=/usr --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --libdir=/usr/lib64 --with-fpectl --enable-shared --enable-ipv6 --with-threads --enable-unicode=ucs4 --infodir=${prefix}/share/info --mandir=${prefix}/share/man --with-computed-gotos --with-dbmliborder=gdbm --with-libc= --enable-loadable-sqlite-extensions --with-system-expat --with-system-ffi --without-ensurepip Thanks, Manuel
[Bug tree-optimization/85259] New: [8 Regression] Missing -Wstringop-overflow= since r256683
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85259 Bug ID: 85259 Summary: [8 Regression] Missing -Wstringop-overflow= since r256683 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org CC: law at gcc dot gnu.org, msebor at gcc dot gnu.org Target Milestone: --- Since the revision, for: $ cat /tmp/xx11.c #include char buf[6]; int main(int argc, char **argv) { strcpy(buf,"hello "); strcat(buf,"world!"); return 0; } $ gcc -O2 -Wall /tmp/xx11.c -D_FORTIFY_SOURCE=2 [no output] Before the revision I see: /usr/include/bits/string_fortified.h:128:10: warning: ‘__builtin___memcpy_chk’ writing 7 bytes into a region of size 6 overflows the destination [-Wstringop-overflow=]
[Bug target/85255] [8 Regression] wrong code with -O2 -fno-tree-fre -mavx512f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85255 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #1 from Jakub Jelinek --- Dup. I've added testcase from this PR into my patch, still waiting for review. *** This bug has been marked as a duplicate of bug 85177 ***
[Bug target/85177] [8 Regression] wrong code with -O -fno-tree-ccp -fno-tree-sra -mavx512f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85177 --- Comment #2 from Jakub Jelinek --- *** Bug 85255 has been marked as a duplicate of this bug. ***
[Bug c++/85254] boost::is_final does not work for template types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85254 --- Comment #3 from Jonathan Wakely --- Reduced a little further: template struct remove_cv{ typedef T type; }; template struct is_final { static const bool value = __is_final(typename remove_cv::type); }; struct final1 final {}; template struct final2 final {}; static_assert( is_final::value, "" ); static_assert( is_final>::value, "" ); This should compile but fails with: is_final_test.cpp:12:16: error: static assertion failed static_assert( is_final>::value, "" ); ^
[Bug c++/63217] template conversion operator returning const reference not used for conversion in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63217 --- Comment #4 from Jonathan Wakely --- Bug 77660 also looks related
[Bug c++/85256] [8 Regression] ICE with capturing pointer to VLA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85256 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-04-06 CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org Target Milestone|--- |8.0 Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Started with r253601.
[Bug c++/85214] [7/8 Regression] ICE on valid C++17 code on x86_64-linux-gnu: in tsubst_copy, at cp/pt.c:14562
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85214 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug tree-optimization/85257] [6/7/8 Regression] wrong code with -O -fno-tree-ccp and reading zeroed vector member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85257 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P2 Status|UNCONFIRMED |NEW Last reconfirmed||2018-04-06 CC||jakub at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Target Milestone|--- |6.5 Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Started with r213045. I'll have a look.
[Bug c++/85258] [7/8 Regression] ICE with invalid range-based for-loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85258 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P4 Status|UNCONFIRMED |NEW Last reconfirmed||2018-04-06 CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org Target Milestone|--- |7.4 Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Started with r242422.
[Bug c++/85254] boost::is_final does not work for template types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85254 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-04-06 Ever confirmed|0 |1 --- Comment #2 from Jonathan Wakely --- Reduced to less than 30kloc namespace boost { template struct integral_constant { static const bool value = val; }; template bool const integral_constant::value; template struct remove_cv{ typedef T type; }; template struct is_final : integral_constant<__is_final(typename remove_cv::type)> {}; } struct final1 final {}; template struct final2 final {}; static_assert( boost::is_final::value, "" ); static_assert( boost::is_final>::value, "" );
[Bug ipa/84947] UBSAN: ipcp_bits_lattice::meet_with(generic_wide_int >, generic_wide_int >, unsigned int) ../../gcc/ipa-cp.c:1058
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84947 Martin Jambor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Martin Jambor --- Fixed
[Bug other/63426] [meta-bug] Issues found with -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63426 Bug 63426 depends on bug 84947, which changed state. Bug 84947 Summary: UBSAN: ipcp_bits_lattice::meet_with(generic_wide_int >, generic_wide_int >, unsigned int) ../../gcc/ipa-cp.c:1058 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84947 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug middle-end/85123] [8 regression] test case gcc.dg/pr63594-2.c begins failing with r254862
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85123 Jakub Jelinek changed: What|Removed |Added Status|REOPENED|RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |FIXED --- Comment #8 from Jakub Jelinek --- Thus fixed.
[Bug middle-end/85123] [8 regression] test case gcc.dg/pr63594-2.c begins failing with r254862
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85123 --- Comment #7 from Tamar Christina --- Patch has been reverted as r259169.
[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81084 --- Comment #22 from Jakub Jelinek --- Another gentle ping. As has been mentioned, powerpcspe also lacks gcc-8/changes.html entry.
[Bug lto/81968] [8 regression] early lto debug objects make Solaris ld SEGV
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81968 Richard Biener changed: What|Removed |Added Target|*-*-solaris2|x86-*-solaris2 Priority|P1 |P3 --- Comment #69 from Richard Biener --- So if sparc*-solaris is clean the priority can be lowered since x86-solaris is neither primary nor secondary. Making it P3 to not completely fall off the radar.
[Bug debug/85252] [6/7/8 Regression] ICE with -g for static zero-length array initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85252 --- Comment #5 from Themos Tsikas --- If you find a gcc version that doesn't ICE, make sure you try the options "-g -O".
[Bug libstdc++/85222] [7/8 Regression] ABI breakage of __throw_ios_failure by r244498
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85222 --- Comment #19 from Richard Biener --- Luckily both failure classes are immutable (via access limitations) so the following issue with the __dual_ios_failure idea doesn't exist: catch (old-ABI &e) { modify e in-place throw; } ... catch (new-ABI &e) { ... expect modified content ... }
[Bug c++/85242] [6/7/8 Regression] ICE with invalid template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85242 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug c++/85258] New: [7/8 Regression] ICE with invalid range-based for-loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85258 Bug ID: 85258 Summary: [7/8 Regression] ICE with invalid range-based for-loop Product: gcc Version: 8.0 Status: UNCONFIRMED Keywords: error-recovery, ice-on-invalid-code Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: reichelt at gcc dot gnu.org Target Milestone: --- The following invalid code snippet triggers an ICE since GCC 7.1.0: template void foo() { int x[8]; for (int& i, j : x) i = 0; } void bar() { foo<0>(); } bug.cc: In function 'void foo()': bug.cc:4:14: error: multiple declarations in range-based 'for' loop for (int& i, j : x) ^ bug.cc: In instantiation of 'void foo() [with int = 0]': bug.cc:10:10: required from here bug.cc:5:5: internal compiler error: Segmentation fault i = 0; ^ 0xebd87f crash_signal ../../gcc/gcc/toplev.c:325 0x85245d reduced_constant_expression_p(tree_node*) ../../gcc/gcc/cp/constexpr.c:1776 0x964822 tsubst_copy ../../gcc/gcc/cp/pt.c:15142 0x9654ef tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool, bool) ../../gcc/gcc/cp/pt.c:18526 0x966768 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool, bool) ../../gcc/gcc/cp/pt.c:17467 0x965a96 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool, bool) ../../gcc/gcc/cp/pt.c:17771 0x971627 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool) ../../gcc/gcc/cp/pt.c:17099 0x97092e tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool) ../../gcc/gcc/cp/pt.c:16300 0x970f2c tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool) ../../gcc/gcc/cp/pt.c:16495 0x97005c tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool) ../../gcc/gcc/cp/pt.c:16286 0x96e71f tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool) ../../gcc/gcc/cp/pt.c:16583 0x96d8b8 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool) ../../gcc/gcc/cp/pt.c:16271 0x96d8b8 instantiate_decl(tree_node*, bool, bool) ../../gcc/gcc/cp/pt.c:23682 0x99476b instantiate_pending_templates(int) ../../gcc/gcc/cp/pt.c:23798 0x8b8e3b c_parse_final_cleanups() ../../gcc/gcc/cp/decl2.c:4725 Please submit a full bug report, [etc.]