[Bug c++/106689] gcc crash while compiling a generic lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106689 --- Comment #6 from Janez Zemva --- I have since changed the repo. You can still demonstrate the bug by uncommenting the line: //[&a, &r, &s]() noexcept -> bool // uncomment for bug
[Bug debug/106263] BTF_KIND_FUNC type does not encode linkage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106263 --- Comment #2 from James Hilliard --- Should this be backported to the gcc 12 branch?
[Bug fortran/106684] inconsistent array initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106684 --- Comment #7 from Jorn Bruggeman --- None from me; thanks for the explanation!
[Bug c/106694] New: Redundant move instructions in ARM SVE intrinsics use cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106694
Bug ID: 106694
Summary: Redundant move instructions in ARM SVE intrinsics use
cases
Product: gcc
Version: rust/master
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: juzhe.zhong at rivai dot ai
Target Milestone: ---
Here is the example: https://godbolt.org/z/4zPK7j8vT
The codes:
#include "arm_sve.h"
int coalesce (svbool_t pg, int64_t* base, int n, int32_t *in1, int64_t *in2,
int64_t*out)
{
svint64x4_t result = svld4_s64 (pg, base);
svint64_t v0 = svget4_s64(result, 0);
svint64_t v1 = svget4_s64(result, 1);
svint64_t v2 = svget4_s64(result, 2);
svint64_t v3 = svget4_s64(result, 3);
for (int i = 0; i < n; i += 1)
{
svint64_t v18 = svld1_s64(pg, in1);
svint64_t v19 = svld1_s64(pg, in2);
v0 = svmad_s64_z(pg, v0, v18, v19);
v1 = svmad_s64_z(pg, v1, v18, v19);
v2 = svmad_s64_z(pg, v2, v18, v19);
v3 = svmad_s64_z(pg, v3, v18, v19);
}
svst1_s64(pg, out+0,v0);
svst1_s64(pg, out+1,v1);
svst1_s64(pg, out+2,v2);
svst1_s64(pg, out+3,v3);
}
Assembly:
coalesce:
ld4d{z24.d - z27.d}, p0/z, [x0]
mov z5.d, z24.d
mov z4.d, z25.d
mov z3.d, z26.d
mov z2.d, z27.d
cmp w1, 0
ble .L2
mov w0, 0
ld1dz1.d, p0/z, [x2]
ld1dz0.d, p0/z, [x3]
.L3:
add w0, w0, 1
movprfx z5.d, p0/z, z5.d
mad z5.d, p0/m, z1.d, z0.d
movprfx z4.d, p0/z, z4.d
mad z4.d, p0/m, z1.d, z0.d
movprfx z3.d, p0/z, z3.d
mad z3.d, p0/m, z1.d, z0.d
movprfx z2.d, p0/z, z2.d
mad z2.d, p0/m, z1.d, z0.d
cmp w1, w0
bne .L3
.L2:
add x3, x4, 8
add x2, x4, 16
add x1, x4, 24
st1dz5.d, p0, [x4]
st1dz4.d, p0, [x3]
st1dz3.d, p0, [x2]
st1dz2.d, p0, [x1]
ret
The "mov" instructions are redundant. I think the issue is that GCC doesn't
have the register coalescing like LLVM.
The subreg can not propagate accorss basic blocks.
Can someone implement register coalesing or subreg forwarding across basic
blocks?
Thanks.
[Bug target/106691] Section anchors is not efficient for riscv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106691 --- Comment #4 from Andrew Pinski --- (In reply to Andrew Waterman from comment #3) > Relaxation to gp happens at link time Doing any kind of relaxation like this is REALLY REALLY BAD at link time. Sorry but the whole relaxation in the RISCV linker needs to be thrown away ...
[Bug target/106691] Section anchors is not efficient for riscv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106691 --- Comment #3 from Andrew Waterman --- Relaxation to gp happens at link time, and because of the relatively small load/store offsets, the small-data limit is actually useful. I don't think we should turn it off, because when we relax to gp, we get lower instruction count than we'd get with anchors. (But it's obviously a gamble, since we aren't guaranteed to get relaxation, depending on the section size.) I do see that for -fPIC (where gp relaxation isn't enabled) and for large objects, anchors seem to be working.
[Bug middle-end/106692] [10/11/12/13 Regression] Cray pointer comparison wrongly optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106692
--- Comment #2 from Andrew Pinski ---
(In reply to Marek Polacek from comment #1)
> Started with r238754 but removing that match.pd doesn't help, so the problem
> is elsewhere.
>
> We optimize away zz1_1(D) != 0:
>
> __attribute__((fn spec (". w ")))
> void shape_cray (real(kind=4) & restrict zz1)
> {
>integer(kind=8) ptrzz;
> - integer(kind=8) _2;
> + integer(kind=8) _3;
>
> :
> - _2 = (integer(kind=8)) zz1_1(D);
> - if (zz1_1(D) != 0)
> -goto ; [INV]
> - else
> -goto ; [INV]
> -
> - :
> + _3 = (integer(kind=8)) zz1_1(D);
>_gfortran_abort ();
I suspect there was a patch which special case references to say they cannot be
null in the middle-end.
[Bug target/106691] Section anchors is not efficient for riscv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106691 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Summary|Section anchors is not |Section anchors is not |implemented for riscv |efficient for riscv Last reconfirmed||2022-08-19 Ever confirmed|0 |1 --- Comment #2 from Andrew Pinski --- Oh it is because -msmall-data-limit defaults to 8. And default_use_anchors_for_symbol_p returns false for small data sections: /* Don't use anchors for small data sections. The small data register acts as an anchor for such sections. */ if (sect->common.flags & SECTION_SMALL) return false; But there is no small data register ...
[Bug middle-end/106692] [10/11/12/13 Regression] Cray pointer comparison wrongly optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106692
--- Comment #1 from Marek Polacek ---
Started with r238754 but removing that match.pd doesn't help, so the problem is
elsewhere.
We optimize away zz1_1(D) != 0:
__attribute__((fn spec (". w ")))
void shape_cray (real(kind=4) & restrict zz1)
{
integer(kind=8) ptrzz;
- integer(kind=8) _2;
+ integer(kind=8) _3;
:
- _2 = (integer(kind=8)) zz1_1(D);
- if (zz1_1(D) != 0)
-goto ; [INV]
- else
-goto ; [INV]
-
- :
+ _3 = (integer(kind=8)) zz1_1(D);
_gfortran_abort ();
- :
- return;
-
}
[Bug target/106691] Section anchors is not implemented for riscv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106691 Andrew Waterman changed: What|Removed |Added CC||andrew at sifive dot com --- Comment #1 from Andrew Waterman --- Oddly enough, I remember that section anchors used to work for RISC-V, and I see TARGET_MIN_ANCHOR_OFFSET and TARGET_MAX_ANCHOR_OFFSET are still defined.
[Bug ada/106693] New: gnat: poisoned calloc in gcc/ada/adaint.[hc] due to use of sched.h on musl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106693 Bug ID: 106693 Summary: gnat: poisoned calloc in gcc/ada/adaint.[hc] due to use of sched.h on musl Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: andrewathalye at outlook dot com Target Milestone: --- On musl libc, sched.h makes use of calloc in a definition, which triggers GCC's #pragma GNU poision from system.h. adaint.h and adaint.c cause this problem to occur while building a native compiler, since they both conditionally include sched.h. Alpine Linux bypasses this by dropping the include and using void* instead of cpu_set_t*. It could also be resolved the same way as the earlier bug 106102, for example by creating a define USE_SCHED_H and implementing it before calloc is poisoned.
[Bug middle-end/106692] New: [10/11/12/13 Regression] Cray pointer comparison wrongly optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106692 Bug ID: 106692 Summary: [10/11/12/13 Regression] Cray pointer comparison wrongly optimized away Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: mpolacek at gcc dot gnu.org Target Milestone: --- The following program crashes with -O but not -O0: $ ./f951 -quiet -frecursive -fPIC -ffixed-line-length-132 -fautomatic -fcray-pointer -O x.f; gfortran x.s; ./a.out Program aborted. Backtrace: #0 0x7fa618e23a12 in ??? #1 0x7fa618e2444d in ??? #2 0x7fa619078d0c in ??? #3 0x401153 in ??? #4 0x401161 in ??? #5 0x401192 in ??? #6 0x7fa618a2954f in __libc_start_call_main at ../sysdeps/nptl/libc_start_call_main.h:58 #7 0x7fa618a29608 in __libc_start_main_impl at ../csu/libc-start.c:389 #8 0x401084 in ??? #9 0x in ??? Aborted (core dumped) $ cat x.f program test k=1 call test_cray(k) end subroutine test_cray(k) pointer(ptrzz1 , zz1) ptrzz1=0 if (ptrzz1 .ne. 0) then call abort() else call shape_cray(zz1) end if end subroutine shape_cray(zz1) pointer(ptrzz , zz) ptrzz=loc(zz1) if (ptrzz .ne. 0) then call abort() end if end
[Bug c++/106689] gcc crash while compiling a generic lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106689 --- Comment #5 from Janez Zemva --- The workaround is very simple, just put "[&]() noexcept -> bool" into sq2.hpp.
[Bug c++/106689] gcc crash while compiling a generic lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106689 Andrew Pinski changed: What|Removed |Added Status|WAITING |UNCONFIRMED Ever confirmed|1 |0
[Bug target/106691] New: Section anchors is not implemented for riscv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106691
Bug ID: 106691
Summary: Section anchors is not implemented for riscv
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
Target: riscv
Take:
static int a, b;
int f(void)
{
return a+b;
}
void g(int c, int d)
{
a = c;
b = d;
}
--- CUT ---
Right now riscv32-linux-gnu produces:
f:
lui a5,%hi(a)
lw a0,%lo(a)(a5)
lui a5,%hi(b)
lw a5,%lo(b)(a5)
add a0,a0,a5
ret
g:
lui a5,%hi(a)
sw a0,%lo(a)(a5)
lui a5,%hi(b)
sw a1,%lo(b)(a5)
ret
While aarch64 produces:
f:
adrpx0, .LANCHOR0
add x2, x0, :lo12:.LANCHOR0
ldr w1, [x0, #:lo12:.LANCHOR0]
ldr w0, [x2, 4]
add w0, w1, w0
ret
g:
adrpx2, .LANCHOR0
add x3, x2, :lo12:.LANCHOR0
str w0, [x2, #:lo12:.LANCHOR0]
str w1, [x3, 4]
ret
One less instruction.
[Bug c++/106689] gcc crash while compiling a generic lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106689 --- Comment #4 from Janez Zemva --- Created attachment 53482 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53482&action=edit preprocessed source
[Bug tree-optimization/106247] GCC12 warning in Eigen: array subscript is partly outside array bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106247
Marc Glisse changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #6 from Marc Glisse ---
(In reply to Andrew Pinski from comment #2)
> the warning is correct in the sense the load is there in IR, though it looks
> like it is dead (but only because b and a are unused):
#include
Eigen::Array a;
Eigen::Array b;
void f(){
b.col(0).tail(2) = a.col(1);
}
still warns about some 256 bit code which is still very dead (we later optimize
the whole function to just
_64 = MEM [(char * {ref-all})&a + 16B];
MEM [(char * {ref-all})&b + 8B] = _64;
)
so the fact that a and b are unused in the original testcase is not important.
I assume there were good reasons to put the warning this early (VRP1), but it
means that some dead code that will be removed later is still around.
(@Daniel: it can be easier to track things with separate issues, if you have a
different testcase to provide)
[Bug c++/106689] gcc crash while compiling a generic lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106689 --- Comment #3 from Janez Zemva --- BTW: I already tried to make a minimal test case, but failed, all compiled fine. Maybe tomorrow.
[Bug c++/106689] gcc crash while compiling a generic lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106689 --- Comment #2 from Janez Zemva --- Sorry, I can't, because I already changed the code a little and I'm keeping the repo such as it is so as to not invalidate this bug report. Why not clone the repo and do what you need to do? I'm keeping it in exact state of my bug report.
[Bug c++/106689] gcc crash while compiling a generic lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106689 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2022-08-19 Ever confirmed|0 |1 Status|UNCONFIRMED |WAITING --- Comment #1 from Andrew Pinski --- Can you attach the preprocessed source which should be easy to get with -freport-bug ? You can compress it if you need to.
[Bug testsuite/106690] check_effective_target_bswap should be enabled for riscv if ZBB ISA extension is enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106690 --- Comment #2 from Andrew Pinski --- Created attachment 53481 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53481&action=edit patch under testing
[Bug testsuite/106690] check_effective_target_bswap should be enabled for riscv if ZBB ISA extension is enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106690 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2022-08-19 Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- The easiest way is to check if __riscv_zbb > 0. Mine.
[Bug testsuite/106690] New: check_effective_target_bswap should be enabled for riscv if ZBB ISA extension is enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106690 Bug ID: 106690 Summary: check_effective_target_bswap should be enabled for riscv if ZBB ISA extension is enabled Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: pinskia at gcc dot gnu.org Target Milestone: --- While looking into __builtin_bswap testcases to quickly run before doing a fun test run, I Noticed check_effective_target_bswap does not see if ZBB is enabled for RISCV.
[Bug c++/106689] New: gcc crash while compiling a generic lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106689
Bug ID: 106689
Summary: gcc crash while compiling a generic lambda
Product: gcc
Version: 12.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: janezz55 at gmail dot com
Target Milestone: ---
Reproducing the crash is easy, clone my repository:
https://github.com/user1095108/sq2
then compile:
g++ -std=c++20 -Ofast sq2.cpp -s -o sq2 -lsqlite3
In file included from sq2.cpp:5:
sq2.hpp: In instantiation of 'sq2::bind<>(std::unique_ptr&, double&&, int&&) requires bool(sizeof ...
((sq2::bind::a ...)))::)> [with auto ...J =
{0, 1}; std::index_sequence = std::integer_sequence]':
sq2.hpp:172:6: required from 'auto sq2::bind(auto:26&&, auto:27&& ...)
requires bool(sizeof ... ((sq2::bind::a ...))) [with int I = 1; auto:26 =
std::unique_ptr&; auto:27 =
{double, int}]'
sq2.cpp:62:14: required from here
sq2.hpp:108:11: internal compiler error: trying to capture 'a#0' in
instantiation of generic lambda
108 | [&a, &r, s(detail::get(stmt))]() noexcept -> bool
| ^
0x19ea8d8 internal_error(char const*, ...)
???:0
0x71c477 add_capture(tree_node*, tree_node*, tree_node*, bool, bool)
???:0
0x71c4e3 add_default_capture(tree_node*, tree_node*, tree_node*)
???:0
0x7e224a tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
???:0
0x7e0aca tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
???:0
0x7f7957 tsubst_lambda_expr(tree_node*, tree_node*, int, tree_node*)
???:0
0x7e205f tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
???:0
0x7e05c7 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
???:0
0x7e8cac tsubst_pack_expansion(tree_node*, tree_node*, int, tree_node*)
???:0
0x7dfea9 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
???:0
0x7daf63 instantiate_decl(tree_node*, bool, bool)
???:0
0x6edadb mark_used(tree_node*, int)
???:0
0x68b81f build_op_call(tree_node*, vec**, int)
???:0
0x810e4d finish_call_expr(tree_node*, vec**, bool,
bool, int)
???:0
0x7e1e2c tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
???:0
0x7daf63 instantiate_decl(tree_node*, bool, bool)
???:0
0x6edadb mark_used(tree_node*, int)
???:0
0x68ad5b build_new_function_call(tree_node*, vec**, int)
???:0
0x810680 finish_call_expr(tree_node*, vec**, bool,
bool, int)
???:0
0x7c79bc c_parse_file()
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug target/99089] unnecessary zero extend before AND
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99089 --- Comment #3 from Andrew Pinski --- The zero extend is gone on the trunk ...
[Bug middle-end/106688] out of ssa Coalescing sometimes chooses the wrong thing causing an extra move
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106688 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=86270, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=70359 --- Comment #7 from Andrew Pinski --- I Knew there was an older bug about a similar thing. See PR 86270 and PR 70359.
[Bug middle-end/106688] out of ssa Coalescing sometimes chooses the wrong thing causing an extra move
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106688 --- Comment #6 from Andrew Pinski --- -fno-tree-coalesce-vars also fixes the issue.
[Bug middle-end/106688] out of ssa Coalescing sometimes chooses the wrong thing causing an extra move
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106688 Andrew Pinski changed: What|Removed |Added Summary|leaving SSA emits |out of ssa Coalescing |assignment into the inner |sometimes chooses the wrong |loop|thing causing an extra move --- Comment #5 from Andrew Pinski --- (In reply to Andrew Pinski from comment #4) > Oh yes out of ssa used the wrong coalescing: > Coalesce list: (24)buf_24 & (33)_33 [map: 9, 16] : Success -> 9 > > Just by accident. The reason why nothing in the RTL can clean it up is because the psedu-register is used inside the loop and outside of the loop.
[Bug middle-end/106688] leaving SSA emits assignment into the inner loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106688 Andrew Pinski changed: What|Removed |Added Component|rtl-optimization|middle-end --- Comment #4 from Andrew Pinski --- Oh yes out of ssa used the wrong coalescing: Coalesce list: (24)buf_24 & (33)_33 [map: 9, 16] : Success -> 9 Just by accident.
[Bug rtl-optimization/106688] leaving SSA emits assignment into the inner loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106688 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Keywords||ra Severity|normal |enhancement Component|tree-optimization |rtl-optimization Last reconfirmed||2022-08-19 Ever confirmed|0 |1 --- Comment #3 from Andrew Pinski --- With --param lim-expensive=0, the cast was pulled out of the loop and the move is gone too. But then again the register move should have been removed during register allocation ...
[Bug tree-optimization/106688] leaving SSA emits assignment into the inner loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106688 Andrew Pinski changed: What|Removed |Added Component|middle-end |tree-optimization --- Comment #2 from Andrew Pinski --- _33 = (const unsigned char *) ivtmp.18_7; invariant up to level 2, cost 1.
[Bug middle-end/106688] leaving SSA emits assignment into the inner loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106688
--- Comment #1 from Andrew Pinski ---
(In reply to Alexander Monakov from comment #0)
> It looks as if going out of SSA places in the loop a register copy
> corresponding to a phi node which is outside of the loop. Strangely, RTL
> optimizations do not clean it up either.
No it is IVOPTs that places the copy inside the loop:
[local count: 1006632961]:
# buf_25 = PHI
# vs1_28 = PHI
__asm__("pmovzxbw %1, %0" : "=x" b_17 : "m" MEM[(i8v8 *)buf_25]);
vs1_18 = b_17 + vs1_28;
_15 = (unsigned long) buf_25;
_14 = _15 + 8;
_2 = (const unsigned char *) _14;
__asm__("pmovzxbw %1, %0" : "=x" b_19 : "m" MEM[(i8v8 *)_2]);
vs1_20 = vs1_18 + b_19;
buf_21 = buf_25 + 16;
_33 = (const unsigned char *) ivtmp.18_7;
if (buf_21 != _33)
goto ; [93.75%]
else
goto ; [6.25%]
Notice the cast is of ivtmp.18_7 assigned to _33 here. The cast is an
invariant.
I don't know why LIM4 didn't pull out the invariant.
[Bug fortran/106684] inconsistent array initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106684
--- Comment #6 from Steve Kargl ---
On Fri, Aug 19, 2022 at 07:16:21PM +, j...@bolding-bruggeman.com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106684
>
> --- Comment #5 from Jorn Bruggeman ---
> Thanks; it does look like older gfortran versions (and ifort) are too
> forgiving
> here, and that, given the F2018 definition of "conformable", the latest
> gfortran releases are correct.
>
> As for "stand-alone" variables, I just means regular variables (i.e., not a
> component of a derived type). What surprised me is that this still compiles
> fine in latest gfortran versions:
>
> program p
>implicit none
>
>real :: a(2,2)
>data a /0., 1., 2., 3./
> end program
>
> with the data assigned to "a" seemingly being of rank 1. However, this seems
> to
> work because the rules governing "data" statements for arrays explicitly
> describe the target elements ("a") being unpacked in array order, and the
> total
> number of values having to match.
>
> Conversely, this is [correctly] rejected by the latest gfortran versions:
>
> program p
>implicit none
>
>real :: a(2,2) = (/0., 1., 2., 3./)
> end program
>
> All in all, I accept this change in 10.4 and 11.3 was not a bug but an
> improvement. It unfortunately does mean that the code (not my own, but one I
> depend on) will need changes in >100 places...
>
I see. I suspect we're seeing mixing of old FORTRAN 77
and the new fangle Fortran. DATA statements go back to
at leaset F77 (if not F66, to lazy to check).
F2018: 8.6.7 DATA statement
The data-stmt-object-list is expanded to form a sequence of
pointers and scalar variables, referred to as "sequence of
variables" in subsequent text. A nonpointer array whose
unqualified name appears as a data-stmt-object or data-i-do-object
is equivalent to a complete sequence of its array elements in
array element order (9.5.3.2).
If there's no onjection I'll close this with INVALID.
[Bug middle-end/106688] New: leaving SSA emits assignment into the inner loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106688
Bug ID: 106688
Summary: leaving SSA emits assignment into the inner loop
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
Target Milestone: ---
For the following testcase, gcc -O2
unsigned foo(const unsigned char *buf, long size);
unsigned bar(const unsigned char *buf, long size)
{
typedef char i8v8 __attribute__((vector_size(8)));
typedef short i16v8 __attribute__((vector_size(16)));
long chunk_sz = 15*16;
for (; size >= chunk_sz; size -= chunk_sz) {
i16v8 vs1 = { 0 };
const unsigned char *end = buf + chunk_sz;
for (; buf != end; buf += 16) {
i16v8 b;
asm("pmovzxbw %1, %0" : "=x"(b) : "m"(*(i8v8*)buf));
vs1 += b;
asm("pmovzxbw %1, %0" : "=x"(b) :
"m"(*(i8v8*)(buf+8)));
vs1 += b;
}
asm("" :: "x"(vs1));
}
return foo(buf, size);
}
(asms needed due to PR 31667)
generates
bar:
cmp rsi, 239
jle .L2
lea rdx, [rdi+240]
.L4:
lea rax, [rdx-240]
pxorxmm0, xmm0
.L3:
pmovzxbw QWORD PTR [rax], xmm1
add rax, 16
paddw xmm0, xmm1
mov rdi, rdx ; <<< ehhh
pmovzxbw QWORD PTR [rax-8], xmm1
paddw xmm0, xmm1
cmp rax, rdx
jne .L3
sub rsi, 240
add rdx, 240
cmp rsi, 239
jg .L4
.L2:
jmp foo
It looks as if going out of SSA places in the loop a register copy
corresponding to a phi node which is outside of the loop. Strangely, RTL
optimizations do not clean it up either.
[Bug fortran/106684] inconsistent array initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106684
--- Comment #5 from Jorn Bruggeman ---
Thanks; it does look like older gfortran versions (and ifort) are too forgiving
here, and that, given the F2018 definition of "conformable", the latest
gfortran releases are correct.
As for "stand-alone" variables, I just means regular variables (i.e., not a
component of a derived type). What surprised me is that this still compiles
fine in latest gfortran versions:
program p
implicit none
real :: a(2,2)
data a /0., 1., 2., 3./
end program
with the data assigned to "a" seemingly being of rank 1. However, this seems to
work because the rules governing "data" statements for arrays explicitly
describe the target elements ("a") being unpacked in array order, and the total
number of values having to match.
Conversely, this is [correctly] rejected by the latest gfortran versions:
program p
implicit none
real :: a(2,2) = (/0., 1., 2., 3./)
end program
All in all, I accept this change in 10.4 and 11.3 was not a bug but an
improvement. It unfortunately does mean that the code (not my own, but one I
depend on) will need changes in >100 places...
[Bug target/106101] [12/13 Regression] ICE in reg_bitfield_target_p since r12-4428-g147ed0184f403b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106101
--- Comment #13 from Segher Boessenkool ---
(Sorry I missed this)
(In reply to Andreas Krebbel from comment #11)
> I've tried to change our movstrict backend patterns to use a predicate on
> the dest operand which enforces a subreg. However, since reload strips the
> subreg away when assigning hard regs we end up with a STRICT_LOW_PART of a
> reg again. At least after reload something like this should be acceptable -
> right?
>
> 298r.ira:
> (insn 8 16 17 3 (set (strict_low_part (subreg:SI (reg/v:DI 64 [ e ]) 4))
> (const_int 0 [0])) "t.cc":37:17 1485 {movstrictsi}
> (nil))
>
> 299r.reload:
> (insn 8 16 17 3 (set (strict_low_part (reg:SI 11 %r11 [orig:64 e+4 ] [64]))
> (mem/u/c:SI (symbol_ref/u:DI ("*.LC0") [flags 0x2]) [0 S4 A32]))
> "t.cc":37:17 1485 {movstrictsi}
> (nil))
So you are suggesting that every strict_low_part after reload can just be
removed? If that is true, should we not just do exactly that then?
[Bug fortran/106684] inconsistent array initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106684 --- Comment #4 from Steve Kargl --- On Fri, Aug 19, 2022 at 06:01:46PM +, j...@bolding-bruggeman.com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106684 > > --- Comment #2 from Jorn Bruggeman --- > > Are you effectively saying that 10.3 and 11.2 (as well as all ifort versions I > am aware of) are too forgiving in both cases (accepting data of different rank > as long at the totals number of elements is the same), while 10.4 and 11.3 are > still too forgiving when it comes to stand-alone array variables? > What I am saying is that the code is nonconforming. Intel and older versions of gfortran do not detect or report the nonconformance. Newer versions of gfortran have grown an ability to detect the shape mismatch in your code and so reported an error. ifort might flag an issue if you give it the right option to request strict standard conformance. I don't know want you mean be stand-alone variable. The program I posted shows the non-conformance due to different shapes.
[Bug fortran/106684] inconsistent array initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106684 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org --- Comment #3 from anlauf at gcc dot gnu.org --- Many other compilers give similar error messages as gfortran. Crayftn: data c /t(1, (/0., 1., 2., 3./))/ ^ ftn-360 crayftn: ERROR P, File = pr106684.f90, Line = 12, Column = 17 The rank of derived type constructor component number 2 does not match the declared rank. Cray Fortran : Version 14.0.0 (20220420160222_c98838affc7b58fed2a72f164d77c35e1bc8772f) Cray Fortran : Compile time: 0.0412 seconds Cray Fortran : 14 source lines Cray Fortran : 1 errors, 0 warnings, 0 other messages, 0 ansi Cray Fortran : "explain ftn-message number" gives more information about each message. NAG: NAG Fortran Compiler Release 7.0(Yurakucho) Build 7009 Warning: pr106684.f90, line 13: Local variable A is initialised but never used Warning: pr106684.f90, line 13: Local variable C is initialised but never used Error: pr106684.f90, line 12: Rank 1 value for rank 2 array A Errors in declarations, no further processing for P [NAG Fortran Compiler error termination, 1 error, 2 warnings] Oracle/Sunstudio: data c /t(1, (/0., 1., 2., 3./))/ ^ "pr106684.f90", Line = 12, Column = 17: ERROR: The rank of derived type constructor component "A" does not match the declared rank. Nvidia gives a warning, but otherwise swallows the code. As there is pretty good agreement here, and if you likely want portable code, I'd recommend to adjust your code as Steve suggested. Don't rely only on Intel.
[Bug fortran/106684] inconsistent array initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106684 --- Comment #2 from Jorn Bruggeman --- I interpret the quoted F2018, 7.5.10 as "the same rules should govern initialization of components of derived types and initialization of stand-alone variables". That was previously (in 10.3, 11.2, and other compilers such as ifort) the case: multidimensional arrays could be initialized with 1d data, whether they were stand-alone variables or components of a derived type (note that it was not just accepted by the compiler - it worked fine too). Now, in 10.4 and 11.3, that is no longer the case: the requirements on initialization of type components have become more stringent as they demand the expression to have the same rank. Assignments to stand-alone variables can still have different rank. Are you effectively saying that 10.3 and 11.2 (as well as all ifort versions I am aware of) are too forgiving in both cases (accepting data of different rank as long at the totals number of elements is the same), while 10.4 and 11.3 are still too forgiving when it comes to stand-alone array variables? Adding reshape does work - but it means the shape needs to be repeated twice, once in the declaration and once in the assigned value, which seems suboptimal.
[Bug target/106600] __builtin_bswap32 is not hooked up for ZBB
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106600 --- Comment #2 from Andrew Pinski --- Created attachment 53480 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53480&action=edit Patch which is under test
[Bug target/106601] __builtin_bswap16 code gen could be improved with ZBB enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106601 --- Comment #3 from Andrew Pinski --- Created attachment 53479 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53479&action=edit Patch which is under test
[Bug fortran/106684] inconsistent array initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106684 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #1 from kargl at gcc dot gnu.org --- F2018, 7.5.10 Construction of derived-type values For a nonpointer component, the declared type and type parameters of the component and expr shall conform in the same way as for a variable and expr in an intrinsic assignment statement (10.2.1.2). F2018, 10.2.1.2 Intrinsic assignment statement In an intrinsic assignment statement, ... (3) the variable and expr shall be conformable unless the variable is an allocatable array that has the same rank as expr and is not a coarray, F2018: 3.36 conformable of two data entities having the same shape, or one being an array and the other being scalar % cat a.f90 program p implicit none a = (/0., 1., 2., 3./) end program % gfcx -o z a.f90 a.f90:13:3: 13 |a = (/0., 1., 2., 3./) | 1 Error: Incompatible ranks 2 and 1 in assignment at (1) Looks like a bug in your program. The quoted text is not a numbered constraint so a Fortran compiler is not required to report an issue. In this case, gfortran was able to diagnose an issue in your code. Simple fix is to use `reshape([0.,1.,2.,3.],[2.2]) in your constrcutor.
[Bug lto/106686] [lto][offloading] lto-wrapper leaves "target.o" temporay files behind when error diagnostic occurred
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106686 --- Comment #1 from Tobias Burnus --- Patch: https://gcc.gnu.org/pipermail/gcc-patches/2022-August/600033.html
[Bug tree-optimization/56456] [meta-bug] bogus/missing -Warray-bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456 Bug 56456 depends on bug 105348, which changed state. Bug 105348 Summary: Overly aggressive -Warray-bounds after conditional https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105348 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID
[Bug middle-end/105348] Overly aggressive -Warray-bounds after conditional
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105348 Martin Sebor changed: What|Removed |Added CC||msebor at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #5 from Martin Sebor --- Resolved as invalid per comment #3.
[Bug tree-optimization/106247] GCC12 warning in Eigen: array subscript is partly outside array bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106247
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|2022-07-10 00:00:00 |2022-08-19
Ever confirmed|0 |1
CC||msebor at gcc dot gnu.org
--- Comment #5 from Martin Sebor ---
This instance of -Warray-bounds (with the text "partly outside the bounds") is
often issued for aliasing violations where an object of one type is being
access by an lvalue of a larger struct. The ultimate access may be to a member
of the larger struct whose offset is within the bounds of the smaller object,
but the access is (or could be) wrong nonetheless (due to the aliasing rules)
and hence the warning.
Here's an example:
$ cat a.c && gcc -O2 -S -Wall a.c
struct A { int i; };
struct B { struct A a; int j; };
void* f (void)
{
struct A *p = __builtin_malloc (sizeof *p);
((struct B*)p)->a.i = 0;
return p;
}
a.c: In function ‘f’:
a.c:7:17: warning: array subscript ‘struct B[0]’ is partly outside array bounds
of ‘unsigned char[4]’ [-Warray-bounds]
7 | ((struct B*)p)->a.i = 0;
| ^~
a.c:6:17: note: object of size 4 allocated by ‘__builtin_malloc’
6 | struct A *p = __builtin_malloc (sizeof *p);
| ^~~~
If your case is comparable this should be resolved as invalid; otherwise, if
it's substantially different please post a reproducible test case.
[Bug tree-optimization/56456] [meta-bug] bogus/missing -Warray-bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456 Bug 56456 depends on bug 106446, which changed state. Bug 106446 Summary: -Warray-bounds false positive on downcast under condition https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106446 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID
[Bug tree-optimization/106446] -Warray-bounds false positive on downcast under condition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106446 Martin Sebor changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #2 from Martin Sebor --- The compiler doesn't know what D2::is_me() might return so it must emit code for both branches in bar(). In the true branch, because struct D1 has no member val, the warning triggers. This is by design.
[Bug c++/106648] [C++23] P2071 - Named universal character escapes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106648
Jakub Jelinek changed:
What|Removed |Added
Attachment #53471|0 |1
is obsolete||
--- Comment #2 from Jakub Jelinek ---
Created attachment 53478
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53478&action=edit
gcc13-pr106648-wip.patch.xz
Updated WIP patch. This has fixed bugs in the generator and a routine that
implements the mapping (tested on names from glibc UTF-8 and
https://eel.is/c++draft/lex.charset table so far), but isn't actually wired up
for \N{name}.
It does for now just exact matching, for fixit hints we'll need to do something
slightly different.
[Bug tree-optimization/106687] [13 Regression] Wrong code with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106687
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2022-08-19
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Target Milestone|--- |13.0
Known to fail||13.0
Known to work||12.1.0
--- Comment #1 from Andrew Pinski ---
Something more reduced:
bool var_0 = (bool)0;
unsigned int var_7 = 42;
char var_215;
int main() {
unsigned b = var_0;
unsigned p2 = var_7;
unsigned *tp;
if (b < p2)
tp = &p2;
else
tp = &b;
unsigned tt = *tp;
unsigned t = tt ^ (var_7 - var_0);
var_215 = t ? t : 42;
if (var_215 != 42)
__builtin_abort();
}
[Bug tree-optimization/106687] New: [13 Regression] Wrong code with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106687
Bug ID: 106687
Summary: [13 Regression] Wrong code with -O2
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: vsevolod.livinskiy at gmail dot com
Target Milestone: ---
Link to the Compiler Explorer: https://godbolt.org/z/a8PTr5sqM
The error disappears if I use another definition of max (b > p2 ? b : p2).
Reproducer:
#include
bool var_0 = (bool)0;
unsigned int var_7 = 42;
char var_215;
const unsigned &a(const unsigned &b, unsigned &p2) { return b < p2 ? p2 : b; }
void test() { var_215 = a(var_0, var_7) ^ (var_7 - var_0) ?: 42; }
int main() {
test();
printf("%d\n", var_215);
if (var_215 != 42)
__builtin_abort();
}
Error:
>$ g++ -O1 small.cpp && ./a.out
42
>$ g++ -O2 small.cpp && ./a.out
0
Aborted (core dumped)
gcc version 13.0.0 20220819 (81e20a6eb9e6b7eb62a09ac58811387f0343bd14)
[Bug c/106683] internal compiler error for unusua inline assembly constraint
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106683 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=104786 --- Comment #2 from Andrew Pinski --- I suspect it was fixed for GCC 9.5.0 by the patch which fixed PR 104786. Anyways it was fixed in GCC 9.5.0.
[Bug c/106683] internal compiler error for unusua inline assembly constraint
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106683 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |9.5
[Bug c++/106685] ICE with concepts and ptr to member functions in requires
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106685 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Known to fail||12.1.0, 6.1.0, 8.1.0 Last reconfirmed||2022-08-19 --- Comment #4 from Andrew Pinski --- Confirmed. the code has always ICE since concepts has been added.
[Bug c++/106685] ICE with concepts and ptr to member functions in requires
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106685 --- Comment #3 from Andrew Pinski --- Created attachment 53477 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53477&action=edit No more headers
[Bug c++/106685] [12/13 Regerssion] ICE during GIMPLE pass: vrp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106685 --- Comment #2 from Andrew Pinski --- Created attachment 53476 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53476&action=edit More reduced
[Bug c++/106685] [12/13 Regerssion] ICE during GIMPLE pass: vrp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106685 --- Comment #1 from Andrew Pinski --- Created attachment 53475 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53475&action=edit testcase Please next time attach the testcase instead of linking to godbolt
[Bug c++/106646] [C++23] P2437R1 - Support for #warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106646 --- Comment #2 from Marek Polacek --- Thanks, I can look into that for C++. I notice that with your patch we say "#warning before C2X is a GCC extension" even when compiling with cc1plus; I suppose the C2X message should be guarded by CPP_OPTION (pfile, cplusplus).
[Bug lto/106686] New: [lto][offloading] lto-wrapper leaves "target.o" temporay files behind when error diagnostic occurred
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106686
Bug ID: 106686
Summary: [lto][offloading] lto-wrapper leaves "target.o"
temporay files behind when error diagnostic occurred
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
Target Milestone: ---
I found a couple of /tmp/ccGARvpn.target.o files - which are surely unintended
leftovers.
The filename is returned by lto-wrapper.cc's compile_offload_image and then
collected in
offload_names[next_name_entry] = compile_offload_image (...)
and processed as
if (offload_names)
{
find_crtoffloadtable (save_temps, dumppfx);
for (i = 0; offload_names[i]; i++)
printf ("%s\n", offload_names[i]);
That seems to work well if not error occurred - but if there was an error, it
seems to be the only file suffix which is not cleaned up.
Reproducer:
- You need a GCC configured for offload (nvptx, gcn or intelmic)
- You need to get it to fail.
On mainline, one way is to compile the following with offloading: 'gcc -fopenmp
*.c'
which outputs:
lto1: error: OpenMP 'requires' directive with 'unified_shared_memory'
specified only in some compilation units
lto1: fatal error: errors during merging of translation units
Input:
--- 1.c --
#pragma omp requires unified_shared_memory
int i;
void foo() {
#pragma omp target enter data map(to:i)
}
--- 2.c --
int j;
void foo() {
#pragma omp target enter data map(to:j)
}
[Bug c++/106685] New: [12/13 Regerssion] ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106685 Bug ID: 106685 Summary: [12/13 Regerssion] ICE Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: egor.pugin at gmail dot com Target Milestone: --- https://godbolt.org/z/987rxevMh
[Bug tree-optimization/105646] g++ does not raise "xxx may be used uninitialized" warning on dead code when optimizing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105646
Richard Biener changed:
What|Removed |Added
Summary|g++ does not raise "xxx is |g++ does not raise "xxx may
|used uninitialized" warning |be used uninitialized"
|under some conditions |warning on dead code when
||optimizing
Last reconfirmed||2022-08-19
Component|c++ |tree-optimization
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
Ever confirmed|0 |1
Status|UNCONFIRMED |ASSIGNED
--- Comment #2 from Richard Biener ---
The issue is that for f3() we'd emit a may-uninitialized warning because f1()
could have thrown and thus v3{v3} is only executed conditionally. For f2()
v2{v2} is always executed (when f2 is entered). The late diagnostic pass
that would emit may-uninitialized warnings doesn't get to see the v3{v3}
initialization because it was removed as dead code.
When not optimizing we choose to diagnose may-uninit before eliminating v3{v3}.
Confirmed. Not sure if we want to fix this. We eventually might use a
different predicate than post-domination for whether a stmt is considered
always executed (ignoring EH and abnormal control flow). Greedily
following "fallthru" edges might work for this, also implementing the
unreachable edge honoring the ??? comment says.
I have a patch.
[Bug tree-optimization/105937] [12/13 Regression] maybe-uninitialized with std::optional
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105937
Richard Biener changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
Ever confirmed|0 |1
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2022-08-19
--- Comment #4 from Richard Biener ---
The predicate analysis has difficulties in handling this case, its like
void foo (int val)
{
int uninit;
for (;;)
{
if (..)
{
.. = val; (*)
val = uninit;
}
# val = PHI <..>
}
}
and we diagnose (*), figuring the loop PHI of 'val' eventually leads to
the PHI that post-dominates the use we want to diagnose. One issue with
this is that the predicates provided are from a different iteration than
those used so we won't have a chance to compare things meanigfully here.
I think the best thing is to avoid diagnosing possibly uninitialized
uses in the next iteration of a loop because we have no chance to
prove the path is unreachable and thus we'll always warn.
At least I think so.
I do have a patch.
[Bug tree-optimization/106511] [13 Regression] New -Werror=maybe-uninitialized since r13-1268-g8c99e307b20c502e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106511 --- Comment #2 from Richard Biener --- VRP could use max_stmt_executions here (note it doesn't properly handle loop nests so the name is somewhat misleading)
[Bug tree-optimization/106511] [13 Regression] New -Werror=maybe-uninitialized since r13-1268-g8c99e307b20c502e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106511
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
--- Comment #1 from Richard Biener ---
The missed optimization is
symTotal = 0;
for (i = 0; i < 16; i++) {
if (t&(1 << (15-i))) {
k = get_bits(bd, 16);
for (j = 0; j < 16; j++)
if (k&(1 << (15-j)))
symToByte[symTotal++] = (16*i)+j;
}
}
...
symCount = symTotal+2;
for (j = 0; j < groupCount; j++) {
unsigned char length[258], temp[20 +1];
int minLen, maxLen, pp;
# 235 "bunzip2.c"
t = get_bits(bd, 5)-1;
for (i = 0; i < symCount; i++) {
...
length[i] = t+1;
}
minLen = maxLen = length[0];
to see that symCount cannot be zero and thus the loop header copy check for the
loop on the last line can be elided. It looks quite obvious to me that
should be able to compute a range for symTotal and thus symCount. SCEV
is likely of not much help here but we should be able to compute
the maximum number of times symTotal++ is executed by looking at the number
of iterations of the loop nest.
Note that with -O we do not run VRP and with -O2 we don't warn. But
the testcase
void link_error ();
int bar ();
void foo ()
{
int symTotal = 0;
for (int i = 0; i < 16; ++i)
{
if (bar())
symTotal++;
}
if (symTotal < 0 || symTotal > 16)
link_error ();
}
shows that even with -O2 VRP only figures that symTotal is positive, it doesn't
get the upper bound:
[local count: 63136016]:
# RANGE [irange] int [0, +INF] NONZERO 0x7fff
# symTotal_19 = PHI
if (symTotal_19 > 16)
given that loop header copying short-cuts the initialization of length[]
it's clear that we diagnose the unconditional use after the loop.
[Bug c/105660] [12/13 Regression] ICE in warn_parm_array_mismatch when merging two function decls and VLA arguments since r12-1218-gc6503fa93b5565c9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105660 --- Comment #6 from Romain Dolbeau --- Please consider this for 12.2, it's a trivial bug with a trivial fix that's been available for two months.
[Bug fortran/106684] New: inconsistent array initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106684 Bug ID: 106684 Summary: inconsistent array initialization Product: gcc Version: 10.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: j...@bolding-bruggeman.com Target Milestone: --- The minor update of 10.3 to 10.4 causes gfortran to no longer accept initialization of multidimensional array components with 1d data. However, standalone multidimensional arrays can still be initialized with 1d data. That seems inconsistent. The same behavior is found in recent releases of 11 and 12 (tested: 11.3.0, 12.1.0) Example: program p implicit none real :: a(2,2) data a /0., 1., 2., 3./ type t integer :: b real :: a(2,2) end type type (t) c data c /t(1, (/0., 1., 2., 3./))/ end program This results in the following error with gfortran 10.4: test_array_init.F90:12:16: 12 |data c /t(1, (/0., 1., 2., 3./))/ |1 Error: The rank of the element in the structure constructor at (1) does not match that of the component (1/2) However, the above code is accepted by gfortran 9.x and 10.3, as well as ifort.
[Bug rtl-optimization/106590] [12/13 Regression] x86-64 miscompilation starting with r12-8233-g1ceddd7497e15d w/ mtune=skylake
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106590 Richard Biener changed: What|Removed |Added Target Milestone|12.2|12.3 --- Comment #10 from Richard Biener --- GCC 12.2 is being released, retargeting bugs to GCC 12.3.
[Bug target/106609] [12/13 Regression] sh3eb-elf cross compiler is being miscompiled since r12-1525-g3155d51bfd1de8b6c4645
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106609 Richard Biener changed: What|Removed |Added Target Milestone|12.2|12.3 --- Comment #11 from Richard Biener --- GCC 12.2 is being released, retargeting bugs to GCC 12.3.
[Bug libstdc++/106589] [12/13 Regression] visit rejects lambdas that do not return void
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106589 Richard Biener changed: What|Removed |Added Target Milestone|12.2|12.3 --- Comment #4 from Richard Biener --- GCC 12.2 is being released, retargeting bugs to GCC 12.3.
[Bug libstdc++/106608] [12/13 Regression] std::optional requires unavailable dtor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106608 Richard Biener changed: What|Removed |Added Target Milestone|12.2|12.3 --- Comment #5 from Richard Biener --- GCC 12.2 is being released, retargeting bugs to GCC 12.3.
[Bug tree-optimization/106570] [12/13 Regression] DCE sometimes fails with depending if statements since r12-2305-g398572c1544d8b75
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106570 Richard Biener changed: What|Removed |Added Target Milestone|12.2|12.3 --- Comment #3 from Richard Biener --- GCC 12.2 is being released, retargeting bugs to GCC 12.3.
[Bug bootstrap/106482] [12/13 Regression] bootstrap of 12.1.0 using 4.8.2 fails with C++ errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106482 Richard Biener changed: What|Removed |Added Target Milestone|12.2|12.3 --- Comment #3 from Richard Biener --- GCC 12.2 is being released, retargeting bugs to GCC 12.3.
[Bug c++/106395] [12/13 regression] [mingw] "redeclared without dllimport attribute: previous dllimport ignored" on C++ friend since r12-299-ga0fdff3cf33f72
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106395 Richard Biener changed: What|Removed |Added Target Milestone|12.2|12.3 --- Comment #3 from Richard Biener --- GCC 12.2 is being released, retargeting bugs to GCC 12.3.
[Bug tree-optimization/106458] [12/13 Regression] glibc's malloc/tst-scratch_buffer.c test is miscompiled with gcc-12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106458 Richard Biener changed: What|Removed |Added Target Milestone|12.2|12.3 --- Comment #16 from Richard Biener --- GCC 12.2 is being released, retargeting bugs to GCC 12.3.
[Bug target/106069] [12/13 Regression] wrong code with -O -fno-tree-forwprop -maltivec on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106069 Richard Biener changed: What|Removed |Added Target Milestone|12.2|12.3 --- Comment #33 from Richard Biener --- GCC 12.2 is being released, retargeting bugs to GCC 12.3.
[Bug c++/106434] [12/13 Regression] Spurious -Wnull-dereference when using std::unique_copy() since r12-5187-g1ae8edf5f73ca5c3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106434 Richard Biener changed: What|Removed |Added Target Milestone|12.2|12.3 --- Comment #5 from Richard Biener --- GCC 12.2 is being released, retargeting bugs to GCC 12.3.
[Bug target/106342] [12/13 Regression] internal compiler error: in extract_insn, at recog.cc:2791 since r12-4240-g2b8453c401b699
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106342 Richard Biener changed: What|Removed |Added Target Milestone|12.2|12.3 --- Comment #9 from Richard Biener --- GCC 12.2 is being released, retargeting bugs to GCC 12.3.
[Bug target/106022] [12 Regression] Enable vectorizer generates extra load
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106022 Richard Biener changed: What|Removed |Added Target Milestone|12.2|12.3 --- Comment #21 from Richard Biener --- GCC 12.2 is being released, retargeting bugs to GCC 12.3.
[Bug tree-optimization/106297] [12/13 Regression] stringop-overflow misbehaviour on atomic since r12-4725-g88b504b7a8c5affb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106297 Richard Biener changed: What|Removed |Added Target Milestone|12.2|12.3 --- Comment #7 from Richard Biener --- GCC 12.2 is being released, retargeting bugs to GCC 12.3.
[Bug c/105972] [12/13 Regression] ICE in lower_stmt, at gimple-low.cc:312 since r12-4608-gb4702276615ff8d4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105972 Richard Biener changed: What|Removed |Added Target Milestone|12.2|12.3 --- Comment #3 from Richard Biener --- GCC 12.2 is being released, retargeting bugs to GCC 12.3.
[Bug rtl-optimization/105952] [12/13 Regression] ICE in sel_redirect_edge_and_branch, at sel-sched-ir.cc:5680
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105952 Richard Biener changed: What|Removed |Added Target Milestone|12.2|12.3 --- Comment #2 from Richard Biener --- GCC 12.2 is being released, retargeting bugs to GCC 12.3.
[Bug analyzer/106206] [12/13 Regression] ICE: canonical types differ for identical types 'int(...)' and 'int(...)' since r12-1931-ge61ffa201403e3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106206 Richard Biener changed: What|Removed |Added Target Milestone|12.2|12.3 --- Comment #2 from Richard Biener --- GCC 12.2 is being released, retargeting bugs to GCC 12.3.
[Bug tree-optimization/105705] [12/13 Regression] std::equal triggers incorrect -Wnonnull warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105705 Richard Biener changed: What|Removed |Added Target Milestone|12.2|12.3 --- Comment #8 from Richard Biener --- GCC 12.2 is being released, retargeting bugs to GCC 12.3.
[Bug tree-optimization/105918] [12/13 Regression] Spurious Warray-bounds in std::to_chars since r12-2132-ga110855667782dac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105918 Richard Biener changed: What|Removed |Added Target Milestone|12.2|12.3 --- Comment #3 from Richard Biener --- GCC 12.2 is being released, retargeting bugs to GCC 12.3.
[Bug tree-optimization/106199] [12/13 Regression] incorrect warning: memcpy writing 1 or more bytes into a region of size 0 overflows the destination with std::vector::insert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106199 Richard Biener changed: What|Removed |Added Target Milestone|12.2|12.3 --- Comment #6 from Richard Biener --- GCC 12.2 is being released, retargeting bugs to GCC 12.3.
[Bug tree-optimization/105867] [12/13 Regression] incorrect dangling-pointer warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105867 Richard Biener changed: What|Removed |Added Target Milestone|12.2|12.3 --- Comment #3 from Richard Biener --- GCC 12.2 is being released, retargeting bugs to GCC 12.3.
[Bug tree-optimization/105679] [12 Regression] extra -Warray-bounds warning added with -fsanitize=shift due to jump threading
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105679 Richard Biener changed: What|Removed |Added Target Milestone|12.2|12.3 --- Comment #8 from Richard Biener --- GCC 12.2 is being released, retargeting bugs to GCC 12.3.
[Bug tree-optimization/106155] [12/13 Regression] spurious "may be used uninitialized" warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106155 Richard Biener changed: What|Removed |Added Target Milestone|12.2|12.3 --- Comment #5 from Richard Biener --- GCC 12.2 is being released, retargeting bugs to GCC 12.3.
[Bug c++/105841] [12/13 Regression] Change in behavior of CTAD for alias templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105841 Richard Biener changed: What|Removed |Added Target Milestone|12.2|12.3 --- Comment #6 from Richard Biener --- GCC 12.2 is being released, retargeting bugs to GCC 12.3.
[Bug target/105617] [12/13 Regression] Slp is maybe too aggressive in some/many cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105617 Richard Biener changed: What|Removed |Added Target Milestone|12.2|12.3 --- Comment #16 from Richard Biener --- GCC 12.2 is being released, retargeting bugs to GCC 12.3.
[Bug target/106101] [12/13 Regression] ICE in reg_bitfield_target_p since r12-4428-g147ed0184f403b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106101 Richard Biener changed: What|Removed |Added Target Milestone|12.2|12.3 --- Comment #12 from Richard Biener --- GCC 12.2 is being released, retargeting bugs to GCC 12.3.
[Bug libstdc++/105580] [12/13 Regression] warning "potential null pointer dereference" raised when using istreambuf_iterator and any "-O" flag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105580 Richard Biener changed: What|Removed |Added Target Milestone|12.2|12.3 --- Comment #3 from Richard Biener --- GCC 12.2 is being released, retargeting bugs to GCC 12.3.
[Bug fortran/105012] [12/13 Regression] wrf from SPECCPU2017 ICEs during LTO linking since r12-7692-g8db155ddf8cec9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105012 Richard Biener changed: What|Removed |Added Target Milestone|12.2|12.3 --- Comment #16 from Richard Biener --- GCC 12.2 is being released, retargeting bugs to GCC 12.3.
[Bug rtl-optimization/106041] [12/13 Regression] infinite loop in fast_dce at -O1 with aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106041 Richard Biener changed: What|Removed |Added Target Milestone|12.2|12.3 --- Comment #8 from Richard Biener --- GCC 12.2 is being released, retargeting bugs to GCC 12.3.
[Bug tree-optimization/105545] [12/13 Regression] Warning for string assignment with _GLIBCXX_ASSERTIONS since r12-3347-g8af8abfbbace49e6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105545 Richard Biener changed: What|Removed |Added Target Milestone|12.2|12.3 --- Comment #8 from Richard Biener --- GCC 12.2 is being released, retargeting bugs to GCC 12.3.
[Bug target/105010] [12/13 regression] GCC 12 after 20220227 fails to build on powerpc64-freebsd with Error: invalid mfcr mask
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105010 Richard Biener changed: What|Removed |Added Target Milestone|12.2|12.3 --- Comment #16 from Richard Biener --- GCC 12.2 is being released, retargeting bugs to GCC 12.3.
[Bug tree-optimization/106514] [12/13 Regression] ranger slowness in path query
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106514 Richard Biener changed: What|Removed |Added Target Milestone|12.2|12.3 --- Comment #9 from Richard Biener --- GCC 12.2 is being released, retargeting bugs to GCC 12.3.
[Bug tree-optimization/105937] [12/13 Regression] maybe-uninitialized with std::optional
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105937 Richard Biener changed: What|Removed |Added Target Milestone|12.2|12.3 --- Comment #3 from Richard Biener --- GCC 12.2 is being released, retargeting bugs to GCC 12.3.
[Bug target/105069] [12/13 regression] sh-elf internal compiler errors and test failures with -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105069 Richard Biener changed: What|Removed |Added Target Milestone|12.2|12.3 --- Comment #11 from Richard Biener --- GCC 12.2 is being released, retargeting bugs to GCC 12.3.
[Bug target/104912] [12/13 Regression] 416.gamess regression after r12-7612-g69619acd8d9b58
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104912 Richard Biener changed: What|Removed |Added Target Milestone|12.2|12.3 --- Comment #12 from Richard Biener --- GCC 12.2 is being released, retargeting bugs to GCC 12.3.
