[Bug c++/112421] New: GCC emits warning potential null dereference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112421
Bug ID: 112421
Summary: GCC emits warning potential null dereference
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jlame646 at gmail dot com
Target Milestone: ---
GCC emits a false positive with the following code.
https://godbolt.org/z/KojKWT4WK
```
std::ifstream t("file.txt");
std::string str((std::istreambuf_iterator(t)),
std::istreambuf_iterator());
```
It says:
```
In file included from
/opt/compiler-explorer/gcc-13.2.0/include/c++/13.2.0/ios:45,
from
/opt/compiler-explorer/gcc-13.2.0/include/c++/13.2.0/ostream:40,
from
/opt/compiler-explorer/gcc-13.2.0/include/c++/13.2.0/iostream:41,
from :1:
In member function 'std::basic_streambuf<_CharT, _Traits>::char_type*
std::basic_streambuf<_CharT, _Traits>::egptr() const [with _CharT = char;
_Traits = std::char_traits]',
inlined from 'std::basic_streambuf<_CharT, _Traits>::int_type
std::basic_streambuf<_CharT, _Traits>::sbumpc() [with _CharT = char; _Traits =
std::char_traits]' at
/opt/compiler-explorer/gcc-13.2.0/include/c++/13.2.0/streambuf:326:49,
inlined from 'std::istreambuf_iterator<_CharT, _Traits>&
std::istreambuf_iterator<_CharT, _Traits>::operator++() [with _CharT = char;
_Traits = std::char_traits]' at
/opt/compiler-explorer/gcc-13.2.0/include/c++/13.2.0/bits/streambuf_iterator.h:173:17,
inlined from 'void std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>::_M_construct(_InIterator, _InIterator, std::input_iterator_tag) [with
_InIterator = std::istreambuf_iterator >; _CharT =
char; _Traits = std::char_traits; _Alloc = std::allocator]' at
/opt/compiler-explorer/gcc-13.2.0/include/c++/13.2.0/bits/basic_string.tcc:178:6,
inlined from 'std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>::basic_string(_InputIterator, _InputIterator, const _Alloc&) [with
_InputIterator = std::istreambuf_iterator >;
= void; _CharT = char; _Traits =
std::char_traits; _Alloc = std::allocator]' at
/opt/compiler-explorer/gcc-13.2.0/include/c++/13.2.0/bits/basic_string.h:753:16,
inlined from 'int main()' at :18:53:
/opt/compiler-explorer/gcc-13.2.0/include/c++/13.2.0/streambuf:495:30: warning:
potential null pointer dereference [-Wnull-dereference]
495 | egptr() const { return _M_in_end; }
```
[Bug c/112420] New: Unexpected vectorization for RISC-V
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112420
Bug ID: 112420
Summary: Unexpected vectorization for RISC-V
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: juzhe.zhong at rivai dot ai
Target Milestone: ---
FAIL: gcc.dg/vect/pr65518.c -flto -ffat-lto-objects scan-tree-dump-times vect
"vectorized 0 loops in function" 2
FAIL: gcc.dg/vect/pr65518.c scan-tree-dump-times vect "vectorized 0 loops in
function" 2
#if VECTOR_BITS > 256
#define NINTS (VECTOR_BITS / 32)
#else
#define NINTS 8
#endif
#define N (NINTS * 2)
#define RESULT (NINTS * (NINTS - 1) / 2 * N + NINTS)
extern void abort (void);
typedef struct giga
{
unsigned int g[N];
} giga;
unsigned long __attribute__((noinline,noclone))
addfst(giga const *gptr, int num)
{
unsigned int retval = 0;
int i;
for (i = 0; i < num; i++)
retval += gptr[i].g[0];
return retval;
}
In "vect" dump, we can see:
single-element interleaving not supported for not adjacent vector loads
However, it still vectorize it.
In https://godbolt.org/z/WfP88sfj4
Shows that ARM SVE will disable vectorization wheras RVV still vectorize it.
[Bug target/112399] RISC-V: Missed AVL propagation for complicate reduction case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112399 JuzheZhong changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from JuzheZhong --- Fixed
[Bug target/112399] RISC-V: Missed AVL propagation for complicate reduction case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112399
--- Comment #1 from CVS Commits ---
The master branch has been updated by Pan Li :
https://gcc.gnu.org/g:f1e084c6c3ef1d1233e35823dacfdf9cee722430
commit r14-5179-gf1e084c6c3ef1d1233e35823dacfdf9cee722430
Author: Juzhe-Zhong
Date: Mon Nov 6 11:34:26 2023 +0800
RISC-V: Enhance AVL propagation for complicate reduction auto-vectorization
I notice we failed to AVL propagate for reduction with more complicate
situation:
double foo (double *__restrict a,
double *__restrict b,
double *__restrict c,
int n)
{
double result = 0;
for (int i = 0; i < n; i++)
result += a[i] * b[i] * c[i];
return result;
}
vsetvli a5,a3,e8,mf8,ta,ma -> should be fused into
e64m1,TU
sllia4,a5,3
vle64.v v3,0(a0)
vle64.v v1,0(a1)
vsetvli a6,zero,e64,m1,ta,ma -> redundant
vfmul.vvv1,v1,v3
vsetvli zero,a5,e64,m1,tu,ma -> redundant
vle64.v v3,0(a2)
vfmacc.vv v2,v1,v3
add a0,a0,a4
add a1,a1,a4
add a2,a2,a4
sub a3,a3,a5
bne a3,zero,.L3
The failed AVL propgation causes redundant AVL/VL togglling.
The root cause as follows:
vsetvl a5, zero
vadd.vv def r136
vsetvl zero, a3, ... TU
vsub.vv (use r136)
We propagate AVL (r136) from 'vsub.vv' into 'vadd.vv' when 'vsub.vv' is TA
policy.
However, it's too restrict so we missed optimization here. We enhance AVL
propation
for TU policy for following situation:
vsetvl a5, zero
vadd.vv def r136
vsetvl zero, a3, ... TU
vsub.vv (use r136, merge != r136)
Note that we should only propagate AVL when merge != r136 for 'vsub.vv'
doesn't
depend on the tail elements.
After this patch:
vsetvli a5,a3,e64,m1,tu,ma
sllia4,a5,3
vle64.v v3,0(a0)
vle64.v v1,0(a1)
vfmul.vvv1,v1,v3
vle64.v v3,0(a2)
vfmacc.vv v2,v3,v1
add a0,a0,a4
add a1,a1,a4
add a2,a2,a4
sub a3,a3,a5
bne a3,zero,.L3
PR target/112399
gcc/ChangeLog:
* config/riscv/riscv-avlprop.cc
(pass_avlprop::get_vlmax_ta_preferred_avl): Enhance AVL
propagation.
* config/riscv/t-riscv: Add new include.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/vsetvl/imm_switch-2.c: Adapt test.
* gcc.target/riscv/rvv/autovec/pr112399.c: New test.
[Bug tree-optimization/105558] simple 8-bit integer calculation fails with -O3 / march=core-avx2 on some gfortran 8/9/10 versions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105558 --- Comment #8 from Thomas Koenig --- (In reply to Andrew Pinski from comment #6) > Would be interesting to find what patch broke this and what patch fixed the > -mtune=generic case. It is not easy bisecting with old compilers - compilation issues keep coming up on more modern systems, and sometimes newer compilers do not compile older compilers...
[Bug tree-optimization/112419] [14 Regression] gcc.dg/Wnonnull-4.c excess error for 32-bit targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112419 uecker at gcc dot gnu.org changed: What|Removed |Added Ever confirmed|0 |1 See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=98541 Last reconfirmed||2023-11-07 Status|UNCONFIRMED |NEW --- Comment #1 from uecker at gcc dot gnu.org --- Confirmed. I think adding -Wstringop-overflow= to the test might fix it. It is just some test which is wrong for 32 bit targets and somehow this problems appeared now due to an unrelated change. I will try this and submit a patch.
[Bug tree-optimization/112419] New: [14 Regression] gcc.dg/Wnonnull-4.c excess error for 32-bit targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112419 Bug ID: 112419 Summary: [14 Regression] gcc.dg/Wnonnull-4.c excess error for 32-bit targets Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: hp at gcc dot gnu.org CC: uecker at gcc dot gnu.org Target Milestone: --- This test started failing with r14-5115-g6e9ee44d96e5 thus: Running /x/gcc/testsuite/gcc.dg/dg.exp ... FAIL: gcc.dg/Wnonnull-4.c (test for excess errors) In gcc.log (after all PASS lines): FAIL: gcc.dg/Wnonnull-4.c (test for excess errors) Excess errors: /o/gcc/gcc/testsuite/gcc.dg/Wnonnull-4.c:144:3: warning: 'fda_n_5' specified size 4294967256 exceeds maximum object size 2147483647 [-Wstringop-overflow=] The same happen for all 32-bit targets (including 64-bit targets when testing with a "-m32"-type option), according to posts to gcc-testresults@ around this commit.
[Bug middle-end/112382] `(a) != a` where a is known to have one known bit set is not optimized to ((~b)>>shift) & 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112382 --- Comment #2 from Andrew Pinski --- (In reply to Richard Biener from comment #1) > Note ((~b)>>shift) & 1 is two more GIMPLE ops than (a) != a so I'd > expect the reverse transform on GIMPLE and maybe target specific expansion > tweaks (or combine at work). Right, that is why I put the component as middle-end. Specifically because I think `(a) != a` should be the Canonical form and only expanded either in isel or expand .
[Bug tree-optimization/112402] [11/12/13/14 Regression] Path splitting causes if-conversion miss
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112402 --- Comment #2 from Andrew Pinski --- The orginal threads about patch splitting: https://gcc.gnu.org/legacy-ml/gcc/2015-03/msg00057.html https://gcc.gnu.org/pipermail/gcc/2015-May/217495.html > or axe path splitting or move it to RTL Jeff had a similar idea back in 2016 (I would assume while he was looking into PR 68541): https://gcc.gnu.org/pipermail/gcc-patches/2016-February/441651.html : ``` And if that's the case, then we may really be looking at something that belongs at the RTL level rather than at the tree/gimple level. Sadly, it's harder to do things like duplicate blocks at the RTL level. ``` and also mentioned in (which was the heustrics added to fix PR 68541): https://gcc.gnu.org/pipermail/gcc-patches/2016-February/441841.html Maybe this is something for GCC 15 ... to move to this to RTL right during the loop optimization phase after pass_rtl_doloop. There is still a CSE and DSE/DCE passes afterwards too.
[Bug middle-end/110015] openjpeg is slower when built with gcc13 compared to clang16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110015 --- Comment #9 from Andrew Pinski --- I should note that PR 112416 is not needed to vectorize the loop, though it would improve code.
[Bug middle-end/110015] openjpeg is slower when built with gcc13 compared to clang16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110015 Andrew Pinski changed: What|Removed |Added Depends on||112418 --- Comment #8 from Andrew Pinski --- (In reply to Andrew Pinski from comment #5) > After fixing PR 112324 (and a secondary patch to phiopt to do > factor_out_conditional_operation for all phi nodes rather than just a single > one) we still miss the abs detection: Filed PR 112418 for the secondary patch. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112418 [Bug 112418] factor_out_conditional_operation could be done for more phis
[Bug tree-optimization/112418] factor_out_conditional_operation could be done for more phis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112418 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2023-11-07 Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Mine.
[Bug tree-optimization/112418] New: factor_out_conditional_operation could be done for more phis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112418
Bug ID: 112418
Summary: factor_out_conditional_operation could be done for
more phis
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: tree-optimization
Assignee: pinskia at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Depends on: 112324
Target Milestone: ---
Take:
```
int f(int a, int b, int d)
{
int c;
if (a < 0)
{
c = d > 0 ? d : -d;
a = -a;
}
else
{
c = d > 0 ? d : -d;
a = a;
}
return a + c;
}
```
We should be able to optimize this to just:
```
_11 = ABS_EXPR ;
c_2 = ABS_EXPR ;
_9 = c_2 + _11;
```
in phiopt1
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112324
[Bug 112324] phiopt fail to recog if (b < 0) max = MAX(-b, max); else max = MAX
(b, max) into max = MAX (ABS(b), max)
[Bug rtl-optimization/112417] expand_builtin_return shoud check alignment for the memory reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112417 HaoChen Gui changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |guihaoc at gcc dot gnu.org CC||guihaoc at gcc dot gnu.org --- Comment #1 from HaoChen Gui --- Created attachment 56521 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56521=edit proposed patch
[Bug target/111907] ICE: in curr_insn_transform, at lra-constraints.cc:4294 unable to generate reloads for: {*andnottf3} with -mavx512f -mno-evex512
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111907 --- Comment #6 from Haochen Jiang --- Proposed patch: https://gcc.gnu.org/pipermail/gcc-patches/2023-November/635410.html
[Bug rtl-optimization/112417] New: expand_builtin_return shoud check alignment for the memory reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112417
Bug ID: 112417
Summary: expand_builtin_return shoud check alignment for the
memory reference
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: guihaoc at gcc dot gnu.org
Target Milestone: ---
//test.c
void * foo (void * p)
{
if (p)
__builtin_return (p);
}
when compiling it with mno-vsx on ppc64, it generates 16-byte aligned vector
load instructions for the memory reference which is 1-byte aligned.
(insn 28 27 30 4 (set (reg:V4SF 66 2)
(mem:V4SF (plus:DI (reg/v/f:DI 118 [ p ])
(reg:DI 120)) [0 S16 A8])) "test4.c":4:5 1676
{*altivec_movv4sf}
It's unsafe as 16-byte aligned vector load instuction does an "AND -16" on the
memory address by itself. I think expand_builtin_return should check the
alignment and call misaligned_mem_ref expand to load the memory reference.
[Bug testsuite/112340] [14 regression] assembler instruction counts off for gcc.target/powerpc/pr106550_1.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112340 Kewen Lin changed: What|Removed |Added Last reconfirmed||2023-11-07 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |guojiufu at gcc dot gnu.org Ever confirmed|0 |1 CC||linkw at gcc dot gnu.org --- Comment #1 from Kewen Lin --- test issue, assigning to Jeff as he already has a patch.
[Bug middle-end/110015] openjpeg is slower when built with gcc13 compared to clang16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110015 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Severity|normal |enhancement Ever confirmed|0 |1 Last reconfirmed||2023-11-07 --- Comment #7 from Andrew Pinski --- Confirmed.
[Bug middle-end/110015] openjpeg is slower when built with gcc13 compared to clang16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110015 Andrew Pinski changed: What|Removed |Added Depends on||112416 --- Comment #6 from Andrew Pinski --- (In reply to Andrew Pinski from comment #5) > > `a < 0 ? (int)-(unsigned)a : a` needs to detected to be `(int)ABSU_EXPR`. Filed PR 112416 for that. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112416 [Bug 112416] absu is not detected
[Bug tree-optimization/112416] New: absu is not detected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112416
Bug ID: 112416
Summary: absu is not detected
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Blocks: 112324
Target Milestone: ---
Target: aarch64
Another case where ABSU is not detected:
```
static inline
int f(int a)
{
return (a<0)?-(unsigned)a : a;
}
void f1(int *a, int n)
{
for(int i = 0; i < n; i++)
a[i] = f(a[i]);
}
static inline
int g(int a)
{
return (a<0)?-a : a;
}
void g1(int *a, int n)
{
for(int i = 0; i < n; i++)
a[i] = g(a[i]);
}
```
As you can see abs is detected for g/g1 but not for f/f1.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112324
[Bug 112324] phiopt fail to recog if (b < 0) max = MAX(-b, max); else max = MAX
(b, max) into max = MAX (ABS(b), max)
[Bug middle-end/110015] openjpeg is slower when built with gcc13 compared to clang16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110015 --- Comment #5 from Andrew Pinski --- After fixing PR 112324 (and a secondary patch to phiopt to do factor_out_conditional_operation for all phi nodes rather than just a single one) we still miss the abs detection: _34 = tmp_24 < 0; _55 = (unsigned int) tmp_24; _56 = -_55; _1 = (intD.6) _56; _30 = _1 | -2147483648; iftmp.0_26 = (unsigned intD.9) _30; # .MEM_27 = VDEF <.MEM_46> # USE = anything # CLB = anything .MASK_STORE (datap_43, 8B, _34, iftmp.0_26); # RANGE [irange] int [0, +INF] _25 = _34 ? _1 : tmp_24; basically `a < 0 ? (int)-(unsigned)a : a` needs to detected to be `(int)ABSU_EXPR`.
[Bug libbacktrace/112263] [C++23] std::stacktrace does not identify symbols in shared library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112263 --- Comment #17 from Jonathan Wakely --- Thanks, Ian!
[Bug rtl-optimization/112415] [14 regression] Python 3.11 miscompiled on HPPA with new RTL fold mem offset pass, since r14-4664-g04c9cf5c786b94
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415 --- Comment #10 from dave.anglin at bell dot net --- On 2023-11-06 5:49 p.m., sjames at gcc dot gnu.org wrote: > Program received signal SIGSEGV, Segmentation fault. > 0x412083f0 in _PyST_GetSymbol (name=0xf9a34a00, ste=) at > Python/symtable.c:396 > 396 PyObject *v = PyDict_GetItemWithError(ste->ste_symbols, name); > (gdb) x/20i $pc > => 0x412083f0 <_PyST_GetScope+20>: ldw c(r26),r26 r26=0x34, so the ldw will fault. It appears r26 and r25 have been exchanged in the code prior to <_PyST_GetScope+20>. In any case, the problem is with the ste argument passed to _PyST_GetSymbol.
[Bug libbacktrace/112263] [C++23] std::stacktrace does not identify symbols in shared library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112263 Ian Lance Taylor changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #16 from Ian Lance Taylor --- Fix committed.
[Bug libbacktrace/111315] libstdc++ stacktrace testsuite failures with --enable-default-pie
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111315 --- Comment #10 from CVS Commits --- The releases/gcc-12 branch has been updated by Ian Lance Taylor : https://gcc.gnu.org/g:56909c9d4842925749cd9e061ef4afa0501f85e9 commit r12-9961-g56909c9d4842925749cd9e061ef4afa0501f85e9 Author: Ian Lance Taylor Date: Mon Nov 6 15:12:41 2023 -0800 libstdc++: use -D_GNU_SOURCE when building libbacktrace PR libbacktrace/111315 PR libbacktrace/112263 * acinclude.m4: Set -D_GNU_SOURCE in BACKTRACE_CPPFLAGS and when grepping link.h for dl_iterate_phdr. * configure: Regenerate.
[Bug libbacktrace/112263] [C++23] std::stacktrace does not identify symbols in shared library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112263 --- Comment #15 from CVS Commits --- The releases/gcc-12 branch has been updated by Ian Lance Taylor : https://gcc.gnu.org/g:56909c9d4842925749cd9e061ef4afa0501f85e9 commit r12-9961-g56909c9d4842925749cd9e061ef4afa0501f85e9 Author: Ian Lance Taylor Date: Mon Nov 6 15:12:41 2023 -0800 libstdc++: use -D_GNU_SOURCE when building libbacktrace PR libbacktrace/111315 PR libbacktrace/112263 * acinclude.m4: Set -D_GNU_SOURCE in BACKTRACE_CPPFLAGS and when grepping link.h for dl_iterate_phdr. * configure: Regenerate.
[Bug libbacktrace/112263] [C++23] std::stacktrace does not identify symbols in shared library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112263 --- Comment #14 from CVS Commits --- The releases/gcc-13 branch has been updated by Ian Lance Taylor : https://gcc.gnu.org/g:8484e3479fe80aebdc4a2406473aef906055b4f8 commit r13-8006-g8484e3479fe80aebdc4a2406473aef906055b4f8 Author: Ian Lance Taylor Date: Mon Nov 6 15:12:05 2023 -0800 libstdc++: use -D_GNU_SOURCE when building libbacktrace PR libbacktrace/111315 PR libbacktrace/112263 * acinclude.m4: Set -D_GNU_SOURCE in BACKTRACE_CPPFLAGS and when grepping link.h for dl_iterate_phdr. * configure: Regenerate.
[Bug libbacktrace/111315] libstdc++ stacktrace testsuite failures with --enable-default-pie
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111315 --- Comment #9 from CVS Commits --- The releases/gcc-13 branch has been updated by Ian Lance Taylor : https://gcc.gnu.org/g:8484e3479fe80aebdc4a2406473aef906055b4f8 commit r13-8006-g8484e3479fe80aebdc4a2406473aef906055b4f8 Author: Ian Lance Taylor Date: Mon Nov 6 15:12:05 2023 -0800 libstdc++: use -D_GNU_SOURCE when building libbacktrace PR libbacktrace/111315 PR libbacktrace/112263 * acinclude.m4: Set -D_GNU_SOURCE in BACKTRACE_CPPFLAGS and when grepping link.h for dl_iterate_phdr. * configure: Regenerate.
[Bug libbacktrace/112263] [C++23] std::stacktrace does not identify symbols in shared library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112263 --- Comment #13 from CVS Commits --- The master branch has been updated by Ian Lance Taylor : https://gcc.gnu.org/g:2b64e4a54042fb8f75f1c1429eb1c13afb9fa118 commit r14-5173-g2b64e4a54042fb8f75f1c1429eb1c13afb9fa118 Author: Ian Lance Taylor Date: Mon Nov 6 15:09:18 2023 -0800 libstdc++: use -D_GNU_SOURCE when building libbacktrace PR libbacktrace/111315 PR libbacktrace/112263 * acinclude.m4: Set -D_GNU_SOURCE in BACKTRACE_CPPFLAGS and when grepping link.h for dl_iterate_phdr. * configure: Regenerate.
[Bug libbacktrace/111315] libstdc++ stacktrace testsuite failures with --enable-default-pie
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111315 --- Comment #8 from CVS Commits --- The master branch has been updated by Ian Lance Taylor : https://gcc.gnu.org/g:2b64e4a54042fb8f75f1c1429eb1c13afb9fa118 commit r14-5173-g2b64e4a54042fb8f75f1c1429eb1c13afb9fa118 Author: Ian Lance Taylor Date: Mon Nov 6 15:09:18 2023 -0800 libstdc++: use -D_GNU_SOURCE when building libbacktrace PR libbacktrace/111315 PR libbacktrace/112263 * acinclude.m4: Set -D_GNU_SOURCE in BACKTRACE_CPPFLAGS and when grepping link.h for dl_iterate_phdr. * configure: Regenerate.
[Bug rtl-optimization/112415] [14 regression] Python 3.11 miscompiled on HPPA with new RTL fold mem offset pass, since r14-4664-g04c9cf5c786b94
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415 --- Comment #9 from Sam James --- I think the key object is Python/compile.o, but not certain yet.
[Bug rtl-optimization/112415] [14 regression] Python 3.11 miscompiled on HPPA with new RTL fold mem offset pass, since r14-4664-g04c9cf5c786b94
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415 --- Comment #8 from Sam James --- (In reply to Jeffrey A. Law from comment #6) Program received signal SIGSEGV, Segmentation fault. 0x412083f0 in _PyST_GetSymbol (name=0xf9a34a00, ste=) at Python/symtable.c:396 396 PyObject *v = PyDict_GetItemWithError(ste->ste_symbols, name); (gdb) x/20i $pc => 0x412083f0 <_PyST_GetScope+20>: ldw c(r26),r26 0x412083f4 <_PyST_GetScope+24>: movb,= ret0,r26,0x41208414 <_PyST_GetScope+56> 0x412083f8 <_PyST_GetScope+28>: copy r4,r19 0x412083fc <_PyST_GetScope+32>: b,l 0x410d6900 ,rp 0x41208400 <_PyST_GetScope+36>: nop 0x41208404 <_PyST_GetScope+40>: ldw -54(sp),rp 0x41208408 <_PyST_GetScope+44>: extrw,u ret0,20,4,ret0 0x4120840c <_PyST_GetScope+48>: bve (rp) 0x41208410 <_PyST_GetScope+52>: ldw,mb -40(sp),r4 0x41208414 <_PyST_GetScope+56>: copy r26,ret0 0x41208418 <_PyST_GetScope+60>: ldw -54(sp),rp 0x4120841c <_PyST_GetScope+64>: bve (rp) 0x41208420 <_PyST_GetScope+68>: ldw,mb -40(sp),r4 0x41208424 <_Py_SymtableStringObjectFlags>: stw rp,-14(sp) 0x41208428 <_Py_SymtableStringObjectFlags+4>:stw,ma r8,80(sp) 0x4120842c <_Py_SymtableStringObjectFlags+8>:copy r23,r8 0x41208430 <_Py_SymtableStringObjectFlags+12>: stw r7,-7c(sp) 0x41208434 <_Py_SymtableStringObjectFlags+16>: copy r24,r7 0x41208438 <_Py_SymtableStringObjectFlags+20>: stw r6,-78(sp) 0x4120843c <_Py_SymtableStringObjectFlags+24>: copy r25,r6 (gdb) (gdb) i r flags r1 0x411bc688 1092339336 rp 0x412083f7 1092649975 r3 0x1 1 r4 0x4136c000 1094107136 r5 0xf9a34a00 4188228096 r6 0x8d141 r7 0xf7b03b88 4155521928 r8 0xf7b03ba8 4155521960 r9 0xf9953b68 4187306856 r100x0 0 r110x8e142 r120x414e1820 1095637024 r130x414e4490 1095648400 r140xf9a76498 4188497048 r150x1 1 r160xf99bb5e8 4187731432 r170xf9ae11b4 4188934580 r180xf99e3b68 4187896680 r190x4136c000 1094107136 r200x411bc7f0 1092339696 r210x41450268 1095041640 r220x8d141 r230x1 1 r240x1 1 r250xf9a34a00 4188228096 r260x3452 dp 0x4136c000 1094107136 ret0 0xf9964020 4187373600 ret1 0x8d141 sp 0xf7b04080 4155523200 r310x1 1 sar0x3d61 pcoqh 0x412083f3 1092649971 pcsqh pcoqt 0x410e4c0f 1091456015 pcsqt eiem iir isr ior ipsw 0xeff0f 982799 goto sr4 sr0 sr1 sr2 sr3 sr5 sr6 sr7 cr0 cr8 cr9 ccr cr12 cr13 cr24 cr25 cr26 0xeff0f 982799 mpsfu_high 0xf7afa500 4155483392 mpsfu_low mpsfu_ovflo pad fpsr fpe1 fpe2 fpe3 fpe4 fpe5 fpe6 fpe7 (gdb)
[Bug rtl-optimization/112415] [14 regression] Python 3.11 miscompiled on HPPA with new RTL fold mem offset pass, since r14-4664-g04c9cf5c786b94
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415 --- Comment #7 from dave.anglin at bell dot net --- On 2023-11-06 5:20 p.m., law at gcc dot gnu.org wrote: > The biggest concern I'd have with f-m-o on the PA would be the > implicit segment selection that happens on the base register -- but it would > only be an issue if we are faulting on an unscaled indexed addressing mode and > only if the linux-gnu port was actually putting different values into the > space > registers. The linux-gnu port does not put different values into the space resisters.
[Bug rtl-optimization/112415] [14 regression] Python 3.11 miscompiled on HPPA with new RTL fold mem offset pass, since r14-4664-g04c9cf5c786b94
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415 --- Comment #6 from Jeffrey A. Law --- Do we have assembly code around the faulting point (x/20i $pc) and a register dump (i r)? The biggest concern I'd have with f-m-o on the PA would be the implicit segment selection that happens on the base register -- but it would only be an issue if we are faulting on an unscaled indexed addressing mode and only if the linux-gnu port was actually putting different values into the space registers. WRT testing -- we did test this on hppa1.1-linux-gnu. Just a bootstrap and regression test of the compiler itself.
[Bug rtl-optimization/112415] [14 regression] Python 3.11 miscompiled on HPPA with new RTL fold mem offset pass, since r14-4664-g04c9cf5c786b94
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415 Sam James changed: What|Removed |Added CC||law at gcc dot gnu.org --- Comment #5 from Sam James --- Built with 14.0.0 20231029. * https://dev.gentoo.org/~sam/bugs/gcc/gcc-python-hppa/cpython-3.11.6-good.tar.xz * https://dev.gentoo.org/~sam/bugs/gcc/gcc-python-hppa/cpython-3.11.6-bad.tar.xz
[Bug rtl-optimization/112415] [14 regression] Python 3.11 miscompiled on HPPA with new RTL fold mem offset pass, since r14-4664-g04c9cf5c786b94
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415 --- Comment #4 from Sam James --- Created attachment 56520 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56520=edit list_of_differing_files.txt
[Bug target/111600] [14 Regression] RISC-V bootstrap time regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111600 --- Comment #32 from JuzheZhong --- 26% time reduction seems not enough. Maybe we still need to optimize MD patterns to fix this issue ? But I have no idea to optimize it since I already tried my best to reduce them. According to RVV intrinsic doc: https://github.com/riscv-non-isa/rvv-intrinsic-doc we have these 6 types variant intrinsics: __vop __vop_tu __vop_mu __vop_tum __vop_tumu __vop_m I have fused them into same pattern (which makes the pattern so complicated) to avoid explosion of MD patterns (otherwise, it will explode 6 times if we dedicate each type intrinsic one MD pattern). But seems it's still an issue. And I have no idea how to reduce them.
[Bug tree-optimization/106511] [13/14 Regression] New -Werror=maybe-uninitialized since r13-1268-g8c99e307b20c502e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106511 --- Comment #7 from Andrew Macleod --- (In reply to Richard Biener from comment #2) > VRP could use max_stmt_executions here (note it doesn't properly handle loop > nests so the name is somewhat misleading) Given some arbitrary statement S, how do I find the relevant loop pointer to pass to max_stmt_executions?I don't suppose there is a generic version which will take care of that lookup? This seems like something the phi analyzer could easily use to calculate the number of times the modifier statement triggers when we have loop PHIs and some other PHI in parallel.. if I can easily ask how many times stmt S is executed...
[Bug rtl-optimization/112415] [14 regression] Python 3.11 miscompiled on HPPA with new RTL fold mem offset pass, since r14-4664-g04c9cf5c786b94
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415 --- Comment #3 from dave.anglin at bell dot net --- On 2023-11-06 4:00 p.m., sjames at gcc dot gnu.org wrote: > Program received signal SIGSEGV, Segmentation fault. > 0x412083fc in _PyST_GetSymbol (name=0xf9a33a60, ste=) at > Python/symtable.c:396 > 396 PyObject *v = PyDict_GetItemWithError(ste->ste_symbols, name); > (gdb) bt > #0 0x412083fc in _PyST_GetSymbol (name=0xf9a33a60, ste=) at > Python/symtable.c:396 > #1 _PyST_GetScope (ste=, name=0xf9a33a60) at > Python/symtable.c:406 Probably, ste is NULL or in page 0, and it's symtable.c that's miscompiled. There's not a lot of testing of gcc-14 on hppa yet.
[Bug rtl-optimization/112415] [14 regression] Python 3.11 miscompiled on HPPA with new RTL fold mem offset pass, since r14-4664-g04c9cf5c786b94
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415 Andrew Pinski changed: What|Removed |Added Keywords||wrong-code Target Milestone|--- |14.0 Target||hppa2.0-unknown-linux-gnu
[Bug rtl-optimization/112415] [14 regression] Python 3.11 miscompiled on HPPA with new RTL fold mem offset pass, since r14-4664-g04c9cf5c786b94
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415 --- Comment #2 from Sam James --- I'll grab a bad vs good build directory next and upload both, and then try see which objects differ. Dave, can you reproduce?
[Bug rtl-optimization/112415] [14 regression] Python 3.11 miscompiled on HPPA with new RTL fold mem offset pass, since r14-4664-g04c9cf5c786b94
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415 Sam James changed: What|Removed |Added Summary|[14 regression] Python 3.11 |[14 regression] Python 3.11 |miscompiled with new RTL|miscompiled on HPPA with |fold mem offset pass, since |new RTL fold mem offset |r14-4664-g04c9cf5c786b94|pass, since ||r14-4664-g04c9cf5c786b94 --- Comment #1 from Sam James --- Backtrace from the crashing Python: ``` (gdb) r Starting program: /var/tmp/portage/dev-lang/python-3.11.6/work/Python-3.11.6/_bootstrap_python ./Tools/scripts/deepfreeze.py Python/frozen_modules/importlib._bootstrap.h:importlib._bootstrap Python/frozen_modules/importlib._bootstrap_external.h:importlib._bootstrap_external Python/frozen_modules/zipimport.h:zipimport Python/frozen_modules/abc.h:abc Python/frozen_modules/codecs.h:codecs Python/frozen_modules/io.h:io Python/frozen_modules/_collections_abc.h:_collections_abc Python/frozen_modules/_sitebuiltins.h:_sitebuiltins Python/frozen_modules/genericpath.h:genericpath Python/frozen_modules/ntpath.h:ntpath Python/frozen_modules/posixpath.h:posixpath Python/frozen_modules/os.h:os Python/frozen_modules/site.h:site Python/frozen_modules/stat.h:stat Python/frozen_modules/importlib.util.h:importlib.util Python/frozen_modules/importlib.machinery.h:importlib.machinery Python/frozen_modules/runpy.h:runpy Python/frozen_modules/__hello__.h:__hello__ Python/frozen_modules/__phello__.h:__phello__ Python/frozen_modules/__phello__.ham.h:__phello__.ham Python/frozen_modules/__phello__.ham.eggs.h:__phello__.ham.eggs Python/frozen_modules/__phello__.spam.h:__phello__.spam Python/frozen_modules/frozen_only.h:frozen_only -o Python/deepfreeze/deepfreeze.c warning: File "/usr/lib/libthread_db.so.1" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load". To enable execution of this file add add-auto-load-safe-path /usr/lib/libthread_db.so.1 line to your configuration file "/root/.config/gdb/gdbinit". To completely disable this security protection add set auto-load safe-path / line to your configuration file "/root/.config/gdb/gdbinit". For more information about this security protection see the "Auto-loading safe path" section in the GDB manual. E.g., run from the shell: info "(gdb)Auto-loading safe path" warning: Unable to find libthread_db matching inferior's thread library, thread debugging will not be available. Program received signal SIGSEGV, Segmentation fault. 0x412083fc in _PyST_GetSymbol (name=0xf9a33a60, ste=) at Python/symtable.c:396 396 PyObject *v = PyDict_GetItemWithError(ste->ste_symbols, name); (gdb) bt #0 0x412083fc in _PyST_GetSymbol (name=0xf9a33a60, ste=) at Python/symtable.c:396 #1 _PyST_GetScope (ste=, name=0xf9a33a60) at Python/symtable.c:406 #2 0x411bb8f8 in compiler_nameop (c=0xf7b03b88, name=, ctx=Load) at Python/compile.c:4274 #3 0x411be074 in compiler_visit_expr (c=0x1, e=) at Python/compile.c:5969 #4 0x411bcc88 in compiler_visit_expr1 (c=0xf7b03b88, e=0x1) at Python/compile.c:5915 #5 0x411be074 in compiler_visit_expr (c=0x1, e=) at Python/compile.c:5969 #6 0x411bceac in compiler_call (e=0x1, c=0xf7b03b88) at Python/compile.c:4952 #7 compiler_visit_expr1 (c=0xf7b03b88, e=0x1) at Python/compile.c:5905 #8 0x411c1f34 in compiler_visit_expr (e=, c=0xf9a33a60) at Python/compile.c:5969 #9 compiler_decorators (decos=0x8d, c=0xf9a33a60) at Python/compile.c:2327 #10 compiler_class (c=0xf9a33a60, s=0x414e4490) at Python/compile.c:2702 #11 0x411c566c in compiler_body (c=0xf7b03b88, stmts=0xf9a33a60) at Python/compile.c:2180 #12 0x411c7e98 in compiler_mod (mod=0xf7b03b88, c=0x0) at Python/compile.c:2197 #13 _PyAST_Compile (mod=0xf7b03b88, filename=0x8d, flags=, optimize=, arena=) at Python/compile.c:581 #14 0x411fe7b8 in Py_CompileStringObject (str=0xf7b03b88 "\371\240\277\220\371\236\353`\371\257\221\260\367\260:t", filename=0x8d, start=-139445336, flags=0xf9a33a60, optimize=) at Python/pythonrun.c:1799 #15 0x4119c334 in builtin_compile_impl (module=, feature_version=, optimize=, dont_inherit=, flags=, mode=, filename=0xf998db68, source=0x8d) at Python/bltinmodule.c:831 #16 builtin_compile (module=, args=, nargs=, kwnames=) at Python/clinic/bltinmodule.c.h:328 #17 0x410f3ae4 in cfunction_vectorcall_FASTCALL_KEYWORDS (func=0xf9a33a60, args=0x8d, nargsf=, kwnames=) at ./Include/cpython/methodobject.h:52 #18 0x4109fa88 in _PyVectorcall_Call (tstate=0xf7b03b88, func=, callable=0xf9a33a60, tuple=, kwargs=) at Objects/call.c:257 #19 0x4109fd28 in _PyObject_Call (tstate=0xf9a33a60, callable=0x1, args=0xf7b03ba8, kwargs=0x8d) at Objects/call.c:328 #20 0x4109fdb8 in PyObject_Call () at Objects/call.c:352 #21 0x411a47c8 in do_call_core (tstate=0x8d, func=0x1, callargs=0xf9a33a60,
[Bug rtl-optimization/112415] New: [14 regression] Python 3.11 miscompiled with new RTL fold mem offset pass, since r14-4664-g04c9cf5c786b94
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
Bug ID: 112415
Summary: [14 regression] Python 3.11 miscompiled with new RTL
fold mem offset pass, since r14-4664-g04c9cf5c786b94
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: sjames at gcc dot gnu.org
CC: danglin at gcc dot gnu.org, manolis.tsamis at vrull dot eu
Target Milestone: ---
I've bisected this twice and come to r14-4664-g04c9cf5c786b94 ('Implement new
RTL optimizations pass: fold-mem-offsets'). -fno-fold-mem-offsets makes things
work.
Python 3.11.6 fails to build on HPPA since that commit with the built-Python
segfaulting during the build.
```
hppa2.0-unknown-linux-gnu-gcc -c -Wsign-compare -DNDEBUG -O2 -pipe
-march=2.0 -fdiagnostics-color=always -frecord-gcc-switches -ggdb3 -fwrapv
-std=c11 -Wextra -Wno-unused-parameter -Wno-missing-field-init
ializers -Wstrict-prototypes -Werror=implicit-function-declaration
-fvisibility=hidden -I./Include/internal -I. -I./Include
-I/usr/include/ncursesw -fPIC -DPy_BUILD_CORE -o Python/frozen.o
Python/frozen.c
./_bootstrap_python ./Tools/scripts/deepfreeze.py \
Python/frozen_modules/importlib._bootstrap.h:importlib._bootstrap \
Python/frozen_modules/importlib._bootstrap_external.h:importlib._bootstrap_external
\
Python/frozen_modules/zipimport.h:zipimport \
Python/frozen_modules/abc.h:abc \
Python/frozen_modules/codecs.h:codecs \
Python/frozen_modules/io.h:io \
Python/frozen_modules/_collections_abc.h:_collections_abc \
Python/frozen_modules/_sitebuiltins.h:_sitebuiltins \
Python/frozen_modules/genericpath.h:genericpath \
Python/frozen_modules/ntpath.h:ntpath \
Python/frozen_modules/posixpath.h:posixpath \
Python/frozen_modules/os.h:os \
Python/frozen_modules/site.h:site \
Python/frozen_modules/stat.h:stat \
Python/frozen_modules/importlib.util.h:importlib.util \
Python/frozen_modules/importlib.machinery.h:importlib.machinery \
Python/frozen_modules/runpy.h:runpy \
Python/frozen_modules/__hello__.h:__hello__ \
Python/frozen_modules/__phello__.h:__phello__ \
Python/frozen_modules/__phello__.ham.h:__phello__.ham \
Python/frozen_modules/__phello__.ham.eggs.h:__phello__.ham.eggs \
Python/frozen_modules/__phello__.spam.h:__phello__.spam \
Python/frozen_modules/frozen_only.h:frozen_only \
-o Python/deepfreeze/deepfreeze.c
make: *** [Makefile:1298: Python/deepfreeze/deepfreeze.c] Segmentation fault
(core dumped)
make: *** Waiting for unfinished jobs
hppa2.0-unknown-linux-gnu-gcc -c -I./Modules/_decimal/libmpdec -DCONFIG_32=1
-DANSI=1 -Wsign-compare -DNDEBUG -O2 -pipe -march=2.0
-fdiagnostics-color=always -frecord-gcc-switches -ggdb3 -fwrapv -std=c11
-Wextra -Wno-unused-parameter -Wno-missing-field-initializers
-Wstrict-prototypes -Werror=implicit-function-declaration -fvisibility=hidden
-I./Include/internal -I. -I./Include -I/usr/include/ncursesw -fPIC -fPIC -o
Modules/_decimal/libmpdec/mpdecimal.o ./Modules/_decimal/libmpdec/mpdecimal.c
* ERROR: dev-lang/python-3.11.6::gentoo failed (compile phase):
* emake failed
```
[Bug fortran/104819] Reject NULL without MOLD as actual to an assumed-rank dummy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104819 --- Comment #3 from anlauf at gcc dot gnu.org --- Created attachment 56519 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56519=edit Partial patch This patch adjusts the checking so that nested NULL()s are accepted, tries to implement Interp J3/22-146 when passing NULL() to an assumed-rank dummy, and catches NULL() passed to an assumed-length dummy. TODO: fix handling of NULL(mold) in gfc_conv_procedure_call.
[Bug target/112413] Wrong switch jump table offset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112413
--- Comment #3 from Vincent Riviere ---
(In reply to Andrew Pinski from comment #1)
> I don't see any issues with the output of gcc. Are you sure this is not a
> binutils gnu as issue where the offsets are done incorrectly there.
Yes, I'm sure it's a gcc bug.
With the testcase I initially provided, by chance it's the favourable case.
But if I artificially add a misalignment with a nop, for example, the wrong
result appears:
$ cat swi2.c
int g;
void f(int i)
{
asm("nop");
switch (i)
{
case 0: g = 6082; break;
case 1: g = 9332; break;
case 2: g = 5642; break;
case 3: g = 1423; break;
case 4: g = 2152; break;
case 5: g = 6779; break;
case 6: g = 7074; break;
case 7: g = 8280; break;
}
}
$ m68k-linux-gcc -Os -c swi2.c -mlong-jump-table-offsets -malign-int
$ m68k-linux-objdump -d swi2.o
swi2.o:file format elf32-m68k
Disassembly of section .text:
:
0: 202f 0004 movel %sp@(4),%d0
4: 4e71nop
6: 7207moveq #7,%d1
8: b280cmpl %d0,%d1
a: 6536bcss 42
c: e588lsll #2,%d0
e: 203b 0808 movel %pc@(18 ,%d0:l),%d0 |right offset
12: 4efb 0802 jmp %pc@(16 ,%d0:l) |wrong offset
16: 284cmoveal %a4,%a4 |harmful filler
18: 0020 orib #32,%d0
1c: 002c orib #44,%d0
20: 0038 orib #56,%d0
See that:
- actual jump table starts at offset 0x18
- at offset 0x16, a useless "moveal %a4,%a4" instruction is inserted as filler
- at offset 0xe, offset 0x18 is used appropriately for label .L4. So the right
jump table entry is properly read.
- but at offset 0x12, a *wrong* offset 0x16 is used for the jump. That's
actually the offset of the filler, while it should be 0x18 for label .L4.
This can't work:
- the jump table offsets are computed from the start of the jump table
- but jmp, with that "2" hardcoded as offset, expects offsets being relative to
the address right after itself.
So if a filler is inserted between jmp and actual table contents, as in the
example above, the jump occurs to a wrong address.
[Bug tree-optimization/111472] [11/12/13/14 Regression] Wrong code at -Os on x86_64-linux-gnu since r11-4563-gd0d8b5d836
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111472 --- Comment #5 from Andrew Pinski --- (In reply to Andrew Macleod from comment #3) > I'm not sure that this didn't uncover something elsewhere, possibly ivopts > since that pass seems to be generating something different and I think there > were some fixes put in there on trunk?. > > Regardless, this currently works on trunk. Can we run a regression on trunk > and see what patch fixed it? Most likely r14-4789-g44e7e4498c (aka PR 110243).
[Bug tree-optimization/111472] [11/12/13/14 Regression] Wrong code at -Os on x86_64-linux-gnu since r11-4563-gd0d8b5d836
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111472 --- Comment #4 from Andrew Macleod --- (In reply to Andrew Macleod from comment #3) > I'm not sure that this didn't uncover something elsewhere, possibly ivopts > since that pass seems to be generating something different and I think there > were some fixes put in there on trunk?. > > Regardless, this currently works on trunk. Can we run a regression on trunk > and see what patch fixed it? > > Andrew And still fails on GCC13, so it appears to have been a trunk patch that fixed it.
[Bug fortran/104819] Reject NULL without MOLD as actual to an assumed-rank dummy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104819 anlauf at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed||2023-11-06 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 CC||anlauf at gcc dot gnu.org --- Comment #2 from anlauf at gcc dot gnu.org --- There are also a few cases where null(null()) is erroneously rejected: program p implicit none integer, pointer :: x call foo (null (x))! valid and accepted call foo (null ()) ! valid and accepted call foo (null (null (x))) ! valid but rejected call foo (null (null ())) ! valid but rejected contains subroutine foo (y) integer, pointer :: y end subroutine foo end
[Bug tree-optimization/111472] [11/12/13/14 Regression] Wrong code at -Os on x86_64-linux-gnu since r11-4563-gd0d8b5d836
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111472 --- Comment #3 from Andrew Macleod --- I'm not sure that this didn't uncover something elsewhere, possibly ivopts since that pass seems to be generating something different and I think there were some fixes put in there on trunk?. Regardless, this currently works on trunk. Can we run a regression on trunk and see what patch fixed it? Andrew
[Bug tree-optimization/112324] phiopt fail to recog if (b < 0) max = MAX(-b, max); else max = MAX (b, max) into max = MAX (ABS(b), max)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112324 --- Comment #5 from Andrew Pinski --- (In reply to Andrew Pinski from comment #4) > (In reply to Andrew Pinski from comment #3) > > Note a simple patch to improve phiopt here does not improve the original > > code in openjpeg. > > > > The reason why is due to the code in phiopt here is only operates on the > > case where the phi would be the only one. In that case we also have a vop > > phi which changes which causes the code not to be done. > > But maybe ifcvt could use the same function to do the transformation before > it does the conversion ... I will try to figure that out next but I want to get this patch though.
[Bug c++/112414] Does gcc need __builtin_assume_separate_storage?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112414 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug c++/112414] New: Does gcc need __builtin_assume_separate_storage?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112414 Bug ID: 112414 Summary: Does gcc need __builtin_assume_separate_storage? Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: unlvsur at live dot com Target Milestone: --- clang provides a new builtin since clang 17 for __builtin_assume_separate_storage. Does GCC need it?
[Bug target/112413] Wrong switch jump table offset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112413 --- Comment #2 from Vincent Riviere --- Cause is in gcc/config/m68k/linux.h, macro ASM_RETURN_CASE_JUMP: https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/m68k/linux.h;h=2e1cb5498b86f053d1e9b7c530648dfa186ca4c4;hb=HEAD#l96 jmp %%pc@(2,%0:w) Offset 2 is hardcoded in the macro. Ideally, it should be replaced with the label of the first jump table entry. But I guess it isn't possible inside that macro. A solution is to force ADDR_VEC_ALIGN to 0, in order to completely disable the jump table alignment. That's consistent with ASM_RETURN_CASE_JUMP expectations. #define ADDR_VEC_ALIGN(ADDR_VEC) 0 This should be done for all m68k targets.
[Bug target/112413] Wrong switch jump table offset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112413 Andrew Pinski changed: What|Removed |Added Component|c |target --- Comment #1 from Andrew Pinski --- I don't see any issues with the output of gcc. Are you sure this is not a binutils gnu as issue where the offsets are done incorrectly there.
[Bug c/112413] New: Wrong switch jump table offset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112413
Bug ID: 112413
Summary: Wrong switch jump table offset
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: vincent.riviere at freesbee dot fr
Target Milestone: ---
In some circumstances, gcc produces bad code for switch instruction.
Main goal of the testcase is to force gcc to produce a jump table.
$ cat swi.c
int g;
void f(int i)
{
switch (i)
{
case 0: g = 6082; break;
case 1: g = 9332; break;
case 2: g = 5642; break;
case 3: g = 1423; break;
case 4: g = 2152; break;
case 5: g = 6779; break;
case 6: g = 7074; break;
case 7: g = 8280; break;
}
}
$ m68k-linux-gcc -Os -S -o - swi.c -mlong-jump-table-offsets -malign-int
#NO_APP
.file "swi.c"
.text
.align 2
.globl f
.type f, @function
f:
move.l 4(%sp),%d0
moveq #7,%d1
cmp.l %d0,%d1
jcs .L1
lsl.l #2,%d0
move.l .L4(%pc,%d0.l),%d0
jmp %pc@(2,%d0:l)
.balignw 4,0x284c |Potential bug here
.L4:
.long .L11-.L4
.long .L10-.L4
.long .L9-.L4
.long .L8-.L4
.long .L7-.L4
.long .L6-.L4
.long .L5-.L4
.long .L3-.L4
.L11:
move.l #6082,g
.L1:
rts
.L10:
move.l #9332,g
jra .L1
...
As the jmp may not be aligned on a multiple of 4, the .balignw directive may
introduce a 2-byte filler, causing jmp to use a wrong offset.
Same happens with m68k-elf-gcc.
[Bug libfortran/112412] New: Masked reduction functions return an unallocated array when the result is empty
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112412 Bug ID: 112412 Summary: Masked reduction functions return an unallocated array when the result is empty Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran Assignee: unassigned at gcc dot gnu.org Reporter: mikael at gcc dot gnu.org Target Milestone: --- Non-masked reduction functions work, but their masked variant don't allocate if the result is empty, so the result is seen as non-allocated. See: https://gcc.gnu.org/pipermail/fortran/2023-November/059902.html
[Bug target/110551] [11/12/13/14 Regression] an extra mov when doing 128bit multiply
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110551 --- Comment #9 from Moncef Mechri --- With Roger's latest patch, codegen looks good with -O2 and -O2 -march=haswell. Thanks! I think this can be marked as resolved?
[Bug fortran/109684] compiling failure: complaining about a final subroutine of a type being not PURE (while it is indeed PURE)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109684 --- Comment #25 from Steve Kargl --- On Mon, Nov 06, 2023 at 03:34:42PM +, trnka at scm dot com wrote: > > If expr->where is pointing to NULL, then something is definitely not > > set up correctly or your code is now going through a different code > > path in the compiler. > > Sorry for the delay with testing this, I was busy with other more pressing > tasks. No problem. I have very limited time to look at gfortran bugs and yours caught my eye. > It's not that expr->where would be NULL completely, but its components (nextc > and lb) are both NULL. Sorry about that. I did mean to say the components not just expr->where. In any event, the locus is clearly not correct. > > If this is related to setting up the artificial __final_* procedure, > > then it might be missing properly setting the locus. This patch > > simply sets the locus of the artificial procedure and its arguments > > to that of the derived symbol. This might prevent the ICE, but > > lead to a bogus error message. Can you test this? > > Tested, does not change a thing. The error does not seem to directly have > anything to do with the __final_*, but with building the __vtab_* using a > structure constructor, which is likely happening at a different place as > a side effect of Paul's finalization improvements. Bummer. I was hoping that it would give a better pointer to where gfortran needs to handle the locus. > As this seems to be a different (although possibly related) issue, > I have created PR112407 for further follow-up and posted my new > observations in there. I saw the new PR. Thanks for the in depth analysis. In setting up the constructor for a __vtab_* (an internal symbol), we likely need to ensure the locus is properly set in each list member.
[Bug target/112411] New: ICE: SIGSEGV with --param=min-nondebug-insn-uid=2147483647 on powerpc64le-unknown-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112411 Bug ID: 112411 Summary: ICE: SIGSEGV with --param=min-nondebug-insn-uid=2147483647 on powerpc64le-unknown-linux-gnu Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Target Milestone: --- Host: x86_64-pc-linux-gnu Target: powerpc64le-unknown-linux-gnu Created attachment 56518 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56518=edit reduced testcase Compiler output: $ powerpc64le-unknown-linux-gnu-gcc --param=min-nondebug-insn-uid=2147483647 testcase.c -wrapper valgrind,-q,--num-callers=100 ==18938== Invalid read of size 4 ==18938==at 0xC9A477: get_attr_length_1(rtx_insn*, int (*)(rtx_insn*)) (final.cc:353) ==18938==by 0x1489717: rs6000_insn_cost (rs6000.cc:22634) ==18938==by 0x1489717: rs6000_insn_cost(rtx_insn*, bool) (rs6000.cc:22614) ==18938==by 0xC6D69E: canonicalize_comparison(machine_mode, rtx_code*, rtx_def**) (expmed.cc:6344) ==18938==by 0xC6DD71: emit_store_flag_1(rtx_def*, rtx_code, rtx_def*, rtx_def*, machine_mode, int, int, machine_mode) (expmed.cc:5629) ==18938==by 0xC6E2A7: emit_store_flag(rtx_def*, rtx_code, rtx_def*, rtx_def*, machine_mode, int, int) (expmed.cc:6037) ==18938==by 0xC6F26A: emit_store_flag_force(rtx_def*, rtx_code, rtx_def*, rtx_def*, machine_mode, int, int) (expmed.cc:6177) ==18938==by 0xC89B8F: convert_mode_scalar(rtx_def*, rtx_def*, int) (expr.cc:689) ==18938==by 0xC7E70D: expand_expr_real_2(separate_ops*, rtx_def*, machine_mode, expand_modifier) (expr.cc:9396) ==18938==by 0xB4A2F0: expand_gimple_stmt_1 (cfgexpand.cc:3983) ==18938==by 0xB4A2F0: expand_gimple_stmt(gimple*) (cfgexpand.cc:4044) ==18938==by 0xB5067E: expand_gimple_basic_block(basic_block_def*, bool) (cfgexpand.cc:6100) ==18938==by 0xB5235E: (anonymous namespace)::pass_expand::execute(function*) (cfgexpand.cc:6835) ==18938==by 0xF7B62A: execute_one_pass(opt_pass*) (passes.cc:2641) ==18938==by 0xF7BF0F: execute_pass_list_1(opt_pass*) (passes.cc:2750) ==18938==by 0xF7BF48: execute_pass_list(function*, opt_pass*) (passes.cc:2761) ==18938==by 0xB92FF5: expand (cgraphunit.cc:1841) ==18938==by 0xB92FF5: cgraph_node::expand() (cgraphunit.cc:1794) ==18938==by 0xB93F09: output_in_order (cgraphunit.cc:2191) ==18938==by 0xB93F09: symbol_table::compile() [clone .part.0] (cgraphunit.cc:2395) ==18938==by 0xB96EA7: compile (cgraphunit.cc:2311) ==18938==by 0xB96EA7: symbol_table::finalize_compilation_unit() (cgraphunit.cc:2583) ==18938==by 0x10B3D62: compile_file() (toplev.cc:473) ==18938==by 0x9B8903: do_compile (toplev.cc:2129) ==18938==by 0x9B8903: toplev::main(int, char**) (toplev.cc:2285) ==18938==by 0x9BA00A: main (main.cc:39) ==18938== Address 0xfffe001c is not stack'd, malloc'd or (recently) free'd ==18938== during RTL pass: expand testcase.c: In function 'foo': testcase.c:7:5: internal compiler error: Segmentation fault 7 | i += j; | ^~ $ powerpc64le-unknown-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-powerpc64le/bin/powerpc64le-unknown-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r14-5141-20231106022717-g1a55724f787-checking-yes-rtl-df-extra-powerpc64le/bin/../libexec/gcc/powerpc64le-unknown-linux-gnu/14.0.0/lto-wrapper Target: powerpc64le-unknown-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --with-cloog --with-ppl --with-isl --with-sysroot=/usr/powerpc64le-unknown-linux-gnu --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=powerpc64le-unknown-linux-gnu --with-ld=/usr/bin/powerpc64le-unknown-linux-gnu-ld --with-as=/usr/bin/powerpc64le-unknown-linux-gnu-as --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-r14-5141-20231106022717-g1a55724f787-checking-yes-rtl-df-extra-powerpc64le Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 14.0.0 20231106 (experimental) (GCC)
[Bug libgcc/65833] Attempting to convert 128 bit integers to 128 bit decimal floating-point results in an unresolved symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65833 Jakub Jelinek changed: What|Removed |Added Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Last reconfirmed||2023-11-06 Status|UNCONFIRMED |ASSIGNED --- Comment #2 from Jakub Jelinek --- Created attachment 56517 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56517=edit gcc14-pr65833.patch Untested implementation (on top of _BitInt support, so for now x86_64 only, but with the hope that other int128 targets will gain _BitInt support soon).
[Bug target/111600] [14 Regression] RISC-V bootstrap time regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111600 --- Comment #31 from Andreas Schwab --- For the first time the bootstrap time has been reduced, from 192543 (20231028) to 141231 (20231103), -26,6%.
[Bug tree-optimization/112324] phiopt fail to recog if (b < 0) max = MAX(-b, max); else max = MAX (b, max) into max = MAX (ABS(b), max)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112324 --- Comment #4 from Andrew Pinski --- (In reply to Andrew Pinski from comment #3) > Note a simple patch to improve phiopt here does not improve the original > code in openjpeg. > > The reason why is due to the code in phiopt here is only operates on the > case where the phi would be the only one. In that case we also have a vop > phi which changes which causes the code not to be done. But maybe ifcvt could use the same function to do the transformation before it does the conversion ...
[Bug c/112409] Structure is not initialized as expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112409 --- Comment #7 from Frediano Ziglio --- Sorry for the noise, thanks for the informations. I didn't notice banner on top. I went back and I notice it, pretty small and it looks like a lot of other website banners for technical disruptions or cookies.
[Bug tree-optimization/112324] phiopt fail to recog if (b < 0) max = MAX(-b, max); else max = MAX (b, max) into max = MAX (ABS(b), max)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112324 --- Comment #3 from Andrew Pinski --- Note a simple patch to improve phiopt here does not improve the original code in openjpeg. The reason why is due to the code in phiopt here is only operates on the case where the phi would be the only one. In that case we also have a vop phi which changes which causes the code not to be done.
[Bug libstdc++/108409] std::chrono::current_zone() doesn't work on AIX or Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108409 Mike Crowe changed: What|Removed |Added CC||mac at mcrowe dot com --- Comment #7 from Mike Crowe --- ICU tries to solve this problem with a table at https://github.com/unicode-org/icu/blob/fa6a4661ba002c1c1ee68cbf5c7ac9af75132d07/icu4c/source/common/putil.cpp#L802 and other heuristics in the same file. Based on my understanding, the table is incorrect for the Australian zones and US/Aleutian (it gets the short names wrong) and it's missing the non-DST US zones. I'm not sure if it's worth going to these lengths to try to map POSIX time zone strings to Olson names, but I thought I'd provide the link in case it's useful.
[Bug c++/112410] error when auto(x) is used in a variable initializer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112410 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org --- Comment #3 from Marek Polacek --- Part of the problem seems to be that fully_implicit_function_template_p is set. I'd like to poke more.
[Bug d/112408] [12/13/14 regression] d21 loops in getCpuInfo0B in Solaris/x86 kernel zone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112408
--- Comment #3 from ibuclaw at gcc dot gnu.org ---
Based on what I see here, this patch to core.cpuid should be sufficient to fix
loop and not introduce any change in existing behaviour.
---
--- a/druntime/src/core/cpuid.d
+++ b/druntime/src/core/cpuid.d
@@ -666,10 +666,12 @@ void getAMDcacheinfo()
// to determine number of processors.
void getCpuInfo0B()
{
-int level=0;
int threadsPerCore;
uint a, b, c, d;
-do {
+// I'm not sure about this. The docs state that there
+// are 2 hyperthreads per core if HT is factory enabled.
+for (int level = 0; level < 2; level++)
+{
version (GNU_OR_LDC) asm pure nothrow @nogc {
"cpuid" : "=a" (a), "=b" (b), "=c" (c), "=d" (d) : "a" (0x0B), "c"
(level);
} else asm pure nothrow @nogc {
@@ -681,19 +683,20 @@ void getCpuInfo0B()
mov c, ECX;
mov d, EDX;
}
-if (b!=0) {
- // I'm not sure about this. The docs state that there
- // are 2 hyperthreads per core if HT is factory enabled.
-if (level==0)
+if (b != 0)
+{
+if (level == 0)
threadsPerCore = b & 0x;
-else if (level==1) {
+else if (level == 1)
+{
cpuFeatures.maxThreads = b & 0x;
cpuFeatures.maxCores = cpuFeatures.maxThreads /
threadsPerCore;
}
-
}
-++level;
-} while (a!=0 || b!=0);
+// Got "invalid domain" returned from cpuid
+if (a == 0 && b == 0)
+break;
+}
}
void cpuidX86()
[Bug c++/112410] error when auto(x) is used in a variable initializer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112410 --- Comment #2 from Andrew Pinski --- Confirmed. Looks like GCC is messing the Most vexing parse here.
[Bug c++/112410] error when auto(x) is used in a variable initializer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112410
Marek Polacek changed:
What|Removed |Added
Ever confirmed|0 |1
CC||mpolacek at gcc dot gnu.org
Last reconfirmed||2023-11-06
Status|UNCONFIRMED |NEW
--- Comment #1 from Marek Polacek ---
I think you're right. Same for
int z(auto{42});
[Bug c++/112410] New: error when auto(x) is used in a variable initializer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112410 Bug ID: 112410 Summary: error when auto(x) is used in a variable initializer Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: vanyacpp at gmail dot com Target Milestone: --- int x = auto(42); // OK int y(auto(42)); // error On the second line GCC -std=c++23 gives an error: error: non-function 'y' declared as implicit template I believe the code is correct and should compile without errors.
[Bug c/112409] Structure is not initialized as expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112409 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #6 from Jonathan Wakely --- (In reply to Frediano Ziglio from comment #5) > But the pointer "passes" through a "void*" conversion, so there should be no > aliasing. Or am I missing something? That's not how aliasing works. You can't just cast to void* to change the effective type of that struct and magically make it valid to read uint16_t values from it. > So what's the standard C way to avoid this (without using specific compiler > options) ? memcpy GCC will also allow you to use a union, but the union has to be visible in the code that performs the type punning.
[Bug target/112397] Two persistent libstdc++ test failures on x86_64-apple-darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112397 Iain Sandoe changed: What|Removed |Added Component|libstdc++ |target --- Comment #2 from Iain Sandoe --- (In reply to Jonathan Wakely from comment #1) > The .cold symbol is created by gcc, I don't see any way to control its > visibility in the source. So maybe a target bug in the compiler, not a > library bug. Agreed its a target issue - it's a question of convincing the linker that the label is not reachable from a different TU if the implementation of the non-cold symbol comes from that.
[Bug c/112409] Structure is not initialized as expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112409 Frediano Ziglio changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |--- --- Comment #5 from Frediano Ziglio --- But the pointer "passes" through a "void*" conversion, so there should be no aliasing. Or am I missing something? So what's the standard C way to avoid this (without using specific compiler options) ?
[Bug c/112409] Structure is not initialized as expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112409 Jonathan Wakely changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #4 from Jonathan Wakely --- There's a reason that the bug reporting guidelines *and* the banner at the top of the bug creation form ask you to try -fno-strict-aliasing, and it's easy to see that the constants are not removed if you use that option. Like the guidelines and the banner say, if -fno-strict-aliasing makes a difference, your code is probably not correct.
[Bug tree-optimization/111572] [14 Regression] Wrong code at -O2 on x86_64-linux-gnu since r14-301-gf2d6beb7a4d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111572 --- Comment #6 from Martin Jambor --- (In reply to Andrew Pinski from comment #5) > Hmm, this works on the trunk now. Would be a good idea to figure out what > "fixed" it. If my simple test is correct, the error disappeared with r14-4790-g9692309ed6b625 (Richi's: tree-optimization/111445 - simple_iv simplification fault)
[Bug c/112409] Structure is not initialized as expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112409
--- Comment #3 from Jonathan Wakely ---
(In reply to Frediano Ziglio from comment #0)
> static unsigned
> cksum(const void *pkt, size_t len, unsigned int start)
> {
> const uint16_t *data = (const uint16_t *) pkt;
> unsigned sum = start;
>
> for (; len >= 2; len -= 2)
> sum += *data++;
Right, this is undefined behaviour, because you're reading uint16_t values from
an object that is not a uint16_t.
[Bug c/112409] Structure is not initialized as expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112409 --- Comment #2 from Andrew Pinski --- I have to double check but I am 99% sure this code is undefined due to alias violations. Use either memcpy or -fno-strict-aliasing.
[Bug c/112409] Structure is not initialized as expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112409 Sam James changed: What|Removed |Added CC||sjames at gcc dot gnu.org --- Comment #1 from Sam James --- You have an aliasing violation with uint8_t <-> uint32_t. Works with -fno-strict-aliasing.
[Bug c/112409] New: Structure is not initialized as expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112409
Bug ID: 112409
Summary: Structure is not initialized as expected
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: freddy77 at gmail dot com
Target Milestone: ---
I was writing a small network utility till I found a weird behaviour computing
TCP checksums. After some debugging I found that the error disappeared with
either -O1 or -O0. So I reduced the program, trying using multiple GCC versions
and it kept happening.
The final program (stripped down) is:
typedef long unsigned int size_t;
typedef unsigned char uint8_t;
typedef unsigned short int uint16_t;
typedef unsigned int uint32_t;
#define ntohs __builtin_bswap16
#define htonl __builtin_bswap32
static inline unsigned
reduce_cksum(unsigned sum)
{
return (sum >> 16) + (sum & 0xu);
}
static unsigned
cksum(const void *pkt, size_t len, unsigned int start)
{
const uint16_t *data = (const uint16_t *) pkt;
unsigned sum = start;
for (; len >= 2; len -= 2)
sum += *data++;
if (len)
sum += ntohs(*((const uint8_t *)data) << 8);
sum = reduce_cksum(sum);
sum = reduce_cksum(sum);
return sum;
}
static unsigned
tcpdump_flow_new(uint32_t saddr, uint32_t daddr)
{
struct {
uint32_t saddr, daddr;
uint8_t zero, proto;
} pseudo = { htonl(saddr), htonl(daddr), 0, 6 };
return cksum(, 10, 0);
}
int main(void)
{
unsigned res = tcpdump_flow_new(0x01020304, 0xa1b2c3d4);
return res;
}
Using -O2 option and Compiler Explorer (but I tried multiple versions locally)
produced this:
main:
xor edx, edx
lea rax, [rsp-12]
lea rsi, [rsp-2]
.L2:
movzx ecx, WORD PTR [rax]
add rax, 2
add edx, ecx
cmp rax, rsi
jne .L2
mov eax, edx
movzx edx, dx
shr eax, 16
add edx, eax
mov eax, edx
movzx edx, dx
shr eax, 16
add eax, edx
ret
It's easy to spot that the constants disappeared from the code and program uses
not initialized memory.
[Bug d/112408] [12/13/14 regression] d21 loops in getCpuInfo0B in Solaris/x86 kernel zone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112408 --- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #1 from ibuclaw at gcc dot gnu.org --- > (In reply to Rainer Orth from comment #0) >> This affects all DMD-based versions of GDC, while the previous C++-based >> versions >> are fine. > The compiler is fine, but if I understand right, all programs built by the > C++-based version would still observe the same infinite loop. Just the opposite: both D-based d21 and every D program somehow using getCpuInfo0B would experience the loop. I believe I originally experienced that in early (GCC 8 or 9) versions when testing libphobos in a Solaris 11.3 kernel zone.
[Bug d/112408] [12/13/14 regression] d21 loops in getCpuInfo0B in Solaris/x86 kernel zone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112408 ibuclaw at gcc dot gnu.org changed: What|Removed |Added CC||ibuclaw at gcc dot gnu.org --- Comment #1 from ibuclaw at gcc dot gnu.org --- (In reply to Rainer Orth from comment #0) > This affects all DMD-based versions of GDC, while the previous C++-based > versions > are fine. The compiler is fine, but if I understand right, all programs built by the C++-based version would still observe the same infinite loop.
[Bug d/112408] [12/13/14 regression] d21 loops in getCpuInfo0B in Solaris/x86 kernel zone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112408 Rainer Orth changed: What|Removed |Added Target Milestone|--- |14.0
[Bug d/112408] New: [12/13/14 regression] d21 loops in getCpuInfo0B in Solaris/x86 kernel zone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112408
Bug ID: 112408
Summary: [12/13/14 regression] d21 loops in getCpuInfo0B in
Solaris/x86 kernel zone
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: d
Assignee: ibuclaw at gdcproject dot org
Reporter: ro at gcc dot gnu.org
Target Milestone: ---
Host: i386-pc-solaris2.11, x86_64-pc-linux-gnu
Target: i386-pc-solaris2.11, x86_64-pc-linux-gnu
Build: i386-pc-solaris2.11, x86_64-pc-linux-gnu
While preparing GCC builds for a new Solaris 11.4/x86 GCC CFarm system, I
re-ran
into an issue with D programs looping inside a Solaris kernel zone (a VM),
while
the same binaries work fine on bare metal.
I've now managed to root-cause the issue. When bootstrapping e.g. GCC 13 with
GCC 9.5.0 or 11.4.0, configuring libphobos in stage 1 loops. This can be
reproduced with
$ cat conftest.d
module object;
extern(C) int main() {
return 0;
}
$ d21 conftest.d
which loops indefinitely. d21 show the following stacktrace:
Thread 2 received signal SIGINT, Interrupt.
[Switching to Thread 1 (LWP 1)]
_D4core5cpuid12getCpuInfo0BFNbNiNeZv ()
at gcc-11.4.0/libphobos/libdruntime/core/cpuid.d:669
669 if (b!=0) {
1: x/i $pc
=> 0x442b311 <_D4core5cpuid12getCpuInfo0BFNbNiNeZv+33>: test %ebx,%ebx
(gdb) bt
#0 _D4core5cpuid12getCpuInfo0BFNbNiNeZv ()
at gcc-11.4.0/libphobos/libdruntime/core/cpuid.d:669
#1 0x0442b7e3 in _D4core5cpuid8cpuidX86FNbNiNeZv ()
at gcc-11.4.0/libphobos/libdruntime/core/cpuid.d:953
#2 0x0442bd75 in _D4core5cpuid18_sharedStaticCtor1FNbNiNeZv ()
at gcc-11.4.0/libphobos/libdruntime/core/cpuid.d:1073
#3 0x0441a421 in runModuleFuncs (this=0x0, modules=...)
at gcc-11.4.0/libphobos/libdruntime/rt/minfo.d:858
#4 _D2rt5minfo11ModuleGroup8runCtorsMFZv (this=...)
at gcc-11.4.0/libphobos/libdruntime/rt/minfo.d:728
#5 0x0441b5bd in __foreachbody1 (this=, sg=...)
at gcc-11.4.0/libphobos/libdruntime/rt/minfo.d:796
#6 0x0440ffd2 in _D3gcc8sections3elf3DSO7opApplyFMDFKSQBjQBiQBcQBbZiZi
(dg=...)
at gcc-11.4.0/libphobos/libdruntime/gcc/sections/elf.d:106
#7 0x0441a61e in rt_moduleCtor ()
at gcc-11.4.0/libphobos/libdruntime/rt/minfo.d:793
#8 0x0440f880 in rt_init ()
at gcc-11.4.0/libphobos/libdruntime/rt/dmain2.d:129
#9 0x022f4c16 in d_init_options (decoded_options=0x47e1f00)
at gcc-13.2.0/gcc/d/d-lang.cc:290
#10 0x02ac5fbc in toplev::main (this=0x7fffb97a, argc=2,
argv=0x7fffb9b8) at gcc-13.2.0/gcc/toplev.cc:2240
#11 0x04301c46 in main (argc=2, argv=0x7fffb9b8)
at gcc-13.2.0/gcc/main.cc:39
Running getCpuInfo0B side-by-side in the kernel zone and on bare metal shows:
kernel zone bare metal
level 0
a 0 1
b 1 2
level 1
a 0 5
b 1 28
level 2
a 0 0
b 1 0
and so on for each higher level. So inside a kernel zone, a!=0 || b!=0 remains
true, explaining the loop.
If I'm reading the spec (Intel® 64 and IA-32 Architectures
Software Developer’s Manual, Combined Volumes: 1, 2A, 2B, 2C, 2D, 3A, 3B,
3C, 3D, and 4, Order Number: 325462-081US, September 2023, Vol. 2A,
3-225, p.821) correctly, this is a bug in the kernel zone software:
A sub-leaf returning an invalid domain always returns 0 in EAX and EBX.
OTOH I don't see why getCpuInfo0B needs to loop here since it's only interested
in levels 0 and 1 anyway.
This affects all DMD-based versions of GDC, while the previous C++-based
versions
are fine.
[Bug c++/50755] [avr] ICE: tree check: expected class 'constant', have 'unary' (convert_expr)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50755 --- Comment #5 from Georg-Johann Lay --- (In reply to Roger Sayle from comment #4) > This appears to be fixed on mainline. At least the test case passes on newer versions. For a definite answer you'd have to bisect / find the patch that solved it.
[Bug fortran/109684] compiling failure: complaining about a final subroutine of a type being not PURE (while it is indeed PURE)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109684 --- Comment #24 from Tomáš Trnka --- (In reply to Steve Kargl from comment #23) > If expr->where is pointing to NULL, then something is definitely not > set up correctly or your code is now going through a different code > path in the compiler. Sorry for the delay with testing this, I was busy with other more pressing tasks. It's not that expr->where would be NULL completely, but its components (nextc and lb) are both NULL. > If this is related to setting up the artificial __final_* procedure, > then it might be missing properly setting the locus. This patch > simply sets the locus of the artificial procedure and its arguments > to that of the derived symbol. This might prevent the ICE, but > lead to a bogus error message. Can you test this? Tested, does not change a thing. The error does not seem to directly have anything to do with the __final_*, but with building the __vtab_* using a structure constructor, which is likely happening at a different place as a side effect of Paul's finalization improvements. As this seems to be a different (although possibly related) issue, I have created PR112407 for further follow-up and posted my new observations in there.
[Bug fortran/112407] [13 Regression] Fix for PR37336 triggers an ICE in gfc_format_decoder while constructing a vtab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112407 --- Comment #1 from Tomáš Trnka --- Created attachment 56516 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56516=edit Hacky patch working around the issue on this testcase
[Bug fortran/112407] New: [13 Regression] Fix for PR37336 triggers an ICE in gfc_format_decoder while constructing a vtab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112407
Bug ID: 112407
Summary: [13 Regression] Fix for PR37336 triggers an ICE in
gfc_format_decoder while constructing a vtab
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: trnka at scm dot com
Target Milestone: ---
Created attachment 56515
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56515=edit
reproducer with dependencies
Following up on comment 7 in PR109684. This seems to be another issue uncovered
by the finalization overhaul:
commit r13-6747-gd7caf313525a46f200d7f5db1ba893f853774aee
Author: Paul Thomas
Date: Sat Mar 18 07:56:23 2023 +
Fortran: Fix bugs and missing features in finalization [PR37336]
2023-03-18 Paul Thomas
The attached test triggers an assert in gfc_format_decoder, at
fortran/error.cc:1078 (on current 13 branch):
0x65cce5 gfc_format_decoder
gcc/fortran/error.cc:1078
0x1b12ed9 pp_format(pretty_printer*, text_info*)
gcc/pretty-print.cc:1475
0x1b030d1 diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*)
gcc/diagnostic.cc:1592
0x6e0127 gfc_report_diagnostic
gcc/fortran/error.cc:890
0x6e0127 gfc_warning
gcc/fortran/error.cc:923
0x6e07e6 gfc_warning(int, char const*, ...)
gcc/fortran/error.cc:954
0x765d5e resolve_procedure_expression
gcc/fortran/resolve.cc:1956
0x765d5e resolve_variable
gcc/fortran/resolve.cc:6066
0x765d5e gfc_resolve_expr(gfc_expr*)
gcc/fortran/resolve.cc:7302
0x7635c9 gfc_resolve_expr(gfc_expr*)
gcc/fortran/resolve.cc:7267
0x7635c9 resolve_structure_cons
gcc/fortran/resolve.cc:1341
0x774521 resolve_values
gcc/fortran/resolve.cc:12802
0x78afd2 do_traverse_symtree
gcc/fortran/symbol.cc:4190
0x76ac7d resolve_types
gcc/fortran/resolve.cc:17941
0x771efc gfc_resolve(gfc_namespace*)
gcc/fortran/resolve.cc:18038
0x760d1e resolve_symbol
gcc/fortran/resolve.cc:16602
0x78afd2 do_traverse_symtree
gcc/fortran/symbol.cc:4190
0x76ab9e resolve_types
gcc/fortran/resolve.cc:17920
0x771efc gfc_resolve(gfc_namespace*)
gcc/fortran/resolve.cc:18038
0x760d1e resolve_symbol
gcc/fortran/resolve.cc:16602
This assert is hit while printing the following warning:
#0 gfc_warning (opt=0,
gmsgid=0x1e55748 "Non-RECURSIVE procedure %qs at %L is possibly calling
itself recursively. Declare it RECURSIVE or use %<-frecursive%>")
In particular, the following line in gfc_format_decoder is failing:
gcc_assert (loc->nextc - loc->lb->line >= 0);
That's because both loc->nextc and loc->lb are 0 here. Walking up the stack, I
have found that this all happens while resolving the structure constructor for
__vtab_ftldynarrayintmodule_Ftldynarrayint. cons->where and cons->expr->where
in resolve_structure_cons both look like the bogus locus causing the assert:
(gdb) p cons->where
$6 = {nextc = 0x0, lb = 0x0}
(gdb) p cons->expr->where
$8 = {nextc = 0x0, lb = 0x0}
Picking the massive commit mentioned above apart into small chunks and
reverting them one by one, I have narrowed the triggering change down to the
following addition to resolve_symbol():
if (!sym->attr.referenced
&& (sym->ts.type == BT_CLASS || sym->ts.type == BT_DERIVED))
{
gfc_expr *final_expr = gfc_lval_expr_from_sym (sym);
if (gfc_is_finalizable (final_expr->ts.u.derived, NULL))
gfc_set_sym_referenced (sym);
gfc_free_expr (final_expr);
}
Specifically, it's the call to gfc_find_derived_vtab() in gfc_is_finalizable()
on the affected module that directly triggers the bug. Two TBPs in the affected
type are directly involved in triggering the assert. Applying the attached hack
works around the issue (by skipping the call to gfc_find_derived_vtab() for the
two affected routines.
FWIW, both affected routines (NewCopyOther and AssignOther) have two arguments
like this:
subroutine NewCopyOther(self, other)
class(ftlDynArrayInt), intent(out) :: self
type(ftlDynArrayInt), intent(in) :: other
impure elemental subroutine AssignOther(self, other)
class(ftlDynArrayInt), intent(inout) :: self
type(ftlDynArrayInt), intent(in):: other
It's always the "other" argument which triggers this, the "self" one never hits
the bit in resolve_symbol() mentioned above. Changing "other" to
class(ftlDynArrayInt) also makes the issue go away.
To reproduce this, unpack the attached tarball (containing the testcase and
three dependency .mod files) and run gfortran -c test-vtab-construct-ice.f90.
The ftlDynArrayInt type hitting the issue is pulled in by the
ChemicalSystemModule, which seems to be a key ingredient. It's a really big
module with dozens of dependencies (so I can't feasibly provide them all) and
the
[Bug c/107954] Support -std=c23/gnu23 as aliases of -std=c2x/gnu2x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107954 --- Comment #7 from CVS Commits --- The master branch has been updated by Joseph Myers : https://gcc.gnu.org/g:fad61bf73b3158157a136bf4d9373fc3d9afe319 commit r14-5160-gfad61bf73b3158157a136bf4d9373fc3d9afe319 Author: Joseph Myers Date: Mon Nov 6 15:01:22 2023 + c: Add -std=c23, -std=gnu23, -Wc11-c23-compat options [PR107954] At the June WG14 meeting, WG14 decided it preferred to keep C23 as the informal name for the next revision of the C standard, despite publication not being before 2024 (publication is due in 2024 whether or not technical changes at the January meeting result in an FDIS ballot being needed). At the Cauldron I raised the question of whether we should thus now add option names such as -std=c23 to GCC, and there was support for doing so. Add -std=c23, making -std=c2x a deprecated alias; also add the alias -std=iso9899:2024. Likewise, add -std=gnu23, making -std=gnu2x a deprecated alias, and add -Wc11-c23-compat, making -Wc11-c2x-compat a deprecated alias. Here, I'm generally just adding the new options and making the minimum changes required to do so, with documentation changed to refer to C23 instead of C2X only where directly associated with documentation of these options. It's intended that future changes will update documentation, diagnostics, comments, variable names, testcase names, etc. to refer consistently to C23. When such changes are made, the new tests c23-opts-3.c, c23-opts-5.c and gnu23-opts-2.c are intended to keep using the old option names they are specifically testing, while other tests would start using the c23/gnu23 versions of the names (as well as the tests themselves being renamed). Updating option names is independent of updating to the final __STDC_VERSION__ value. There, the question is whether we should update the value now or wait for the remaining significant features to be implemented first. (I intend to review Martin's tag compatibility patches for GCC 14. I'm not aware of anyone working on #embed - or on the [[unsequenced]] and [[reproducible]] attributes, though support for standard attributes is optional.) Bootstrapped with no regressions for x86_64-pc-linux-gnu. PR c/107954 gcc/ * doc/cpp.texi (__STDC_VERSION__): Refer to -std=c23 and -std=gnu23 instead of -std=c2x and -std=gnu2x. * doc/extend.texi (Attribute Syntax): Refer to C23 and -std=c23 instead of C2x and -std=c2x. * doc/invoke.texi (-Wc11-c23-compat, -std=c23, -std=gnu23) (-std=iso9899:2024): Document, with -Wc11-c2x-compat, -std=c2x and -std=gnu2x as deprecated aliases. Update descriptions of C23. * doc/standards.texi (Standards): Describe C23 with C2X as an old name. gcc/c-family/ * c.opt (Wc11-c2x-compat): Rename to Wc11-c23-compat and make into a deprecated alias of Wc11-c23-compat. (std=c2x): Rename to std=c23 and make into a deprecated alias of std=c23. (std=gnu2x): Rename to std=gnu23 and make into a deprecated alias of std=gnu23. (std=iso9899:2024): New option. Alias of std=c23. * c-lex.cc (interpret_float): Use OPT_Wc11_c23_compat instead of OPT_Wc11_c2x_compat. * c-opts.cc (c_common_handle_option): Use OPT_std_c23 instead of OPT_std_c2x and OPT_std_gnu23 instead of OPT_std_gnu2x. gcc/c/ * c-errors.cc (pedwarn_c11): Use OPT_Wc11_c23_compat instead of OPT_Wc11_c2x_compat. * c-typeck.cc (build_conditional_expr, convert_for_assignment): Use OPT_Wc11_c23_compat instead of OPT_Wc11_c2x_compat. gcc/testsuite/ * gcc.dg/c23-opts-1.c, gcc.dg/c23-opts-2.c, gcc.dg/c23-opts-3.c, gcc.dg/c23-opts-4.c, gcc.dg/c23-opts-5.c, gcc.dg/gnu23-opts-1.c, gcc.dg/gnu23-opts-2.c: New tests.
[Bug target/112393] [14 Regression] ICE: in gen_reg_rtx, at emit-rtl.cc:1208 with -mavx5124fmaps -Wuninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112393 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #6 from Andrew Pinski --- .
[Bug target/112405] GCN: "gcc.dg/vect/vect-simd-clone-20.c:22:1: error: conversion of register to a different size in 'view_convert_expr'"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112405 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Richard Biener --- Fixed.
[Bug target/112405] GCN: "gcc.dg/vect/vect-simd-clone-20.c:22:1: error: conversion of register to a different size in 'view_convert_expr'"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112405 --- Comment #2 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:9125969086bfa1bf804b246ea574a2329b06d2c5 commit r14-5158-g9125969086bfa1bf804b246ea574a2329b06d2c5 Author: Richard Biener Date: Mon Nov 6 14:34:07 2023 +0100 tree-optimization/112405 - SIMD clone calls with (loop) mask The following fixes the mask argument generation for SIMD clone calls under either loop masking or when the actual call is not masked but only a inbranch simd clone is available. The issue was that we tried to directly convert the vector mask to the call argument type but SIMD clone masks require 1 or 0 (which could be even float) values for mask elements so we have to resort to a VEC_COND_EXPR to generate them just like we do for regular passing of the mask. PR tree-optimization/112405 * tree-vect-stmts.cc (vectorizable_simd_clone_call): Properly handle invariant and/or loop mask passing.
[Bug tree-optimization/111950] [14 Regression] ICE in compute_live_loop_exits, at tree-ssa-loop-manip.cc:250 since r14-4786-gd118738e71c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111950 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #12 from Richard Biener --- Fixed.
[Bug tree-optimization/111000] [14 Regression] Wrong code at -O3 on x86_64-linux-gnu since r14-2944-g3d48c11ad08
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111000 Bug 111000 depends on bug 111950, which changed state. Bug 111950 Summary: [14 Regression] ICE in compute_live_loop_exits, at tree-ssa-loop-manip.cc:250 since r14-4786-gd118738e71c https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111950 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug target/112405] GCN: "gcc.dg/vect/vect-simd-clone-20.c:22:1: error: conversion of register to a different size in 'view_convert_expr'"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112405 Richard Biener changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Last reconfirmed||2023-11-06 Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- I will have a look.
[Bug tree-optimization/110641] [14 Regression] ICE in adjust_loop_info_after_peeling, at tree-ssa-loop-ivcanon.cc:1023 since r14-2230-g7e904d6c7f2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110641 Jan Hubicka changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #3 from Jan Hubicka --- mine.
[Bug tree-optimization/111950] [14 Regression] ICE in compute_live_loop_exits, at tree-ssa-loop-manip.cc:250 since r14-4786-gd118738e71c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111950 --- Comment #11 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:bf72d50d16f0c1fa8102ca2544d2a05772f8c273 commit r14-5155-gbf72d50d16f0c1fa8102ca2544d2a05772f8c273 Author: Richard Biener Date: Fri Nov 3 14:24:10 2023 +0100 tree-optimization/111950 - vectorizer loop copying The following simplifies LC-PHI arg population during epilog peeling, thereby fixing the testcase in this PR. PR tree-optimization/111950 * tree-vect-loop-manip.cc (slpeel_duplicate_current_defs_from_edges): Remove. (find_guard_arg): Likewise. (slpeel_update_phi_nodes_for_guard2): Likewise. (slpeel_tree_duplicate_loop_to_edge_cfg): Remove calls to slpeel_duplicate_current_defs_from_edges, do not elide LC-PHIs for invariant values. (vect_do_peeling): Materialize PHI arguments for the edge around the epilog from the PHI defs of the main loop exit. * gcc.dg/torture/pr111950.c: New testcase.
[Bug middle-end/112406] [14 Regression] Several SPECCPU 2017 benchmarks fail with LTO on internal compiler error: in expand_insn, at optabs.cc:8305
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112406 Richard Biener changed: What|Removed |Added Target Milestone|--- |14.0 --- Comment #1 from Richard Biener --- Possibly the same as PR112359?
[Bug tree-optimization/112404] [14 Regression] 521.wrf_r fails to build with internal compiler error: in get_vectype_for_scalar_type, at tree-vect-stmts.cc:13311
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112404 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from Richard Biener --- Fixed.
[Bug tree-optimization/112404] [14 Regression] 521.wrf_r fails to build with internal compiler error: in get_vectype_for_scalar_type, at tree-vect-stmts.cc:13311
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112404 --- Comment #4 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:3cc9ad41db87fb85b13a56bff1f930c258542a70 commit r14-5154-g3cc9ad41db87fb85b13a56bff1f930c258542a70 Author: Richard Biener Date: Mon Nov 6 12:43:11 2023 +0100 tree-optimization/112404 - two issues with SLP of .MASK_LOAD The following fixes an oversight in vect_check_scalar_mask when the mask is external or constant. When doing BB vectorization we need to provide a group_size, best via an overload accepting the SLP node as argument. When fixed we then run into the issue that we have not analyzed alignment of the .MASK_LOADs because they were not identified as loads by vect_gather_slp_loads. Fixed by reworking the detection. PR tree-optimization/112404 * tree-vectorizer.h (get_mask_type_for_scalar_type): Declare overload with SLP node argument. * tree-vect-stmts.cc (get_mask_type_for_scalar_type): Implement it. (vect_check_scalar_mask): Use it. * tree-vect-slp.cc (vect_gather_slp_loads): Properly identify loads also for nodes with children, like .MASK_LOAD. * tree-vect-loop.cc (vect_analyze_loop_2): Look at the representative for load nodes and check whether it is a grouped access before looking for load-lanes support. * gfortran.dg/pr112404.f90: New testcase.
[Bug middle-end/110859] New FAIL: 23_containers/vector/bool/110807.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110859 Jonathan Wakely changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2023-11-06 --- Comment #4 from Jonathan Wakely --- bug 110807 comment 11 has some analysis of this failure (which I admittedly don't understand).
