[Bug target/103743] PPC: Inefficient equality compare for large 64-bit constants having only 16-bit relevant bits in high part
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103743 --- Comment #7 from CVS Commits --- The master branch has been updated by Jiu Fu Guo : https://gcc.gnu.org/g:1060cd2ad00b5174f4f8ef8ca3d8c283e321ffca commit r13-4803-g1060cd2ad00b5174f4f8ef8ca3d8c283e321ffca Author: Jiufu Guo Date: Tue Dec 20 11:43:57 2022 +0800 rs6000: Optimize cmp on rotated 16bits constant Hi, When checking eq/ne with a constant which has only 16bits, it can be optimized to check the rotated data. By this, the constant building is optimized. As the example in PR103743: For "in == 0x8000LL", this patch generates: rotldi 3,3,1 ; cmpldi 0,3,1 instead of: li 9,-1 ; rldicr 9,9,0,0 ; cmpd 0,3,9 Compare with previous version: https://gcc.gnu.org/pipermail/gcc-patches/2022-August/600475.html. This patch refactor the code according to review comments. e.g. updating function names/comments/code. This patch pass bootstrap and regtest on ppc64 and ppc64le. Is it ok for trunk? Thanks for comments! BR, Jeff(Jiufu) PR target/103743 gcc/ChangeLog: * config/rs6000/rs6000-protos.h (can_be_rotated_to_lowbits): New. (can_be_rotated_to_positive_16bits): New. (can_be_rotated_to_negative_15bits): New. * config/rs6000/rs6000.cc (can_be_rotated_to_lowbits): New definition. (can_be_rotated_to_positive_16bits): New definition. (can_be_rotated_to_negative_15bits): New definition. * config/rs6000/rs6000.md (*rotate_on_cmpdi): New define_insn_and_split. (eqne): Move earlier. gcc/testsuite/ChangeLog: * gcc.target/powerpc/pr103743.c: New test. * gcc.target/powerpc/pr103743_1.c: New test.
[Bug target/108185] [RISC-V]RVV assemble not set vsetvli correct.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108185 jiawei changed: What|Removed |Added Version|13.0|fortran-dev --- Comment #1 from jiawei --- vl1re8.vv25,0(a0) sub a5,a3,a5 vs1r.v v25,0(a1) vs1r.v v25,0(a5) addia4,a1,800 csrrt0,vlenb sllit1,t0,1 vsetvli a5,zero,e8,m1,ta,ma vsm.v v25,0(a4)
[Bug target/108185] New: [RISC-V]RVV assemble not set vsetvli correct.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108185
Bug ID: 108185
Summary: [RISC-V]RVV assemble not set vsetvli correct.
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jiawei at iscas dot ac.cn
Target Milestone: ---
Currently, when use gcc13 to compile follow code with rvv
extension(-march=rv64gcv -O3),
void foo5_3 (int32_t * restrict in, int32_t * restrict out, size_t n, int
cond)
{
vint8m1_t v = *(vint8m1_t*)in;
*(vint8m1_t*)out = v;
vbool8_t v3 = *(vbool8_t*)in;
*(vbool8_t*)(out + 200) = v3;
}
it will generate asm as:
vl1re8.vv25,0(a0)
sub a5,a3,a5
vs1r.v v25,0(a1)
vs1r.v v25,0(a5)
seems not use vsetvli correctly, any suggestions?
[Bug middle-end/105818] ICE: 'global_options' are modified in local context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105818 Kewen Lin changed: What|Removed |Added URL|https://gcc.gnu.org/piperma |https://gcc.gnu.org/piperma |il/gcc-patches/2022-June/59 |il/gcc-patches/2022-Novembe |6628.html |r/607527.html --- Comment #4 from Kewen Lin --- Filed PR108184 to avoid to use optimize_function_for_speed_p too early, fixing it can cover this exposed ICE, but IMHO this is still a separated issue, the case found on aarch64 can still show that the information on size/speed is inconsistent and this issue is worth to fixing.
[Bug target/108184] rs6000: Use optimize_function_for_speed_p too early
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108184 Kewen Lin changed: What|Removed |Added Target||powerpc*-linux-gnu Ever confirmed|0 |1 CC||bergner at gcc dot gnu.org, ||hubicka at gcc dot gnu.org, ||segher at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2022-12-20 Target Milestone|--- |13.0
[Bug target/100952] [12/13 regression] several test case failures after r12-1202
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100952 HaoChen Gui changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #19 from HaoChen Gui --- Closing as fixed then (pr56605.c still fails on older branches, but that is harmless). Other issues are all fixed.
[Bug target/108184] New: rs6000: Use optimize_function_for_speed_p too early
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108184
Bug ID: 108184
Summary: rs6000: Use optimize_function_for_speed_p too early
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: linkw at gcc dot gnu.org
Target Milestone: ---
In the review of patch [1] for PR105818, Honza pointed out
"I think we should generally avoid doing decisions about size/speed
optimizations so early since the setting may change due to attributes or
profile feedback..."
I agreed that the current uses of optimize_function_for_speed_p in function
rs6000_option_override_internal are too early and can be inaccurate. I tried to
make the below test case to demonstrate it.
Compiled with -mdejagnu-tune=power8 -O3:
__attribute__ ((cold)) int
fusion_short (short *p)
{
return p[0x12345];
}
Since the function is attributed with cold, it's considered not to optimize for
speed, so we shouldn't break the sign extended loads and fuse it with the
addis, that is it's unexpected to see extsh generated but we have:
addis 3,3,0x2
lhz 3,18058(3)
extsh 3,3
[1] https://gcc.gnu.org/pipermail/gcc-patches/2022-November/607527.html
[Bug modula2/107612] plugin/m2rte doesn't build on Mac OS X 10.7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107612 --- Comment #10 from Iain Sandoe --- I fixed the plugin build to avoid linking libstdc++ (small additions to Rainer's patch) * linking libstdc++ causes the build to fail because the plugin cannot find the libstdc++ because it is not yet installed. * it's not right to link it anyway - the plugin needs to resolve its symbols from cc1gm2 Adding -nodefaultlibs fixes this + I adjusted the install name. Actually, I do not think the rpaths are needed - because the plugin is explicitly loaded - it does not need to find any dependent libs. diff --git a/gcc/m2/Make-lang.in b/gcc/m2/Make-lang.in index 0ea73e766d1..8d86c1371f3 100644 --- a/gcc/m2/Make-lang.in +++ b/gcc/m2/Make-lang.in @@ -36,7 +36,10 @@ ifeq (,$(findstring darwin,$(host))) soext=.so else soext=.dylib - PLUGINLDFLAGS=-Wl,-undefined,dynamic_lookup + PLUGINLDFLAGS = -Wl,-undefined,dynamic_lookup + PLUGINLDFLAGS += -Wl,-install_name,m2rte$(soext) + PLUGINLDFLAGS += -Wl,-rpath,@loader_path,-rpath,@loader_path/.. + PLUGINLDFLAGS += -nodefaultlibs endif
[Bug modula2/107631] many tests don't link on Mac OS X 10.7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107631 --- Comment #3 from Iain Sandoe --- FAOD, I am not expecting that the patch is the correct one - it is a proof-of-principle as to where the issue lies.
[Bug modula2/107631] many tests don't link on Mac OS X 10.7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107631 Iain Sandoe changed: What|Removed |Added Last reconfirmed||2022-12-20 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #2 from Iain Sandoe --- as discussed on irc, these functions do no exist on Darwin (and the significand* set will likely be missing on several other targets). Posix has obsoleted scalb* which should be replaced with scalbn* === I hacked the implementation thus: (with this, on x86_64 darwin, we have 11k passes and 33 fails) [PATCH] gm2: hack the builtins for scalb and significand --- gcc/m2/gm2-libs/Builtins.mod | 14 -- 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/gcc/m2/gm2-libs/Builtins.mod b/gcc/m2/gm2-libs/Builtins.mod index c679259dc3c..f4d4ded06b1 100644 --- a/gcc/m2/gm2-libs/Builtins.mod +++ b/gcc/m2/gm2-libs/Builtins.mod @@ -222,21 +222,23 @@ BEGIN RETURN cbuiltin.ilogbl (x) END ilogbl ; + PROCEDURE __ATTRIBUTE__ __BUILTIN__ ((__builtin_significand)) significand (r: REAL) : REAL ; BEGIN - RETURN cbuiltin.significand (r) + RETURN cbuiltin.scalbn (r, -cbuiltin.ilogb (r)) END significand ; PROCEDURE __ATTRIBUTE__ __BUILTIN__ ((__builtin_significandf)) significandf (s: SHORTREAL) : SHORTREAL ; BEGIN - RETURN cbuiltin.significandf (s) + RETURN cbuiltin.scalbnf (s, -cbuiltin.ilogbf (s)) END significandf ; PROCEDURE __ATTRIBUTE__ __BUILTIN__ ((__builtin_significandl)) significandl (l: LONGREAL) : LONGREAL ; BEGIN - RETURN cbuiltin.significandl (l) + RETURN cbuiltin.scalbnl (l, -cbuiltin.ilogbl (l)) END significandl ; + PROCEDURE __ATTRIBUTE__ __BUILTIN__ ((__builtin_modf)) modf (x: REAL; VAR y: REAL) : REAL ; BEGIN RETURN cbuiltin.modf (x, y) @@ -299,17 +301,17 @@ END nexttowardl ; PROCEDURE __ATTRIBUTE__ __BUILTIN__ ((__builtin_scalb)) scalb (x, n: REAL) : REAL ; BEGIN - RETURN cbuiltin.scalb (x, n) + RETURN cbuiltin.scalbn (x, VAL (INTEGER, n)) END scalb ; PROCEDURE __ATTRIBUTE__ __BUILTIN__ ((__builtin_scalbf)) scalbf (x, n: SHORTREAL) : SHORTREAL ; BEGIN - RETURN cbuiltin.scalbf (x, n) + RETURN cbuiltin.scalbnf (x, VAL (INTEGER, n)) END scalbf ; PROCEDURE __ATTRIBUTE__ __BUILTIN__ ((__builtin_scalbl)) scalbl (x, n: LONGREAL) : LONGREAL ; BEGIN - RETURN cbuiltin.scalbl (x, n) + RETURN cbuiltin.scalbnl (x, VAL (INTEGER, n)) END scalbl ; PROCEDURE __ATTRIBUTE__ __BUILTIN__ ((__builtin_scalbln)) scalbln (x: REAL; n: LONGINT) : REAL ; -- 2.37.1 (Apple Git-137.1)
[Bug tree-optimization/106912] [13 Regression] ICE in vect_transform_loops, at tree-vectorizer.cc:1032 since r13-1575-gcf3a120084e94614
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106912 --- Comment #8 from Andrew Pinski --- I think PR 106433 is the same exact issue.
[Bug middle-end/108154] Inappropriate -Wstringop-overread in the C99 [static n] func param decl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108154 Martin Sebor changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #3 from Martin Sebor --- The warning here is intentional -- as noted, a [static 1] array can be as small as a single element. The warning is designed to help detect stronger assumptions inadvertently made by the function definition. (The compiler makes no analysis to see how the function is being called; it could if the function were declared static but but without full LTO it can't for an extern function.) The recommended annotation to indicate that a pointer argument must not be null is attribute nonnull.
[Bug middle-end/97048] [meta-bug] bogus/missing -Wstringop-overread warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97048 Bug 97048 depends on bug 108154, which changed state. Bug 108154 Summary: Inappropriate -Wstringop-overread in the C99 [static n] func param decl https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108154 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID
[Bug modula2/108183] wrong code generated in the modula2 scaffold mechanism
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108183
--- Comment #1 from Iain Sandoe ---
example:
a-hello.s:217:2: error: symbol '__M2_termios_ctor' can not be undefined in a
subtraction expression
leal__M2_termios_ctor-L5$pb(%eax), %edx #, _T53_57
(lldb) p (void) debug_tree(decl)
>
QI
size
unit-size
align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x106829dc8
arg-types >
pointer_to_this >
addressable public static QI (null):0:0 align:8 warn_if_not_align:0 context
(mem:QI (symbol_ref:SI ("_M2_termios_ctor") ) [0 S1 A8]) chain >
[Bug modula2/108183] wrong code generated in the modula2 scaffold mechanism
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108183 Iain Sandoe changed: What|Removed |Added Ever confirmed|0 |1 Target||i686-darwin, powerpc-darwin Last reconfirmed||2022-12-19 Status|UNCONFIRMED |NEW
[Bug modula2/108182] gm2 driver mishandles target and multilib options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108182 --- Comment #1 from Andrew Pinski --- Even some -f options are mutlilib'ed. Eg.: cr16/t-cr16:MULTILIB_OPTIONS = fPIC mint32 And MIPS does EL/EB: mips/t-img-linux:MULTILIB_OPTIONS = mips64r6 mabi=64 EL So this is definitely a bad assumption.
[Bug modula2/108183] New: wrong code generated in the modula2 scaffold mechanism
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108183 Bug ID: 108183 Summary: wrong code generated in the modula2 scaffold mechanism Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: modula2 Assignee: gaius at gcc dot gnu.org Reporter: iains at gcc dot gnu.org Target Milestone: --- On m32 Darwin, we see very many failures like: /Volumes/ramdisk/ccPnX6B8.s:379:non-relocatable subtraction expression, "__M2_dtoa_ctor" minus "L5$pb" /Volumes/ramdisk/ccPnX6B8.s:379:symbol: "__M2_dtoa_ctor" can't be undefined in a subtraction expression === It seems that the function declarations for '__M2_dtoa_ctor' (and other imported module ctors) are declared with TREE_STATIC() set, which indicates that there is a definition in the TU (which there is not) - they should be declared as external. So far, I could not figure out where these decls are built and what controls whether they are considered external or not.
[Bug modula2/108182] gm2 driver mishandles target and multilib options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108182 Iain Sandoe changed: What|Removed |Added CC||gaius at gcc dot gnu.org Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2022-12-19
[Bug modula2/108182] New: gm2 driver mishandles target and multilib options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108182 Bug ID: 108182 Summary: gm2 driver mishandles target and multilib options Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: modula2 Assignee: gaius at gcc dot gnu.org Reporter: iains at gcc dot gnu.org Target Milestone: --- The language_specific_driver for modula 2 is treating every command-line option beginning with '-m' as a multilib specifier, also expecting that the following characters are the name of the multilib_os_dir. This is not correct: 1. there are many other target options beginning with '-m' (e.g. -march=) 2. the characters following -m are not usually the multilib_os_dir. The language_specific_driver code needs to translate the command line options appropriately to determine the multilib_os_dir (there is code that does this in gcc/gcc.cc)
[Bug tree-optimization/106896] [13 Regression] ICE in to_sreal_scale, at profile-count.cc:339 since r13-2288-g61c4c989034548f4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106896 Andrew Pinski changed: What|Removed |Added Last reconfirmed|2022-09-12 00:00:00 |2022-12-19 --- Comment #8 from Andrew Pinski --- Just a quick note, for some reason using the original testcase with the C++ front-end does not produce the ICE while using the C front-end does. I didn't look into the IR difference or predict differences of why though.
[Bug target/106339] [13 Regression] ICE in exact_div, at poly-int.h:2232
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106339 Andrew Pinski changed: What|Removed |Added Keywords||needs-bisection --- Comment #2 from Andrew Pinski --- I cannot reproduce this ICE any more.
[Bug middle-end/106257] [13 Regression] ICE in expand_builtin_unreachable, at builtins.cc:5189 since r13-1204-gd68d366425369649
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106257
Andrew Pinski changed:
What|Removed |Added
Keywords||needs-bisection
--- Comment #2 from Andrew Pinski ---
Testcase just for easier access:
```
void* a;
void foo() {
if ((a = &))
return;
l:;
}
int main() {
foo();
goto *a;
return 0;
}
```
I can no longer reproduce this ICE.
[Bug target/107692] [13 regression] r13-3950-g071e428c24ee8c breaks many test cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107692 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #13 from Andrew Pinski --- .
[Bug target/107304] internal compiler error: in convert_move, at expr.cc:220 with -march=tigerlake
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107304 Andrew Pinski changed: What|Removed |Added Target Milestone|13.0|10.5 Known to fail||10.4.0, 11.3.0, 12.2.0 Resolution|--- |FIXED Known to work||10.4.1, 11.3.1, 12.2.1 Status|NEW |RESOLVED --- Comment #31 from Andrew Pinski --- (In reply to H.J. Lu from comment #27) > Fixed for GCC 13, 12.3, 11.4 and 10.5. .
[Bug target/105339] [x86] missing AVX-512F scalef functions when optimization is disabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105339 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to work||10.4.0, 11.3.1, 12.1.0, ||9.5.0 Resolution|--- |FIXED Target Milestone|--- |9.5 Known to fail||11.3.0 --- Comment #8 from Andrew Pinski --- .
[Bug testsuite/104726] gcc.target/i386/pr104551.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104726 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Component|target |testsuite Target Milestone|12.3|12.0 Resolution|--- |FIXED --- Comment #10 from Andrew Pinski --- Fixed.
[Bug c++/53288] [C++11] Lifetime of temporary object backing pointer-to-member expression not extended
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53288 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug target/101697] [11/12 regression] ICE compiling uClibc-ng for h8300-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101697 Andrew Pinski changed: What|Removed |Added Target Milestone|11.4|13.0 Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #10 from Andrew Pinski --- .
[Bug libstdc++/99533] "operation not permitted" error on recursive_directory_iterator despite skip_permission_denied
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99533 Jonathan Wakely changed: What|Removed |Added Status|NEW |RESOLVED Target Milestone|--- |9.4 Resolution|--- |FIXED --- Comment #10 from Jonathan Wakely --- Fixed on all active branches
[Bug target/97442] Wrong represenation of AArch64 saba in RTL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97442 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |11.0 Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #2 from Andrew Pinski --- Fixed.
[Bug other/97280] Documentation typo - 'roudnevenl'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97280 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Target Milestone|--- |11.0 Resolution|--- |FIXED --- Comment #3 from Andrew Pinski --- .
[Bug c++/96227] Comma operation sequencing issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96227 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |8.5 Resolution|--- |FIXED Status|WAITING |RESOLVED
[Bug middle-end/91584] [9 Regression] Bogus warning from -Warray-bounds during string assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91584 Andrew Pinski changed: What|Removed |Added Target Milestone|10.5|10.0 Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #11 from Andrew Pinski --- Fixed by r10-2892-g5d69df7e929252 .
[Bug tree-optimization/56456] [meta-bug] bogus/missing -Warray-bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456 Bug 56456 depends on bug 91584, which changed state. Bug 91584 Summary: [9 Regression] Bogus warning from -Warray-bounds during string assignment https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91584 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/89689] false warning -Wstringop-overflow=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89689 Andrew Pinski changed: What|Removed |Added Target Milestone|10.5|--- Summary|[9 regression] false|false warning |warning |-Wstringop-overflow= |-Wstringop-overflow=| --- Comment #11 from Andrew Pinski --- This is no longer a regression but "It does not address the deeper issues raised by Martin or cases that could be trivially derived from the original by placing other live statements within the true arm of the conditional." So marking the bug report that way ...
[Bug c++/89687] Empty pack expansion in `decltype` results in cryptic compiler error (dump_expr)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89687 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |10.0 Status|NEW |RESOLVED --- Comment #3 from Andrew Pinski --- .
[Bug c++/80871] Template partial ordering considered non-ambiguous with deduced and non-deduced parameter packs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80871 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |10.2
[Bug sanitizer/79096] [10/11/12/13 Regression] address sanitizer and jni does not work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79096 Andrew Pinski changed: What|Removed |Added Status|WAITING |SUSPENDED --- Comment #12 from Andrew Pinski --- .
[Bug c++/55004] [meta-bug] constexpr issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004 Bug 55004 depends on bug 71504, which changed state. Bug 71504 Summary: [C++11] constexpr fails with multidimensional arrays https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71504 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/71504] [C++11] constexpr fails with multidimensional arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71504 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|10.5|10.0 Status|ASSIGNED|RESOLVED --- Comment #15 from Andrew Pinski --- .
[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 Bug 53947 depends on bug 71271, which changed state. Bug 71271 Summary: SLP loop vectorized twice https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71271 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/71271] SLP loop vectorized twice
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71271 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |9.0 Status|NEW |RESOLVED --- Comment #6 from Andrew Pinski --- Fixed.
[Bug tree-optimization/35357] Loop peeling not happening
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35357 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |8.0 Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Andrew Pinski --- Yes this was fixed for GCC 8.
[Bug target/38126] suboptimal code for (a && b || !a && !b)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38126 Andrew Pinski changed: What|Removed |Added Target Milestone|13.0|---
[Bug rtl-optimization/93272] LRA: EH reg allocated to hold local variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93272 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |10.0 Status|REOPENED|RESOLVED --- Comment #9 from Andrew Pinski --- (In reply to Andreas Krebbel from comment #8) > Since this is a latent bug in LRA I think the patch needs backporting to GCC > 8 and 9 branches. 9 branch is closed so closing as fixed for GCC 10.
[Bug c++/103524] [meta-bug] modules issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524 Bug 103524 depends on bug 100881, which changed state. Bug 100881 Summary: [modules] default arguments break when the default argument's type isn't explicitly included/exported https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100881 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug c++/100881] [modules] default arguments break when the default argument's type isn't explicitly included/exported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100881 Patrick Palka changed: What|Removed |Added Target Milestone|--- |13.0 CC||ppalka at gcc dot gnu.org Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #2 from Patrick Palka --- Fixed for GCC 13, thanks for the bug report.
[Bug c++/101886] [11/12 Regression][concepts TS] ICE with auto as template argument since r11-7011-g6e0a231a4aa2407b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101886 Patrick Palka changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Summary|[11/12/13 |[11/12 Regression][concepts |Regression][concepts TS]|TS] ICE with auto as |ICE with auto as template |template argument since |argument since |r11-7011-g6e0a231a4aa2407b |r11-7011-g6e0a231a4aa2407b | CC||ppalka at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug c++/100881] [modules] default arguments break when the default argument's type isn't explicitly included/exported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100881 --- Comment #1 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:64f7a3b38765bcf7cdf5b37a991c06337468ad8b commit r13-4800-g64f7a3b38765bcf7cdf5b37a991c06337468ad8b Author: Patrick Palka Date: Mon Dec 19 15:35:51 2022 -0500 c++: modules and std::source_location::current() def arg [PR100881] We currently declare __builtin_source_location with a const void* return type instead of the actual type const std::source_location::__impl*, and later when folding this builtin we obtain the actual type via name lookup. But the below testcase demonstrates this approach seems to interact poorly with modules, since we may import an entity that uses std::source_location::current() in its default argument (or DMI) without necessarily importing , and thus the name lookup for std::source_location will fail at the call site (when using the default argument) unless we also import . This patch fixes this by instead initially declaring the builtin with an auto return type and updating it appropriately upon its first use (in standard code the first/only use would be in the definition of std::source_location). Thus when folding calls to this builtin we can get at its return type through the type of the CALL_EXPR and avoid needing to do a name lookup. PR c++/100881 gcc/cp/ChangeLog: * constexpr.cc (cxx_eval_builtin_function_call): Adjust calls to fold_builtin_source_location. * cp-gimplify.cc (cp_gimplify_expr): Likewise. (cp_fold): Likewise. (get_source_location_impl_type): Remove location_t parameter and adjust accordingly. No longer static. (fold_builtin_source_location): Take a CALL_EXPR tree instead of a location and obtain the impl type from its return type. * cp-tree.h (enum cp_tree_index): Remove CPTI_SOURCE_LOCATION_IMPL enumerator. (source_location_impl): Remove. (fold_builtin_source_location): Adjust parameter type. (get_source_location_impl_type): Declare. * decl.cc (cxx_init_decl_processing): Declare __builtin_source_location with auto return type instead of const void*. (require_deduced_type): Update the return type of __builtin_source_location. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/srcloc3.C: Adjust expected note s/evaluating/using. * g++.dg/cpp2a/srcloc4.C: Likewise. * g++.dg/cpp2a/srcloc5.C: Likewise. * g++.dg/cpp2a/srcloc6.C: Likewise. * g++.dg/cpp2a/srcloc7.C: Likewise. * g++.dg/cpp2a/srcloc8.C: Likewise. * g++.dg/cpp2a/srcloc9.C: Likewise. * g++.dg/cpp2a/srcloc10.C: Likewise. * g++.dg/cpp2a/srcloc11.C: Likewise. * g++.dg/cpp2a/srcloc12.C: Likewise. * g++.dg/cpp2a/srcloc13.C: Likewise. * g++.dg/modules/pr100881_a.C: New test. * g++.dg/modules/pr100881_b.C: New test.
[Bug c++/101886] [11/12/13 Regression][concepts TS] ICE with auto as template argument since r11-7011-g6e0a231a4aa2407b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101886 --- Comment #4 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:a7c8036b26082d8da001e05596777c5f911590e1 commit r13-4799-ga7c8036b26082d8da001e05596777c5f911590e1 Author: Patrick Palka Date: Mon Dec 19 14:59:43 2022 -0500 c++: ICE with concepts TS multiple auto deduction [PR101886] In extract_autos_r, we need to recompute TYPE_CANONICAL for the template type parameter after adjusting its index, otherwise we end up with a comptypes ICE for the below testcase. Note that such in-place type adjustment isn't generally safe to do since the type could be the TYPE_CANONICAL of another (unadjusted) type, but in this case the canonical auto (of some level and 0 index) is the first auto (of that level) that's created, and so any auto that we do end up adjusting can't be the canonical one. PR c++/101886 gcc/cp/ChangeLog: * pt.cc (extract_autos_r): Recompute TYPE_CANONICAL after adjusting the template type parameter's index. Simplify by using TEMPLATE_TYPE_IDX. Add some sanity checks. gcc/testsuite/ChangeLog: * g++.dg/concepts/auto5.C: New test.
[Bug middle-end/47406] gcc.dg/torture/builtin-modf-1.c FAILs on IRIX 6.5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47406 Bug 47406 depends on bug 48341, which changed state. Bug 48341 Summary: LDBL_EPSILON is wrong on IRIX 6.5 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48341 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX
[Bug c/48341] LDBL_EPSILON is wrong on IRIX 6.5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48341 Andrew Pinski changed: What|Removed |Added Resolution|--- |WONTFIX Status|UNCONFIRMED |RESOLVED Target Milestone|--- |4.8.0 --- Comment #9 from Andrew Pinski --- (In reply to Vincent Lefèvre from comment #5) > Thus the summary of this bug should be changed to: > > LDBL_EPSILON is wrong on PowerPC That is already part of PR 61399. Anyways IRIX support was removed in 2012 by r0-115719-gb24513a1a2bb35 for GCC 4.8.0.
[Bug c/108043] [13 Regression] ICE: in fold_convert_loc, at fold-const.cc:2618 on invalid function braced initializer since r13-2205-g14cfa01755a66afb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108043
--- Comment #5 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:4e4620d8c796af482b57b94932618d1f9d9af9f7
commit r13-4797-g4e4620d8c796af482b57b94932618d1f9d9af9f7
Author: Jakub Jelinek
Date: Mon Dec 19 20:55:56 2022 +0100
c: Diagnose compound literals with function type [PR108043]
Both C99 and latest C2X say that compound literal shall have an object type
(complete object type in the latter case) or array of unknown bound,
so complit with function type is invalid. When the initializer had to be
non-empty for such case, we used to diagnose it as incorrect initializer,
but with (fntype){} now allowed we just ICE on it.
The following patch diagnoses that.
2022-12-19 Jakub Jelinek
PR c/108043
* c-parser.cc (c_parser_postfix_expression_after_paren_type):
Diagnose
compound literals with function type.
* gcc.dg/pr108043.c: New test.
* gcc.dg/c99-complit-2.c (foo): Adjust expected diagnostics for
complit with function type.
[Bug middle-end/108181] [missed optimization] Call to virtual function under runtime index should be optimized into jump with an offset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108181 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2022-12-19 --- Comment #1 from Andrew Pinski --- [local count: 1073741809]: switch (idx_13(D)) [0.00%], case 0: [10.00%], case 1: [10.00%], case 2: [10.00%], case 3: [10.00%], case 4: [10.00%], case 5: [10.00%], case 6: [10.00%], case 7: [10.00%], case 8: [10.00%], case 9: [10.00%]> [local count: 107374182]: : _1 = MEM[(int (*) () * *)f_14(D)]; iftmp.0_43 = *_1; _45 = iftmp.0_43 (f_14(D)); [tail call] goto ; [100.00%] [local count: 107374182]: : _2 = MEM[(int (*) () * *)f_14(D)]; iftmp.2_40 = MEM[(int (*) () *)_2 + 8B]; _42 = iftmp.2_40 (f_14(D)); [tail call] goto ; [100.00%] So 3 things need to happen. First pulling out the load from f_14 (getting the vtable) out of the switch. And then pushing the call out of the switch. And then seeing the load that is left is idx_13(D) * 4. There are a few bugs for these things but I am not going to look for them right now.
[Bug c++/108181] New: [missed optimization] Call to virtual function under runtime index should be optimized into jump with an offset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108181
Bug ID: 108181
Summary: [missed optimization] Call to virtual function under
runtime index should be optimized into jump with an
offset
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: m.cencora at gmail dot com
Target Milestone: ---
Given code below compiled with g++ 11 or newer, compiler should be able to
optimize 'get' into similar code as manually-optimized 'get_opt'.
g++ -std=c++20 -O2
#include
#include
struct foo
{
virtual constexpr int& get0() noexcept = 0;
virtual constexpr int& get1() noexcept = 0;
virtual constexpr int& get2() noexcept = 0;
virtual constexpr int& get3() noexcept = 0;
virtual constexpr int& get4() noexcept = 0;
virtual constexpr int& get5() noexcept = 0;
virtual constexpr int& get6() noexcept = 0;
virtual constexpr int& get7() noexcept = 0;
virtual constexpr int& get8() noexcept = 0;
virtual constexpr int& get9() noexcept = 0;
};
template
constexpr auto memPtr = nullptr;
template
constexpr auto memPtr = ::get0;
template
constexpr auto memPtr = ::get1;
template
constexpr auto memPtr = ::get2;
template
constexpr auto memPtr = ::get3;
template
constexpr auto memPtr = ::get4;
template
constexpr auto memPtr = ::get5;
template
constexpr auto memPtr = ::get6;
template
constexpr auto memPtr = ::get7;
template
constexpr auto memPtr = ::get8;
template
constexpr auto memPtr = ::get9;
int& get(unsigned idx, foo* f) noexcept
{
switch (idx)
{
case 0:
return (f->*memPtr)();
case 1:
return (f->*memPtr)();
case 2:
return (f->*memPtr)();
case 3:
return (f->*memPtr)();
case 4:
return (f->*memPtr)();
case 5:
return (f->*memPtr)();
case 6:
return (f->*memPtr)();
case 7:
return (f->*memPtr)();
case 8:
return (f->*memPtr)();
case 9:
return (f->*memPtr)();
default:
__builtin_unreachable();
}
}
int& get_opt(unsigned idx, foo* f) noexcept
{
// assuming System V x64 ABI
struct RawMemPtr
{
std::uintptr_t v[2];
};
using PtrType = int& (foo::*)() noexcept;
const RawMemPtr rawPtr{{sizeof(void*) * idx + 1, 0}};
const auto ptr = std::bit_cast(rawPtr);
return (f->*ptr)();
}
[Bug c++/108180] New: [OpenMP] Passing a class member variable to firstprivate() erroneously calls its dtor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108180 Bug ID: 108180 Summary: [OpenMP] Passing a class member variable to firstprivate() erroneously calls its dtor Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: i...@ebner-markus.de Target Milestone: --- Created attachment 54128 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54128=edit Minimal example cpp Following situation: I have a class. This class has a member variable (itself of a complex type). The class also has a member function in which an OpenMP loop (#pragma omp parallel for) is used. This loop accesses the mentioned class member variable through the firstprivate() flag. As far as I understood, this should copy the variable into every worker thread by calling the copy constructor. However, now upon leaving the class's member function, the dtor of the class member variable is called. Here is a code example: https://godbolt.org/z/oxb3Pq9he The log shows, that the dtor of the mentioned class member variable is erroneously called twice.
[Bug target/108174] ICE: tree check: expected function_type or method_type, have ggc_freed in aarch64_resolve_overloaded_memtag, at config/aarch64/aarch64-builtins.cc:3349
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108174 --- Comment #4 from Andrew Pinski --- (In reply to Arseny Solokha from comment #3) > Created attachment 54127 [details] > Preprocessed testcase > > Though for that to ICE, I have to change an argument to --param > ggc-min-expand from 3 to 1. Right, most likely a variable or some source is not marked with GTY. Usually `--param ggc-min-expand=0 --param ggc-min-heapsize=0` Will always cause the ICE; though this can be slow as gc is a mark and sweep and marking can be slow.
[Bug target/108174] ICE: tree check: expected function_type or method_type, have ggc_freed in aarch64_resolve_overloaded_memtag, at config/aarch64/aarch64-builtins.cc:3349
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108174 --- Comment #3 from Arseny Solokha --- Created attachment 54127 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54127=edit Preprocessed testcase Though for that to ICE, I have to change an argument to --param ggc-min-expand from 3 to 1.
[Bug target/108177] MVE predicated stores to same address get optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108177 --- Comment #3 from avieira at gcc dot gnu.org --- The architecture describes it as only writing the true-predicated bytes and leaving the others untouched. I guess reading and writting to the same memory is the best we can do to 'mimic' that in RTL. SVE does the same as x86, so I'll try that approach over unspec_volatile.
[Bug modula2/108153] Profiled lto bootstrap failure with modula2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108153 --- Comment #4 from Jakub Jelinek --- I've tried to reproduce it on gcc112.fsffrance.org with ../configure --enable-languages=c,c++,lto,m2 --with-build-config=bootstrap-lto --enable-link-serialization=1 --disable-libsanitizer make -j160 profiledbootstrap but it works there.
[Bug c++/101603] [meta-bug] pointer to member functions issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101603 Bug 101603 depends on bug 108104, which changed state. Bug 108104 Summary: ICE in unify, at cp/pt.c:24333 with template partial specialization and pointer to memeber function and nullptr https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108104 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/108104] ICE in unify, at cp/pt.c:24333 with template partial specialization and pointer to memeber function and nullptr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108104 Patrick Palka changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Patrick Palka --- Fixed for GCC 12.3/13, thanks for the bug report.
[Bug c++/107417] g++ fails to recognize parameter pack in requires-expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107417 Patrick Palka changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from Patrick Palka --- Fixed for GCC 12.3/13, thanks for the bug report.
[Bug c++/103081] [ICE] with "using enum"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103081 Patrick Palka changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #13 from Patrick Palka --- Fixed for GCC 12.3/13, thanks for the bug report.
[Bug c++/107542] ICE in spaceship_comp_cat, at cp/method.cc:1055
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107542 Patrick Palka changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Patrick Palka --- Fixed for GCC 12.3/13, thanks for the bug report.
[Bug c++/107579] [11/12 Regression] ICE on fold-expression on .* member access operator since r12-2862-g9707d2e5dbb92d2b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107579 --- Comment #10 from CVS Commits --- The releases/gcc-12 branch has been updated by Patrick Palka : https://gcc.gnu.org/g:cdc1a14be1182874ccf1ceb27ee5b67c5ce8c62d commit r12-8998-gcdc1a14be1182874ccf1ceb27ee5b67c5ce8c62d Author: Patrick Palka Date: Thu Dec 15 16:02:05 2022 -0500 c++: extract_local_specs and unevaluated contexts [PR100295] Here during partial instantiation of the constexpr if, extra_local_specs walks the statement looking for local specializations within to capture. However, we're thwarted by the fact that 'ts' first appears inside an unevaluated context, and so the calls to process_outer_var_ref for its local specializations are a no-op. And since we walk each tree exactly once, we end up not capturing the local specializations despite 'ts' later occurring in an evaluated context. This patch fixes this by making extract_local_specs walk evaluated contexts first before walking unevaluated contexts. We could probably get away with not walking unevaluated contexts at all, but this approach seems more clearly safe. PR c++/100295 PR c++/107579 gcc/cp/ChangeLog: * pt.cc (el_data::skip_unevaluated_operands): New data member. (extract_locals_r): If skip_unevaluated_operands is true, don't walk into unevaluated contexts. (extract_local_specs): Walk the pattern twice, first with skip_unevaluated_operands true followed by it set to false. gcc/testsuite/ChangeLog: * g++.dg/cpp1z/constexpr-if-lambda5.C: New test. (cherry picked from commit 18499b9f848707aee42d810e99ac0a4c9788433c)
[Bug c++/100295] Internal compiler error from generic lambda capturing parameter pack and expanding it in if constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100295 --- Comment #8 from CVS Commits --- The releases/gcc-12 branch has been updated by Patrick Palka : https://gcc.gnu.org/g:cdc1a14be1182874ccf1ceb27ee5b67c5ce8c62d commit r12-8998-gcdc1a14be1182874ccf1ceb27ee5b67c5ce8c62d Author: Patrick Palka Date: Thu Dec 15 16:02:05 2022 -0500 c++: extract_local_specs and unevaluated contexts [PR100295] Here during partial instantiation of the constexpr if, extra_local_specs walks the statement looking for local specializations within to capture. However, we're thwarted by the fact that 'ts' first appears inside an unevaluated context, and so the calls to process_outer_var_ref for its local specializations are a no-op. And since we walk each tree exactly once, we end up not capturing the local specializations despite 'ts' later occurring in an evaluated context. This patch fixes this by making extract_local_specs walk evaluated contexts first before walking unevaluated contexts. We could probably get away with not walking unevaluated contexts at all, but this approach seems more clearly safe. PR c++/100295 PR c++/107579 gcc/cp/ChangeLog: * pt.cc (el_data::skip_unevaluated_operands): New data member. (extract_locals_r): If skip_unevaluated_operands is true, don't walk into unevaluated contexts. (extract_local_specs): Walk the pattern twice, first with skip_unevaluated_operands true followed by it set to false. gcc/testsuite/ChangeLog: * g++.dg/cpp1z/constexpr-if-lambda5.C: New test. (cherry picked from commit 18499b9f848707aee42d810e99ac0a4c9788433c)
[Bug c++/108104] ICE in unify, at cp/pt.c:24333 with template partial specialization and pointer to memeber function and nullptr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108104 --- Comment #6 from CVS Commits --- The releases/gcc-12 branch has been updated by Patrick Palka : https://gcc.gnu.org/g:6e09ca0cba625b8bb2ef50f9df726eb455ebb813 commit r12-8997-g6e09ca0cba625b8bb2ef50f9df726eb455ebb813 Author: Patrick Palka Date: Thu Dec 15 15:38:47 2022 -0500 c++: partial ordering with memfn ptr cst [PR108104] Here we're triggering an overzealous assert in unify during partial ordering since the member function pointer constants are represented as ordinary CONSTRUCTORs (with TYPE_PTRMEMFUNC_P TREE_TYPE) but the assert expects COMPOUND_LITERAL_P constructors. PR c++/108104 gcc/cp/ChangeLog: * pt.cc (unify) : Relax assert to accept any CONSTRUCTOR parm, not just COMPOUND_LITERAL_P one. gcc/testsuite/ChangeLog: * g++.dg/template/ptrmem33.C: New test. (cherry picked from commit 38304846d18d6bb14b0fd6c627c5c6d43a814d01)
[Bug c++/107417] g++ fails to recognize parameter pack in requires-expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107417 --- Comment #4 from CVS Commits --- The releases/gcc-12 branch has been updated by Patrick Palka : https://gcc.gnu.org/g:b428bb449be1bdbbd4000b51bb7c665981dc8c8f commit r12-8996-gb428bb449be1bdbbd4000b51bb7c665981dc8c8f Author: Patrick Palka Date: Sun Dec 4 10:47:24 2022 -0500 c++: pack in requires-expr parm list [PR107417] Here find_parameter_packs_r isn't detecting the pack T inside the requires-expr's parameter list ultimately because cp_walk_trees deliberately avoids walking the list so as to avoid false positives in the unexpanded pack checker. But it should still be fine to walk the TREE_TYPE of each parameter, which we already need to do from for_each_template_parm_r, and is sufficient to fix the testcase. PR c++/107417 gcc/cp/ChangeLog: * pt.cc (for_each_template_parm_r) : Move walking of the TREE_TYPE of each parameter to ... * tree.cc (cp_walk_subtrees) : ... here. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/concepts-requires33.C: New test. (cherry picked from commit 079add3ad39d6620d34665dd9c26c21951eb657c)
[Bug c++/103081] [ICE] with "using enum"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103081 --- Comment #12 from CVS Commits --- The releases/gcc-12 branch has been updated by Patrick Palka : https://gcc.gnu.org/g:648db321893acabd06c24da149c09fceab4daeff commit r12-8995-g648db321893acabd06c24da149c09fceab4daeff Author: Patrick Palka Date: Sat Dec 3 10:28:25 2022 -0500 c++: substituting CONST_DECL_USING_P enumerators [PR103081] We implement class-scope using enum by injecting clones of the enum's CONST_DECLs as fields of the class, for which CONST_DECL_USING_P is true, so that qualified lookup naturally finds the enumerators. Substitution into such a CONST_DECL currently ICEs however, because we assume the DECL_CONTEXT is always the ENUMERAL_TYPE (which has TYPE_VALUES) but in this case it's the RECORD_TYPE for the class scope (which has TYPE_FIELDS). Since these CONST_DECLs appear to always be non-dependent, this patch fixes this by shortcutting substitution for CONST_DECLs that have non-dependent DECL_CONTEXT. This subsumes the existing (and seemingly dead) DECL_NAMESPACE_SCOPE_P early exit test and also benefits substitution into ordinary non-dependent CONST_DECLs. PR c++/103081 gcc/cp/ChangeLog: * pt.cc (tsubst_copy) : Generalize early exit test for namespace-scope decls to check dependence of the enclosing scope instead. Remove dead early exit test. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/using-enum-10.C: New test. * g++.dg/cpp2a/using-enum-10a.C: New test. (cherry picked from commit b3912122c9dfaba6c8229e8f095885f69782ceda)
[Bug c++/107542] ICE in spaceship_comp_cat, at cp/method.cc:1055
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107542 --- Comment #7 from CVS Commits --- The releases/gcc-12 branch has been updated by Patrick Palka : https://gcc.gnu.org/g:37595f8354e3e48e4a1a94537f3d1ae095ed75df commit r12-8994-g37595f8354e3e48e4a1a94537f3d1ae095ed75df Author: Patrick Palka Date: Tue Nov 29 19:25:37 2022 -0500 c++: ICE with <=> of incompatible pointers [PR107542] In a SFINAE context composite_pointer_type returns error_mark_node if the given pointer types are incompatible. But the SPACESHIP_EXPR case of cp_build_binary_op wasn't prepared for this error_mark_node result, which led to an ICE (from spaceship_comp_cat) for the below testcase. (In a non-SFINAE context composite_pointer_type issues a permerror and returns cv void* in this case, so this ICE seems specific to SFINAE.) PR c++/107542 gcc/cp/ChangeLog: * typeck.cc (cp_build_binary_op): In the SPACESHIP_EXPR case, handle an error_mark_node result type. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/spaceship-sfinae2.C: New test. (cherry picked from commit 000e9863120cbc75a0f8d497264519974c97669f)
[Bug c/98487] ICE: tree check: expected identifier_node, have tree_list in is_attribute_p, at attribs.h:155 [C2X or C++11 attribute syntax, gnu::format and -Wsuggest-attribute=format] or a suggest wa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98487 Andrew Pinski changed: What|Removed |Added Known to fail||12.2.0 Known to work||12.2.1 Target Milestone|--- |12.3
[Bug c/98487] ICE: tree check: expected identifier_node, have tree_list in is_attribute_p, at attribs.h:155 [C2X or C++11 attribute syntax, gnu::format and -Wsuggest-attribute=format] or a suggest wa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98487 Marek Polacek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #8 from Marek Polacek --- Fixed for GCC 13 and 12.3.
[Bug c/98487] ICE: tree check: expected identifier_node, have tree_list in is_attribute_p, at attribs.h:155 [C2X or C++11 attribute syntax, gnu::format and -Wsuggest-attribute=format] or a suggest wa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98487 --- Comment #7 from CVS Commits --- The releases/gcc-12 branch has been updated by Marek Polacek : https://gcc.gnu.org/g:0e345504ec9349d9a3bf826c3e16b7e973739485 commit r12-8993-g0e345504ec9349d9a3bf826c3e16b7e973739485 Author: Marek Polacek Date: Fri Dec 16 12:28:43 2022 -0500 c-family: Fix ICE with -Wsuggest-attribute [PR98487] Here we crash because check_function_format was using TREE_PURPOSE directly rather than using get_attribute_name. PR c/98487 gcc/c-family/ChangeLog: * c-format.cc (check_function_format): Use get_attribute_name. gcc/testsuite/ChangeLog: * c-c++-common/Wsuggest-attribute-1.c: New test. (cherry picked from commit 68e51bd0a85794cd437d3e740357dfef84dc560d)
[Bug c/98487] ICE: tree check: expected identifier_node, have tree_list in is_attribute_p, at attribs.h:155 [C2X or C++11 attribute syntax, gnu::format and -Wsuggest-attribute=format] or a suggest wa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98487 --- Comment #6 from CVS Commits --- The trunk branch has been updated by Marek Polacek : https://gcc.gnu.org/g:68e51bd0a85794cd437d3e740357dfef84dc560d commit r13-4796-g68e51bd0a85794cd437d3e740357dfef84dc560d Author: Marek Polacek Date: Fri Dec 16 12:28:43 2022 -0500 c-family: Fix ICE with -Wsuggest-attribute [PR98487] Here we crash because check_function_format was using TREE_PURPOSE directly rather than using get_attribute_name. PR c/98487 gcc/c-family/ChangeLog: * c-format.cc (check_function_format): Use get_attribute_name. gcc/testsuite/ChangeLog: * c-c++-common/Wsuggest-attribute-1.c: New test.
[Bug c++/108179] [11/12/13 regression] ICE related to template template parameters in tsubst, at cp/pt.cc:15782
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108179 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2022-12-19 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug c++/108179] [11/12/13 regression] ICE related to template template parameters in tsubst, at cp/pt.cc:15782
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108179 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |11.4 Known to fail||11.3.0, 12.1.0 Known to work||11.1.0, 11.2.0 Summary|[11/12 regression] ICE |[11/12/13 regression] ICE |related to template |related to template |template parameters in |template parameters in |tsubst, at cp/pt.cc:15782 |tsubst, at cp/pt.cc:15782
[Bug c++/108179] New: [11/12 regression] ICE related to template template parameters in tsubst, at cp/pt.cc:15782
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108179
Bug ID: 108179
Summary: [11/12 regression] ICE related to template template
parameters in tsubst, at cp/pt.cc:15782
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: s at stu dot scot
Target Milestone: ---
Created attachment 54126
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54126=edit
Bug report from -freport-bug
The following code produces an internal compiler error on all g++ 11 and 12
versions I tried. This is the most minimal example I could come up with. It
compiles fine under g++ 10 and clang.
```
template class F>
struct Foo {};
template class F>
void f(Foo) {}
```
Works in:
* g++-10 (Ubuntu 10.4.0-4ubuntu1~22.04) 10.4.0
Doesn't work in:
* g++-11 (Ubuntu 11.3.0-1ubuntu1~22.04) 11.3.0
* g++-12 (Ubuntu 12.1.0-2ubuntu1~22.04) 12.1.0
* x86-64 gcc 12.2 on compiler explorer: https://godbolt.org/z/EMncPKcea
[Bug c++/64867] split warning for passing non-POD to varargs function from -Wconditionally-supported into new warning flag, -Wnon-pod-varargs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64867 --- Comment #32 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:263c22a95bc9a0d80c4873c0291b0f938cea7310 commit r13-4795-g263c22a95bc9a0d80c4873c0291b0f938cea7310 Author: Jason Merrill Date: Mon Dec 5 10:00:31 2022 -0500 build: add -Wconditionally-supported to strict_warn [PR64867] The PR (which isn't resolved by this commit) pointed out to me that GCC should build with -Wconditionally-supported to support bootstrapping with a C++11 compiler that makes different choices. PR c++/64867 gcc/ChangeLog: * configure.ac (strict_warn): Add -Wconditionally-supported. * configure: Regenerate.
[Bug libstdc++/108178] Filesystem::copy_file can't copy from /proc on Linux machines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108178 --- Comment #3 from Jonathan Wakely --- On the other hand, it's not a bug in /proc, because the size of some of those files might vary dynamically, and the size isn't known until you try to read it. So even if we got a size from stat, we might read a different number of bytes once we open it, and so sendfile wouldn't copy the whole thing anyway. And on the gripping hand, reading from /proc could be considered undefined behaviour because files that are changing while performing std::filesystem operations cause races and so the behaviour is not defined by the standard. But we can make it work in practice.
[Bug target/108172] [13 Regression] ICE in emit_move_multi_word, at expr.cc:4087 since r13-4616-g2cba118e538ba0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108172 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug target/108177] MVE predicated stores to same address get optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108177
--- Comment #2 from Richard Biener ---
I suspect
(insn 10 9 11 2 (set (mem:V16QI (reg/v/f:SI 117 [ pa ]) [0 MEM[(signed char[16]
*)pa_2(D)]+0 S16 A8])
(unspec:V16QI [
(reg/v:V16QI 116 [ a ])
(reg:V16BI 120)
] VSTRBQ_U)) "include/arm_mve.h":12501:3 4673 {mve_vstrbq_p_uv16qi}
(nil))
isn't a very accurate description of a masked store. On x86 we have
(insn 17 16 0 (set (mem:V8DI (reg/v/f:DI 87 [ p ]) [0 S64 A8])
(vec_merge:V8DI (reg:V8DI 92)
(mem:V8DI (reg/v/f:DI 87 [ p ]) [0 S64 A8])
(subreg:QI (reg:SI 95) 0)))
"/home/rguenther/obj-trunk-g/gcc/include/avx512fintrin.h":6484:3 -1
For AVX we use:
(define_expand "maskstore"
[(set (match_operand:V48_AVX2 0 "memory_operand")
(unspec:V48_AVX2
[(match_operand: 2 "register_operand")
(match_operand:V48_AVX2 1 "register_operand")
(match_dup 0)]
UNSPEC_MASKMOV))]
"TARGET_AVX")
note how the memory destination is also an input to the UNSPEC here.
[Bug libstdc++/108178] Filesystem::copy_file can't copy from /proc on Linux machines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108178 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2022-12-19 Ever confirmed|0 |1 --- Comment #2 from Jonathan Wakely --- Yes, but we should probably add a workaround anyway. Maybe we should not use sendfile for zero-sized files, and use fstream instead. That will copy until EOF, without caring about the file size obtained from stat(2). For real files that actually do have zero size that might be slightly slower than attempting to use sendfile, but hopefully not too bad. I'll try to benchmark it.
[Bug libstdc++/108178] Filesystem::copy_file can't copy from /proc on Linux machines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108178 --- Comment #1 from Richard Biener --- But that's a bug of the procfs filesystem, not of the standard library.
[Bug tree-optimization/108164] [12 Regression] wrong code with "-O3 -fno-tree-dce" on x86_64-linux-gnu since r12-5267-g540d92ae9b629eb4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108164 Richard Biener changed: What|Removed |Added Known to work||13.0 Summary|[12/13 Regression] wrong|[12 Regression] wrong code |code with "-O3 |with "-O3 -fno-tree-dce" on |-fno-tree-dce" on |x86_64-linux-gnu since |x86_64-linux-gnu since |r12-5267-g540d92ae9b629eb4 |r12-5267-g540d92ae9b629eb4 | Priority|P3 |P2 --- Comment #9 from Richard Biener --- Fixed on trunk sofar.
[Bug tree-optimization/108164] [12/13 Regression] wrong code with "-O3 -fno-tree-dce" on x86_64-linux-gnu since r12-5267-g540d92ae9b629eb4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108164 --- Comment #8 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:ec459469f8a75d96a9b26694554efcc900d411de commit r13-4794-gec459469f8a75d96a9b26694554efcc900d411de Author: Richard Biener Date: Mon Dec 19 14:55:45 2022 +0100 tree-optimization/108164 - undefined overflow with IV vectorization vect_update_ivs_after_vectorizer can end up emitting a signed IV update when the loop body performed an unsigned computation. The following makes sure to perform that update in the type of the loop update type to avoid undefined behavior on overflow. PR tree-optimization/108164 * tree-vect-loop-manip.cc (vect_update_ivs_after_vectorizer): Perform vect_step_op_add update in the appropriate type. * gcc.dg/pr108164.c: New testcase.
[Bug libstdc++/108178] New: Filesystem::copy_file can't copy from /proc on Linux machines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108178 Bug ID: 108178 Summary: Filesystem::copy_file can't copy from /proc on Linux machines Product: gcc Version: 11.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: faivel555 at gmail dot com Target Milestone: --- Hello, When trying to copy a file from /proc folder on Linux, copy_file won't copy the file but will generate a success status. The problem is that copy_file passes 0 file size to sendfile() on Linux machines as you can see here: https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/src/filesystem/ops-common.h#L499 , making sendfile() to do nothing. Since most of the files if not all files in /proc don't have a valid file size, the copying will be successful but no files are copied. Thanks, Faivel
[Bug target/108174] ICE: tree check: expected function_type or method_type, have ggc_freed in aarch64_resolve_overloaded_memtag, at config/aarch64/aarch64-builtins.cc:3349
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108174 --- Comment #2 from Martin Liška --- Please attach pre-processed source file.
[Bug target/108172] [13 Regression] ICE in emit_move_multi_word, at expr.cc:4087 since r13-4616-g2cba118e538ba0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108172 Martin Liška changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2022-12-19 CC||marxin at gcc dot gnu.org, ||tnfchris at gcc dot gnu.org Summary|[13 Regression] ICE in |[13 Regression] ICE in |emit_move_multi_word, at|emit_move_multi_word, at |expr.cc:4087|expr.cc:4087 since ||r13-4616-g2cba118e538ba0 --- Comment #1 from Martin Liška --- Started with r13-4616-g2cba118e538ba0.
[Bug fortran/108175] Target macros missing in gfortran with -cpp (C preprocessor)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108175 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Andrew Pinski --- Dup of bug 42954 *** This bug has been marked as a duplicate of bug 42954 ***
[Bug fortran/42954] [10/11/12/13 regression] TARGET_*_CPP_BUILTINS issues with gfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42954 --- Comment #38 from Andrew Pinski --- *** Bug 108175 has been marked as a duplicate of this bug. ***
[Bug target/108177] MVE predicated stores to same address get optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108177 --- Comment #1 from avieira at gcc dot gnu.org --- I noticed that for SVE stores seem to be marked as volatile memory accesses, I suspect it's because they are represented using masked stores which probably are by definition volatile (for this reason?). A fix for this for now, before MVE starts using maskedstore patterns, would be to use unspec_volatile for such stores.
[Bug target/108177] New: MVE predicated stores to same address get optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108177
Bug ID: 108177
Summary: MVE predicated stores to same address get optimized
away
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: avieira at gcc dot gnu.org
Target Milestone: ---
GCC currently generates wrong code for predicated MVE stores to the same
address. Like:
#include
uint8x16_t foo (uint8x16_t a, uint8_t *pa, mve_pred16_t p1, mve_pred16_t p2)
{
vstrbq_p_u8 (pa, a, p1);
vstrbq_p_u8 (pa, a, p2);
}
with 'gcc -mcpu=cortex-m55 -mfloat-abi=hard -O3' it will only generate the
second MVE store. Though if (p2 | p1) != p2 then the second store will not
fully overwrite the first.
[Bug analyzer/108171] [13 Regression] ICE in binding_key::make, at analyzer/store.cc:132 since r13-4529-gdfe2ef7f2b6cac70
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108171 Martin Liška changed: What|Removed |Added Summary|[13 Regression] ICE in |[13 Regression] ICE in |binding_key::make, at |binding_key::make, at |analyzer/store.cc:132 |analyzer/store.cc:132 since ||r13-4529-gdfe2ef7f2b6cac70 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2022-12-19 CC||marxin at gcc dot gnu.org --- Comment #1 from Martin Liška --- Started with r13-4529-gdfe2ef7f2b6cac70.
[Bug testsuite/108151] gcc.dg/pr64536.c stores pointers in a long, broken for llp64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108151 --- Comment #4 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:6e85f89a7d59a99a3395b6e153b99262a58b2f6c commit r13-4783-g6e85f89a7d59a99a3395b6e153b99262a58b2f6c Author: Jakub Jelinek Date: Mon Dec 19 15:05:16 2022 +0100 testsuite: Fix up pr64536.c for LLP64 targets [PR108151] Apparently llp64 had 2 further warnings, fixed thusly. 2022-12-19 Jakub Jelinek PR testsuite/108151 * gcc.dg/pr64536.c (bar): Cast long to __INTPTR_TYPE__ before casting to long *.
[Bug modula2/108147] Bootstrap failure on powerpc64le-linux with m2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108147 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #16 from Jakub Jelinek --- Should be fixed now.
[Bug modula2/108147] Bootstrap failure on powerpc64le-linux with m2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108147
--- Comment #15 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:158b18ffa510105b239bd2f4a253ed33e21fcebc
commit r13-4781-g158b18ffa510105b239bd2f4a253ed33e21fcebc
Author: Jakub Jelinek
Date: Mon Dec 19 14:20:36 2022 +0100
modula2: Fix up bootstrap on powerpc64le-linux [PR108147]
As mentioned in the PR, bootstrap with m2 enabled currently fails
on powerpc64le-linux, we get weird ICE after printing some diagnostics.
The problem is that mc creates from *.def prototypes like
extern void m2linemap_WarningAtf (m2linemap_location_t location, void *
message);
but the actual function definitions use
void m2linemap_WarningAtf (m2linemap_location_t location, void * message,
...) { code }
and on powerpc64le-linux such lying about the prototype results in
wrong-code, on the caller side we assume the function isn't varargs
and so don't reserve 64 bytes in the frame for it, while the callee
relies on the area being reserved and stores into it.
Fixed by adding non-stdarg wrappers around stdarg functions (because
we want va_list and pass it to diagnostics functions).
2022-12-19 Jakub Jelinek
PR modula2/108147
* gm2-gcc/m2linemap.def (ErrorAtf, WarningAtf, NoteAtf):
Comment out prototypes with varargs.
* gm2-gcc/m2linemap.h (m2linemap_ErrorAtf, m2linemap_WarningAtf,
m2linemap_NoteAtf): No longer varargs.
* gm2-gcc/m2linemap.cc (m2linemap_ErrorAtf): Turned into a
non-varargs wrapper around ...
(m2linemap_ErrorAtf_1): ... this. New static function.
(m2linemap_WarningAtf): Turned into a non-varargs wrapper around
...
(m2linemap_WarningAtf_1): ... this. New static function.
(m2linemap_NoteAtf): Turned into a non-varargs wrapper around ...
(m2linemap_NoteAtf_1): ... this. New static function.
[Bug tree-optimization/108164] [12/13 Regression] wrong code with "-O3 -fno-tree-dce" on x86_64-linux-gnu since r12-5267-g540d92ae9b629eb4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108164
--- Comment #7 from Richard Biener ---
Hmm, it's correct.
short __attribute__((noipa))
foo(short f)
{
while (f >= -1)
f++;
return f;
}
int main ()
{
if (foo (-1) != -32768)
__builtin_abort ();
return 0;
}
shows exactly the same vectorization (-O3 -fno-vect-cost-model --param
vect-epilogues-nomask=0).
With the testcase in the description thread2 performs some threading which
isn't performed on this testcase though and that's a trigger.
-fdbg-cnt=registered_jump_thread:3-4 triggers it (3-3 and 4-4 is broken as
well).
The difference between -fdbg-cnt=registered_jump_thread:3-3 (borken) and
-fdisable-tree-thread2 (OK) is
--- a/a-t.c.254t.optimized 2022-12-19 13:43:00.654410480 +0100
+++ b/a-t.c.254t.optimized 2022-12-19 13:43:08.818523519 +0100
@@ -125,7 +125,7 @@
[local count: 118111600]:
# RANGE [irange] short int [-INF, -2]
- # f_34 = PHI <-32768(3), f_36(5)>
+ # f_34 = PHI <-32767(3), f_36(5)>
# RANGE [irange] int [-2147483647, 1]
_4 = c.3_31 + 1;
if (_4 != 1)
this difference appears at a-t.c.196t.dom3 which follows thread2. We enter
dom3 with
[local count: 105119324]:
# f_71 = PHI
[local count: 118111600]:
# RANGE [irange] short int [-INF, -2]
# f_34 = PHI
and the dom3 dump has things like
Optimizing block #9
LKUP STMT f.1_96 = PHI
2>>> STMT f.1_96 = PHI
STMT f.1_96 = PHI
Optimizing statement _9 = f.1_96 + 2;
Replaced 'f.1_96' with constant '32767'
gimple_simplified to _9 = 32769;
Folded to: _9 = 32769;
_9 : global value re-evaluated to [irange] UNDEFINED
LKUP STMT _9 = 32769
ASGN _9 = 32769
Optimizing statement f_40 = (short int) _9;
Replaced '_9' with constant '32769'
gimple_simplified to f_40 = -32767;
Folded to: f_40 = -32767;
f_40 : global value re-evaluated to [irange] UNDEFINED
LKUP STMT f_40 = -32767
Something goes wrong here. For example for
_9 = 32769;
we have [irange] unsigned short [1, 32768] as global range and
gimple_ranger::update_stmt will update that to UNDEFINED
That bogus value comes from cprop_into_successor_phis where we have
a SSA_NAME_VALUE of -32767 recorded for f_71. The only place I see is
0>>> COPY f_71 = -32767
0>>> COPY f_34 = -32767
LKUP STMT _4 = c.3_31 plus_expr 1
LKUP STMT _4 ne_expr 1
Registering killing_def (path_oracle) _4
Registering value_relation (path_oracle) (_4 > c.3_31) (root: bb9)
COPY f_34 = -32767
COPY f_71 = -32767
but as you can see we revert that again.
The value pops in again from record_equivalences_from_phis when visiting BB 15
via
/* If we managed to iterate through each PHI alternative without
breaking out of the loop, then we have a PHI which may create
a useful equivalence. We do not need to record unwind data for
this, since this is a true assignment and not an equivalence
inferred from a comparison. All uses of this ssa name are dominated
by this assignment, so unwinding just costs time and space. */
if (i == gimple_phi_num_args (phi))
{
if (may_propagate_copy (lhs, rhs))
set_ssa_name_value (lhs, rhs);
because just one edge is marked EDGE_EXECUTABLE (9 -> 15). That means
the value computed in BB9 is wrong. That's exactly that with the
UNDEFINED global range result.
I _think_ what may go wrong is that we emit
[local count: 94607391]:
_50 = BIT_FIELD_REF ;
niters_vector_mult_vf.19_74 = bnd.18_75 << 3;
_72 = (short int) niters_vector_mult_vf.19_74;
tmp.20_73 = f_36 + _72;
if (niters_vector_mult_vf.19_74 == niters.17_100)
goto ; [12.50%]
else
goto ; [87.50%]
[local count: 82781467]:
# f_92 = PHI
# RANGE [irange] unsigned short [0, 32767][+INF, +INF]
f.1_98 = (unsigned short) f_92;
see how we replace the final value with something computed in signed
arithmetic. This is also visible in my shorter testcase.
I have a patch.
[Bug c++/108165] -Wdangling-reference false positive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108165
--- Comment #4 from Jonathan Wakely ---
(In reply to Romain Geissler from comment #3)
> In my real life case B was std::string and used a "string literal" at call
> site, and I guess using the implicit conversion from const char[] to
> std::string is something that might happen in many call sites in big code
> bases.
And in general that is not safe.
const std::string& f(const std::string& s) { return s; }
const std::string& s = f(""); // BUG
Warning here would be entirely correct. A temporary string is created from the
string literal, then a reference to that temporary is returned, and bound to
another reference.
This is a dangling reference, and a serious bug, and exactly what the new
warning is designed to diagnose.
> Is it expected that -Wdangling-reference doesn't take into account the
> definition of f ?
Yes.
> The problem of dangling reference in general needs
> function definitions to be effective, otherwise I fear there might be quite
> some false positives.
Yes, but not in a case like f(const std::string&) above. The warning is correct
in most real cases.
The situation for the code in comment 0 is different though, there is no A
temporary. The temporary is the second argument of type B, and that isn't
returned. This seems like a bug in the implementation of the warning's
heuristics, not a problem with the design of the warning.
[Bug modula2/108176] Bootstrap fails with --with-build-config=bootstrap-ubsan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108176 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2022-12-19
