[Bug tree-optimization/99856] [9/10/11 Regression] Alpha Compositing auto vectorization regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99856 Richard Biener changed: What|Removed |Added Version|unknown |9.3.0 Priority|P3 |P2 Status|NEW |ASSIGNED Target Milestone|--- |9.4 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Target||x86_64-*-* --- Comment #2 from Richard Biener --- t.c:16:14: note: op template: patt_266 = () _8; t.c:16:14: note:stmt 0 patt_266 = () _8; t.c:16:14: note:stmt 1 patt_243 = () _28; t.c:16:14: note:stmt 2 patt_220 = () _46; t.c:16:14: note:stmt 3 patt_198 = () _60; t.c:16:14: note:children 0x38267e0 WTF t.c:16:14: note: ==> examining pattern def stmt: patt_266 = () _8; t.c:16:14: note: precomputed vectype: vector(8) unsigned int t.c:16:14: note: get vectype for smallest scalar type: unsigned char the dumps do not show who creates this 17 bit precision temporary, but clearly this causes t.c:16:14: note: ==> examining statement: patt_266 = () _8; t.c:16:14: note: vect_is_simple_use: operand *_7, type of def: internal t.c:16:14: missed: type conversion to/from bit-precision unsupported. t.c:16:14: missed: bit-precision arithmetic not supported. t.c:16:14: note: vect_is_simple_use: operand *_7, type of def: internal t.c:11:1: missed: not vectorized: relevant stmt not supported: patt_266 = () _8; t.c:16:14: note: removing SLP instance operations starting from: *_20 = _21; t.c:16:14: missed: unsupported SLP instances t.c:16:14: note: re-trying with SLP disabled ... t.c:16:14: note: ==> examining statement: patt_266 = () _8; t.c:16:14: note: vect_is_simple_use: operand *_7, type of def: internal t.c:16:14: note: vect_is_simple_use: vectype const vector(32) unsigned char t.c:16:14: missed: type conversion to/from bit-precision unsupported. t.c:16:14: missed: bit-precision arithmetic not supported. t.c:16:14: note: vect_is_simple_use: operand *_7, type of def: internal t.c:16:14: note: vect_is_simple_use: vectype const vector(32) unsigned char t.c:11:1: missed: not vectorized: relevant stmt not supported: patt_266 = () _8; t.c:16:14: missed: bad operation or unsupported loop bound. Breakpoint 6, build_nonstandard_integer_type (precision=17, unsignedp=1) at /home/rguenther/src/gcc3/gcc/tree.c:8090 8090 if (unsignedp) (gdb) bt #0 build_nonstandard_integer_type (precision=17, unsignedp=1) at /home/rguenther/src/gcc3/gcc/tree.c:8090 #1 0x024461ab in vect_recog_over_widening_pattern (vinfo=0x385bf60, last_stmt_info=0x38d1130, type_out=0x7fffc7d0) at /home/rguenther/src/gcc3/gcc/tree-vect-patterns.c:1719 #2 0x02453c10 in vect_pattern_recog_1 (vinfo=0x385bf60, recog_func=0x359bf80 , stmt_info=0x38d1130) at /home/rguenther/src/gcc3/gcc/tree-vect-patterns.c:5463 #3 0x02453fee in vect_pattern_recog (vinfo=0x385bf60) at /home/rguenther/src/gcc3/gcc/tree-vect-patterns.c:5603 where (gdb) p last_stmt_info->min_output_precision $9 = 17 (gdb) p last_stmt_info->operation_precision $10 = 8 and the min_output_precision is determined from the defs uses min_input_precision. I didn't trace further where we arrive at '17', but diff --git a/gcc/tree-vect-patterns.c b/gcc/tree-vect-patterns.c index b575b456301..803de3fc287 100644 --- a/gcc/tree-vect-patterns.c +++ b/gcc/tree-vect-patterns.c @@ -1705,6 +1705,7 @@ vect_recog_over_widening_pattern (vec_info *vinfo, /* Apply the minimum efficient precision we just calculated. */ if (new_precision < min_precision) new_precision = min_precision; + new_precision = vect_element_precision (new_precision); if (new_precision >= TYPE_PRECISION (type)) return NULL; restores vectorization.
[Bug c++/99858] Wrong throw-expression behaviour with reference to pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99858 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2021-04-01 Ever confirmed|0 |1 Keywords||wrong-code --- Comment #1 from Richard Biener --- clang behaves as you expect, ICC behaves the same as GCC so it's unclear (it might be that the ABI makes GCC/ICC behavior more natural to follow).
[Bug c++/99861] [modules] ICE in hashtab_chk_error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99861 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #1 from Martin Liška --- ... > /usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header algorithm I can confirm that, but with: --param=hash-table-verification-limit=1000
[Bug c++/99861] [modules] ICE in hashtab_chk_error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99861 Martin Liška changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2021-04-01
[Bug ipa/99862] New: [meta-issue] various missed optimizations for dead code elimination
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99862
Bug ID: 99862
Summary: [meta-issue] various missed optimizations for dead
code elimination
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: zhendong.su at inf dot ethz.ch
CC: marxin at gcc dot gnu.org
Target Milestone: ---
[561] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/11.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--prefix=/local/suz-local/software/local/gcc-trunk --enable-languages=c,c++
--disable-werror --enable-multilib --with-system-zlib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.1 20210401 (experimental) [master revision
e4bb1bd60a9:c23a685bf70:95d217ab52d31dc06fda42fc136dea165909e88b] (GCC)
[562] %
[562] % gcctk -O1 -S -o O1.s small.c
[563] % gcctk -O3 -S -o O3.s small.c
[564] %
[564] % wc O1.s O3.s
23 45 420 O1.s
39 74 669 O3.s
62 119 1089 total
[565] %
[565] % grep foo O1.s
[566] % grep foo O3.s
callfoo
[567] %
[567] % cat small.c
extern void foo(void);
static int a, b;
static int c() {
foo();
while (1)
while (b)
foo();
}
void d() {
if (a)
c();
}
int main() {
d();
return 0;
}
[Bug ipa/99862] [meta-issue] various missed optimizations for dead code elimination
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99862
--- Comment #1 from Zhendong Su ---
[578] % gcctk -O1 -S -o O1.s small.c
[579] % gcctk -O3 -S -o O3.s small.c
[580] %
[580] % wc O1.s O3.s
22 43 410 O1.s
37 77 682 O3.s
59 120 1092 total
[581] %
[581] % grep foo O1.s
[582] % grep foo O3.s
callfoo
[583] %
[583] % cat small.c
extern void foo(void);
static int a, b;
static void c() {
if (a) {
foo();
for (; b < 1; b++)
;
}
}
int main() {
c();
c();
return 0;
}
[Bug ipa/99862] [meta-issue] various missed optimizations for dead code elimination
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99862
--- Comment #2 from Zhendong Su ---
[659] % gcctk -O1 -S -o O1.s small.c
[660] % gcctk -O3 -S -o O3.s small.c
[661] %
[661] % wc O1.s O3.s
40 86 599 O1.s
68 138 1047 O3.s
108 224 1646 total
[662] %
[662] % grep foo O1.s
[663] % grep foo O3.s
callfoo
[664] %
[664] % cat small.c
extern void foo(void);
int a, b, *c;
static void d(int f) {
if (f)
foo();
}
static int e(int f) {
int g[] = {2, 8, 2, 8, 2, 8, 2, 8, 2, 8, 2};
int h[60];
h[0] = g != c;
if (b)
while (a) {
int *i[1] = {&h[6]};
}
return f;
}
static int *j(int *p) { return 0; }
int main () {
int m = e(0);
d(m);
int l[8];
if (j(l))
while (1)
;
return 0;
}
[Bug tree-optimization/97009] [9/10/11 Regression] Inlining with non-standard selected_int_kind leads to errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97009 --- Comment #9 from CVS Commits --- The master branch has been updated by Martin Jambor : https://gcc.gnu.org/g:19d71674616e6494a60432a2a28adcd762a6c877 commit r11-7944-g19d71674616e6494a60432a2a28adcd762a6c877 Author: Martin Jambor Date: Thu Apr 1 10:12:23 2021 +0200 sra: Fix bug in grp_write propagation (PR 97009) SRA represents parts of aggregates which are arrays accessed with unknown index as "unscalarizable regions." When there are two such regions one within another and the outer is only read whereas the inner is written to, SRA fails to propagate that write information across assignments. This means that a second aggregate can contain data while SRA thinks it does not and the pass can wrongly eliminate big chunks of assignment from that second aggregate into a third aggregate, which is what happens in PR 97009. Fixed by checking all children of unscalariable accesses for the grp_write flag. gcc/ChangeLog: 2021-03-31 Martin Jambor PR tree-optimization/97009 * tree-sra.c (access_or_its_child_written): New function. (propagate_subaccesses_from_rhs): Use it instead of a simple grp_write test. gcc/testsuite/ChangeLog: 2021-03-31 Martin Jambor PR tree-optimization/97009 * gcc.dg/tree-ssa/pr97009.c: New test.
[Bug tree-optimization/99856] [9/10/11 Regression] Alpha Compositing auto vectorization regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99856 --- Comment #3 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:b75c4e1384c021ca94fc8e8db8e517e802b820f3 commit r11-7945-gb75c4e1384c021ca94fc8e8db8e517e802b820f3 Author: Richard Biener Date: Thu Apr 1 09:29:14 2021 +0200 tree-optimization/99856 - fix overwideing pattern creation This fixes an omission of promoting a bit-precision required precision to a vector element precision. 2021-04-01 Richard Biener PR tree-optimization/99856 * tree-vect-patterns.c (vect_recog_over_widening_pattern): Promote precision to vector element precision. * gcc.dg/vect/pr99856.c: New testcase.
[Bug target/99863] New: [10/11 Regression] wrong code with -O -fno-tree-forwprop -mno-sse2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99863 Bug ID: 99863 Summary: [10/11 Regression] wrong code with -O -fno-tree-forwprop -mno-sse2 Product: gcc Version: 11.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Target Milestone: --- Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 50493 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50493&action=edit reduced testcase Output: $ x86_64-pc-linux-gnu-gcc -O -fno-tree-forwprop -mno-sse2 testcase.c -Wno-psabi $ ./a.out Aborted $ x86_64-pc-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r11-7937-20210331154556-geadf009b229-checking-yes-rtl-df-extra-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/11.0.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld --with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-r11-7937-20210331154556-geadf009b229-checking-yes-rtl-df-extra-amd64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 11.0.1 20210331 (experimental) (GCC)
[Bug tree-optimization/96573] [10/11 Regression] Regression in optimization on x86-64 with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96573 --- Comment #4 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:5b9a65ecbeb22ef6dd3344baae97f85b645522e3 commit r11-7946-g5b9a65ecbeb22ef6dd3344baae97f85b645522e3 Author: Jakub Jelinek Date: Thu Apr 1 10:51:03 2021 +0200 bswap: Handle bswapping of pointers [PR96573] In GCC8/9 we used to optimize this into a bswap, but we no longer do. Handling byteswapping of pointers is easy, all we need is to allow them, for the __builtin_bswap* we already use TYPE_PRECISION to determine the precision and we cast the operand and result to the correct type if they aren't uselessly convertible to what the builtin expects. 2021-04-01 Jakub Jelinek PR tree-optimization/96573 * gimple-ssa-store-merging.c (init_symbolic_number): Handle also pointer types. * gcc.dg/pr96573.c: New test.
[Bug target/99863] [10/11 Regression] wrong code with -O -fno-tree-forwprop -mno-sse2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99863 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Target Milestone|--- |10.3 Ever confirmed|0 |1 Keywords||needs-bisection Last reconfirmed||2021-04-01 Priority|P3 |P2 --- Comment #1 from Richard Biener --- Confirmed. It's a bit hard to follow what goes wrong (didn't yet spot it).
[Bug target/99863] [10/11 Regression] wrong code with -O -fno-tree-forwprop -mno-sse2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99863
--- Comment #2 from Richard Biener ---
Also time to fix this stupid veclower behavior:
_7 = (unsigned int) _14;
_5 = {_7, _7, _7, _7, _7, _7, _7, _7, _7, _7, _7, _7, _7, _7, _7, _7};
- v512u32_0_16 = _5 * v512u32_0_15(D);
+ _53 = {_7, _7, _7, _7, _7, _7, _7, _7, _7, _7, _7, _7, _7, _7, _7, _7};
+ _54 = BIT_FIELD_REF <_53, 32, 0>;
+ _55 = BIT_FIELD_REF ;
+ _56 = _54 * _55;
+ _57 = {_7, _7, _7, _7, _7, _7, _7, _7, _7, _7, _7, _7, _7, _7, _7, _7};
+ _58 = BIT_FIELD_REF <_57, 32, 32>;
+ _59 = BIT_FIELD_REF ;
+ _60 = _58 * _59;
...
instead of
_5 = {_7, _7, _7, _7, _7, _7, _7, _7, _7, _7, _7, _7, _7, _7, _7, _7};
- v512u32_0_16 = _5 * v512u32_0_15(D);
_54 = BIT_FIELD_REF <_5, 32, 0>;
...
or even better
_5 = {_7, _7, _7, _7, _7, _7, _7, _7, _7, _7, _7, _7, _7, _7, _7, _7};
- v512u32_0_16 = _5 * v512u32_0_15(D);
+ _55 = BIT_FIELD_REF ;
+ _56 = _7 * _55;
it's all "fixed" later by CSE of course.
The error might be involving the clever handling of
- v256u8_r_17 = _8 + _19;
+ _117 = BIT_FIELD_REF <_8, 64, 0>;
+ _118 = BIT_FIELD_REF <_19, 64, 0>;
+ _119 = _117 ^ _118;
+ _120 = _118 & 9187201950435737471;
+ _121 = _117 & 9187201950435737471;
+ _122 = _119 & 9259542123273814144;
+ _123 = _120 + _121;
+ _124 = _122 ^ _123;
+ _125 = BIT_FIELD_REF <_8, 64, 64>;
+ _126 = BIT_FIELD_REF <_19, 64, 64>;
...
+ _149 = {_124, _132, _140, _148};
+ _150 = VIEW_CONVERT_EXPR(_149);
+ v256u8_r_17 = _150;
it's enough to -fdisable-tree-forwprop4 (forwprop after veclower) to make
the problem show up so it might be as well an RTL optimization issue.
[Bug tree-optimization/99856] [9/10 Regression] Alpha Compositing auto vectorization regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99856 --- Comment #4 from CVS Commits --- The releases/gcc-10 branch has been updated by Richard Biener : https://gcc.gnu.org/g:1cfe48d35e31e905632e37ae6a9cb37d35f9a228 commit r10-9649-g1cfe48d35e31e905632e37ae6a9cb37d35f9a228 Author: Richard Biener Date: Thu Apr 1 09:29:14 2021 +0200 tree-optimization/99856 - fix overwideing pattern creation This fixes an omission of promoting a bit-precision required precision to a vector element precision. 2021-04-01 Richard Biener PR tree-optimization/99856 * tree-vect-patterns.c (vect_recog_over_widening_pattern): Promote precision to vector element precision. * gcc.dg/vect/pr99856.c: New testcase.
[Bug c++/99864] New: Abbreviated member function template doesn't compile with default function argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99864
Bug ID: 99864
Summary: Abbreviated member function template doesn't compile
with default function argument
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: stream009 at gmail dot com
Target Milestone: ---
I got a strange compile error when I use abbreviated function template and
default function argument on member function.
Compiler version: gcc 10.2
Compiler Exploer Link: https://godbolt.org/z/7cMTP875E
// begin source
class foo
{
public:
int mem_fn(auto a, int b = 0);
};
inline int foo::
mem_fn(auto a, int b/*= 0*/)
{
return a + b;
}
int main()
{
foo x;
x.mem_fn(1);
}
// end source
// begin error message
16:15: error: call to 'int foo::mem_fn(auto:2, int) [with auto:1 = int]' uses
the default argument for parameter 2, which is not yet defined
16 | x.mem_fn(1);
| ^
// end error message
- It does compile if function definition is in the class definition
(https://godbolt.org/z/T3ncebTqz)
- It does compile if function is not member function
(https://godbolt.org/z/o8Wc98xE4)
- It does compile if member function is not function template
(https://godbolt.org/z/vWTxTbjoY)
- It does compile if member function is not abbreviated template function
(https://godbolt.org/z/qqzK9E6qc)
[Bug tree-optimization/96573] [10 Regression] Regression in optimization on x86-64 with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96573 Jakub Jelinek changed: What|Removed |Added Summary|[10/11 Regression] |[10 Regression] Regression |Regression in optimization |in optimization on x86-64 |on x86-64 with -O3 |with -O3 --- Comment #5 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug tree-optimization/99856] [9 Regression] Alpha Compositing auto vectorization regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99856 --- Comment #5 from CVS Commits --- The releases/gcc-9 branch has been updated by Richard Biener : https://gcc.gnu.org/g:3d705c86c08985af73823b71af21c2ffe2c23758 commit r9-9317-g3d705c86c08985af73823b71af21c2ffe2c23758 Author: Richard Biener Date: Thu Apr 1 09:29:14 2021 +0200 tree-optimization/99856 - fix overwideing pattern creation This fixes an omission of promoting a bit-precision required precision to a vector element precision. 2021-04-01 Richard Biener PR tree-optimization/99856 * tree-vect-patterns.c (vect_recog_over_widening_pattern): Promote precision to vector element precision. * gcc.dg/vect/pr99856.c: New testcase. (cherry picked from commit 1cfe48d35e31e905632e37ae6a9cb37d35f9a228)
[Bug tree-optimization/99856] [9 Regression] Alpha Compositing auto vectorization regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99856 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Richard Biener --- Fixed.
[Bug libstdc++/99865] New: std::filesystem namespace identifiers pollute global namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99865
Bug ID: 99865
Summary: std::filesystem namespace identifiers pollute global
namespace
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: zoid at riseup dot net
Target Milestone: ---
At least two free functions from the std::filesystem namespace resolve without
being scope-resolved. The two I found were std::filesystem::create_directory
and std::filesystem::remove_all. There might be more. I am uncertain if this is
a problem in the library implementation or the compiler itself.
Minimal Reproducible Example:
#include
struct TempDir {
std::filesystem::path const path;
TempDir(std::filesystem::path const& p) : path(p) {
// std::filesystem::create_directory(p); // <-- expected
if (!create_directory(p)) { // <- compiles
throw 0;
}
}
~TempDir() {
// std::filesystem::remove_all(path); // <-- expected
remove_all(path); // <- compiles
}
};
int main() {
// create_directory("bar"); // <- rejected (correctly)
TempDir("foo");
}
Compile with: g++ -Wall -Wextra -pedantic -std=c++17 mre.cpp
Produces zero diagnostics. Compiles binary a.out.
My expectation would have been that the compiler rejected the lines marked with
"compiles". As it does when these identifiers appear directly in main.
Tested with g++ 10.2.1 under both debian and fedora. Output of g++ -v:
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/10/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa:hsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 10.2.1-6'
--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-Km9U7s/gcc-10-10.2.1/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-10-Km9U7s/gcc-10-10.2.1/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.2.1 20210110 (Debian 10.2.1-6)
[Bug libstdc++/99865] std::filesystem namespace identifiers pollute global namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99865 --- Comment #1 from zoid at riseup dot net --- Note: I tried attaching mre.ii generated by -save-temps but its file size of over 1MB was rejected by bugzilla. If the file is required, please advise how I can provide it.
[Bug libstdc++/99865] std::filesystem namespace identifiers pollute global namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99865 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #2 from Andrew Pinski --- This is just ADL (Argument-dependent lookup) and therefor very much valid C++ code. ADL has been a standard part of C++ since the first standard even. See https://en.cppreference.com/w/cpp/language/adl for more examples of ADL
[Bug tree-optimization/97009] [9/10/11 Regression] Inlining with non-standard selected_int_kind leads to errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97009 --- Comment #10 from CVS Commits --- The releases/gcc-10 branch has been updated by Martin Jambor : https://gcc.gnu.org/g:368875572b6b6be75d7cc162797d07e779194fb1 commit r10-9650-g368875572b6b6be75d7cc162797d07e779194fb1 Author: Martin Jambor Date: Thu Apr 1 10:12:23 2021 +0200 sra: Fix bug in grp_write propagation (PR 97009) SRA represents parts of aggregates which are arrays accessed with unknown index as "unscalarizable regions." When there are two such regions one within another and the outer is only read whereas the inner is written to, SRA fails to propagate that write information across assignments. This means that a second aggregate can contain data while SRA thinks it does not and the pass can wrongly eliminate big chunks of assignment from that second aggregate into a third aggregate, which is what happens in PR 97009. Fixed by checking all children of unscalariable accesses for the grp_write flag. gcc/ChangeLog: 2021-03-31 Martin Jambor PR tree-optimization/97009 * tree-sra.c (access_or_its_child_written): New function. (propagate_subaccesses_from_rhs): Use it instead of a simple grp_write test. gcc/testsuite/ChangeLog: 2021-03-31 Martin Jambor PR tree-optimization/97009 * gcc.dg/tree-ssa/pr97009.c: New test. (cherry picked from commit 19d71674616e6494a60432a2a28adcd762a6c877)
[Bug libstdc++/99865] std::filesystem namespace identifiers pollute global namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99865 --- Comment #3 from zoid at riseup dot net --- Apologies. I always forget about ADL.
[Bug target/99863] [10/11 Regression] wrong code with -O -fno-tree-forwprop -mno-sse2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99863 --- Comment #3 from Richard Biener --- diff --git a/gcc/gimplify.c b/gcc/gimplify.c index 6da66985ad6..1f417a52702 100644 --- a/gcc/gimplify.c +++ b/gcc/gimplify.c @@ -5231,6 +5231,7 @@ gimplify_init_constructor (tree *expr_p, gimple_seq *pre_p, gimple_seq *post_p, TREE_TYPE (ce->value))) TREE_STATIC (ctor) = 0; } + recompute_constructor_flags (ctor); if (!is_gimple_reg (TREE_OPERAND (*expr_p, 0))) TREE_OPERAND (*expr_p, 1) = get_formal_tmp_var (ctor, pre_p); } simplifies the IL (vector lowering was supposed to simplify the element extraction but GENERIC match.pd folding is confused about TREE_SIDE_EFFECTS on the vector CTOR). It still nicely triggers the bug though.
[Bug target/99866] New: gcc/config/aarch64/aarch64-protos.h: 2 * passing structs ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99866 Bug ID: 99866 Summary: gcc/config/aarch64/aarch64-protos.h: 2 * passing structs ? Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- 1. gcc/config/aarch64/aarch64-protos.h:348:70: performance: Function parameter 'base' should be passed by const reference. [passedByValue] Source code is constexpr aarch64_simd_vec_issue_info (aarch64_base_vec_issue_info base, unsigned int ld2_st2_general_ops, unsigned int ld3_st3_general_ops, unsigned int ld4_st4_general_ops) 2. gcc/config/aarch64/aarch64-protos.h:377:34: performance: Function parameter 'base' should be passed by const reference. [passedByValue] Duplicate.
[Bug target/99863] [10/11 Regression] wrong code with -O -fno-tree-forwprop -mno-sse2 since r10-7268-g529ea7d9596b26ba
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99863 Martin Liška changed: What|Removed |Added Summary|[10/11 Regression] wrong|[10/11 Regression] wrong |code with -O|code with -O |-fno-tree-forwprop |-fno-tree-forwprop |-mno-sse2 |-mno-sse2 since ||r10-7268-g529ea7d9596b26ba CC||law at gcc dot gnu.org, ||marxin at gcc dot gnu.org --- Comment #4 from Martin Liška --- Started with r10-7268-g529ea7d9596b26ba.
[Bug ipa/98265] [10/11 Regression] gcc-10 has significantly worse code generated with -O2 compared to -O1 (or gcc-9 -O2) when using the Eigen C++ library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98265 --- Comment #9 from CVS Commits --- The master branch has been updated by Jan Hubicka : https://gcc.gnu.org/g:3064fc21aa29d8e04b23c0b52dc4f67de1da6b2f commit r11-7948-g3064fc21aa29d8e04b23c0b52dc4f67de1da6b2f Author: Jan Hubicka Date: Thu Apr 1 12:11:39 2021 +0200 Add testcase for PR98265 gcc/testsuite/ChangeLog: 2021-04-01 Jan Hubicka PR ipa/98265 * gcc.dg/tree-ssa/pr98265.C: New test.
[Bug ipa/98265] [10/11 Regression] gcc-10 has significantly worse code generated with -O2 compared to -O1 (or gcc-9 -O2) when using the Eigen C++ library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98265 Jan Hubicka changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from Jan Hubicka --- Trunk now generates on the unreduced testcase: .file "test.cpp" .text .p2align 4 .globl _Z1f .type _Z1f, @function _Z1f: .LFB6287: .cfi_startproc mulss %xmm3, %xmm0 movq%rdi, %rax mulss %xmm3, %xmm1 mulss %xmm3, %xmm2 movss %xmm0, (%rdi) movss %xmm1, 4(%rdi) movss %xmm2, 8(%rdi) ret .cfi_endproc .LFE6287: .size _Z1f, .-_Z1f .ident "GCC: (GNU) 11.0.1 20210331 (experimental)" .section.note.GNU-stack,"",@progbits
[Bug target/99863] [10/11 Regression] wrong code with -O -fno-tree-forwprop -mno-sse2 since r10-7268-g529ea7d9596b26ba
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99863 --- Comment #5 from Richard Biener --- (In reply to Martin Liška from comment #4) > Started with r10-7268-g529ea7d9596b26ba. Reverting on trunk fixes the issue. Good vs. bad assembly shows the likely culprit: shrq$32, %rax - movq%rax, %r8 - testq %rdi, %rdi + movq%rax, %rdi setne %al
[Bug c++/99859] constexpr evaluation with member function is incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99859
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
Last reconfirmed||2021-04-01
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
--- Comment #2 from Jakub Jelinek ---
We want testcases in our bugzilla rather than external links.
No need for any headers,
template
struct intrusive_ptr
{
T *ptr = nullptr;
constexpr explicit intrusive_ptr(T* p) : ptr(p) {
++ptr->count_;
}
constexpr ~intrusive_ptr() {
if (ptr->dec() == 0)
//if (--ptr->count_ == 0)
delete ptr;
}
constexpr intrusive_ptr(intrusive_ptr const& a) : ptr(a.ptr) {
++ptr->count_;
}
};
struct Foo {
int count_ = 0;
constexpr int dec() {
return --count_;
}
};
template class intrusive_ptr;
constexpr void bar(intrusive_ptr a)
{
// if (a.ptr->count_ != 2) throw 1;
}
constexpr bool foo() {
intrusive_ptr a(new Foo());
bar(a);
return true;
}
static_assert(foo());
reproduces too. Wonder if it isn't related to the instantiation of
intrusive_ptr::~intrusive_ptr() while constexpr evaluating the static
assert.
[Bug target/99647] arm: GCC generates invalid MVE vmov instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99647 Alex Coplan changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |acoplan at gcc dot gnu.org Last reconfirmed||2021-04-01 Ever confirmed|0 |1 --- Comment #2 from Alex Coplan --- Taking a look at this.
[Bug rtl-optimization/99863] [10/11 Regression] wrong code with -O -fno-tree-forwprop -mno-sse2 since r10-7268-g529ea7d9596b26ba
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99863
Richard Biener changed:
What|Removed |Added
Component|target |rtl-optimization
--- Comment #6 from Richard Biener ---
(In reply to Richard Biener from comment #5)
> (In reply to Martin Liška from comment #4)
> > Started with r10-7268-g529ea7d9596b26ba.
>
> Reverting on trunk fixes the issue. Good vs. bad assembly shows the likely
> culprit:
>
> shrq$32, %rax
> - movq%rax, %r8
> - testq %rdi, %rdi
> + movq%rax, %rdi
> setne %al
And this is
(insn 6 3 7 2 (set (reg:CCZ 17 flags)
(compare:CCZ (reg/v:DI 177 [ u64_0 ])
(const_int 0 [0]))) "t.c":14:30 8 {*cmpdi_ccno_1}
(nil))
(insn 7 6 8 2 (set (reg:QI 179)
(eq:QI (reg:CCZ 17 flags)
(const_int 0 [0]))) "t.c":14:30 802 {*setcc_qi}
(expr_list:REG_DEAD (reg:CCZ 17 flags)
(nil)))
...
(insn 23 22 24 2 (set (reg:CCZ 17 flags)
(compare:CCZ (reg/v:DI 177 [ u64_0 ])
(const_int 0 [0]))) "t.c":15:19 8 {*cmpdi_ccno_1}
(nil))
(insn 24 23 25 2 (set (reg:QI 190)
(ne:QI (reg:CCZ 17 flags)
(const_int 0 [0]))) "t.c":15:19 802 {*setcc_qi}
(nil))
deferring deletion of insn with uid = 23.
likely somehow seeing the set as a noop move. trial is (reg:CCZ 17 flags)
but likely CSE doesn't track CC flag clobbers appropriately though there's
no other CC clobber insn visible at this point. At least CSE1 fails
to remove the REG_DEAD note on reg:CCZ in insn 7?
Later we happily insert CC clobbers inbetween - notably DSE1 (eh?!)
produces
(insn 166 12 168 2 (set (reg:SI 262)
(subreg:SI (reg:DI 182 [ foo0_v256u32_0 ]) 0)) "t.c":14:36 75
{*movsi_internal}
(nil))
(insn 168 166 167 2 (set (reg:DI 263)
(reg:DI 182 [ foo0_v256u32_0 ])) "t.c":14:36 74 {*movdi_internal}
(expr_list:REG_DEAD (reg:DI 182 [ foo0_v256u32_0 ])
(nil)))
(insn 167 168 169 2 (parallel [
(set (reg:DI 263)
(lshiftrt:DI (reg:DI 263)
(const_int 32 [0x20])))
(clobber (reg:CC 17 flags))
]) "t.c":14:36 703 {*lshrdi3_1}
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)))
which uses subregs/shifts to elide a load/store pair (I think).
[Bug rtl-optimization/99863] [10/11 Regression] wrong code with -O -fno-tree-forwprop -mno-sse2 since r10-7268-g529ea7d9596b26ba
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99863 --- Comment #7 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:512429a885e87bef51057a001681b7d8d106e807 commit r11-7949-g512429a885e87bef51057a001681b7d8d106e807 Author: Richard Biener Date: Thu Apr 1 11:51:33 2021 +0200 tree-optimization/99863 - clear vector CTOR TREE_SIDE_EFFECTS When we gimplify a vector CTOR the original CONSTRUCTOR tree remains but we fail to recompute flags such as TREE_SIDE_EFFECTS. This causes later GENERIC folding of them in vector lowering to give up since the match.pd machinery is careful about TREE_SIDE_EFFECTS. Fixing this makes vector lowering produce much less garbage and thus following the IL for PR99793 easier. 2021-04-01 Richard Biener PR tree-optimization/99863 * gimplify.c (gimplify_init_constructor): Recompute vector constructor flags.
[Bug c++/99858] Wrong throw-expression behaviour with reference to pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99858
--- Comment #2 from Jonathan Wakely ---
As requested by https://gcc.gnu.org/bugs/ please provide code, not just a URL.
Reduced:
extern "C" int printf(const char*, ...);
int main() try {
try {
throw (void*)1;
} catch (void*& ptr) {
printf("%p %p\n", ptr, &ptr);
ptr = nullptr;
throw;
}
} catch (void*& ptr) {
printf("%p %p\n", ptr, &ptr);
}
Not a regression. I'll take a look at the EH code.
[Bug rtl-optimization/99863] [10/11 Regression] wrong code with -O -fno-tree-forwprop -mno-sse2 since r10-7268-g529ea7d9596b26ba
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99863 Eric Botcazou changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #8 from Eric Botcazou --- Richard, did you mean to CC me for another PR by any chance?
[Bug rtl-optimization/99863] [10/11 Regression] wrong code with -O -fno-tree-forwprop -mno-sse2 since r10-7268-g529ea7d9596b26ba
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99863 --- Comment #9 from Eric Botcazou --- > Richard, did you mean to CC me for another PR by any chance? Never mind, I was confused by your commit.
[Bug target/99867] New: [11 Regression] ICE in to_constant, at poly-int.h:504
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99867 Bug ID: 99867 Summary: [11 Regression] ICE in to_constant, at poly-int.h:504 Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: asolokha at gmx dot com Target Milestone: --- Target: aarch64-linux-gnu gcc-11.0.1-alpha20210328 snapshot (g:499fa254ae8c9752d8c2cf3130b13ffddfd83546) ICEs when compiling gcc/testsuite/gcc.target/aarch64/sve/acle/general/struct_1.c: % aarch64-linux-gnu-gcc-11.0.1 -c gcc/testsuite/gcc.target/aarch64/sve/acle/general/struct_1.c during RTL pass: expand gcc/testsuite/gcc.target/aarch64/sve/acle/general/struct_1.c: In function 'f': gcc/testsuite/gcc.target/aarch64/sve/acle/general/struct_1.c:7:14: internal compiler error: in to_constant, at poly-int.h:504 7 | svint8x2_t x = *a; | ^ 0x6cfe32 poly_int_pod<2u, unsigned short>::to_constant() const /var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210328/work/gcc-11-20210328/gcc/poly-int.h:504 0x6d5651 poly_int_pod<2u, unsigned short>::to_constant() const /var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210328/work/gcc-11-20210328/gcc/expr.c:3695 0x6d5651 emit_move_multi_word /var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210328/work/gcc-11-20210328/gcc/expr.c:3680 0xb450ce emit_move_insn(rtx_def*, rtx_def*) /var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210328/work/gcc-11-20210328/gcc/expr.c:3936 0xb4d8a7 store_expr(tree_node*, rtx_def*, int, bool, bool) /var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210328/work/gcc-11-20210328/gcc/expr.c:6072 0xb4f2c0 expand_assignment(tree_node*, tree_node*, bool) /var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210328/work/gcc-11-20210328/gcc/expr.c:5622 0xa158d7 expand_gimple_stmt_1 /var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210328/work/gcc-11-20210328/gcc/cfgexpand.c:3910 0xa158d7 expand_gimple_stmt /var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210328/work/gcc-11-20210328/gcc/cfgexpand.c:4008 0xa1bbea expand_gimple_basic_block /var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210328/work/gcc-11-20210328/gcc/cfgexpand.c:6045 0xa1d78f execute /var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210328/work/gcc-11-20210328/gcc/cfgexpand.c:6729 It does not ICE when provided w/ -march containing "+sve", so I wonder if this PR is really a duplicate of PR99657.
[Bug c++/98481] [10 Regression] std::vector::size_type as return type gets tagged with abi:cxx11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98481 --- Comment #6 from CVS Commits --- The releases/gcc-10 branch has been updated by Richard Biener : https://gcc.gnu.org/g:892024d4af83b258801ff7484bf28f0cf1a1a999 commit r10-9651-g892024d4af83b258801ff7484bf28f0cf1a1a999 Author: Jakub Jelinek Date: Thu Apr 1 09:59:47 2021 +0200 c++, abi: Fix abi_tag attribute handling [PR98481] In GCC10 cp_walk_subtrees has been changed to walk template arguments. As the following testcase, that changed the mangling of some functions. I believe the previous behavior that find_abi_tags_r doesn't recurse into template args has been the correct one, but setting *walk_subtrees = 0 for the types and handling the types subtree walking manually in find_abi_tags_r looks too hard, there are a lot of subtrees and details what should and shouldn't be walked, both in tree.c (walk_type_fields there, which is static) and in cp_walk_subtrees itself. The following patch abuses the fact that *walk_subtrees is an int to tell cp_walk_subtrees it shouldn't walk the template args. But we don't want to introduce an ABI change in the middle of the GCC 10 cycle, so the GCC 10 version of this patch introduces ABI v15 for the fix, which will be available but not default in GCC 10.3. Co-authored-by: Jason Merrill gcc/cp/ChangeLog: PR c++/98481 * class.c (find_abi_tags_r): Set *walk_subtrees to 2 instead of 1 for types. (mark_abi_tags_r): Likewise. * tree.c (cp_walk_subtrees): If *walk_subtrees_p is 2, look through typedefs. gcc/testsuite/ChangeLog: PR c++/98481 * g++.dg/abi/abi-tag24.C: New test. * g++.dg/abi/abi-tag24a.C: New test. * g++.dg/abi/macro0.C: Adjust expected value. gcc/ChangeLog: PR c++/98481 * common.opt (fabi-version): Default to 14. gcc/c-family/ChangeLog: PR c++/98481 * c-opts.c (c_common_post_options): Bump latest_abi_version.
[Bug target/99867] [11 Regression] ICE in to_constant, at poly-int.h:504
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99867 Richard Biener changed: What|Removed |Added Target Milestone|--- |11.0
[Bug middle-end/99857] [11 Regression] FAIL: libgomp.c/declare-variant-1.c (test for excess errors) by r11-7926
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99857 H.J. Lu changed: What|Removed |Added Status|RESOLVED|NEW Ever confirmed|0 |1 Last reconfirmed||2021-04-01 Resolution|FIXED |--- --- Comment #2 from H.J. Lu --- > Fixed with g:23ce9945d5efa77c96161443f68e03664705ada3. No, it doesn't fix this regression.
[Bug rtl-optimization/99863] [10/11 Regression] wrong code with -O -fno-tree-forwprop -mno-sse2 since r10-7268-g529ea7d9596b26ba
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99863
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #10 from Jakub Jelinek ---
I think the REG_DEAD note isn't the problem here.
At least, when I dump bb 2 in rest_of_handle_dse right before df_analyze call,
there is
(insn 6 3 7 2 (set (reg:CCZ 17 flags)
(compare:CCZ (reg/v:DI 203 [ y ])
(const_int 0 [0]))) "pr99863.c":14:12 8 {*cmpdi_ccno_1}
(nil))
(insn 7 6 8 2 (set (reg:QI 205)
(eq:QI (reg:CCZ 17 flags)
(const_int 0 [0]))) "pr99863.c":14:12 802 {*setcc_qi}
(expr_list:REG_DEAD (reg:CCZ 17 flags)
(nil)))
...
(insn 40 38 41 2 (set (reg:QI 220)
(ne:QI (reg:CCZ 17 flags)
(const_int 0 [0]))) "pr99863.c":15:11 802 {*setcc_qi}
(expr_list:REG_DEAD (reg:CCZ 17 flags)
(nil)))
but if I dump it right after df_analyze call, I see:
(insn 6 3 7 2 (set (reg:CCZ 17 flags)
(compare:CCZ (reg/v:DI 203 [ y ])
(const_int 0 [0]))) "pr99863.c":14:12 8 {*cmpdi_ccno_1}
(expr_list:REG_DEAD (reg/v:DI 203 [ y ])
(nil)))
(insn 7 6 8 2 (set (reg:QI 205)
(eq:QI (reg:CCZ 17 flags)
(const_int 0 [0]))) "pr99863.c":14:12 802 {*setcc_qi}
(nil))
...
(insn 40 38 41 2 (set (reg:QI 220)
(ne:QI (reg:CCZ 17 flags)
(const_int 0 [0]))) "pr99863.c":15:11 802 {*setcc_qi}
(expr_list:REG_DEAD (reg:CCZ 17 flags)
(nil)))
i.e. the problematic REG_DEAD note is gone and I think at this point DF knows
that CC is live there.
But replace_read has code to check for live hard regs, see
note_stores (this_insn, look_for_hardregs, regs_set);
in there etc.
[Bug c++/99283] [modules] ICE in assert_definition, at cp/module.cc:4608
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99283 --- Comment #17 from CVS Commits --- The master branch has been updated by Nathan Sidwell : https://gcc.gnu.org/g:584731ecedf09c2c067913c4af9ed0a30cf19e8d commit r11-7950-g584731ecedf09c2c067913c4af9ed0a30cf19e8d Author: Nathan Sidwell Date: Thu Apr 1 05:25:53 2021 -0700 c++: inter-cluster import order [PR 99283] I finally managed to reduce the testcase without hitting other bugs. This problem is caused by discovering a duplicate in the middle of reading in the entity in question. I had thougt the import seeding at the beginning of a cluster prevented that, but it is insufficient. Specifically an earlier cluster in the same module can cause the import of a duplicate. Although clusters within a module are well-ordered, there is no ordering between clusters of one module and clusters of another module. And thus we can get duplicate declaration loops. This prevents the problem by also seeding references to earlier clusters in the same module. As the FIXME notes, it is sufficient to reference a single entity in any particular earlier cluster, plus, we also could determine the implicit dependencies and prune that seeding even further. I do not do that -- it decrease the loading that will happen, but would reduce the serialization size. As ever, let's get correctness first. PR c++/99283 gcc/cp/ * module.cc (trees_out::decl_node): Adjust importedness reference assert. (module_state::intercluster_seed): New. Seed both imports and inter-cluster references. Broken out of ... (module_state::write_cluster): ... here. Call it. gcc/testsuite/ * g++.dg/modules/pr99283-6.h: New. * g++.dg/modules/pr99283-6_a.H: New. * g++.dg/modules/pr99283-6_b.H: New. * g++.dg/modules/pr99283-6_c.C: New. * g++.dg/modules/hdr-init-1_c.C: Adjust scan. * g++.dg/modules/indirect-3_c.C: Adjust scan. * g++.dg/modules/indirect-4_c.C: Adjust scan. * g++.dg/modules/lambda-3_b.C: Adjust scan. * g++.dg/modules/late-ret-3_c.C: Adjust scan. * g++.dg/modules/pr99425-1_b.H: Adjust scan. * g++.dg/modules/pr99425-1_c.C: Adjust scan.
[Bug c++/99283] [modules] ICE in assert_definition, at cp/module.cc:4608
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99283 --- Comment #18 from Nathan Sidwell --- * 584731ecedf 2021-04-01 | c++: inter-cluster import order [PR 99283]
[Bug c++/99283] [modules] ICE in assert_definition, at cp/module.cc:4608
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99283 --- Comment #19 from Nathan Sidwell --- Yes! that seems to have done it!
[Bug rtl-optimization/99863] [10/11 Regression] wrong code with -O -fno-tree-forwprop -mno-sse2 since r10-7268-g529ea7d9596b26ba
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99863
--- Comment #11 from rguenther at suse dot de ---
On Thu, 1 Apr 2021, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99863
>
> Jakub Jelinek changed:
>
>What|Removed |Added
>
> CC||jakub at gcc dot gnu.org
>
> --- Comment #10 from Jakub Jelinek ---
> I think the REG_DEAD note isn't the problem here.
> At least, when I dump bb 2 in rest_of_handle_dse right before df_analyze call,
> there is
> (insn 6 3 7 2 (set (reg:CCZ 17 flags)
> (compare:CCZ (reg/v:DI 203 [ y ])
> (const_int 0 [0]))) "pr99863.c":14:12 8 {*cmpdi_ccno_1}
> (nil))
> (insn 7 6 8 2 (set (reg:QI 205)
> (eq:QI (reg:CCZ 17 flags)
> (const_int 0 [0]))) "pr99863.c":14:12 802 {*setcc_qi}
> (expr_list:REG_DEAD (reg:CCZ 17 flags)
> (nil)))
> ...
> (insn 40 38 41 2 (set (reg:QI 220)
> (ne:QI (reg:CCZ 17 flags)
> (const_int 0 [0]))) "pr99863.c":15:11 802 {*setcc_qi}
> (expr_list:REG_DEAD (reg:CCZ 17 flags)
> (nil)))
> but if I dump it right after df_analyze call, I see:
> (insn 6 3 7 2 (set (reg:CCZ 17 flags)
> (compare:CCZ (reg/v:DI 203 [ y ])
> (const_int 0 [0]))) "pr99863.c":14:12 8 {*cmpdi_ccno_1}
> (expr_list:REG_DEAD (reg/v:DI 203 [ y ])
> (nil)))
> (insn 7 6 8 2 (set (reg:QI 205)
> (eq:QI (reg:CCZ 17 flags)
> (const_int 0 [0]))) "pr99863.c":14:12 802 {*setcc_qi}
> (nil))
> ...
> (insn 40 38 41 2 (set (reg:QI 220)
> (ne:QI (reg:CCZ 17 flags)
> (const_int 0 [0]))) "pr99863.c":15:11 802 {*setcc_qi}
> (expr_list:REG_DEAD (reg:CCZ 17 flags)
> (nil)))
>
> i.e. the problematic REG_DEAD note is gone and I think at this point DF knows
> that CC is live there.
> But replace_read has code to check for live hard regs, see
> note_stores (this_insn, look_for_hardregs, regs_set);
> in there etc.
But find_shift_sequence doesn't seem to check whether the emitted
insns contain any extra hardreg clobbers that make the replacement
invalid.
[Bug ipa/99447] [11 Regression] ICE (segfault) in lookup_page_table_entry
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99447 Matthias Klose changed: What|Removed |Added Resolution|--- |WORKSFORME Status|WAITING |RESOLVED --- Comment #28 from Matthias Klose --- also retried with trunk 20210331, and the two extra --param settings. Can't reproduce it anymore.
[Bug c++/99283] [modules] ICE in assert_definition, at cp/module.cc:4608
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99283
--- Comment #20 from Alexander Lelyakin ---
Just make:
git pull
make
make install
That is: just make in previously configured dir.
Then:
---
g++ -std=c++20 -fmodules-ts -x c++-system-header string
g++ -std=c++20 -fmodules-ts -x c++-system-header type_traits
g++ -std=c++20 -fmodules-ts -x c++-system-header iostream
In file included from /home/sasha/GCC/include/c++/11.0.1/bits/ios_base.h:41,
from /home/sasha/GCC/include/c++/11.0.1/ios:42,
from /home/sasha/GCC/include/c++/11.0.1/ostream:38,
from /home/sasha/GCC/include/c++/11.0.1/iostream:39:
/home/sasha/GCC/include/c++/11.0.1/bits/locale_classes.h:163:23: internal
compiler error: in assert_definition, at cp/module.cc:4492
163 | locale(const std::string& __s) : locale(__s.c_str()) { }
| ^~
0x6e31c7 trees_in::assert_definition(tree_node*, bool)
../../gcc/gcc/cp/module.cc:4492
0xa5eed0 trees_in::odr_duplicate(tree_node*, bool)
../../gcc/gcc/cp/module.cc:11323
0xa6e5af trees_in::read_function_def(tree_node*, tree_node*)
../../gcc/gcc/cp/module.cc:11403
0xa70aa1 module_state::read_cluster(unsigned int)
../../gcc/gcc/cp/module.cc:14817
0xa7111d module_state::load_section(unsigned int, binding_slot*)
../../gcc/gcc/cp/module.cc:18079
0xa711df module_state::lazy_load(unsigned int, binding_slot*)
../../gcc/gcc/cp/module.cc:18737
0xa6b460 trees_in::tree_node(bool)
../../gcc/gcc/cp/module.cc:9661
0xa7091b module_state::read_cluster(unsigned int)
../../gcc/gcc/cp/module.cc:14714
0xa7111d module_state::load_section(unsigned int, binding_slot*)
../../gcc/gcc/cp/module.cc:18079
0xa711df module_state::lazy_load(unsigned int, binding_slot*)
../../gcc/gcc/cp/module.cc:18737
0xa6b460 trees_in::tree_node(bool)
../../gcc/gcc/cp/module.cc:9661
0xa7091b module_state::read_cluster(unsigned int)
../../gcc/gcc/cp/module.cc:14714
0xa7111d module_state::load_section(unsigned int, binding_slot*)
../../gcc/gcc/cp/module.cc:18079
0xa712d8 lazy_load_binding(unsigned int, tree_node*, tree_node*, binding_slot*)
../../gcc/gcc/cp/module.cc:18770
0xa8301e name_lookup::search_namespace_only(tree_node*)
../../gcc/gcc/cp/name-lookup.c:928
0xa8321a name_lookup::search_namespace(tree_node*)
../../gcc/gcc/cp/name-lookup.c:1014
0xa8321a name_lookup::search_namespace(tree_node*)
../../gcc/gcc/cp/name-lookup.c:1007
0xa8331c name_lookup::search_qualified(tree_node*, bool)
../../gcc/gcc/cp/name-lookup.c:1075
0xa8785f qualified_namespace_lookup
../../gcc/gcc/cp/name-lookup.c:7161
0xa88878 lookup_qualified_name(tree_node*, tree_node*, LOOK_want, bool)
../../gcc/gcc/cp/name-lookup.c:7122
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug rtl-optimization/99863] [10/11 Regression] wrong code with -O -fno-tree-forwprop -mno-sse2 since r10-7268-g529ea7d9596b26ba
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99863 --- Comment #12 from Jakub Jelinek --- Ah, I see the actual problem. replace_read checks the hard regs in the insn sequence and compares them to the live hard regs at the point of the read_insn, in the testcase insn 134 after the CC setter 6 and CC users 7 and 40. CC is not live on the insn 134. But we emit that sequence elsewhere: 2076 /* Insert this right before the store insn where it will be safe 2077 from later insns that might change it before the read. */ 2078 emit_insn_before (insns, store_insn->insn); and store_insn->insn in this case is insn 19, which is in between insn 7 and 40, and CC is live there. So, I think we need to do this live hard regs testing in record_store instead or in addition to. We already call get_stored_val there just for testing purposes and throw it away afterwards.
[Bug rtl-optimization/99863] [10/11 Regression] wrong code with -O -fno-tree-forwprop -mno-sse2 since r10-7268-g529ea7d9596b26ba
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99863
--- Comment #13 from Jakub Jelinek ---
So, I think we want to do:
--- gcc/dse.c.jj2021-01-28 09:59:11.973750676 +0100
+++ gcc/dse.c 2021-04-01 15:16:22.003913061 +0200
@@ -1970,8 +1970,7 @@ get_stored_val (store_info *store_info,
static bool
replace_read (store_info *store_info, insn_info_t store_insn,
- read_info_t read_info, insn_info_t read_insn, rtx *loc,
- bitmap regs_live)
+ read_info_t read_info, insn_info_t read_insn, rtx *loc)
{
machine_mode store_mode = GET_MODE (store_info->mem);
machine_mode read_mode = GET_MODE (read_info->mem);
@@ -2040,7 +2039,8 @@ replace_read (store_info *store_info, in
note_stores (this_insn, look_for_hardregs, regs_set);
}
- bitmap_and_into (regs_set, regs_live);
+ if (store_insn->fixed_regs_live)
+ bitmap_and_into (regs_set, store_insn->fixed_regs_live);
if (!bitmap_empty_p (regs_set))
{
if (dump_file && (dump_flags & TDF_DETAILS))
@@ -2286,7 +2286,7 @@ check_mem_read_rtx (rtx *loc, bb_info_t
offset - store_info->offset,
width)
&& replace_read (store_info, i_ptr, read_info,
- insn_info, loc, bb_info->regs_live))
+ insn_info, loc))
return;
/* The bases are the same, just see if the offsets
@@ -2352,8 +2352,7 @@ check_mem_read_rtx (rtx *loc, bb_info_t
store_info->width)
&& all_positions_needed_p (store_info,
offset - store_info->offset, width)
- && replace_read (store_info, i_ptr, read_info, insn_info, loc,
- bb_info->regs_live))
+ && replace_read (store_info, i_ptr, read_info, insn_info, loc))
return;
remove = canon_true_dependence (store_info->mem,
to fix this. Perhaps together with filling fixed_regs_live on more stores,
currently we fill it in only for insn with exactly one store or on memset
calls, perhaps we want to fill it on insns with more than one store?
[Bug rtl-optimization/99863] [10/11 Regression] wrong code with -O -fno-tree-forwprop -mno-sse2 since r10-7268-g529ea7d9596b26ba
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99863 --- Comment #14 from Jakub Jelinek --- Though, we don't add the multiple stores case to active_local_stores and all the replace_read calls are from the active_local_stores chain. So I think the above patch should DTRT.
[Bug rtl-optimization/99863] [10/11 Regression] wrong code with -O -fno-tree-forwprop -mno-sse2 since r10-7268-g529ea7d9596b26ba
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99863 --- Comment #15 from rguenther at suse dot de --- On Thu, 1 Apr 2021, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99863 > > --- Comment #14 from Jakub Jelinek --- > Though, we don't add the multiple stores case to active_local_stores and all > the replace_read calls are from the active_local_stores chain. > So I think the above patch should DTRT. I suppose it already fails elsewhere if fixed_regs_live is not available?
[Bug fortran/99818] [10/11 Regression] ICE in gfc_get_tree_for_caf_expr, at fortran/trans-expr.c:2186
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99818 Paul Thomas changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org --- Comment #3 from Paul Thomas --- Created attachment 50494 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50494&action=edit Fix for the PR The fix is trivial - gfortran now gives the correct error. 15 | call y%s |1 Error: Actual argument to ‘x’ at (1) must be a coarray Paul
[Bug rtl-optimization/99863] [10/11 Regression] wrong code with -O -fno-tree-forwprop -mno-sse2 since r10-7268-g529ea7d9596b26ba
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99863 --- Comment #16 from Jakub Jelinek --- (In reply to rguent...@suse.de from comment #15) > On Thu, 1 Apr 2021, jakub at gcc dot gnu.org wrote: > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99863 > > > > --- Comment #14 from Jakub Jelinek --- > > Though, we don't add the multiple stores case to active_local_stores and all > > the replace_read calls are from the active_local_stores chain. > > So I think the above patch should DTRT. > > I suppose it already fails elsewhere if fixed_regs_live is not > available? No. But the way I wrote the above patch, if fixed_regs_live is not available, it will punt if any hard regs are live in the considered sequence.
[Bug c++/99586] Use of class template identifier checked for CTAD before instantiation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99586 Patrick Palka changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Status|NEW |ASSIGNED CC||ppalka at gcc dot gnu.org
[Bug tree-optimization/97009] [9 Regression] Inlining with non-standard selected_int_kind leads to errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97009 Martin Jambor changed: What|Removed |Added Summary|[9/10/11 Regression]|[9 Regression] Inlining |Inlining with non-standard |with non-standard |selected_int_kind leads to |selected_int_kind leads to |errors |errors --- Comment #11 from Martin Jambor --- Pushed to master and gcc-10 branch, I will backport the patch to gcc-9 next week.
[Bug c++/99283] [modules] ICE in assert_definition, at cp/module.cc:4608
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99283 --- Comment #21 from Nathan Sidwell --- Pants
[Bug c++/99283] [modules] ICE in assert_definition, at cp/module.cc:4608
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99283
--- Comment #22 from Alexander Lelyakin ---
Clean rebuild do not change things:
/home/sasha/GCC/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header streambuf
/home/sasha/GCC/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header
type_traits
/home/sasha/GCC/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header valarray
In file included from /home/sasha/GCC/include/c++/11.0.1/iterator:66,
from
/home/sasha/GCC/include/c++/11.0.1/bits/ranges_algobase.h:36,
from /home/sasha/GCC/include/c++/11.0.1/bits/ranges_algo.h:35,
from /home/sasha/GCC/include/c++/11.0.1/algorithm:64,
from /home/sasha/GCC/include/c++/11.0.1/valarray:38:
/home/sasha/GCC/include/c++/11.0.1/bits/streambuf_iterator.h:53:5: internal
compiler error: in assert_definition, at cp/module.cc:4492
53 | {
| ^
0x6e31c7 trees_in::assert_definition(tree_node*, bool)
../../gcc/gcc/cp/module.cc:4492
0xa5eed0 trees_in::odr_duplicate(tree_node*, bool)
../../gcc/gcc/cp/module.cc:11323
0xa6e5af trees_in::read_function_def(tree_node*, tree_node*)
../../gcc/gcc/cp/module.cc:11403
0xa70aa1 module_state::read_cluster(unsigned int)
../../gcc/gcc/cp/module.cc:14817
0xa7111d module_state::load_section(unsigned int, binding_slot*)
../../gcc/gcc/cp/module.cc:18079
0xa711df module_state::lazy_load(unsigned int, binding_slot*)
../../gcc/gcc/cp/module.cc:18737
0xa6b460 trees_in::tree_node(bool)
../../gcc/gcc/cp/module.cc:9661
0xa7091b module_state::read_cluster(unsigned int)
../../gcc/gcc/cp/module.cc:14714
0xa7111d module_state::load_section(unsigned int, binding_slot*)
../../gcc/gcc/cp/module.cc:18079
0xa711df module_state::lazy_load(unsigned int, binding_slot*)
../../gcc/gcc/cp/module.cc:18737
0xa74337 lazy_load_pendings(tree_node*)
../../gcc/gcc/cp/module.cc:18830
0xb7eed5 complete_type(tree_node*)
../../gcc/gcc/cp/typeck.c:140
0xb3fe22 lookup_member(tree_node*, tree_node*, int, bool, int,
access_failure_info*)
../../gcc/gcc/cp/search.c:1148
0xa79195 get_class_binding
../../gcc/gcc/cp/name-lookup.c:5333
0xa8065f outer_binding(tree_node*, cxx_binding*, bool)
../../gcc/gcc/cp/name-lookup.c:7649
0xa808af innermost_non_namespace_value(tree_node*)
../../gcc/gcc/cp/name-lookup.c:7686
0xae6547 check_template_shadow(tree_node*)
../../gcc/gcc/cp/pt.c:4379
0xa7ced1 push_class_level_binding_1
../../gcc/gcc/cp/name-lookup.c:5418
0xa7d49e push_class_level_binding(tree_node*, tree_node*)
../../gcc/gcc/cp/name-lookup.c:5567
0xa7d49e pushdecl_class_level(tree_node*)
../../gcc/gcc/cp/name-lookup.c:5280
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug libstdc++/99868] New: std::string is not copied correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99868
Bug ID: 99868
Summary: std::string is not copied correctly
Product: gcc
Version: 7.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: apyszczuk at gmail dot com
Target Milestone: ---
Created attachment 50495
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50495&action=edit
save-temps
This code does not correctly copy the string *str*.
#include
#include
void mod (char* data) {
data[0] = 'c';
}
int main () {
const std::string str {"8:0.0"};
std::string dn {str};
mod (const_cast (dn.data ()));
std::cout << "dn = " << dn << "\n";
std::cout << "str = " << str << "\n";
return 0;
}
*dn* should be "c:0.0" and *str* should be untouched but in fact both have the
same value.
If I change:
std::string dn {str};
to:
std::string dn {str.c_str ()};
then *str* is "8:0.0" as it should be.
VERSION:
--
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/opt/rh/devtoolset-7/root/usr/libexec/gcc/x86_64-redhat-linux/7/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap
--enable-languages=c,c++,fortran,lto --prefix=/opt/rh/devtoolset-7/root/usr
--mandir=/opt/rh/devtoolset-7/root/usr/share/man
--infodir=/opt/rh/devtoolset-7/root/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared
--enable-threads=posix --enable-checking=release --enable-multilib
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-linker-build-id
--with-gcc-major-version-only --enable-plugin --with-linker-hash-style=gnu
--enable-initfini-array --with-default-libstdcxx-abi=gcc4-compatible
--with-isl=/builddir/build/BUILD/gcc-7.2.1-20170829/obj-x86_64-redhat-linux/isl-install
--enable-libmpx --enable-gnu-indirect-function --with-tune=generic
--with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
gcc version 7.2.1 20170829 (Red Hat 7.2.1-1) (GCC)
--
COMPILATION:
g++ -std=c++17 main.cpp -o main && ./main
(in 11 and 14 is the same)
As I saw, GCC 8.3 does not have the same issue: https://ideone.com/EuNi6U
[Bug bootstrap/87858] Building old multilib bootstrap GCC: stage1 32-bit libstdc++ fails to build after building 64-bit libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87858 Libor Bukata changed: What|Removed |Added CC||libor.bukata at oracle dot com --- Comment #4 from Libor Bukata --- We also cannot build older GCC versions with GCC 11 nightly (commit 8a6a62614a8ae) on Solaris Trunk: /builds/gcc_nightly_full_build/components/gcc10/build/amd64/./gcc/xgcc -shared-libgcc -B/builds/gcc_nightly_full_build/components/gcc10/build/amd64/./gcc -nostdinc++ -L/builds/gcc_nightly_full_build/components/gcc10/build/amd64/x86_64-pc-solaris2.11/32/libstdc++-v3/src -L/builds/gcc_nightly_full_build/components/gcc10/build/amd64/x86_64-pc-solaris2.11/32/libstdc++-v3/src/.libs -L/builds/gcc_nightly_full_build/components/gcc10/build/amd64/x86_64-pc-solaris2.11/32/libstdc++-v3/libsupc++/.libs -B/usr/gcc/10/x86_64-pc-solaris2.11/bin/ -B/usr/gcc/10/x86_64-pc-solaris2.11/lib/ -isystem /usr/gcc/10/x86_64-pc-solaris2.11/include -isystem /usr/gcc/10/x86_64-pc-solaris2.11/sys-include -fno-checking -m32 -x c++-header -nostdinc++ -g -O2 -m32 -I/builds/gcc_nightly_full_build/components/gcc10/build/amd64/x86_64-pc-solaris2.11/32/libstdc++-v3/include/x86_64-pc-solaris2.11 -I/builds/gcc_nightly_full_build/components/gcc10/build/amd64/x86_64-pc-solaris2.11/32/libstdc++-v3/include -I/builds/gcc_nightly_full_build/components/gcc10/gcc-10.2.0/libstdc++-v3/libsupc++ -O2 -g -std=gnu++0x /builds/gcc_nightly_full_build/components/gcc10/gcc-10.2.0/libstdc++-v3/include/precompiled/stdc++.h \ -o x86_64-pc-solaris2.11/bits/stdc++.h.gch/O2ggnu++0x.gch ld.so.1: cc1plus: fatal: libstdc++.so.6: version 'GLIBCXX_3.4.29' not found (required by file /builds/gcc_nightly_full_build/components/gcc10/build/amd64/gcc/cc1plus) ld.so.1: cc1plus: fatal: /builds/gcc_nightly_full_build/components/gcc10/build/amd64/gcc/cc1plus: mismatched ELF symbol versioning xgcc: fatal error: Killed signal terminated program cc1plus GLIBCXX_3.4.29 is a new addition to libstdc++.so.6 that is not available in older libstdc++.so.6 libraries of GCC 7, 9, and 10.
[Bug rtl-optimization/99863] [10/11 Regression] wrong code with -O -fno-tree-forwprop -mno-sse2 since r10-7268-g529ea7d9596b26ba
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99863 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #17 from Jakub Jelinek --- Created attachment 50496 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50496&action=edit gcc11-pr99863.patch Full untested patch I'm going to bootstrap/regtest overnight.
[Bug c++/98481] [10 Regression] std::vector::size_type as return type gets tagged with abi:cxx11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98481 --- Comment #7 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:5f00df5925082c7b66da91270f2ed29bf4818c93 commit r11-7951-g5f00df5925082c7b66da91270f2ed29bf4818c93 Author: Jason Merrill Date: Wed Mar 31 17:48:50 2021 -0400 c++: Add ABI version for PR98481 fix The PR98481 fix corrects an ABI regression in GCC 10, but we don't want to introduce an ABI change in the middle of the GCC 10 cycle. This patch introduces ABI v15 for the fix, which will be available but not default in GCC 10.3; the broken behavior remains in ABI v14. Compatibility aliases will not be generated for this change. gcc/ChangeLog: PR c++/98481 * common.opt: Document v15 and v16. gcc/c-family/ChangeLog: PR c++/98481 * c-opts.c (c_common_post_options): Bump latest_abi_version. gcc/cp/ChangeLog: PR c++/98481 * mangle.c (write_expression): Adjust. * class.c (find_abi_tags_r): Disable PR98481 fix for ABI v14. (mark_abi_tags_r): Likewise. gcc/testsuite/ChangeLog: PR c++/98481 * g++.dg/abi/abi-tag24a.C: New test. * g++.dg/abi/macro0.C: Adjust expected value.
[Bug target/99847] Optimization breaks alignment on CPU32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99847 ⎓ changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #5 from ⎓ --- I can confirm that everything works as it should with m68k-unknown-elf-gcc/g++ build with crosstool-NG. But I would still prefer that m68k-linux-* refuses to work with the older CPUs or something like that. This problem could potentially discourage less experienced people away from experimenting with m68k.
[Bug c++/99859] constexpr evaluation with member function is incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99859
--- Comment #3 from Jakub Jelinek ---
The instantiation isn't the problem,
template
struct intrusive_ptr
{
T *ptr = nullptr;
constexpr explicit intrusive_ptr(T* p) : ptr(p) {
++ptr->count_;
}
constexpr ~intrusive_ptr() {
if (ptr->dec() == 0)
delete ptr;
}
constexpr intrusive_ptr(intrusive_ptr const& a) : ptr(a.ptr) {
++ptr->count_;
}
};
struct Foo {
int count_ = 0;
constexpr int dec() {
return --count_;
}
};
constexpr bool baz() {
Foo f { 4 };
intrusive_ptr a(&f);
return true;
}
constexpr bool x = baz();
constexpr void bar(intrusive_ptr a)
{
}
constexpr bool foo() {
intrusive_ptr a(new Foo());
bar(a);
return true;
}
static_assert(foo());
fails too, and during the finish_static_assert fold_nondependent_expr
evaluation only one cxx_eval_outermost_expr is called.
[Bug target/99867] [10/11 Regression] ICE in to_constant, at poly-int.h:504
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99867
Alex Coplan changed:
What|Removed |Added
Ever confirmed|0 |1
CC||acoplan at gcc dot gnu.org
Known to fail||10.2.1, 11.0
Status|UNCONFIRMED |NEW
Last reconfirmed||2021-04-01
Summary|[11 Regression] ICE in |[10/11 Regression] ICE in
|to_constant, at |to_constant, at
|poly-int.h:504 |poly-int.h:504
Keywords||ice-on-invalid-code
--- Comment #1 from Alex Coplan ---
Confirmed. ICEs with just:
#include
void g(svint8x2_t *p) { svint8x2_t x = *p; }
Notably for the related:
#include
void f(svint8_t *p) { svint8_t x = *p; }
we diagnose it:
diag.c: In function ‘f’:
diag.c:2:32: error: this operation requires the SVE ISA extension
2 | void f(svint8_t *p) { svint8_t x = *p; }
|^
diag.c:2:32: note: you can enable SVE using the command-line option ‘-march’,
or by using the ‘target’ attribute or pragma
[Bug c++/99869] New: ICE: in do_auto_deduction, at cp/pt.c:29620
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99869
Bug ID: 99869
Summary: ICE: in do_auto_deduction, at cp/pt.c:29620
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: ---
This is a small variant of fixed PR 99815.
https://godbolt.org/z/jezs4qh3E
template concept C = true;
template
auto bar(Ts...) { for (C auto c : ""); }
:4:42: internal compiler error: in do_auto_deduction, at cp/pt.c:29620
4 | auto bar(Ts...) { for (C auto c : ""); }
| ^~
0x1cfca39 internal_error(char const*, ...)
???:0
0x6ba92b fancy_abort(char const*, int, char const*)
???:0
0x90a724 do_auto_deduction(tree_node*, tree_node*, tree_node*, int,
auto_deduction_context, tree_node*, int)
???:0
0x8e126d c_parse_file()
???:0
0xa60292 c_common_parse_file()
???:0
Please submit a full bug report,
with preprocessed source if appropriate.
[Bug target/97513] [11 regression] aarch64 SVE regressions since r11-3822
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97513 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |ASSIGNED --- Comment #7 from rsandifo at gcc dot gnu.org --- Testing a patch for the slp_perm_*.c regressions, which as Jakub says are real. The remaining SVE testsuite failures looks like testisms, so I'll deal with those separately.
[Bug target/99870] New: uiret generated for -mcmodel=kernel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99870
Bug ID: 99870
Summary: uiret generated for -mcmodel=kernel
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
Target Milestone: ---
Target: x86-64
[hjl@gnu-cfl-2 tmp]$ /usr/gcc-11.0.1-x32/bin/gcc -march=sapphirerapids
-mcmodel=kernel -mno-sse -mno-mmx -O2 -S -mno-80387 x.c
[hjl@gnu-cfl-2 tmp]$ cat x.s
.file "x.c"
.text
.p2align 4
.globl foo
.type foo, @function
foo:
.LFB0:
.cfi_startproc
uiret
.cfi_endproc
.LFE0:
.size foo, .-foo
.ident "GCC: (GNU) 11.0.1 20210330 (experimental)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-cfl-2 tmp]$ cat x.c
__attribute__((interrupt))
void
foo (void *frame)
{
}
[hjl@gnu-cfl-2 tmp]$ /usr/gcc-11.0.1-x32/bin/gcc -march=sapphirerapids
-mcmodel=kernel -mno-sse -mno-mmx -O2 -S -mno-80387 x.c
[hjl@gnu-cfl-2 tmp]$ cat x.s
.file "x.c"
.text
.p2align 4
.globl foo
.type foo, @function
foo:
.LFB0:
.cfi_startproc
uiret << This should be iret.
.cfi_endproc
.LFE0:
.size foo, .-foo
.ident "GCC: (GNU) 11.0.1 20210330 (experimental)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-cfl-2 tmp]$
[Bug libstdc++/99871] New: #includes inside push visibility scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99871 Bug ID: 99871 Summary: #includes inside push visibility scope Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: nathan at gcc dot gnu.org Target Milestone: --- I ran into this working on module bugs (99823). While it is not affecting that debugging, it has code smell. We have the following: #pragma GCC visibility push(default) .. some decls #include ... more decls #pragma GCC visibility pop The case I ran into is # 33 "../x86_64-pc-linux-gnu/libstdc++-v3/include/bits/nested_exception.h" 3 #pragma GCC visibility push(default) ... #include "type_traits" ... #pragma GCC visibility pop That visibility pragma will not affect the visibility of decls in type_traits, when that is translated to an include. Fortunately, you asked for default visibility.
[Bug c/99872] New: [11 Regression] optimizations sometimes lead to missing asm prefixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99872 Bug ID: 99872 Summary: [11 Regression] optimizations sometimes lead to missing asm prefixes Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: critical Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: jyong at gcc dot gnu.org Target Milestone: --- Host: x86_64-pc-linux-gnu Target: x86_64-w64-mingw32 Build: x86_64-pc-linux-gnu Created attachment 50497 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50497&action=edit lib32_libmingwex_a-pow.c test case Compiling with the following command line: x86_64-w64-mingw32-gcc -O2 -c lib32_libmingwex_a-pow.c -std=gnu99 -m32 Causes an undefined symbols with the wrong asm prefixes to be emitted: T ___attribute__pow 0010 B ___attribute__pow_d 0008 B ___attribute__pow_x B ___attribute__pow_y b .bss d .data U ___fpclassify U _internal_modf U LC5 U _LC6 r .rdata r .rdata$zzz U ___signbit t .text Adding -fno-leading-underscore makes the symbols resolved, 32bit Windows code is supposed to have a leading underscore.
[Bug c++/99584] [11 Regression] ICE Segmentation fault when expanding lambda noexcept specifier with invalid parameter pack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99584 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED CC||jason at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug c++/99584] [11 Regression] ICE Segmentation fault when expanding lambda noexcept specifier with invalid parameter pack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99584 Jason Merrill changed: What|Removed |Added Keywords|ice-on-invalid-code |ice-on-valid-code --- Comment #2 from Jason Merrill --- Probably the same issue as PR 95583.
[Bug libstdc++/99871] #includes inside push visibility scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99871 Jonathan Wakely changed: What|Removed |Added Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2021-04-01
[Bug libstdc++/99871] #includes inside push visibility scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99871 --- Comment #1 from Jonathan Wakely --- I wonder if there's a reason we don't just put the visibility on the namespace the way we do elsewhere: namespace std _GLIBCXX_VISIBILITY(default) I will do that, or just move the pragma after the includes.
[Bug c++/99805] filesystem::path::parent_path got a wrong path
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99805 Jonathan Wakely changed: What|Removed |Added Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Last reconfirmed||2021-04-01 Status|UNCONFIRMED |ASSIGNED --- Comment #3 from Jonathan Wakely --- Ah yes, that explains why devtoolset reproduces it. Thanks.
[Bug c++/99805] [9/10/11 Regression] filesystem::path::parent_path got a wrong path
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99805 Jonathan Wakely changed: What|Removed |Added Known to fail||10.2.0, 11.0, 9.3.0 Target Milestone|--- |9.4 Summary|filesystem::path::parent_pa |[9/10/11 Regression] |th got a wrong path |filesystem::path::parent_pa ||th got a wrong path Known to work||8.4.1
[Bug libstdc++/99868] std::string is not copied correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99868
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED |RESOLVED
--- Comment #1 from Jonathan Wakely ---
(In reply to Artur from comment #0)
> void mod (char* data) {
> data[0] = 'c';
> }
>
> int main () {
> const std::string str {"8:0.0"};
> std::string dn {str};
>
> mod (const_cast (dn.data ()));
This is undefined behaviour.
You are using the old std::string implementation, which matches the rules in
the C++03 standard. That standard is very clear about the requirements for
data():
"Requires: The program shall not alter any of the values stored in the
character array."
The character sequence owned by dn is shared with str, so changing one changes
the other. But you can't change it in a correct program, only in a program with
undefined behaviour.
> As I saw, GCC 8.3 does not have the same issue: https://ideone.com/EuNi6U
The oldest supported release is GCC 8.4, nothing older than that is supported
or maintained.
The behaviour is the same in all releases, but you need to use the gcc4
std::string implementation by specifying -D_GLIBCXX_USE_CXX11_ABI=0 (which is
implied when using the GCC from devtoolset).
[Bug c++/99831] [10/11 Regression] ICE: in reshape_init, at cp/decl.c:6720
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99831 Marek Polacek changed: What|Removed |Added Keywords||patch --- Comment #9 from Marek Polacek --- https://gcc.gnu.org/pipermail/gcc-patches/2021-April/567599.html
[Bug fortran/91726] [8/9 Regression] ICE in gfc_conv_array_ref, at fortran/trans-array.c:3612
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91726
--- Comment #9 from José Rui Faustino de Sousa ---
Hi Paul!
This seems to fix the ICE generated by using -ftrapv -fcheck=bounds
Fixes "nelems" type and adds an optional assert to make sure it stays fixed.
Best regards,
José Rui
diff --git a/gcc/fortran/trans-array.c b/gcc/fortran/trans-array.c
index be5eb89350f..7954b138605 100644
--- a/gcc/fortran/trans-array.c
+++ b/gcc/fortran/trans-array.c
@@ -9375,7 +9375,7 @@ structure_alloc_comps (gfc_symbol * der_type, tree decl,
nelems));
}
else
- nelems = build_int_cst (size_type_node, 1);
+ nelems = build_int_cst (gfc_array_index_type, 1);
if (CLASS_DATA (c)->attr.dimension
|| CLASS_DATA (c)->attr.codimension)
diff --git a/gcc/fortran/trans-expr.c b/gcc/fortran/trans-expr.c
index 2fa17b36c03..258e885faaa 100644
--- a/gcc/fortran/trans-expr.c
+++ b/gcc/fortran/trans-expr.c
@@ -1446,6 +1452,7 @@ gfc_copy_class_to_class (tree from, tree to, tree nelems,
bool unlimited)
name = (const char *)(DECL_NAME (to)->identifier.id.str);
from_len = gfc_conv_descriptor_size (from_data, 1);
+ gcc_assert (TREE_TYPE (orig_nelems) == gfc_array_index_type);
tmp = fold_build2_loc (input_location, NE_EXPR,
logical_type_node, from_len, orig_nelems);
msg = xasprintf ("Array bound mismatch for dimension %d "
[Bug tree-optimization/99873] New: [11 Regression] GCC no longer makes as much use of ST3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99873
Bug ID: 99873
Summary: [11 Regression] GCC no longer makes as much use of ST3
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: rsandifo at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org
Target Milestone: ---
Target: aarch64*-*-*
For:
void
f (int *restrict x, int *restrict y, int *restrict z, int n)
{
for (int i = 0; i < n; i += 3)
{
x[i] = y[i] + z[i];
x[i + 1] = y[i + 1] - z[i + 1];
x[i + 2] = y[i + 2] | z[i + 2];
}
}
GCC 10 produced a nice loop using LD3 and ST3:
.L4:
ld3 {v4.4s - v6.4s}, [x4], 48
ld3 {v16.4s - v18.4s}, [x6], 48
add v1.4s, v16.4s, v4.4s
sub v2.4s, v5.4s, v17.4s
orr v3.16b, v18.16b, v6.16b
st3 {v1.4s - v3.4s}, [x5], 48
cmp x8, x4
bne .L4
But GCC 11 instead uses lane stores:
.L4:
ld3 {v4.4s - v6.4s}, [x9], 48
mov x8, x4
ld3 {v16.4s - v18.4s}, [x11], 48
add x16, x4, 24
add x15, x4, 36
add x14, x4, 16
add x13, x4, 28
add x12, x4, 40
add v2.4s, v16.4s, v4.4s
add x7, x4, 20
sub v1.4s, v5.4s, v17.4s
add x6, x4, 32
orr v0.16b, v18.16b, v6.16b
add x5, x4, 44
add x4, x4, 48
str s2, [x8], 12
st1 {v2.s}[1], [x8]
st1 {v2.s}[2], [x16]
st1 {v2.s}[3], [x15]
str s1, [x4, -44]
st1 {v1.s}[1], [x14]
st1 {v1.s}[2], [x13]
st1 {v1.s}[3], [x12]
str s0, [x4, -40]
st1 {v0.s}[1], [x7]
st1 {v0.s}[2], [x6]
st1 {v0.s}[3], [x5]
cmp x10, x9
bne .L4
I think this is due to r11-3966 optimistically splitting store groups
in a way that we can't recover from if SLP subsequently fails.
Maybe the easiest thing for GCC 11 would be to block the split if the
target supports IFN_STORE_LANES for the group size and element type.
That restores the above case. Of the two tests affected by r11-3966,
vect-complex-5.c seems better with LD2 & ST4, while the motivating
case (pr97428.c) still uses SLP as intended.
[Bug c++/99869] [11 Regression] ICE: in do_auto_deduction, at cp/pt.c:29620
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99869 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2021-04-01 Ever confirmed|0 |1 Priority|P3 |P1 Target Milestone|--- |11.0 CC||mpolacek at gcc dot gnu.org Summary|ICE: in do_auto_deduction, |[11 Regression] ICE: in |at cp/pt.c:29620|do_auto_deduction, at ||cp/pt.c:29620 --- Comment #1 from Marek Polacek --- Confirmed. Also tarted with r11-7540. Patrick, can you please take a look at this one too?
[Bug c++/99869] [11 Regression] ICE: in do_auto_deduction, at cp/pt.c:29620
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99869 Marek Polacek changed: What|Removed |Added Keywords||ice-on-valid-code --- Comment #2 from Marek Polacek --- (In reply to Marek Polacek from comment #1) > Confirmed. Also tarted with r11-7540. Patrick, can you please take a look > at this one too? *started
[Bug c++/99874] New: ICE Segmentation fault when declared variable template of template lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99874
Bug ID: 99874
Summary: ICE Segmentation fault when declared variable template
of template lambda
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/4fxhP6jf9
template
auto l = [] requires requires { x; } {};
int main() {
l<0>.template operator()<0>();
}
:2:40: internal compiler error: Segmentation fault
2 | auto l = [] requires requires { x; } {};
|^
0x1cfca39 internal_error(char const*, ...)
???:0
0x917a92 tsubst(tree_node*, tree_node*, int, tree_node*)
???:0
0x73f042 tsubst_requires_expr(tree_node*, tree_node*, int, tree_node*)
???:0
0x73f08a constraints_satisfied_p(tree_node*, tree_node*)
???:0
0x954d48 fn_type_unification(tree_node*, tree_node*, tree_node*, tree_node*
const*, unsigned int, tree_node*, unification_kind_t, int, conversion**, bool,
bool)
???:0
0x6ded59 build_new_method_call(tree_node*, tree_node*, vec**, tree_node*, int, tree_node**, int)
???:0
0x8e126d c_parse_file()
???:0
0xa60292 c_common_parse_file()
???:0
Please submit a full bug report,
with preprocessed source if appropriate.
[Bug c++/99869] [11 Regression] ICE: in do_auto_deduction, at cp/pt.c:29620
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99869 Patrick Palka changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org CC||ppalka at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #3 from Patrick Palka --- I'm on it.
[Bug tree-optimization/99873] [11 Regression] GCC no longer makes as much use of ST3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99873 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot gnu.org Last reconfirmed||2021-04-01 Ever confirmed|0 |1 --- Comment #1 from rsandifo at gcc dot gnu.org --- Testing a patch.
[Bug libstdc++/99875] New: [10 Regression] experimental filesystem fails on Darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99875 Bug ID: 99875 Summary: [10 Regression] experimental filesystem fails on Darwin Product: gcc Version: 10.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: iains at gcc dot gnu.org Target Milestone: --- On the RC1 for 10.3 === libstdc++ Summary === # of unexpected failures51 of the form Excess errors: /src-local/gcc-git-10/libstdc++-v3/testsuite/util/testsuite_fs.h:135: error: '::getpid' has not been declared these were not present at r10-9540.
[Bug libstdc++/99875] [10 Regression] experimental filesystem fails on Darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99875 Iain Sandoe changed: What|Removed |Added Target||x86_64-darwin, i686-darwin Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2021-04-01 --- Comment #1 from Iain Sandoe --- also present for m32 on platform versions supporting this.
[Bug libstdc++/99876] New: std::filesystem::absolute is inefficient
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99876
Bug ID: 99876
Summary: std::filesystem::absolute is inefficient
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: terra at gnome dot org
Target Milestone: ---
Created attachment 50498
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50498&action=edit
Preprocesses source code
The documentation for std::filesystem::absolute states:
"For POSIX-based operating systems, std::filesystem::absolute(p) is equivalent
to std::filesystem::current_path() / p except for when p is the empty path. "
g++ implements it is way -- that is correct, but wasteful.
If the given filename is already absolute, it should be simply returned.
There is no need to call current_path() which leads to a getcwd syscall.
# /usr/local/products/gcc/10.1.0/bin/g++ -std=gnu++17 -Wall -O2 ttt.C
# strace ./a.out 2>&1 | tail
getcwd("/work/nova7/23232/src", 4096) = 22
getcwd("/work/nova7/23232/src", 4096) = 22
getcwd("/work/nova7/23232/src", 4096) = 22
getcwd("/work/nova7/23232/src", 4096) = 22
getcwd("/work/nova7/23232/src", 4096) = 22
getcwd("/work/nova7/23232/src", 4096) = 22
getcwd("/work/nova7/23232/src", 4096) = 22
getcwd("/work/nova7/23232/src", 4096) = 22
exit_group(0) = ?
+++ exited with 0 +++
# cat ttt.C
#include
int
main()
{
std::filesystem::path foo ("/home/welinder");
for (int i = 0; i < 1; i++)
(void)std::filesystem::absolute(foo);
}
# uname -a
Linux monsterd03 5.3.18-lp152.66-default #1 SMP Tue Mar 2 13:18:19 UTC 2021
(73933a3) x86_64 x86_64 x86_64 GNU/Linux
# /usr/local/products/gcc/10.1.0/bin/g++ -v
Using built-in specs.
COLLECT_GCC=/usr/local/products/gcc/10.1.0/bin/g++
COLLECT_LTO_WRAPPER=/usr/local/products/gcc/10.1.0/lib/gcc/x86_64-suse-linux/10.1.0/lto-wrapper
Target: x86_64-suse-linux
Configured with: ../../gcc-10.1.0/configure --enable-languages=c,c++,fortran
--enable-targets=x86_64-suse-linux,i686-suse-linux
--prefix=/usr/local/products/gcc/10.1.0 --with-gnu-as
--with-as=/usr/local/products/gcc/binutils-2.32/bin/as --with-gnu-ld
--with-ld=/usr/local/products/gcc/binutils-2.32/bin/ld --enable-threads=posix
--enable-shared --enable-__cxa_atexit --enable-libstdcxx-allocator=pool
x86_64-suse-linux
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.1.0 (GCC)
[Bug libstdc++/99875] [10 Regression] experimental filesystem fails on Darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99875 Jonathan Wakely changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Status|NEW |ASSIGNED Target Milestone|--- |10.3 --- Comment #2 from Jonathan Wakely --- I backported r11-7220 as r10-9589 but I also need to backport r11-7239
[Bug c++/99584] [11 Regression] ICE Segmentation fault when expanding lambda noexcept specifier with invalid parameter pack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99584 --- Comment #3 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:0cf4813202f19768e31666f6aa82bde4dce4065a commit r11-7953-g0cf4813202f19768e31666f6aa82bde4dce4065a Author: Jason Merrill Date: Thu Apr 1 15:17:40 2021 -0400 c++: variadic lambda noexcept-specifier [PR99583] The tree-walk looking for parameter packs didn't find this one because we weren't stepping into TYPE_RAISES_EXCEPTIONS. gcc/cp/ChangeLog: PR c++/99583 PR c++/99584 * tree.c (cp_walk_subtrees) [FUNCTION_TYPE]: Walk into TYPE_RAISES_EXCEPTIONS. gcc/testsuite/ChangeLog: PR c++/99583 * g++.dg/cpp0x/lambda/lambda-variadic12.C: New test.
[Bug c++/99583] Parameter packs not expanded in lambda noexcept specifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99583 --- Comment #2 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:0cf4813202f19768e31666f6aa82bde4dce4065a commit r11-7953-g0cf4813202f19768e31666f6aa82bde4dce4065a Author: Jason Merrill Date: Thu Apr 1 15:17:40 2021 -0400 c++: variadic lambda noexcept-specifier [PR99583] The tree-walk looking for parameter packs didn't find this one because we weren't stepping into TYPE_RAISES_EXCEPTIONS. gcc/cp/ChangeLog: PR c++/99583 PR c++/99584 * tree.c (cp_walk_subtrees) [FUNCTION_TYPE]: Walk into TYPE_RAISES_EXCEPTIONS. gcc/testsuite/ChangeLog: PR c++/99583 * g++.dg/cpp0x/lambda/lambda-variadic12.C: New test.
[Bug c++/99584] [11 Regression] ICE Segmentation fault when expanding lambda noexcept specifier with invalid parameter pack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99584 Jason Merrill changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 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 Jason Merrill changed: What|Removed |Added CC||jason at gcc dot gnu.org Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #3 from Jason Merrill --- Same issue. *** This bug has been marked as a duplicate of bug 99584 ***
[Bug c++/99584] [11 Regression] ICE Segmentation fault when expanding lambda noexcept specifier with invalid parameter pack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99584 --- Comment #5 from Jason Merrill --- *** Bug 99583 has been marked as a duplicate of this bug. ***
[Bug libstdc++/99096] Several failures in the libstdc++-v3 test suite for x86_64-apple-darwin20.3.0 after r11-7220
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99096 --- Comment #4 from CVS Commits --- The releases/gcc-10 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:3a2dc91d7574d1b03b4e5a8ce4098afb62145c35 commit r10-9653-g3a2dc91d7574d1b03b4e5a8ce4098afb62145c35 Author: Jonathan Wakely Date: Sun Feb 14 20:38:32 2021 + libstdc++: Restore in testsuite_fs.h header [PR 99096] libstdc++-v3/ChangeLog: PR libstdc++/99096 * testsuite/util/testsuite_fs.h: Always include . (cherry picked from commit 4e3590d06cf8a06fcc460ccda6150483a0311bae)
[Bug libstdc++/99875] [10 Regression] experimental filesystem fails on Darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99875 Jonathan Wakely changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from Jonathan Wakely --- Should be fixed at r10-9653
[Bug libstdc++/99876] std::filesystem::absolute is inefficient
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99876
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2021-04-01
Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0 |1
--- Comment #1 from Jonathan Wakely ---
(In reply to M Welinder from comment #0)
> If the given filename is already absolute, it should be simply returned.
> There is no need to call current_path() which leads to a getcwd syscall.
Yes we already do that for the overload with an error_code parameter:
fs::path
fs::absolute(const path& p, error_code& ec)
{
path ret;
if (p.empty())
{
ec = make_error_code(std::errc::invalid_argument);
return ret;
}
ec.clear();
if (p.is_absolute())
{
ret = p;
return ret;
}
[Bug libstdc++/99876] std::filesystem::absolute is inefficient
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99876
--- Comment #2 from Jonathan Wakely ---
--- a/libstdc++-v3/src/c++17/fs_ops.cc
+++ b/libstdc++-v3/src/c++17/fs_ops.cc
@@ -65,19 +65,12 @@ namespace posix = std::filesystem::__gnu_posix;
fs::path
fs::absolute(const path& p)
{
-#ifdef _GLIBCXX_FILESYSTEM_IS_WINDOWS
error_code ec;
path ret = absolute(p, ec);
if (ec)
_GLIBCXX_THROW_OR_ABORT(filesystem_error("cannot make absolute path", p,
ec));
return ret;
-#else
- if (p.empty())
-_GLIBCXX_THROW_OR_ABORT(filesystem_error("cannot make absolute path", p,
- make_error_code(std::errc::invalid_argument)));
- return current_path() / p;
-#endif
}
fs::path
[Bug tree-optimization/78394] False positives of maybe-uninitialized with -Og
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78394
Martin Sebor changed:
What|Removed |Added
Last reconfirmed|2017-07-20 00:00:00 |2021-4-1
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 #16 from Martin Sebor ---
Reconfirming with GCC 11. Both instances of the warning go back as far as
support for -Og so it's not a regression.
With my patched GCC the output for just the first function is:
pr78394.C: In function ‘float foo()’:
pr78394.C:19:17: warning: ‘vy’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
19 | return vx + vy;
| ^~
pr78394.C:13:15: note: used when ‘(a <= i)’
13 | float vx, vy;
| ^~
pr78394.C:13:15: note: ‘vy’ was declared here
pr78394.C:19:17: warning: ‘vx’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
19 | return vx + vy;
| ^~
pr78394.C:13:11: note: used when ‘(a <= i)’
13 | float vx, vy;
| ^~
pr78394.C:13:11: note: ‘vx’ was declared here
The dump the warning sees is below as as noted the root cause is that the IL
satisfies the conditions under which it's designed to trigger. So the only
ways to avoid it would seem to be to either a) extend the warning to figure out
that the condition it uses cannot happen (basically implement some of the
optimizations disabled at -Og) or b) turn off -Wmaybe-uninitialized at -Og
(i.e,. remove it from -Wall). I'm not in favor of (a) but (b) makes sense to
me. I'd like to try to improve it for GCC 12 so unless I fail at that I'm not
for disabling it at other optimization levels.
float foo ()
{
int i;
float vy;
float vx;
int a;
float _6;
float _8;
[local count: 118111600]:
# VUSE <.MEM_4(D)>
a_5 = b;
if (a_5 <= 3)
goto ; [50.00%]
else
goto ; [50.00%]
[local count: 59055800]:
goto ; [100.00%]
[local count: 59055800]:
[local count: 118111600]:
# a_1 = PHI
goto ; [100.00%]
[local count: 955630225]:
_8 = (float) i_2;
i_7 = i_2 + 1;
[local count: 1073741824]:
# i_2 = PHI <1(4), i_7(5)>
# .MEM_3 = PHI <.MEM_4(D)(4), .MEM_3(5)>
# vx_9 = PHI
# vy_10 = PHI
if (a_1 > i_2)
goto ; [89.00%]
else
goto ; [11.00%]
[local count: 118111600]:
_6 = vx_9 + vy_10;
# VUSE <.MEM_3>
return _6;
}
[Bug c++/99805] [9/10/11 Regression] filesystem::path::parent_path got a wrong path
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99805
--- Comment #4 from Jonathan Wakely ---
Wow, this is tricksy.
The bug happens when parsing the string into a path. The path is split into
components and the offset of each component from the beginning of the string is
stored, so that parent_path() can efficiently erase the part of the native()
string that refers to the last component. The offset is calculated like this:
for (auto& c : buf)
{
auto pos = c.str.data() - _M_pathname.data();
::new(output++) _Cmpt(c.str, c.type, pos);
++_M_cmpts._M_impl->_M_size;
}
The bug is that for the COW std::string _M_pathname.data() causes the string to
be reallocated, and so changes the address at which the string is stored. So
the string_view c.str no longer refers to the same data as _M_pathname. We get
a bogus offset for the components, and when we try to remove the last component
to get the parent_path(), we don't remove anything from the string.
[Bug sanitizer/99877] New: Crash in GIMPLE pass:sanopt in huge function using OpenMP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99877 Bug ID: 99877 Summary: Crash in GIMPLE pass:sanopt in huge function using OpenMP Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: carl.nettelblad at it dot uu.se CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at gcc dot gnu.org Target Milestone: --- Created attachment 50499 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50499&action=edit Command line and output This code has worked (seemingly) just fine until the new function computecandcliques was added, with a heap corruption bug (in my own code). When trying to track this bug down, I tried to compile the thing with address sanitizer, but I kept getting crashes even when successively reducing optimization settings and trying a few other things. I know this is certainly not a minimal test case, but I hope it is reproducible for you with these files. I did confirm crashes with very similar error output on optimization levels 3 to 1 and on various versions of GCC 9.x and 10.x. I don't have ready access to 10.2.1, though.
