[Bug c/99049] _Alignof ignores requested alignment of bit-field types in ms_struct struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99049 Richard Biener changed: What|Removed |Added CC||jsm28 at gcc dot gnu.org Keywords||ABI, wrong-code --- Comment #1 from Richard Biener --- I guess the expectation is reasonable but details on the handling of bitfield types may escape me. How does MSVC behave here?
[Bug tree-optimization/99046] [[gnu::const]] function needs noexcept to be recognized as loop invariant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99046 Richard Biener changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-02-10 Status|UNCONFIRMED |NEW --- Comment #1 from Richard Biener --- The issue is that most passes (including LIM) are not set up to move the EH side-effects of stmts so they simply give up. It's true that whether const implies nothrow is debatable but we definitely have two independent bits in the middle-end.
[Bug fortran/99036] [11 Regression] ICE in gfc_current_interface_head, at fortran/interface.c:4699
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99036 Richard Biener changed: What|Removed |Added Target Milestone|--- |11.0
[Bug ipa/99034] [10/11 Regression] ICE in emit_to_new_bb_before, at except.c:932
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99034 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug c++/99033] [9/10/11 Regression] ICE in tree_to_poly_int64, at tree.c:3091
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99033 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug c++/99030] [11 Regression] ICE in finish_expr_stmt, at cp/semantics.c:776
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99030 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug rtl-optimization/99054] New: memory leak in thread_prologue_and_epilogue_insns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99054 Bug ID: 99054 Summary: memory leak in thread_prologue_and_epilogue_insns Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: rguenth at gcc dot gnu.org Target Milestone: --- ==3252== Memcheck, a memory error detector ==3252== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==3252== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info ==3252== Command: ./cc1 -quiet -fdiagnostics-plain-output -O3 -o ssa-dom-thread-1.s /home/rguenther/src/gcc3/gcc/testsuite/gcc.dg/torture/pr98289.c ==3252== ==3252== ==3252== HEAP SUMMARY: ==3252== in use at exit: 1,877,561 bytes in 2,761 blocks ==3252== total heap usage: 54,967 allocs, 52,206 frees, 10,428,830 bytes allocated ==3252== ==3252== 40 bytes in 1 blocks are definitely lost in loss record 28 of 699 ==3252==at 0x4C2E2DF: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==3252==by 0x28ECCA8: xrealloc (xmalloc.c:177) ==3252==by 0xC78E72: void va_heap::reserve(vec*&, unsigned int, bool) (vec.h:290) ==3252==by 0xC789CF: vec::reserve(unsigned int, bool) (vec.h:1778) ==3252==by 0xCABA7B: vec::safe_push(basic_block_def* const&) (vec.h:1887) ==3252==by 0xCBF762: find_partition_fixes(bool) (cfgrtl.c:2405) ==3252==by 0xCBF7B2: fixup_partitions() (cfgrtl.c:2434) ==3252==by 0xCBE8A6: commit_edge_insertions() (cfgrtl.c:2112) ==3252==by 0xF14501: thread_prologue_and_epilogue_insns() (function.c:6084) ==3252==by 0xF152E0: rest_of_handle_thread_prologue_and_epilogue() (function.c:6510) ==3252==by 0xF154C0: (anonymous namespace)::pass_thread_prologue_and_epilogue::execute(function*) (function.c:6586) ==3252==by 0x12E7FEA: execute_one_pass(opt_pass*) (passes.c:2572)
[Bug fortran/99053] memory leak in module reading, gfc_new_symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99053 --- Comment #1 from Richard Biener --- If there's currently no part in the FE that tries to release memory of this kind then a valid strathegy would be to change the current heap allocations via X[C]NEW to allocations from a frontend specific obstack and simply release the whole obstack at the point the FE transfers control to the middle-end (assuming later langhook calls from it will not reach into the data, of course). Guess FE people will have an idea of the lifetime of objects.
[Bug fortran/99053] New: memory leak in module reading, gfc_new_symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99053 Bug ID: 99053 Summary: memory leak in module reading, gfc_new_symbol Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: rguenth at gcc dot gnu.org Target Milestone: --- It looks like gfc_symbols as allocated via module reading are never deallocated, even when the frontend finished parsing. Compiling 521.wrf_r module_cpl.fppized.f90 like 1612940030.01: ==2296== Memcheck, a memory error detector 1612940030.01: ==2296== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. 1612940030.01: ==2296== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info 1612940030.01: ==2296== Command: /home/rguenther/install/gcc-test/usr/local/bin/../lib/gcc/x86_64-pc-linux-gnu/11.0.0/f951 module_cpl.fppized.f90 -I . -I ./netcdf/include -I ./inc -quiet -dumpbase module_cpl.fppized.f90 -dumpbase-ext .f90 -march=znver2 -g0 -Ofast -std=legacy -fconvert=big-endian -fno-openmp -fintrinsic-modules-path /home/rguenther/install/gcc-test/usr/local/bin/../lib64/gcc/x86_64-pc-linux-gnu/11.0.0/finclude -o /tmp/ccSQlHm7.s shows this and various other fortran FE leaks.
[Bug fortran/99052] New: memory leak in gfc_match_actual_arglist
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99052 Bug ID: 99052 Summary: memory leak in gfc_match_actual_arglist Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: rguenth at gcc dot gnu.org Target Milestone: --- Compiling module_timing.fppized.f90 of 521.wrf_r like 1612940048.84: ==2302== Memcheck, a memory error detector 1612940048.84: ==2302== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. 1612940048.84: ==2302== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info 1612940048.84: ==2302== Command: /home/rguenther/install/gcc-test/usr/local/bin/../lib/gcc/x86_64-pc-linux-gnu/11.0.0/f951 module_timing.fppized.f90 -I . -I ./netcdf/include -I ./inc -quiet -dumpbase module_timing.fppized.f90 -dumpbase-ext .f90 -march=znver2 -g0 -Ofast -std=legacy -fconvert=big-endian -fno-openmp -fintrinsic-modules-path /home/rguenther/install/gcc-test/usr/local/bin/../lib64/gcc/x86_64-pc-linux-gnu/11.0.0/finclude -o /tmp/ccpIqHn9.s 1612940048.84: ==2302== 1612940054.84: ==2302== 1612940054.84: ==2302== HEAP SUMMARY: 1612940054.84: ==2302== in use at exit: 1,896,871 bytes in 3,356 blocks 1612940054.84: ==2302== total heap usage: 20,895 allocs, 17,539 frees, 11,039,674 bytes allocated 1612940054.84: ==2302== 1612940054.84: ==2302== 40 bytes in 1 blocks are definitely lost in loss record 30 of 861 1612940054.84: ==2302==at 0x4C306B5: calloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) 1612940054.84: ==2302==by 0x16ABBE0: xcalloc (xmalloc.c:162) 1612940054.84: ==2302==by 0x6F16E9: gfc_match_actual_arglist(int, gfc_actual_arglist**, bool) (primary.c:1899) 1612940054.84: ==2302==by 0x6F460D: gfc_match_rvalue(gfc_expr**) (primary.c:3925) 1612940054.84: ==2302==by 0x6C88EE: match_primary (matchexp.c:157) 1612940054.84: ==2302==by 0x6C88EE: match_level_1 (matchexp.c:211) 1612940054.84: ==2302==by 0x6C88EE: match_mult_operand(gfc_expr**) (matchexp.c:267) 1612940054.84: ==2302==by 0x6C8B38: match_add_operand(gfc_expr**) (matchexp.c:356) 1612940054.84: ==2302==by 0x6C8D8C: match_level_2(gfc_expr**) (matchexp.c:480) 1612940054.84: ==2302==by 0x6C8EE2: match_level_3(gfc_expr**) (matchexp.c:551) 1612940054.84: ==2302==by 0x6C8FD4: match_level_4 (matchexp.c:599) 1612940054.84: ==2302==by 0x6C8FD4: match_and_operand(gfc_expr**) (matchexp.c:693) 1612940054.84: ==2302==by 0x6C91C2: match_or_operand(gfc_expr**) (matchexp.c:722) 1612940054.84: ==2302==by 0x6C9292: match_equiv_operand(gfc_expr**) (matchexp.c:765) 1612940054.84: ==2302==by 0x6C9364: match_level_5(gfc_expr**) (matchexp.c:811)
[Bug debug/98755] [11 regression] r11-6755 causes failure in g++.dg/debug/dwarf2/constexpr-var-1.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98755 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Fixed.
[Bug debug/98755] [11 regression] r11-6755 causes failure in g++.dg/debug/dwarf2/constexpr-var-1.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98755 --- Comment #2 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:e1782d8ad10dc6b556e118fd25fdaff04ce54dde commit r11-7162-ge1782d8ad10dc6b556e118fd25fdaff04ce54dde Author: Jakub Jelinek Date: Wed Feb 10 07:54:30 2021 +0100 dwarf2out: Don't prune static data members initialized with constants with -gdwarf-5 [PR98755] In DWARF4 and earlier, static data members were represented as DW_TAG_member and the pruning code wouldn't prune those, but in DWARF5 they are represented as DW_TAG_variable with the class parent and the pruning code prunes those by default unless they are referenced from a separate definition without the class parent (out of class definition). C++17 inline vars have the definitions in the class though and even before if the static data member isn't ODR used, it doesn't need to be defined, so we could just never describe those static data members in the debug info. This change stops the pruning of DW_TAG_variable with DW_AT_const_value attribute with a class parent for -gdwarf-5 and later. This fixes -FAIL: g++.dg/debug/dwarf2/constexpr-var-1.C scan-assembler-times DW_AT_const_expr 2 -FAIL: libstdc++-prettyprinters/80276.cc whatis p4 -FAIL: libstdc++-prettyprinters/80276.cc whatis p4 -FAIL: libstdc++-prettyprinters/libfundts.cc print as -FAIL: libstdc++-prettyprinters/libfundts.cc print as -FAIL: libstdc++-prettyprinters/libfundts.cc print os -FAIL: libstdc++-prettyprinters/libfundts.cc print os 2021-02-10 Jakub Jelinek PR debug/98755 * dwarf2out.c (prune_unused_types_walk): Mark DW_TAG_variable DIEs at class scope for DWARF5+.
[Bug c++/99051] New: [modules] ICE/SIGSEGV in get_location_from_adhoc_loc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99051 Bug ID: 99051 Summary: [modules] ICE/SIGSEGV in get_location_from_adhoc_loc Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: boris at kolpackov dot net Target Milestone: --- cat
[Bug preprocessor/98882] [11 Regression] ICE in in cpp_directive_only_process on empty translation unit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98882 --- Comment #8 from Boris Kolpackov --- Done, bug 99050.
[Bug c++/99050] New: [modules] ICE in cpp_directive_only_process on include translation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99050 Bug ID: 99050 Summary: [modules] ICE in cpp_directive_only_process on include translation Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: boris at kolpackov dot net Target Milestone: --- After the fix in bug 98882 I now get an ICE (that same assert) when partially preprocessing (-E -fdirectives-only) a TU that has an include directive that is translated to an import: cat&2; } function resp () { info " < $*"; echo "$*"; } while read l; do info " > $l" case "$l" in HELLO*) resp "HELLO 1 test ;" ;; MODULE-REPO) resp "PATHNAME /" ;; INCLUDE-TRANSLATE*hello.hxx) resp "PATHNAME $(pwd)/hello.gcm" ;; INCLUDE-TRANSLATE*) resp "BOOL FALSE" ;; MODULE-EXPORT*|MODULE-IMPORT*) resp "PATHNAME $(pwd)/hello.gcm" ;; MODULE-COMPILED*) resp "OK" ;; *) resp "ERROR 'unexpected request: $l'" ;; esac done EOF chmod ugo+x ./mapper g++ -std=c++2a -fmodules-ts -fmodule-mapper='|./mapper' -fmodule-header -x c++ header hello.hxx g++ -std=c++2a -fmodules-ts -fmodule-mapper='|./mapper' -E -fdirectives-only -x c++ -o main.ii main.cxx main.cxx:1: internal compiler error: in cpp_directive_only_process, at libcpp/lex.c:4323 0x2c26a7a cpp_directive_only_process(cpp_reader*, void*, void (*)(cpp_reader*, CPP_DO_task, void*, ...)) ../../gcc/libcpp/lex.c:4323 0xf1745e scan_translation_unit_directives_only ../../gcc/gcc/c-family/c-ppoutput.c:402 0xf16928 preprocess_file(cpp_reader*) ../../gcc/gcc/c-family/c-ppoutput.c:100 0xf10e2b c_common_init() ../../gcc/gcc/c-family/c-opts.c:1195 0xbe8ea7 cxx_init() ../../gcc/gcc/cp/lex.c:332 0x180c1af lang_dependent_init ../../gcc/gcc/toplev.c:1881 0x180ca61 do_compile ../../gcc/gcc/toplev.c:2178 Note that there is no assert if we are using import directly, without include translation.
[Bug fortran/98979] [11 regression] ICE in several tests cases after r11-7112
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98979 --- Comment #7 from CVS Commits --- The master branch has been updated by Julian Brown : https://gcc.gnu.org/g:f7fb2f662fe12f327ece8b034ab76b36fdca4696 commit r11-7161-gf7fb2f662fe12f327ece8b034ab76b36fdca4696 Author: Julian Brown Date: Tue Feb 9 12:00:14 2021 -0800 openacc: Add XFAILs [PR98979] This patch adds some XFAILs for PR98979 until the patch to fix them has been approved. See: https://gcc.gnu.org/pipermail/gcc-patches/2021-February/564711.html gcc/testsuite/ PR fortran/98979 * gfortran.dg/goacc/array-with-dt-2.f90: Add expected errors. * gfortran.dg/goacc/derived-chartypes-1.f90: Skip ICEing test. * gfortran.dg/goacc/derived-chartypes-2.f90: Likewise. libgomp/ PR fortran/98979 * testsuite/libgomp.oacc-fortran/array-stride-dt-1.f90: Add expected errors.
[Bug fortran/98979] [11 regression] ICE in several tests cases after r11-7112
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98979 --- Comment #6 from CVS Commits --- The master branch has been updated by Julian Brown : https://gcc.gnu.org/g:b0fb2720d88d680af18981a2097397196b505a1f commit r11-7160-gb0fb2720d88d680af18981a2097397196b505a1f Author: Julian Brown Date: Tue Feb 9 14:09:00 2021 -0800 Revert "openacc: Allow strided arrays in update directives" This patch reverts the non-testsuite parts of commit 9a4d32f85ccebc0ee4b24e6d9d7a4f11c04d7146 which cause ICEs without the yet-to-be-approved patch here: https://gcc.gnu.org/pipermail/gcc-patches/2021-February/564711.html gcc/fortran/ PR fortran/98979 * openmp.c (resolve_omp_clauses): Omit OpenACC update in contiguity check and stride-specified error.
[Bug fortran/99036] [11 Regression] ICE in gfc_current_interface_head, at fortran/interface.c:4699
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99036
kargl at gcc dot gnu.org changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed||2021-02-10
CC||kargl at gcc dot gnu.org
Priority|P3 |P4
Status|UNCONFIRMED |NEW
--- Comment #1 from kargl at gcc dot gnu.org ---
Possible patch. Tested against Gerhard's example. Not regression tested.
diff --git a/gcc/fortran/decl.c b/gcc/fortran/decl.c
index 723915822f3..8cdfdf8f03a 100644
--- a/gcc/fortran/decl.c
+++ b/gcc/fortran/decl.c
@@ -9881,6 +9879,12 @@ gfc_match_modproc (void)
/* Store the current state of the interface. We will need it if we
end up with a syntax error and need to recover. */
old_interface_head = gfc_current_interface_head ();
+ if (!old_interface_head)
+{
+ gfc_error ("MODULE PROCEDURE at %C must be in a generic module "
+"interface");
+ return MATCH_ERROR;
+}
/* Check if the F2008 optional double colon appears. */
gfc_gobble_whitespace ();
diff --git a/gcc/fortran/interface.c b/gcc/fortran/interface.c
index 87fe14280e6..aec5536d7c6 100644
--- a/gcc/fortran/interface.c
+++ b/gcc/fortran/interface.c
@@ -4696,7 +4696,7 @@ gfc_current_interface_head (void)
return current_interface.uop->op;
default:
- gcc_unreachable ();
+ return NULL;
}
}
[Bug c/99049] New: _Alignof ignores requested alignment of bit-field types in ms_struct struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99049
Bug ID: 99049
Summary: _Alignof ignores requested alignment of bit-field
types in ms_struct struct
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: ju.orth at gmail dot com
Target Milestone: ---
Consider
typedef int Int __attribute__((aligned(128)));
struct __attribute__((ms_struct)) X {
Int i:1;
};
struct Y {
char c;
struct X x;
};
int f(void) {
return _Alignof(struct X);
}
int g(void) {
return __builtin_offsetof(struct Y, x);
}
When compiling this on x86_64-unknown-linux-gnu, f returns 16 but g returns
128. I believe that _Alignof and __builtin_offsetof as above should always
return the same value.
[Bug preprocessor/96391] [10/11 Regression] internal compiler error: in linemap_compare_locations, at libcpp/line-map.c:1359
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96391 --- Comment #12 from Michael Cronenworth --- (In reply to David Malcolm from comment #11) > FWIW I had another go at reproduing this, but after various failures due to > running out of disk space, I was able to rebuild the SRPM from comment #0 > without seeing the crash, via: Yes, and with -save-temps you double the disk space required. :( > mock --rebuild mingw-wine-gecko-2.47.1-2.fc32.src.rpm -N -r fedora-32-i386 That's a reasonable mock command for a Fedora 32 build. > (which the root.log tells me used gcc-c++-10.2.1-9.fc32.i686.rpm). That's the Linux GCC. You will want to see the version for MinGW: mingw-gcc-9.2.1-6.fc32 - which does not crash so I'm not surprised you didn't crash. > Michael: is that the mock configuration that's failing for you, or are you > using a different one? Try: mock --rebuild mingw-wine-gecko-2.47.1-2.fc32.src.rpm -N -r fedora-33-i386 It's still failing for me today. I'm working around it by passing -save-temps to CFLAGS as packages that fail to compile in Fedora for too long are dropped from the distribution.
[Bug libgcc/99048] New: __gcc_qadd produces spurious NaN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99048
Bug ID: 99048
Summary: __gcc_qadd produces spurious NaN
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgcc
Assignee: unassigned at gcc dot gnu.org
Reporter: bbarenblat at gmail dot com
Target Milestone: ---
Target: powerpc64le-linux-gnu
Created attachment 50160
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50160&action=edit
minimal example
__gcc_qadd, which adds two long doubles on POWER, can emit NaN for non-NaN
input:
$ cat ldbl.c
extern int printf(const char* restrict, ...);
int main() {
long double a = -0x1.1e282e024debdb875f47f6c85p+1021L;
printf("%Le\n", a + 0x1.f78p+1023L);
}
$ gcc -O0 -o ldbl ldbl.c
$ ./ldbl
nan
$ gcc -O1 -o ldbl ldbl.c
$ ./ldbl
1.546510e+308
Examining the assembly from the second invocation shows that GCC has optimized
out the entire computation. In the first invocation, however, the compiled
program calls __gcc_qadd, which yields NaN. By IEEE 754, adding two non-NaN
inputs should never produce a NaN output.
Output of 'gcc -v':
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/powerpc64le-linux-gnu/10/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: powerpc64le-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 10.2.1-6'
--with-bugurl=file:///usr/share/doc/gcc-10/README.Bugs
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-10
--program-prefix=powerpc64le-linux-gnu- --enable-shared
--enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --libdir=/usr/lib --enable-nls --enable-bootstrap
--enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object --enable-plugin
--enable-default-pie --with-system-zlib --enable-libphobos-checking=release
--with-target-system-zlib=auto --enable-objc-gc=auto --enable-secureplt
--with-cpu=power8 --enable-targets=powerpcle-linux --disable-multilib
--enable-multiarch --disable-werror --with-long-double-128
--enable-offload-targets=nvptx-none=/build/gcc-10-jGDcMs/gcc-10-10.2.1/debian/tmp-nvptx/usr
--without-cuda-driver --enable-checking=release --build=powerpc64le-linux-gnu
--host=powerpc64le-linux-gnu --target=powerpc64le-linux-gnu
--with-build-config=bootstrap-lto-lean --enable-link-mutex
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.2.1 20210110 (Debian 10.2.1-6)
[Bug c++/99047] New: ICE on simple task coroutine example
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99047
Bug ID: 99047
Summary: ICE on simple task coroutine example
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redbeard0531 at gmail dot com
Target Milestone: ---
https://godbolt.org/z/ecxEbb Code compiles on MSVC and clang, and at least on
clang produces the expected output.
#include
#include
template
struct [[nodiscard]] task {
struct promise_type {
std::suspend_always initial_suspend() {
return {};
}
auto final_suspend() noexcept {
struct awaiter {
std::false_type await_ready() noexcept {
return {};
}
std::coroutine_handle<> await_suspend(std::coroutine_handle<>)
noexcept {
return next;
}
void await_resume() noexcept {
}
std::coroutine_handle<> next;
};
return awaiter{next};
}
void unhandled_exception() noexcept {
std::terminate();
}
auto get_return_object() {
return task(this);
}
auto coro() {
return std::coroutine_handle::from_promise(*this);
}
void return_value(T val) {
result.emplace(std::move(val));
}
std::coroutine_handle<> next;
std::optional result;
};
task(task&& source) : p(std::exchange(source.p, nullptr)) {}
explicit task(promise_type* p) : p(p) {}
~task() {
if (p)
p->coro().destroy();
}
bool await_ready() noexcept {
return p->coro().done();
}
std::coroutine_handle<> await_suspend(std::coroutine_handle<> next)
noexcept {
p->next = next;
return p->coro();
}
const T& await_resume() const& noexcept {
return *p->result;
}
promise_type* p;
};
task five() {
co_return 5;
}
task six() {
co_return (co_await five()) + 1;
}
int main() {
auto task = six();
task.p->next = std::noop_coroutine();
task.p->coro().resume();
return *task.p->result;
}
: In function 'void _Z4fivev.actor(five()::_Z4fivev.frame*)':
:92:11: internal compiler error: in fold_convert_loc, at
fold-const.c:2430
92 | task five() {
| ^~~~
0x1ce6f09 internal_error(char const*, ...)
???:0
0x6b6f43 fancy_abort(char const*, int, char const*)
???:0
0xc92cd4 fold_convert_loc(unsigned int, tree_node*, tree_node*)
???:0
0xd126ae gimple_boolify(tree_node*)
???:0
0xd1b720 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
???:0
0xd1bb4a gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
[snipping many more frames]
[Bug c++/95888] [9/10/11 Regression] Regression in 9.3. GCC freezes when compiling code using boost::poly_collection::segment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95888 Marek Polacek changed: What|Removed |Added Keywords|compile-time-hog|patch --- Comment #7 from Marek Polacek --- Patch posted: https://gcc.gnu.org/pipermail/gcc-patches/2021-February/565086.html
[Bug rtl-optimization/98692] Unitialized Values reported only with -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98692 --- Comment #16 from Segher Boessenkool --- (In reply to Mark Wielaard from comment #13) > ==25741== Use of uninitialised value of size 8 > ==25741==at 0x1504: main (pr9862.C:16) r4 is argv here >0x14f0 <+16>: ld r3,0(r4) r3 = argv[0]; >0x14f4 <+20>: mr r31,r4 r31 = argv; // because we need it after the call, save it in a non-volatile reg >0x14f8 <+24>: std r0,16(r1) >0x14fc <+28>: stdur1,-48(r1) >0x1500 <+32>: bl 0x16b4 The call; after this we have to load argv[0] again, the called function might have changed it. >0x1504 <+36>: ld r3,0(r31) r3 = argv[0]; So it is funny that the exact same insn four insns earlier (in the program text) worked fine, but this one fails. The ABI says (taken from the ELFv1 ABI, the ELFv2 doc is not nice for copy/paste): Here is a sample implementation of _savegpr0_N and _restgpr0_N. _savegpr0_14: std r14,-144(r1) _savegpr0_15: std r15,-136(r1) _savegpr0_16: std r16,-128(r1) _savegpr0_17: std r17,-120(r1) _savegpr0_18: std r18,-112(r1) _savegpr0_19: std r19,-104(r1) _savegpr0_20: std r20,-96(r1) _savegpr0_21: std r21,-88(r1) _savegpr0_22: std r22,-80(r1) _savegpr0_23: std r23,-72(r1) _savegpr0_24: std r24,-64(r1) _savegpr0_25: std r25,-56(r1) _savegpr0_26: std r26,-48(r1) _savegpr0_27: std r27,-40(r1) _savegpr0_28: std r28,-32(r1) _savegpr0_29: std r29,-24(r1) _savegpr0_30: std r30,-16(r1) _savegpr0_31: std r31,-8(r1) std r0, 16(r1) blr _restgpr0_14: ld r14,-144(r1) _restgpr0_15: ld r15,-136(r1) _restgpr0_16: ld r16,-128(r1) _restgpr0_17: ld r17,-120(r1) _restgpr0_18: ld r18,-112(r1) _restgpr0_19: ld r19,-104(r1) _restgpr0_20: ld r20,-96(r1) _restgpr0_21: ld r21,-88(r1) _restgpr0_22: ld r22,-80(r1) _restgpr0_23: ld r23,-72(r1) _restgpr0_24: ld r24,-64(r1) _restgpr0_25: ld r25,-56(r1) _restgpr0_26: ld r26,-48(r1) _restgpr0_27: ld r27,-40(r1) _restgpr0_28: ld r28,-32(r1) _restgpr0_29: ld r0, 16(r1) ld r29,-24(r1) mtlr r0 ld r30,-16(r1) ld r31,-8(r1) blr _restgpr0_30: ld r30,-16(r1) _restgpr0_31: ld r0, 16(r1) ld r31,-8(r1) mtlr r0 blr So this is one function with many entry points you could say. Maybe that is what confused valgrind?
[Bug analyzer/99044] use-after-free false positive in loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99044 David Malcolm changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-02-09 Status|UNCONFIRMED |ASSIGNED Summary|use-after-free false|use-after-free false |positive|positive in loop --- Comment #1 from David Malcolm --- Thanks for filing this bug report. Confirmed with trunk. Looks like the analyzer gets confused about the repeated frees relating to "e", where it seems to confuse the value of e in the first iteration with that of the second iteration. Similar to PR analyzer/93695 in that respect.
[Bug rtl-optimization/98692] Unitialized Values reported only with -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98692 --- Comment #15 from Segher Boessenkool --- (In reply to Will Schmidt from comment #14) > The _restgpr* and _savegpr* functions are not referenced when the test is > built at other optimization levels. (I've looked at disassembly from -O0 .. > -O4). Right, it is a size optimisation. > I do note that the _restgpr and _savegpr functions are called differently. > savegpr is called with bl while the restgpr is called via a direct branch; i > can't immediately tell if this is by design or if it is in error. It is by design: these are special functions defined by the ABI, specifically to save some code space.
[Bug analyzer/99042] Another false -Wanalyzer-malloc-leak on code path involving unknown function call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99042
David Malcolm changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Summary|file-leak is wrong |Another false
||-Wanalyzer-malloc-leak on
||code path involving unknown
||function call
Ever confirmed|0 |1
Last reconfirmed||2021-02-09
--- Comment #1 from David Malcolm ---
Thanks Antonio.
Confirmed with trunk. A minimal reproducer:
$ cat ../../src/gcc/testsuite/gcc.dg/analyzer/pr99042.c
#include
struct foo {
FILE *file;
};
extern void unknown_fn ();
int open_next_file(struct foo *p)
{
if ((p->file = fopen("test.txt", "w")) == NULL)
return 1;
unknown_fn ();
return 0;
}
$ ./xgcc -B. -S ../../src/gcc/testsuite/gcc.dg/analyzer/pr99042.c -fanalyzer
In function ‘open_next_file’:
../../src/gcc/testsuite/gcc.dg/analyzer/pr99042.c:14:10: warning: leak of FILE
‘’ [CWE-775] [-Wanalyzer-file-leak]
14 | return 0;
| ^
‘open_next_file’: events 1-5
|
| 11 | if ((p->file = fopen("test.txt", "w")) == NULL)
| | ~ ^~
| | | |
| | | (1) opened here
| | (2) assuming ‘*p.file’ is non-NULL
| | (3) following ‘false’ branch...
| 12 | return 1;
| 13 | unknown_fn ();
| | ~
| | |
| | (4) ...to here
| 14 | return 0;
| | ~
| | |
| | (5) ‘’ leaks here; was opened at (1)
|
The call to the unknown_fn seems to be necessary to trigger the false positive,
which is similar to PR analyzer/98575 (but not fixed by my recent patches for
that); updating Summary field accordingly. In the git example, strbuf_release
is the unknown fn.
[Bug tree-optimization/99046] New: [[gnu::const]] function needs noexcept to be recognized as loop invariant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99046
Bug ID: 99046
Summary: [[gnu::const]] function needs noexcept to be
recognized as loop invariant
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target Milestone: ---
(from https://stackoverflow.com/q/66100945/1918193)
double x[1000] = {};
[[gnu::const]] double* g(double* var);
void f() {
for (int i = 1; i < 1000; i++) {
g(x)[i] = (g(x)[i-1] + 1.0) * 1.001;
}
}
g++ -O3 eliminates half of the calls to g, but fails to move it to a single
call before the loop, while llvm does just that. Gcc does manage it if I mark f
as noexcept or nothrow. Whether const functions may throw seems debatable, but
if they do throw, I expect them to do so consistently, and since the loop has
at least one iteration and starts with this call, the transformation seems safe
to me.
[Bug libstdc++/98985] libstdc++: filesystem::rename not overwriting files on Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98985 --- Comment #1 from Jonathan Wakely --- I'll fix it by using MoveFileExW in posix::rename instead. MoveFileExW seems to have some weird differences from POSIX rename when the source or destination name is a directory.
[Bug rtl-optimization/98692] Unitialized Values reported only with -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98692 --- Comment #14 from Will Schmidt --- Using gdb/vgdb to view the valgrind shadow register values, it looks like the uninitialized values are being loaded in via the _restgpr0_25 call being made at the end of isVariable(). Dump of assembler code for function isVariable(char*): 0x16ac <+0>: lis r2,4098 0x16b0 <+4>: addir2,r2,32512 0x16b4 <+8>: mflrr0 0x16b8 <+12>:addis r9,r2,-2 0x16bc <+16>:addir9,r9,-30152 (here: r1 is 0x1fff00e440 ; shadow registers r24..r31 show zero). 0x16c0 <+20>:bl 0x1820 <_savegpr0_25> savegpr0_25 stores r25 thru r31 into the stack (offset of r1) 0x16c4 <+24>:stdur1,-128(r1) And stack pointer updates itself. r1 is now 0x1fff00e3c0 0x16c8 <+28>:ld r29,0(r9) 0x16cc <+32>:ld r28,8(r9) 0x16d0 <+36>:nop 0x16d4 <+40>:mr r30,r3 0x16d8 <+44>:ld r27,16(r9) 0x16dc <+48>:li r31,0 0x16e0 <+52>:addir25,r2,-32456 0x16e4 <+56>:addir26,r1,32 0x16e8 <+60>:std r29,32(r1) 0x16ec <+64>:std r28,40(r1) 0x16f0 <+68>:rldicr r9,r31,3,60 0x16f4 <+72>:li r5,2 0x16f8 <+76>:std r27,48(r1) 0x16fc <+80>:mr r3,r30 0x1700 <+84>:ldx r4,r26,r9 0x1704 <+88>:bl 0x14c0 <0023.plt_call.strncmp@@GLIBC_2.17> 0x1708 <+92>:ld r2,24(r1) 0x170c <+96>:mr. r9,r3 0x1710 <+100>: bne 0x1718 0x1714 <+104>: stw r9,0(r25) 0x1718 <+108>: cmpldi r31,1 0x171c <+112>: bne 0x1728 r1 still 0x1fff00e3c0 0x1720 <+116>: addir1,r1,128 now r1 is 0x1fff00e440 0x1724 <+120>: b 0x1844 <_restgpr0_25> and as we progress through restoring the regs, the valgrind shadow registers are indicating the values are uninitialized as they are restored off the stack (r1). 0x1964 <_restgpr0_25>: ld r25,-56(r1) (gdb) p/x $r25s1 $29 = 0x (gdb) p/x $r26s1 $31 = 0x0 => 0x1968 <_restgpr0_26>: ld r26,-48(r1) (gdb) p/x $r26s1 $32 = 0x 0x196c <_restgpr0_27>: ld r27,-40(r1) 0x1970 <_restgpr0_28>: ld r28,-32(r1) 0x1974 <_restgpr0_29>: ld r0,16(r1) The _restgpr* and _savegpr* functions are not referenced when the test is built at other optimization levels. (I've looked at disassembly from -O0 .. -O4). I do note that the _restgpr and _savegpr functions are called differently. savegpr is called with bl while the restgpr is called via a direct branch; i can't immediately tell if this is by design or if it is in error. 17d0: 71 01 00 48 bl 1940 <_savegpr0_25> 1834: 30 01 00 48 b 1964 <_restgpr0_25>
[Bug analyzer/98575] [11 regression] False -Wanalyzer-malloc-leak on code path involving unknown function call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98575 David Malcolm changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #7 from David Malcolm --- Should be fixed by the above commits. I verified the fix on gcc135.fsffrance.org in the GCC compile farm: CentOS Linux release 7.8.2003 (AltArch) powerpc64le-unknown-linux-gnu glibc-2.17-307.el7.1.ppc64le Please let me know if you're still seeing issues.
[Bug fortran/99045] New: In select rank, compiler error for call to type-bound procedure.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99045 Bug ID: 99045 Summary: In select rank, compiler error for call to type-bound procedure. Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gustav.r.jansen at gmail dot com Target Milestone: --- Created attachment 50159 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50159&action=edit Source code for reproducer The attached code fails to compile when a type-bound procedure is called within a select rank block. The compiler gives the following output: /home/software/gcc/10.2.0/bin/gfortran -v -save-temps -Wall -Wextra -fno-strict-aliasing -fwrapv -fno-aggressive-loop-optimizations -fsanitize=undefined -c main.f90 Using built-in specs. COLLECT_GCC=/home/software/gcc/10.2.0/bin/gfortran Target: x86_64-pc-linux-gnu Configured with: ../gcc-10.2.0/configure --prefix=/home/software/gcc/10.2.0 --disable-multilib Thread model: posix Supported LTO compression algorithms: zlib gcc version 10.2.0 (GCC) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-Wextra' '-fno-strict-aliasing' '-fwrapv' '-fno-aggressive-loop-optimizations' '-fsanitize=undefined' '-c' '-mtune=generic' '-march=x86-64' /home/software/gcc/10.2.0/libexec/gcc/x86_64-pc-linux-gnu/10.2.0/f951 main.f90 -quiet -dumpbase main.f90 -mtune=generic -march=x86-64 -auxbase main -Wall -Wextra -version -fno-strict-aliasing -fwrapv -fno-aggressive-loop-optimizations -fsanitize=undefined -fintrinsic-modules-path /home/software/gcc/10.2.0/lib/gcc/x86_64-pc-linux-gnu/10.2.0/finclude -o main.s GNU Fortran (GCC) version 10.2.0 (x86_64-pc-linux-gnu) compiled by GNU C version 10.2.0, GMP version 6.1.0, MPFR version 3.1.4, MPC version 1.0.3, isl version isl-0.18-GMP GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU Fortran2008 (GCC) version 10.2.0 (x86_64-pc-linux-gnu) compiled by GNU C version 10.2.0, GMP version 6.1.0, MPFR version 3.1.4, MPC version 1.0.3, isl version isl-0.18-GMP GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 main.f90:21:43: 21 | call t%do_something_in_a_type() | 1 Error: ‘do_something_in_a_type’ at (1) is not a function
[Bug rtl-optimization/99041] combine creates invalid address which ICEs in decompose_normal_address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99041 --- Comment #5 from Segher Boessenkool --- (As Jakub said; I'm just slow).
[Bug analyzer/98575] [11 regression] False -Wanalyzer-malloc-leak on code path involving unknown function call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98575 --- Comment #6 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:790a8e8942b3f5a896ab5897cd209de1d9c382ae commit r11-7156-g790a8e8942b3f5a896ab5897cd209de1d9c382ae Author: David Malcolm Date: Tue Feb 9 15:54:14 2021 -0500 analyzer: support "_IO_"-prefixed variants of FILE * fns [PR98575] PR analyzer/98575 describes an unexpected -Wanalyzer-malloc-leak false positive from gcc.dg/analyzer/pr94851-1.c on glibc < 2.28. The issue is that a getchar call gets inlined into a call to _IO_getc, and "_IO_getc" is not in the set of FILE * functions the analyzer "knows about". This exposes a bug in memory leak detection on code paths in which an unknown function has been called. The memory leak bug is fixed in the prior commit, but for good measure this patch special-cases the "_IO_"-prefixed names in glibc so that the analyzer can reuse its knowledge about the unprefixed variants. gcc/analyzer/ChangeLog: PR analyzer/98575 * sm-file.cc (is_file_using_fn_p): Support "_IO_"-prefixed variants. gcc/testsuite/ChangeLog: PR analyzer/98575 * gcc.dg/analyzer/file-1.c (test_5): New. * gcc.dg/analyzer/file-3.c: New test.
[Bug c++/99018] Comparing address of array element not considered a constant expression in certain contexts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99018
David Stone changed:
What|Removed |Added
CC||david at doublewise dot net
--- Comment #1 from David Stone ---
Here's a simpler test case
```
struct s {
constexpr ~s() {
if (this) {
}
}
};
constexpr bool f(s (&&)[1]) {
return true;
}
static_assert(f(
{s()}
));
```
Message:
```
:12:16: error: non-constant condition for static assertion
12 | static_assert(f(
| ~^
13 | {s()}
| ~
14 | ));
| ~
:14:1: error: '(((s*)(&)) != 0)' is not a constant
expression
14 | ));
| ^
Compiler returned: 1
```
[Bug analyzer/98575] [11 regression] False -Wanalyzer-malloc-leak on code path involving unknown function call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98575 --- Comment #5 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:1d9f3b7ad4f965a0acc21d42cb2d186ecd065b71 commit r11-7155-g1d9f3b7ad4f965a0acc21d42cb2d186ecd065b71 Author: David Malcolm Date: Tue Feb 9 15:53:01 2021 -0500 analyzer: treat pointers written to *UNKNOWN as escaping [PR98575] PR analyzer/98575 describes an unexpected -Wanalyzer-malloc-leak false positive from gcc.dg/analyzer/pr94851-1.c on glibc < 2.28. The issue is that a getchar call gets inlined into a call to _IO_getc, and "_IO_getc" is not in the set of FILE * functions the analyzer "knows about". This leads to a global pointer struct buf *curbp; being treated as UNKNOWN after the call to _IO_getc. Later when a malloced pointer is written to curbp->b_amark, the write is discarded (since curbp is unknown) without noting that the pointer has escaped, and so the pointer is erroneously treated as leaking when the function returns. This patch updates the handling of *UNKNOWN to treat pointers written to them as having escaped, fixing the false positive. The patch stops the leak warning in gcc.dg/analyzer/explode-1.c. After merging states at the join-point after the first switch, pp has UNKNOWN value, and so *pp is a write through UNKNOWN, which with this patch is now treated as escaping - despite the fact that all possible values for *pp are on the stack. There doesn't seem to be a good way to fix this, and the testcase is an artifically constructed one, so the patch simply removes the dg-warning directive. gcc/analyzer/ChangeLog: PR analyzer/98575 * store.cc (store::set_value): Treat a pointer written to *UNKNOWN as having escaped. gcc/testsuite/ChangeLog: PR analyzer/98575 * gcc.dg/analyzer/explode-1.c: Remove expected leak warning. * gcc.dg/analyzer/pr94851-2.c: New test. * gcc.dg/analyzer/pr98575-1.c: New test.
[Bug rtl-optimization/99041] combine creates invalid address which ICEs in decompose_normal_address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99041 --- Comment #4 from Segher Boessenkool --- combine always asks recog(), so that must have said it is okay?
[Bug bootstrap/98860] [11 Regression] boostrap failure on MinGW-w64 windows 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2021-02-09 Ever confirmed|0 |1 --- Comment #33 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #32) > FWIW Wine gives this error when trying to run binaries created by GCC trunk > (and binutils 2.34): > > 0104:err:process:exec_process L"Z:\\tmp\\a.exe" not supported on this system i.e. there's no need to transfer anything to Windows for execution.
[Bug bootstrap/98860] [11 Regression] boostrap failure on MinGW-w64 windows 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860 --- Comment #32 from Jonathan Wakely --- FWIW Wine gives this error when trying to run binaries created by GCC trunk (and binutils 2.34): 0104:err:process:exec_process L"Z:\\tmp\\a.exe" not supported on this system Comparing the objdump -h output for a working a.exe (compiled with GCC 10.2) and trunk, I see these extra sections for the trunk version: 0 .debug_loclists 001e7053 0001 0001 0480 2**0 CONTENTS, READONLY, DEBUGGING 1 .debug_rnglists 00058653 0001 0001 001e7680 2**0 CONTENTS, READONLY, DEBUGGING I'm not sure what else to compare. Stripping all debug symbols from a.exe makes it usable with Wine.
[Bug bootstrap/98860] [11 Regression] boostrap failure on MinGW-w64 windows 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860 --- Comment #31 from Mikael Pettersson --- Created attachment 50158 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50158&action=edit conftest.c (based configure's cross compilation test) This runs Ok when compiled with "-O2 -g -gdwarf-4", but fails with Windows error code 193 aka "Exec format error" when compiled with "-O2 -g -gdwarf-5". The error is reproducible with a x86_64-w64-mingw32 cross (just transfer the EXEs to Windows for execution). Compiling with -S shows differences in several .debug sections.
[Bug rtl-optimization/96015] [10/11 Regression] gcc-10.1.0 miscompiles Python on hppa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96015 --- Comment #44 from dave.anglin at bell dot net --- On 2021-02-09 2:01 p.m., ebotcazou at gcc dot gnu.org wrote: > This should be fixed on the 10 branch. Thank you Eric 😁
[Bug target/98729] [11 Regression] GCC 11 MinGW Windows build doesn't generate working PE executables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98729 --- Comment #13 from Jonathan Wakely --- (In reply to Brecht Sanders from comment #8) > Also, my win64 build uses SEH, not dwarf, DWARF is still used for debug info even if you don't use it for EH.
[Bug c++/95888] [9/10/11 Regression] Regression in 9.3. GCC freezes when compiling code using boost::poly_collection::segment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95888
--- Comment #6 from Marek Polacek ---
I've found out that the same issue happens with auto template parameter too,
and started way before my change:
template class A {
A(int, int);
template friend class A;
friend T;
};
template struct B {
template struct C {
A begin() { return {1, 0}; }
};
template
C fn();
};
int
main ()
{
B b;
b.fn<1>().begin();
}
this (valid) used to crash, and since r243867 we loop infinitely.
I have a patch that fixes both.
[Bug analyzer/99044] New: use-after-free false positive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99044
Bug ID: 99044
Summary: use-after-free false positive
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: antonio.chirizzi at gmail dot com
Target Milestone: ---
Created attachment 50157
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50157&action=edit
Reproducer for the bug
Please find attached the reproducer for this use-after-free which looks a false
positive.
ls-tree-with-commit.c: In function ‘oid2strbuf_free’:
ls-tree-with-commit.c:53:17: warning: use after ‘free’ of ‘e_strbuf’ [CWE-416]
[-Wanalyzer-use-after-free]
53 | strbuf_release(e_strbuf->value);
| ^~~
‘oid2strbuf_free’: events 1-6
|
| 51 | while ((e = hashmap_iter_next(&iter))) {
| |^
| ||
| |(1) following ‘true’ branch (when ‘e’ is
non-NULL)...
| |(4) following ‘true’ branch (when ‘e’ is
non-NULL)...
| 52 | struct oid2strbuf *e_strbuf = (struct oid2strbuf
*)e;
| |
| ||
| |(2) ...to here
| |(5) ...to here
| 53 | strbuf_release(e_strbuf->value);
| | ~~~
| | |
| | (6) use after ‘free’ of ‘e_strbuf’; freed at (3)
| 54 | free(e_strbuf->value);
| 55 | free(e);
| | ~~~
| | |
| | (3) freed here
use "gcc -fanalyzer -c ls-tree-with-commit.c"
[Bug tree-optimization/99002] [11 Regression] memory leak in if-to-switch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99002 --- Comment #2 from Richard Biener --- Another one: ==17557== Memcheck, a memory error detector ==17557== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==17557== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info ==17557== Command: ./cc1 -quiet -fdiagnostics-plain-output -O3 -o ssa-dom-thread-1.s /home/rguenther/src/gcc3/gcc/testsuite/gcc.dg/torture/pr63464.c ==17557== ==17557== ==17557== HEAP SUMMARY: ==17557== in use at exit: 1,890,206 bytes in 2,855 blocks ==17557== total heap usage: 86,712 allocs, 83,857 frees, 16,547,876 bytes allocated ==17557== ==17557== 448 bytes in 8 blocks are definitely lost in loss record 674 of 760 ==17557==at 0x4C2E94F: operator new(unsigned long) (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==17557==by 0x24FF041: if_chain::is_beneficial() (gimple-if-to-switch.cc:207) ==17557==by 0x250052F: (anonymous namespace)::pass_if_to_switch::execute(function*) (gimple-if-to-switch.cc:545) ==17557==by 0x12E7FEA: execute_one_pass(opt_pass*) (passes.c:2572) ==17557==by 0x12E8321: execute_pass_list_1(opt_pass*) (passes.c:2661) ==17557==by 0x12E8352: execute_pass_list_1(opt_pass*) (passes.c:2662) ==17557==by 0x12E83AA: execute_pass_list(function*, opt_pass*) (passes.c:2672) ==17557==by 0x12E62DF: do_per_function_toporder(void (*)(function*, void*), void*) (passes.c:1774) ==17557==by 0x12E8FDA: execute_ipa_pass_list(opt_pass*) (passes.c:3006) ==17557==by 0xCFC9EE: ipa_passes() (cgraphunit.c:2157) ==17557==by 0xCFCE24: symbol_table::compile() (cgraphunit.c:2292) ==17557==by 0xCFD391: symbol_table::finalize_compilation_unit() (cgraphunit.c:2540)
[Bug rtl-optimization/99041] combine creates invalid address which ICEs in decompose_normal_address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99041 --- Comment #3 from Peter Bergner --- (In reply to Jakub Jelinek from comment #2) > Combiner tries to combine whatever it can and if it matches (and costs > suggest it is beneficial) it keeps it. > So, this looks like a target bug to me. > In particular, mma_assemble_input_operand predicate seems to allow any MEM > whatsoever as long as it has V16QImode: > (define_special_predicate "mma_assemble_input_operand" > (match_test "(mode == V16QImode > && (vsx_register_operand (op, mode) || MEM_P (op)))")) > I don't believe it can allow any, there must be some requirement on what the > address of the MEM can be, whether a REG + REG, REG + offset etc. and the > ICE is a proof it is not the case. Ahh, ok. I can make that more robust. Thanks for the pointer!
[Bug fortran/99043] New: Inconsistent behavior when calling rank(ptr) for assumed-rank null pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99043 Bug ID: 99043 Summary: Inconsistent behavior when calling rank(ptr) for assumed-rank null pointer Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gustav.r.jansen at gmail dot com Target Milestone: --- Created attachment 50156 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50156&action=edit Source code that reproduces the described behaviour Calling rank(ptr) on an assumed-rank null pointer dummy argument returns -1 when the procedure is called with an assumed-rank argument, while it returns the correct rank when the procedure is called with a non-assumed-rank argument. The attached file contains a small reproducer to illustrate the behavior. Here is the output when executed: Lvl1: Expected rank 3, got rank:3 Lvl2: Expected rank 3, got rank: -1 Here is the output of the compiler: /home/software/gcc/10.2.0/bin/gfortran -v -save-temps -Wall -Wextra -fno-strict-aliasing -fwrapv -fno-aggressive-loop-optimizations -fsanitize=undefined -o assumed_rank.x main.f90 Driving: /home/software/gcc/10.2.0/bin/gfortran -v -save-temps -Wall -Wextra -fno-strict-aliasing -fwrapv -fno-aggressive-loop-optimizations -fsanitize=undefined -o assumed_rank.x main.f90 -l gfortran -l m -shared-libgcc Using built-in specs. COLLECT_GCC=/home/software/gcc/10.2.0/bin/gfortran COLLECT_LTO_WRAPPER=/home/software/gcc/10.2.0/libexec/gcc/x86_64-pc-linux-gnu/10.2.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../gcc-10.2.0/configure --prefix=/home/software/gcc/10.2.0 --disable-multilib Thread model: posix Supported LTO compression algorithms: zlib gcc version 10.2.0 (GCC) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-Wextra' '-fno-strict-aliasing' '-fwrapv' '-fno-aggressive-loop-optimizations' '-fsanitize=undefined' '-o' 'assumed_rank.x' '-shared-libgcc' '-mtune=generic' '-march=x86-64' /home/software/gcc/10.2.0/libexec/gcc/x86_64-pc-linux-gnu/10.2.0/f951 main.f90 -quiet -dumpbase main.f90 -mtune=generic -march=x86-64 -auxbase main -Wall -Wextra -version -fno-strict-aliasing -fwrapv -fno-aggressive-loop-optimizations -fsanitize=undefined -fintrinsic-modules-path /home/software/gcc/10.2.0/lib/gcc/x86_64-pc-linux-gnu/10.2.0/finclude -o main.s GNU Fortran (GCC) version 10.2.0 (x86_64-pc-linux-gnu) compiled by GNU C version 10.2.0, GMP version 6.1.0, MPFR version 3.1.4, MPC version 1.0.3, isl version isl-0.18-GMP GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU Fortran2008 (GCC) version 10.2.0 (x86_64-pc-linux-gnu) compiled by GNU C version 10.2.0, GMP version 6.1.0, MPFR version 3.1.4, MPC version 1.0.3, isl version isl-0.18-GMP GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-Wextra' '-fno-strict-aliasing' '-fwrapv' '-fno-aggressive-loop-optimizations' '-fsanitize=undefined' '-o' 'assumed_rank.x' '-shared-libgcc' '-mtune=generic' '-march=x86-64' as -v --64 -o main.o main.s GNU assembler version 2.30 (x86_64-linux-gnu) using BFD version (GNU Binutils for Ubuntu) 2.30 Reading specs from /home/software/gcc/10.2.0/lib64/../lib64/libgfortran.spec rename spec lib to liborig COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-Wextra' '-fno-strict-aliasing' '-fwrapv' '-fno-aggressive-loop-optimizations' '-fsanitize=undefined' '-o' 'assumed_rank.x' '-shared-libgcc' '-mtune=generic' '-march=x86-64' COMPILER_PATH=/home/software/gcc/10.2.0/libexec/gcc/x86_64-pc-linux-gnu/10.2.0/:/home/software/gcc/10.2.0/libexec/gcc/x86_64-pc-linux-gnu/10.2.0/:/home/software/gcc/10.2.0/libexec/gcc/x86_64-pc-linux-gnu/:/home/software/gcc/10.2.0/lib/gcc/x86_64-pc-linux-gnu/10.2.0/:/home/software/gcc/10.2.0/lib/gcc/x86_64-pc-linux-gnu/ LIBRARY_PATH=/home/software/gcc/10.2.0/lib64/../lib64/:/home/software/gcc/10.2.0/lib/gcc/x86_64-pc-linux-gnu/10.2.0/:/home/software/gcc/10.2.0/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../lib64/:/lib/x86_64-linux-gnu/:/lib/../lib64/:/usr/lib/x86_64-linux-gnu/:/home/software/gcc/10.2.0/lib64/:/home/software/gcc/10.2.0/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-Wextra' '-fno-strict-aliasing' '-fwrapv' '-fno-aggressive-loop-optimizations' '-fsanitize=undefined' '-o' 'assumed_rank.x' '-shared-libgcc' '-mtune=generic' '-march=x86-64' /home/software/gcc/10.2.0/libexec/gcc/x86_64-pc-linux-gnu/10.2.0/collect2 -plugin /home/software/gcc/10.2.0/libexec/gcc/x86_64-pc-linux-gnu/10.2.0/liblto_plugin.so -plugin-opt=/home/software/gcc/10.2.0/libexec/gcc/x86_64-pc-linux-gnu/10.2.0/lto-wrapper -plugin-opt=-fresolution=main.res -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lquadmath -plugin-opt=-pass-thro
[Bug rtl-optimization/99041] combine creates invalid address which ICEs in decompose_normal_address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99041 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Combiner tries to combine whatever it can and if it matches (and costs suggest it is beneficial) it keeps it. So, this looks like a target bug to me. In particular, mma_assemble_input_operand predicate seems to allow any MEM whatsoever as long as it has V16QImode: (define_special_predicate "mma_assemble_input_operand" (match_test "(mode == V16QImode && (vsx_register_operand (op, mode) || MEM_P (op)))")) I don't believe it can allow any, there must be some requirement on what the address of the MEM can be, whether a REG + REG, REG + offset etc. and the ICE is a proof it is not the case.
[Bug rtl-optimization/96015] [10/11 Regression] gcc-10.1.0 miscompiles Python on hppa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96015 Eric Botcazou changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #43 from Eric Botcazou --- This should be fixed on the 10 branch.
[Bug rtl-optimization/96015] [10/11 Regression] gcc-10.1.0 miscompiles Python on hppa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96015 --- Comment #42 from CVS Commits --- The releases/gcc-10 branch has been updated by Eric Botcazou : https://gcc.gnu.org/g:b1d2ed3ad54378e8798dab27c841418f3f60cff2 commit r10-9354-gb1d2ed3ad54378e8798dab27c841418f3f60cff2 Author: Eric Botcazou Date: Tue Feb 9 19:49:18 2021 +0100 Fix miscompilation of Python on HP-PA/Linux This is the miscompilation of Python at -O2 on HP-PA/Linux present on the mainline and 10 branch, caused by the presence of a call to __builtin_unreachable () in the middle of a heavily branchy code, which confuses the reorg pass. gcc/ PR rtl-optimization/96015 * reorg.c (skip_consecutive_labels): Minor comment tweaks. (relax_delay_slots): When deleting a jump to the next active instruction over a barrier, first delete the barrier if the jump is the only way to reach the target label.
[Bug rtl-optimization/96015] [10/11 Regression] gcc-10.1.0 miscompiles Python on hppa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96015 --- Comment #41 from CVS Commits --- The master branch has been updated by Eric Botcazou : https://gcc.gnu.org/g:20f28986a8d3cad3c848d1e7da48f4bea7637298 commit r11-7154-g20f28986a8d3cad3c848d1e7da48f4bea7637298 Author: Eric Botcazou Date: Tue Feb 9 19:49:18 2021 +0100 Fix miscompilation of Python on HP-PA/Linux This is the miscompilation of Python at -O2 on HP-PA/Linux present on the mainline and 10 branch, caused by the presence of a call to __builtin_unreachable () in the middle of a heavily branchy code, which confuses the reorg pass. gcc/ PR rtl-optimization/96015 * reorg.c (skip_consecutive_labels): Minor comment tweaks. (relax_delay_slots): When deleting a jump to the next active instruction over a barrier, first delete the barrier if the jump is the only way to reach the target label.
[Bug analyzer/99042] New: file-leak is wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99042 Bug ID: 99042 Summary: file-leak is wrong Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: analyzer Assignee: dmalcolm at gcc dot gnu.org Reporter: antonio.chirizzi at gmail dot com Target Milestone: --- Created attachment 50155 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50155&action=edit Reproducer log.c file for the bug A file leak warning is shown, but it should not. See attached log.c reproducer. Please note that I tried to strip the file to a minimum (while trying to leave all the big complex data structures), but it still shows many warnings due to undeclared functions (it's part of the git code base) The leak warning is anyway consistent with what is shown on the real log.c file in the code base. In function ‘open_next_file’: log.c:495:16: warning: leak of FILE ‘’ [CWE-775] [-Wanalyzer-file-leak] 495 | return 0; |^ ‘open_next_file’: events 1-3 | | 491 | if ((rev->diffopt.file = fopen(filename.buf, "w")) == NULL) | |^ | || | |(1) following ‘false’ branch... |.. | 494 | strbuf_release(&filename); | | ~ | | | | | (2) ...to here | 495 | return 0; | |~ | || | |(3) ‘’ leaks here | Use "gcc -fanalyzer -c log.c"
[Bug rtl-optimization/99041] combine creates invalid address which ICEs in decompose_normal_address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99041
Peter Bergner changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Last reconfirmed||2021-02-09
--- Comment #1 from Peter Bergner ---
This looks like a combine issue. Before combine, we have:
(insn 124 123 125 3 (set (reg:V2DF 198 [ MEM [(void *)_75] ])
(mem:V2DF (reg:DI 149 [ ivtmp.49 ]) [0 MEM [(void *)_75]+0 S16
A8])) "bug.ii":22:67 1130 {vsx_movv2df_64bit}
(nil))
(insn 125 124 126 3 (set (reg:DI 199)
(plus:DI (reg:DI 142 [ _63 ])
(reg:DI 149 [ ivtmp.49 ]))) "bug.ii":22:67 66 {*adddi3}
(nil))
(insn 126 125 127 3 (set (reg:V2DF 200 [ MEM [(void *)_24 + _16 * 1] ])
(mem:V2DF (plus:DI (reg:DI 199)
(reg:DI 197)) [0 MEM [(void *)_24 + _16 * 1]+0 S16 A8]))
"bug.ii":22:67 1130 {vsx_movv2df_64bit}
(expr_list:REG_DEAD (reg:DI 199)
(nil)))
(insn 127 126 128 3 (set (reg:OO 138 [ _41 ])
(unspec:OO [
(subreg:V16QI (reg:V2DF 198 [ MEM [(void *)_75] ]) 0)
(subreg:V16QI (reg:V2DF 200 [ MEM [(void *)_24 + _16 * 1]
]) 0)
] UNSPEC_MMA_ASSEMBLE)) 2074 {*mma_assemble_pair}
(expr_list:REG_DEAD (reg:V2DF 200 [ MEM [(void *)_24 + _16 * 1] ])
(expr_list:REG_DEAD (reg:V2DF 198 [ MEM [(void *)_75] ])
(nil
After combine, we have:
(note 124 123 125 3 NOTE_INSN_DELETED)
(note 125 124 126 3 NOTE_INSN_DELETED)
(note 126 125 127 3 NOTE_INSN_DELETED)
(insn 127 126 128 3 (set (reg:OO 138 [ _41 ])
(unspec:OO [
(mem:V16QI (reg:DI 149 [ ivtmp.49 ]) [0 MEM [(void
*)_75]+0 S16 A8])
(mem:V16QI (plus:DI (plus:DI (reg:DI 142 [ _63 ])
(reg:DI 149 [ ivtmp.49 ]))
(reg:DI 197)) [0 MEM [(void *)_24 + _16 * 1]+0 S16
A8])
] UNSPEC_MMA_ASSEMBLE)) 2074 {*mma_assemble_pair}
(nil))
That bad address on the 2nd mem then makes it all the way to LRA which
eventually dies when it calls decompose_normal_address on it.
Segher, is combine allowed to create invalid addresses like that and LRA is
supposed to fix it up or is this really a combine issue?
[Bug target/99025] [11 Regression] ICE Segmentation fault since r11-6351-g12ae2bc70846a2be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99025 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #1 from Jakub Jelinek --- Created attachment 50154 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50154&action=edit gcc11-pr99025.patch Untested fix. The problem is that when simplify_gen_subreg is called on a SUBREG and simplify_subreg fails to simplify it, because of mismatching element mode as well as mismatching size, then simplify_gen_subreg just returns NULL instead of creating the subreg. The patch forces those SUBREGs into regs so that simplify_gen_subreg will then always work.
[Bug rtl-optimization/99041] New: combine creates invalid address which ICEs in decompose_normal_address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99041
Bug ID: 99041
Summary: combine creates invalid address which ICEs in
decompose_normal_address
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: bergner at gcc dot gnu.org
Target Milestone: ---
Created attachment 50153
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50153&action=edit
creduced test case
For a reduced test case from the Eigen library with some MMA builtin usage, we
are ICEing in decompose_normal_address():
bergner@pike:~/gcc/BUGS/MMA/CHIP$ xg++ -B/path/to/gcc -S -mcpu=power10
-std=c++03 -nostdinc -fno-check-new -fno-common -fstrict-aliasing -ansi -O2 -w
polynomialsolver.ii
during RTL pass: reload
polynomialsolver.ii: In function ‘void test_polynomialsolver()’:
polynomialsolver.ii:78:67: internal compiler error: in
decompose_normal_address, at rtlanal.c:6754
78 | void test_polynomialsolver() { polynomialsolver< double, 5 >(5); }
| ^
0x10ecf3cf decompose_normal_address
/home/bergner/gcc/gcc-fsf-mainline-pr98872/gcc/rtlanal.c:6754
0x10ecf3cf decompose_address(address_info*, rtx_def**, machine_mode, unsigned
char, rtx_code)
/home/bergner/gcc/gcc-fsf-mainline-pr98872/gcc/rtlanal.c:6787
0x10cda44f process_address_1
/home/bergner/gcc/gcc-fsf-mainline-pr98872/gcc/lra-constraints.c:3460
0x10cdd80b process_address
/home/bergner/gcc/gcc-fsf-mainline-pr98872/gcc/lra-constraints.c:3734
0x10cdd80b curr_insn_transform
/home/bergner/gcc/gcc-fsf-mainline-pr98872/gcc/lra-constraints.c:4049
0x10ce497f lra_constraints(bool)
/home/bergner/gcc/gcc-fsf-mainline-pr98872/gcc/lra-constraints.c:5138
0x10cc560f lra(_IO_FILE*)
/home/bergner/gcc/gcc-fsf-mainline-pr98872/gcc/lra.c:2336
0x10c535bb do_reload
/home/bergner/gcc/gcc-fsf-mainline-pr98872/gcc/ira.c:5821
0x10c535bb execute
/home/bergner/gcc/gcc-fsf-mainline-pr98872/gcc/ira.c:6007
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug target/88197] ICE in decompose_normal_address, at rtlanal.c:6381
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88197 --- Comment #4 from Peter Bergner --- (In reply to Peter Bergner from comment #3) > Actually, this looks like a combine issue. Before combine, we have: Bah, wrong bug. Sorry!
[Bug target/88197] ICE in decompose_normal_address, at rtlanal.c:6381
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88197
--- Comment #3 from Peter Bergner ---
Actually, this looks like a combine issue. Before combine, we have:
(insn 124 123 125 3 (set (reg:V2DF 198 [ MEM [(void *)_75] ])
(mem:V2DF (reg:DI 149 [ ivtmp.49 ]) [0 MEM [(void *)_75]+0 S16
A8])) "bug.ii":22:67 1130 {vsx_movv2df_64bit}
(nil))
(insn 125 124 126 3 (set (reg:DI 199)
(plus:DI (reg:DI 142 [ _63 ])
(reg:DI 149 [ ivtmp.49 ]))) "bug.ii":22:67 66 {*adddi3}
(nil))
(insn 126 125 127 3 (set (reg:V2DF 200 [ MEM [(void *)_24 + _16 * 1] ])
(mem:V2DF (plus:DI (reg:DI 199)
(reg:DI 197)) [0 MEM [(void *)_24 + _16 * 1]+0 S16 A8]))
"bug.ii":22:67 1130 {vsx_movv2df_64bit}
(expr_list:REG_DEAD (reg:DI 199)
(nil)))
(insn 127 126 128 3 (set (reg:OO 138 [ _41 ])
(unspec:OO [
(subreg:V16QI (reg:V2DF 198 [ MEM [(void *)_75] ]) 0)
(subreg:V16QI (reg:V2DF 200 [ MEM [(void *)_24 + _16 * 1]
]) 0)
] UNSPEC_MMA_ASSEMBLE)) 2074 {*mma_assemble_pair}
(expr_list:REG_DEAD (reg:V2DF 200 [ MEM [(void *)_24 + _16 * 1] ])
(expr_list:REG_DEAD (reg:V2DF 198 [ MEM [(void *)_75] ])
(nil
After combine, we have:
(note 124 123 125 3 NOTE_INSN_DELETED)
(note 125 124 126 3 NOTE_INSN_DELETED)
(note 126 125 127 3 NOTE_INSN_DELETED)
(insn 127 126 128 3 (set (reg:OO 138 [ _41 ])
(unspec:OO [
(mem:V16QI (reg:DI 149 [ ivtmp.49 ]) [0 MEM [(void
*)_75]+0 S16 A8])
(mem:V16QI (plus:DI (plus:DI (reg:DI 142 [ _63 ])
(reg:DI 149 [ ivtmp.49 ]))
(reg:DI 197)) [0 MEM [(void *)_24 + _16 * 1]+0 S16
A8])
] UNSPEC_MMA_ASSEMBLE)) 2074 {*mma_assemble_pair}
(nil))
That bad address on the 2nd mem then makes it all the way to LRA which
eventually dies when it calls decompose_normal_address on it.
Segher, is combine allowed to create invalid addresses like that and LRA is
supposed to fix it up or is this really a combine issue?
[Bug c++/99040] New: [modules] partitions & using declarations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99040
Bug ID: 99040
Summary: [modules] partitions & using declarations
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nathan at gcc dot gnu.org
Target Milestone: ---
triaged from pr98760
// t1.ii
export module format;
export namespace NS
{
void Format ();
}
// t2.ii
export module hello:check;
export namespace NS {}
// t3.ii
export module hello;
export import :check;
import format;
export namespace NS
{
using NS::Format;
}
// t4.ii
module hello;
./cc1plus -quiet -std=c++17 -fmodules-ts -fpreprocessed t1.ii && ./cc1plus
-quiet -std=c++17 -fmodules-ts -fpreprocessed t2.ii && ./cc1plus -quiet
-std=c++17 -fmodules-ts -fpreprocessed t3.ii && ./cc1plus -quiet -std=c++17
-fmodules-ts -fpreprocessed t4.ii -fno-module-lazy
t4.ii:1:14: internal compiler error: in add_module_decl, at
cp/name-lookup.c:4199
1 | module hello;
| ^
0xd3c3ae add_module_decl(tree_node*, tree_node*, tree_node*)
../../../src/gcc/cp/name-lookup.c:4199
0xd0a848 module_state::read_cluster(unsigned int)
../../../src/gcc/cp/module.cc:14908
0xd13cf8 module_state::load_section(unsigned int, binding_slot*)
../../../src/gcc/cp/module.cc:18068
0xd13a26 module_state::read_language(bool)
../../../src/gcc/cp/module.cc:17997
0xd16625 direct_import
../../../src/gcc/cp/module.cc:18870
0xd16a79 declare_module(module_state*, unsigned int, bool, tree_node*,
cpp_reader*)
../../../src/gcc/cp/module.cc:18975
0xd72cf2 cp_parser_module_declaration
../../../src/gcc/cp/parser.c:13757
0xd5f315 cp_parser_translation_unit
../../../src/gcc/cp/parser.c:4894
0xdc21a4 c_parse_file()
../../../src/gcc/cp/parser.c:45179
0xfa7278 c_common_parse_file()
../../../src/gcc/c-family/c-opts.c:1218
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug c++/99039] cross-module using declarations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99039 Nathan Sidwell changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |nathan at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2021-02-09 Ever confirmed|0 |1
[Bug c++/99030] [11 Regression] ICE in finish_expr_stmt, at cp/semantics.c:776
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99030 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED
[Bug c++/99039] New: cross-module using declarations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99039
Bug ID: 99039
Summary: cross-module using declarations
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nathan at gcc dot gnu.org
Target Milestone: ---
triaged from pr98760
// t1.ii
export module format;
export namespace NS
{
void Format ();
}
// t3.ii
export module hello;
import format;
export namespace NS
{
using NS::Format;
}
devvm1702:99>./cc1plus -quiet -std=c++17 -fmodules-ts -fpreprocessed t1.ii &&
./cc1plus -quiet -std=c++17 -fmodules-ts -fpreprocessed t3.ii
t3.ii:1:9: internal compiler error: in decl_node, at cp/module.cc:8634
1 | export module hello;
| ^~
0xcee399 trees_out::decl_node(tree_node*, walk_kind)
../../../src/gcc/cp/module.cc:8634
0xcf07cb trees_out::tree_node(tree_node*)
../../../src/gcc/cp/module.cc:9161
0xd0976d module_state::write_cluster(elf_out*, depset**, unsigned int,
depset::hash&, unsigned int*, unsigned int*)
../../../src/gcc/cp/module.cc:14660
0xd12c73 module_state::write(elf_out*, cpp_reader*)
../../../src/gcc/cp/module.cc:17707
0xd18d3b finish_module_processing(cpp_reader*)
../../../src/gcc/cp/module.cc:19779
0xc3c87e c_parse_final_cleanups()
../../../src/gcc/cp/decl2.c:5178
0xfa734d c_common_parse_file()
../../../src/gcc/c-family/c-opts.c:1240
Please submit a full bug report,
[Bug c++/99035] [9/10/11 Regression] ICE in declare_weak, at varasm.c:5930
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99035 Marek Polacek changed: What|Removed |Added Priority|P3 |P2
[Bug c++/99035] [9/10/11 Regression] ICE in declare_weak, at varasm.c:5930
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99035 Marek Polacek changed: What|Removed |Added Last reconfirmed||2021-02-09 Ever confirmed|0 |1 Target Milestone|--- |9.4 Status|UNCONFIRMED |NEW CC||jakub at gcc dot gnu.org, ||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek --- Started with r269059.
[Bug target/99038] New: aarch64_rtx_costs is missing tests for vector immediate forms
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99038 Bug ID: 99038 Summary: aarch64_rtx_costs is missing tests for vector immediate forms Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: rsandifo at gcc dot gnu.org Target Milestone: --- Target: aarch64*-*-* aarch64_rtx_costs is relatively good about matching immediates for scalar operations, but it's missing cases for the corresponding vector operations. E.g. PLUS of a vector constant is more expensive (by 1 instruction) than PLUS of a register, even if the constant is a valid immediate operand. This contributes to the brittleness of the costing scheme. E.g. any change to the cost of CONST_VECTOR moves will trigger for cases in which no CONST_VECTOR move is actually needed.
[Bug ipa/99034] [10/11 Regression] ICE in emit_to_new_bb_before, at except.c:932
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99034 Marek Polacek changed: What|Removed |Added Ever confirmed|0 |1 Component|c++ |ipa CC||hubicka at gcc dot gnu.org, ||marxin at gcc dot gnu.org, ||mpolacek at gcc dot gnu.org Status|UNCONFIRMED |NEW Target Milestone|--- |10.3 Last reconfirmed||2021-02-09 --- Comment #1 from Marek Polacek --- Started with r276469.
[Bug c++/99033] [9/10/11 Regression] ICE in tree_to_poly_int64, at tree.c:3091
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99033 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org Summary|[11 Regression] ICE in |[9/10/11 Regression] ICE in |tree_to_poly_int64, at |tree_to_poly_int64, at |tree.c:3091 |tree.c:3091 Target Milestone|--- |9.4 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2021-02-09 --- Comment #2 from Marek Polacek --- Seems to have started with r231665.
[Bug target/99037] Invalid representation of vector zero in aarch64-simd.md
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99037 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Target Milestone|--- |12.0 Last reconfirmed||2021-02-09
[Bug target/99037] New: Invalid representation of vector zero in aarch64-simd.md
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99037 Bug ID: 99037 Summary: Invalid representation of vector zero in aarch64-simd.md Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: rsandifo at gcc dot gnu.org CC: andre.simoesdiasvieira at arm dot com Target Milestone: --- Target: aarch64*-*-* As Andre noticed, the following patterns have an invalid representation of constant zero: - move_lo_quad_internal_ - move_lo_quad_internal_be_ The vector forms use (vec_duplicate …) of a constant instead of a const_vector, and both forms use (const_int 0) even for FP modes. In r5-3343 the patterns were split into two, one with a vec_duplicate and one with a const_int. But I think that was the wrong (partial) fix: we should have a single pattern for each, but use aarch64_simd_or_scalar_imm_zero to match the right form. I guess this will have to wait for GCC 12 at this point.
[Bug c++/99030] [11 Regression] ICE in finish_expr_stmt, at cp/semantics.c:776
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99030 Marek Polacek changed: What|Removed |Added Target Milestone|--- |11.0 Last reconfirmed||2021-02-09 Ever confirmed|0 |1 CC||mpolacek at gcc dot gnu.org, ||nathan at gcc dot gnu.org Status|UNCONFIRMED |NEW --- Comment #1 from Marek Polacek --- Started with r11-3100.
[Bug c++/99032] GCC accepts attributes on friend declarations (not definitions)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99032 Marek Polacek changed: What|Removed |Added Last reconfirmed||2021-02-09 Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Keywords||accepts-invalid CC||mpolacek at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek --- Mine for GCC 12.
[Bug fortran/99036] New: [11 Regression] ICE in gfc_current_interface_head, at fortran/interface.c:4699
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99036 Bug ID: 99036 Summary: [11 Regression] ICE in gfc_current_interface_head, at fortran/interface.c:4699 Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Changed between 20210117 and 20210124 : $ cat z1.f90 module m contains module procedure s end end $ gfortran-11-20210117 -c z1.f90 z1.f90:3:20: 3 |module procedure s |1 Error: MODULE PROCEDURE at (1) must be in a generic module interface $ gfortran-11-20210207 -c z1.f90 f951: internal compiler error: in gfc_current_interface_head, at fortran/interface.c:4699 0x69b474 gfc_current_interface_head() ../../gcc/fortran/interface.c:4699 0x6777e5 gfc_match_modproc() ../../gcc/fortran/decl.c:9883 0x6db9c1 match_word ../../gcc/fortran/parse.c:65 0x6dfe30 decode_statement ../../gcc/fortran/parse.c:522 0x6e097c next_free ../../gcc/fortran/parse.c:1316 0x6e097c next_statement ../../gcc/fortran/parse.c:1548 0x6e511c parse_contained ../../gcc/fortran/parse.c:5743 0x6e5fd7 parse_module ../../gcc/fortran/parse.c:6170 0x6e6307 gfc_parse_file() ../../gcc/fortran/parse.c:6473 0x732e7f gfc_be_parse_file ../../gcc/fortran/f95-lang.c:212
[Bug c++/99035] New: [9/10/11 Regression] ICE in declare_weak, at varasm.c:5930
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99035 Bug ID: 99035 Summary: [9/10/11 Regression] ICE in declare_weak, at varasm.c:5930 Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Affects versions down to r7 (r9 between 20190217 and 20190224), with option -fsyntax-only : $ g++-11-20210207 -c weak-6.c -fsyntax-only weak-6.c:7:14: internal compiler error: in declare_weak, at varasm.c:5930 7 | #pragma weak foo | ^~~ 0xf96654 declare_weak(tree_node*) ../../gcc/varasm.c:5930 0x86f6e1 apply_pragma_weak ../../gcc/c-family/c-pragma.c:265 0x870ae1 handle_pragma_weak ../../gcc/c-family/c-pragma.c:376 0xac cp_parser_pragma ../../gcc/cp/parser.c:45120 0x7a03db cp_parser_translation_unit ../../gcc/cp/parser.c:4936 0x7a03db c_parse_file() ../../gcc/cp/parser.c:45179 0x86d982 c_common_parse_file() ../../gcc/c-family/c-opts.c:1218
[Bug c++/99034] New: [10/11 Regression] ICE in emit_to_new_bb_before, at except.c:932
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99034 Bug ID: 99034 Summary: [10/11 Regression] ICE in emit_to_new_bb_before, at except.c:932 Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- This changed between 20190929 and 20191006 at -O2+ : $ g++-10-20190929 -c pr90208-2.c -finstrument-functions -O2 $ $ g++-11-20210207 -c pr90208-2.c -finstrument-functions -O2 during RTL pass: expand pr90208-2.c: In function 'void baz()': pr90208-2.c:20:1: internal compiler error: Segmentation fault 20 | } | ^ 0xcd922f crash_signal ../../gcc/toplev.c:327 0x9bd1e6 emit_to_new_bb_before ../../gcc/except.c:932 0x9c185a dw2_build_landing_pads ../../gcc/except.c:1013 0x9c185a finish_eh_generation() ../../gcc/except.c:1521 0x8e2e7d execute ../../gcc/cfgexpand.c:6837 --- pr90208-2.c: In function 'void baz()': pr90208-2.c:16:1: error: EH landing pad label 16 | baz (void) | ^~~ is not first in a sequence of labels in bb 5during IPA pass: inline pr90208-2.c:16:1: internal compiler error: verify_flow_info failed 0xae3ac4 verify_flow_info() ../../gcc/cfghooks.c:269 0x1046ba4 checking_verify_flow_info ../../gcc/cfghooks.h:212 0x1046ba4 cleanup_tree_cfg_noloop ../../gcc/tree-cfgcleanup.c:1136 0x1046ba4 cleanup_tree_cfg(unsigned int) ../../gcc/tree-cfgcleanup.c:1187 0xef8a44 execute_function_todo ../../gcc/passes.c:2008 0xef97f2 execute_todo ../../gcc/passes.c:2096 0xefba43 execute_one_ipa_transform_pass ../../gcc/passes.c:2293 0xefba43 execute_all_ipa_transforms(bool) ../../gcc/passes.c:2337 0xb22995 cgraph_node::expand() ../../gcc/cgraphunit.c:1820 0xb24316 expand_all_functions ../../gcc/cgraphunit.c:1995 0xb24316 symbol_table::compile() ../../gcc/cgraphunit.c:2359 0xb2784f symbol_table::compile() ../../gcc/cgraphunit.c:2543 0xb2784f symbol_table::finalize_compilation_unit() ../../gcc/cgraphunit.c:2540
[Bug c++/99033] [11 Regression] ICE in tree_to_poly_int64, at tree.c:3091
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99033 G. Steinmetz changed: What|Removed |Added Target||x86_64-pc-linux-gnu Keywords||ice-on-valid-code --- Comment #1 from G. Steinmetz --- Seems to go back to r6 when configured with --enable-checking=yes : (and then with no need for -fsanitize=undefined) $ g++-11-20210207 -c z1.cc z1.cc:9:1: internal compiler error: tree check: expected constructor, have error_mark in array_size_for_constructor, at varasm.c:5340 9 | } | ^ 0x6629b8 tree_check_failed(tree_node const*, char const*, int, char const*, ...) ../../gcc/tree.c:9814 0x1389b07 tree_check(tree_node*, char const*, int, char const*, tree_code) ../../gcc/tree.h:3349 0x1389b07 array_size_for_constructor ../../gcc/varasm.c:5340 0x1389b07 output_constructor_regular_field ../../gcc/varasm.c:5511 0x1389b07 output_constructor ../../gcc/varasm.c:5797 0x1389ee9 output_constant ../../gcc/varasm.c:5149 #...
[Bug c++/99033] New: [11 Regression] ICE in tree_to_poly_int64, at tree.c:3091
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99033
Bug ID: 99033
Summary: [11 Regression] ICE in tree_to_poly_int64, at
tree.c:3091
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Behavior of release versions changed between 20200517 and 20200524 :
$ cat z1.cc
struct S {
char c;
struct T {} T::*b[];
} a;
void f ()
{
a.c = 1;
}
$ g++-11-20200517 -c z1.cc -fsanitize=undefined
$
$ g++-11-20210207 -c z1.cc -fsanitize=undefined
during GIMPLE pass: ubsan
z1.cc: In function 'void f()':
z1.cc:9:1: internal compiler error: in tree_to_poly_int64, at tree.c:3091
9 | }
| ^
0xf4bbe8 tree_to_poly_int64(tree_node const*)
../../gcc/tree.c:3091
0xf68db4 component_ref_size(tree_node*, special_array_member*)
../../gcc/tree.c:13909
0xd6eb12 decl_init_size(tree_node*, bool)
../../gcc/tree-object-size.c:196
0xd6f062 addr_object_size
../../gcc/tree-object-size.c:285
0xd70583 compute_builtin_object_size(tree_node*, int, unsigned long*,
tree_node**, tree_node**)
../../gcc/tree-object-size.c:570
0xcf945a instrument_object_size
../../gcc/ubsan.c:2150
0xcfe535 execute
../../gcc/ubsan.c:2405
[Bug c++/99032] New: GCC accepts attributes on friend declarations (not definitions)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99032
Bug ID: 99032
Summary: GCC accepts attributes on friend declarations (not
definitions)
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dangelog at gmail dot com
Target Milestone: ---
Hi,
The following code is accepted by GCC 10.2:
struct S { [[deprecated]] friend void f(); };
No errors and no warnings are generated under -Wall -Wextra -pedantic.
The code is however ill-formed: an attribute cannot appear on a friend
declaration which isn't also a definition:
https://eel.is/c++draft/dcl.attr#grammar-5.sentence-3
If an attribute-specifier-seq appertains to a friend declaration
([class.friend]), that declaration shall be a definition.
For comparison, Clang rejects this, and MSVC accepts it (without warnings).
[Bug c++/99031] New: Comparing pointers to heap-allocated memory is not a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99031
Bug ID: 99031
Summary: Comparing pointers to heap-allocated memory is not a
constant expression
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: david at doublewise dot net
Target Milestone: ---
The following valid translation unit
```
constexpr bool f() {
auto a = new int;
auto b = new int;
if (a == b) {
}
delete b;
delete a;
return true;
}
static_assert(f());
```
is rejected with
```
:11:16: error: non-constant condition for static assertion
11 | static_assert(f());
| ~^~
:11:16: in 'constexpr' expansion of 'f()'
:4:15: error: '(((int*)(& heap )) == ((int*)(& heap )))' is not a
constant expression
4 | if (a == b) {
| ~~^~~~
Compiler returned: 1
```
See it live: https://godbolt.org/z/of45no
[Bug c++/99030] New: [11 Regression] ICE in finish_expr_stmt, at cp/semantics.c:776
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99030
Bug ID: 99030
Summary: [11 Regression] ICE in finish_expr_stmt, at
cp/semantics.c:776
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Changed somewhere between 20200823 and 20201004 :
$ cat z1.cc
void foo ()
{
extern int a;
[] (auto b) { a; } (1);
}
$ g++-11-20200823 -c z1.cc
$
$ g++-11-20210207 -c z1.cc
z1.cc: In instantiation of 'foo():: [with auto:1 = int]':
z1.cc:4:24: required from here
z1.cc:4:17: internal compiler error: in finish_expr_stmt, at cp/semantics.c:776
4 | [] (auto b) { a; } (1);
| ^
0x7e11cc finish_expr_stmt(tree_node*)
../../gcc/cp/semantics.c:776
0x7c72b9 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/cp/pt.c:18158
0x7c5c17 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/cp/pt.c:18475
0x7c5c17 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/cp/pt.c:18475
0x7ba4f3 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/cp/pt.c:25835
0x7ba4f3 instantiate_body
../../gcc/cp/pt.c:25835
0x7bb580 instantiate_decl(tree_node*, bool, bool)
../../gcc/cp/pt.c:26124
0x6ea4d3 maybe_instantiate_decl(tree_node*)
../../gcc/cp/decl2.c:5463
0x6ead54 mark_used(tree_node*, int)
../../gcc/cp/decl2.c:5691
0x674792 build_over_call
../../gcc/cp/call.c:9357
0x678b73 build_op_call_1
../../gcc/cp/call.c:4957
0x678b73 build_op_call(tree_node*, vec**, int)
../../gcc/cp/call.c:4986
0x7e4c72 finish_call_expr(tree_node*, vec**, bool,
bool, int)
../../gcc/cp/semantics.c:2762
0x783995 cp_parser_postfix_expression
../../gcc/cp/parser.c:7715
0x793d35 cp_parser_unary_expression
../../gcc/cp/parser.c:8818
0x76d96f cp_parser_cast_expression
../../gcc/cp/parser.c:9722
0x76e1a2 cp_parser_binary_expression
../../gcc/cp/parser.c:9824
0x76e900 cp_parser_assignment_expression
../../gcc/cp/parser.c:10128
0x76f77c cp_parser_expression
../../gcc/cp/parser.c:10298
0x772317 cp_parser_expression_statement
../../gcc/cp/parser.c:11965
[Bug tree-optimization/98950] jump threading memory leak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98950 --- Comment #3 from Richard Biener --- Also hapens as ==15400== Memcheck, a memory error detector ==15400== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==15400== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info ==15400== Command: ./cc1 -quiet -fdiagnostics-plain-output -O3 -o ssa-dom-thread-2.s /home/rguenther/src/gcc3/gcc/testsuite/gcc.c-torture/compile/20101217-1.c ==15400== ==15400== ==15400== HEAP SUMMARY: ==15400== in use at exit: 1,890,156 bytes in 2,913 blocks ==15400== total heap usage: 27,977 allocs, 25,064 frees, 9,494,149 bytes allocated ==15400== ==15400== 16 bytes in 1 blocks are definitely lost in loss record 9 of 740 ==15400==at 0x4C2E94F: operator new(unsigned long) (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==15400==by 0x180CA7B: thread_jumps::convert_and_register_current_path(edge_def*) (tree-ssa-threadbackward.c:472) ==15400==by 0x180CD8E: thread_jumps::register_jump_thread_path_if_profitable(tree_node*, tree_node*, basic_block_def*) (tree-ssa-threadbackward.c:561) ==15400==by 0x180CEB6: thread_jumps::handle_phi(gphi*, tree_node*, basic_block_def*) (tree-ssa-threadbackward.c:600) ==15400==by 0x180D268: thread_jumps::fsm_find_control_statement_thread_paths(tree_node*) (tree-ssa-threadbackward.c:730) ==15400==by 0x180D575: thread_jumps::find_jump_threads_backwards(basic_block_def*, bool) (tree-ssa-threadbackward.c:780) ==15400==by 0x180D681: (anonymous namespace)::pass_thread_jumps::execute(function*) (tree-ssa-threadbackward.c:828) ==15400==by 0x12E7FEA: execute_one_pass(opt_pass*) (passes.c:2572) ==15400==by 0x12E8321: execute_pass_list_1(opt_pass*) (passes.c:2661) ==15400==by 0x12E8352: execute_pass_list_1(opt_pass*) (passes.c:2662) ==15400==by 0x12E83AA: execute_pass_list(function*, opt_pass*) (passes.c:2672) ==15400==by 0xCFBD80: cgraph_node::expand() (cgraphunit.c:1827) and ==14700== Memcheck, a memory error detector ==14700== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==14700== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info ==14700== Command: ./cc1 -quiet -fdiagnostics-plain-output -O3 -o ssa-dom-thread-1.s /home/rguenther/src/gcc3/gcc/testsuite/gcc.dg/torture/pr53703.c ==14700== ==14700== HEAP SUMMARY: ==14700== in use at exit: 1,955,873 bytes in 2,872 blocks ==14700== total heap usage: 28,797 allocs, 25,925 frees, 9,610,851 bytes allocated ==14700== ==14700== 16 bytes in 1 blocks are definitely lost in loss record 8 of 747 ==14700==at 0x4C2E94F: operator new(unsigned long) (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==14700==by 0x180CA7B: thread_jumps::convert_and_register_current_path(edge_def*) (tree-ssa-threadbackward.c:472) ==14700==by 0x180CD8E: thread_jumps::register_jump_thread_path_if_profitable(tree_node*, tree_node*, basic_block_def*) (tree-ssa-threadbackward.c:561) ==14700==by 0x180CEB6: thread_jumps::handle_phi(gphi*, tree_node*, basic_block_def*) (tree-ssa-threadbackward.c:600) ==14700==by 0x180D268: thread_jumps::fsm_find_control_statement_thread_paths(tree_node*) (tree-ssa-threadbackward.c:730) ==14700==by 0x180D575: thread_jumps::find_jump_threads_backwards(basic_block_def*, bool) (tree-ssa-threadbackward.c:780) ==14700==by 0x180D681: (anonymous namespace)::pass_thread_jumps::execute(function*) (tree-ssa-threadbackward.c:828) ==14700==by 0x12E7FEA: execute_one_pass(opt_pass*) (passes.c:2572) ==14700==by 0x12E8321: execute_pass_list_1(opt_pass*) (passes.c:2661) ==14700==by 0x12E8352: execute_pass_list_1(opt_pass*) (passes.c:2662) ==14700==by 0x12E83AA: execute_pass_list(function*, opt_pass*) (passes.c:2672) ==14700==by 0xCFBD80: cgraph_node::expand() (cgraphunit.c:1827) ==14700==
[Bug target/98998] [11 Regression] ICE in change_address_1, at emit-rtl.c:2275 since r11-3427
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98998 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P1 Target Milestone|--- |11.0
[Bug target/98998] [11 Regression] ICE in change_address_1, at emit-rtl.c:2275 since r11-3427
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98998 Jakub Jelinek changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-02-09 Status|UNCONFIRMED |NEW CC||jakub at gcc dot gnu.org Summary|ICE in change_address_1, at |[11 Regression] ICE in |emit-rtl.c:2275 |change_address_1, at ||emit-rtl.c:2275 since ||r11-3427 --- Comment #1 from Jakub Jelinek --- Started with r11-3427-ge94797250b403d66cb3624a594e41faf0dd76617
[Bug analyzer/99028] diagnostic path is too verbose
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99028 --- Comment #2 from David Malcolm --- At -fanalyzer-verbosity=1 and below, we only show those two events: In function ‘add_to_trie’: ../../src/gcc/testsuite/gcc.dg/analyzer/pr99028.c:175:28: warning: dereference of possibly-NULL ‘child’ [CWE-690] [-Wanalyzer-possible-null-dereference] 175 | child->len = root->len - i - 1; | ~~~^~~ ‘add_to_trie’: events 1-2 | | 172 | child = malloc(sizeof(*child)); | | ^~ | | | | | (1) this call could return NULL |.. | 175 | child->len = root->len - i - 1; | | ~~ | || | |(2) ‘child’ could be NULL: unchecked value from (1) | The default is -fanalyzer-verbosity=2. It seems some tweaking is needed.
[Bug preprocessor/98882] [11 Regression] ICE in in cpp_directive_only_process on empty translation unit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98882 --- Comment #7 from Jakub Jelinek --- Please file that as a different PR. And that is something for Nathan to look at, I don't know anything about that.
[Bug analyzer/99028] diagnostic path is too verbose
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99028 David Malcolm changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2021-02-09 --- Comment #1 from David Malcolm --- Thanks Antonio; I can successfully reproduce the issue with the attachment. I agree that the path is overly verbose. It should only show events (7) and (8).
[Bug middle-end/99007] [11 Regression] ICE in dominated_by_p, at dominance.c:1124
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99007 --- Comment #4 from Jakub Jelinek --- Created attachment 50152 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50152&action=edit gcc11-pr99007.patch Untested fix.
[Bug tree-optimization/99029] New: memory leak in IPA pure-const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99029 Bug ID: 99029 Summary: memory leak in IPA pure-const Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: rguenth at gcc dot gnu.org Target Milestone: --- ==14211== Memcheck, a memory error detector ==14211== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==14211== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info ==14211== Command: ./cc1 -quiet -fdiagnostics-plain-output -O3 -o ssa-dom-thread-2.s /home/rguenther/src/gcc3/gcc/testsuite/gcc.c-torture/compile/20040202-1.c ==14211== ==14211== ==14211== HEAP SUMMARY: ==14211== in use at exit: 1,866,764 bytes in 2,685 blocks ==14211== total heap usage: 15,548 allocs, 12,863 frees, 5,056,602 bytes allocated ==14211== ==14211== 40 bytes in 1 blocks are definitely lost in loss record 30 of 664 ==14211==at 0x4C2E2DF: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==14211==by 0x28ECCA8: xrealloc (xmalloc.c:177) ==14211==by 0xD00CF0: void va_heap::reserve(vec*&, unsigned int, bool) (vec.h:290) ==14211==by 0xD0054B: vec::reserve(unsigned int, bool) (vec.h:1778) ==14211==by 0xD00017: vec::safe_push(cgraph_node* const&) (vec.h:1887) ==14211==by 0x2635957: propagate_malloc() (ipa-pure-const.c:1945) ==14211==by 0x2635C47: (anonymous namespace)::pass_ipa_pure_const::execute(function*) (ipa-pure-const.c:2007) ==14211==by 0x12E7FEA: execute_one_pass(opt_pass*) (passes.c:2572) ==14211==by 0x12E8F82: execute_ipa_pass_list(opt_pass*) (passes.c:3001) ==14211==by 0xCFCB91: ipa_passes() (cgraphunit.c:2215) ==14211==by 0xCFCE24: symbol_table::compile() (cgraphunit.c:2292) ==14211==by 0xCFD391: symbol_table::finalize_compilation_unit() (cgraphunit.
[Bug c++/98944] [modules] Failed to read compiled module with a non-exported partition.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98944 Nathan Sidwell changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from Nathan Sidwell --- 92941cea2f0 2021-02-09 | c++: Fix indirect partitions [PR 98944]
[Bug c++/98944] [modules] Failed to read compiled module with a non-exported partition.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98944 --- Comment #2 from CVS Commits --- The master branch has been updated by Nathan Sidwell : https://gcc.gnu.org/g:92941cea2f05a8cf79fc71aa39fa948dcfb82d7a commit r11-7150-g92941cea2f05a8cf79fc71aa39fa948dcfb82d7a Author: Nathan Sidwell Date: Tue Feb 9 08:11:58 2021 -0800 c++: Fix indirect partitions [PR 98944] The most recent reimplementation of module loading initialization changed the behaviour of setting an import's location, and broke some partition handling. PR c++/98944 gcc/cp/ * module.cc (module_state::is_rooted): Rename to ... (module_state::has_location): ... here. Adjust callers. (module_state::read_partitions): Adjust validity check. Don't overwrite a known location. gcc/testsuite/ * g++.dg/modules/pr98944_a.C: New. * g++.dg/modules/pr98944_b.C: New. * g++.dg/modules/pr98944_c.C: New. * g++.dg/modules/pr98944_d.C: New.
[Bug tree-optimization/98950] jump threading memory leak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98950
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Last reconfirmed||2021-02-09
--- Comment #2 from Martin Liška ---
Reduced test-case:
$ cat jsonapi.i
typedef enum {
JSON_TOKEN_STRINGJSON_TOKEN_ARRAY_ENDJSON_TOKEN_NULL} JsonTokenType;
typedef enum {
JSON_SUCCESS} JsonParseErrorType;
typedef int json_scalar_action;
typedef struct {
json_scalar_action scalar;
} JsonSemAction;
static JsonParseErrorType parse_array_element();
void json_count_array_elements() {
JsonParseErrorType result;
while (1) {
result = parse_array_element();
if (result )
return ;
}
}
int lex_peek(void);
int json_lex(void);
JsonSemAction parse_scalar_sem;
JsonParseErrorType parse_scalar() {
JsonTokenType tok = lex_peek();
if (tok &&
tok != parse_scalar_sem.scalar )
return json_lex();
return JSON_SUCCESS;
}
JsonParseErrorType parse_array_element() {
JsonParseErrorType result;
result = parse_scalar();
if (result )
return result;
}
$ gcc jsonapi.i -O3 -c -wrapper valgrind,--leak-check=yes
...
==3008== 16 bytes in 1 blocks are definitely lost in loss record 10 of 863
==3008==at 0x4839DEF: operator new(unsigned long) (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==3008==by 0x1091A50:
thread_jumps::convert_and_register_current_path(edge_def*)
(tree-ssa-threadbackward.c:472)
==3008==by 0x1091D92: register_jump_thread_path_if_profitable
(tree-ssa-threadbackward.c:561)
==3008==by 0x1091D92:
thread_jumps::register_jump_thread_path_if_profitable(tree_node*, tree_node*,
basic_block_def*) (tree-ssa-threadbackward.c:550)
==3008==by 0x1092A1E: thread_jumps::handle_phi(gphi*, tree_node*,
basic_block_def*) (tree-ssa-threadbackward.c:600)
==3008==by 0x1092915:
thread_jumps::fsm_find_control_statement_thread_paths(tree_node*)
(tree-ssa-threadbackward.c:730)
==3008==by 0x10931CE: (anonymous
namespace)::pass_thread_jumps::execute(function*)
(tree-ssa-threadbackward.c:828)
==3008==by 0xD99A37: execute_one_pass(opt_pass*) (passes.c:2567)
==3008==by 0xD9A412: execute_pass_list_1(opt_pass*) (passes.c:2656)
==3008==by 0xD9A424: execute_pass_list_1(opt_pass*) (passes.c:2657)
==3008==by 0xD9A455: execute_pass_list(function*, opt_pass*)
(passes.c:2667)
==3008==by 0xA0A1F4: cgraph_node::expand() (cgraphunit.c:1827)
==3008==by 0xA0B85E: expand_all_functions (cgraphunit.c:1995)
==3008==by 0xA0B85E: compile (cgraphunit.c:2359)
==3008==by 0xA0B85E: symbol_table::compile() (cgraphunit.c:2270)
[Bug analyzer/99028] New: diagnostic path is too verbose
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99028
Bug ID: 99028
Summary: diagnostic path is too verbose
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: antonio.chirizzi at gmail dot com
Target Milestone: ---
Created attachment 50151
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50151&action=edit
Tar.gz file which contains the path.c file (from the git source code repo)
When analysing a path for a possible null dereference, in the straight forward
case, there should be no need to show the verbose description of how it can
lead to a null dereference.
Take this case where a call to malloc is followed by the usage of the returned
pointer:
In function ‘add_to_trie’:
path.c:175:28: warning: dereference of possibly-NULL ‘child’ [CWE-690]
[-Wanalyzer-possible-null-dereference]
175 | child->len = root->len - i - 1;
| ~~~^~~
‘add_to_trie’: events 1-8
|
| 157 | if (!*key) {
| |^
| ||
| |(1) following ‘false’ branch...
|..
| 164 | for (i = 0; i < root->len; i++) {
| | ~ ~
| || |
| || (3) following ‘true’ branch...
| |(2) ...to here
| 165 | if (root->contents[i] == key[i])
| |~~~
| |||
| ||(4) ...to here
| |(5) following ‘false’ branch...
|..
| 172 | child = malloc(sizeof(*child));
| | ~~
| | |
| | (6) ...to here
| | (7) this call could return NULL
|..
| 175 | child->len = root->len - i - 1;
| | ~~
| ||
| |(8) ‘child’ could be NULL: unchecked
value from (7)
|
I am attaching the source code which demonstrates this.
Use only "gcc -fanalyzer -c path.c"
[Bug fortran/99027] New: Incorrect ubound result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99027 Bug ID: 99027 Summary: Incorrect ubound result Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: andrew.burgess at embecosm dot com Target Milestone: --- I believe I have run into a case where ubound is giving the wrong result. Given: program test integer, dimension (1:3,1:6) :: array print *, "ubound = ", ubound (array (1, 1:4)) end program test I see the output: ubound =1 When I would have expected: ubound =4 Due to array (1, 1:4) being a 4 element 1-dimensional array. I am seeing this behaviour in my default Fedora compiler: GNU Fortran (GCC) 9.3.1 20200408 (Red Hat 9.3.1-2) But I also build current HEAD from git (26a3f288f18) and am still seeing this issue: GNU Fortran (GCC) 11.0.0 20210209 (experimental) Interestingly, if I change the test program to: program test integer, dimension (1:3,1:6) :: array print *, "ubound = ", ubound (array (1:2, 1:4)) end program test Then I do now see what I would expect for this case: ubound =2 4
[Bug middle-end/99007] [11 Regression] ICE in dominated_by_p, at dominance.c:1124
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99007
--- Comment #3 from Jakub Jelinek ---
And allocate clause isn't needed either, this ICEs since
r9-3941-g28567c40e2c7c88e424283e8a1a6ff8cb7ba440c
when host teams has been introduced:
int
bar (int n)
{
int s[n];
int i, j;
for (i = 0; i < n; i++)
s[i] = 0;
#pragma omp teams distribute parallel for reduction(+:s) private (j)
for (i = 0; i < 8; i++)
for (j = 0; j < n; j++)
s[j] += i;
return s[0] + s[n - 1];
}
and
int
bar (int n)
{
int s[n];
int i, j;
for (i = 0; i < n; i++)
s[i] = 0;
#pragma omp parallel reduction(+:s) num_threads(2)
#pragma omp parallel for reduction(+:s) private (j)
for (i = 0; i < 8; i++)
for (j = 0; j < n; j++)
s[j] += i;
return s[0] + s[n - 1];
}
ICEs since r7-536-g381cdae49785fc4b1941a6b37bad3e8c6f3f428d
[Bug tree-optimization/99026] New: memleak in switch-conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99026 Bug ID: 99026 Summary: memleak in switch-conversion Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: rguenth at gcc dot gnu.org Target Milestone: --- ==12554== Memcheck, a memory error detector ==12554== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==12554== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info ==12554== Command: ./cc1 -quiet -fdiagnostics-plain-output -O3 -o ssa-dom-thread-1.s /home/rguenther/src/gcc3/gcc/testsuite/gcc.dg/torture/pr45830.c ==12554== ==12554== ==12554== HEAP SUMMARY: ==12554== in use at exit: 1,958,822 bytes in 2,888 blocks ==12554== total heap usage: 49,711 allocs, 46,823 frees, 11,522,312 bytes allocated ==12554== ==12554== 752 (40 direct, 712 indirect) bytes in 1 blocks are definitely lost in loss record 675 of 759 ==12554==at 0x4C2E94F: operator new(unsigned long) (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==12554==by 0x1630BB2: tree_switch_conversion::jump_table_cluster::find_jump_tables(vec&) (tree-switch-conversion.c:1224) ==12554==by 0x24FF349: if_chain::is_beneficial() (gimple-if-to-switch.cc:241) ==12554==by 0x250052F: (anonymous namespace)::pass_if_to_switch::execute(function*) (gimple-if-to-switch.cc:545) ==12554==by 0x12E7FEA: execute_one_pass(opt_pass*) (passes.c:2572) ==12554==by 0x12E8321: execute_pass_list_1(opt_pass*) (passes.c:2661) ==12554==by 0x12E8352: execute_pass_list_1(opt_pass*) (passes.c:2662) ==12554==by 0x12E83AA: execute_pass_list(function*, opt_pass*) (passes.c:2672) ==12554==by 0x12E62DF: do_per_function_toporder(void (*)(function*, void*), void*) (passes.c:1774) ==12554==by 0x12E8FDA: execute_ipa_pass_list(opt_pass*) (passes.c:3006) ==12554==by 0xCFC9EE: ipa_passes() (cgraphunit.c:2157) ==12554==by 0xCFCE24: symbol_table::compile() (cgraphunit.c:2292) ==12554== ==12554==
[Bug c++/99007] [11 Regression] ICE in dominated_by_p, at dominance.c:1124
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99007
--- Comment #2 from Jakub Jelinek ---
Simplified testcase, no need for templates, and no need for UB in the code and
no need for C++:
void
bar (int n)
{
long s[n];
#pragma omp teams distribute parallel for reduction(+:s) allocate(s)
for (int i = 0; i < 8; i++)
;
}
[Bug libstdc++/98985] libstdc++: filesystem::rename not overwriting files on Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98985 Jonathan Wakely changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2021-02-09 Ever confirmed|0 |1
[Bug tree-optimization/98950] jump threading memory leak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98950 --- Comment #1 from Martin Liška --- I'm reducing 150kB big .i file, one compiler execution in valgrind takes ~25s.
[Bug libstdc++/99021] coroutine_handle<_Promise>::from_address() should be noexcept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99021 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |10.3 Severity|normal |enhancement Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #5 from Jonathan Wakely --- (In reply to Mathias Stearn from comment #3) > Any chance of a backport of this and Yes I just had to wait for the tests to finish. > https://github.com/gcc-mirror/gcc/commit/ > f1b6e46c417224887c2f21baa6d4c538a25fe9fb#diff- > ed08df78eba81189642b4e8d670a0adb4b377db6846aecb090b4dce52a9251fa to the v10 That was already done: 517fb88b8a96795cce3f88862148880b1c46b198 Fixed, thanks.
[Bug preprocessor/96391] [10/11 Regression] internal compiler error: in linemap_compare_locations, at libcpp/line-map.c:1359
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96391 --- Comment #11 from David Malcolm --- FWIW I had another go at reproduing this, but after various failures due to running out of disk space, I was able to rebuild the SRPM from comment #0 without seeing the crash, via: mock --rebuild mingw-wine-gecko-2.47.1-2.fc32.src.rpm -N -r fedora-32-i386 (which the root.log tells me used gcc-c++-10.2.1-9.fc32.i686.rpm). Michael: is that the mock configuration that's failing for you, or are you using a different one?
[Bug target/99025] [11 Regression] ICE Segmentation fault since r11-6351-g12ae2bc70846a2be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99025 Martin Liška changed: What|Removed |Added Ever confirmed|0 |1 Priority|P3 |P1 Known to fail||11.0 Status|UNCONFIRMED |NEW Known to work||10.2.0 Target Milestone|--- |11.0 Last reconfirmed||2021-02-09
[Bug target/99025] New: [11 Regression] ICE Segmentation fault since r11-6351-g12ae2bc70846a2be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99025
Bug ID: 99025
Summary: [11 Regression] ICE Segmentation fault since
r11-6351-g12ae2bc70846a2be
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: wwwhhhyyy333 at gmail dot com
Target Milestone: ---
Host: x86_64-linux-gnu
The following ICEs, reduced from postgresql package:
$ cat pg_proc.i
long ProcedureCreate_values[16];
int ProcedureCreate_X;
union {
float value;
int retval;
} ProcedureCreate_myunion;
void
ProcedureCreate() {
ProcedureCreate_myunion.value = ProcedureCreate_X;
ProcedureCreate_values[6 - 1] = ProcedureCreate_myunion.retval;
float X;
union {
float value;
int retval;
} myunion;
myunion.value = X;
ProcedureCreate_values[7 - 1] = myunion.retval;
}
$ gcc pg_proc.i -c -O3 -march=haswell
during RTL pass: expand
pg_proc.i: In function ‘ProcedureCreate’:
pg_proc.i:19:1: internal compiler error: Segmentation fault
19 | }
| ^
0xe7b97a crash_signal
/home/marxin/Programming/gcc/gcc/toplev.c:327
0xcb5b3b mark_jump_label_1
/home/marxin/Programming/gcc/gcc/jump.c:1097
0xcb5bd3 mark_jump_label_1
/home/marxin/Programming/gcc/gcc/jump.c:1221
0xcb5bd3 mark_jump_label_1
/home/marxin/Programming/gcc/gcc/jump.c:1221
0xcb5bd3 mark_jump_label_1
/home/marxin/Programming/gcc/gcc/jump.c:1221
0xcb605d mark_all_labels
/home/marxin/Programming/gcc/gcc/jump.c:332
0xcb605d rebuild_jump_labels_1
/home/marxin/Programming/gcc/gcc/jump.c:74
0x9d36b4 execute
/home/marxin/Programming/gcc/gcc/cfgexpand.c:6779
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
