[Bug tree-optimization/101105] [11/12 Regression] wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101105 --- Comment #6 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:50374fdacbd121bc4a61b073e559208ff61bee06 commit r12-1765-g50374fdacbd121bc4a61b073e559208ff61bee06 Author: Richard Biener Date: Wed Jun 23 12:43:03 2021 +0200 tree-optimization/101105 - fix runtime alias test optimization We were ignoring DR_STEP for VF == 1 which is OK only in case the scalar order is preserved or both DR steps are the same. 2021-06-23 Richard Biener PR tree-optimization/101105 * tree-vect-data-refs.c (vect_prune_runtime_alias_test_list): Only ignore steps when they are equal or scalar order is preserved. * gcc.dg/torture/pr101105.c: New testcase.
[Bug target/101185] [12 Regression] pr96814.c failed after r12-1669 on non-avx512 platform
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101185 --- Comment #6 from Uroš Bizjak --- (In reply to Richard Biener from comment #5) > Of course I wonder why the RA even chooses registers that are not available > on the architecture. I suppose there's no real way to turn regs on/off but > the way is to make them never match any instruction pattern and thus give RA > no incentive to use them? That is, why was kmovd %edx,%k0 deemed a valid > recognizable instruction? RA is not problematic here, because registers are available due to -mavx512f. The problem is that due to the register pressure around cpuid insn on 32bit targets RA chooses to move the value to the mask register. cpuid and the logic around is used to determine if avx512f is supported on the runtime target, and mask instructions acting as logic instructions around cpuid causes SIGILL in case avx512 is not supported during execution. The solution to this is to allocate mask registers last and raise the cost of moves from GPR to mask regs, so (similar to MMX) mask regs are only used when absolutely necessary. In the past, I have introduced separate instruction patterns, instanced exclusively from builtins, but they didn't support generic logic operators, e.g. "mask1 & mask2". To solve this, mask reg alternatives were added to standard logic patterns, so there is now no clear cut between mask and GPR alternatives.
[Bug tree-optimization/101173] [9/10/11/12 Regression] wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101173 Richard Biener changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #6 from Richard Biener --- No problem, I'll hold on the patch for a bit longer to give you a chance to look.
[Bug tree-optimization/101061] tree-vrp misoptimization on skylake+ using union-based aliasing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101061 Richard Biener changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #15 from Richard Biener --- Let's close this now.
[Bug tree-optimization/101105] [11 Regression] wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101105 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Summary|[11/12 Regression] wrong|[11 Regression] wrong code |code at -O3 on |at -O3 on x86_64-linux-gnu |x86_64-linux-gnu| Assignee|rsandifo at gcc dot gnu.org|rguenth at gcc dot gnu.org Known to work||12.0 --- Comment #7 from Richard Biener --- Fixed on trunk sofar.
[Bug target/101185] [12 Regression] pr96814.c failed after r12-1669 on non-avx512 platform
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101185 --- Comment #7 from Hongtao.liu --- The key point here is cpuid check function should not be compiled with -mavx512vl or -mavx512bw, rely on cost model or alloca order is not all-inclusive.
[Bug tree-optimization/101105] [11 Regression] wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101105 Richard Biener changed: What|Removed |Added Known to work||7.5.0 --- Comment #8 from Richard Biener --- Note the same problematic code exists on the 8, 9 and 10 branches, too, only the 7 branch has sufficiently different code.
[Bug gcov-profile/80223] RFE: Exclude functions from profile instrumentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80223 --- Comment #22 from Martin Liška --- > For example, if an inlining pass happens after instrumentation, then the > function attribute doesn't necessarily need to suppress inlining. After > instrumentation is done, we can even treat the noprofile attribute as a > no-op. In the case of GCC, the instrumentation happens before inlining, but after early inlining. The patch reviewer noticed that and we would implement it that way. So yes, in order to preserve the attribute contract, we have to block inlining for functions decorated with the attribute.
[Bug c/101188] New: [AVR] Miscompilation and function pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101188 Bug ID: 101188 Summary: [AVR] Miscompilation and function pointers Product: gcc Version: 11.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: joel.bertrand at systella dot fr Target Milestone: --- Hello, I'm writing a firmware that runs on an ATmega1284. To build this bare metal firmware, I have used avr-gcc 5.4.0 and I have seen a strange pointer corruption. Thus, I have built from scratch a new gcc (11.1.0) that triggers the same bug. In a first time, my code is downloadable at https://hilbert.systella.fr/public/firmware.tar.gz I have tried to make a simple testcase, but when I remove some unused code, sometimes, firmware runs as expected. That being said, a lot of code is not executed. In main.c, I only initialize my board and I only try to send LoRaWAN packets. In lorawan/ldl_mac.c, you will find the following code : #if defined(LDL_FIX_GCC_BUG) void app_handler(void *app, enum ldl_mac_response_type type, const union ldl_mac_response_arg *arg); if (self->handler != app_handler) for(;;); #endif self->handler(self->app, LDL_MAC_DEV_NONCE_UPDATED, &arg); If I undefined LDL_FIX_GCC_BUG, firmware crashes as self->handler seems to be nullified. With LDL_FIX_GCC_BUG, firmware never stalls in for(;;) and runs as expected. Of course, self->handler should be equal to app_handler. If I replace self->handler(self->app, LDL_MAC_DEV_NONCE_UPDATED, &arg) by app_handler(self->app, LDL_MAC_DEV_NONCE_UPDATED, &arg), even if I delete code between #if and #endif, firmware runs also as expected. Thus, I have checked assembly output. good_2.S : (https://hilbert.systella.fr/public/good_2.S) a318: f6 01 movw r30, r12 ... a33c: e3 50 subi r30, 0x03 ; 3 a33e: ff 4f sbci r31, 0xFF ; 255 a340: 01 90 ld r0, Z+ a342: f0 81 ld r31, Z a344: e0 2d mov r30, r0 This loads Z with R13:R12, and then later offsets it by -0xFF03 to obtain the address of self->handler, which is then used by the icall instruction. bad.S : (https://hilbert.systella.fr/public/bad.S) a31c: f6 01 movw r30, r12 ... a340: 68 01 movw r12, r16 a342: ff e4 ldi r31, 0x4F ; 79 a344: cf 1a sub r12, r31 a346: fe ef ldi r31, 0xFE ; 254 a348: df 0a sbc r13, r31 a34a: e3 50 subi r30, 0x03 ; 3 a34c: ff 4f sbci r31, 0xFF ; 255 a34e: 01 90 ld r0, Z+ a350: f0 81 ld r31, Z a352: e0 2d mov r30, r0 Note the clobbering of R31:R30 with immediate values *before* the offsetting is done. I think this is a codegen bug - the compiler should have either picked a different set of regs to subtract R13:R12 from, or should have restored Z with a movw r30, r12 before 0xa34a. Regards, JN
[Bug tree-optimization/101178] SLP permute propagation doesn't handle VEC_PERM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101178
--- Comment #1 from Richard Biener ---
Another case:
double a[2], b[2], c[2];
void foo ()
{
double tem0 = a[1] + b[1];
double tem1 = a[0] - b[0];
c[0] = tem0;
c[1] = tem1;
}
here the addsub VEC_PERM merge node has wrong order (+, - instead of -, +)
for x86 addsub at the place we currently match for SLP patterns. But if
we'd move the load permutations across this node we can not only save
one permute but also match x86 addsub.
Currently optimize_slp materializes the perms at the addsub VEC_PERM merge
node which does the trick (but pattern matching was too early here).
It will be a cost thing to decide whether to materialize here or to hope
for eliding another permute up the chain.
double a[2], b[2], c[2];
void foo ()
{
double tem0 = a[1] - b[1];
double tem1 = a[0] + b[0];
c[0] = tem0;
c[1] = tem1;
}
is currently miscompiled when we first match .ADDSUB since then optimize_slp
happily treats it as lane agnostic operation. That's probably a latent
wrong-code issue on the branch as well.
[Bug tree-optimization/101189] New: ICE at -Os and above on x86_64-linux-gnu: in fold_cond, at vr-values.c:3471
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101189
Bug ID: 101189
Summary: ICE at -Os and above on x86_64-linux-gnu: in
fold_cond, at vr-values.c:3471
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: zhendong.su at inf dot ethz.ch
Target Milestone: ---
[535] % 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/12.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 12.0.0 20210624 (experimental) [master revision
fcf617f0d2a:8f55dced666:3bd86940c428de9dde53e41265fb1435ed236f5e] (GCC)
[536] %
[536] % gcctk -O1 small.c; ./a.out
[537] %
[537] % gcctk -Os small.c
during GIMPLE pass: evrp
small.c: In function ‘main’:
small.c:13:1: internal compiler error: in fold_cond, at vr-values.c:3471
13 | }
| ^
0x1189432 simplify_using_ranges::fold_cond(gcond*)
../../gcc-trunk/gcc/vr-values.c:3470
0x1189465 simplify_using_ranges::simplify_cond_using_ranges_1(gcond*)
../../gcc-trunk/gcc/vr-values.c:3513
0x119194f simplify_using_ranges::simplify(gimple_stmt_iterator*)
../../gcc-trunk/gcc/vr-values.c:4229
0x184ffb8 hybrid_folder::fold_stmt(gimple_stmt_iterator*)
../../gcc-trunk/gcc/gimple-ssa-evrp.c:527
0xfa5116 substitute_and_fold_dom_walker::before_dom_children(basic_block_def*)
../../gcc-trunk/gcc/tree-ssa-propagate.c:870
0x1808717 dom_walker::walk(basic_block_def*)
../../gcc-trunk/gcc/domwalk.c:309
0xfa42d5 substitute_and_fold_engine::substitute_and_fold(basic_block_def*)
../../gcc-trunk/gcc/tree-ssa-propagate.c:987
0x184f0ef execute_early_vrp
../../gcc-trunk/gcc/gimple-ssa-evrp.c:690
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.
[538] %
[538] % cat small.c
static int a, b;
int main() {
int d = 0, e, f = 5;
if (a)
f = 0;
for (; f < 4; f++)
;
e = f ^ -f;
e && d;
if (!e)
e || b;
return 0;
}
[Bug tree-optimization/101190] New: vectorizer failed to vectorize generate vashlv8hi, but use vashlv4si and extend.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101190
Bug ID: 101190
Summary: vectorizer failed to vectorize generate vashlv8hi, but
use vashlv4si and extend.
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: crazylht at gmail dot com
Target Milestone: ---
Host: x86_64-pc-linux-gnu
cat test.c
void
foo (unsigned short* __restrict pdst, unsigned short* psrc)
{
for (int i = 0; i != 8; i++)
pdst[i] <<= psrc[i];
}
typedef short v8hi __attribute__((vector_size(16)));
v8hi
foo1 (v8hi a, v8hi b)
{
return a << b;
}
After support vashl_optab, gcc still failed to generate vpsllvw for foo, only
success for foo1.
I wonder shouldn't foo be equal to foo1.
[Bug target/99488] dwz: /usr/lib/gcc/mips64el-linux-gnuabi64/11/go1: Found two copies of .debug_line_str section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99488 --- Comment #19 from YunQiang Su --- It is a bug of binutils: https://sourceware.org/bugzilla/show_bug.cgi?id=28009
[Bug target/99488] dwz: /usr/lib/gcc/mips64el-linux-gnuabi64/11/go1: Found two copies of .debug_line_str section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99488 --- Comment #20 from YunQiang Su --- (In reply to Andrew Pinski from comment #15) > (In reply to YunQiang Su from comment #14) > > The problem sees due to some problem of LTO. > > So I if understand correctly this binutils patch is fixes the issue? If so > please close this bug as moved and open up a binutils bug and submit the > patch there. I have no permission to close this bug report. Can you help me to do so?
[Bug target/99488] dwz: /usr/lib/gcc/mips64el-linux-gnuabi64/11/go1: Found two copies of .debug_line_str section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99488 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |MOVED --- Comment #21 from Andrew Pinski --- Marking as moved as requested.
[Bug tree-optimization/101187] enhancement for vector logic right shift with constant bigger than element precision
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101187 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Do we really want that for vectors with int or larger elements though? Shouldn't it be done for char/short elements only? For non-common targets where char and/or short could have the same precision as int, maybe best would be to do it only for elements with precision smaller than precision of integer_type_node. The advantage of doing it only for the char/short cases is that we can catch it later in warnings, ubsan etc. We should verify what we diagnose with ubsan if we say char/short element vector shifts are well defined. Also, we should do that only if the shift count is smaller than precision of integer_type_node, i.e. optimize vector char >> 8 to >> 31 but not >> 32 and more. For signed vectors >> should be optimized to shift by element precision - 1.
[Bug target/101185] [12 Regression] pr96814.c failed after r12-1669 on non-avx512 platform
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101185 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #8 from Jakub Jelinek --- Yeah, ideally main including the cpuid check should be compiled with the least possible target and if the check is successful call a noipa function with the command line chosen attributes. We've always been playing with fire here...
[Bug target/101185] [12 Regression] pr96814.c failed after r12-1669 on non-avx512 platform
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101185 --- Comment #9 from Hongtao.liu --- (In reply to Jakub Jelinek from comment #8) > Yeah, ideally main including the cpuid check should be compiled with the > least possible target and if the check is successful call a noipa function > with the command line chosen attributes. > We've always been playing with fire here... Yes, does this solution sound good to you, uros? If yes, please ignore my patch[1], I'll resend a new one. [1]https://gcc.gnu.org/pipermail/gcc-patches/2021-June/573591.html
[Bug gcov-profile/101191] New: [GCOV] Wrong coverage with "for(;;)" statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101191
Bug ID: 101191
Summary: [GCOV] Wrong coverage with "for(;;)" statement
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: gcov-profile
Assignee: unassigned at gcc dot gnu.org
Reporter: njuwy at smail dot nju.edu.cn
CC: marxin at gcc dot gnu.org
Target Milestone: ---
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-pc-linux-gnu/10.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure -enable-checking=release -enable-languages=c,c++
-disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.2.0 (GCC)
$ cat test.c
#include
#include
int x[10] = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9};
int main() {
int niterations = 0, i;
for (;;) {
int i, mi, max;
max = 0;
for (i = 0; i < 10; i++) {
if (x[i] > max) {
max = x[i];
mi = i;
}
}
if (max == 0)
break;
x[mi] = 0;
niterations++;
if (niterations > 10)
abort();
}
exit(0);
}
$ gcc -O0 --coverage test.c;./a.out;gcov test;cat test.c.gcov
libgcov profiling error:/home/wangyang/coverage/test/test.gcda:overwriting an
existing profile data with a different timestamp
File 'test.c'
Lines executed:93.33% of 15
Creating 'test.c.gcov'
-:0:Source:test.c
-:0:Graph:test.gcno
-:0:Data:test.gcda
-:0:Runs:1
-:1:#include
-:2:#include
-:3:int x[10] = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9};
-:4:
1:5:int main() {
1:6: int niterations = 0, i;
-:7:
9:8: for (;;) {
-:9:int i, mi, max;
10: 10:max = 0;
110: 11:for (i = 0; i < 10; i++) {
100: 12: if (x[i] > max) {
45: 13:max = x[i];
45: 14:mi = i;
-: 15: }
-: 16:}
10: 17:if (max == 0)
1: 18: break;
9: 19:x[mi] = 0;
9: 20:niterations++;
9: 21:if (niterations > 10)
#: 22: abort();
-: 23: }
-: 24:
1: 25: exit(0);
-: 26:}
Line 8 should be executed 10 times
[Bug tree-optimization/101186] predictable comparison of integer variables not folded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101186
--- Comment #2 from Di Zhao ---
(In reply to Richard Biener from comment #1)
> The complication is that the a == b equivalence has to be taken into account
> to relate the c < a and c >= b relations.
>
> Maybe the new relation code can do sth here, but confirmed on trunk.
>
> void g (int a, int b, int x, int y)
> {
> int c = y;
> if (a != 0)
> c = x;
> while (b < 1000)
> // without this loop, jump thread & VRP can remove dead code
> {
> if (a != 0)
> {
> if (c > x)
> printf ("Unreachable!");
> }
>
> that's also a classical example for predicated value-numbering (which we
> don't implement).
I've implemented a patch on FRE regarding this and will send it to patches
mailing list soon.
Thanks
[Bug target/101185] [12 Regression] pr96814.c failed after r12-1669 on non-avx512 platform
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101185 --- Comment #10 from Uroš Bizjak --- (In reply to Hongtao.liu from comment #9) > (In reply to Jakub Jelinek from comment #8) > > Yeah, ideally main including the cpuid check should be compiled with the > > least possible target and if the check is successful call a noipa function > > with the command line chosen attributes. > > We've always been playing with fire here... > > Yes, does this solution sound good to you, uros? If yes, please ignore my > patch[1], I'll resend a new one. > > [1]https://gcc.gnu.org/pipermail/gcc-patches/2021-June/573591.html I'm afraid the above proposed solution would shift the burden from the compiler to the user, and the burden does not justify relatively minor and solvable issue to use generic "a & b" on masks. IMO, using VxBI modes offer clear path to solution; VxBI move patterns and logic insns should be trivial to implement, whereas more "esoteric" operations, like shifts, unpacks and arithmetic, need some more though, since they don't operate on vectors. Another issue with current implementation is with DImode logic operations on masks for 32-bit targets. ATM, they are simply disabled, e.g.: (define_insn "*_1" [(set (match_operand:SWI248 0 "nonimmediate_operand" "=rm,r,?k") (any_or:SWI248 (match_operand:SWI248 1 "nonimmediate_operand" "%0,0,k") (match_operand:SWI248 2 "" "r,m,k"))) (clobber (reg:CC FLAGS_REG))] where ;; Single word integer modes without QImode. (define_mode_iterator SWI248 [HI SI (DI "TARGET_64BIT")]) Please also note that mask operations do not clobber flags
[Bug target/101185] [12 Regression] pr96814.c failed after r12-1669 on non-avx512 platform
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101185 --- Comment #11 from Hongtao.liu --- (In reply to Uroš Bizjak from comment #10) > (In reply to Hongtao.liu from comment #9) > > (In reply to Jakub Jelinek from comment #8) > > > Yeah, ideally main including the cpuid check should be compiled with the > > > least possible target and if the check is successful call a noipa function > > > with the command line chosen attributes. > > > We've always been playing with fire here... > > > > Yes, does this solution sound good to you, uros? If yes, please ignore my > > patch[1], I'll resend a new one. > > > > [1]https://gcc.gnu.org/pipermail/gcc-patches/2021-June/573591.html > > I'm afraid the above proposed solution would shift the burden from the > compiler to the user, and the burden does not justify relatively minor and > solvable issue to use generic "a & b" on masks. Then we need a new type for __mmask8(perhaps w/ new psABI), orelse in the backend we always see integer mode for a & b.
[Bug tree-optimization/101189] [12 Regression] ICE at -Os and above on x86_64-linux-gnu: in fold_cond, at vr-values.c:3471 since r12-1721-ga2c9173331914eff
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101189 Martin Liška changed: What|Removed |Added Target Milestone|--- |12.0 Known to work||11.1.0 Known to fail||12.0 Version|unknown |12.0 CC||amacleod at redhat dot com, ||marxin at gcc dot gnu.org Status|UNCONFIRMED |NEW Summary|ICE at -Os and above on |[12 Regression] ICE at -Os |x86_64-linux-gnu: in|and above on |fold_cond, at |x86_64-linux-gnu: in |vr-values.c:3471|fold_cond, at ||vr-values.c:3471 since ||r12-1721-ga2c9173331914eff Last reconfirmed||2021-06-24 Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Confirmed, started with r12-1721-ga2c9173331914eff.
[Bug target/101185] [12 Regression] pr96814.c failed after r12-1669 on non-avx512 platform
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101185 --- Comment #12 from Richard Biener --- (In reply to Hongtao.liu from comment #7) > The key point here is cpuid check function should not be compiled with > -mavx512vl or -mavx512bw, rely on cost model or alloca order is not > all-inclusive. Yeah, it looks bogus to check for AVX512 in a function that has the ISA already enabled ...
[Bug tree-optimization/101187] enhancement for vector logic right shift with constant bigger than element precision
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101187 --- Comment #3 from rguenther at suse dot de --- On Thu, 24 Jun 2021, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101187 > > Jakub Jelinek changed: > >What|Removed |Added > > CC||jakub at gcc dot gnu.org > > --- Comment #2 from Jakub Jelinek --- > Do we really want that for vectors with int or larger elements though? > Shouldn't it be done for char/short elements only? > For non-common targets where char and/or short could have the same precision > as > int, maybe best would be to do it only for elements with precision smaller > than > precision of integer_type_node. > The advantage of doing it only for the char/short cases is that we can catch > it > later in warnings, ubsan etc. > We should verify what we diagnose with ubsan if we say char/short element > vector shifts are well defined. > Also, we should do that only if the shift count is smaller than precision of > integer_type_node, i.e. optimize vector char >> 8 to >> 31 but not >> 32 and > more. > For signed vectors >> should be optimized to shift by element precision - 1. But why restrict it? CCP will optimize unsigned int >> 32 as well (but yes, we diagnose that). Unless there was this OpenCL compatibility thing which leaves large shift semantics up to the target?
[Bug tree-optimization/101187] enhancement for vector logic right shift with constant bigger than element precision
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101187 --- Comment #4 from Jakub Jelinek --- To make sure we diagnose it and catch it in ubsan and FE constant expression folding. The folding of the shift count into constant can happen almost any time during the optimizations. For ubsan and FE constant expression folding likely all that is needed is that it is in match.pd GIMPLE only, because constexpr evaluation can use match.pd folding and ubsan shifts are instrumented in the FEs, but for the diagnostics not.
[Bug c++/101163] slow compilation for huge classes (>20k members functions)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101163 --- Comment #5 from René Bürgel --- Do I get that right, that this procedure is done for *every* member when adding it? So, this would make it basically quadratic...
[Bug middle-end/101172] [11/12 Regression] ICE Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101172 --- Comment #5 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:65371066d8967560e3508af4a804e0ddb90acee7 commit r12-1771-g65371066d8967560e3508af4a804e0ddb90acee7 Author: Jakub Jelinek Date: Thu Jun 24 12:22:14 2021 +0200 stor-layout: Avoid DECL_BIT_FIELD_REPRESENTATIVE with NULL TREE_TYPE [PR101172] finish_bitfield_representative has an early out if the field after a bitfield has error_mark_node type, but that early out leads to TREE_TYPE of the DECL_BIT_FIELD_REPRESENTATIVE being NULL, which breaks assumptions on code that uses the DECL_BIT_FIELD_REPRESENTATIVE during error-recovery. The following patch instead sets TREE_TYPE of the representative to error_mark_node, something the users can deal with better. At this point the representative can be set as DECL_BIT_FIELD_REPRESENTATIVE for multiple bitfields, so making sure that we clear the DECL_BIT_FIELD_REPRESENTATIVE instead would be harder (but doable, e.g. with the error_mark_node TREE_TYPE set by this patch set some flag in the caller and if the flag is there, walk all the fields once again and clear all DECL_BIT_FIELD_REPRESENTATIVE that have error_mark_node TREE_TYPE). 2021-06-24 Jakub Jelinek PR middle-end/101172 * stor-layout.c (finish_bitfield_representative): If nextf has error_mark_node type, set repr type to error_mark_node too. * gcc.dg/pr101172.c: New test.
[Bug middle-end/101170] [12 Regression] ICE in df_ref_record building libgomp for ColdFire
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101170 --- Comment #6 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:9872bd8c35be0f4d475fac739115cf5b82cdabc0 commit r12-1772-g9872bd8c35be0f4d475fac739115cf5b82cdabc0 Author: Jakub Jelinek Date: Thu Jun 24 12:24:48 2021 +0200 df: Fix up handling of paradoxical subregs in debug insns [PR101170] The recent addition of gcc_assert (regno < endregno); triggers during glibc build on m68k. The problem is that RA decisions shouldn't depend on expressions in DEBUG_INSNs and those expressions can contain paradoxical subregs of certain pseudos. If RA then decides to allocate the pseudo to a register with very small hard register REGNO, we can trigger the new assert, as (int) subreg_regno_offset may be negative on big endian and the small REGNO + the negative offset can wrap around. The following patch in that case records the range from the REGNO 0 to endregno, before the addition of the assert as both regno and endregno are unsigned it wouldn't record anything at all silently. 2021-06-24 Jakub Jelinek PR middle-end/101170 * df-scan.c (df_ref_record): For paradoxical big-endian SUBREGs where regno + subreg_regno_offset wraps around use 0 as starting regno. * gcc.dg/pr101170.c: New test.
[Bug middle-end/101172] [11 Regression] ICE Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101172 Jakub Jelinek changed: What|Removed |Added Summary|[11/12 Regression] ICE |[11 Regression] ICE |Segmentation fault |Segmentation fault --- Comment #6 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug middle-end/101170] [12 Regression] ICE in df_ref_record building libgomp for ColdFire
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101170 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Jakub Jelinek --- Should be fixed now.
[Bug c++/101163] slow compilation for huge classes (>20k members functions)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101163
--- Comment #6 from Jakub Jelinek ---
Yes, the C++ FE has quadratic behavior here:
#define A(n) int f##n;
#define B(n) A(n##0) A(n##1) A(n##2) A(n##3) A(n##4) A(n##5) A(n##6) A(n##7)
A(n##8) A(n##9)
#define C(n) B(n##0) B(n##1) B(n##2) B(n##3) B(n##4) B(n##5) B(n##6) B(n##7)
B(n##8) B(n##9)
#define D(n) C(n##0) C(n##1) C(n##2) C(n##3) C(n##4) C(n##5) C(n##6) C(n##7)
C(n##8) C(n##9)
#define E(n) D(n##0) D(n##1) D(n##2) D(n##3) D(n##4) D(n##5) D(n##6) D(n##7)
D(n##8) D(n##9)
#define F(n) E(n##0) E(n##1) E(n##2) E(n##3) E(n##4) E(n##5) E(n##6) E(n##7)
E(n##8) E(n##9)
#define G(n) F(n##0) F(n##1) F(n##2) F(n##3) F(n##4) F(n##5) F(n##6) F(n##7)
F(n##8) F(n##9)
struct S {
E(0) E(1) E(2) E(3) E(4) E(5) E(6)
};
The C FE too, but only in checking builds (
3358#ifdef ENABLE_TREE_CHECKING
3359 {
3360tree t2;
3361for (t2 = op2; t2; t2 = TREE_CHAIN (t2))
3362 gcc_assert (t2 != t1);
3363 }
3364#endif
in chainon).
E(0) E(1) E(2) E(3) E(4) E(5)
time ~/src/gcc/obj88/gcc/cc1 -quiet pr101164.C
real0m15.515s
user0m15.430s
sys 0m0.037s
time ~/src/gcc/obj88/gcc/cc1plus -quiet pr101164.C
real0m25.771s
user0m25.654s
sys 0m0.036s
E(0) E(1) E(2) E(3) E(4) E(5) E(6)
time ~/src/gcc/obj88/gcc/cc1 -quiet pr101164.C
real0m20.994s
user0m20.875s
sys 0m0.050s
time ~/src/gcc/obj88/gcc/cc1plus -quiet pr101164.C
real0m35.292s
user0m35.138s
sys 0m0.035s
In the C++ case it is
#0 fields_linear_search (klass=,
name=, want_type=true) at
../../gcc/cp/name-lookup.c:1799
#1 0x00c7b400 in get_class_binding_direct (klass=, name=,
want_type=true)
at ../../gcc/cp/name-lookup.c:1881
#2 0x00c7b9be in get_class_binding (klass=, name=, want_type=true) at
../../gcc/cp/name-lookup.c:1950
#3 0x00db109c in lookup_field_r (binfo=,
data=0x7fffcb20) at ../../gcc/cp/search.c:1023
#4 0x00db2324 in dfs_walk_all (binfo=,
pre_fn=0xdb0f2c , post_fn=0x0,
data=0x7fffcb20)
at ../../gcc/cp/search.c:1453
#5 0x00db1711 in lookup_member (xbasetype=,
name=, protect=2, want_type=true,
complain=3, afi=0x0)
at ../../gcc/cp/search.c:1166
#6 0x00c8a8be in get_class_binding (name=, scope=0x7fffea04ce10) at
../../gcc/cp/name-lookup.c:5333
#7 0x00c8b158 in push_class_level_binding_1 (name=, x=) at
../../gcc/cp/name-lookup.c:5439
#8 0x00c8b669 in push_class_level_binding (name=, x=) at
../../gcc/cp/name-lookup.c:5545
#9 0x00c8a49e in pushdecl_class_level (x=) at ../../gcc/cp/name-lookup.c:5280
#10 0x00dc3866 in finish_member_declaration (decl=) at ../../gcc/cp/semantics.c:3521
#11 0x00cd2d68 in cp_parser_member_declaration (parser=0x7fffea06e7b8)
at ../../gcc/cp/parser.c:26627
#12 0x00cd17dc in cp_parser_member_specification_opt
(parser=0x7fffea06e7b8) at ../../gcc/cp/parser.c:25990
#13 0x00ccf414 in cp_parser_class_specifier_1 (parser=0x7fffea06e7b8)
at ../../gcc/cp/parser.c:25061
#14 0x00cd057a in cp_parser_class_specifier (parser=0x7fffea06e7b8) at
../../gcc/cp/parser.c:25377
#15 0x00cc1a1a in cp_parser_type_specifier (parser=0x7fffea06e7b8,
flags=1, decl_specs=0x7fffd410, is_declaration=true,
declares_class_or_enum=0x7fffd37c,
is_cv_qualifier=0x7fffd37b) at ../../gcc/cp/parser.c:18609
#16 0x00cbc00e in cp_parser_decl_specifier_seq (parser=0x7fffea06e7b8,
flags=1, decl_specs=0x7fffd410, declares_class_or_enum=0x7fffd40c)
at ../../gcc/cp/parser.c:15210
#17 0x00cba6ff in cp_parser_simple_declaration (parser=0x7fffea06e7b8,
function_definition_allowed_p=true, maybe_range_for_decl=0x0) at
../../gcc/cp/parser.c:14466
#18 0x00cba687 in cp_parser_block_declaration (parser=0x7fffea06e7b8,
statement_p=false) at ../../gcc/cp/parser.c:14413
#19 0x00cba353 in cp_parser_declaration (parser=0x7fffea06e7b8,
prefix_attrs=) at ../../gcc/cp/parser.c:14284
#20 0x00cba448 in cp_parser_toplevel_declaration
(parser=0x7fffea06e7b8) at ../../gcc/cp/parser.c:14313
#21 0x00ca5568 in cp_parser_translation_unit (parser=0x7fffea06e7b8) at
../../gcc/cp/parser.c:4942
[Bug tree-optimization/101190] vectorizer failed to generate vashlv8hi, but extend to int and use vashlv4si instead
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101190 Richard Biener changed: What|Removed |Added Last reconfirmed||2021-06-24 Keywords||missed-optimization Ever confirmed|0 |1 Target||x86_64-pc-linux-gnu Host|x86_64-pc-linux-gnu | Status|UNCONFIRMED |NEW --- Comment #1 from Richard Biener --- the issue is that likely (is that prerequesite patch in yet?) vect_recog_over_widening_pattern is not detecting that the shift could be done in smaller than int precision. C promotion rules gives us _4 = *_3; _5 = (int) _4; _7 = *_6; _8 = (int) _7; _9 = _5 << _8; _10 = (short unsigned int) _9; *_3 = _10; where promotion of the shift amount is a GCC choice. The first reason is that we hit /* See whether we have found that this operation can be done on a narrower type without changing its semantics. */ unsigned int new_precision = last_stmt_info->operation_precision; if (!new_precision) return NULL; which is because the analysis code seems to bail for non-constant shift amounts with the fear to introduce shifts that are undefined (out-of-bounds). But then the check above doesn't really factor in a possible truncation.
[Bug ipa/101066] [10/11/12 Regression] Wrong code after fixup_cfg3 since r10-3311-gff6686d2e5f797d6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101066 --- Comment #4 from Stefan Schulze Frielinghaus --- (In reply to Martin Jambor from comment #3) > I have proposed a fix on the mailing list: > https://gcc.gnu.org/pipermail/gcc-patches/2021-June/573338.html I gave it a try on IBM Z where the testcase runs fine, now. Thanks!
[Bug gcov-profile/101192] New: [GCOV] The coverage of a callee function goes wrong.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101192
Bug ID: 101192
Summary: [GCOV] The coverage of a callee function goes wrong.
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: gcov-profile
Assignee: unassigned at gcc dot gnu.org
Reporter: njuwy at smail dot nju.edu.cn
CC: marxin at gcc dot gnu.org
Target Milestone: ---
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-pc-linux-gnu/10.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure -enable-checking=release -enable-languages=c,c++
-disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.2.0 (GCC)
$ cat test.c
#include
#include
char a[] = "12345";
char b[] = "12345";
void loop(char *pz, char *pzDta) {
for (;;) {
switch (*(pz++) = *(pzDta++)) {
case 0:
goto loopDone2;
case '"':
case '\\':
pz[-1] = '\\';
*(pz++) = pzDta[-1];
}
}
loopDone2:;
if (a - pz != b - pzDta)
abort();
}
int main() {
loop(a, b);
exit(0);
}
$ gcc -O0 --coverage test.c;./a.out;gcov test;cat test.c.gcov
libgcov profiling error:/home/wangyang/coverage/test/test.gcda:overwriting an
existing profile data with a different timestamp
File 'test.c'
Lines executed:71.43% of 14
Creating 'test.c.gcov'
-:0:Source:test.c
-:0:Graph:test.gcno
-:0:Data:test.gcda
-:0:Runs:1
-:1:#include
-:2:#include
-:3:char a[] = "12345";
-:4:char b[] = "12345";
-:5:
6:6:void loop(char *pz, char *pzDta) {
-:7: for (;;) {
6:8:switch (*(pz++) = *(pzDta++)) {
1:9:case 0:
1: 10: goto loopDone2;
-: 11:
#: 12:case '"':
-: 13:case '\\':
#: 14: pz[-1] = '\\';
#: 15: *(pz++) = pzDta[-1];
-: 16:}
-: 17: }
1: 18:loopDone2:;
-: 19:
1: 20: if (a - pz != b - pzDta)
#: 21:abort();
1: 22:}
-: 23:
1: 24:int main() {
1: 25: loop(a, b);
1: 26: exit(0);
-: 27:}
Lets see line 6, "loop" function was only executed once.
[Bug rtl-optimization/100328] IRA doesn't model matching constraint well
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100328 --- Comment #3 from Kewen Lin --- (In reply to Vladimir Makarov from comment #2) > (In reply to Kewen Lin from comment #1) > > Created attachment 50715 [details] > > ira:consider matching cstr in all alternatives > > > > With little understanding on ira, I am not quite sure this patch is on the > > reasonable direction. It aims to check the matching constraint in all > > alternatives, if there is one alternative with matching constraint and > > matches the current preferred regclass, it will record the output operand > > number and further create one copy for it. Normally it can get the priority > > against shuffle copies and the matching constraint will get satisfied with > > higher possibility, reload doesn't create extra copies to meet the matching > > constraint or the desirable register class when it has to. > > > > For FMA A,B,C,D, I think ideally copies A/B, A/C, A/D can firstly stay as > > shuffle copies, and later any of A,B,C,D gets assigned by one hardware > > register which is a VSX register but not a FP register, which means it has > > to pay costs once we can NOT go with VSX alternatives, so at that time we > > can increase the freq for the remaining copies related to this, once the > > matching constraint gets satisfied further, there aren't any extra costs to > > pay. This idea seems a bit complicated in the current framework, so the > > proposed patch aggressively emphasizes the matching constraint at the time > > of creating copies. > > > > FWIW bootstrapped/regtested on powerpc64le-linux-gnu P9. The evaluation with > > Power9 SPEC2017 all run shows 505.mcf_r +2.98%, 508.namd_r +3.37%, 519.lbm_r > > +2.51%, no remarkable degradation is observed. > > Thank you for working on this issue. > > The current implementation of ira_get_dup_out_num was specifically tuned for > better register allocation for x86-64 div insns. > > Your patch definitely improves code for power9 and I would say significantly > (congratulations!). The patch you proposed makes me think that it might > work for major targets as well. > > I would prefer to avoid introducing new parameter because there are too many > of them already and its description is cryptic. > Thanks for your comments, Vladimir! Yeah, Segher also thought it can benefit other targets and suggested making it on by default, I've made this parameter on by default in v2, if it's fine on x86-64 and aarch64 with some testing and benchmarking later, I think we can simply get rid of the parameter as you suggested. > It would be nice if you benchmark the patch on x86-64 too, If there is no > overall degradation with new behaviour we could remove the parameter and > make the new behaviour as a default. If it is not, well we will keep the > parameter. > Sorry that I don't have a x86-64 or aarch64 performance machine at hand, the new version v2 was bootstrapped/regtested on powerpc64le-linux-gnu P9 and x86_64-redhat-linux, but had some failures on aarch64, I was still investigating it. Once it got root-caused and fixed, I would ask around folks to help to benchmark this. > As for the patch itself, I don't like some variable names. Sorry. Could > you use op_regno, out_regno, and present_alt instead of op_no, out_no, tot. > Please, in general use longer variable names reflecting their purpose as GCC > developers reads code in many times more than writing it. Got it, thanks for the suggestion! This part has been simplified with recog_op_alt, hope it looks better.
[Bug target/101185] [12 Regression] pr96814.c failed after r12-1669 on non-avx512 platform
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101185
H.J. Lu changed:
What|Removed |Added
CC||hjl.tools at gmail dot com
Keywords||patch
Ever confirmed|0 |1
Last reconfirmed||2021-06-24
Status|UNCONFIRMED |NEW
--- Comment #13 from H.J. Lu ---
(In reply to Richard Biener from comment #12)
> (In reply to Hongtao.liu from comment #7)
> > The key point here is cpuid check function should not be compiled with
> > -mavx512vl or -mavx512bw, rely on cost model or alloca order is not
> > all-inclusive.
>
> Yeah, it looks bogus to check for AVX512 in a function that has the ISA
> already enabled ...
This worked by accident, not by design. The cost of mask register is
orthogonal to this CPUID issue. CPUID check should be compiled with
__attribute__ ((target("general-regs-only"))):
https://gcc.gnu.org/pipermail/gcc-patches/2021-June/573616.html
[Bug rtl-optimization/100328] IRA doesn't model matching constraint well
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100328 Kewen Lin changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org Last reconfirmed||2021-06-24 Ever confirmed|0 |1 --- Comment #4 from Kewen Lin --- Created attachment 51059 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51059&action=edit ira-respect-matching-constraint-v2 This v2 considers the situation that: for one preferred register class there can be two or more alternatives, one of them has the matching constraint, while another doesn't have. For the given operand, even if it's assigned by a hardware reg which doesn't meet the matching constraint, it can simply use the alternative which doesn't have matching constraint so no register copy is needed. One typical case is define_insn *mov_internal2 on rs6000: (define_insn "*mov_internal2" [(set (match_operand:CC 2 "cc_reg_operand" "=y,x,?y") (compare:CC (match_operand:P 1 "gpc_reg_operand" "0,r,r") (const_int 0))) (set (match_operand:P 0 "gpc_reg_operand" "=r,r,r") (match_dup 1))] "" "@ cmpi %2,%0,0 mr. %0,%1 #" So we shouldn't create constraint copy for it. For fma style insns on rs6000, there are also several alternatives for preferred regclass and also only one with matching constraint. The difference is that for the given operand although there is no matching constraint applied for the alternaitve but matching constraint is being applied for one other input operand in this same alternative, it means when one matching constraint can be applied to more than one input operand, it has to have several alternatives like this. And to create constraint copies for all of these input operands with matching constraint is fine, once the matching constraint is honored on one input operand, it implicitly disable the others due to the interference relationship. So this patch is going to record and check all the other alternatives, which don't have matching constraint but with preferred classes, whether there is one input operand having same matching constraint. It also considers the possible free register move in the same register class, disable this if so since the register copy to meet the constraint is considered as free. I re-evaluated SPEC2017 performance with option set Ofast unroll, bmks 508.namd_r and 519.lbm_r were observed to be improved by 2.4% ~ 3.8% on Power8 and Power9. As mentioned before, it's bootstrapped/regtested on powerpc64le-linux-gnu P9 and x86_64-redhat-linux, but hit some regression failures on aarch64, I am still investigating the only one PASS->FAIL: (the others are XFAIL->XPASS) PASS->FAIL: gcc.target/aarch64/sve/acle/general/pr94683.c -march=armv8.2-a+sve -moverride=tune=none check-function-bodies test In this case, the newly created constraint copy is expected (which was shuffle copy), but this copy change somehow affects the full cost on register 92 due to conflict with reg 102. Need more digging on this.
[Bug libstdc++/80504] missing qualification causes ADL to be used in std::ref / std::cref
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80504 --- Comment #5 from Jonathan Wakely --- Huh, what I actually committed doesn't match the changelog. Oops. But what I committed is better anyway.
[Bug gcov-profile/101193] New: [GCOV] Bit operation leads to wrong coverage information
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101193
Bug ID: 101193
Summary: [GCOV] Bit operation leads to wrong coverage
information
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: gcov-profile
Assignee: unassigned at gcc dot gnu.org
Reporter: njuwy at smail dot nju.edu.cn
CC: marxin at gcc dot gnu.org
Target Milestone: ---
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-pc-linux-gnu/10.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure -enable-checking=release -enable-languages=c,c++
-disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.2.0 (GCC)
$ cat test.c
#ifdef __UINT32_TYPE__
typedef __UINT32_TYPE__ uint32_t;
#else
typedef __UINT32_TYPE__ unsigned;
#endif
struct bitfield {
unsigned char f0 : 7;
unsigned char : 1;
unsigned char f1 : 7;
unsigned char : 1;
unsigned char f2 : 7;
unsigned char : 1;
unsigned char f3 : 7;
};
struct ok {
unsigned char f0;
unsigned char f1;
unsigned char f2;
unsigned char f3;
};
union bf_or_uint32 {
struct ok inval;
struct bitfield bfval;
};
__attribute__((noinline, noclone)) uint32_t
partial_read_le32(union bf_or_uint32 in) {
return in.bfval.f0 | (in.bfval.f1 << 8) | (in.bfval.f2 << 16) |
(in.bfval.f3 << 24);
}
int main() {
union bf_or_uint32 bfin;
uint32_t out;
char cin[] = {0x83, 0x85, 0x87, 0x89};
bfin.inval = (struct ok){0x83, 0x85, 0x87, 0x89};
out = partial_read_le32(bfin);
return 0;
}
$ gcc -O0 --coverage test.c;./a.out;gcov test;cat test.c.gcov
File 'test.c'
Lines executed:100.00% of 8
Creating 'test.c.gcov'
-:0:Source:test.c
-:0:Graph:test.gcno
-:0:Data:test.gcda
-:0:Runs:1
-:1:#ifdef __UINT32_TYPE__
-:2:typedef __UINT32_TYPE__ uint32_t;
-:3:#else
-:4:typedef __UINT32_TYPE__ unsigned;
-:5:#endif
-:6:
-:7:struct bitfield {
-:8: unsigned char f0 : 7;
-:9: unsigned char : 1;
-: 10: unsigned char f1 : 7;
-: 11: unsigned char : 1;
-: 12: unsigned char f2 : 7;
-: 13: unsigned char : 1;
-: 14: unsigned char f3 : 7;
-: 15:};
-: 16:
-: 17:struct ok {
-: 18: unsigned char f0;
-: 19: unsigned char f1;
-: 20: unsigned char f2;
-: 21: unsigned char f3;
-: 22:};
-: 23:
-: 24:union bf_or_uint32 {
-: 25: struct ok inval;
-: 26: struct bitfield bfval;
-: 27:};
-: 28:
-: 29:
-: 30:__attribute__((noinline, noclone)) uint32_t
1: 31:partial_read_le32(union bf_or_uint32 in) {
2: 32: return in.bfval.f0 | (in.bfval.f1 << 8) | (in.bfval.f2 << 16)
|
1: 33: (in.bfval.f3 << 24);
-: 34:}
-: 35:
-: 36:
1: 37:int main() {
-: 38: union bf_or_uint32 bfin;
-: 39: uint32_t out;
1: 40: char cin[] = {0x83, 0x85, 0x87, 0x89};
1: 41: bfin.inval = (struct ok){0x83, 0x85, 0x87, 0x89};
1: 42: out = partial_read_le32(bfin);
-: 43:
-: 44:
1: 45: return 0;
-: 46:}
-: 47:
-: 48:
Line 32 should be executed only once.
[Bug target/89021] Implement mmintrin.h in SSE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89021 --- Comment #59 from CVS Commits --- The master branch has been updated by Uros Bizjak : https://gcc.gnu.org/g:836328b2c99f5b8d45dcca5797f162af322e74da commit r12-1789-g836328b2c99f5b8d45dcca5797f162af322e74da Author: Uros Bizjak Date: Thu Jun 24 15:39:26 2021 +0200 i386: Add pack/unpack patterns for 64bit vectors [PR89021] 2021-06-24 Uroš Bizjak gcc/ PR target/89021 * config/i386/i386-expand.c (ix86_expand_sse_unpack): Handle V8QI and V4HI modes. * config/i386/mmx.md (sse4_1_v4qiv4hi2): New insn pattern. (sse4_1_v4qiv4hi2): Ditto. (mmxpackmode): New mode attribute. (vec_pack_trunc_): New expander. (mmxunpackmode): New mode attribute. (vec_unpacks_lo_): New expander. (vec_unpacks_hi_): Ditto. (vec_unpacku_lo_): Ditto. (vec_unpacku_hi_): Ditto. * config/i386/i386.md (extsuffix): Move from ... * config/i386/sse.md: ... here. gcc/testsuite/ PR target/89021 * gcc.dg/vect/vect-nb-iter-ub-3.c (dg-additional-options): Add --param vect-epilogues-nomask=0. * gcc.target/i386/pr97249-1.c (foo): Add #pragma GCC unroll to avoid loop vectorization. (foo1): Ditto. (foo2): Ditto.
[Bug c++/101194] New: 7.2 Regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101194
Bug ID: 101194
Summary: 7.2 Regression
Product: gcc
Version: 7.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: yannick.lepennec+gcc at live dot fr
Target Milestone: ---
Dear Maintainers,
Obligatory godbolt: https://godbolt.org/z/KnMnc7P57
Since GCC 7.2:
$ g++ -std=c++17 -Wall -Wextra -pedantic-errors
#include
struct nodefault {
nodefault(int) {}
};
int main() {
std::array arr1{ nodefault{1} }; // OK
std::array arr2{ arr1[0] }; // Error???
}
Gives:
main.cpp: In function 'int main()':
main.cpp:9:44: error: no matching function for call to 'nodefault::nodefault()'
std::array arr2{ arr1[0] }; // Error???
^
main.cpp:4:5: note: candidate: nodefault::nodefault(int)
nodefault(int) {}
^
main.cpp:4:5: note: candidate expects 1 argument, 0 provided
main.cpp:3:8: note: candidate: constexpr nodefault::nodefault(const nodefault&)
struct nodefault {
^
main.cpp:3:8: note: candidate expects 1 argument, 0 provided
main.cpp:3:8: note: candidate: constexpr nodefault::nodefault(nodefault&&)
main.cpp:3:8: note: candidate expects 1 argument, 0 provided
main.cpp:9:44: error: no matching function for call to 'nodefault::nodefault()'
std::array arr2{ arr1[0] }; // Error???
^
main.cpp:4:5: note: candidate: nodefault::nodefault(int)
nodefault(int) {}
^
main.cpp:4:5: note: candidate expects 1 argument, 0 provided
main.cpp:3:8: note: candidate: constexpr nodefault::nodefault(const nodefault&)
struct nodefault {
^
main.cpp:3:8: note: candidate expects 1 argument, 0 provided
main.cpp:3:8: note: candidate: constexpr nodefault::nodefault(nodefault&&)
main.cpp:3:8: note: candidate expects 1 argument, 0 provided
main.cpp:9:44: error: no matching function for call to 'nodefault::nodefault()'
std::array arr2{ arr1[0] }; // Error???
^
main.cpp:4:5: note: candidate: nodefault::nodefault(int)
nodefault(int) {}
^
main.cpp:4:5: note: candidate expects 1 argument, 0 provided
main.cpp:3:8: note: candidate: constexpr nodefault::nodefault(const nodefault&)
struct nodefault {
^
main.cpp:3:8: note: candidate expects 1 argument, 0 provided
main.cpp:3:8: note: candidate: constexpr nodefault::nodefault(nodefault&&)
main.cpp:3:8: note: candidate expects 1 argument, 0 provided
main.cpp:9:44: error: no matching function for call to 'nodefault::nodefault()'
std::array arr2{ arr1[0] }; // Error???
^
main.cpp:4:5: note: candidate: nodefault::nodefault(int)
nodefault(int) {}
^
main.cpp:4:5: note: candidate expects 1 argument, 0 provided
main.cpp:3:8: note: candidate: constexpr nodefault::nodefault(const nodefault&)
struct nodefault {
^
main.cpp:3:8: note: candidate expects 1 argument, 0 provided
main.cpp:3:8: note: candidate: constexpr nodefault::nodefault(nodefault&&)
main.cpp:3:8: note: candidate expects 1 argument, 0 provided
main.cpp:9:44: error: no matching function for call to 'nodefault::nodefault()'
std::array arr2{ arr1[0] }; // Error???
^
main.cpp:4:5: note: candidate: nodefault::nodefault(int)
nodefault(int) {}
^
main.cpp:4:5: note: candidate expects 1 argument, 0 provided
main.cpp:3:8: note: candidate: constexpr nodefault::nodefault(const nodefault&)
struct nodefault {
^
main.cpp:3:8: note: candidate expects 1 argument, 0 provided
main.cpp:3:8: note: candidate: constexpr nodefault::nodefault(nodefault&&)
main.cpp:3:8: note: candidate expects 1 argument, 0 provided
main.cpp:9:44: error: no matching function for call to 'nodefault::nodefault()'
std::array arr2{ arr1[0] }; // Error???
^
main.cpp:4:5: note: candidate: nodefault::nodefault(int)
nodefault(int) {}
^
main.cpp:4:5: note: candidate expects 1 argument, 0 provided
main.cpp:3:8: note: candidate: constexpr nodefault::nodefault(const nodefault&)
struct nodefault {
^
main.cpp:3:8: note: candidate expects 1 argument, 0 provided
main.cpp:3:8: note: candidate: constexpr nodefault::nodefault(nodefault&&)
main.cpp:3:8: note: candidate expects 1 argument, 0 provided
---
GCC 7.2 and above accept the same code with -std=c++14. GCC 7.1 accepts it with
either. The error message seems to have gotten shorter in more recent GCC, but
is still present. I have bisected this to
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=0634d9fe36e8ced1c6046759f9ce1d2655c8d731
[Bug c/101195] New: ICE: in tree_to_uhwi, at tree.c:6324
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101195
Bug ID: 101195
Summary: ICE: in tree_to_uhwi, at tree.c:6324
Product: gcc
Version: tree-ssa
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: cnsun at uwaterloo dot ca
Target Milestone: ---
$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/scratch/software/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /tmp/tmp.gHvB6MNy5h-gcc-builder/gcc/configure
--enable-languages=c,c++,lto --enable-checking-yes --enable-multiarch
--prefix=/scratch/software/gcc-trunk --disable-bootstrap
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20210624 (experimental) [master revision
:e518ee6cd:fcf617f0d2a5a1b624718e07d7b219cb0234436f] (GCC)
$ cat mutant.c
test_eh_return_data_regno() {
volatile res = __builtin_eh_return_data_regno(-42.);
}
$ gcc-trunk mutant.c
mutant.c:1:1: warning: return type defaults to ‘int’ [-Wimplicit-int]
1 | test_eh_return_data_regno() {
| ^
mutant.c: In function ‘test_eh_return_data_regno’:
mutant.c:2:12: warning: type defaults to ‘int’ in declaration of ‘res’
[-Wimplicit-int]
2 | volatile res = __builtin_eh_return_data_regno(-42.);
|^~~
during RTL pass: expand
mutant.c:2:18: internal compiler error: in tree_to_uhwi, at tree.c:6324
2 | volatile res = __builtin_eh_return_data_regno(-42.);
| ^~~~
0x7c7c7e tree_to_uhwi(tree_node const*)
/tmp/tmp.gHvB6MNy5h-gcc-builder/gcc/gcc/tree.c:6324
0x7c7c7e tree_to_uhwi(tree_node const*)
/tmp/tmp.gHvB6MNy5h-gcc-builder/gcc/gcc/tree.c:6322
0xb50537 expand_builtin_eh_return_data_regno(tree_node*)
/tmp/tmp.gHvB6MNy5h-gcc-builder/gcc/gcc/except.c:2170
0xa222f6 expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int)
/tmp/tmp.gHvB6MNy5h-gcc-builder/gcc/gcc/builtins.c:10409
0xb7366c expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/tmp/tmp.gHvB6MNy5h-gcc-builder/gcc/gcc/expr.c:11439
0xb7e018 store_expr(tree_node*, rtx_def*, int, bool, bool)
/tmp/tmp.gHvB6MNy5h-gcc-builder/gcc/gcc/expr.c:5994
0xb7f65f expand_assignment(tree_node*, tree_node*, bool)
/tmp/tmp.gHvB6MNy5h-gcc-builder/gcc/gcc/expr.c:5729
0xa4cb8b expand_call_stmt
/tmp/tmp.gHvB6MNy5h-gcc-builder/gcc/gcc/cfgexpand.c:2844
0xa4cb8b expand_gimple_stmt_1
/tmp/tmp.gHvB6MNy5h-gcc-builder/gcc/gcc/cfgexpand.c:3877
0xa4cb8b expand_gimple_stmt
/tmp/tmp.gHvB6MNy5h-gcc-builder/gcc/gcc/cfgexpand.c:4041
0xa528c9 expand_gimple_basic_block
/tmp/tmp.gHvB6MNy5h-gcc-builder/gcc/gcc/cfgexpand.c:6083
0xa5479f execute
/tmp/tmp.gHvB6MNy5h-gcc-builder/gcc/gcc/cfgexpand.c:6809
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.
[Bug c/101196] New: [12 Regression] ICE: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in useless_type_conversion_p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101196
Bug ID: 101196
Summary: [12 Regression] ICE: tree check: expected class
‘type’, have ‘exceptional’ (error_mark) in
useless_type_conversion_p
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: anbu1024.me at gmail dot com
Target Milestone: ---
$ cat 37.c
extern int var[16];
void foo(int [x]);
void bar(void)
{
void foo(int array[]);
}
void baz(void)
{
foo(var);
}
---
$ gcc-sp12 --version
gcc (GCC) 12.0.0 20210620 (experimental)
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
---
$ gcc-sp12 37.c
37.c:4:15: error: ‘x’ undeclared here (not in a function)
4 | void foo(int [x]);
| ^
37.c: In function ‘baz’:
37.c:13:7: error: type of formal parameter 1 is incomplete
13 | foo(var);
| ^~~
37.c:13:3: internal compiler error: tree check: expected class ‘type’, have
‘exceptional’ (error_mark) in useless_type_conversion_p, at gimple-expr.c:259
13 | foo(var);
| ^~~
0x7a313c tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
../../gcc-12-20210620/gcc/tree.c:8734
0x6d5d8a tree_class_check(tree_node*, tree_code_class, char const*, int, char
const*)
../../gcc-12-20210620/gcc/tree.h:3494
0x6d5d8a useless_type_conversion_p(tree_node*, tree_node*)
../../gcc-12-20210620/gcc/gimple-expr.c:259
0xbc1108 types_compatible_p
../../gcc-12-20210620/gcc/gimple-expr.h:67
0xbc1108 gimplify_addr_expr
../../gcc-12-20210620/gcc/gimplify.c:6234
0xbb9384 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc-12-20210620/gcc/gimplify.c:14141
0xbc4dc4 gimplify_call_expr
../../gcc-12-20210620/gcc/gimplify.c:3454
0xbbacd4 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc-12-20210620/gcc/gimplify.c:14066
0xbbc9f6 gimplify_stmt(tree_node**, gimple**)
../../gcc-12-20210620/gcc/gimplify.c:6865
0xbbd14d gimplify_bind_expr
../../gcc-12-20210620/gcc/gimplify.c:1426
0xbbacee gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc-12-20210620/gcc/gimplify.c:14295
0xbd2229 gimplify_stmt(tree_node**, gimple**)
../../gcc-12-20210620/gcc/gimplify.c:6865
0xbd2229 gimplify_body(tree_node*, bool)
../../gcc-12-20210620/gcc/gimplify.c:15339
0xbd266d gimplify_function_tree(tree_node*)
../../gcc-12-20210620/gcc/gimplify.c:15493
0xa10bf7 cgraph_node::analyze()
../../gcc-12-20210620/gcc/cgraphunit.c:670
0xa135f7 analyze_functions
../../gcc-12-20210620/gcc/cgraphunit.c:1234
0xa1428d symbol_table::finalize_compilation_unit()
../../gcc-12-20210620/gcc/cgraphunit.c:2508
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug c/101171] [12 Regression] ICE: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in c_expr_sizeof_expr, at c/c-typeck.c:3006
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101171 --- Comment #5 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:fdc5522fb04b4a820b28c4d1f16f54897f5978de commit r12-1790-gfdc5522fb04b4a820b28c4d1f16f54897f5978de Author: Jakub Jelinek Date: Thu Jun 24 15:55:28 2021 +0200 c: Fix C cast error-recovery [PR101171] The following testcase ICEs during error-recovery, as build_c_cast calls note_integer_operands on error_mark_node and that wraps it into C_MAYBE_CONST_EXPR which is unexpected and causes ICE later on. Seems most other callers of note_integer_operands check early if something is error_mark_node and return before calling note_integer_operands on it. The following patch fixes it by not calling on error_mark_node, another possibility would be to handle error_mark_node in note_integer_operands and just return it. 2021-06-24 Jakub Jelinek PR c/101171 * c-typeck.c (build_c_cast): Don't call note_integer_operands on error_mark_node. * gcc.dg/pr101171.c: New test.
[Bug c/101176] valgrind error for c-c++-common/builtin-has-attribute.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101176 --- Comment #2 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:178fb8df9315f2f8f45b7fe5faf11a9c2912cc28 commit r12-1791-g178fb8df9315f2f8f45b7fe5faf11a9c2912cc28 Author: Jakub Jelinek Date: Thu Jun 24 15:58:02 2021 +0200 c: Fix up c_parser_has_attribute_expression [PR101176] This function keeps src_range member of the result uninitialized, which at least under valgrind can show up later when those uninitialized location_t's can make it into the IL or location_t hash tables. 2021-06-24 Jakub Jelinek PR c/101176 * c-parser.c (c_parser_has_attribute_expression): Set source range for the result.
[Bug c/101171] [10/11/12 Regression] ICE: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in c_expr_sizeof_expr, at c/c-typeck.c:3006
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101171 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P4 Target Milestone|--- |10.4 Summary|[12 Regression] ICE: tree |[10/11/12 Regression] ICE: |check: expected class |tree check: expected class |‘type’, have ‘exceptional’ |‘type’, have ‘exceptional’ |(error_mark) in |(error_mark) in |c_expr_sizeof_expr, at |c_expr_sizeof_expr, at |c/c-typeck.c:3006 |c/c-typeck.c:3006 --- Comment #6 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug c/101176] valgrind error for c-c++-common/builtin-has-attribute.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101176 --- Comment #3 from Jakub Jelinek --- Fixed on the trunk so far. Guess it needs fixing in 9/10/11 too.
[Bug middle-end/101134] Bogus -Wstringop-overflow warning about non-existent overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101134 --- Comment #8 from Giuseppe D'Angelo --- In a -Wall build, it's a bit unfair to pretend the users to know if a warning is being generated by the frontend, the middleend, the backend and so on. All they get is a list of warnings saying "this is like this, this is like that". You're saying that all such warnings should be treated as "maybe", as false positives are a possibility. But I don't agree with this. First, as I said, the mood of the warning is "indicative", which denotes certainty and reality, not possibility. (But I'll grant, not being a native English speaker, this may just be a personal impression of the warning being "stern".) Second, the presence of things like -Wmaybe-uninitialized vs -Wuninitialized hints at the fact that GCC *wants* to distinguish these "maybe" vs. "certain" cases, at least in certain contexts (like, where it CAN do that!), and give different warnings if it can. Third, frontend warnings simply don't have false positives: if the compiler tells you "this function may be marked override", "this class has virtual functions but no virtual destructor", "this case label falls through into the next one", that's absolutely true in 100% of the cases. A false positive here would clearly be treated as a bug in GCC, and not dismissed as "but it's a warning, and a warning is just a 'maybe', and yes, GCC is telling you to add `override`, and then you added it, and now the program doesn't even build any more because the warning was wrong and `override` was not even needed, but see, it's your fault for not understanding the 'maybe' part". So, in a nutshell, yes, I'd be much more comfortable if warnings that denote a possibility (for any reason, really, I'm not asking to NEVER generate false positives) would simply have "may" or "might" added to their text. If that's the majority of middle-end warnings because they all generate false positives, why would that be a problem, in principle? But fair enough, let's agree to disagree. :)
[Bug c++/98832] CTAD fails for alias template of aggregate with specified undeducible template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98832 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2021-06-24 --- Comment #1 from Patrick Palka --- Confirmed. It looks like we're overlooking the aggregate deduction candidate for the underlying template when building the set of guides for the alias.
[Bug tree-optimization/101197] New: __builtin_memmove does not perform constant optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101197 Bug ID: 101197 Summary: __builtin_memmove does not perform constant optimizations Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: unlvsur at live dot com Target Milestone: --- https://godbolt.org/z/qTMEo93j1 Two code does exactly the same thing but gcc refuses to optimize this. While clang generates exactly the same output of assembly https://godbolt.org/z/7a4r1hxj7
[Bug c++/101182] [concepts] ICE with ++ in non-template requires-expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101182 --- Comment #1 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:c06493dc30afbf65b14d783c7cd53f20877ef577 commit r12-1792-gc06493dc30afbf65b14d783c7cd53f20877ef577 Author: Patrick Palka Date: Thu Jun 24 11:29:02 2021 -0400 c++: requires-expression folding [PR101182] Here we're crashing because cp_fold_function walks into the (templated) requirements of a requires-expression outside a template, but the folding routines aren't prepared to handle templated trees. This patch fixes this by making cp_fold use evaluate_requires_expr to fold a requires-expression as a whole, which also means we no longer need to explicitly do so during gimplification. (Note that we delay folding of such requires-expressions for sake of better diagnostics when one is used as the condition of a failed static_assert.) PR c++/101182 gcc/cp/ChangeLog: * constraint.cc (evaluate_requires_expr): Adjust function comment. * cp-gimplify.c (cp_genericize_r) : Move to ... (cp_fold) : ... here. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/concepts-requires25.C: New test.
[Bug tree-optimization/101145] niter analysis fails for until-wrap condition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101145
--- Comment #2 from bin cheng ---
(In reply to Richard Biener from comment #1)
> This comes up with a pending patch to split loops like
>
> void
> foo (int *a, int *b, unsigned l, unsigned n)
> {
> while (++l != n)
> a[l] = b[l] + 1;
> }
>
> into
>
> while (++l > n)
> a[l] = b[l] + 1;
> while (++l < n)
> a[l] = b[l] + 1;
>
> since for the second loop (the "usual" case involving no wrapping of the IV)
> this results in affine IVs and thus analyzable data dependence.
Special case like "i++ > constant" are handled in function
adjust_cond_for_loop_until_wrap, however, it only handles constant invariant on
the other side right now.
Will see how to cover simple cases as reported here.
[Bug middle-end/101134] Bogus -Wstringop-overflow warning about non-existent overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101134 Segher Boessenkool changed: What|Removed |Added Status|RESOLVED|REOPENED Last reconfirmed||2021-06-24 CC||segher at gcc dot gnu.org Ever confirmed|0 |1 Resolution|WONTFIX |--- --- Comment #9 from Segher Boessenkool --- (In reply to Martin Sebor from comment #7) > Changing the warning text from "does X" to "may do X" wouldn't help because > all instances of it (or all warnings) would have to use the latter form, and > that's already implied by the former. Every GCC warning already means > "something looks fishy here" and not "this is definitely a bug." Yes. And most warning texts do not say "A is B" when that is not true. All that do are buggy. Reopened.
[Bug c++/98832] CTAD fails for alias template of aggregate with specified undeducible template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98832 --- Comment #2 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:c761be53f6b62e22ac5de18c4aaf88648f64f5b7 commit r12-1793-gc761be53f6b62e22ac5de18c4aaf88648f64f5b7 Author: Patrick Palka Date: Thu Jun 24 13:11:44 2021 -0400 c++: alias CTAD and aggregate deduction cand [PR98832] During alias CTAD, we're accidentally ignoring the aggregate deduction candidate for the underlying template because this guide is added separately via maybe_aggr_guide (which doesn't yet handle alias templates) instead of via deduction_guides_for (which does). This patch makes maybe_aggr_guide handle alias templates in a manner similar to deduction_guides_for. PR c++/98832 gcc/cp/ChangeLog: * pt.c (maybe_aggr_guide): Handle alias templates appropriately. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/class-deduction-alias9.C: New test.
[Bug middle-end/101134] Bogus -Wstringop-overflow warning about non-existent overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101134 rsandifo at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot gnu.org CC||rsandifo at gcc dot gnu.org Status|REOPENED|ASSIGNED --- Comment #10 from rsandifo at gcc dot gnu.org --- I'll take this. Not really my area, it's just a bit of a pet peeve when the compiler isn't equivocal enough.
[Bug tree-optimization/101186] predictable comparison of integer variables not folded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101186
Andrew Macleod changed:
What|Removed |Added
CC||aldyh at redhat dot com,
||amacleod at redhat dot com
--- Comment #3 from Andrew Macleod ---
(In reply to Di Zhao from comment #0)
> GCC fail to remove dead codes for following cases:
>
> #include
>
> void f (unsigned int a, unsigned int b, unsigned int c)
> // if a,b,c are signed, VRP can remove dead code
> {
> if (a == b)
> {
> printf ("a");
> if (c < a)
> {
> printf ("b");
> if (c >= b)
> printf ("Unreachable!");
> }
> }
> }
>
I believe this commit fixes the first case, EVRP now eliminates the unreachable
print.
commit ce0b409f562cd09c67cc2dce74143a0f0647cde5 (origin/master, origin/HEAD)
Author: Andrew MacLeod
Date: Thu Jun 24 11:13:47 2021 -0400
Fix relation query of equivalences.
the second one requires some form of predication, or the desire to thread thru
the top of the block.. It touches on some stuff Aldy is looking at (which isn't
finished yet) .
:
if (a_7(D) != 0)
goto ; [INV]
else
goto ; [INV]
:
goto ; [INV]
:
# c_16 = PHI
:
# b_1 = PHI
if (b_1 <= 999)
goto ; [INV]
else
goto ; [INV]
:
if (a_7(D) != 0)
goto ; [INV]
else
goto ; [INV]
:
if (x_10(D) < c_16)
goto ; [INV]
else
goto ; [INV]
I dont know what rules there are, but the path 2->3->9->10->4 would result in
bb4 becoming "goto bb5", and then BB5 could fold to "goto bb8" as c_16 == x_10
on that path in BB9.
[Bug middle-end/101195] ICE: in tree_to_uhwi, at tree.c:6324
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101195 Andrew Pinski changed: What|Removed |Added Version|tree-ssa|12.0 Keywords||ice-on-valid-code Component|c |middle-end --- Comment #1 from Andrew Pinski --- Looks like there is a missing check on the argument types for this builtin.
[Bug libstdc++/101198] New: libstdc++-v3/doc/html/manual/policy_based_data_structures_test.html is not valid XHTML; fails DTD validation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101198 Bug ID: 101198 Summary: libstdc++-v3/doc/html/manual/policy_based_data_structu res_test.html is not valid XHTML; fails DTD validation Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: dmalcolm at gcc dot gnu.org Target Milestone: --- libstdc++-v3/doc/html/manual/policy_based_data_structures_test.html has this: http://www.w3.org /TR/xhtml1/DTD/xhtml1-transitional.dtd"> In particular, that DTD has: i.e. every element is required to have an alt="" attribute to be valid according to the DTD. There are numerous img elements; none of them have alt attributes. Is this file autogenerated from XML? I'm not quite sure where the issue is.
[Bug tree-optimization/101189] [12 Regression] ICE at -Os and above on x86_64-linux-gnu: in fold_cond, at vr-values.c:3471 since r12-1721-ga2c9173331914eff
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101189 --- Comment #2 from Andrew Macleod --- We always register relations on outgoing edges from a conditional. in this case _2 = -f_6; // f_6 was known to be [4,5] if (_2 == f_6) // This this was known to fail because _2 was [-5, -4] goto ; [INV] else goto ; [INV] : if (_2 != f_6) // which makes this unreachable code goto ; [INV] else goto ; [INV] THe problem is we were registering _2 == f_6 as a relation on the edge 6->8 which would then make the condition on bb_8 false. We know that _2 != f_6, so the vrp folder was saying this branch was always taken, and the relation code was prompted that its never taken :-P Its an unreachable branch, but it was adding an inconsitency. Instead, if we know an edge cannot be taken, like 6->8, do not register a relation on that edge.
[Bug gcov-profile/80223] RFE: Exclude functions from profile instrumentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80223 --- Comment #23 from Nick Desaulniers --- (In reply to Fangrui Song from comment #18) > I > think a similar topic may need to be raided on llvm-dev side as I feel this > is the tip of the iceberg - more attributes can be similarly leveraged. So, > how about a llvm-dev discussion? Sure. llvm-dev RFC: https://lists.llvm.org/pipermail/llvm-dev/2021-June/151509.html llvm patch: https://reviews.llvm.org/D104810
[Bug c++/91911] Strange interaction between CTAD and decltype
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91911
Patrick Palka changed:
What|Removed |Added
Ever confirmed|0 |1
CC||ppalka at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot
gnu.org
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2021-06-24
--- Comment #1 from Patrick Palka ---
Confirmed, this never worked. More reduced:
template
struct span {
using value_type = T;
span(T);
};
template
using SpanType = decltype(span(X()));
template
using ConstSpanType = span::value_type>;
using type = ConstSpanType;
using type = span;
[Bug c++/98077] C++ 17: Using alias template bug in gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98077 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from Patrick Palka --- This is essentially a dup of the older 91911, I think *** This bug has been marked as a duplicate of bug 91911 ***
[Bug c++/91911] Strange interaction between CTAD and decltype
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91911 Patrick Palka changed: What|Removed |Added CC||juergen.reiss at gmx dot de --- Comment #2 from Patrick Palka --- *** Bug 98077 has been marked as a duplicate of this bug. ***
[Bug c++/100723] [9/10/11/12] ICE in tsubst when using std::variant in templated class using CTAD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100723 Patrick Palka changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE CC||ppalka at gcc dot gnu.org --- Comment #3 from Patrick Palka --- This also looks like a dup of 91911 *** This bug has been marked as a duplicate of bug 91911 ***
[Bug c++/91911] Strange interaction between CTAD and decltype
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91911 Patrick Palka changed: What|Removed |Added CC||cadet.gabriel at gmail dot com --- Comment #3 from Patrick Palka --- *** Bug 100723 has been marked as a duplicate of this bug. ***
[Bug libstdc++/101198] libstdc++-v3/doc/html/manual/policy_based_data_structures_test.html is not valid XHTML; fails DTD validation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101198 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2021-06-24 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Jonathan Wakely --- Yes, it's generated by docbook from XML sources.
[Bug libstdc++/101198] libstdc++-v3/doc/html/manual/policy_based_data_structures_test.html is not valid XHTML; fails DTD validation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101198 --- Comment #2 from Jonathan Wakely --- I think this will fix it: --- a/libstdc++-v3/doc/xml/manual/test_policy_data_structures.xml +++ b/libstdc++-v3/doc/xml/manual/test_policy_data_structures.xml @@ -105,6 +105,7 @@ + Graph of results for hash text find But it's needed for every image in the doc.
[Bug middle-end/101134] Bogus -Wstringop-overflow warning about non-existent overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101134 David Malcolm changed: What|Removed |Added CC||dmalcolm at gcc dot gnu.org --- Comment #11 from David Malcolm --- FWIW the current GCC UX guidelines: https://gcc.gnu.org/onlinedocs/gccint/Guidelines-for-Diagnostics.html don't talk about a distinction between "possible" vs "definite" in the wording, but it looks to me like they ought to for cases like this ...and it may already be implied by some of the stuff like "Ideally a diagnostic should contain enough information to allow the user to make an informed choice about whether they should care (and how to fix it), but a balance must be drawn against overloading the user with irrelevant data.", in that a "possible" vs "definite" distinction doesn't add much verbiage, but is very useful in terms of clarity to the end-user, IMHO.
[Bug fortran/101199] New: program changes the value of a dummy argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101199 Bug ID: 101199 Summary: program changes the value of a dummy argument Product: gcc Version: 11.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: ygalklein at gmail dot com Target Milestone: --- I have written the following example code: ```fortran module mod_original_struct implicit none private public :: original_struct, extended_struct type original_struct private real, PUBLIC :: var1 real :: var2, var3, var4 real, dimension(3) :: vec1, vec2 contains private procedure, public :: init=>initoriginal_struct end type original_struct type, extends(original_struct) :: extended_struct private type(original_struct), dimension(2), public :: origs contains private procedure, public :: init=>initextended_struct, advance end type extended_struct contains subroutine advance(this) class(extended_struct), intent(inout) :: this print*, 'head of advance, this%var1 = ', this%var1 call this%init(vec1=this%vec1(:),& vec2=this%vec2(:),& var1=this%var1,& var2=this%var2,& var3=this%var3,& var4=this%var4,& origs=this%origs) end subroutine advance subroutine initoriginal_struct(this, vec1, vec2, var1, var2, var3, var4, origs) class(original_struct), intent(out) :: this real, dimension(3), intent(in) :: vec1, vec2 real, intent(in) :: var1, var2, var3, var4 type(original_struct), intent(in), dimension(2), optional :: origs this%vec1(:) = vec1(:) this%vec2(:) = vec2(:) this%var1 = var1 this%var2 = var2 this%var3 = var3 this%var4 = var4 if (present(origs)) error stop "initoriginal_struct was called with origs, this is strange" end subroutine initoriginal_struct subroutine initextended_struct(this, vec1, vec2, var1, var2, var3, var4, origs) class(extended_struct), intent(out) :: this real, dimension(3), intent(in) :: vec1, vec2 real, intent(in) :: var1, var2, var3, var4 type(original_struct), intent(in), dimension(2), optional :: origs print*, 'head of initextended_struct, the input argument var1 = ', var1 this%vec1(:) = vec1(:) this%vec2(:) = vec2(:) this%var1 = var1 this%var2 = var2 this%var3 = var3 this%var4 = var4 if (.not. present(origs)) error stop "initextended_struct was called without origs" this%origs(:) = origs(:) end subroutine initextended_struct end module mod_original_struct program example use mod_original_struct, only: extended_struct, original_struct implicit none type(original_struct), DIMENSION(2) :: origs type(extended_struct) :: extended1 call origs(1)%init(vec1=[0.5, 0., 0.],& vec2=[0., 0.3, 0.],& var1=3.,& var2=1.2,& var3=0.4,& var4=4.5) call origs(2)%init(vec1=[0., 0.8, 0.],& vec2=[0.2, 0., 0.],& var1=4.,& var2=1.5,& var3=0.5,& var4=6.5) call extended1%init(vec1=[0., 0., 0.7],& vec2=[0.2, 0., 0.],& var1=10.,& var2=6.,& var3=3.2,& var4=10.,& origs=origs) print*, 'bf advance, extended1%var1 = ', extended1%var1 call extended1%advance() end program example ``` when compiling with gfortran 11.1, the program compiles succesfully and the output is: head of initextended_struct, the input argument var1 =10.000 bf advance, extended1%var1 =10.000 head of advance, this%var1 =10.000 head of initextended_struct, the input argument var1 =0. One can see that the value of var1 that was sent to init of the extented struct in the routine advance has changed its value from the line bf the call to init to the head of init. This is a failure of the program. The same happens with gfortran 10.3 and also gfortran 9.3 and also gfortran 8.2 and also 7.3 and also 6.4 and also 5.4 and also 4.8.2 One should note that compiling with intel compiler 2020u4 - compiles succesfully and the output is: head of initextended_struct, the input argument var1 =10.0 bf advance, extended1%var1 =10.0 head of
[Bug tree-optimization/101189] [12 Regression] ICE at -Os and above on x86_64-linux-gnu: in fold_cond, at vr-values.c:3471 since r12-1721-ga2c9173331914eff
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101189 --- Comment #3 from CVS Commits --- The master branch has been updated by Andrew Macleod : https://gcc.gnu.org/g:a0accaa99844b0c40661202635859f8c0be76cdd commit r12-1797-ga0accaa99844b0c40661202635859f8c0be76cdd Author: Andrew MacLeod Date: Thu Jun 24 13:35:21 2021 -0400 Only register relations on live edges Register a relation on a conditional edge only if the LHS supports this edge being taken. gcc/ PR tree-optimization/101189 * gimple-range-fold.cc (fold_using_range::range_of_range_op): Pass LHS range of condition to postfold routine. (fold_using_range::postfold_gcond_edges): Only process the TRUE or FALSE edge if the LHS range supports it being taken. * gimple-range-fold.h (postfold_gcond_edges): Add range parameter. gcc/testsuite/ * gcc.dg/tree-ssa/pr101189.c: New.
[Bug tree-optimization/101189] [12 Regression] ICE at -Os and above on x86_64-linux-gnu: in fold_cond, at vr-values.c:3471 since r12-1721-ga2c9173331914eff
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101189 Andrew Macleod changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #4 from Andrew Macleod --- fixed.
[Bug tree-optimization/101200] New: Unneeded AND after shift
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101200
Bug ID: 101200
Summary: Unneeded AND after shift
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: steinar+gcc at gunderson dot no
Target Milestone: ---
The code after reduction is:
struct {
int b[6];
} c;
unsigned char d;
void e() {
unsigned char a = d >> 4, f = d & 15;
c.b[a] = c.b[f];
}
with g++-11 -O2, this produces
movzbl d(%rip), %eax
movq%rax, %rdx
shrq$4, %rax
andl$15, %edx
andl$15, %eax
movlc(,%rdx,4), %edx
movl%edx, c(,%rax,4)
ret
The second AND with 15 is unneeded and should have been optimized away by VRP
as I understand it. I can't reproduce it with ARM, though, so maybe there's
something x86-specific?
Compiler is
gcc version 11.1.0 (Debian 11.1.0-3)
The same code is generated back to at least 4.9. Also present in
gcc version 12.0.0 20210527 (experimental) [master revision
262e75d22c3:7bb6b9b2f47:9d3a953ec4d2695e9a6bfa5f22655e2aea47a973] (Debian
20210527-1)
[Bug other/101201] New: [12 regression] test case gcc.target/powerpc/pr56605.c fails on BE after r12-1202
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101201 Bug ID: 101201 Summary: [12 regression] test case gcc.target/powerpc/pr56605.c fails on BE after r12-1202 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- g:9080a3bf23297885fdc47221da37a71d6dec93c5, r12-1202 make -k check-gcc RUNTESTFLAGS="powerpc.exp=gcc.target/powerpc/pr56605.c" FAIL: gcc.target/powerpc/pr56605.c scan-rtl-dump-times combine "\\(compare:CC \\((?:and|zero_extend):DI \\(reg:[SD]I" 1 # of expected passes1 # of unexpected failures1 This only occurs on BE either power 7 or power 8. commit 9080a3bf23297885fdc47221da37a71d6dec93c5 Author: Haochen Gui Date: Fri Jun 4 14:38:53 2021 +0800 rs6000: Disable mode promotion for pseudos
[Bug rtl-optimization/101200] Unneeded AND after shift
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101200
Andrew Pinski changed:
What|Removed |Added
Component|tree-optimization |rtl-optimization
Keywords||missed-optimization
Severity|normal |enhancement
--- Comment #1 from Andrew Pinski ---
This does not make sense:
Trying 12 -> 14:
12: {r93:QI=r82:QI 0>>0x4;clobber flags:CC;}
REG_DEAD r82:QI
REG_UNUSED flags:CC
14: {r95:DI=r93:QI#0&0xf;clobber flags:CC;}
REG_UNUSED flags:CC
REG_DEAD r93:QI
Failed to match this instruction:
(parallel [
(set (reg:DI 95 [ a ])
(zero_extract:DI (subreg:HI (reg:QI 82 [ d.0_1 ]) 0)
(const_int 4 [0x4])
(const_int 4 [0x4])))
(clobber (reg:CC 17 flags))
])
How can you have a subreg of HI and then get a zero_extract of DI?
[Bug other/101201] [12 regression] test case gcc.target/powerpc/pr56605.c fails on BE after r12-1202
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101201 seurer at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from seurer at gcc dot gnu.org --- Oops, sorry, dupe of PR100952 *** This bug has been marked as a duplicate of bug 100952 ***
[Bug target/100952] [12 regression] several test case failures after r12-1202
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100952 --- Comment #5 from seurer at gcc dot gnu.org --- *** Bug 101201 has been marked as a duplicate of this bug. ***
[Bug rtl-optimization/101200] Unneeded AND after shift
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101200
--- Comment #2 from Andrew Pinski ---
Note the tree level looks decent:
a_6 = d.0_1 >> 4;
f_7 = d.0_1 & 15;
_2 = (int) f_7;
_3 = (int) a_6;
_4 = c.b[_2];
c.b[_3] = _4;
Which gets expanded (for c.b[_3] and dependents) into:
(insn 5 4 0 (set (reg:QI 82 [ d.0_1 ])
(mem/c:QI (symbol_ref:DI ("d") [flags 0x2] ) [0 d+0 S1 A8])) "t6.c":6:17 -1
(nil))
.
(insn 12 11 13 (parallel [
(set (reg:QI 93 [ a ])
(lshiftrt:QI (reg:QI 82 [ d.0_1 ])
(const_int 4 [0x4])))
(clobber (reg:CC 17 flags))
]) "t6.c":6:17 -1
(nil))
(insn 13 12 14 (set (reg:SI 94)
(zero_extend:SI (reg:QI 93 [ a ]))) "t6.c":7:6 -1
(nil))
(insn 14 13 15 (set (reg:DI 95)
(sign_extend:DI (reg:SI 94))) "t6.c":7:10 -1
(nil))
(insn 15 14 0 (set (mem:SI (plus:DI (mult:DI (reg:DI 95)
(const_int 4 [0x4]))
(reg/f:DI 92)) [1 c.b[_3]+0 S4 A32])
(reg:SI 85 [ _4 ])) "t6.c":7:10 -1
(nil))
Part of the problem is tracking of QI vs DI modes.
[Bug testsuite/101114] new test case libgomp.c/../libgomp.c-c++-common/struct-elem-5.c fails after its introduction in r12-1565
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101114 --- Comment #2 from seurer at gcc dot gnu.org --- To be complete this shows up as two failures: FAIL: libgomp.c++/../libgomp.c-c++-common/struct-elem-5.c execution test FAIL: libgomp.c/../libgomp.c-c++-common/struct-elem-5.c execution test
[Bug rtl-optimization/101200] Unneeded AND after shift
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101200 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2021-06-24 Target||x86_64-linux-gnu --- Comment #3 from Andrew Pinski --- For aarch64 we get: adrpx1, .LANCHOR0 add x0, x1, :lo12:.LANCHOR0 add x0, x0, 8 ldrbw1, [x1, #:lo12:.LANCHOR0] and x2, x1, 15 ubfxx1, x1, 4, 4 ldr w2, [x0, x2, lsl 2] str w2, [x0, x1, lsl 2] ret Note the shift and and is combined into one instruction (ubfx) but really only a shift instruction is needed. Here we have: Trying 21 -> 22: 21: r112:SI=r92:SI 0>>0x4 REG_DEAD r92:SI 22: r113:DI=sign_extend(r112:SI) REG_DEAD r112:SI Successfully matched this instruction: (set (reg:DI 113) (zero_extract:DI (subreg:DI (reg:SI 92 [ d.0_1 ]) 0) (const_int 4 [0x4]) (const_int 4 [0x4]))) The multiple modes issue is part of the problem. If I was redesigning the backends, I would only allow DI mode (and SI mode for i386) and always have the zero extends on loads.
[Bug middle-end/101134] Bogus -Wstringop-overflow warning about non-existent overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101134
--- Comment #12 from Martin Sebor ---
I don't need to be convinced that it would be nice to be able to differentiate
between certain bugs and possible ones. The text of this class of warnings
already does differentiate between "may write/read/access" and
"writing/reading/accessing" under some conditions:
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/builtins.c;h=73c12e3bb8c39907b6bd95148f860709dbbf3f50;hb=refs/heads/releases/gcc-11#l4136
This is not among them. In this case the IL that triggers the warning is:
[local count: 10145877954]:
# size_18 = PHI <512(2), size_13(10)>
# prephitmp_54 = PHI <"edFunction.staticBuf(2), newBuf_36(10)>
...
[local count: 2825037180]:
newBuf_33 = malloc (_51);
goto ; [100.00%]
[local count: 6591753510]:
newBuf_35 = realloc (_30, _51);
...
[local count: 9416790700]:
# newBuf_36 = PHI
...
[local count: 3449598541]:
MEM[(char *)prephitmp_54 + -1B] = 0; <<< -Wstring-overflow
prephitmp_54 is set to point to either the beginning of
quotedFunction.staticBuf or the dynamically allocated buffer. So prephitmp_54
- 1 is unconditionally invalid and the warning triggers. The warning doesn't
consider the predicates leading up to the invalid store: all it uses to make
its decision is the statement itself and its arguments. For PHIs, to minimize
noise, it triggers only if the statement is invalid for all arguments. This is
how most flow-based warnings work in GCC (some like -Warray-bounds don't
consider PHIs yet).
To do better and either hope to issue a "maybe" kind of a warning or preferably
avoid it altogether if the code is unreachable we would need to do what
-Wmaybe-uninitialized does (as I said in comment #5) and analyze the
predicates. I've been working on extracting the uninitialized predicate
analyzer for the last few months. I'm not sure to what extent it will be
usable outside the uninitialized pass yet or how well it will work. As we
know, -Wmaybe-uninitialized has lots of false positives (and negatives). But
even the uninitialized pass issues unconditional warnings for conditional bugs.
For instance:
int f (void)
{
int i, j = 0;
int *p = i ? &i : &j;
return *p;
}
a.c: In function ‘f’:
a.c:4:14: warning: ‘i’ is used uninitialized [-Wuninitialized]
4 | int *p = i ? &i : &j;
| ^
It does that because the first time it runs it's too early to make the
distinction, and by the second time it runs to issuse -Wmaybe-uninitialized the
uninitialized read has been eliminated. And this is done to strike a
reasonable balance between false negatives and positives.
So in general, the distinction between the two cases can only be made when it
can be discerned from the IL, and the IL doesn't always preserve the
conditional nature of the problem statement. So every warning must always be
viewed as a "maybe" kind of a warning. It will never be a sure a thing, either
at the scope of individual functions, and certainly not with inlining or
function cloning.
[Bug tree-optimization/101202] New: ICE at -O3 on x86_64-linux-gnu: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101202
Bug ID: 101202
Summary: ICE at -O3 on x86_64-linux-gnu: Segmentation fault
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: zhendong.su at inf dot ethz.ch
Target Milestone: ---
This seems to be a very recent regression.
[529] % 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/12.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 12.0.0 20210624 (experimental) [master revision
a0accaa9984:cc7f2982315:ce3316e9c02c81c509173572c71a101f4eb62a24] (GCC)
[530] %
[530] % gcctk -O2 small.c; ./a.out
[531] %
[531] % gcctk -O3 small.c
during GIMPLE pass: slp
small.c: In function ‘main’:
small.c:4:5: internal compiler error: Segmentation fault
4 | int main() {
| ^~~~
0xdb35cf crash_signal
../../gcc-trunk/gcc/toplev.c:327
0x10cf440 vect_optimize_slp(vec_info*)
../../gcc-trunk/gcc/tree-vect-slp.c:3694
0x10d7d77 vect_optimize_slp(vec_info*)
../../gcc-trunk/gcc/vec.h:1448
0x10d7d77 vect_slp_analyze_bb_1
../../gcc-trunk/gcc/tree-vect-slp.c:5608
0x10d7d77 vect_slp_region
../../gcc-trunk/gcc/tree-vect-slp.c:5695
0x10d9a0a vect_slp_bbs
../../gcc-trunk/gcc/tree-vect-slp.c:5845
0x10d9f4c vect_slp_function(function*)
../../gcc-trunk/gcc/tree-vect-slp.c:5931
0x10e12a6 execute
../../gcc-trunk/gcc/tree-vectorizer.c:1445
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.
[532] %
[532] % cat small.c
int printf(const char *, ...);
unsigned a, b, d;
int c, e, f;
int main() {
while (a)
if (b) {
f = a;
while (e) {
int h, i;
if (d) {
h = a;
i = d;
L:
d = a | d && c;
if (a) {
printf("%d", a);
goto L;
}
}
a = h;
d = i;
}
}
return 0;
}
[Bug c++/92105] [8/9/10 Regression] decltype(decltype(decltype)) prints exponential number of repeated errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92105
Jeremy R. changed:
What|Removed |Added
CC||llvm at rifkin dot dev
--- Comment #6 from Jeremy R. ---
Hey Jonathan, this is one of the most exciting bugs I've seen in gcc. This is a
little off-topic and I know the post is years old but:
Some folks and I have been doing a golf challenge to create the shortest
program which emits >1000 lines of error messages on gcc (version 8 or greater,
-fmessage-length not allowed). The previous best was a recursive template:
templateF(){F}k(){F<1>}, 43 characters, but this bug allows
us to beat that with just:
#define d decltype
d(d(d(d(d
[Bug middle-end/101134] Bogus -Wstringop-overflow warning about non-existent overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101134 --- Comment #13 from Giuseppe D'Angelo --- Hi, (In reply to Martin Sebor from comment #12) > So in general, the distinction between the two cases can only be made when > it can be discerned from the IL, and the IL doesn't always preserve the > conditional nature of the problem statement. So every warning must always > be viewed as a "maybe" kind of a warning. It will never be a sure a thing, > either at the scope of individual functions, and certainly not with inlining > or function cloning. I think there's been a misunderstanding. Apologies if I created confusion, let me try and reset the conversation: I perfectly understand if, in the context of this particular warning (or any other similar middle-end warning), it is very hard, or currently impossible, or even always impossible to distinguish between the "maybe" case and the "certain" case. Without such a distinction available or possible, I'm also OK with raising false positives. Therefore, in relation to this aspect of the original submission (the code raising a false positive warning), I'm perfectly fine at marking the request of not triggering the warning altogether as out of scope / won't fix / etc. On other hand, I was not OK with the idea that the *warning message* should keep saying that "there *is* an overflow", in a positive indicative mood. All I'd really ask there would be to reword the message in order to say something like "there *may be* an overflow" instead. It might seem like a trivial/useless change for someone who knows how the middle-end works and where such warnings come from, but it would bring a lot of clarity to end-users (to me, at least) if any warning message would clearly indicate whether it may be a false positive. And that could be achieved by simply adding "may" to the warning messages in question. Does this make sense? Thanks,
[Bug target/101185] [12 Regression] pr96814.c failed after r12-1669 on non-avx512 platform
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101185 --- Comment #14 from CVS Commits --- The master branch has been updated by hongtao Liu : https://gcc.gnu.org/g:980e278dbe5b50dc5a856ea627359c521f1cda53 commit r12-1800-g980e278dbe5b50dc5a856ea627359c521f1cda53 Author: liuhongt Date: Thu Jun 24 16:14:13 2021 +0800 Revert x86_order_regs_for_local_alloc changes in r12-1669. Still put general regs as first alloca order. gcc/ChangeLog: PR target/101185 * config/i386/i386.c (x86_order_regs_for_local_alloc): Revert r12-1669. gcc/testsuite/ChangeLog PR target/101185 * gcc.target/i386/bitwise_mask_op-3.c: Add xfail to temporarily avoid regression, eventually xfail should be removed.
[Bug tree-optimization/101145] niter analysis fails for until-wrap condition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101145 --- Comment #3 from Jiu Fu Guo --- Yes, while the code in adjust_cond_for_loop_until_wrap seems somehow tricky: /* Only support simple cases for the moment. */ if (TREE_CODE (iv0->base) != INTEGER_CST || TREE_CODE (iv1->base) != INTEGER_CST) return false; This code requires both sides are constant.
[Bug tree-optimization/101145] niter analysis fails for until-wrap condition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101145 --- Comment #4 from bin cheng --- (In reply to Jiu Fu Guo from comment #3) > Yes, while the code in adjust_cond_for_loop_until_wrap seems somehow tricky: > > /* Only support simple cases for the moment. */ > if (TREE_CODE (iv0->base) != INTEGER_CST > || TREE_CODE (iv1->base) != INTEGER_CST) > return false; > > This code requires both sides are constant. Actually it requires an IV with constant base.
[Bug fortran/101079] [OPENMP] The value of list-item in linear clause in loop construct is not calculated on each iteration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101079 --- Comment #4 from xiao@compiler-dev.com --- (In reply to Jakub Jelinek from comment #1) > Under discussions in OpenMP language committee, but the latest proposal is > that this is invalid, you need to increment the linear variable by > linear-step in the body of the construct. If that is voted into 5.2, we > won't be changing GCC for this which always assumed that is the case. Not > incrementing it in the body means that the testcase will behave > significantly differently with -fno-openmp, and also result in worse > generated code for many cases that do increment the linear variables. Hi Jakub, can you tell me where they discuss the proposal? I am very interested in the new features introduced from version 4.5, especially the implementation in the compiler.
[Bug other/91085] fixincludes breaks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91085 Xi Ruoyao changed: What|Removed |Added CC||xry111 at mengyan1223 dot wang --- Comment #13 from Xi Ruoyao --- Patch: https://gcc.gnu.org/pipermail/gcc-patches/2021-June/573676.html
[Bug libstdc++/101203] New: Remove unnecessary empty check in std::function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101203
Bug ID: 101203
Summary: Remove unnecessary empty check in std::function
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: lutztonineubert at gmail dot com
Target Milestone: ---
Hello,
this empty() check in std_function.h:
https://github.com/gcc-mirror/gcc/blob/master/libstdc++-v3/include/bits/std_function.h#L558
_Res
operator()(_ArgTypes... __args) const
{
if (_M_empty())
__throw_bad_function_call();
return _M_invoker(_M_functor, std::forward<_ArgTypes>(__args)...);
}
can, as I assume, be removed to gain better performance.
An empty, default constructed std::function could be initialized with
__throw_bad_function_call() instead with nullptr/zeros.
If std::function::operator()(...) gets called, still
__throw_bad_function_call() would get called as before.
The implementation of `explicit operator bool()` or better `_M_empty()` would
then check if the function is initialized with the address of
__throw_bad_function_call.
This would be a similar technic as used in std::any:
https://github.com/gcc-mirror/gcc/blob/master/libstdc++-v3/include/experimental/any#L436
[Bug fortran/101199] program changes the value of a dummy argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101199 --- Comment #1 from ygal klein --- The problem stays for even a smaller example program: ``` fortran module mod_original_struct implicit none private public :: extended_struct type original_struct private real, PUBLIC :: var1 contains private procedure, public :: init=>initoriginal_struct end type original_struct type, extends(original_struct) :: extended_struct private contains private procedure, public :: init=>initextended_struct, advance end type extended_struct contains subroutine advance(this) class(extended_struct), intent(inout) :: this print*, 'head of advance, this%var1 = ', this%var1 call this%init(var1=this%var1) end subroutine advance subroutine initoriginal_struct(this, var1) class(original_struct), intent(out) :: this real, intent(in) :: var1 this%var1 = var1 end subroutine initoriginal_struct subroutine initextended_struct(this, var1) class(extended_struct), intent(out) :: this real, intent(in) :: var1 print*, 'head of initextended_struct, the input argument var1 = ', var1 this%var1 = var1 end subroutine initextended_struct end module mod_original_struct program example use mod_original_struct, only: extended_struct implicit none type(extended_struct) :: extended1 call extended1%init(var1=10.) print*, 'bf advance, extended1%var1 = ', extended1%var1 call extended1%advance() end program example ``` This is the wrong output coming from all gfortran versions (4.8.2, 5.4, 6.4, 7.3, 8.2, 9.3, 10.3 and 11.1): head of initextended_struct, the input argument var1 =10.000 bf advance, extended1%var1 =10.000 head of advance, this%var1 =10.000 head of initextended_struct, the input argument var1 =0. the dummy argument var1 changed its value at entrance to init from advance. using intel 2020u4 provides the right output. as presented in the first comment: The problem
[Bug fortran/101199] program changes the value of a dummy argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101199 --- Comment #2 from ygal klein --- The problem also persists in an example code that is with no extended type: ```fortran module mod_original_struct implicit none private public :: original_struct type original_struct private real, PUBLIC :: var1 contains private procedure, public :: init=>initoriginal_struct, advance end type original_struct contains subroutine advance(this) class(original_struct), intent(inout) :: this print*, 'head of advance, this%var1 = ', this%var1 call this%init(var1=this%var1) end subroutine advance subroutine initoriginal_struct(this, var1) class(original_struct), intent(out) :: this real, intent(in) :: var1 print*, 'head of initoriginal_struct, the input argument var1 = ', var1 this%var1 = var1 end subroutine initoriginal_struct end module mod_original_struct program example use mod_original_struct, only: original_struct implicit none type(original_struct) :: struct1 call struct1%init(var1=10.) print*, 'bf advance, struct1%var1 = ', struct1%var1 call struct1%advance() end program example ``` The gfortran wrong output is: head of initoriginal_struct, the input argument var1 =10.000 bf advance, struct1%var1 =10.000 head of advance, this%var1 =10.000 head of initoriginal_struct, the input argument var1 =0. using intel 2020u4 provides the right output.
[Bug target/100952] [12 regression] several test case failures after r12-1202
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100952 --- Comment #6 from HaoChen Gui --- Seurer, Could you provide detail info about test? Such as config and build option. I tested the build on P10 and no failure on parity_1.f90. Thanks. PASS: gfortran.dg/parity_1.f90 -O0 (test for excess errors)
[Bug target/100952] [12 regression] several test case failures after r12-1202
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100952 --- Comment #7 from HaoChen Gui --- PASS: gfortran.dg/parity_1.f90 -O0 execution test
[Bug libstdc++/101194] [9/10/11/12 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101194 Richard Biener changed: What|Removed |Added Component|c++ |libstdc++ Target Milestone|--- |9.5 Keywords||rejects-valid Summary|7.2 Regression |[9/10/11/12 Regression]
[Bug middle-end/101195] ICE: in tree_to_uhwi, at tree.c:6324
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101195
Richard Biener changed:
What|Removed |Added
Keywords||accepts-invalid
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Last reconfirmed||2021-06-25
--- Comment #2 from Richard Biener ---
DEF_GCC_BUILTIN(BUILT_IN_EH_RETURN_DATA_REGNO, "eh_return_data_regno",
BT_FN_INT_INT, ATTR_LEAF_LIST)
so -42 is perfectly fine, but
2165{
2166 error ("argument of %<__builtin_eh_return_regno%> must be
constant");
2167 return constm1_rtx;
2168}
2169
2170 iwhich = tree_to_uhwi (which);
we then don't check the argument range before accessing it as unsigned.
[Bug middle-end/101197] __builtin_memmove does not perform constant optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101197
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Keywords||missed-optimization
Status|UNCONFIRMED |NEW
Last reconfirmed||2021-06-25
Component|tree-optimization |middle-end
--- Comment #1 from Richard Biener ---
void foo (char *a, char *b)
{
__builtin_memmove (a, b, 32);
}
is not expanded inline (not even with-minline-all-stringops).
[Bug tree-optimization/101202] ICE at -O3 on x86_64-linux-gnu: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101202 Richard Biener changed: What|Removed |Added Last reconfirmed||2021-06-25 Version|unknown |12.0 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #1 from Richard Biener --- Mine.
[Bug libstdc++/101203] Remove unnecessary empty check in std::function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101203 --- Comment #1 from Jonathan Wakely --- PR 56551 uses a similar idea. It wouldn't be ABI compatible with existing code though.
[Bug tree-optimization/101190] vectorizer failed to generate vashlv8hi, but extend to int and use vashlv4si instead
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101190
--- Comment #2 from Hongtao.liu ---
(In reply to Richard Biener from comment #1)
> the issue is that likely (is that prerequesite patch in yet?)
> vect_recog_over_widening_pattern is not detecting that the shift could be
> done in smaller than int precision. C promotion rules gives us
>
> _4 = *_3;
> _5 = (int) _4;
> _7 = *_6;
> _8 = (int) _7;
> _9 = _5 << _8;
> _10 = (short unsigned int) _9;
> *_3 = _10;
>
> where promotion of the shift amount is a GCC choice. The first reason is
> that we hit
>
> /* See whether we have found that this operation can be done on a
> narrower type without changing its semantics. */
> unsigned int new_precision = last_stmt_info->operation_precision;
> if (!new_precision)
> return NULL;
>
> which is because the analysis code seems to bail for non-constant shift
> amounts with the fear to introduce shifts that are undefined (out-of-bounds).
It make sense for a variable shift count which we don't know its range.
But the below testcase should generate vpsllvw just like icx did.
https://godbolt.org/z/h9PWfbP7K
void
foo (unsigned short* __restrict pdst, unsigned short* psrc)
{
for (int i = 0; i != 8; i++)
pdst[i] <<= (psrc[i] % 16);
}
