[Bug tree-optimization/100102] [8/9/10/11 Regression] ICE in tsubst, at cp/pt.c:15310
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100102 --- Comment #5 from Richard Biener --- (In reply to Erik Schnetter from comment #0) > I am using GCC 10.3.0 on x86_64 GNU/Linux. GCC was built via Spack, and is > called from nvcc. > > I encounter the following ICE: ... > GCC 10.2.0 compiles the code without problems. I tried plain GCC 10.2.0 with the attached preprocessed source and it ICEs the same way. I suppose there might be some header differences? > To reproduce, compile the attached preprocessed source code with the options > > g++ -std=c++14 -c -x c++ -fPIC -fopenmp -Werror=return-type -pthread -O2 > -m64 -g -gdwarf-2 "AMReX_BlockMutex.cpp.ii" -o "AMReX_BlockMutex.cpp.o" It already crashes with just g++ -std=c++14 for me (since the crash is inside the C++ frontend).
[Bug target/100093] different behavior between -mtune=cpu_type and target_attribute (“arch=cputype”)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100093 --- Comment #2 from Hongtao.liu --- Created attachment 50611 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50611&action=edit tested patch waiting for GCC12. [i386] MASK_AVX256_SPLIT_UNALIGNED_STORE/LOAD should be cleared in opts->x_target_flags when X86_TUNE_AVX256_UNALIGNED_LOAD/STORE_OPTIMAL is enabled by target attribute. gcc/ChangeLog: PR target/10093 * config/i386/i386-options.c (ix86_option_override_internal): Clear MASK_AVX256_SPLIT_UNALIGNED_LOAD/STORE in x_target_flags when X86_TUNE_AVX256_UNALIGNED_LOAD/STORE_OPTIMAL is enabled by target attribute. gcc/testsuite/ChangeLog: PR target/10093 * gcc.target/i386/pr10093.c: New test. 2 files changed, 19 insertions(+) gcc/config/i386/i386-options.c | 7 +++ gcc/testsuite/gcc.target/i386/pr10093.c | 12 modified gcc/config/i386/i386-options.c @@ -2853,9 +2853,16 @@ ix86_option_override_internal (bool main_args_p, if (!ix86_tune_features[X86_TUNE_AVX256_UNALIGNED_LOAD_OPTIMAL] && !(opts_set->x_target_flags & MASK_AVX256_SPLIT_UNALIGNED_LOAD)) opts->x_target_flags |= MASK_AVX256_SPLIT_UNALIGNED_LOAD; + else if (!main_args_p + && ix86_tune_features[X86_TUNE_AVX256_UNALIGNED_LOAD_OPTIMAL]) +opts->x_target_flags &= ~MASK_AVX256_SPLIT_UNALIGNED_LOAD; + if (!ix86_tune_features[X86_TUNE_AVX256_UNALIGNED_STORE_OPTIMAL] && !(opts_set->x_target_flags & MASK_AVX256_SPLIT_UNALIGNED_STORE)) opts->x_target_flags |= MASK_AVX256_SPLIT_UNALIGNED_STORE; + else if (!main_args_p + && ix86_tune_features[X86_TUNE_AVX256_UNALIGNED_STORE_OPTIMAL]) +opts->x_target_flags &= ~MASK_AVX256_SPLIT_UNALIGNED_STORE; /* Enable 128-bit AVX instruction generation
[Bug c++/100111] New: `-fno-elide-constructors` causes ICE in GCC 10.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100111
Bug ID: 100111
Summary: `-fno-elide-constructors` causes ICE in GCC 10.3
Product: gcc
Version: 10.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lh_mouse at 126 dot com
Target Milestone: ---
Host: x86_64-linux-gnu
Target: x86_64-linux-gnu
Created attachment 50610
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50610&action=edit
minimum testcase
```
lh_mouse@lhmouse-ideapad ~/Desktop $ cat ice.cc
// g++-10 -fno-elide-constructors ice.cc
struct b {};
struct j : b {
int e;
constexpr j(b k) : b(k), e() {}
};
struct g {
j h;
constexpr g() : h({}) {}
} a;
lh_mouse@lhmouse-ideapad ~/Desktop $ g++-10 -fno-elide-constructors ice.cc
ice.cc:11:3: in ‘constexpr’ expansion of ‘a.g::g()’
ice.cc:10:23: in ‘constexpr’ expansion of ‘((g*)this)->g::h.j::j((b(), b()))’
ice.cc:11:3: internal compiler error: in cxx_eval_store_expression, at
cp/constexpr.c:4939
11 | } a;
| ^
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
```
```
lh_mouse@lhmouse-ideapad ~/Desktop $ g++-10 -v
Using built-in specs.
COLLECT_GCC=g++-10
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/10/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa:hsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
10.3.0-1ubuntu1~20.04~2' --with-bugurl=file:///usr/share/doc/gcc-10/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-10
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib
--enable-libphobos-checking=release --with-target-system-zlib=auto
--enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib
--with-tune=generic
--enable-offload-targets=nvptx-none=/build/gcc-10-S8Osas/gcc-10-10.3.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-10-S8Osas/gcc-10-10.3.0/debian/tmp-gcn/usr,hsa
--without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
--with-build-config=bootstrap-lto-lean --enable-link-mutex
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.3.0 (Ubuntu 10.3.0-1ubuntu1~20.04~2)
```
[Bug fortran/100110] New: Parameterized Derived Types, problems with global variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100110 Bug ID: 100110 Summary: Parameterized Derived Types, problems with global variable Product: gcc Version: 10.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: xiao@compiler-dev.com Target Milestone: --- the test case is, program p implicit none type t(n) integer, len :: n integer :: arr(n, n) end type type(t(2)) :: obj print *, obj%n print *, shape(obj%arr) call test() contains subroutine test() print *, obj%n print *, shape(obj%arr) end subroutine end program expected result is 2 2 2 2 2 2 but is 0 0 0 0 0 0
[Bug c++/100079] [9/10/11 Regression] Non-type template parameter, itself a nested template, rejected with internal error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100079
--- Comment #4 from CVS Commits ---
The master branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:89c863488bc8c7315596bcb753173aa2fd8be727
commit r11-8207-g89c863488bc8c7315596bcb753173aa2fd8be727
Author: Jason Merrill
Date: Wed Apr 14 17:27:19 2021 -0400
c++: C++20 class NTTP trailing zero-init [PR100079]
The new testcase was breaking because constexpr evaluation was simplifying
Bar{Baz<42>{}} to Bar{empty}, but then we weren't treating them as
equivalent. Poking at this revealed that the code for eliding trailing
zero-initialization in class non-type template argument mangling was pretty
broken, including the test, mangle71.
I dealt with the FIXME to support RANGE_EXPR, and fixed the confusion
between a list-initialized temporary mangled as written (i.e. in the
signature of a function template) and a template parameter object mangled
as
the value representation of the object. I'm distinguishing between these
using COMPOUND_LITERAL_P. A later patch will adjust the use of
COMPOUND_LITERAL_P to be more useful for this distinction, but it works now
for distinguishing these cases in mangling.
gcc/cp/ChangeLog:
PR c++/100079
* cp-tree.h (first_field): Declare.
* mangle.c (range_expr_nelts): New.
(write_expression): Improve class NTTP mangling.
* pt.c (get_template_parm_object): Clear TREE_HAS_CONSTRUCTOR.
* tree.c (zero_init_expr_p): Improve class NTTP handling.
* decl.c: Adjust comment.
gcc/testsuite/ChangeLog:
PR c++/100079
* g++.dg/abi/mangle71.C: Fix expected mangling.
* g++.dg/abi/mangle77.C: New test.
* g++.dg/cpp2a/nontype-class-union1.C: Likewise.
* g++.dg/cpp2a/nontype-class-equiv1.C: Removed.
* g++.dg/cpp2a/nontype-class44.C: New test.
[Bug target/100056] [9/10 Regression] orr + lsl vs. [us]bfiz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100056 --- Comment #11 from Luc Van Oostenryck --- Works nicely now. Thank you.
[Bug target/100028] [9/10 Regression] arm64 failure to generate bfxil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100028 --- Comment #8 from Luc Van Oostenryck --- Woks nicely now. Thanks
[Bug c++/100109] New: ICE: unexpected expression 'E' of kind template_parm_index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100109
Bug ID: 100109
Summary: ICE: unexpected expression 'E' of kind
template_parm_index
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
https://godbolt.org/z/Go1W7YrYs
template
void f() {
[] { enum e { e = E }; };
}
template void f<>();
:3:13: internal compiler error: unexpected expression 'E' of kind
template_parm_index
3 | [] { enum e { e = E }; };
| ^
0x1d02849 internal_error(char const*, ...)
???:0
0x7a74bd build_enumerator(tree_node*, tree_node*, tree_node*, tree_node*,
unsigned int)
???:0
0x92c3c8 lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
???:0
0x9182fd tsubst(tree_node*, tree_node*, int, tree_node*)
???:0
0x9183a7 tsubst(tree_node*, tree_node*, int, tree_node*)
???:0
0x94b882 tsubst_lambda_expr(tree_node*, tree_node*, int, tree_node*)
???:0
0x91e1df instantiate_decl(tree_node*, bool, bool)
???:0
0x9600bb instantiate_pending_templates(int)
???:0
0x7cd579 c_parse_final_cleanups()
???:0
Please submit a full bug report,
with preprocessed source if appropriate.
[Bug target/100108] New: [10 Regression] powerpc: recognize 32-bit CPU as POWER9 with -misel option
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100108
Bug ID: 100108
Summary: [10 Regression] powerpc: recognize 32-bit CPU as
POWER9 with -misel option
Product: gcc
Version: 10.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: rin at NetBSD dot org
Target Milestone: ---
Created attachment 50609
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50609&action=edit
Fix for this regression
GCC10 wrongly recognizes CPU as POWER9 if -misel is specified, even when
it is configured for 32-bit processors:
% cat test.c
int main(void)
{
return 0;
}
% gcc10 -misel -S test.c -o test10.S
% gcc9 -misel -S test.c -o test9.S
% diff -u test9.S test10.S
--- test.9 2021-04-16 10:53:47.116917225 +0900
+++ test.10 2021-04-16 10:53:38.075282430 +0900
@@ -1,5 +1,5 @@
.file "test.c"
- .machine ppc
+ .machine power9
.section".text"
.align 2
.globl main
...(snip)...
This is because rs6000_machine_from_flags() assumes ISEL instructions
are supported only by POWER9 and successors. However, ISEL is also
implemented for 32-bit processors like e500.
Please apply the attached patch to fix the problem.
% gcc10 -v
Using built-in specs.
COLLECT_GCC=/build/tools.broken/bin/powerpc--netbsd-gcc
COLLECT_LTO_WRAPPER=/build/tools.broken/libexec/gcc/powerpc--netbsd/10.3.0/lto-wrapper
Target: powerpc--netbsd
Configured with: /usr/src/tools/gcc/../../external/gpl3/gcc/dist/configure
--target=powerpc--netbsd --enable-long-long --enable-threads
--with-bugurl=http://www.NetBSD.org/support/send-pr.html
--with-pkgversion='NetBSD nb1 20210411' --with-system-zlib --without-isl
--enable-__cxa_atexit --enable-libstdcxx-time=rt --enable-libstdcxx-threads
--with-diagnostics-color=auto-if-env --with-default-libstdcxx-abi=new
--with-sysroot=/build/dest/evbppc-powerpc --with-mpc=/build/tools.broken
--with-mpfr=/build/tools.broken --with-gmp=/build/tools.broken --disable-nls
--disable-multilib --program-transform-name='s,^,powerpc--netbsd-,'
--enable-languages='c c++ objc' --prefix=/build/tools.broken
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.3.0 (NetBSD nb1 20210411)
% gcc9 -v
Using built-in specs.
COLLECT_GCC=/build/tools.9/bin/powerpc--netbsd-gcc
COLLECT_LTO_WRAPPER=/build/tools.9/libexec/gcc/powerpc--netbsd/9.3.0/lto-wrapper
Target: powerpc--netbsd
Configured with: /usr/src/tools/gcc/../../external/gpl3/gcc.old/dist/configure
--target=powerpc--netbsd --enable-long-long --enable-threads
--with-bugurl=http://www.NetBSD.org/support/send-pr.html
--with-pkgversion='NetBSD nb1 20200907' --with-system-zlib --without-isl
--enable-__cxa_atexit --enable-libstdcxx-time=rt --enable-libstdcxx-threads
--with-diagnostics-color=auto-if-env --with-default-libstdcxx-abi=new
--with-sysroot=/build/dest/evbppc-powerpc --with-mpc=/build/tools.9
--with-mpfr=/build/tools.9 --with-gmp=/build/tools.9 --disable-nls
--disable-multilib --program-transform-name='s,^,powerpc--netbsd-,'
--enable-languages='c c++ objc' --prefix=/build/tools.9
Thread model: posix
gcc version 9.3.0 (NetBSD nb1 20200907)
[Bug middle-end/100104] std::transform is 1.5 times faster than std::copy with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100104 --- Comment #4 from 康桓瑋 --- And Build "copy" with -O2 on ARM64 is identical with -O3 (https://godbolt.org/z/5hjKGbrTd): .LC0: .string "vector::_M_realloc_insert" transform(std::vector > const&): stp x29, x30, [sp, -64]! mov x29, sp stp x19, x20, [sp, 16] mov x19, x8 ldp x20, x0, [x0] stp xzr, xzr, [x8] str xzr, [x8, 16] sub x0, x0, x20 cmp x0, 0 ble .L19 mov x1, 0 str x21, [sp, 32] asr x21, x0, 3 mov x0, 0 b .L23 .L35: str w2, [x0], 4 add x20, x20, 8 subsx21, x21, #1 str x0, [x19, 8] beq .L34 .L36: ldp x0, x1, [x19, 8] .L23: ldr d0, [x20] fcvtzs w2, d0 str w2, [sp, 60] cmp x1, x0 bne .L35 add x2, sp, 60 mov x0, x19 bl void std::vector >::_M_realloc_insert(__gnu_cxx::__normal_iterator > >, int&&) add x20, x20, 8 subsx21, x21, #1 bne .L36 .L34: ldr x21, [sp, 32] .L19: mov x0, x19 ldp x19, x20, [sp, 16] ldp x29, x30, [sp], 64 ret ldr x2, [x19] ldr x1, [x19, 16] mov x19, x0 sub x1, x1, x2 cbz x2, .L25 mov x0, x2 bl operator delete(void*, unsigned long) .L25: mov x0, x19 bl _Unwind_Resume DW.ref.__gxx_personality_v0: .xword __gxx_personality_v0 === However, "transform" has been further optimized under -O3 (https://godbolt.org/z/5hjKGbrTd): .LC0: .string "vector::_M_realloc_insert" transform(std::vector > const&): stp x29, x30, [sp, -96]! mov x29, sp stp x19, x20, [sp, 16] stp x21, x22, [sp, 32] mov x21, x8 ldp x20, x22, [x0] stp xzr, xzr, [x8] str xzr, [x8, 16] cmp x22, x20 beq .L1 mov x19, 0 stp x23, x24, [sp, 48] stp x25, x26, [sp, 64] mov x25, 2305843009213693951 stp x27, x28, [sp, 80] mov x28, 0 b .L13 .L32: str w27, [x19], 4 add x20, x20, 8 str x19, [x21, 8] cmp x22, x20 beq .L31 .L13: ldr d0, [x20] fcvtzs w27, d0 cmp x19, x28 bne .L32 ldr x24, [x21] sub x23, x19, x24 asr x1, x23, 2 cmp x1, x25 beq .L33 cmp x1, 0 csinc x0, x1, xzr, ne addsx0, x0, x1 bcs .L7 cbnzx0, .L34 mov x28, 0 mov x26, 0 .L9: add x19, x23, 4 str w27, [x26, x23] add x19, x26, x19 cmp x23, 0 bgt .L35 cbnzx24, .L36 .L12: add x20, x20, 8 stp x26, x19, [x21] str x28, [x21, 16] cmp x22, x20 bne .L13 .L31: ldp x23, x24, [sp, 48] ldp x25, x26, [sp, 64] ldp x27, x28, [sp, 80] .L1: mov x0, x21 ldp x19, x20, [sp, 16] ldp x21, x22, [sp, 32] ldp x29, x30, [sp], 96 ret .L35: mov x1, x24 mov x2, x23 mov x0, x26 bl memmove ldr x1, [x21, 16] sub x1, x1, x24 .L11: mov x0, x24 bl operator delete(void*, unsigned long) b .L12 .L36: ldr x1, [x21, 16] sub x1, x1, x24 b .L11 .L34: cmp x0, x25 cselx0, x0, x25, ls lsl x28, x0, 2 .L8: mov x0, x28 bl operator new(unsigned long) mov x26, x0 add x28, x0, x28 b .L9 .L7: mov x28, 9223372036854775804 b .L8 .L33: adrpx0, .LC0 add x0, x0, :lo12:.LC0 bl std::__throw_length_error(char const*) ldr x2, [x21] mov x19, x0 ldr x1, [x21, 16] sub x1, x1, x2 cbz x2, .L16 mov x0, x2 bl operator delete(void*, unsigned long) .L16: mov x0, x19 bl _Unwind_Resume DW.ref.__gxx_personality_v0: .xword __gxx_personality_v0
[Bug target/100107] New: [10 Regression] powerpc: redundant .machine directive clobbers CPU flags to assembler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100107
Bug ID: 100107
Summary: [10 Regression] powerpc: redundant .machine directive
clobbers CPU flags to assembler
Product: gcc
Version: 10.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: rin at NetBSD dot org
Target Milestone: ---
Created attachment 50608
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50608&action=edit
Fix for this regression
GCC10 miscompiles inline assembler codes for 403/405 processors:
% cat mfpid.c
unsigned mfpid(void)
{
unsigned pid;
__asm volatile("mfpid %0" : "=r"(pid));
return pid;
}
% gcc10 -m403 -c mfpid.c -o mfpid10.o && objdump -D403 mfpid10.o > mfpid10.dump
% gcc9 -m403 -c mfpid.c -o mfpid9.o && objdump -D403 mfpid9.o > mfpid9.dump
% diff -u mfpid9.dump mfpid10.dump
...(snip)...
- c: 7d 31 ea a6 mfpid r9
+ c: 7d 30 0a a6 mfspr r9,48
...(snip)...
This is because redundant .machine directive, introduced by commit
2d94f7dea9c73ef3c116a0ddc722724578a860fe:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=2d94f7dea9c73ef3c116a0ddc722724578a860fe
clobbers CPU flags passed to assembler (-m403 in this case). Actually, diff
b/w .S files generated by GCC9 and 10 reads:
% diff -u mfpid9.S mfpid10.S
--- mfpid9.S2021-04-16 10:21:47.688171347 +0900
+++ mfpid10.S 2021-04-16 10:21:37.262150628 +0900
@@ -1,4 +1,5 @@
.file "mfpid.c"
+ .machine ppc
.section".text"
.align 2
.globl mfpid
...(snip)...
By reverting that commit with attached patch, this file can be successfully
compiled again with GCC10.
% gcc10 -v
Using built-in specs.
COLLECT_GCC=/build/tools.broken/bin/powerpc--netbsd-gcc
COLLECT_LTO_WRAPPER=/build/tools.broken/libexec/gcc/powerpc--netbsd/10.3.0/lto-wrapper
Target: powerpc--netbsd
Configured with: /usr/src/tools/gcc/../../external/gpl3/gcc/dist/configure
--target=powerpc--netbsd --enable-long-long --enable-threads
--with-bugurl=http://www.NetBSD.org/support/send-pr.html
--with-pkgversion='NetBSD nb1 20210411' --with-system-zlib --without-isl
--enable-__cxa_atexit --enable-libstdcxx-time=rt --enable-libstdcxx-threads
--with-diagnostics-color=auto-if-env --with-default-libstdcxx-abi=new
--with-sysroot=/build/dest/evbppc-powerpc --with-mpc=/build/tools.broken
--with-mpfr=/build/tools.broken --with-gmp=/build/tools.broken --disable-nls
--disable-multilib --program-transform-name='s,^,powerpc--netbsd-,'
--enable-languages='c c++ objc' --prefix=/build/tools.broken
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.3.0 (NetBSD nb1 20210411)
% gcc9 -v
Using built-in specs.
COLLECT_GCC=/build/tools.9/bin/powerpc--netbsd-gcc
COLLECT_LTO_WRAPPER=/build/tools.9/libexec/gcc/powerpc--netbsd/9.3.0/lto-wrapper
Target: powerpc--netbsd
Configured with: /usr/src/tools/gcc/../../external/gpl3/gcc.old/dist/configure
--target=powerpc--netbsd --enable-long-long --enable-threads
--with-bugurl=http://www.NetBSD.org/support/send-pr.html
--with-pkgversion='NetBSD nb1 20200907' --with-system-zlib --without-isl
--enable-__cxa_atexit --enable-libstdcxx-time=rt --enable-libstdcxx-threads
--with-diagnostics-color=auto-if-env --with-default-libstdcxx-abi=new
--with-sysroot=/build/dest/evbppc-powerpc --with-mpc=/build/tools.9
--with-mpfr=/build/tools.9 --with-gmp=/build/tools.9 --disable-nls
--disable-multilib --program-transform-name='s,^,powerpc--netbsd-,'
--enable-languages='c c++ objc' --prefix=/build/tools.9
Thread model: posix
gcc version 9.3.0 (NetBSD nb1 20200907)
[Bug middle-end/100104] std::transform is 1.5 times faster than std::copy with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100104 --- Comment #3 from 康桓瑋 --- Build "copy" with -O2 on x86-64 (https://godbolt.org/z/Gja6xrq9G): .LC0: .string "vector::_M_realloc_insert" copy(std::vector > const&): pushr15 pxorxmm0, xmm0 pushr14 pushr13 pushr12 mov r12, rdi pushrbp pushrbx sub rsp, 40 mov r13, QWORD PTR [rsi+8] mov rbx, QWORD PTR [rsi] movups XMMWORD PTR [rdi], xmm0 mov QWORD PTR [rdi+16], 0 cmp rbx, r13 je .L1 xor r8d, r8d xor ecx, ecx jmp .L13 .L31: mov DWORD PTR [rcx], ebp add rbx, 8 add rcx, 4 mov QWORD PTR [r12+8], rcx cmp r13, rbx je .L1 .L13: cvttsd2si ebp, QWORD PTR [rbx] cmp rcx, r8 jne .L31 movabs rax, 2305843009213693951 mov r15, QWORD PTR [r12] sub rcx, r15 mov rdx, rcx mov r14, rcx sar rdx, 2 cmp rdx, rax je .L32 testrdx, rdx mov eax, 1 cmovne rax, rdx add rax, rdx jc .L7 testrax, rax jne .L33 xor r8d, r8d xor edi, edi .L9: lea rcx, [rdi+4+r14] movqxmm0, rdi mov DWORD PTR [rdi+r14], ebp movqxmm1, rcx punpcklqdq xmm0, xmm1 testr14, r14 jg .L34 testr15, r15 jne .L35 .L12: add rbx, 8 mov QWORD PTR [r12+16], r8 movups XMMWORD PTR [r12], xmm0 cmp r13, rbx jne .L13 .L1: add rsp, 40 mov rax, r12 pop rbx pop rbp pop r12 pop r13 pop r14 pop r15 ret .L34: mov rsi, r15 mov rdx, r14 mov QWORD PTR [rsp+8], r8 mov QWORD PTR [rsp], rcx movaps XMMWORD PTR [rsp+16], xmm0 callmemmove mov rsi, QWORD PTR [r12+16] mov rcx, QWORD PTR [rsp] mov r8, QWORD PTR [rsp+8] movdqa xmm0, XMMWORD PTR [rsp+16] sub rsi, r15 .L11: mov rdi, r15 mov QWORD PTR [rsp+8], r8 mov QWORD PTR [rsp], rcx movaps XMMWORD PTR [rsp+16], xmm0 calloperator delete(void*, unsigned long) movdqa xmm0, XMMWORD PTR [rsp+16] mov r8, QWORD PTR [rsp+8] mov rcx, QWORD PTR [rsp] jmp .L12 .L35: mov rsi, QWORD PTR [r12+16] sub rsi, r15 jmp .L11 .L33: movabs rdx, 2305843009213693951 cmp rax, rdx cmova rax, rdx sal rax, 2 mov QWORD PTR [rsp], rax mov rdi, rax .L8: calloperator new(unsigned long) mov r8, QWORD PTR [rsp] mov rdi, rax add r8, rax jmp .L9 .L7: movabs rax, 9223372036854775804 mov QWORD PTR [rsp], rax mov rdi, rax jmp .L8 .L32: mov edi, OFFSET FLAT:.LC0 callstd::__throw_length_error(char const*) mov rbp, rax jmp .L15 copy(std::vector > const&) [clone .cold]: === with -O3: .LC0: .string "vector::_M_realloc_insert" copy(std::vector > const&): pushr15 pxorxmm0, xmm0 pushr14 pushr13 pushr12 mov r12, rdi pushrbp pushrbx sub rsp, 40 mov r13, QWORD PTR [rsi+8] mov rbx, QWORD PTR [rsi] movups XMMWORD PTR [rdi], xmm0 mov QWORD PTR [rdi+16], 0 cmp rbx, r13 je .L1 xor r8d, r8d xor ecx, ecx jmp .L13 .L31: mov DWORD PTR [rcx], ebp add rbx, 8 add rcx, 4 mov QWORD PTR [r12+8], rcx cmp r13, rbx je .L1 .L13: cvttsd2si ebp, QWORD PTR [rbx] cmp rcx, r8 jne .L31 movabs rax, 2305843009213693951 mov r15, QWORD PTR [r12] sub rcx, r15 mov rdx, rcx mov r14, rcx sar rdx, 2 cmp rdx, rax je .L32 testrdx, rdx mov eax, 1 cmovne rax, rdx add rax, rdx jc .L7 testrax, rax jne .L33 xor r8d, r8d xor edi, edi .L9: lea rcx, [rdi+4+r14] movqxmm0, rdi mov DWORD PTR [rdi+r14], ebp movqxmm1, rcx punpcklqdq xmm0, xmm1 testr14, r14
[Bug middle-end/100104] std::transform is 1.5 times faster than std::copy with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100104 --- Comment #2 from 康桓瑋 --- Build "copy" with -O2 on x86-64 (https://godbolt.org/z/Gja6xrq9G): .LC0: .string "vector::_M_realloc_insert" copy(std::vector > const&): pushr15 pxorxmm0, xmm0 pushr14 pushr13 pushr12 mov r12, rdi pushrbp pushrbx sub rsp, 40 mov r13, QWORD PTR [rsi+8] mov rbx, QWORD PTR [rsi] movups XMMWORD PTR [rdi], xmm0 mov QWORD PTR [rdi+16], 0 cmp rbx, r13 je .L1 xor r8d, r8d xor ecx, ecx jmp .L13 .L31: mov DWORD PTR [rcx], ebp add rbx, 8 add rcx, 4 mov QWORD PTR [r12+8], rcx cmp r13, rbx je .L1 .L13: cvttsd2si ebp, QWORD PTR [rbx] cmp rcx, r8 jne .L31 movabs rax, 2305843009213693951 mov r15, QWORD PTR [r12] sub rcx, r15 mov rdx, rcx mov r14, rcx sar rdx, 2 cmp rdx, rax je .L32 testrdx, rdx mov eax, 1 cmovne rax, rdx add rax, rdx jc .L7 testrax, rax jne .L33 xor r8d, r8d xor edi, edi .L9: lea rcx, [rdi+4+r14] movqxmm0, rdi mov DWORD PTR [rdi+r14], ebp movqxmm1, rcx punpcklqdq xmm0, xmm1 testr14, r14 jg .L34 testr15, r15 jne .L35 .L12: add rbx, 8 mov QWORD PTR [r12+16], r8 movups XMMWORD PTR [r12], xmm0 cmp r13, rbx jne .L13 .L1: add rsp, 40 mov rax, r12 pop rbx pop rbp pop r12 pop r13 pop r14 pop r15 ret .L34: mov rsi, r15 mov rdx, r14 mov QWORD PTR [rsp+8], r8 mov QWORD PTR [rsp], rcx movaps XMMWORD PTR [rsp+16], xmm0 callmemmove mov rsi, QWORD PTR [r12+16] mov rcx, QWORD PTR [rsp] mov r8, QWORD PTR [rsp+8] movdqa xmm0, XMMWORD PTR [rsp+16] sub rsi, r15 .L11: mov rdi, r15 mov QWORD PTR [rsp+8], r8 mov QWORD PTR [rsp], rcx movaps XMMWORD PTR [rsp+16], xmm0 calloperator delete(void*, unsigned long) movdqa xmm0, XMMWORD PTR [rsp+16] mov r8, QWORD PTR [rsp+8] mov rcx, QWORD PTR [rsp] jmp .L12 .L35: mov rsi, QWORD PTR [r12+16] sub rsi, r15 jmp .L11 .L33: movabs rdx, 2305843009213693951 cmp rax, rdx cmova rax, rdx sal rax, 2 mov QWORD PTR [rsp], rax mov rdi, rax .L8: calloperator new(unsigned long) mov r8, QWORD PTR [rsp] mov rdi, rax add r8, rax jmp .L9 .L7: movabs rax, 9223372036854775804 mov QWORD PTR [rsp], rax mov rdi, rax jmp .L8 .L32: mov edi, OFFSET FLAT:.LC0 callstd::__throw_length_error(char const*) mov rbp, rax jmp .L15 copy(std::vector > const&) [clone .cold]: === with -O3: .LC0: .string "vector::_M_realloc_insert" copy(std::vector > const&): pushr15 pxorxmm0, xmm0 pushr14 pushr13 pushr12 mov r12, rdi pushrbp pushrbx sub rsp, 40 mov r13, QWORD PTR [rsi+8] mov rbx, QWORD PTR [rsi] movups XMMWORD PTR [rdi], xmm0 mov QWORD PTR [rdi+16], 0 cmp rbx, r13 je .L1 xor r8d, r8d xor ecx, ecx jmp .L13 .L31: mov DWORD PTR [rcx], ebp add rbx, 8 add rcx, 4 mov QWORD PTR [r12+8], rcx cmp r13, rbx je .L1 .L13: cvttsd2si ebp, QWORD PTR [rbx] cmp rcx, r8 jne .L31 movabs rax, 2305843009213693951 mov r15, QWORD PTR [r12] sub rcx, r15 mov rdx, rcx mov r14, rcx sar rdx, 2 cmp rdx, rax je .L32 testrdx, rdx mov eax, 1 cmovne rax, rdx add rax, rdx jc .L7 testrax, rax jne .L33 xor r8d, r8d xor edi, edi .L9: lea rcx, [rdi+4+r14] movqxmm0, rdi mov DWORD PTR [rdi+r14], ebp movqxmm1, rcx punpcklqdq xmm0, xmm1 testr14, r14
[Bug tree-optimization/91470] [10/11 Regression] bogus uninitialized warning in trans-intrinsic.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91470
Martin Sebor changed:
What|Removed |Added
Known to fail||10.2.0, 11.0
Last reconfirmed|2019-08-27 00:00:00 |2021-4-15
CC||msebor at gcc dot gnu.org
--- Comment #5 from Martin Sebor ---
Reconfirmed with GCC 11 and a reduced/corrected test case and slightly enhanced
output:
$ cat pr91470.c && gcc -O2 -S -Wall pr91470.c
int i1;
int* f1 (int);
void f2 (int, int);
void g2 (int, void *);
void f0 (void)
{
int *p;
for (int i = 0; i < 2; i++)
{
f2 (0, 0);
f2 (0, 0);
f2 (0, 0);
f2 (0, 0);
g2 (i1, 0);
if (i == 0)
p = f1 (0);
}
g2 (i1, p);
}
void f0 ()
{
int i;
int * p;
int i1.0_1;
int i1.1_2;
int _6;
[local count: 357878152]:
[local count: 715863673]:
# p_26 = PHI
# i_27 = PHI <_6(6), 0(2)>
# .MEM_28 = PHI <.MEM_25(6), .MEM_10(D)(2)>
# .MEM_12 = VDEF <.MEM_28>
f2 (0, 0);
# .MEM_13 = VDEF <.MEM_12>
f2 (0, 0);
# .MEM_14 = VDEF <.MEM_13>
f2 (0, 0);
# .MEM_15 = VDEF <.MEM_14>
f2 (0, 0);
# VUSE <.MEM_15>
i1.0_1 = i1;
# .MEM_16 = VDEF <.MEM_15>
g2 (i1.0_1, 0B);
_6 = i_27 + 1;
if (_6 == 1)
goto ; [21.69%]
else
goto ; [78.31%]
[local count: 155270830]:
# .MEM_17 = VDEF <.MEM_16>
p_18 = f1 (0);
goto ; [100.00%]
[local count: 560592843]:
if (_6 != 2)
goto ; [36.16%]
else
goto ; [63.84%]
[local count: 202714689]:
[local count: 357985519]:
# p_4 = PHI
# .MEM_25 = PHI <.MEM_16(8), .MEM_17(4)>
goto ; [100.00%]
[local count: 357878152]:
# VUSE <.MEM_16>
i1.1_2 = i1;
# .MEM_11 = VDEF <.MEM_16>
g2 (i1.1_2, p_26); [tail call]
# VUSE <.MEM_11>
return;
}
pr91470.c: In function ‘f0’:
pr91470.c:23:3: warning: ‘p’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
23 | g2 (i1, p);
| ^~
pr91470.c:9:8: note: used when ‘i + 1 != 1 && i + 1 != 2 || i + 1 != 1 && i + 1
== 2’
9 | int *p;
|^
pr91470.c:9:8: note: ‘p’ was declared here
[Bug tree-optimization/99971] GCC generates partially vectorized and scalar code at once
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99971 Dávid Bolvanský changed: What|Removed |Added CC||david.bolvansky at gmail dot com --- Comment #7 from Dávid Bolvanský --- Still bad for -O3 -march=skylake-avx512 https://godbolt.org/z/azb8aTG43
[Bug middle-end/86172] [meta-bug] issues with -Wnull-dereference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86172 Bug 86172 depends on bug 89202, which changed state. Bug 89202 Summary: missing -Wnonnull-dereference or -Wuninitialized for a certain bug (CCP) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89202 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE
[Bug tree-optimization/18501] [8/9/10/11 Regression] Missing 'used uninitialized' warning (CCP)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18501 --- Comment #96 from Martin Sebor --- *** Bug 89202 has been marked as a duplicate of this bug. ***
[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639 Bug 24639 depends on bug 89202, which changed state. Bug 89202 Summary: missing -Wnonnull-dereference or -Wuninitialized for a certain bug (CCP) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89202 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE
[Bug tree-optimization/89202] missing -Wnonnull-dereference or -Wuninitialized for a certain bug (CCP)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89202 Martin Sebor changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #2 from Martin Sebor --- Agreed, it's dupe of pr18501. -Wnull-dereference would benefit from the same predicate analysis as -Wmaybe-uninitialized. *** This bug has been marked as a duplicate of bug 18501 ***
[Bug middle-end/90844] missing -Wmaybe-uninitialized with -flto and optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90844
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
Summary|Another case of missing use |missing
|of uninitialized variable |-Wmaybe-uninitialized with
|warning (inlining, CCP) |-flto and optimization
Last reconfirmed|2019-06-12 00:00:00 |2021-4-15
Known to fail||10.2.0, 11.0, 8.3.0, 9.3.0
--- Comment #3 from Martin Sebor ---
The late uninit pass doesn't run with -flto; all that runs is the early
uninitialized pass and it disables the "conditional" -Wmaybe-uninitialized when
optimization is enabled:
static unsigned int
execute_early_warn_uninitialized (void)
{
/* Currently, this pass runs always but
execute_late_warn_uninitialized only runs with optimization. With
optimization we want to warn about possible uninitialized as late
as possible, thus don't do it here. However, without
optimization we need to warn here about "may be uninitialized". */
calculate_dominance_info (CDI_POST_DOMINATORS);
warn_uninitialized_vars (/*warn_maybe_uninitialized=*/!optimize);
^
Changing that like so lets the warning do its thing even with -flto:
@@ -3086,7 +3079,8 @@ execute_early_warn_uninitialized (void)
optimization we need to warn here about "may be uninitialized". */
calculate_dominance_info (CDI_POST_DOMINATORS);
- warn_uninitialized_vars (/*warn_maybe_uninitialized=*/!optimize);
+ bool wmaybe_uninit = !optimize || flag_lto;
+ warn_uninitialized_vars (wmaybe_uninit);
/* Post-dominator information cannot be reliably updated. Free it
after the use. */
[Bug c/89180] [meta-bug] bogus/missing -Wunused warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89180 Bug 89180 depends on bug 99972, which changed state. Bug 99972 Summary: missing -Wunused-result on a call to a locally redeclared warn_unused_result function https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99972 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c/99972] missing -Wunused-result on a call to a locally redeclared warn_unused_result function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99972 Martin Sebor changed: What|Removed |Added Target Milestone|--- |11.0 Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from Martin Sebor --- Fix committed in r11-8205.
[Bug c/99420] [11 Regression] bogus -Warray-parameter on a function redeclaration in function scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99420 Martin Sebor changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #8 from Martin Sebor --- Fix committed in r11-8205.
[Bug c/99420] [11 Regression] bogus -Warray-parameter on a function redeclaration in function scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99420 --- Comment #7 from CVS Commits --- The master branch has been updated by Martin Sebor : https://gcc.gnu.org/g:da879e01ecd35737c18be1da3324f4560aba1961 commit r11-8205-gda879e01ecd35737c18be1da3324f4560aba1961 Author: Martin Sebor Date: Thu Apr 15 15:49:30 2021 -0600 Propagate type attribute when merging extern declarations at local scope. Resolves: PR c/99420 - bogus -Warray-parameter on a function redeclaration in function scope PR c/99972 - missing -Wunused-result on a call to a locally redeclared warn_unused_result function gcc/c/ChangeLog: PR c/99420 PR c/99972 * c-decl.c (pushdecl): Always propagate type attribute. gcc/testsuite/ChangeLog: PR c/99420 PR c/99972 * gcc.dg/Warray-parameter-9.c: New test. * gcc.dg/Wnonnull-6.c: New test. * gcc.dg/Wreturn-type3.c: New test. * gcc.dg/Wunused-result.c: New test. * gcc.dg/attr-noreturn.c: New test. * gcc.dg/attr-returns-nonnull.c: New test.
[Bug c/99972] missing -Wunused-result on a call to a locally redeclared warn_unused_result function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99972 --- Comment #4 from CVS Commits --- The master branch has been updated by Martin Sebor : https://gcc.gnu.org/g:da879e01ecd35737c18be1da3324f4560aba1961 commit r11-8205-gda879e01ecd35737c18be1da3324f4560aba1961 Author: Martin Sebor Date: Thu Apr 15 15:49:30 2021 -0600 Propagate type attribute when merging extern declarations at local scope. Resolves: PR c/99420 - bogus -Warray-parameter on a function redeclaration in function scope PR c/99972 - missing -Wunused-result on a call to a locally redeclared warn_unused_result function gcc/c/ChangeLog: PR c/99420 PR c/99972 * c-decl.c (pushdecl): Always propagate type attribute. gcc/testsuite/ChangeLog: PR c/99420 PR c/99972 * gcc.dg/Warray-parameter-9.c: New test. * gcc.dg/Wnonnull-6.c: New test. * gcc.dg/Wreturn-type3.c: New test. * gcc.dg/Wunused-result.c: New test. * gcc.dg/attr-noreturn.c: New test. * gcc.dg/attr-returns-nonnull.c: New test.
[Bug middle-end/85563] [8/9/10/11 regression] -Wmaybe-uninitialized false alarm regression with __builtin_unreachable and GCC 8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85563
Martin Sebor changed:
What|Removed |Added
Keywords||missed-optimization
Last reconfirmed|2018-04-30 00:00:00 |2021-4-15
CC||msebor at gcc dot gnu.org
Known to fail|8.0.1 |10.2.0, 11.0, 8.3.0, 9.3.0
--- Comment #18 from Martin Sebor ---
Reconfirming with GCC 11.
Inverting the reachability expression:
((CONSP (Vframe_list)) ? (void) 0 : __builtin_unreachable ());
to
(!(CONSP (Vframe_list)) ? __builtin_unreachable () : (void) 0);
or changing it to a corresponding if statement avoids the warning and improves
the emitted code, implying there is a missed optimization opportunity there
somewhere.
I also reduced the test from comment #6 a bit further to make it easier to
read:
struct A
{
struct A *p, *q;
};
extern void *p;
inline _Bool
f (void* a)
{
return ((__INTPTR_TYPE__) (a) & ~(- (1 << 3))) == 3;
}
inline struct A *
g (void* a)
{
return (struct A *)((char *)a - 3);
}
extern void* foo (void*);
void bar (void)
{
#if NOWARN
if (!f (p))
__builtin_unreachable ();
#else
f (p) ? (void)0 : __builtin_unreachable ();
#endif
void* q;
for (void *r = p; f (r) && ((q = g (r)->p), 1); r = g (r)->q)
;
foo (q);
}
[Bug target/100106] [10/11 Regression] ICE in gen_movdi, at config/arm/arm.md:6187 since r10-2840-g70cdb21e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100106 Alex Coplan changed: What|Removed |Added Target||arm Keywords||ice-on-valid-code Known to fail||10.2.1, 11.0 Target Milestone|--- |10.4 Known to work||9.2.1
[Bug target/100106] New: [10/11 Regression] ICE in gen_movdi, at config/arm/arm.md:6187 since r10-2840-g70cdb21e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100106
Bug ID: 100106
Summary: [10/11 Regression] ICE in gen_movdi, at
config/arm/arm.md:6187 since r10-2840-g70cdb21e
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: acoplan at gcc dot gnu.org
Target Milestone: ---
The following fails:
$ cat test.c
union a {
float _Complex b;
long long c;
};
void g(union a);
void e() {
union a f = {1.0f};
g(f);
}
$ gcc/xgcc -B gcc test.c -c -O
during RTL pass: expand
test.c: In function ‘e’:
test.c:9:11: internal compiler error: in gen_movdi, at config/arm/arm.md:6187
9 | union a f = {1.0f};
| ^
0x1de9e64 gen_movdi(rtx_def*, rtx_def*)
/home/alecop01/toolchain/src/gcc/gcc/config/arm/arm.md:6187
0xdb9086 rtx_insn* insn_gen_fn::operator()(rtx_def*,
rtx_def*) const
/home/alecop01/toolchain/src/gcc/gcc/recog.h:407
0xd8ff58 emit_move_insn_1(rtx_def*, rtx_def*)
/home/alecop01/toolchain/src/gcc/gcc/expr.c:3766
0xd909ca emit_move_insn(rtx_def*, rtx_def*)
/home/alecop01/toolchain/src/gcc/gcc/expr.c:3936
0xd69cbb store_bit_field_1
/home/alecop01/toolchain/src/gcc/gcc/expmed.c:804
0xd6b8bb store_bit_field(rtx_def*, poly_int<1u, unsigned long>, poly_int<1u,
unsigned long>, poly_int<1u, unsigned long>, poly_int<1u, unsigned long>,
machine_mode, rtx_def*, bool)
/home/alecop01/toolchain/src/gcc/gcc/expmed.c:1183
0xd9eaef store_field
/home/alecop01/toolchain/src/gcc/gcc/expr.c:7353
0xd95ddf expand_assignment(tree_node*, tree_node*, bool)
/home/alecop01/toolchain/src/gcc/gcc/expr.c:5482
0xbf2c4e expand_gimple_stmt_1
/home/alecop01/toolchain/src/gcc/gcc/cfgexpand.c:3910
0xbf303d expand_gimple_stmt
/home/alecop01/toolchain/src/gcc/gcc/cfgexpand.c:4008
0xbfbaa3 expand_gimple_basic_block
/home/alecop01/toolchain/src/gcc/gcc/cfgexpand.c:6045
0xbfd954 execute
/home/alecop01/toolchain/src/gcc/gcc/cfgexpand.c:6729
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug fortran/63797] Bogus ambiguous reference to 'sqrt'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63797 --- Comment #9 from anlauf at gcc dot gnu.org --- Patch: https://gcc.gnu.org/pipermail/fortran/2021-April/055935.html
[Bug fortran/63797] Bogus ambiguous reference to 'sqrt'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63797 --- Comment #8 from anlauf at gcc dot gnu.org --- (In reply to Steve Kargl from comment #7) > which looks like a default initialization. Does sqrt need to be > recorded into the module? If not, then your patch is probably ok. My patch actually does not have any affect on the module file generated for your testcase. I'll add it to my testcase and submit.
[Bug middle-end/84877] Local stack copy of BLKmode parameter on the stack is not aligned when the requested alignment exceeds MAX_SUPPORTED_STACK_ALIGNMENT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84877 --- Comment #22 from CVS Commits --- The master branch has been updated by Hans-Peter Nilsson : https://gcc.gnu.org/g:58fe131b91007793c0f12f5fe6cab3f1a017d0fa commit r11-8204-g58fe131b91007793c0f12f5fe6cab3f1a017d0fa Author: Hans-Peter Nilsson Date: Thu Apr 15 21:51:08 2021 +0200 gcc.dg/pr84877.c: Xfail for cris-*-* Unfortunately it appears that this PR is on nobody's radar. Xfailing it to get an arguably artificial zero regression state (since T0=2007-01-05) helps my autotester. Caveat: the pass/fail state of this test, as long as stack alignment isn't adjusted, is dependent on the alignment of the stack at the entry of main, so depending on the target, e.g. the size and number of environment variables at invocation time can affect the result (including simulator runs where environment variables are propagated to the target). gcc/testsuite: PR middle-end/84877 * gcc.dg/pr84877.c: Xfail for cris-*-*.
[Bug demangler/100105] New: stack exhaust by recursion in cxxfilt demangler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100105 Bug ID: 100105 Summary: stack exhaust by recursion in cxxfilt demangler Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: demangler Assignee: unassigned at gcc dot gnu.org Reporter: rding at gatech dot edu Target Milestone: --- Created attachment 50607 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50607&action=edit PoC for the crash Hi, A stack exhaustion bug has been found for cxxfilt on the HEAD of the master branch. I was pointed by the reply (https://sourceware.org/bugzilla/show_bug.cgi?id=27737) to report it here since the bug is from the demangler before imported into the codebase of Binutils. The version information is as follows: commit a15a276b46bf07323a1d270d7abece83ef1ea78f (HEAD -> master, origin/master, origin/HEAD) Author: Tom Tromey Date: Thu Apr 15 10:14:11 2021 -0600 cxxfilt --version GNU c++filt (GNU Binutils) 2.36.50.20210415 Copyright (C) 2021 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or (at your option) any later version. This program has absolutely no warranty. The configuration of Binutils is: CC=/home/ren/tmp/afl-2.52b/afl-gcc CFLAGS="-g -fsanitize=address" LDFLAGS="-fsanitize=address" ./configure --disable-gdb --disable-werror CC=/home/ren/tmp/afl-2.52b/afl-gcc CFLAGS="-g -fsanitize=address" LDFLAGS="-fsanitize=address" make To trigger the bug: ./cxxfilt < poc ASAN:DEADLYSIGNAL = ==25277==ERROR: AddressSanitizer: stack-overflow on address 0x7fff13a95fb0 (pc 0x563d15ede61e bp 0x0fffe2752c2e sp 0x7fff13a95fb0 T0) #0 0x563d15ede61d in demangle_path rust-demangle.c:664 #1 0x563d15edfcfd in demangle_path rust-demangle.c:774 #2 0x563d15edfcfd in demangle_path rust-demangle.c:774 #3 0x563d15edfcfd in demangle_path rust-demangle.c:774 ... #248 0x563d15edfcfd in demangle_path rust-demangle.c:774 #249 0x563d15edfcfd in demangle_path rust-demangle.c:774 #250 0x563d15edfcfd in demangle_path rust-demangle.c:774 SUMMARY: AddressSanitizer: stack-overflow rust-demangle.c:664 in demangle_path ==25277==ABORTING The triggering environment we see is on Ubuntu 18.04 (bionic), with gcc version 7.5.0. Please find the PoC we provide in the attachment and let us know if you have any trouble reproducing the crash. Thank you! Credit: Ren Ding (rd...@gatech.edu) Hanqing Zhao (hanq...@gatech.edu)
[Bug c++/80456] [8/9/10 Regression] calling constexpr member function from volatile-qualified member function: error: ‘this’ is not a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80456 Jason Merrill changed: What|Removed |Added Known to work||11.0 Summary|[8/9/10/11 Regression] |[8/9/10 Regression] calling |calling constexpr member|constexpr member function |function from |from volatile-qualified |volatile-qualified member |member function: error: |function: error: ‘this’ is |‘this’ is not a constant |not a constant expression |expression Known to fail|11.0| --- Comment #10 from Jason Merrill --- Fixed for 11 so far.
[Bug c++/80456] [8/9/10/11 Regression] calling constexpr member function from volatile-qualified member function: error: ‘this’ is not a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80456 --- Comment #9 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:3682052e4ccf0a29d1f61df1c8e31f8190eafafe commit r11-8203-g3682052e4ccf0a29d1f61df1c8e31f8190eafafe Author: Jason Merrill Date: Thu Apr 15 15:13:18 2021 -0400 c++: constexpr and volatile member function [PR80456] When calling a static member function we still need to evaluate an explicit object argument. But we don't want to force a load of the entire object if the argument is volatile, so we take its address. If as a result it no longer has any side-effects, we don't need to evaluate it after all. gcc/cp/ChangeLog: PR c++/80456 * call.c (build_new_method_call_1): Check again for side-effects with a volatile object. gcc/testsuite/ChangeLog: PR c++/80456 * g++.dg/cpp0x/constexpr-volatile3.C: New test.
[Bug middle-end/89230] Bogus uninited usage warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89230 --- Comment #10 from CVS Commits --- The master branch has been updated by Martin Sebor : https://gcc.gnu.org/g:2dbbbe893f75f587c48111ab4c97cf5e74fb91bb commit r11-8202-g2dbbbe893f75f587c48111ab4c97cf5e74fb91bb Author: Martin Sebor Date: Thu Apr 15 14:09:56 2021 -0600 PR middle-end/89230 - Bogus uninited usage warning with printf gcc/testsuite/ChangeLog: * gcc.dg/uninit-pr89230-1.c: New test. * gcc.dg/uninit-pr89230-2.c: Same.
[Bug jit/100096] libgccjit.so.0: Cannot write-enable text segment: Permission denied on NetBSD 9.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100096 --- Comment #17 from Sascha Wilde --- (In reply to David Malcolm from comment #16) > (In reply to Sascha Wilde from comment #10) > > (In reply to David Malcolm from comment #8) > > > It would be good to know exactly where that error message is being > > > emitted. > > > > > > If you add: > > > gcc_jit_context_set_logfile (ctxt, stderr, 0, 0); > > > to the test code (e.g. immediately after the call to > > > gcc_jit_context_acquire), libgccjit ought to spew out a copious amount of > > > logging (see > > > https://gcc.gnu.org/onlinedocs/jit/internals/index.html#example-of-log-file) > > > > > > Can you attach the log you get please? > > > > With security.pax.mprotect.global=1 it produces no extra output. > > I'll attach the output produced when security.pax.mprotect.global is > > disabled. > > Thanks! I was wondering if the error message was: > (a) due to a problem dynamically linking libgccjit into the process, or > (b) a later problem with linking the code that libgccjit generates into > the process. > > Given that there's no extra log output at all with the protection flag, it > sounds like it's (a) - though you may run into a similar problem with (b) > if/when (a) gets solved. FWIW, the reason why I stumbled upon this problem is that I am testing the native compiling GNU Emacs branch[0] on the NetBSD system. (Which, by the way, can be build and works great once security.pax.mprotect.global is disabled) When security.pax.mprotect.global is enable the Emacs, linked with libgccjit can not be started at all, failing with the same error as the hello-world example. So this matches your analysis that the problem is triggered by dynamically linking libgccjit. [0] https://akrl.sdf.org/gccemacs.html
[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639 Bug 24639 depends on bug 89230, which changed state. Bug 89230 Summary: Bogus uninited usage warning https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89230 What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED
[Bug middle-end/89230] Bogus uninited usage warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89230 Martin Sebor changed: What|Removed |Added Known to fail||10.2.0, 7.3.0, 8.3.0, 9.2.0 Target Milestone|--- |11.0 Resolution|--- |FIXED Status|WAITING |RESOLVED --- Comment #9 from Martin Sebor --- GCC 11 doesn't issue warnings for the test cases in comment #4 or comment #5 anymore. It has disappeared with g:520d5ad337eaa15860a5a964daf7ca46cf31c029. Let me add the test cases to the test suite and resolve this report as fixed.
[Bug tree-optimization/81776] missing sprintf optimization due to pointer escape analysis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81776 Martin Sebor changed: What|Removed |Added Known to fail||10.2.0, 11.0, 8.3.0, 9.3.0 Last reconfirmed|2018-04-05 00:00:00 |2021-4-15 --- Comment #3 from Martin Sebor --- Reconfirmed with GCC 11. Even worse, since the integration of the sprintf pass into strlen in r274933 GCC doesn't eliminate the abort in g1().
[Bug middle-end/100104] std::transform is 1.5 times faster than std::copy with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100104 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization Component|c++ |middle-end --- Comment #1 from Andrew Pinski --- What target is this on?
[Bug c++/80456] [8/9/10/11 Regression] calling constexpr member function from volatile-qualified member function: error: ‘this’ is not a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80456 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Known to work||7.5.0 Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug c++/100101] [11 Regression] ICE with -Wzero-as-null-pointer-constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100101 --- Comment #5 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:2efbbba16a0630fac8cadcd6d9e0ffaabfadb79f commit r11-8201-g2efbbba16a0630fac8cadcd6d9e0ffaabfadb79f Author: Jason Merrill Date: Thu Apr 15 13:38:54 2021 -0400 c++: noexcept error recursion [PR100101] Here instantiating the noexcept-specifier for bar() means instantiating A::value, which complains about the conversion from 0 to int* in the default argument of foo. Since my patch for PR99583, printing the error context involves looking at C::type, which again wants to instantiate A::value, which breaks. For now at least, let's break this recursion by avoiding looking into the noexcept-specifier in find_typenames, and limit that to just the uses_parameter_packs case that PR99583 cares about. gcc/cp/ChangeLog: PR c++/100101 PR c++/99583 * pt.c (find_parameter_packs_r) [FUNCTION_TYPE]: Walk into TYPE_RAISES_EXCEPTIONS here. * tree.c (cp_walk_subtrees): Not here. gcc/testsuite/ChangeLog: PR c++/100101 * g++.dg/cpp0x/noexcept67.C: New test.
[Bug c++/100101] [11 Regression] ICE with -Wzero-as-null-pointer-constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100101 Jason Merrill changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Jason Merrill --- Fixed.
[Bug c++/99583] Parameter packs not expanded in lambda noexcept specifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99583 --- Comment #4 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:2efbbba16a0630fac8cadcd6d9e0ffaabfadb79f commit r11-8201-g2efbbba16a0630fac8cadcd6d9e0ffaabfadb79f Author: Jason Merrill Date: Thu Apr 15 13:38:54 2021 -0400 c++: noexcept error recursion [PR100101] Here instantiating the noexcept-specifier for bar() means instantiating A::value, which complains about the conversion from 0 to int* in the default argument of foo. Since my patch for PR99583, printing the error context involves looking at C::type, which again wants to instantiate A::value, which breaks. For now at least, let's break this recursion by avoiding looking into the noexcept-specifier in find_typenames, and limit that to just the uses_parameter_packs case that PR99583 cares about. gcc/cp/ChangeLog: PR c++/100101 PR c++/99583 * pt.c (find_parameter_packs_r) [FUNCTION_TYPE]: Walk into TYPE_RAISES_EXCEPTIONS here. * tree.c (cp_walk_subtrees): Not here. gcc/testsuite/ChangeLog: PR c++/100101 * g++.dg/cpp0x/noexcept67.C: New test.
[Bug c++/99683] Deduction failure when using CTAD of CNTTP inside a deduction guide
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99683 Patrick Palka changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=93383 Status|UNCONFIRMED |NEW CC||ppalka at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2021-04-15 --- Comment #2 from Patrick Palka --- Thanks for the reduced testcases, confirmed. Closely related to PR93383 I think.
[Bug target/100085] Bad code for union transfer from __float128 to vector types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100085 --- Comment #3 from Segher Boessenkool --- The rotates in 6 and 7 are not merged, and neither are the vec_selects in 8 and 9. Both should be pretty easy to do, there is no unspec in sight, etc.
[Bug tree-optimization/100102] [8/9/10/11 Regression] ICE in tsubst, at cp/pt.c:15310
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100102
Jakub Jelinek changed:
What|Removed |Added
Keywords||ice-on-valid-code
--- Comment #4 from Jakub Jelinek ---
Another reduction, which is accepted by g++ 7.x and clang++ and ICEs the same
way by 8-trunk:
template using a = int;
template struct b;
template struct c;
template struct i;
template using e = typename i::f;
template using g = e::h>;
template struct j;
template struct k {
static long o();
template using n = a::den>;
template , l struct q {};
};
[Bug c++/100104] New: std::transform is 1.5 times faster than std::copy with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100104
Bug ID: 100104
Summary: std::transform is 1.5 times faster than std::copy with
-O3
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
Consider:
std::vector v1(100, 0);
// copy using copy
std::vector v2;
std::copy(v1.begin(), v1.end(), std::back_inserter(v2));
// copy using transform
std::vector v2;
std::transform(v1.begin(), v1.end(), std::back_inserter(v2), [](auto x) {
return x; });
Those two will generate similar assembly code under -O2, but is very different
under -O3/-Ofast, and transform will be 1.5 times faster than the copy. I don’t
know if this is a bug since these two represent the same thing, and correct me
if I am wrong.
quick-bench with -O2:
https://quick-bench.com/q/uKT8QEmPkS1wr153s3P-DRt90eY
quick-bench with -O3:
https://quick-bench.com/q/syuBCQYVtCoVwT2MRtLT25P-MQI
goldbot:
https://godbolt.org/z/7ee77cs8W
[Bug target/100099] Compilation speed of #include is too slow. Just include the header takes 0.342 seconds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100099 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement Keywords||compile-time-hog Component|preprocessor|target Status|UNCONFIRMED |NEW Last reconfirmed||2021-04-15 Ever confirmed|0 |1 --- Comment #2 from Andrew Pinski --- One thing which could be done is similar to what AARCH64 did for SVE/SVE2 builtins and just implement the majority of the intrinsics in the front-end. The aarch64 target does this in the user include header: #pragma GCC aarch64 "arm_sve.h" Which just interjects the intrinsics as builtins at that point.
[Bug c++/99683] Deduction failure when using CTAD of CNTTP inside a deduction guide
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99683
--- Comment #1 from Omer Rosler ---
It seems that
Reduced:
template
struct A
{
constexpr A(int) {}
};
A(int) -> A;
template //template works fine
struct B
{
template
B(T);
};
template
B(T) -> B; //see below
int main()
{
B t(42);
}
specifying A explicitly also works, it's the deduction that triggers the bug
If the initializer of `A` is not dependent on the template parameter of the
guide (i.e `T`) than the bug isn't showing
[Bug jit/100096] libgccjit.so.0: Cannot write-enable text segment: Permission denied on NetBSD 9.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100096 --- Comment #16 from David Malcolm --- (In reply to Sascha Wilde from comment #10) > (In reply to David Malcolm from comment #8) > > It would be good to know exactly where that error message is being emitted. > > > > If you add: > > gcc_jit_context_set_logfile (ctxt, stderr, 0, 0); > > to the test code (e.g. immediately after the call to > > gcc_jit_context_acquire), libgccjit ought to spew out a copious amount of > > logging (see > > https://gcc.gnu.org/onlinedocs/jit/internals/index.html#example-of-log-file) > > > > Can you attach the log you get please? > > With security.pax.mprotect.global=1 it produces no extra output. > I'll attach the output produced when security.pax.mprotect.global is > disabled. Thanks! I was wondering if the error message was: (a) due to a problem dynamically linking libgccjit into the process, or (b) a later problem with linking the code that libgccjit generates into the process. Given that there's no extra log output at all with the protection flag, it sounds like it's (a) - though you may run into a similar problem with (b) if/when (a) gets solved.
[Bug tree-optimization/100102] [8/9/10/11 Regression] ICE in tsubst, at cp/pt.c:15310
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100102 Jakub Jelinek changed: What|Removed |Added Summary|ICE in tsubst, at |[8/9/10/11 Regression] ICE |cp/pt.c:15310 |in tsubst, at cp/pt.c:15310 Target Milestone|--- |8.5 Priority|P3 |P2 CC||jason at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Started to ICE with r8-2724-g88b811bd29063036fd4536ee1312b1269cade6ed
[Bug tree-optimization/100102] ICE in tsubst, at cp/pt.c:15310
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100102
Jakub Jelinek changed:
What|Removed |Added
Last reconfirmed||2021-04-15
Status|UNCONFIRMED |NEW
CC||jakub at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #2 from Jakub Jelinek ---
Reduced testcase (though invalid):
template using a = int;
template struct b;
template struct c {
static long m_fn1();
template using d = a::den>;
class e d;
};
[Bug middle-end/90115] OpenACC: predetermined private levels for variables declared in blocks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90115 Thomas Schwinge changed: What|Removed |Added Blocks||90114 --- Comment #1 from Thomas Schwinge --- Very much related is privatization via the corresponding 'private' clauses, at the respective level. (Thus not filing a new PR for that.) OpenACC 3.1, 2.5.12 "private clause" (similar 2.5.13 "firstprivate clause") states that on compute constructs, "The 'private' clause [...] declares that a copy of each item on the list will be created for each gang", and OpenACC 3.1, 2.9.10 "private clause" states: | The 'private' clause on a 'loop' construct specifies that a copy of each item in var-list will be created. If the body of the loop is executed in 'vector-partitioned' mode, a copy of the item is created for each thread associated with each vector lane. If the body of the loop is executed in 'worker-partitioned' 'vector-single' mode, a copy of the item is created for and shared across the set of threads associated with all the vector lanes of each worker. Otherwise, a copy of the item is created for and shared across the set of threads associated with all the vector lanes of all the workers of each gang. Also related is PR90114 "Predetermined private levels for variables declared in OpenACC accelerator routines". Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90114 [Bug 90114] Predetermined private levels for variables declared in OpenACC accelerator routines
[Bug c++/99861] [modules] ICE in hashtab_chk_error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99861
--- Comment #4 from Alexander Lelyakin ---
After every few commits one sequence stops to reproduce this error, but some
another appears.
See current status here: http://lelyakin.de/modules/in%20hashtab_chk_error/
Today shortest sequence is:
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header cerrno
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header unordered_map
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header cstring
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header stdexcept
/usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header algorithm
hash table checking failed: equal operator returns true for a pair of values
with a different hash value
In file included from /usr/local/include/c++/11.0.1/vector:66,
from /usr/local/include/c++/11.0.1/functional:62,
from
/usr/local/include/c++/11.0.1/pstl/glue_algorithm_defs.h:13,
from /usr/local/include/c++/11.0.1/algorithm:74:
/usr/local/include/c++/11.0.1/bits/stl_uninitialized.h: In static member
function ‘static _ForwardIterator
std::__uninitialized_copy::__uninit_copy(_InputIterator, _InputIterator,
_ForwardIterator)’:
/usr/local/include/c++/11.0.1/bits/stl_uninitialized.h:110:23: internal
compiler error: in hashtab_chk_error, at hash-table.c:137
110 | { return std::copy(__first, __last, __result); }
| ^~~~
0x92f4b5 hashtab_chk_error()
../../gcc/gcc/hash-table.c:137
0xb3e835 hash_table::verify(spec_entry*
const&, unsigned int)
../../gcc/gcc/hash-table.h:1033
0xb3edbe hash_table::find_slot_with_hash(spec_entry* const&, unsigned int,
insert_option)
../../gcc/gcc/hash-table.h:968
0xafba1b match_mergeable_specialization(bool, spec_entry*)
../../gcc/gcc/cp/pt.c:3
0xa74b08 trees_in::key_mergeable(int, merge_kind, tree_node*, tree_node*,
tree_node*, tree_node*, bool)
../../gcc/gcc/cp/module.cc:10670
0xa78704 trees_in::decl_value()
../../gcc/gcc/cp/module.cc:7903
0xa71567 trees_in::tree_node(bool)
../../gcc/gcc/cp/module.cc:9153
0xa77b8b module_state::read_cluster(unsigned int)
../../gcc/gcc/cp/module.cc:14811
0xa7808d module_state::load_section(unsigned int, binding_slot*)
../../gcc/gcc/cp/module.cc:18082
0xa7814f module_state::lazy_load(unsigned int, binding_slot*)
../../gcc/gcc/cp/module.cc:18740
0xa723d0 trees_in::tree_node(bool)
../../gcc/gcc/cp/module.cc:9664
0xa7788b module_state::read_cluster(unsigned int)
../../gcc/gcc/cp/module.cc:14717
0xa7808d module_state::load_section(unsigned int, binding_slot*)
../../gcc/gcc/cp/module.cc:18082
0xa7814f module_state::lazy_load(unsigned int, binding_slot*)
../../gcc/gcc/cp/module.cc:18740
0xa723d0 trees_in::tree_node(bool)
../../gcc/gcc/cp/module.cc:9664
0xa7788b module_state::read_cluster(unsigned int)
../../gcc/gcc/cp/module.cc:14717
0xa7808d module_state::load_section(unsigned int, binding_slot*)
../../gcc/gcc/cp/module.cc:18082
0xa7814f module_state::lazy_load(unsigned int, binding_slot*)
../../gcc/gcc/cp/module.cc:18740
0xa723d0 trees_in::tree_node(bool)
../../gcc/gcc/cp/module.cc:9664
0xa7788b module_state::read_cluster(unsigned int)
../../gcc/gcc/cp/module.cc:14717
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
g++ (GCC) 11.0.1 20210415 (experimental)
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[Bug c++/81714] incorrect location for uninitialised variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81714 Martin Sebor changed: What|Removed |Added CC||skvadrik at gmail dot com --- Comment #3 from Martin Sebor --- *** Bug 60741 has been marked as a duplicate of this bug. ***
[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639 Bug 24639 depends on bug 60741, which changed state. Bug 60741 Summary: -Wmaybe-uninitialized wrong location https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60741 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE
[Bug middle-end/60741] -Wmaybe-uninitialized wrong location
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60741 Martin Sebor changed: What|Removed |Added CC||msebor at gcc dot gnu.org Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from Martin Sebor --- The poor location in C++ is also tracked in pr81714. Let me keep that bug open since it has a simpler test case and resolve this one as its dupe. (The C front end does point to the + expression.) *** This bug has been marked as a duplicate of bug 81714 ***
[Bug c++/100101] [11 Regression] ICE with -Wzero-as-null-pointer-constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100101
--- Comment #4 from Jakub Jelinek ---
--- gcc/cp/error.c.jj 2021-02-25 23:27:46.561918450 +0100
+++ gcc/cp/error.c 2021-04-15 19:10:38.389850343 +0200
@@ -1554,10 +1554,12 @@ find_typenames_r (tree *tp, int *walk_su
/* Add the typename without any cv-qualifiers. */
mv = TYPE_MAIN_VARIANT (*tp);
- if (PACK_EXPANSION_P (*tp))
+ if (PACK_EXPANSION_P (*tp) || EXPR_P (*tp))
{
/* Don't mess with parameter packs since we don't remember
-the pack expansion context for a particular typename. */
+the pack expansion context for a particular typename.
+Similarly, don't walk into expressions such as
+those inside of TYPE_RAISES_EXCEPTIONS. */
*walk_subtrees = false;
return NULL_TREE;
}
passed make check-c++-all and fixes the testcase.
[Bug c++/100101] [11 Regression] ICE with -Wzero-as-null-pointer-constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100101 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug target/99540] [10 Regression] ICE: Segmentation fault in aarch64_add_offset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99540 rsandifo at gcc dot gnu.org changed: What|Removed |Added Target Milestone|10.4|8.5 --- Comment #13 from rsandifo at gcc dot gnu.org --- I think it should be backported back to GCC 8.
[Bug c++/100091] [11 Regression] decltype([]{}) rejected as a default template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100091 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Jason Merrill --- Fixed in r11-8199
[Bug c++/99700] [10/11 Regression] uninitialized variable accepted as a constant expression in C++ 20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99700
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot
gnu.org
Status|NEW |ASSIGNED
--- Comment #3 from Patrick Palka ---
It seems reduced_constant_expression_p needs to check that a
CONSTRUCTOR_NO_CLEARING array ctor initializes all elements.
I'm testing:
diff --git a/gcc/cp/constexpr.c b/gcc/cp/constexpr.c
index c8d9dae36fb..6e530f9c88d 100644
--- a/gcc/cp/constexpr.c
+++ b/gcc/cp/constexpr.c
@@ -46,6 +46,7 @@ do {
\
static HOST_WIDE_INT find_array_ctor_elt (tree ary, tree dindex,
bool insert = false);
+static int array_index_cmp (tree key, tree index);
/* Returns true iff FUN is an instantiation of a constexpr function
template or a defaulted constexpr function. */
@@ -2912,7 +2913,25 @@ reduced_constant_expression_p (tree t)
else if (cxx_dialect >= cxx20
/* An ARRAY_TYPE doesn't have any TYPE_FIELDS. */
&& TREE_CODE (TREE_TYPE (t)) == ARRAY_TYPE)
- field = NULL_TREE;
+ {
+ tree min = TYPE_MIN_VALUE (TYPE_DOMAIN (TREE_TYPE (t)));
+ tree max = TYPE_MAX_VALUE (TYPE_DOMAIN (TREE_TYPE (t)));
+ if (find_array_ctor_elt (t, min) == -1
+ || find_array_ctor_elt (t, max) == -1)
+ return false;
+ tree cursor = size_zero_node;
+ FOR_EACH_CONSTRUCTOR_ELT (CONSTRUCTOR_ELTS (t), i, idx, val)
+ {
+ if (!reduced_constant_expression_p (val))
+ return false;
+ if (array_index_cmp (cursor, idx) != 0)
+ return false;
+ if (TREE_CODE (idx) == RANGE_EXPR)
+ cursor = TREE_OPERAND (idx, 1);
+ cursor = int_const_binop (PLUS_EXPR, cursor, size_one_node);
+ }
+ return true;
+ }
else if (cxx_dialect >= cxx20
&& TREE_CODE (TREE_TYPE (t)) == UNION_TYPE)
{
[Bug target/99540] [10 Regression] ICE: Segmentation fault in aarch64_add_offset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99540 --- Comment #12 from Alex Coplan --- Looks like this can be closed?
[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639 Bug 24639 depends on bug 81962, which changed state. Bug 81962 Summary: -Wmaybe-uninitialized refers to wrong line (and only works with -O3) (Fortran) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81962 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE
[Bug middle-end/63943] wrong location for -Wmaybe-uninitialized in inlined function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63943 Martin Sebor changed: What|Removed |Added See Also|https://gcc.gnu.org/bugzill | |a/show_bug.cgi?id=81962 | CC||janus at gcc dot gnu.org --- Comment #6 from Martin Sebor --- *** Bug 81962 has been marked as a duplicate of this bug. ***
[Bug middle-end/81962] -Wmaybe-uninitialized refers to wrong line (and only works with -O3) (Fortran)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81962
Martin Sebor changed:
What|Removed |Added
See Also|https://gcc.gnu.org/bugzill |
|a/show_bug.cgi?id=63943 |
CC||msebor at gcc dot gnu.org
Status|NEW |RESOLVED
Resolution|--- |DUPLICATE
--- Comment #5 from Martin Sebor ---
This is, in fact, a duplicate of pr63943.
A C test case that reproduces the same effect is below. I doubt this will ever
be perfect.
$ cat a.c && gcc -O2 -S -Wall -fdump-tree-uninit-lineno=/dev/stdout a.c
int z;
void f (int i)
{
z = i + 1;
}
void g (int a, int b, int c)
{
int x;
if (a && b)
x = a + b;
if (b && c)
f (x + 1);
}
;; Function f (f, funcdef_no=0, decl_uid=1944, cgraph_uid=1, symbol_order=1)
void f (int i)
{
int _1;
[local count: 1073741824]:
[a.c:5:9] _1 = i_2(D) + 1;
[a.c:5:5] z = _1;
[a.c:6:1] return;
}
;; Function g (g, funcdef_no=1, decl_uid=1949, cgraph_uid=2, symbol_order=2)
...
a.c: In function ‘g’:
a.c:5:9: warning: ‘x’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
5 | z = i + 1;
| ~~^~~
a.c:10:7: note: ‘x’ was declared here
10 | int x;
| ^
void g (int a, int b, int c)
{
int x;
_Bool _1;
_Bool _2;
_Bool _3;
_Bool _4;
_Bool _5;
int _14;
[local count: 1073741824]:
[a.c:11:7] _1 = a_8(D) != 0;
[a.c:11:9] _2 = b_9(D) != 0;
[a.c:11:9] _3 = _1 & _2;
[a.c:11:6] if (_3 != 0)
goto ; [50.00%]
else
goto ; [50.00%]
[local count: 536870912]:
goto ; [100.00%]
[local count: 536870913]:
[a.c:12:7] x_11 = a_8(D) + b_9(D);
[local count: 1073741824]:
# x_6 = PHI
[a.c:14:9] _4 = c_12(D) != 0;
[a.c:14:9] _5 = _2 & _4;
[a.c:14:6] if (_5 != 0)
goto ; [50.00%]
else
goto ; [50.00%]
[local count: 536870912]:
goto ; [100.00%]
[local count: 536870913]:
[a.c:5:9] _14 = x_6 + 2;
[a.c:5:5] z = _14;
[local count: 1073741824]:
[a.c:16:1] return;
}
*** This bug has been marked as a duplicate of bug 63943 ***
[Bug c++/100101] [11 Regression] ICE with -Wzero-as-null-pointer-constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100101 --- Comment #3 from Jakub Jelinek --- In particular it is the TYPENAME_TYPE type seen in bar's noexcept expression. Does find_typenames_r ever want to walk into expressions? I.e. couldn't the fix be if (EXPR_P (*tp)) *walk_subtrees = 0; ?
[Bug fortran/100103] New: Automatic reallocation fails inside select rank
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100103 Bug ID: 100103 Summary: Automatic reallocation fails inside select rank Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jrfsousa at gmail dot com Target Milestone: --- Created attachment 50606 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50606&action=edit Fortran code showing problem Hi All! Automatic reallocation on intrinsic assignment fails inside select rank construct. Seen on: GNU Fortran (GCC) 11.0.1 20210415 (experimental) GNU Fortran (GCC) 10.3.1 20210415 Thank you very much. Best regards, José Rui
[Bug tree-optimization/70392] [openacc] inconsistent line numbers in uninitialised warnings for if clause
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70392 Martin Sebor changed: What|Removed |Added Last reconfirmed|2017-12-30 00:00:00 |2021-4-15 See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=81714 Known to fail||10.2.0, 11.0, 6.3.0, 7.0.1, ||8.3.0, 9.3.0 CC||msebor at gcc dot gnu.org --- Comment #5 from Martin Sebor --- Reconfirmed with GCC 11. The cases in I. comment #0 are also the subject of pr81714 so let's use this to track just the openacc subset.
[Bug libstdc++/96657] [9/10 Regression] libsupc++.a missing required functions from src/c++98/atomicity.cc when atomic builtins are not supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96657 Jonathan Wakely changed: What|Removed |Added Summary|[9/10/11 Regression]|[9/10 Regression] |libsupc++.a missing |libsupc++.a missing |required functions from |required functions from |src/c++98/atomicity.cc when |src/c++98/atomicity.cc when |atomic builtins are not |atomic builtins are not |supported |supported --- Comment #6 from Jonathan Wakely --- Fixed on trunk. Backports to follow.
[Bug jit/100096] libgccjit.so.0: Cannot write-enable text segment: Permission denied on NetBSD 9.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100096 --- Comment #15 from Sascha Wilde --- (In reply to Jakub Jelinek from comment #13) > readelf -wi libgccjit.so.0 | grep DW_AT_producer | grep -v 'fPIC\|fpic' FWIW, I had the command running for quite some while without spotting any line not containing -fPIC -- but these might still come though... (In reply to Jakub Jelinek from comment #14) > Though, DW_AT_producer lines don't really provide the filename and comp_dir, > so guess what I need is better > readelf -wi libgccjit.so.0 | grep -A4 DW_AT_producer | bzip2 -9 > output. Ill provide you with the output. Please allow me some time, as this really runs _long_ on the system in question (a small Atom CPU N270). I hope to provide the output tomorrow...
[Bug libstdc++/64735] std::future broken on armel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64735 --- Comment #14 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:6c0c7fc6236470a533675cd3cd1ebb1cc3dd112c commit r11-8198-g6c0c7fc6236470a533675cd3cd1ebb1cc3dd112c Author: Jonathan Wakely Date: Wed Apr 14 20:48:54 2021 +0100 libstdc++: Move atomic functions to libsupc++ [PR 96657] The changes for PR libstdc++/64735 mean that libsupc++ function might now depend on the __exchange_and_add and __atomic_add functions defined in config/cpu/*/atomicity.h which is not compiled into libsupc++. This causes a link failure for some targets when trying to use libsupc++ without the rest of libstdc++. This patch simply moves the definitions of those functions into libsupc++ so that they are available there. libstdc++-v3/ChangeLog: PR libstdc++/96657 * libsupc++/Makefile.am: Add atomicity.cc here. * src/c++98/Makefile.am: Remove it from here. * libsupc++/Makefile.in: Regenerate. * src/c++98/Makefile.in: Regenerate. * testsuite/18_support/exception_ptr/96657.cc: New test.
[Bug libstdc++/96657] [9/10/11 Regression] libsupc++.a missing required functions from src/c++98/atomicity.cc when atomic builtins are not supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96657 --- Comment #5 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:6c0c7fc6236470a533675cd3cd1ebb1cc3dd112c commit r11-8198-g6c0c7fc6236470a533675cd3cd1ebb1cc3dd112c Author: Jonathan Wakely Date: Wed Apr 14 20:48:54 2021 +0100 libstdc++: Move atomic functions to libsupc++ [PR 96657] The changes for PR libstdc++/64735 mean that libsupc++ function might now depend on the __exchange_and_add and __atomic_add functions defined in config/cpu/*/atomicity.h which is not compiled into libsupc++. This causes a link failure for some targets when trying to use libsupc++ without the rest of libstdc++. This patch simply moves the definitions of those functions into libsupc++ so that they are available there. libstdc++-v3/ChangeLog: PR libstdc++/96657 * libsupc++/Makefile.am: Add atomicity.cc here. * src/c++98/Makefile.am: Remove it from here. * libsupc++/Makefile.in: Regenerate. * src/c++98/Makefile.in: Regenerate. * testsuite/18_support/exception_ptr/96657.cc: New test.
[Bug tree-optimization/100102] ICE in tsubst, at cp/pt.c:15310
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100102 --- Comment #1 from Erik Schnetter --- Created attachment 50605 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50605&action=edit Compressed preprocessed source code
[Bug tree-optimization/100102] New: ICE in tsubst, at cp/pt.c:15310
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100102 Bug ID: 100102 Summary: ICE in tsubst, at cp/pt.c:15310 Product: gcc Version: 10.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: schnetter at gmail dot com Target Milestone: --- I am using GCC 10.3.0 on x86_64 GNU/Linux. GCC was built via Spack, and is called from nvcc. I encounter the following ICE: cd /tmp/eschnetter/spack-stage/spack-stage-amrex-21.04-eiivnj5bgmpnqg6o7ofgmy4yvdfgxasa/spack-build-eiivnj5/Src && /home/eschnetter/src/CarpetX/spack/opt/spack/linux-ubuntu18.04-skylake_avx512/gcc-10.3.0/cuda-11.2.2-jbyezwujy3vielujb4xz3izwi6q36jnb/bin/nvcc -forward-unknown-to-host-compiler -ccbin=/home/eschnetter/src/CarpetX/Cactus/view-cuda-compilers/bin/g++ -Damrex_EXPORTS -I/tmp/eschnetter/spack-stage/spack-stage-amrex-21.04-eiivnj5bgmpnqg6o7ofgmy4yvdfgxasa/spack-src/Src/Base -I/tmp/eschnetter/spack-stage/spack-stage-amrex-21.04-eiivnj5bgmpnqg6o7ofgmy4yvdfgxasa/spack-src/Src/Boundary -I/tmp/eschnetter/spack-stage/spack-stage-amrex-21.04-eiivnj5bgmpnqg6o7ofgmy4yvdfgxasa/spack-src/Src/AmrCore -I/tmp/eschnetter/spack-stage/spack-stage-amrex-21.04-eiivnj5bgmpnqg6o7ofgmy4yvdfgxasa/spack-src/Src/Amr -I/tmp/eschnetter/spack-stage/spack-stage-amrex-21.04-eiivnj5bgmpnqg6o7ofgmy4yvdfgxasa/spack-src/Src/LinearSolvers/MLMG -I/tmp/eschnetter/spack-stage/spack-stage-amrex-21.04-eiivnj5bgmpnqg6o7ofgmy4yvdfgxasa/spack-src/Src/LinearSolvers/Projections -I/tmp/eschnetter/spack-stage/spack-stage-amrex-21.04-eiivnj5bgmpnqg6o7ofgmy4yvdfgxasa/spack-src/Src/Particle -I/tmp/eschnetter/spack-stage/spack-stage-amrex-21.04-eiivnj5bgmpnqg6o7ofgmy4yvdfgxasa/spack-build-eiivnj5 -isystem=/home/eschnetter/src/CarpetX/spack/opt/spack/linux-ubuntu18.04-skylake_avx512/gcc-10.3.0/openmpi-4.0.5-jl7qr7jpt3fe6z5rdfkgj2n4t5b4xbdn/include -isystem=/home/eschnetter/src/CarpetX/spack/opt/spack/linux-ubuntu18.04-skylake_avx512/gcc-10.3.0/hdf5-1.10.7-gkflrn3su7geakoyly56sqebg2pqa2yr/include -isystem=/home/eschnetter/src/CarpetX/spack/opt/spack/linux-ubuntu18.04-skylake_avx512/gcc-10.3.0/zlib-1.2.11-dd2emzewyp4o4c22f3niqq3dyhjhqkzs/include -m64 --expt-relaxed-constexpr --expt-extended-lambda -Wno-deprecated-gpu-targets -gencode=arch=compute_75,code=sm_75 -maxrregcount=255 -Xcudafe --diag_suppress=esa_on_defaulted_function_ignored --use_fast_math -Xcudafe --display_error_number --Wext-lambda-captures-this --Werror ext-lambda-captures-this --Werror cross-execution-space-call --generate-line-info --source-in-ptx -O2 -g -DNDEBUG -Xcompiler=-fPIC -Xcompiler=-fopenmp -Xcompiler=-Werror=return-type -Xcompiler -pthread -std=c++14 -MD -MT Src/CMakeFiles/amrex.dir/Base/AMReX_BlockMutex.cpp.o -MF CMakeFiles/amrex.dir/Base/AMReX_BlockMutex.cpp.o.d -x cu -dc /tmp/eschnetter/spack-stage/spack-stage-amrex-21.04-eiivnj5bgmpnqg6o7ofgmy4yvdfgxasa/spack-src/Src/Base/AMReX_BlockMutex.cpp -o CMakeFiles/amrex.dir/Base/AMReX_BlockMutex.cpp.o /home/eschnetter/src/CarpetX/spack/opt/spack/linux-ubuntu18.04-skylake_avx512/gcc-10.1.0/gcc-10.3.0-74t7ecp2jgn6myrtnrziqo5hg6bncbb4/include/c++/10.3.0/chrono: In substitution of 'template template using __is_harmonic = std::__bool_constant<(std::ratio<((_Period2::num / std::chrono::duration<_Rep, _Period>::_S_gcd(_Period2::num, _Period::num)) * (_Period::den / std::chrono::duration<_Rep, _Period>::_S_gcd(_Period2::den, _Period::den))), ((_Period2::den / std::chrono::duration<_Rep, _Period>::_S_gcd(_Period2::den, _Period::den)) * (_Period::num / std::chrono::duration<_Rep, _Period>::_S_gcd(_Period2::num, _Period::num)))>::den == 1)> [with _Period2 = _Period2; _Rep = _Rep; _Period = _Period]': /home/eschnetter/src/CarpetX/spack/opt/spack/linux-ubuntu18.04-skylake_avx512/gcc-10.1.0/gcc-10.3.0-74t7ecp2jgn6myrtnrziqo5hg6bncbb4/include/c++/10.3.0/chrono:473:154: required from here /home/eschnetter/src/CarpetX/spack/opt/spack/linux-ubuntu18.04-skylake_avx512/gcc-10.1.0/gcc-10.3.0-74t7ecp2jgn6myrtnrziqo5hg6bncbb4/include/c++/10.3.0/chrono:428:27: internal compiler error: Segmentation fault 428 | _S_gcd(intmax_t __m, intmax_t __n) noexcept | ^~ 0xc5d6af crash_signal /tmp/eschnetter/spack-stage/spack-stage-gcc-10.3.0-74t7ecp2jgn6myrtnrziqo5hg6bncbb4/spack-src/gcc/toplev.c:328 0x754d6d tsubst(tree_node*, tree_node*, int, tree_node*) /tmp/eschnetter/spack-stage/spack-stage-gcc-10.3.0-74t7ecp2jgn6myrtnrziqo5hg6bncbb4/spack-src/gcc/cp/pt.c:15310 0x767d76 tsubst_template_args(tree_node*, tree_node*, int, tree_node*) /tmp/eschnetter/spack-stage/spack-stage-gcc-10.3.0-74t7ecp2jgn6myrtnrziqo5hg6bncbb4/spack-src/gcc/cp/pt.c:13225 0x760766 tsubst_aggr_type /tmp/eschnetter/spack-stage/spack-stage-gcc-10.3.0-74t7ecp2jgn6myrtnrziqo5hg6bncbb4/spack-src/gcc/cp/pt.c:13428 0x76aa5f tsubst_function_decl /tmp/eschnetter/spack-stage/spack-st
[Bug tree-optimization/99971] GCC generates partially vectorized and scalar code at once
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99971 --- Comment #6 from andysem at mail dot ru --- Hmm, it looks like the original code has changed enough so that the problem no longer reproduces, with or without __restrict__. I don't have the older version of the code, so I can't tell what changed exactly. Data alignment most probably did change, but data layout of A (its equivalent in the original code) as well as the operation on it certainly didn't. Sorry for the confusion.
[Bug c++/100101] [11 Regression] ICE with -Wzero-as-null-pointer-constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100101 --- Comment #2 from Jakub Jelinek --- So maybe find_typenames doesn't want to walk into TYPE_RAISES_EXCEPTIONS?
[Bug fortran/100094] Undefined pointers have incorrect rank when using optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100094 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #1 from kargl at gcc dot gnu.org --- Isn't the code invalid Fortran because it references an undefined pointer? If yes, the compiler is allows to do whatever it wants with the code.
[Bug c++/100101] [11 Regression] ICE with -Wzero-as-null-pointer-constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100101 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P1 CC||jakub at gcc dot gnu.org
[Bug c++/100101] [11 Regression] ICE with -Wzero-as-null-pointer-constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100101 Patrick Palka changed: What|Removed |Added CC||jason at gcc dot gnu.org, ||ppalka at gcc dot gnu.org Status|UNCONFIRMED |NEW Target Milestone|--- |11.0 Last reconfirmed||2021-04-15 Ever confirmed|0 |1 --- Comment #1 from Patrick Palka --- Seems to have started with r11-7953.
[Bug target/99767] [9/10/11 Regression] ICE in expand_direct_optab_fn, at internal-fn.c:3360
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99767 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #6 from Jakub Jelinek --- Created attachment 50604 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50604&action=edit gcc11-pr99767.patch Untested fix that does that.
[Bug c++/100091] [11 Regression] decltype([]{}) rejected as a default template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100091 Jason Merrill changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug jit/100096] libgccjit.so.0: Cannot write-enable text segment: Permission denied on NetBSD 9.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100096 --- Comment #14 from Jakub Jelinek --- Though, DW_AT_producer lines don't really provide the filename and comp_dir, so guess what I need is better readelf -wi libgccjit.so.0 | grep -A4 DW_AT_producer | bzip2 -9 output.
[Bug jit/100096] libgccjit.so.0: Cannot write-enable text segment: Permission denied on NetBSD 9.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100096 --- Comment #13 from Jakub Jelinek --- The important question is what TUs are compiled without -fPIC/-fpic, those with those options are fine. So perhaps readelf -wi libgccjit.so.0 | grep DW_AT_producer | grep -v 'fPIC\|fpic' ?
[Bug target/99767] [9/10/11 Regression] ICE in expand_direct_optab_fn, at internal-fn.c:3360
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99767
--- Comment #5 from Jakub Jelinek ---
Note, we have already:
/* Stub out scalar statements that must not survive vectorization.
Doing this here helps with grouped statements, or statements that
are involved in patterns. */
for (gimple_stmt_iterator gsi = gsi_start_bb (bb);
!gsi_end_p (gsi); gsi_next (&gsi))
{
gcall *call = dyn_cast (gsi_stmt (gsi));
if (call && gimple_call_internal_p (call, IFN_MASK_LOAD))
{
tree lhs = gimple_get_lhs (call);
if (!VECTOR_TYPE_P (TREE_TYPE (lhs)))
{
tree zero = build_zero_cst (TREE_TYPE (lhs));
gimple *new_stmt = gimple_build_assign (lhs, zero);
gsi_replace (&gsi, new_stmt, true);
}
}
}
in tree-vect-loop.c.
Perhaps we should handle similarly IFN_COND_* ?
Instead of using zero for those perhaps we could just use the last argument of
those calls (i.e. the ELSE part).
[Bug jit/100096] libgccjit.so.0: Cannot write-enable text segment: Permission denied on NetBSD 9.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100096 --- Comment #12 from Sascha Wilde --- (In reply to Jakub Jelinek from comment #9) > Perhaps > readelf -wi libgccjit.so.0 | grep DW_AT_producer > would make it clearer on what is and what is not built with -fpic/-fPIC. This runs quite long and only yields lines like: DW_AT_producer: (indirect string, offset: 0x155c1): GNU C++14 10.2.0 -mtune=generic -march=i486 -g -O2 -fPIC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables <30387> DW_AT_producer: (indirect string, offset: 0x155c1): GNU C++14 10.2.0 -mtune=generic -march=i486 -g -O2 -fPIC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables <3ccf4> DW_AT_producer: (indirect string, offset: 0x155c1): GNU C++14 10.2.0 -mtune=generic -march=i486 -g -O2 -fPIC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables [...] If this is really helpful to you, I'm fully willing to let it run through all the way and provide you with the complete output, of course.
[Bug c++/99387] ICE when mixing CNTTP with deduction guides
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99387
--- Comment #3 from Patrick Palka ---
Reduced:
template struct A { };
template struct B { };
template class Tmpl, Tmpl V>
void f (A);
int main() {
A{}> x;
f(x);
}
[Bug c++/100101] New: [11 Regression] ICE with -Wzero-as-null-pointer-constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100101
Bug ID: 100101
Summary: [11 Regression] ICE with
-Wzero-as-null-pointer-constant
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: reichelt at gcc dot gnu.org
Target Milestone: ---
Compiling the following valid code snippet with
"-Wzero-as-null-pointer-constant" triggers an assertion on trunk.
This is a recent regression from within the last month.
==
template struct A
{
template static char foo(U*, int* = 0);
static const bool value = sizeof(foo(static_cast(nullptr))) > 0;
};
template struct B
{
static const bool value = b;
};
template struct C
{
typedef B::value> type;
};
template
void bar() noexcept(A::value && C::type::value) {}
void baz()
{
bar();
}
==
'
Internal compiler error: Error reporting routines re-entered.
0x8cfbf8 convert_default_arg(tree_node*, tree_node*, tree_node*, int, int)
../../gcc/gcc/cp/call.c:8348
0x8dc177 build_over_call
../../gcc/gcc/cp/call.c:9230
0x8da248 build_new_method_call_1
../../gcc/gcc/cp/call.c:10783
0x8db2af build_new_method_call(tree_node*, tree_node*, vec**, tree_node*, int, tree_node**, int)
../../gcc/gcc/cp/call.c:10858
0xae76dd finish_call_expr(tree_node*, vec**, bool,
bool, int)
../../gcc/gcc/cp/semantics.c:2751
0xa99115 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:20484
0xa969ec tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:19958
0xa957f3 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:19876
0xaa0e48 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:19164
0x06 instantiate_decl(tree_node*, bool, bool)
../../gcc/gcc/cp/pt.c:26117
0x98fc9a maybe_instantiate_decl(tree_node*)
../../gcc/gcc/cp/decl2.c:5460
0x990ff8 maybe_instantiate_decl(tree_node*)
../../gcc/gcc/cp/decl2.c:5663
0x990ff8 mark_used(tree_node*, int)
../../gcc/gcc/cp/decl2.c:5689
0xa951f0 tsubst_qualified_id
../../gcc/gcc/cp/pt.c:16466
0xa96ee8 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:19914
0xaa0e48 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:19164
0xab59ce tsubst_template_args(tree_node*, tree_node*, int, tree_node*)
../../gcc/gcc/cp/pt.c:13384
0xabed23 tsubst_aggr_type
../../gcc/gcc/cp/pt.c:13587
0xa9dd10 tsubst_decl
../../gcc/gcc/cp/pt.c:14847
0xacc3dd instantiate_class_template_1
../../gcc/gcc/cp/pt.c:12031
Please submit a full bug report, [etc.]
[Bug jit/100096] libgccjit.so.0: Cannot write-enable text segment: Permission denied on NetBSD 9.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100096 --- Comment #11 from Sascha Wilde --- Created attachment 50603 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50603&action=edit tut01-hello-world log output
[Bug jit/100096] libgccjit.so.0: Cannot write-enable text segment: Permission denied on NetBSD 9.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100096 --- Comment #10 from Sascha Wilde --- (In reply to David Malcolm from comment #8) > It would be good to know exactly where that error message is being emitted. > > If you add: > gcc_jit_context_set_logfile (ctxt, stderr, 0, 0); > to the test code (e.g. immediately after the call to > gcc_jit_context_acquire), libgccjit ought to spew out a copious amount of > logging (see > https://gcc.gnu.org/onlinedocs/jit/internals/index.html#example-of-log-file) > > Can you attach the log you get please? With security.pax.mprotect.global=1 it produces no extra output. I'll attach the output produced when security.pax.mprotect.global is disabled.
[Bug c++/99963] [11 Regression] [concepts] template vs concept auto reports ambiguous overload
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99963 --- Comment #3 from Luke Dalessandro --- I understand. Thank you (I've forwarded this on to clang, which _does_ accept the ambiguous form).
[Bug target/100067] Unexpected warning for -mcpu=neoverse-n1 when configured with --with-fpu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100067 --- Comment #5 from Christophe Lyon --- (In reply to Richard Earnshaw from comment #4) > (In reply to Christophe Lyon from comment #3) > > Unfortunately this is causing many regressions in the GCC testsuite. > > Sigh! I'm not entirely surprised. I suspect most of this is testisms, > though. > :-) Yes, probably. > > --target arm-none-linux-gnueabi > > --with-mode arm > > --with-cpu cortex-a9 > > --with-fpu default > > Dejagnu flags: -march=armv5t > > gcc.target/arm/aes-fuse-1.c is compiled with > > > > -march=armv5t -mfpu=crypto-neon-fp-armv8 -mfloat-abi=softfp -mcpu=cortex-a72 > > cc1: warning: switch '-mcpu=cortex-a72' conflicts with switch > > '-march=armv5t' > > The warning is correct. That's a stupid combination to pass to the compiler > (arch=armv5 and cpu=). What's less clear is why this wasn't > happening before. Indeed. I just checked the command line was the same before your patch (i.e. your patch has no impact on the effective-targets that could change the flags used) FTR, even before your patch there were several such annoying warnings.
[Bug jit/100096] libgccjit.so.0: Cannot write-enable text segment: Permission denied on NetBSD 9.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100096 --- Comment #9 from Jakub Jelinek --- So I see 236 R_386_RELATIVE text relocations and 231 other text relocations. Seems the compiler itself is built with -fpic/-fPIC, but some of the libraries that are linked into it are not, e.g. libintl.a, at least parts of libgcc (the dfp stuff), libbacktrace. Perhaps readelf -wi libgccjit.so.0 | grep DW_AT_producer would make it clearer on what is and what is not built with -fpic/-fPIC. On i686-linux I certainly can't reproduce this, there are no text relocations.
[Bug target/100067] Unexpected warning for -mcpu=neoverse-n1 when configured with --with-fpu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100067 --- Comment #4 from Richard Earnshaw --- (In reply to Christophe Lyon from comment #3) > Unfortunately this is causing many regressions in the GCC testsuite. Sigh! I'm not entirely surprised. I suspect most of this is testisms, though. > > For instance: > --target arm-none-linux-gnueabi > --with-mode arm > --with-cpu cortex-a9 > --with-fpu default > gcc.target/arm/armv8_2-fp16-neon-1.c is compiled with > -mfloat-abi=softfp -march=armv8.2-a+fp16 > > /gcc/testsuite/gcc.target/arm/armv8_2-fp16-neon-1.c: In function > 'test_vceqz_16x4': > /gcc/testsuite/gcc.target/arm/armv8_2-fp16-neon-1.c:139:13: warning: > implicit declaration of function 'vceqz_f16'; did you mean 'vceqq_u16'? > [-Wimplicit-function-declaration] > /gcc/testsuite/gcc.target/arm/armv8_2-fp16-neon-1.c:10:25: note: in > definition of macro 'MSTRCAT' > /gcc/testsuite/gcc.target/arm/armv8_2-fp16-neon-1.c:139:1: note: in > expansion of macro 'VCMP1_TEST' > /gcc/testsuite/gcc.target/arm/armv8_2-fp16-neon-1.c:139:13: error: > incompatible types when returning type 'int' but 'uint16x4_t' was expected > [...] It's not obvious what's happening here. I'll look. > > > --target arm-none-linux-gnueabi > --with-mode arm > --with-cpu cortex-a9 > --with-fpu default > Dejagnu flags: -march=armv5t > gcc.target/arm/aes-fuse-1.c is compiled with > > -march=armv5t -mfpu=crypto-neon-fp-armv8 -mfloat-abi=softfp -mcpu=cortex-a72 > cc1: warning: switch '-mcpu=cortex-a72' conflicts with switch '-march=armv5t' The warning is correct. That's a stupid combination to pass to the compiler (arch=armv5 and cpu=). What's less clear is why this wasn't happening before.
[Bug jit/100096] libgccjit.so.0: Cannot write-enable text segment: Permission denied on NetBSD 9.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100096 --- Comment #8 from David Malcolm --- (In reply to Sascha Wilde from comment #6) > However, please note that > "Cannot write-enable text segment: Permission denied" > is the more pressing problem, as it prevents libgccjit to be used > on NetBSD with default security settings. It would be good to know exactly where that error message is being emitted. If you add: gcc_jit_context_set_logfile (ctxt, stderr, 0, 0); to the test code (e.g. immediately after the call to gcc_jit_context_acquire), libgccjit ought to spew out a copious amount of logging (see https://gcc.gnu.org/onlinedocs/jit/internals/index.html#example-of-log-file) Can you attach the log you get please?
[Bug jit/100096] libgccjit.so.0: Cannot write-enable text segment: Permission denied on NetBSD 9.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100096 --- Comment #7 from Andreas Schwab --- That's just the consequence of text relocations.
[Bug jit/100096] libgccjit.so.0: Cannot write-enable text segment: Permission denied on NetBSD 9.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100096 --- Comment #6 from Sascha Wilde --- However, please note that "Cannot write-enable text segment: Permission denied" is the more pressing problem, as it prevents libgccjit to be used on NetBSD with default security settings.
[Bug jit/100096] libgccjit.so.0: Cannot write-enable text segment: Permission denied on NetBSD 9.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100096 --- Comment #5 from Sascha Wilde --- (In reply to Jakub Jelinek from comment #3) > So, how many text relocations do you see? > E.g. readelf -Wa libgccjit.so.0 output attached here would be useful. I attached the requested output (its nearly 9MiB uncompressed, so used bzip2 to stay below the file size limit of 1000K)
[Bug c++/100091] [11 Regression] decltype([]{}) rejected as a default template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100091
--- Comment #4 from Pilar Latiesa ---
> Of course such use of a lambda is quite pointless
Not as pointless as it might appear. This defaulted template parameter enables
a form of stateful metaprogramming:
#include
template
class T {};
static_assert(!std::is_same_v, T>); // passes with GCC 10
I don’t know if that is valid C++, and would love to know whether or not it is.
On the other hand, sometimes it is convenient to use lambdas this way:
template
class my_functor
{
[[no_unique_address]] TOp const Op = {};
};
