[Bug target/105930] [12/13 Regression] Excessive stack spill generation on 32-bit x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105930 Roger Sayle changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #27 from Roger Sayle --- This should now be fixed on both mainline and the GCC 12 release branch.
[Bug tree-optimization/106243] New: Failure to optimize (0 - x) & 1 on vector type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106243
Bug ID: 106243
Summary: Failure to optimize (0 - x) & 1 on vector type
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
#include
typedef int64_t v2i64 __attribute__((vector_size(16)));
v2i64 f(v2i64 x)
{
return (0 - x) & 1;
}
This can be optimized to `return x & 1;`. LLVM does this transformation, but
GCC does not
[Bug tree-optimization/106063] [12 Regression] ICE: in gimple_expand_vec_cond_expr, at gimple-isel.cc:281 with -O2 -fno-tree-forwprop --param=evrp-mode=legacy-first
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106063 --- Comment #6 from CVS Commits --- The master branch has been updated by Dimitar Dimitrov : https://gcc.gnu.org/g:4ebbf3906895bcb40d7ff2729cf46deae66bc268 commit r13-1595-g4ebbf3906895bcb40d7ff2729cf46deae66bc268 Author: Dimitar Dimitrov Date: Sun Jul 10 11:15:39 2022 +0300 testsuite: Require int128 for gcc.dg/pr106063.c Require effective target int128 for gcc.dg/pr106063.c. PR tree-optimization/106063 gcc/testsuite/ChangeLog: * gcc.dg/pr106063.c: Require effective target int128. Signed-off-by: Dimitar Dimitrov
[Bug tree-optimization/106244] New: Failure to optimize (1 << x) & 1 to `x == 0` if separated into multiple statements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106244
Bug ID: 106244
Summary: Failure to optimize (1 << x) & 1 to `x == 0` if
separated into multiple statements
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
#include
int8_t f(int8_t x)
{
int8_t sh = 1 << x;
return sh & 1;
}
This can be optimized to `return x == 0;`. This transformation is done by LLVM,
but not by GCC.
PS: For some reason GCC manages to do this optimization if I replace `f` with
`return (1 << x) & 1;` instead of having it spelled out in 2 statements.
[Bug tree-optimization/106245] New: Failure to optimize (u8)(a << 7) >> 7 pattern to a & 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106245
Bug ID: 106245
Summary: Failure to optimize (u8)(a << 7) >> 7 pattern to a & 1
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
#include
int8_t f(int8_t a)
{
return (uint8_t)(a << 7) >> 7;
}
This can be optimized to `return a & 1;`. This transformation is done by LLVM,
but not by GCC.
[Bug tree-optimization/106246] New: [13 Regression] powerpc-darwin9 bootstrap fails after r13-1575-gcf3a120084e946 ICE vect_transform_loops, at tree-vectorizer.cc:1032
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106246
Bug ID: 106246
Summary: [13 Regression] powerpc-darwin9 bootstrap fails after
r13-1575-gcf3a120084e946 ICE vect_transform_loops, at
tree-vectorizer.cc:1032
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: iains at gcc dot gnu.org
Target Milestone: ---
Created attachment 53283
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53283&action=edit
reduced reproducer
reproduces on a cross from x86_64-linux-gnu like so:
$ ./gcc/cc1plus -quiet -O2 -fpreprocessed ../ggc-page.ii
during GIMPLE pass: vect
../ggc-page.ii: In function ‘void ggc_pch_total_size()’:
../ggc-page.ii:8:6: internal compiler error: in vect_transform_loops, at
tree-vectorizer.cc:1032
8 | void ggc_pch_total_size() {
| ^~
0x1ba4c31 vect_transform_loops
../../src/gcc/tree-vectorizer.cc:1032
0x1ba5250 try_vectorize_loop_1
../../src/gcc/tree-vectorizer.cc:1153
0x1ba5389 try_vectorize_loop
../../src/gcc/tree-vectorizer.cc:1183
0x1ba561d execute
../../src/gcc/tree-vectorizer.cc:1299
[Bug tree-optimization/106246] [13 Regression] powerpc-darwin9 bootstrap fails after r13-1575-gcf3a120084e946 ICE vect_transform_loops, at tree-vectorizer.cc:1032
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106246 Iain Sandoe changed: What|Removed |Added Keywords||build, ice-on-valid-code Last reconfirmed||2022-07-10 Target||powerpc-darwin9 Target Milestone|--- |13.0 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Known to fail||13.0 --- Comment #1 from Iain Sandoe --- note, that powerpc64-linux-gnu (BE power7) seems to be OK (although that's still a 64b host) (confirmed with a native build and crosses on x86-64 darwin and linux).
[Bug c++/106241] compiler can't handle large array of strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106241 --- Comment #4 from Jonathan Wakely --- Yes, like https://wg21.link/p1967r7 But in the meantime, you can create a static array of trivial types (not std::string) and then iterate over it at runtime to copy the values into the data structure you want to use (a multimap containing strings, or whatever).
[Bug c++/106241] compiler can't handle large array of strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106241 --- Comment #5 from Robert Durkacz --- That is a good idea. On Sun, 10 Jul 2022 at 19:56, redi at gcc dot gnu.org < gcc-bugzi...@gcc.gnu.org> wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106241 > > --- Comment #4 from Jonathan Wakely --- > Yes, like https://wg21.link/p1967r7 > > But in the meantime, you can create a static array of trivial types (not > std::string) and then iterate over it at runtime to copy the values into > the > data structure you want to use (a multimap containing strings, or > whatever). > > -- > You are receiving this mail because: > You reported the bug.
[Bug preprocessor/91733] No longer treat carriage return as an end-of-line
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91733 David Malcolm changed: What|Removed |Added CC||dmalcolm at gcc dot gnu.org Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from David Malcolm --- Thanks; marking this one as RESOLVED.
[Bug c++/106247] New: GCC12 warning in Eigen: array subscript is partly outside array bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106247
Bug ID: 106247
Summary: GCC12 warning in Eigen: array subscript is partly
outside array bounds
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: fchelnokov at gmail dot com
Target Milestone: ---
If one compiles the following program using Eigen 3.4.0:
#include
int main(){
Eigen::Array a;
a.setRandom();
Eigen::Array b;
b.col(0).tail(2) = a.col(1);
}
in GCC12 with command-line options: -std=c++20 -Wall -Wextra -pedantic-errors
-O2 -march=haswell
then a large error occurs ending with
/opt/compiler-explorer/gcc-12.1.0/lib/gcc/x86_64-linux-gnu/12.1.0/include/avxintrin.h:893:24:
warning: array subscript '__m256d_u[0]' is partly outside array bounds of
'Eigen::Array [1]' [-Warray-bounds]
893 | return *(__m256d_u *)__P;
|^~~
Similar errors occur with other -march options or other code using Eigen
library.
Everything is fine in GCC 11 or other compilers. Online demo:
https://gcc.godbolt.org/z/hT348GYo9
Is it Eigen or GCC bug? Related discussion:
https://stackoverflow.com/q/72871100/7325599
[Bug target/105930] [12/13 Regression] Excessive stack spill generation on 32-bit x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105930 --- Comment #28 from Linus Torvalds --- (In reply to Roger Sayle from comment #27) > This should now be fixed on both mainline and the GCC 12 release branch. Thanks everybody. Looks like the xchg optimization isn't in the gcc-12 release branch, but the stack use looks reasonable from my (very limited) testing.
[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 Andrew Pinski changed: What|Removed |Added Target||x86_64-linux-gnu Ever confirmed|0 |1 Status|UNCONFIRMED |WAITING Last reconfirmed||2022-07-10 Keywords||diagnostic Component|c++ |tree-optimization --- Comment #1 from Andrew Pinski --- Can you attach the 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
--- Comment #2 from Andrew Pinski ---
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):
array.7_137 = (long unsigned int) &MEM [(void *)&b + 8B];
_139 = array.7_137 >> 3;
_140 = -_139;
_141 = _140 & 3;
first_142 = (long int) _141;
_143 = MIN_EXPR ;
_145 = 2 - _143;
alignedEnd_148 = _143;
goto ; [100.00%]
[local count: 8655976563]:
index.12_166 = (long unsigned int) index_165;
_167 = index.12_166 * 8;
_168 = &MEM [(void *)&a + 16B] + _167;
_171 = &MEM [(void *)&b + 8B] + _167;
_172 = *_168;
MEM[(double &)_171] = _172;
index_173 = index_165 + 1;
[local count: 9725816346]:
# index_165 = PHI <0(2), index_173(3)>
if (_143 > index_165)
goto ; [89.00%]
else
goto ; [11.00%]
[local count: 8655976563]:
index.10_152 = (long unsigned int) index_151;
_153 = index.10_152 * 8;
_154 = &MEM [(void *)&a + 16B] + _153;
_155 = MEM[(__m256d_u * {ref-all})_154];
_158 = &MEM [(void *)&b + 8B] + _153;
MEM[(__m256d * {ref-all})_158] = _155;
index_159 = index_151 + 4;
[local count: 9725816346]:
# index_151 = PHI <_143(4), index_159(5)>
if (alignedEnd_148 > index_151)
goto ; [89.00%]
else
goto ; [11.00%]
[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 Fedor Chelnokov changed: What|Removed |Added CC||fchelnokov at gmail dot com --- Comment #3 from Fedor Chelnokov --- Created attachment 53284 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53284&action=edit Preprocessed source Preprocessed source is attached.
[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 Andrew Pinski changed: What|Removed |Added Ever confirmed|1 |0 Status|WAITING |UNCONFIRMED
[Bug tree-optimization/106245] Failure to optimize (u8)(a << 7) >> 7 pattern to a & 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106245
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Last reconfirmed||2022-07-10
Target||x86_64-linux-gnu
--- Comment #1 from Andrew Pinski ---
Confirmed. Note on aarch64, it is optimized down to &1 on the RTL level.
The issue is we don't optimize:
int f(int a)
{
return (a << 31) >> 31;
}
Into:
int f(int a)
{
return -(a&1);
}
I thought I had saw a bug report about that but I can't find it.
[Bug middle-end/25521] change semantics of const volatile variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25521 Jose E. Marchesi changed: What|Removed |Added CC||jose.marchesi at oracle dot com --- Comment #6 from Jose E. Marchesi --- So I am being bitten by this in the BPF backend [1]. Long story short: LLVM places initialized `volatile const' variables in .rodata, whereas GCC puts them in .data. The kernel's libbpf scans the objects and generates a "skeleton" header that, among other things, reflects the sections in the compiled BPF object. This divergence in behavior between LLVM and GCC makes the skeleton to define different data structures, i.e. obj->rodata->foo vs. obj->data->foo. See [1] for details. I don't actually understand Gabriel's comment, "If it may be modified by hardware or other external means, it can't go into .rodata section.". Why not? The permissions of the .rodata section eventually determines the permissions used to map the corresponding pages in the particular process running the program, but I don't see how can prevent the same physical memory to be updated by hardware, or even other processes mapping the same physical page using write perms. Or what am I missing? Can we change the behavior of GCC to put such variables in .rodata? [1] https://lore.kernel.org/bpf/87fsj8vjcy@oracle.com/T/#me726127e166f97fd50f09b647a604f176f809c63
[Bug middle-end/25521] change semantics of const volatile variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25521
--- Comment #7 from Jose E. Marchesi ---
If, as a workaround, I try to use a `section' attribute, like in:
__attribute__((section(".rodata"))) volatile const int lala = 0;
I don't get an ICE, but a section with write permissions:
.section.rodata,"aw"
And the assembler then complains:
foo-gcc.s:4: Warning: setting incorrect section attributes for .rodata
[Bug tree-optimization/106244] Failure to optimize (1 << x) & 1 to `x == 0` if separated into multiple statements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106244
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2022-07-10
Ever confirmed|0 |1
Severity|normal |enhancement
Status|UNCONFIRMED |NEW
--- Comment #1 from Andrew Pinski ---
Actually it is not optimized if it was in one statement:
int8_t f1(int8_t x)
{
return ((int8_t)(1 << x)) & 1;
}
The IR has:
_4 = (int) x_1(D);
_5 = 1 << _4;
sh_6 = (int8_t) _5;
_7 = sh_6 & 1;
We optimize directly "(1 << x) & 1" but not with a cast.
[Bug tree-optimization/106243] Failure to optimize (0 - x) & 1 on gimple level (including vector types)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106243
Andrew Pinski changed:
What|Removed |Added
Summary|Failure to optimize (0 - x) |Failure to optimize (0 - x)
|& 1 on vector type |& 1 on gimple level
||(including vector types)
Ever confirmed|0 |1
Last reconfirmed||2022-07-10
Status|UNCONFIRMED |NEW
--- Comment #1 from Andrew Pinski ---
Confirmed, even scalar version is not optimized on the gimple level:
int f1(int x)
{
x = -x;
return x & 1;
}
RTL level is done during combine for the scalar version:
Trying 6 -> 7:
6: {r86:SI=-r87:SI;clobber flags:CC;}
REG_DEAD r87:SI
REG_UNUSED flags:CC
7: {r85:SI=r86:SI&0x1;clobber flags:CC;}
REG_DEAD r86:SI
REG_UNUSED flags:CC
Successfully matched this instruction:
(parallel [
(set (reg:SI 85)
(and:SI (reg:SI 87)
(const_int 1 [0x1])))
(clobber (reg:CC 17 flags))
])
[Bug c++/106241] compiler can't handle large array of strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106241 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #6 from Andrew Pinski --- Dup of bug 105838 (and there might be others). *** This bug has been marked as a duplicate of bug 105838 ***
[Bug c++/105838] [10/11/12/13 Regression] g++ 12.1.0 runs out of memory or time when building const std::vector of std::strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105838 Andrew Pinski changed: What|Removed |Added CC||robert.durkacz at gmail dot com --- Comment #8 from Andrew Pinski --- *** Bug 106241 has been marked as a duplicate of this bug. ***
[Bug preprocessor/97498] #pragma GCC diagnostic ignored "-Wunused-function" inconsistent
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97498 --- Comment #3 from CVS Commits --- The master branch has been updated by Lewis Hyatt : https://gcc.gnu.org/g:0587cef3d7962a8b0f44779589ba2920dd3d71e5 commit r13-1596-g0587cef3d7962a8b0f44779589ba2920dd3d71e5 Author: Lewis Hyatt Date: Sat Jul 9 16:12:21 2022 -0400 c: Fix location for _Pragma tokens [PR97498] The handling of #pragma GCC diagnostic uses input_location, which is not always as precise as needed; in particular the relative location of some tokens and a _Pragma directive will crucially determine whether a given diagnostic is enabled or suppressed in the desired way. PR97498 shows how the C frontend ends up with input_location pointing to the beginning of the line containing a _Pragma() directive, resulting in the wrong behavior if the diagnostic to be modified pertains to some tokens found earlier on the same line. This patch fixes that by addressing two issues: a) libcpp was not assigning a valid location to the CPP_PRAGMA token generated by the _Pragma directive. b) C frontend was not setting input_location to something reasonable. With this change, the C frontend is able to change input_location to point to the _Pragma token as needed. This is just a two-line fix (one for each of a) and b)), the testsuite changes were needed only because the location on the tested warnings has been somewhat improved, so the tests need to look for the new locations. gcc/c/ChangeLog: PR preprocessor/97498 * c-parser.cc (c_parser_pragma): Set input_location to the location of the pragma, rather than the start of the line. libcpp/ChangeLog: PR preprocessor/97498 * directives.cc (destringize_and_run): Override the location of the CPP_PRAGMA token from a _Pragma directive to the location of the expansion point, as is done for the tokens lexed from it. gcc/testsuite/ChangeLog: PR preprocessor/97498 * c-c++-common/pr97498.c: New test. * c-c++-common/gomp/pragma-3.c: Adapt for improved warning locations. * c-c++-common/gomp/pragma-5.c: Likewise. * gcc.dg/pragma-message.c: Likewise. libgomp/ChangeLog: * testsuite/libgomp.oacc-c-c++-common/reduction-5.c: Adapt for improved warning locations. * testsuite/libgomp.oacc-c-c++-common/vred2d-128.c: Likewise.
[Bug preprocessor/97498] #pragma GCC diagnostic ignored "-Wunused-function" inconsistent
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97498 Lewis Hyatt changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Lewis Hyatt --- Fixed for GCC 13.
[Bug libstdc++/106248] New: operator>>std::basic_istream at boundary condition behave differently in different opt levels
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106248
Bug ID: 106248
Summary: operator>>std::basic_istream at boundary condition
behave differently in different opt levels
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: Ting.Wang.SH at ibm dot com
Target Milestone: ---
SYMPTOM:
Saw operator>>std::basic_istream set ios_base::eofbit differently when buffer
size equals to stream content size under different optimization levels. This is
observed on gcc version 11.2.0 with libstdc++.so.6.0.30, and not observed on
gcc version 9.4.0 with libstdc++.so.6.0.28.
This might not be a bug, however the behavior change under different
optimization levels is a little bit annoying.
An example C++ program is
$ cat a.cc
#include
#include
#include
char a_[10];
int main(int argc, char *argv[])
{
std::basic_string, std::allocator >
input((const char *)" abcdefghi");
std::basic_stringbuf, std::allocator >
sbuf(input);
std::basic_istream > istr(&sbuf);
istr >> a_;
std::cout << "istr.rdstate: " << istr.rdstate() << std::endl;
return 0;
}
$ g++ -O0 -o a.O0 a.cc
$ ./a.O0
istr.rdstate: 2
$ g++ -O3 -o a.O3 a.cc
$ ./a.O3
istr.rdstate: 0
[Bug middle-end/25521] change semantics of const volatile variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25521 --- Comment #8 from Jose E. Marchesi --- After a little discussion in IRC I filed this LLVM bug: https://github.com/llvm/llvm-project/issues/56468 Regarding the ICE described by Ulrich, I cannot reproduce it using: bpf-unknown-none-gcc (GCC) 13.0.0 20220708 (experimental) Maybe it is time to close this bug?
[Bug tree-optimization/106249] New: ICE in check_loop_closed_ssa_def, at tree-ssa-loop-manip.cc:645
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106249 Bug ID: 106249 Summary: ICE in check_loop_closed_ssa_def, at tree-ssa-loop-manip.cc:645 Product: gcc Version: 13.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: asolokha at gmx dot com Target Milestone: --- gfortran 13.0.0 20220710 snapshot (g:0587cef3d7962a8b0f44779589ba2920dd3d71e5) ICEs when compiling the following testcase w/ -O1 -fpeel-loops -funreachable-traps: SUBROUTINE YYPARS(LSTACK,YYPS,YYSTAT) INTEGER LSTACK,YYPS,YYSTAT INTEGER YYXI INTEGER YYEXCA(0:11) YYXI = 1 10 CONTINUE IF (YYPS .GT. LSTACK) CALL ERRORM() 30 CONTINUE IF ((YYEXCA(YYXI) .NE. (-1)) .OR. (YYEXCA(YYXI) .NE. YYSTAT)) THEN YYXI = YYXI + 2 GO TO 30 END IF GO TO 10 RETURN END % gfortran-13.0.0 -O1 -fpeel-loops -funreachable-traps -c apyn3fnn.f during GIMPLE pass: cunroll apyn3fnn.f:1:23: 1 | SUBROUTINE YYPARS(LSTACK,YYPS,YYSTAT) | ^ internal compiler error: in check_loop_closed_ssa_def, at tree-ssa-loop-manip.cc:645 0x771827 check_loop_closed_ssa_def /var/tmp/portage/sys-devel/gcc-13.0.0_p20220710/work/gcc-13-20220710/gcc/tree-ssa-loop-manip.cc:645 0x10e97c4 check_loop_closed_ssa_bb /var/tmp/portage/sys-devel/gcc-13.0.0_p20220710/work/gcc-13-20220710/gcc/tree-ssa-loop-manip.cc:659 0x10eab26 verify_loop_closed_ssa(bool, loop*) /var/tmp/portage/sys-devel/gcc-13.0.0_p20220710/work/gcc-13-20220710/gcc/tree-ssa-loop-manip.cc:695 0x10eab26 verify_loop_closed_ssa(bool, loop*) /var/tmp/portage/sys-devel/gcc-13.0.0_p20220710/work/gcc-13-20220710/gcc/tree-ssa-loop-manip.cc:679 0x10d24d6 tree_unroll_loops_completely /var/tmp/portage/sys-devel/gcc-13.0.0_p20220710/work/gcc-13-20220710/gcc/tree-ssa-loop-ivcanon.cc:1499 0x10d2551 execute /var/tmp/portage/sys-devel/gcc-13.0.0_p20220710/work/gcc-13-20220710/gcc/tree-ssa-loop-ivcanon.cc:1603 0x10d2551 execute /var/tmp/portage/sys-devel/gcc-13.0.0_p20220710/work/gcc-13-20220710/gcc/tree-ssa-loop-ivcanon.cc:1593
[Bug tree-optimization/106249] [13 Regression] ICE in check_loop_closed_ssa_def, at tree-ssa-loop-manip.cc:645
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106249 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |13.0 Summary|ICE in |[13 Regression] ICE in |check_loop_closed_ssa_def, |check_loop_closed_ssa_def, |at |at |tree-ssa-loop-manip.cc:645 |tree-ssa-loop-manip.cc:645
[Bug libstdc++/106248] operator>>std::basic_istream at boundary condition behave differently in different opt levels
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106248 Andrew Pinski changed: What|Removed |Added Keywords||wrong-code --- Comment #1 from Andrew Pinski --- This is interesting because I get the same behavior in clang with LLVM's libc++. Also with -std=c++20 I get the value 0 for all optimization levels. Maybe there is undefined code here ...
[Bug target/106228] [13 regression] r13-1457-g10b502fb78351a causes bootstrap failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106228
Richard Biener changed:
What|Removed |Added
Status|REOPENED|ASSIGNED
--- Comment #13 from Richard Biener ---
OK, it's vect_setup_realignment called from
tree offset = NULL_TREE;
if ((alignment_support_scheme == dr_explicit_realign_optimized
|| alignment_support_scheme == dr_explicit_realign)
&& !compute_in_loop)
{
/* If we have different first_stmt_info, we can't set up realignment
here, since we can't guarantee first_stmt_info DR has been
initialized yet, use first_stmt_info_for_drptr DR by bumping the
distance from first_stmt_info DR instead as below. */
if (!diff_first_stmt_info)
msq = vect_setup_realignment (vinfo,
first_stmt_info, gsi, &realignment_token,
alignment_support_scheme, NULL_TREE,
&at_loop);
The following fixes that ICE.
diff --git a/gcc/tree-vect-data-refs.cc b/gcc/tree-vect-data-refs.cc
index d20a10a1524..53e52cb58cb 100644
--- a/gcc/tree-vect-data-refs.cc
+++ b/gcc/tree-vect-data-refs.cc
@@ -5780,6 +5780,13 @@ vect_setup_realignment (vec_info *vinfo, stmt_vec_info
stmt_info,
if (loop_for_initial_load)
pe = loop_preheader_edge (loop_for_initial_load);
+ tree vuse;
+ gphi *vphi = get_virtual_phi (loop_for_initial_load->header);
+ if (vphi)
+vuse = PHI_ARG_DEF_FROM_EDGE (vphi, pe);
+ else
+vuse = gimple_vuse (gsi_stmt (*gsi));
+
/* 3. For the case of the optimized realignment, create the first vector
load at the loop preheader. */
@@ -5813,6 +5820,7 @@ vect_setup_realignment (vec_info *vinfo, stmt_vec_info
stmt_info,
new_stmt = gimple_build_assign (vec_dest, data_ref);
new_temp = make_ssa_name (vec_dest, new_stmt);
gimple_assign_set_lhs (new_stmt, new_temp);
+ gimple_set_vuse (new_stmt, vuse);
if (pe)
{
new_bb = gsi_insert_on_edge_immediate (pe, new_stmt);
The testsuite FAILs seem to use -mdejagnu-cpu=power7 so likely are the same.
[Bug tree-optimization/106246] [13 Regression] powerpc-darwin9 bootstrap fails after r13-1575-gcf3a120084e946 ICE vect_transform_loops, at tree-vectorizer.cc:1032
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106246 Richard Biener changed: What|Removed |Added Status|NEW |WAITING CC||rguenth at gcc dot gnu.org --- Comment #2 from Richard Biener --- Maybe a duplicate of PR106228. I can't reproduce with the fix for that in the tree. Is there anything besides --target=powerpc-darwin9 to use? Any -mcpu=?
[Bug tree-optimization/106237] [13 regression] serveral tests begin ICEing starting with r13-1575-gcf3a120084e946
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106237 Richard Biener changed: What|Removed |Added Ever confirmed|0 |1 Target Milestone|--- |13.0 Status|UNCONFIRMED |WAITING Last reconfirmed||2022-07-11 --- Comment #1 from Richard Biener --- They seem to all use -mdejagnu-cpu=power7 if I'm looking correctly. Can you re-check after the PR106228 fix is in?
[Bug tree-optimization/106246] [13 Regression] powerpc-darwin9 bootstrap fails after r13-1575-gcf3a120084e946 ICE vect_transform_loops, at tree-vectorizer.cc:1032
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106246 --- Comment #3 from Iain Sandoe --- (In reply to Richard Biener from comment #2) > Maybe a duplicate of PR106228. I can't reproduce with the fix for that in > the tree. Is there anything besides --target=powerpc-darwin9 to use? Any > -mcpu=? there's a build (with debug) on gcc186 (/home/iains/gcc-master/bld-x-ppc-darwin9) if that's any use. I bootstrapped master and then : $ ./gcc/xgcc -v Using built-in specs. COLLECT_GCC=./gcc/xgcc Target: powerpc-apple-darwin9 Configured with: ../src/configure --prefix=/home/iains/gcc-master/gcc-13-0-0 --target=powerpc-apple-darwin9 --build=x86_64-pc-linux-gnu --enable-languages=c,c++ it could be a dup, indeed (I also see the libgfortran fails on the previous rev, and the new vector test case fails).
[Bug tree-optimization/106250] New: [13 Regression] ICE in optab_for_tree_code, at optabs-tree.cc:96
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106250
Bug ID: 106250
Summary: [13 Regression] ICE in optab_for_tree_code, at
optabs-tree.cc:96
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
Target: aarch64-linux-gnu
gcc 13.0.0 20220710 snapshot (g:0587cef3d7962a8b0f44779589ba2920dd3d71e5) ICEs
when compiling the following testcase w/ -O1 -ftree-loop-vectorize:
int
foo (unsigned long int x, int y, int z)
{
int ret = 0;
while (y < 1)
{
x *= 2;
ret = x == z;
z = y;
++y;
}
return ret;
}
% aarch64-linux-gnu-gcc-13.0.0 -O1 -ftree-loop-vectorize -c ljvzdvet.c
during GIMPLE pass: vect
ljvzdvet.c: In function 'foo':
ljvzdvet.c:2:1: internal compiler error: in optab_for_tree_code, at
optabs-tree.cc:96
2 | foo (unsigned long int x, int y, int z)
| ^~~
0x74dfb3 optab_for_tree_code(tree_code, tree_node const*, optab_subtype)
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20220710/work/gcc-13-20220710/gcc/optabs-tree.cc:96
0x139bda4 directly_supported_p(code_helper, tree_node*, optab_subtype)
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20220710/work/gcc-13-20220710/gcc/gimple-match-head.cc:1390
0x11b8174 vectorizable_reduction(_loop_vec_info*, _stmt_vec_info*, _slp_tree*,
_slp_instance*, vec*)
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20220710/work/gcc-13-20220710/gcc/tree-vect-loop.cc:7372
0x11bfd1b vect_analyze_loop_operations
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20220710/work/gcc-13-20220710/gcc/tree-vect-loop.cc:1753
0x11bfd1b vect_analyze_loop_2
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20220710/work/gcc-13-20220710/gcc/tree-vect-loop.cc:2558
0x11c11fb vect_analyze_loop_1
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20220710/work/gcc-13-20220710/gcc/tree-vect-loop.cc:2899
0x11c19d0 vect_analyze_loop(loop*, vec_info_shared*)
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20220710/work/gcc-13-20220710/gcc/tree-vect-loop.cc:3053
0x11f7aa4 try_vectorize_loop_1
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20220710/work/gcc-13-20220710/gcc/tree-vectorizer.cc:1067
0x11f7aa4 try_vectorize_loop
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20220710/work/gcc-13-20220710/gcc/tree-vectorizer.cc:1183
0x11f8304 execute
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-13.0.0_p20220710/work/gcc-13-20220710/gcc/tree-vectorizer.cc:1299
