[Bug c++/98232] [9 Regression] ICE when compiling libreoffice
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98232 Richard Biener changed: What|Removed |Added Summary|[9 branch] [regression] ICE |[9 Regression] ICE when |when compiling libreoffice |compiling libreoffice Last reconfirmed||2020-12-11 Keywords||ice-on-valid-code Status|UNCONFIRMED |WAITING Known to work||9.3.0 Known to fail||9.3.1 Ever confirmed|0 |1 Priority|P3 |P1 Target Milestone|--- |9.4 --- Comment #1 from Richard Biener --- Please provide preprocessed source of vcldemo.cxx and the G++ command-line options used as well as the host/target you are compiling on/for.
[Bug ada/98228] [11 Regression] ICE: Assert_Failure atree.adb:931: Error detected at s-gearop.adb:382:34 [a-ngrear.adb:313:7 [a-nllrar.ads:18:1]] on s390x-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98228 Richard Biener changed: What|Removed |Added Target Milestone|--- |11.0 Keywords||build
[Bug middle-end/98227] [11 Regression] ICE: tree check: expected tree that contains 'decl common' structure, have 'constructor' in get_section, at varasm.c:297 on riscv64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98227 Richard Biener changed: What|Removed |Added Target Milestone|--- |11.0 Keywords||build Component|ada |middle-end Priority|P3 |P1 CC||hjl.tools at gmail dot com --- Comment #1 from Richard Biener --- Looks like get_section is also called for CTORs and 'decl' isn't very well named.
[Bug tree-optimization/98234] [11 Regression] OOM at -O2 for PR91257 testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98234 Richard Biener changed: What|Removed |Added Target Milestone|--- |11.0 Keywords||memory-hog CC||amacleod at redhat dot com --- Comment #1 from Richard Biener --- Note this was tested before the g:7f359556a772e26eabf8d31e53aae1de6f2f200d
[Bug tree-optimization/98234] New: [11 Regression] OOM at -O2 for PR91257 testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98234 Bug ID: 98234 Summary: [11 Regression] OOM at -O2 for PR91257 testcase Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: rguenth at gcc dot gnu.org Target Milestone: --- > /usr/bin/time gcc-10 -S pr91257.c -O2 pr91257.c: In function 'gen_opt': pr91257.c:291:6: warning: implicit declaration of function 'asdf' [-Wimplicit-function-declaration] 291 | v0 = asdf(41, 28120, 584); | ^~~~ pr91257.c:294:1: warning: implicit declaration of function 'call_err' [-Wimplicit-function-declaration] 294 | call_err(reg); | ^~~~ 28.60user 0.41system 0:29.04elapsed 99%CPU (0avgtext+0avgdata 1377844maxresident)k 49464inputs+0outputs (7major+648860minor)pagefaults 0swaps > /usr/bin/time ~/install/gcc-11.0/usr/local/bin/gcc -S pr91257.c -O2 pr91257.c: In function 'gen_opt': pr91257.c:291:6: warning: implicit declaration of function 'asdf' [-Wimplicit-function-declaration] 291 | v0 = asdf(41, 28120, 584); | ^~~~ pr91257.c:294:1: warning: implicit declaration of function 'call_err' [-Wimplicit-function-declaration] 294 | call_err(reg); | ^~~~ gcc: fatal error: Killed signal terminated program cc1 compilation terminated. Command exited with non-zero status 1 23.79user 5.15system 0:30.29elapsed 95%CPU (0avgtext+0avgdata 32175084maxresident)k 388216inputs+0outputs (4037major+8529324minor)pagefaults 0swaps at ~7GB a backtrace is #0 0x7739c2e7 in __memset_avx2_unaligned_erms () from /lib64/libc.so.6 #1 0x01803865 in ssa_block_ranges::ssa_block_ranges ( this=0x1b0593ab0, t=0x770595e8, allocator=) at /home/rguenther/src/trunk/gcc/gimple-range-cache.cc:147 #2 0x01803eb9 in block_range_cache::get_block_ranges (this=0x290a238, name=) at /home/rguenther/src/trunk/gcc/tree.h:3450 #3 0x01804758 in block_range_cache::set_bb_range (r=..., bb=0x76f36410, name=0x7fffddb457e0, this=0x290a238) at /home/rguenther/src/trunk/gcc/gimple-range-cache.cc:1016 #4 ranger_cache::fill_block_cache (this=0x290a0e0, name=0x7fffddb457e0, bb=0x76f36410, def_bb=0x76f363a8) at /home/rguenther/src/trunk/gcc/gimple-range-cache.cc:1016 ... #16 0x0180c017 in execute_early_vrp () at /home/rguenther/src/trunk/gcc/gimple-ssa-evrp.c:349 and finishing frames never leaves EVRP before going OOM. -O2 -fno-tree-vrp finishes with 30.27user 0.42system 0:30.76elapsed 99%CPU (0avgtext+0avgdata 1555304maxresident)k 62736inputs+0outputs (72major+610841minor)pagefaults 0swaps
[Bug fortran/68778] [F03] Missing default initialization of finalized derived types type(C_PTR) component in subroutines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68778 Ev Drikos changed: What|Removed |Added CC||drikosev at gmail dot com --- Comment #6 from Ev Drikos --- (In reply to janus from comment #5) > ... > With current trunk I always get F, so apparently this has been fixed on > trunk. > > Can anyone confirm this? The chances are that this has been fixed! $ gfortran8 pr68778-00.f90 $ ./a.out TEST2: ASSOCIATED? (EXPECT: F) F (20 times) $ gfortran8 -v Using built-in specs. COLLECT_GCC=gfortran8 COLLECT_LTO_WRAPPER=/opt/local/libexec/gcc/x86_64-apple-darwin18.7.0/8.4.0/lto-wrapper Target: x86_64-apple-darwin18.7.0 Configured with: ../gcc-8.4.0/configure --prefix=/opt/local --program-suffix=8 --enable-languages=lto,c,c++,fortran --enable-checking=release --disable-nls --with-system-zlib CC=/usr/local/bin/gcc CXX=/usr/local/bin/g++ CPP=/usr/local/bin/cpp GCC=/usr/local/bin/gcc CC_FOR_TARGET=/usr/local/bin/gcc CXX_FOR_TARGET=/usr/local/bin/g++ CPP_FOR_TARGET=/usr/local/bin/cpp GCC_FOR_TARGET=/usr/local/bin/gcc Thread model: posix gcc version 8.4.0 (GCC)
[Bug libstdc++/98233] New: A small bug in stl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98233
Bug ID: 98233
Summary: A small bug in stl
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: 570070308 at qq dot com
Target Milestone: ---
In the code
```
#include
#include
struct A
{
public:
int a;
std::vector m;
};
int main()
{
A x;
x.m.emplace_back();
x.a=13;
x.m[0].a=9;
printf("%d\n",x.m[0].a);
x.m[0]=x;
printf("%d\n",x.m[0].m[0].a);
return 0;
}
```
expect to output 9 and 9.
But the result is 9 and 13.
[Bug c++/98232] New: [9 branch] [regression] ICE when compiling libreoffice
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98232
Bug ID: 98232
Summary: [9 branch] [regression] ICE when compiling libreoffice
Product: gcc
Version: 9.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: me at hussam dot eu.org
Target Milestone: ---
this worked in the 20201120 snapshot and broke in the 20201127 snapshot.
[CXX] vcl/workben/vcldemo.cxx
/home/hussam/cache/system/libreoffice/src/libreoffice/vcl/workben/vcldemo.cxx:
In destructor ‘virtual {anonymous}::DemoWin::RenderThread::~RenderThread()’:
/home/hussam/cache/system/libreoffice/src/libreoffice/vcl/workben/vcldemo.cxx:1726:18:
internal compiler error: Segmentation fault
1726 | join();
I don't know what other information to provide.
Let me know please.
[Bug c++/98231] [11 Regression] bogus error: no match for ‘operator<<’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98231 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Target Milestone|--- |11.0 Priority|P3 |P1 Last reconfirmed||2020-12-11 Ever confirmed|0 |1 Keywords||rejects-valid CC||nathan at gcc dot gnu.org
[Bug c++/98231] New: [11 Regression] bogus error: no match for ‘operator<<’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98231
Bug ID: 98231
Summary: [11 Regression] bogus error: no match for ‘operator<<’
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mpolacek at gcc dot gnu.org
Target Milestone: ---
template struct basic_ostream {};
namespace N {
template
void operator<<(basic_ostream, T);
}
basic_ostream os;
template void
foo (T value)
{
using N::operator<<;
os << value;
}
void bar() { foo (1); }
gives
$ ./cc1plus -quiet ceph.C
ceph.C: In instantiation of ‘void foo(T) [with T = int]’:
ceph.C:14:20: required from here
ceph.C:12:6: error: no match for ‘operator<<’ (operand types are
‘basic_ostream’ and ‘int’)
12 | os << value;
| ~~~^~~~
Started with r11-4690.
[Bug testsuite/98208] make check's check-fixincludes fails in sys/types.h around AIX_PHYSADR_T_CHECK
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98208 --- Comment #10 from Ilya Leoshkevich --- I've posted the combined fixincludes/tests/base/sys/types.h + genfixes patch here: https://gcc.gnu.org/pipermail/gcc-patches/2020-December/561601.html
[Bug rtl-optimization/98212] [10 Regression] X86 unoptimal code for float equallity comparison followed by jump
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98212 Jakub Jelinek changed: What|Removed |Added Summary|[10/11 Regression] X86 |[10 Regression] X86 |unoptimal code for float|unoptimal code for float |equallity comparison|equallity comparison |followed by jump|followed by jump --- Comment #9 from Jakub Jelinek --- Fixed on the trunk. Not sure about backports, seems too risky to me.
[Bug rtl-optimization/98212] [10/11 Regression] X86 unoptimal code for float equallity comparison followed by jump
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98212
--- Comment #8 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:a5c05005499dd323296008fda4f414d8647adf0c
commit r11-5923-ga5c05005499dd323296008fda4f414d8647adf0c
Author: Jakub Jelinek
Date: Fri Dec 11 00:36:21 2020 +0100
dojump: Fix up probabilities splitting in dojump.c comparison splitting
[PR98212]
When compiling:
void foo (void);
void bar (float a, float b) { if (__builtin_expect (a != b, 1)) foo (); }
void baz (float a, float b) { if (__builtin_expect (a == b, 1)) foo (); }
void qux (float a, float b) { if (__builtin_expect (a != b, 0)) foo (); }
void corge (float a, float b) { if (__builtin_expect (a == b, 0)) foo (); }
on x86_64, we get (unimportant cruft removed):
bar:ucomiss %xmm1, %xmm0
jp .L4
je .L1
.L4:jmp foo
.L1:ret
baz:ucomiss %xmm1, %xmm0
jp .L6
jne .L6
jmp foo
.L6:ret
qux:ucomiss %xmm1, %xmm0
jp .L13
jne .L13
ret
.L13: jmp foo
corge: ucomiss %xmm1, %xmm0
jnp .L18
.L14: ret
.L18: jne .L14
jmp foo
(note for bar and qux that changed with a patch I've posted earlier today).
This is all reasonable, except the last function, the overall jump to
the tail call is predicted unlikely (10%), so it is good jmp foo isn't on
the straight line path, but NaNs are (or should be) considered very
unlikely
in the programs, so IMHO the right code (and one emitted with the following
patch) is:
corge: ucomiss %xmm1, %xmm0
jp .L14
je .L18
.L14: ret
.L18: jmp foo
Let's discuss the probabilities in the above testcase:
for !and_them it looks all correct, so for
bar we split
if (a != b) goto t; // prob 90%
goto f;
into:
if (a unord b) goto t; // first_prob = prob * cprob = 90% * 1% = 0.9%
if (a ltgt b) goto t; // adjusted prob = (prob - first_prob) / (1 -
first_prob) = (90% - 0.9%) / (1 - 0.9%) = 89.909%
and for qux we split
if (a != b) goto t; // prob 10%
goto f;
into:
if (a unord b) goto t; // first_prob = prob * cprob = 10% * 1% = 0.1%
if (a ltgt b) goto t; // adjusted prob = (prob - first_prob) / (1 -
first_prob) = (10% - 0.1%) / (1 - 0.1%) = 9.910%
Now, the and_them cases should be probability wise exactly the same
if we swap the f and t labels, because baz
if (a == b) goto t; // prob 90%
goto f;
is equivalent to:
if (a != b) goto f; // prob 10%
goto t;
which is in qux. This means we could expand baz as:
if (a unord b) goto f; // 0.1%
if (a ltgt b) goto f; // 9.910%
goto t;
But we don't expand it exactly that way, but instead (as the comment says)
as:
if (a ord b) ; else goto f; // first_prob as probability of ;
if (a uneq b) goto t; // adjusted prob
goto f;
So, first_prob.invert () should be 0.1% and adjusted prob should be
1 - 9.910%.
Thus, the right thing is 4 inverts:
prob = prob.invert (); // baz is equivalent to qux with swap(t, f) and thus
inverted original prob
first_prob = prob.split (cprob.invert ()).invert ();
// cprob.invert because by doing if (cond) ; else goto f; we effectively
invert the condition
// the second invert because first_prob is probability of ; rather than
goto f
prob = prob.invert (); // lastly because adjusted prob we want is
// probability of goto t;, while the one from corresponding !and_them case
// would be if (...) goto f; goto t;
2020-12-11 Jakub Jelinek
PR rtl-optimization/98212
* dojump.c (do_compare_rtx_and_jump): Change computation of
first_prob for and_them. Add comment explaining and_them case.
* gcc.dg/predict-8.c: Adjust expected probability.
[Bug libstdc++/98226] Slow std::countr_one
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98226 --- Comment #5 from Jonathan Wakely --- I've removed some redundant code from them, but not changed the indirection that this PR complains about. I don't plan to change that.
[Bug libstdc++/98226] Slow std::countr_one
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98226 --- Comment #4 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:2ea62857a3fbdf091ba38cbb62e98dc76b198e2e commit r11-5922-g2ea62857a3fbdf091ba38cbb62e98dc76b198e2e Author: Jonathan Wakely Date: Thu Dec 10 21:57:42 2020 + libstdc++: Remove redundant branches in countl_one and countr_one [PR 98226] There's no need to explicitly check for the maximum value, because the function we call handles it correctly anyway. libstdc++-v3/ChangeLog: PR libstdc++/98226 * include/std/bit (__countl_one, __countr_one): Remove redundant branches.
[Bug ada/98230] incorrect Type'Mod during a loop whose range is computed by a variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98230 --- Comment #9 from Adam Van Ymeren --- Awesome thanks!
[Bug tree-optimization/98174] [11 Regression] Ranger takes too much memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98174 --- Comment #4 from CVS Commits --- The master branch has been updated by Andrew Macleod : https://gcc.gnu.org/g:7f359556a772e26eabf8d31e53aae1de6f2f200d commit r11-5921-g7f359556a772e26eabf8d31e53aae1de6f2f200d Author: Andrew MacLeod Date: Thu Dec 10 14:59:14 2020 -0500 Reduce memory requirements for ranger Calculate block exit info upfront, and then any SSA_NAME which is never used in an outgoing range calculation is a pure global and can bypass the on-entry cache. PR tree-optimization/98174 * gimple-range-cache.cc (ranger_cache::ssa_range_in_bb): Only push poor values to be examined if it isn't a pure global. (ranger_cache::block_range): Don't process pure globals. (ranger_cache::fill_block_cache): Adjust has_edge_range call. * gimple-range-gori.cc (gori_map::all_outgoing): New bitmap. (gori_map::gori_map): Allocate all_outgoing. (gori_map::is_export_p): No specified BB returns global context. (gori_map::calculate_gori): Accumulate each block into global. (gori_compute::gori_compute): Preprocess each block for exports. (gori_compute::has_edge_range_p): No edge returns global context. * gimple-range-gori.h (has_edge_range_p): Provide default parameter.
[Bug ada/98230] incorrect Type'Mod during a loop whose range is computed by a variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98230 Eric Botcazou changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #8 from Eric Botcazou --- Fixed on all branches.
[Bug ada/98230] incorrect Type'Mod during a loop whose range is computed by a variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98230 --- Comment #7 from CVS Commits --- The releases/gcc-8 branch has been updated by Eric Botcazou : https://gcc.gnu.org/g:87c40733898283f0d1e48bcbf8055c2718064e77 commit r8-10673-g87c40733898283f0d1e48bcbf8055c2718064e77 Author: Ed Schonberg Date: Thu Dec 10 22:26:57 2020 +0100 Fix PR ada/98230 It's a rather curious malfunction of the 'Mod attribute applied to the variable of a loop whose upper bound is dynamic. gcc/ada/ChangeLog: PR ada/98230 * exp_attr.adb (Expand_N_Attribute_Reference, case Mod): Use base type of argument to obtain static bound and required size. gcc/testsuite/ChangeLog: * gnat.dg/modular6.adb: New test.
[Bug ada/98230] incorrect Type'Mod during a loop whose range is computed by a variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98230 --- Comment #6 from CVS Commits --- The releases/gcc-9 branch has been updated by Eric Botcazou : https://gcc.gnu.org/g:da6e672dc9bbedb993a5fea498954f0ca861b7ec commit r9-9107-gda6e672dc9bbedb993a5fea498954f0ca861b7ec Author: Ed Schonberg Date: Thu Dec 10 22:26:57 2020 +0100 Fix PR ada/98230 It's a rather curious malfunction of the 'Mod attribute applied to the variable of a loop whose upper bound is dynamic. gcc/ada/ChangeLog: PR ada/98230 * exp_attr.adb (Expand_N_Attribute_Reference, case Mod): Use base type of argument to obtain static bound and required size. gcc/testsuite/ChangeLog: * gnat.dg/modular6.adb: New test.
[Bug ada/98230] incorrect Type'Mod during a loop whose range is computed by a variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98230 --- Comment #5 from CVS Commits --- The releases/gcc-10 branch has been updated by Eric Botcazou : https://gcc.gnu.org/g:bc7d2977d108ed00c30c9f21d5701f28ffb50f29 commit r10-9137-gbc7d2977d108ed00c30c9f21d5701f28ffb50f29 Author: Ed Schonberg Date: Thu Dec 10 22:26:57 2020 +0100 Fix PR ada/98230 It's a rather curious malfunction of the 'Mod attribute applied to the variable of a loop whose upper bound is dynamic. gcc/ada/ChangeLog: PR ada/98230 * exp_attr.adb (Expand_N_Attribute_Reference, case Mod): Use base type of argument to obtain static bound and required size. gcc/testsuite/ChangeLog: * gnat.dg/modular6.adb: New test.
[Bug ada/98230] incorrect Type'Mod during a loop whose range is computed by a variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98230 --- Comment #4 from CVS Commits --- The master branch has been updated by Eric Botcazou : https://gcc.gnu.org/g:779bf1823ced0814803d2be7f7ded0317e70140c commit r11-5920-g779bf1823ced0814803d2be7f7ded0317e70140c Author: Ed Schonberg Date: Thu Dec 10 22:26:57 2020 +0100 Fix PR ada/98230 It's a rather curious malfunction of the 'Mod attribute applied to the variable of a loop whose upper bound is dynamic. gcc/ada/ChangeLog: PR ada/98230 * exp_attr.adb (Expand_N_Attribute_Reference, case Mod): Use base type of argument to obtain static bound and required size. gcc/testsuite/ChangeLog: * gnat.dg/modular6.adb: New test.
[Bug c++/91506] Incorrectly issued error: parameter may not have variably modified type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91506 Marek Polacek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Marek Polacek --- Fixed in GCC 11.
[Bug c++/91506] Incorrectly issued error: parameter may not have variably modified type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91506 --- Comment #3 from CVS Commits --- The master branch has been updated by Marek Polacek : https://gcc.gnu.org/g:96a5c483afbe0cb3fb037641bf2b5658531d9255 commit r11-5917-g96a5c483afbe0cb3fb037641bf2b5658531d9255 Author: Marek Polacek Date: Thu Dec 10 15:34:19 2020 -0500 c++: Add fixed test [PR91506] Pre-r11-557 we issued a bogus error: parameter may not have variably modified type 'double [x]' but now we compile this, as we should. gcc/testsuite/ChangeLog: PR c++/91506 * g++.dg/init/array60.C: New test.
[Bug ada/98230] incorrect Type'Mod during a loop whose range is computed by a variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98230 Eric Botcazou changed: What|Removed |Added Target Milestone|--- |8.5 Summary|Incorrect Type'Mod during a |incorrect Type'Mod during a |loop whose range is |loop whose range is |computed by a variable |computed by a variable
[Bug ada/98230] Bug in Type'Modulus during a loop whose range is computed by a variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98230 Eric Botcazou changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot gnu.org --- Comment #3 from Eric Botcazou --- Investigating.
[Bug ada/98230] Bug in Type'Modulus during a loop whose range is computed by a variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98230 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-12-10 Ever confirmed|0 |1 CC||ebotcazou at gcc dot gnu.org --- Comment #2 from Eric Botcazou --- Rather curious indeed.
[Bug c++/91506] Incorrectly issued error: parameter may not have variably modified type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91506 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org CC||mpolacek at gcc dot gnu.org --- Comment #2 from Marek Polacek --- Fixed by r11-557.
[Bug c++/63707] Brace initialization of array sometimes fails if no copy constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63707 --- Comment #13 from Jakub Jelinek --- At least for #c5 the important difference between that testcase and // ~Child (); which is accepted is I think since r0-113052-ge2df21bfc6c81b4bc410a42002c8427454ffa628 in the cp/init.c (perform_member_init) code: 888 /* A FIELD_DECL doesn't really have a suitable lifetime, but 889 make_temporary_var_for_ref_to_temp will treat it as automatic and 890 set_up_extended_ref_temp wants to use the decl in a warning. */ 891 init = extend_ref_init_temps (member, init, ); 892 if (TREE_CODE (type) == ARRAY_TYPE 893 && TYPE_HAS_NONTRIVIAL_DESTRUCTOR (TREE_TYPE (type))) 894 init = build_vec_init_expr (type, init, tf_warning_or_error); If it has trivial destructor, nothing calls build_vec_init_expr and the copy ctor isn't needed, but when it is called, it is needed. I think in this case extend_ref_init_temps doesn't do anything at all, so it is unclear if build_vec_init_expr is needed too or not.
[Bug ada/98230] Bug in Type'Modulus during a loop whose range is computed by a variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98230 --- Comment #1 from Adam Van Ymeren --- Forgot some details === output of gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/8/lto-wrapper OFFLOAD_TARGET_NAMES=nvptx-none OFFLOAD_TARGET_DEFAULT=1 Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 8.3.0-6' --with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr --with-gcc-major-version-only --program-suffix=-8 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --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-libmpx --enable-plugin --enable-default-pie --with-system-zlib --with-target-system-zlib --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 8.3.0 (Debian 8.3.0-6)
[Bug ada/98230] New: Bug in Type'Modulus during a loop whose range is computed by a variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98230 Bug ID: 98230 Summary: Bug in Type'Modulus during a loop whose range is computed by a variable Product: gcc Version: 8.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: adam at vany dot ca Target Milestone: --- Created attachment 49732 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49732=edit Source code to reproduce The T'Modulus of a type appears to change during a loop with a computed range. The bug does not reproduce if the loop has a fixed range (range 1 .. 30 instead of range 1 .. Max). It also does not reproduce if T'Mod is not called during the loop. Output N: 1 Modulus: 3 Mod: 1 N: 2 Modulus: 3 Mod: 2 N: 3 Modulus: 3 Mod: 3 N: 4 Modulus: 3 Mod: 4 N: 5 Modulus: 3 Mod: 5 N: 6 Modulus: 3 Mod: 6 N: 7 Modulus: 3 Mod: 7 N: 8 Modulus: 3 Mod: 8 N: 9 Modulus: 3 Mod: 9 N: 10 Modulus:03 Mod: 10 N: 11 Modulus:13 Mod: 11 N: 12 Modulus:23 Mod: 12 N: 13 Modulus:33 Mod: 13 N: 14 Modulus:43 Mod: 14 N: 15 Modulus:53 Mod: 15 N: 16 Modulus:63 Mod: 16 N: 17 Modulus:73 Mod: 17 N: 18 Modulus:83 Mod: 18 N: 19 Modulus:93 Mod: 19 N: 20 Modulus:03 Mod: 20 N: 21 Modulus:13 Mod: 21 N: 22 Modulus:23 Mod: 22 N: 23 Modulus:33 Mod: 23 N: 24 Modulus:43 Mod: 24 N: 25 Modulus:53 Mod: 25 N: 26 Modulus:63 Mod: 26 N: 27 Modulus:73 Mod: 27 N: 28 Modulus:83 Mod: 28 N: 29 Modulus:93 Mod: 29 N: 30 Modulus:03 Mod: 30 === Expected output Modulus should not change, it should always be 3, Mod: should always stay in the range 0-3. If the loop is change to 1 .. 30, instead of 1 .. Max, it works as expected.
[Bug c++/59238] Dynamic allocating a list-initialized object of a type with private destructor fails.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59238 --- Comment #6 from Jakub Jelinek --- Fixed on the trunk now, not sure if this should be eventually backported or not.
[Bug tree-optimization/98169] isnan pattern not folded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98169 Jakub Jelinek changed: What|Removed |Added Target Milestone|--- |11.0 Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #8 from Jakub Jelinek --- Ok, thanks, the rest is now fixed.
[Bug tree-optimization/98169] isnan pattern not folded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98169 --- Comment #7 from Uroš Bizjak --- (In reply to Jakub Jelinek from comment #6) > Not familiar with the 64-bit vector support myself, CCing Uros on that. PR98218
[Bug rtl-optimization/98229] [11 Regression] ICE at -O1 in 32-bit mode on x86_64-pc-linux-gnu in decompose, at rtl.h:2282
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98229 --- Comment #1 from Jakub Jelinek --- Created attachment 49731 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49731=edit gcc11-pr98229.patch Untested fix.
[Bug libstdc++/98226] Slow std::countr_one
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98226 --- Comment #3 from Andrew Pinski --- (In reply to Jonathan Wakely from comment #2) > Oh, but you didn't enable any optimization at all, so who cares about the > performance? I was thinking the same.
[Bug rtl-optimization/98229] [11 Regression] ICE at -O1 in 32-bit mode on x86_64-pc-linux-gnu in decompose, at rtl.h:2282
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98229 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Last reconfirmed||2020-12-10 Summary|ICE at -O1 in 32-bit mode |[11 Regression] ICE at -O1 |on x86_64-pc-linux-gnu in |in 32-bit mode on |decompose, at rtl.h:2282|x86_64-pc-linux-gnu in ||decompose, at rtl.h:2282 Target Milestone|--- |11.0 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Priority|P3 |P1 CC||jakub at gcc dot gnu.org
[Bug c++/98216] [C++20] std::array template parameter error with negative values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98216 --- Comment #4 from Emmanuel Le Trong --- Looking at the symbols in your snippet: $ nm -C toto | grep wrapper 00402030 u wrapper::arr That looks like a weird NaN to me.
[Bug tree-optimization/98169] isnan pattern not folded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98169
Jakub Jelinek changed:
What|Removed |Added
CC||uros at gcc dot gnu.org
--- Comment #6 from Jakub Jelinek ---
(In reply to denis.campredon from comment #2)
> This also applies to vector types.
>
> ---
> typedef float __attribute__((vector_size(8))) T;
>
> T f(T a) {
> return a != a;
> }
That is a MMX-ish type, with:
typedef float __attribute__((vector_size(16))) T;
T f(T a) {
return a != a;
}
I get the expected
cmpneqps%xmm0, %xmm0
Not familiar with the 64-bit vector support myself, CCing Uros on that.
[Bug rtl-optimization/98229] New: ICE at -O1 in 32-bit mode on x86_64-pc-linux-gnu in decompose, at rtl.h:2282
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98229
Bug ID: 98229
Summary: ICE at -O1 in 32-bit mode on x86_64-pc-linux-gnu in
decompose, at rtl.h:2282
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: zhendong.su at inf dot ethz.ch
Target Milestone: ---
[555] % 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.0/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.0 20201210 (experimental) [master revision
b46dd03fe94:30c63a5c82a:afc14c8d0a9e7af13698a7eec84226a3cc4b0e67] (GCC)
[556] %
[556] % gcctk -m32 -O0 -c small.c
[557] %
[557] % gcctk -m32 -O1 -c small.c
during RTL pass: expand
small.c: In function ‘f’:
small.c:2:14: internal compiler error: in decompose, at rtl.h:2282
2 | void f() { a = a % ~0UL; }
|~~^~
0x927acb wi::int_traits >::decompose(long*,
unsigned int, std::pair const&)
../../gcc-trunk/gcc/rtl.h:2280
0x927acb wide_int_ref_storage::wide_int_ref_storage
>(std::pair const&)
../../gcc-trunk/gcc/wide-int.h:1025
0x927acb generic_wide_int
>::generic_wide_int >(std::pair const&)
../../gcc-trunk/gcc/wide-int.h:782
0x927acb wide_int_storage::wide_int_storage
>(std::pair const&)
../../gcc-trunk/gcc/wide-int.h:1115
0x927acb
generic_wide_int::generic_wide_int >(std::pair const&)
../../gcc-trunk/gcc/wide-int.h:782
0x927acb expand_divmod(int, tree_code, machine_mode, rtx_def*, rtx_def*,
rtx_def*, int, optab_methods)
../../gcc-trunk/gcc/expmed.c:4214
0xbec854 expand_doubleword_mod
../../gcc-trunk/gcc/optabs.c:1085
0xbecca1 expand_doubleword_divmod(machine_mode, rtx_def*, rtx_def*, rtx_def**,
bool)
../../gcc-trunk/gcc/optabs.c:1159
0xbea858 expand_binop(machine_mode, optab_tag, rtx_def*, rtx_def*, rtx_def*,
int, optab_methods)
../../gcc-trunk/gcc/optabs.c:2119
0xbedf03 sign_expand_binop(machine_mode, optab_tag, optab_tag, rtx_def*,
rtx_def*, rtx_def*, int, optab_methods)
../../gcc-trunk/gcc/optabs.c:2282
0x928606 expand_divmod(int, tree_code, machine_mode, rtx_def*, rtx_def*,
rtx_def*, int, optab_methods)
../../gcc-trunk/gcc/expmed.c:5216
0x938553 expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
../../gcc-trunk/gcc/expr.c:9243
0x93f5e0 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc-trunk/gcc/expr.c:10177
0x94b9d1 store_expr(tree_node*, rtx_def*, int, bool, bool)
../../gcc-trunk/gcc/expr.c:5859
0x94d84f expand_assignment(tree_node*, tree_node*, bool)
../../gcc-trunk/gcc/expr.c:5595
0x7f483a expand_gimple_stmt_1
../../gcc-trunk/gcc/cfgexpand.c:3901
0x7f483a expand_gimple_stmt
../../gcc-trunk/gcc/cfgexpand.c:3999
0x7fc087 expand_gimple_basic_block
../../gcc-trunk/gcc/cfgexpand.c:6036
0x7fe9d6 execute
../../gcc-trunk/gcc/cfgexpand.c:6720
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
[558] %
[558] % cat small.c
unsigned long long a;
void f() { a = a % ~0UL; }
[Bug libstdc++/98226] Slow std::countr_one
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98226 --- Comment #2 from Jonathan Wakely --- Oh, but you didn't enable any optimization at all, so who cares about the performance?
[Bug ada/98228] New: [11 Regression] ICE: Assert_Failure atree.adb:931: Error detected at s-gearop.adb:382:34 [a-ngrear.adb:313:7 [a-nllrar.ads:18:1]] on s390x-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98228 Bug ID: 98228 Summary: [11 Regression] ICE: Assert_Failure atree.adb:931: Error detected at s-gearop.adb:382:34 [a-ngrear.adb:313:7 [a-nllrar.ads:18:1]] on s390x-linux-gnu Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: doko at debian dot org Target Milestone: --- seen with trunk 20201210 on s390x-linux-gnu /<>/build/./gcc/xgcc -B/<>/build/./gcc/ -B/ usr/lib/gcc-snapshot/s390x-linux-gnu/bin/ -B/usr/lib/gcc-snapshot/s390x-linux-gnu/lib/ -isystem /usr/lib/gcc-snapshot/s390x- linux-gnu/include -isystem /usr/lib/gcc-snapshot/s390x-linux-gnu/sys-include -c -g -O2 -fPIC -W -Wall -gnatpg -nostdinc a-nllrar.ads -o a-nllrar.o +===GNAT BUG DETECTED==+ | 11.0.0 20201210 (experimental) [master revision 79c1b9fb44c:3f67ba38dca:8c60696b699e0b22cc12ae628473f0a23f90c82e] (s390x-l inux-gnu) | | Assert_Failure atree.adb:931 | | Error detected at s-gearop.adb:382:34 [a-ngrear.adb:313:7 [a-nllrar.ads:18:1]]| | Please submit a bug report; see https://gcc.gnu.org/bugs/ . | | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact command that you entered. | | Also include sources listed below. | +==+ Please include these source files with error report Note that list may not be accurate in some cases, so please double check that the problem can still be reproduced with the set of files listed. Consider also -gnatd.n switch (see debug.adb). system.ads a-nllrar.ads a-numeri.ads ada.ads a-ngrear.ads s-exctab.ads s-stalib.ads a-unccon.ads a-ngrear.adb a-contai.ads a-cgaaso.ads s-gearop.ads s-secsta.ads s-parame.ads s-stoele.ads s-fatllf.ads s-fatgen.ads a-except.ads s-traent.ads s-gearop.adb s-exnllf.ads compilation abandoned make[9]: *** [../gcc-interface/Makefile:302: a-nllrar.o] Error 1 make[9]: *** Waiting for unfinished jobs gcc configured with: --enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++ --prefix=/usr/lib/gcc-snapshot --with-gcc-major-version-only --program-prefix= --enable-shared --enable-linker-build-id --disable-nls --enable-bootstrap --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libquadmath --disable-libquadmath-support --enable-plugin --with-system-zlib --enable-libphobos-checking=release --with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch=z13 --with-tune=z15 --with-long-double-128 --enable-multilib --enable-checking=yes,extra,rtl --build=s390x-linux-gnu --host=s390x-linux-gnu --target=s390x-linux-gnu --with-build-config=bootstrap-lto-lean --enable-link-serialization=2 building the profiledbootstrap-lean target
[Bug libstdc++/98226] Slow std::countr_one
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98226 --- Comment #1 from Jonathan Wakely --- This seems like an optimizer bug. There is no way I'm going to repeat the entire body of countr_zero in countr_one.
[Bug c++/96124] Template specialization auto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96124 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2020-12-10
[Bug c++/98216] [C++20] std::array template parameter error with negative values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98216
--- Comment #3 from Jonathan Wakely ---
Reduced:
struct an_array
{
constexpr bool operator==(const an_array& a) const { return d == a.d; }
double d;
};
constexpr auto
add_array (an_array a, an_array b)
{
a.d += b.d;
return a;
}
template
struct wrapper
{
static constexpr auto arr = A;
};
constexpr auto ONE = an_array {{ 1. }};
constexpr auto MINUS_ONE = an_array {{ -1. }};
constexpr auto MINUS_TWO = an_array {{ -2. }};
int
main ()
{
#ifndef FIX
auto a = wrapper {};
__builtin_printf("%f\n", a.arr.d);
#endif
auto c = wrapper {};
__builtin_printf("%f\n", c.arr.d);
if (c.arr != MINUS_ONE)
__builtin_abort();
}
Prints:
-2.00
-2.00
Aborted (core dumped)
If you define FIX (i.e. don't instantiate wrapper first) it works:
-1.00
[Bug ada/98227] New: [11 Regression] ICE: tree check: expected tree that contains 'decl common' structure, have 'constructor' in get_section, at varasm.c:297 on riscv64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98227 Bug ID: 98227 Summary: [11 Regression] ICE: tree check: expected tree that contains 'decl common' structure, have 'constructor' in get_section, at varasm.c:297 on riscv64-linux-gnu Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: doko at debian dot org Target Milestone: --- trunk 20201210 ftbfs on riscv64-linux-gnu mkdir -p ada/libgnat/ /<>/build/./prev-gcc/xgcc -B/<>/build/./prev-gcc/ -B/usr/lib/gcc-snapshot/riscv64-linux-gnu/bin/ - B/usr/lib/gcc-snapshot/riscv64-linux-gnu/bin/ -B/usr/lib/gcc-snapshot/riscv64-linux-gnu/lib/ -isystem /usr/lib/gcc-snapshot/ riscv64-linux-gnu/include -isystem /usr/lib/gcc-snapshot/riscv64-linux-gnu/sys-include -fno-checking -c -g -O2 -fno-checki ng -gtoggle -fprofile-generate -gnatpg -gnata -W -Wall -nostdinc -I- -I. -Iada/generated -Iada -Iada/gcc-interface -I../../ src/gcc/ada -I../../src/gcc/ada/gcc-interface -Iada/libgnat -I../../src/gcc/ada/libgnat ../../src/gcc/ada/libgnat/a-elchha.a db -o ada/libgnat/a-elchha.o +===GNAT BUG DETECTED==+ | 11.0.0 20201210 (experimental) [master revision 79c1b9fb44c:3f67ba38dca:8c60696b699e0b22cc12ae628473f0a23f90c82e] (riscv64 -linux-gnu) GCC error:| | tree check: expected tree that contains 'decl common' structure, | | have 'constructor' in get_section, at varasm.c:297 | | Error detected around ../../src/gcc/ada/libgnat/a-elchha.adb:118:7 | | Please submit a bug report; see https://gcc.gnu.org/bugs/ . | | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact command that you entered. | | Also include sources listed below. | +==+ Please include these source files with error report Note that list may not be accurate in some cases, so please double check that the problem can still be reproduced with the set of files listed. Consider also -gnatd.n switch (see debug.adb). ../../src/gcc/ada/gcc-interface/system.ads ../../src/gcc/ada/libgnat/a-elchha.adb ../../src/gcc/ada/libgnat/a-elchha.ads ../../src/gcc/ada/libgnat/a-except.ads ../../src/gcc/ada/libgnat/ada.ads ../../src/gcc/ada/libgnat/s-parame.ads ../../src/gcc/ada/libgnat/s-stalib.ads ../../src/gcc/ada/libgnat/a-unccon.ads ../../src/gcc/ada/libgnat/s-traent.ads ../../src/gcc/ada/libgnat/s-soflin.ads ../../src/gcc/ada/libgnat/s-secsta.ads ../../src/gcc/ada/libgnat/s-stoele.ads ../../src/gcc/ada/libgnat/s-stache.ads raised TYPES.UNRECOVERABLE_ERROR : comperr.adb:407 make[5]: *** [../../src/gcc/ada/gcc-interface/Make-lang.in:139: ada/libgnat/a-elchha.o] Error 1 make[5]: *** Waiting for unfinished jobs rm gfdl.pod gcc.pod gfortran.pod gcov-dump.pod gcov-tool.pod fsf-funding.pod gpl.pod cpp.pod gcov.pod lto-dump.pod gccgo.pod gdc.pod make[5]: Leaving directory '/<>/build/gcc' make[4]: *** [Makefile:4904: all-stageprofile-gcc] Error 2 make[4]: Leaving directory '/<>/build' make[3]: *** [Makefile:25239: stageprofile-bubble] Error 2 make[3]: Leaving directory '/<>/build' make[2]: *** [Makefile:25504: profiledbootstrap-lean] Error 2 make[2]: Leaving directory '/<>/build' that's a profiled bootstrap configured with: --enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++ --prefix=/usr/lib/gcc-snapshot --with-gcc-major-version-only --program-prefix= --enable-shared --enable-linker-build-id --disable-nls --enable-bootstrap --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libitm --disable-libsanitizer --disable-libquadmath --disable-libquadmath-support --enable-plugin --with-system-zlib --enable-libphobos-checking=release --with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch --disable-werror --disable-multilib --with-arch=rv64imafdc --with-abi=lp64d --enable-checking=yes --build=riscv64-linux-gnu --host=riscv64-linux-gnu --target=riscv64-linux-gnu
[Bug c++/98216] [C++20] std::array template parameter error with negative values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98216
--- Comment #2 from Jonathan Wakely ---
Reduced:
template
struct array
{
constexpr T& operator[](int n) { return d[n]; }
constexpr const T& operator[](int n) const { return d[n]; }
constexpr bool operator==(const array& a) const
{
for (int i = 0; i < N; ++i)
if (d[i] != a.d[i])
return false;
return true;
}
T d[N];
};
using an_array = array ;
constexpr auto
add_array (an_array a, an_array const& b)
{
a[0] += b[0];
return a;
}
template
struct wrapper
{
static constexpr auto
arr = A;
};
template
auto
add (wrapper const&, wrapper const&)
{
return wrapper {};
}
constexpr auto ONE = an_array {{ 1. }};
constexpr auto MINUS_ONE = an_array {{ -1. }};
constexpr auto MINUS_TWO = an_array {{ -2. }};
int
main ()
{
auto a = wrapper {};
auto b = wrapper {};
auto c = add (a, b);
__builtin_printf("%f %f %f\n", a.arr[0], b.arr[0], c.arr[0]);
if (c.arr != MINUS_ONE)
__builtin_abort();
}
Prints:
-2.00 1.00 -2.00
Aborted (core dumped)
[Bug tree-optimization/97104] [11 Regression] aarch64, SVE: ICE in vect_get_loop_mask since r11-3070-g783dc66f9cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97104 akrl at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1
[Bug libstdc++/98226] New: Slow std::countr_one
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98226
Bug ID: 98226
Summary: Slow std::countr_one
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: zaikin.icc at gmail dot com
Target Milestone: ---
The function std::countr_one() from C++20 is slow. For a given x (say, unsigned
int) it in fact calls std::countr_zero(~x) which in turn calls
__builtin_ctz(~x). Calling __builtin_ctz(~x) directly from std::countr_one()
would increase the performance. The test case contains three sources, each of
which finally does the same but with different performance.
Test case:
---
test1.cpp:
#include
int main()
{
unsigned j;
for (unsigned i=0; i<(1 << 30); i++) {
j = std::countr_one(i);
}
}
---
g++ -std=c++20 ./test1.cpp -o test1
test2.cpp:
#include
int main()
{
unsigned j;
for (unsigned i=0; i<(1 << 30); i++) {
j = std::countr_zero(~i);
}
}
---
g++ -std=c++20 ./test2.cpp -o test2
test3.cpp:
#include
int main()
{
unsigned j;
for (unsigned i=0; i<(1 << 30); i++) {
j = __builtin_ctz(~i);
}
}
---
g++ -std=c++20 ./test3.cpp -o test3
The user time is reported below:
time ./test1
5.266s
time ./test2
3.028s
time ./test3
0.741s
$ 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='Ubuntu
10.2.0-5ubuntu1~20.04' --with-bugurl=file:///usr/share/doc/gcc-10/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-10
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new
--enable-gnu-unique-object --disable-vtable-verify --enable-plugin
--enable-default-pie --with-system-zlib --enable-libphobos-checking=release
--with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch
--disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none=/build/gcc-10-WJNXnb/gcc-10-10.2.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-10-WJNXnb/gcc-10-10.2.0/debian/tmp-gcn/usr,hsa
--without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.2.0 (Ubuntu 10.2.0-5ubuntu1~20.04)
[Bug c++/91415] Invalid warning for C++17 sequencing of shift operator E1<
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91415
--- Comment #13 from Nicolai Josuttis ---
Oh, sorry, your are right, the example indeed works.
BUT: I used in fact a slightly different example
(sorry, didn't expect that there is a difference):
int main() {
int i = 0;
int j = i++ << i++; // OK, NO WARNING
std::cout << i++ << i++; // still WARNING
}
see https://wandbox.org/permlink/ioZnOv3oAp5F0BsQ
According to my understanding the warning should especially
also not come when we pass i++ twice to std::cout
(to sequence output was a key goal of this fix in C++17).
But may be I am missing something.
[Bug libstdc++/71899] An internal BooleanTestable trait should be provided
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71899 Jonathan Wakely changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #7 from Jonathan Wakely --- Yep, added in c5e1c1d3aba39e960cc5fb0dcd77e447e5dee7eb OK, closing, thanks.
[Bug fortran/97723] type bound ASSIGNMENT(=) within select rank block wrongly rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97723 --- Comment #3 from Paul Thomas --- (In reply to Paul Thomas from comment #2) > > The fix regtests OK. I will commit as 'obvious' with a test case in the next > day or two. Cancel that, there is one regression. Paul
[Bug libstdc++/71899] An internal BooleanTestable trait should be provided
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71899 --- Comment #6 from Daniel Krügler --- (In reply to Jonathan Wakely from comment #5) > LWG 2743 seems to be the wrong issue, I think https://wg21.link/lwg2114 is > the right one. Ah yes, this was an unintended mislinking on my side. Feel free to close this issue, the resolution approach is now different already and it is likely the libraries will already implement something like boolean-testable-impl anyway (https://wg21.link/p1964r2).
[Bug c++/98220] LTO causes floating point exception
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98220 --- Comment #12 from Jonathan Wakely --- (In reply to wuz73 from comment #11) > (In reply to Jonathan Wakely from comment #10) > > No it's, not a bug, because the C++ standard says the order is unspecified. > > The compiler is allowed to reorder them, and that's what happens with -flto. > > So what if I do need certain order (e.g. using libs provided by 3rd party)? You fix your code to not depend on initialization order, because the order is unspecified. For example, as I suggested in comment 8. Code that depends on a specific order is broken according to the C++ standard. Or you use non-standard extensions like __attribute__((init_priority(nnn))) to control the relative order of global constructors. > Also this floating point exception is really obscure. How can I pinpoint the > culprit? You look at the stack trace (e.g. in GDB) and see which global variable is being constructed, and which uninitialized global variable it is accessing.
[Bug libstdc++/44952] #include implies global constructor.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44952 --- Comment #16 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #5) > 27.4 [iostream.objects] paragraph 2 > The results of including in a translation unit shall be as if > defined an instance of ios_base::Init with static storage > duration. Similarly, the entire program shall behave as if there were at > least one instance of ios_base::Init with static storage duration. N.B. https://wg21.link/lwg2765 removed that last sentence, so we are no longer required to run the stream initialization in all programs. Only in programs which include in at least one TU.
[Bug fortran/35718] deallocating non-allocated pointer target does not fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35718 Paul Thomas changed: What|Removed |Added Assignee|pault at gcc dot gnu.org |unassigned at gcc dot gnu.org --- Comment #9 from Paul Thomas --- (In reply to Thomas Koenig from comment #8) > We have an unsigned short in our descriptor that we can use > for keeping track of what we allocated and where. > > So, we have 16 bits. State we can keep around is: > > Type of descriptor: Allocatable, pointer, passed argument. 2 bits. > > Associated: No, allocated, target. 2 bits. > > Contiguous: 1 bit. > > Anything else we would need? That would still leave us 11 bit in reserve. Hi Thomas, That was the intention of the field in the descriptor. I just never got round to it. I have unassigned myself since I have a huge backlog of other issues. Cheers Paul
[Bug fortran/97723] type bound ASSIGNMENT(=) within select rank block wrongly rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97723 Paul Thomas changed: What|Removed |Added Last reconfirmed||2020-12-10 Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #2 from Paul Thomas --- Blast! Finger slipped The fix regtests OK. I will commit as 'obvious' with a test case in the next day or two. Thanks for the report. Paul
[Bug fortran/97723] type bound ASSIGNMENT(=) within select rank block wrongly rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97723 Paul Thomas changed: What|Removed |Added CC||pault at gcc dot gnu.org --- Comment #1 from Paul Thomas --- Created attachment 49730 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49730=edit Fix for the PR
[Bug c++/98220] LTO causes floating point exception
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98220 --- Comment #11 from wuz73 at hotmail dot com --- (In reply to Jonathan Wakely from comment #10) > No it's, not a bug, because the C++ standard says the order is unspecified. > The compiler is allowed to reorder them, and that's what happens with -flto. So what if I do need certain order (e.g. using libs provided by 3rd party)? Also this floating point exception is really obscure. How can I pinpoint the culprit?
[Bug target/97727] bf16_vstN_lane_2 test fails on aarch64_be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97727 akrl at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from akrl at gcc dot gnu.org --- This should be fixed in trunk and gcc-10.
[Bug libstdc++/96710] __int128 vs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96710
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2020-12-10
Ever confirmed|0 |1
--- Comment #1 from Jonathan Wakely ---
I would like is_scalar to be true for all scalar types such as __int20 and
__float128, irrespective of whether is_integer or is_floating_point is true.
They're certainly not class types, nor pointers, so they have to fit somewhere
in the type system.
A related issue is that on msp430 std::incrementable<__int20> is false for
strict mode. Ideally all the INT_N extension types would satisfy that, maybe
via something like:
--- a/libstdc++-v3/include/bits/iterator_concepts.h
+++ b/libstdc++-v3/include/bits/iterator_concepts.h
@@ -173,15 +173,15 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
= make_signed_t() - std::declval<_Tp>())>;
};
-#if defined __STRICT_ANSI__ && defined __SIZEOF_INT128__
- // __int128 is incrementable even if !integral<__int128>
- template<>
-struct incrementable_traits<__int128>
-{ using difference_type = __int128; };
-
- template<>
-struct incrementable_traits
-{ using difference_type = __int128; };
+#ifdef __STRICT_ANSI__
+ // Types like __int128 are incrementable even if integral<__int128> is
false.
+ // In non-strict modes they match the partial specialization above,
+ // but in strict modes we need this one so they satisfy std::incrementable.
+ template
+requires (__gnu_cxx::__is_integer_nonstrict<_Tp>::__value
+ != std::__is_integer<_Tp>::__value)
+struct incrementable_traits<_Tp>
+{ using difference_type = make_signed_t; };
#endif
namespace __detail
@@ -556,40 +556,22 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
class __max_diff_type;
class __max_size_type;
-template
- concept __is_signed_int128
-#if __SIZEOF_INT128__
- = same_as<_Tp, __int128>;
-#else
- = false;
-#endif
-
-template
- concept __is_unsigned_int128
-#if __SIZEOF_INT128__
- = same_as<_Tp, unsigned __int128>;
-#else
- = false;
-#endif
-
template
concept __cv_bool = same_as;
template
- concept __integral_nonbool = integral<_Tp> && !__cv_bool<_Tp>;
-
-template
- concept __is_int128 = __is_signed_int128<_Tp> ||
__is_unsigned_int128<_Tp>;
+ concept __integral_nonbool
+ = __gnu_cxx::__is_integer_nonstrict_v<_Tp> && !__cv_bool<_Tp>;
template
concept __is_integer_like = __integral_nonbool<_Tp>
- || __is_int128<_Tp>
|| same_as<_Tp, __max_diff_type> || same_as<_Tp, __max_size_type>;
template
- concept __is_signed_integer_like = signed_integral<_Tp>
- || __is_signed_int128<_Tp>
- || same_as<_Tp, __max_diff_type>;
+ concept __is_signed_integer_like
+ = (__gnu_cxx::__is_integer_nonstrict_v<_Tp>
+ && bool(__gnu_cxx::__int_traits<_Tp>::__is_signed))
+ || same_as<_Tp, __max_diff_type>;
} // namespace ranges::__detail
[Bug tree-optimization/98174] [11 Regression] Ranger takes too much memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98174 --- Comment #3 from Richard Biener --- (In reply to Richard Biener from comment #2) > Maybe related (didn't check yet), the testcases for PR91257 and PR93199 now > OOM at -O2 https://gcc.opensuse.org/gcc-old/c++bench-czerny/random/
[Bug tree-optimization/98174] [11 Regression] Ranger takes too much memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98174 --- Comment #2 from Richard Biener --- Maybe related (didn't check yet), the testcases for PR91257 and PR93199 now OOM at -O2
[Bug c++/78173] Hard error subtracting pointers to incomplete type in SFINAE context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78173 Patrick Palka changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Target Milestone|--- |10.3 CC||ppalka at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #4 from Patrick Palka --- Looking.
[Bug c++/68451] internal compiler error: Segmentation fault when using decltype with friend inside a class template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68451 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Marek Polacek --- Fixed.
[Bug c++/68451] internal compiler error: Segmentation fault when using decltype with friend inside a class template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68451 --- Comment #4 from CVS Commits --- The master branch has been updated by Marek Polacek : https://gcc.gnu.org/g:e271cd0234d5db2f95c35454b8b29b6e8386caa8 commit r11-5912-ge271cd0234d5db2f95c35454b8b29b6e8386caa8 Author: Marek Polacek Date: Thu Dec 10 09:56:40 2020 -0500 c++: Add fixed test [PR68451] I was about to add this test with dg-ice but it turned out it had already been fixed by the recent r11-3361! gcc/testsuite/ChangeLog: PR c++/68451 * g++.dg/cpp0x/friend6.C: New test.
[Bug c++/68451] internal compiler error: Segmentation fault when using decltype with friend inside a class template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68451 Marek Polacek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org CC||mpolacek at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #3 from Marek Polacek --- Woo, this was recently fixed by r11-3361.
[Bug target/97875] suboptimal loop vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97875 Christophe Lyon changed: What|Removed |Added Status|WAITING |ASSIGNED --- Comment #6 from Christophe Lyon --- Indeed enabling movmisalign for MVE greatly helps.
[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729 --- Comment #42 from abebeos at lazaridis dot com --- from Dimitar Dimitrov dimi...@dinux.eu within https://gcc.gnu.org/pipermail/gcc-patches/2020-December/561489.html > I tested the trees you have given with my own AVR test setup [1]. I confirm > your results: > - saaadhu's tree does not introduce any regressions. > - pipcet's tree has 142 gcc and 299 g++ regressions (although many of them >are duplicates, e.g. same test case with different optimization levels). > > [1] https://github.com/dinuxbg/gnupru/blob/master/testing/buildbot-avr.sh
[Bug c++/64194] [C++14] for function template with auto return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64194 --- Comment #17 from CVS Commits --- The releases/gcc-10 branch has been updated by Patrick Palka : https://gcc.gnu.org/g:4fb1ee669ccaad16795baf25d2cab48d8cf8c1eb commit r10-9136-g4fb1ee669ccaad16795baf25d2cab48d8cf8c1eb Author: Patrick Palka Date: Wed Jul 29 22:06:44 2020 -0400 c++: overload sets and placeholder return type [PR64194] In the testcase below, template argument deduction for the call g(id) goes wrong because the functions in the overload set id each have a yet-undeduced auto return type, and this undeduced return type makes try_one_overload fail to match up any of the overloads with g's parameter type, leading to g's template argument going undeduced and to the overload set going unresolved. This patch fixes this issue by performing return type deduction via instantiation before doing try_one_overload, in a manner similar to what resolve_address_of_overloaded_function does. gcc/cp/ChangeLog: PR c++/64194 * pt.c (resolve_overloaded_unification): If the function template specialization has a placeholder return type, then instantiate it before attempting unification. gcc/testsuite/ChangeLog: PR c++/64194 * g++.dg/cpp1y/auto-fn60.C: New test. (cherry picked from commit 2c58f5cadfac338a67723fd6e41c9097760c4a33)
[Bug c++/98220] LTO causes floating point exception
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98220 --- Comment #10 from Jonathan Wakely --- No it's, not a bug, because the C++ standard says the order is unspecified. The compiler is allowed to reorder them, and that's what happens with -flto.
[Bug bootstrap/95582] [11 Regression] LTO lean + PGO bootstrap is broken in Ada
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95582 --- Comment #20 from Eric Botcazou --- > So I'm going to look at this again. Some random thoughts on the Ada bools > though. It would be nice if the Ada FE could leave boolean_type_node > untouched so that when the middle-end produces a compare to feed a branch > it does not end up using the 8-bit precision bool (because there's no out-of > range values to be considered for a compare result). Basically keep the > Ada boolean "data type" separate from the middle-end boolean "logical type". IIRC I tried that but this was pessimizing because of spurious conversions.
[Bug c++/98220] LTO causes floating point exception
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98220 --- Comment #9 from wuz73 at hotmail dot com --- Without -flto I can specify link order. So -flto will ignore the order? It is still a bug as in many cases orders do matter.
[Bug bootstrap/95582] [11 Regression] LTO lean + PGO bootstrap is broken in Ada
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95582 --- Comment #19 from Richard Biener --- So I'm going to look at this again. Some random thoughts on the Ada bools though. It would be nice if the Ada FE could leave boolean_type_node untouched so that when the middle-end produces a compare to feed a branch it does not end up using the 8-bit precision bool (because there's no out-of range values to be considered for a compare result). Basically keep the Ada boolean "data type" separate from the middle-end boolean "logical type". That said, I've ventured into the vectorizer detail failing recently and thus, revisiting for a fix (or rather, [re-]understanding).
[Bug target/95285] AArch64:aarch64 medium code model proposal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95285 Wilco changed: What|Removed |Added CC||wdijkstr at arm dot com --- Comment #16 from Wilco --- Note there is an early writeup of the current code models here: https://github.com/ARM-software/abi-aa/pull/57/files (I've added the issues with the current large model in review comments).
[Bug analyzer/97090] gcc.dg/analyzer/malloc-vs-local-1b.c fails on arm and powerpc64*-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97090 Rainer Orth changed: What|Removed |Added Target Milestone|--- |11.0 CC||ro at gcc dot gnu.org --- Comment #10 from Rainer Orth --- I see the same flakyness of both gcc.dg/analyzer/unknown-fns-4.c (usually XPASSing XPASS: gcc.dg/analyzer/unknown-fns-4.c (test for warnings, line 13) but PASSing once in a while) and gcc.dg/analyzer/malloc-vs-local-1b.c (usually FAILing FAIL: gcc.dg/analyzer/malloc-vs-local-1b.c (test for bogus messages, line 170) but PASSing once in a while) on both sparc-sun-solaris2.11 and i386-pc-solaris2.11.
[Bug testsuite/98225] gcc.misc-tests/outputs.exp ltrans_args tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98225 Rainer Orth changed: What|Removed |Added Target Milestone|--- |11.0
[Bug testsuite/98225] New: gcc.misc-tests/outputs.exp ltrans_args tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98225 Bug ID: 98225 Summary: gcc.misc-tests/outputs.exp ltrans_args tests FAIL Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org Target Milestone: --- Between 20201020 (5d53ec27015b916640171e891870adf2c6fdfd4c) and 20201021 (c8f795cac6a1325bc6bcba3f47b7d04cb790400c), a couple of gcc.misc-tests/outputs.exp tests began to FAIL: FAIL: outputs lto st mult dumpdir named: dir/outputs-ltrans0.ltrans_args FAIL: outputs lto st mult empty dumpbase namedb: dir/outputs.ltrans0.ltrans_args FAIL: outputs lto st mult empty dumpbase unnamed: a.ltrans0.ltrans_args FAIL: outputs lto st mult namedb: dir/outputs.ltrans0.ltrans_args FAIL: outputs lto st mult unnamed: a.ltrans0.ltrans_args FAIL: outputs lto st sing dumpdir empty dumpbase named: dir/outputs-0.ltrans0.ltrans_args FAIL: outputs lto st sing dumpdir named: dir/outputs-ltrans0.ltrans_args FAIL: outputs lto st sing empty dumpbase namedb: dir/outputs.ltrans0.ltrans_args FAIL: outputs lto st sing empty dumpbase unnamed: a.ltrans0.ltrans_args FAIL: outputs lto st sing namedb: dir/outputs.ltrans0.ltrans I'm seeing this on both Solaris/sparc and x86, 32 and 64-bit, both with the native linker and with GNU ld (thus without and with the lto-plugin). There are also gcc-testresults reports for all sorts of targets: i686-pc-linux-gnu, aarch64-suse-linux-gnu, riscv64-suse-linux-gnu, x86_64-pc-linux-gnu, x86_64-unknown-freebsd11.4, x86_64-apple-darwin16. I've tried to have a look, but failed for all sorts of reasons: * When running the corresponding compilation with -v, -v isn't passed on to lto-wrapper. * Despite -save-temps, the lto-wrapper input objects are removed at the end, so I cannot manually rerun lto-wrapper to investigate. I guess this would be way easier for someone familiar with the code to investigate.
[Bug testsuite/98224] [11 regression] gcc.dg/Walloca-2.c XPASSes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98224 Rainer Orth changed: What|Removed |Added Target Milestone|--- |11.0
[Bug testsuite/98224] New: [11 regression] gcc.dg/Walloca-2.c XPASSes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98224 Bug ID: 98224 Summary: [11 regression] gcc.dg/Walloca-2.c XPASSes Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org CC: aldyh at gcc dot gnu.org Target Milestone: --- Between 20201020 (5d53ec27015b916640171e891870adf2c6fdfd4c) and 20201021 (c8f795cac6a1325bc6bcba3f47b7d04cb790400c), gcc.dg/Walloca-2.c began to XPASS: XPASS: gcc.dg/Walloca-2.c (test for bogus messages, line 16) I'm seeing it on 32-bit Solaris/sparc and x86, but there are many gcc-testresults reports. I suspect the xfail and the FIXME comment can just go?
[Bug tree-optimization/91384] [8/9/10/11 Regression] Compare with negation is not eliminated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91384
--- Comment #10 from Richard Biener ---
But then
void foo (void);
void bar (void);
int
test (int a)
{
if (a)
foo ();
else
bar ();
return -a;
}
is not optimized either (the usual argument - the user could have written it
in the way the compiler canonicalizes).
On RTL where the CCs are appearant that's a LCM / PRE problem with the
compare anticipating the zero flag here and the negate computing it.
That makes it profitable to move the negate and eliminate the CC flag
compute with it (for the testcase above).
On the original case where we have
int
test (int a)
{
int r = -a;
if (a)
foo ();
else
bar ();
return r;
}
that's more a local CSE opportunity (though of course for this modified
testcase we sink the -a compute to the return, re-creating the first
case in this comment).
As it is only RTL representing CC at all this is really a RTL global
optimization issue in the end. GIMPLE can only help to a limited extent
and all missed canonicalization (like if we add a single_use check)
eventually leads to missed global CSE opportunities.
[Bug tree-optimization/91384] [8/9/10/11 Regression] Compare with negation is not eliminated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91384
--- Comment #9 from Richard Biener ---
The local gimple transform is not right or wrong, it depends on the
surroundings
and unless we have a way to assess those in a good way doing it in one or the
other way is going to hurt either case.
The usual "fix" is to stick single-use restrictions onto the patterns involving
uses in compares, we're not very consistent with that.
Like the following
diff --git a/gcc/match.pd b/gcc/match.pd
index 43bacb4f68e..c5582021b0e 100644
--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -4503,10 +4503,11 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
&& TYPE_OVERFLOW_UNDEFINED (TREE_TYPE (@0
(scmp @0 @1)))
(simplify
- (cmp (negate @0) CONSTANT_CLASS_P@1)
+ (cmp (negate@2 @0) CONSTANT_CLASS_P@1)
(if (FLOAT_TYPE_P (TREE_TYPE (@0))
|| (ANY_INTEGRAL_TYPE_P (TREE_TYPE (@0))
- && TYPE_OVERFLOW_UNDEFINED (TREE_TYPE (@0
+ && TYPE_OVERFLOW_UNDEFINED (TREE_TYPE (@0))
+ && single_use (@2)))
(with { tree tem = const_unop (NEGATE_EXPR, TREE_TYPE (@0), @1); }
(if (tem && !TREE_OVERFLOW (tem))
(scmp @0 { tem; }))
[Bug target/98219] User-interrupt return pop corrupt RIP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98219 H.J. Lu changed: What|Removed |Added Target Milestone|--- |11.0
[Bug target/98219] User-interrupt return pop corrupt RIP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98219 H.J. Lu changed: What|Removed |Added Attachment #49724|0 |1 is obsolete|| Attachment #49725|0 |1 is obsolete|| Assignee|unassigned at gcc dot gnu.org |hjl.tools at gmail dot com --- Comment #8 from H.J. Lu --- Created attachment 49729 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49729=edit An updated patch with testcases I am testing this.
[Bug analyzer/98223] gcc.dg/analyzer/pr94851-1.c XPASSes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98223 Rainer Orth changed: What|Removed |Added Target Milestone|--- |11.0
[Bug analyzer/98223] New: gcc.dg/analyzer/pr94851-1.c XPASSes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98223 Bug ID: 98223 Summary: gcc.dg/analyzer/pr94851-1.c XPASSes Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: analyzer Assignee: dmalcolm at gcc dot gnu.org Reporter: ro at gcc dot gnu.org Target Milestone: --- Between 20201007 (dae673abd37d400408959497e50fe1f3fbef5533) and 20201008 (3e1123e52f8eca2650efa0bc81768792d328961f), gcc.dg/analyzer/pr94851-1.c began to XPASS: XPASS: gcc.dg/analyzer/pr94851-1.c bogus leak (test for bogus messages, line 43) I initially saw it on i386-pc-solaris2.11 and sparc-sun-solaris2.11 (both 32 and 64-bit), but according to gcc-testresults, it happens on many targets (everywhere?). Maybe just remove the xfail?
[Bug tree-optimization/91384] [8/9/10/11 Regression] Compare with negation is not eliminated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91384
--- Comment #8 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #1)
> Started with r223689. Though, generally that change looks like a useful
> GIMPLE canonicalization.
How about we amend the above change to:
diff --git a/gcc/match.pd b/gcc/match.pd
index 43bacb4f68e..1370ba7302d 100644
--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -4506,6 +4506,7 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
(cmp (negate @0) CONSTANT_CLASS_P@1)
(if (FLOAT_TYPE_P (TREE_TYPE (@0))
|| (ANY_INTEGRAL_TYPE_P (TREE_TYPE (@0))
+ && integer_nonzerop (@0)
&& TYPE_OVERFLOW_UNDEFINED (TREE_TYPE (@0
(with { tree tem = const_unop (NEGATE_EXPR, TREE_TYPE (@0), @1); }
(if (tem && !TREE_OVERFLOW (tem))
so we simplify (cmp (negate @0) CONSTANT_CLASS_P@1)) only for non-zero integer
arguments. For the original testcase, the compare is eliminated:
test:
negl%edi
pushq %r12
movl%edi, %r12d
je .L2
callfoo
movl%r12d, %eax
popq%r12
ret
.L2:
callbar
movl%r12d, %eax
popq%r12
ret
Please also note that for the slightly changed original testcase:
--cut here--
void f1 (void);
void f2 (void);
void
foo (int a)
{
int r = -a;
if (r)
f1 ();
else
f2 ();
}
--cut here--
combine RTL pass manages to remove the negation without problems:
Trying 6 -> 7:
6: {r84:SI=-r85:SI;clobber flags:CC;}
REG_DEAD r85:SI
REG_UNUSED flags:CC
7: flags:CCZ=cmp(r84:SI,0)
REG_DEAD r84:SI
Successfully matched this instruction:
(set (reg:CCZ 17 flags)
(compare:CCZ (reg:SI 85)
(const_int 0 [0])))
so the compilation (-O2) results in the same assembly:
foo:
testl %edi, %edi
je .L2
jmp f1
.L2:
jmp f2
[Bug libstdc++/71899] An internal BooleanTestable trait should be provided
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71899 --- Comment #5 from Jonathan Wakely --- LWG 2743 seems to be the wrong issue, I think https://wg21.link/lwg2114 is the right one.
[Bug ipa/98222] [11 Regression] ICE at -O3 on x86_64-pc-linux-gnu: verify_cgraph_node failed since r11-4267-g0e590b68fa374365
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98222 Martin Liška changed: What|Removed |Added Known to work||10.2.0 Target Milestone|--- |11.0 Priority|P3 |P1 Summary|ICE at -O3 on |[11 Regression] ICE at -O3 |x86_64-pc-linux-gnu:|on x86_64-pc-linux-gnu: |verify_cgraph_node failed |verify_cgraph_node failed ||since ||r11-4267-g0e590b68fa374365 Ever confirmed|0 |1 CC||hubicka at gcc dot gnu.org Status|UNCONFIRMED |NEW Keywords|needs-bisection | Known to fail||11.0 Last reconfirmed||2020-12-10
[Bug tree-optimization/95396] [8/9/10 Regression] GCC produces incorrect code with -O3 for loops since r8-6511-g3ae129323d150621
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95396 rsandifo at gcc dot gnu.org changed: What|Removed |Added Summary|[8/9/10/11 Regression] GCC |[8/9/10 Regression] GCC |produces incorrect code |produces incorrect code |with -O3 for loops since|with -O3 for loops since |r8-6511-g3ae129323d150621 |r8-6511-g3ae129323d150621 --- Comment #13 from rsandifo at gcc dot gnu.org --- Fixed on trunk by r11-5904.
[Bug libstdc++/67214] undefined behaviour in std::num_get::_M_extract_int()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67214 Jonathan Wakely changed: What|Removed |Added Status|NEW |RESOLVED Target Milestone|--- |8.0 Resolution|--- |FIXED --- Comment #6 from Jonathan Wakely --- It didn't get backported, but the fix is in all active branches.
[Bug tree-optimization/97929] [11 Regression] ICE: in exact_div, at poly-int.h:2219 (vect_get_num_vectors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97929 Joel Hutton changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Joel Hutton --- Fixed on trunk with r11-5903-gf5b902a9af9d1cce6c540c7f71e02e22e45c23ef
[Bug tree-optimization/98221] [10/11 regression] Wrong unpack operation emitted in tree-ssa-forwprop.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98221 --- Comment #4 from Richard Biener --- (In reply to Andreas Krebbel from comment #3) > tree-vect-loop-manip.c: vect_maybe_permute_loop_masks also emits > VEC_UNPACKS_HI/LO dependent on BYTES_BIG_ENDIAN. > > What is the expectation wrt the meaning of hi/lo in RTL standard names? I > couldn't find it clearly documented for this either. Well, for things like > 'smulm3_highpart' we say it is about the 'most significant half' but I don't > see anything for the vector hi/lo. It would be nice to clarify this indeed. Like for ppc64le with "big-endian" vector ops the only chance is to have the target emulate litte-endian vector ops given the 1:1 match on BYTES_BIG_ENDIAN. Note in supportable_widening_operation we also swap case VEC_WIDEN_MULT_EVEN_EXPR: /* Support the recursion induced just above. */ c1 = VEC_WIDEN_MULT_EVEN_EXPR; c2 = VEC_WIDEN_MULT_ODD_EXPR; break; and I wonder if we can build a wrong-code testcase from that (unless even/odd interpretation also depends on BYTES_BIG_ENDIAN). s390 does seem to implement those at least.
[Bug tree-optimization/97929] [11 Regression] ICE: in exact_div, at poly-int.h:2219 (vect_get_num_vectors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97929 --- Comment #3 from CVS Commits --- The master branch has been updated by Joel Hutton : https://gcc.gnu.org/g:f5b902a9af9d1cce6c540c7f71e02e22e45c23ef commit r11-5903-gf5b902a9af9d1cce6c540c7f71e02e22e45c23ef Author: Joel Hutton Date: Thu Dec 10 11:55:18 2020 + [VECT] pr97929 fix This addresses pr97929. The case for WIDEN_PLUS and WIDEN_MINUS were missing in vect_get_smallest_scalar_type. gcc/ChangeLog: PR tree-optimization/97929 * tree-vect-data-refs.c (vect_get_smallest_scalar_type): Add WIDEN_PLUS/WIDEN_MINUS case. gcc/testsuite/ChangeLog: * gcc.dg/vect/pr97929.c: New test.
[Bug ipa/98222] New: ICE at -O3 on x86_64-pc-linux-gnu: verify_cgraph_node failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98222
Bug ID: 98222
Summary: ICE at -O3 on x86_64-pc-linux-gnu: verify_cgraph_node
failed
Product: gcc
Version: 11.0
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: ---
[517] % 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.0/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.0 20201210 (experimental) [master revision
66dea8899df:e246cb295db:680e4202f23ce74f3b26c7f090b9d22a56765554] (GCC)
[518] %
[518] % gcctk -O2 small.c; ./a.out
[519] %
[519] % gcctk -O3 small.c
small.c: In function ‘f’:
small.c:3:5: error: edge points to wrong declaration:
3 | int f (int j, int k) {
| ^
>
QI
size
unit-size
align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7f73b4e72d20
arg-types >>
addressable used nothrow static decl_5 QI small.c:3:5 align:8
warn_if_not_align:0 context >
Instead of:
unit-size
align:32 warn_if_not_align:0 symtab:0 alias-set 1 canonical-type
0x7f73b4d565e8 precision:32 min max
pointer_to_this >
QI
size
unit-size
align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7f73b4d6e348
arg-types
chain
chain >>>
pointer_to_this >
addressable used nothrow public static decl_5 QI small.c:3:5 align:8
warn_if_not_align:0 context
initial
result
ignored SI small.c:3:5 size unit-size
align:32 warn_if_not_align:0 context >
arguments
used read SI small.c:3:12 size
unit-size
align:32 warn_if_not_align:0 context
arg-type
chain
used read SI small.c:3:19 size
unit-size
align:32 warn_if_not_align:0 context arg-type >>
struct-function 0x7f73b4e99000 chain >
f/42 (f) @0x7f73b4eb0440
Type: function definition analyzed
Visibility: artificial
next sharing asm name: 41
previous sharing asm name: 44
References: b/1 (write) a/0 (read) b/1 (read) a/0 (read) c/2 (read)
Referring:
Function f/42 is inline copy in f/3
Availability: local
Function flags: count:462210652 (estimated locally) body local nonfreeing_fn
Called by: f/41 (inlined) (462210652 (estimated locally),0.43 per call)
Calls: f/3 (415989587 (estimated locally),0.39 per call)
f.constprop.0.isra.0/6 (152529514 (estimated locally),0.14 per call)
during IPA pass: inline
small.c:3:5: internal compiler error: verify_cgraph_node failed
0x83d218 cgraph_node::verify_node()
../../gcc-trunk/gcc/cgraph.c:3809
0x82956c symtab_node::verify()
../../gcc-trunk/gcc/symtab.c:1356
0xab2017 save_inline_function_body
../../gcc-trunk/gcc/ipa-inline-transform.c:679
0xab2017 inline_transform(cgraph_node*)
../../gcc-trunk/gcc/ipa-inline-transform.c:750
0xc29a49 execute_one_ipa_transform_pass
../../gcc-trunk/gcc/passes.c:2290
0xc29a49 execute_all_ipa_transforms(bool)
../../gcc-trunk/gcc/passes.c:2337
0x8422d5 cgraph_node::expand()
../../gcc-trunk/gcc/cgraphunit.c:1822
0x843c76 expand_all_functions
../../gcc-trunk/gcc/cgraphunit.c:1997
0x843c76 symbol_table::compile()
../../gcc-trunk/gcc/cgraphunit.c:2361
0x84721f symbol_table::compile()
../../gcc-trunk/gcc/cgraphunit.c:2545
0x84721f symbol_table::finalize_compilation_unit()
../../gcc-trunk/gcc/cgraphunit.c:2542
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
[520] %
[520] % cat small.c
int a, b, *c;
int f (int j, int k) {
b = k / j;
if (a)
f(0, 0);
*c = f(b & a, 0);
return 0;
}
int main() {
if (a)
while (1)
f(0, 0);
return 0;
}
[Bug tree-optimization/98221] [10/11 regression] Wrong unpack operation emitted in tree-ssa-forwprop.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98221 --- Comment #3 from Andreas Krebbel --- tree-vect-loop-manip.c: vect_maybe_permute_loop_masks also emits VEC_UNPACKS_HI/LO dependent on BYTES_BIG_ENDIAN. What is the expectation wrt the meaning of hi/lo in RTL standard names? I couldn't find it clearly documented for this either. Well, for things like 'smulm3_highpart' we say it is about the 'most significant half' but I don't see anything for the vector hi/lo.
[Bug tree-optimization/98211] [11 Regression] Wrong code at -O3 since r11-4482-gb626b00823af9ca9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98211 --- Comment #11 from Richard Biener --- (In reply to rsand...@gcc.gnu.org from comment #8) > (In reply to Richard Biener from comment #7) > > Hmm, OK, so besides the incomplete bool pattern matching the issue seems to > > be that while we reject the problematic conversion in > > vectorizable_conversion it slips through via vectorizable_assignment because > > it does > > > > /* Conversion between boolean types of different sizes is > > a simple assignment in case their vectypes are same > > boolean vectors. */ > > && (!VECTOR_BOOLEAN_TYPE_P (vectype) > > || !VECTOR_BOOLEAN_TYPE_P (vectype_in))) > > > > as opposed to vectorizable_conversions > > > > if (VECTOR_BOOLEAN_TYPE_P (vectype_out) > > && !VECTOR_BOOLEAN_TYPE_P (vectype_in)) > > > > that was added by g:2dab46d5fc9f95de16bd9bf0f219be5e64324d1f without a > > testcase > > or PR reference so it's difficult to tell what it was supposed to allow. > Agree that looks odd… > > > Now, > > for the case in question the conversion would have slipped though anyway > > since > > the only difference in the types is the sign and that one is BOOLEAN_TYPE > > and the other INTEGER_TYPE. So the exception above seems to intent to allow > > conversions with different precisions (note we now have precision 1 for all > > vector bools). > > > > So I'm going to just copy the vectorizable_conversion condition into > > vectorizable_assignment as well. > Shouldn't it instead be: > > VECTOR_BOOLEAN_TYPE_P (vectype) != VECTOR_BOOLEAN_TYPE_P (vectype_in) > > as is used in some other places (sometimes with ^ instead of !=)? > AFAIK using VCE would break in both directions. I think the intent was to allow vector to vector, both SImode to be converted for free (since in the end they have the same representation, _not_ occupying 2 and 4 bits but only one). I've recently "fixed" (changed) the integer mode bool vectors to always be vector to reflect that so I'm going to test simply removing that odd condition.
[Bug middle-end/98190] [11 Regression] GCC11 miscompiles code using _Bool when inlining: bfxil instruction misused since r11-165
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98190 --- Comment #16 from rguenther at suse dot de --- On Thu, 10 Dec 2020, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98190 > > --- Comment #15 from Jakub Jelinek --- > Created attachment 49727 > --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49727=edit > gcc11-pr98190.patch > > So, I have bootstrapped/regtested this patch last night on x86_64, i686, > aarch64, armv7hl, powerpc64le (and s390x still pending) linux. > Unfortunately, on aarch64 it regresses: > gcc.c-torture/execute/pr93213.c > and on powerpc64le that test plus: > g++.dg/warn/Wstrict-aliasing-bogus-char-1.C > gcc.dg/pr87273.c > gcc.dg/torture/pr91656-1.c > gcc.dg/tree-ssa/pr92085-2.c > gcc.dg/tree-ssa/pr94703.c > > Seems the assumption that for promoted SUBREG to_rtx the store is always to > all > the bits is incorrect, e.g. on pr93213.c the memcpy is copying just half of > the bits. So, shall we check the bitpos 0 bitsize all to_rtx bits for the > store_rtx case and otherwise check depending on endianity if the most > significant bit of to_rtx is overwritten and extend in that case? in foo() you mean? For __builtin_memmove (_1, _1, 1); ? So that's a parameter destination - does it at least have correctly DECL_NOT_GIMPLE_REG_P set? Did expansion really do sth different when we had it TREE_ADDRESSABLE?
[Bug tree-optimization/98211] [11 Regression] Wrong code at -O3 since r11-4482-gb626b00823af9ca9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98211 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from Richard Biener --- Fixed, though the fixed issue is latent.
[Bug tree-optimization/98211] [11 Regression] Wrong code at -O3 since r11-4482-gb626b00823af9ca9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98211 --- Comment #9 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:76c09f2af9d8ab9c760d860626f069d12d86f0a9 commit r11-5901-g76c09f2af9d8ab9c760d860626f069d12d86f0a9 Author: Richard Biener Date: Thu Dec 10 11:12:53 2020 +0100 tree-optimization/98211 - fix bogus vectorization of conversion Pattern recog incompletely handles some bool cases but we shouldn't miscompile as a result but not vectorize. Unfortunately vectorizable_assignment lets invalid conversions (that vectorizable_conversion rejects) slip through. The following rectifies that. 2020-12-10 Richard Biener PR tree-optimization/98211 * tree-vect-stmts.c (vectorizable_assignment): Disallow invalid conversions to bool vector types. * gcc.dg/pr98211.c: New testcase.
