[Bug libstdc++/113159] More robust std::sort for silly comparator functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113159 Florian Weimer changed: What|Removed |Added CC||fw at gcc dot gnu.org --- Comment #6 from Florian Weimer --- We'll likely revert most of the qsort changes for glibc 2.39 because the new implementation is both slower and has a significant backwards compatibility impact.
[Bug other/113168] New: ABOUT-NLS seems way out of date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113168 Bug ID: 113168 Summary: ABOUT-NLS seems way out of date Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: internal-improvement Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: pinskia at gcc dot gnu.org Target Milestone: --- For an example: ``` the Free Translation Project's homepage, `http://www.iro.umontreal.ca/contrib/po/HTML/' ``` That is no longer the URL. It is https://translationproject.org/html/welcome.html .
[Bug target/113133] [14 Regression] ICE: SIGSEGV in mark_label_nuses(rtx_def*) (emit-rtl.cc:3896) with -O -fno-tree-ter -mavx512f -march=barcelona
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113133 --- Comment #7 from Haochen Jiang --- (In reply to Uroš Bizjak from comment #1) > Created attachment 56962 [details] > Proposed patch > > Patch in testing. > > lowpart_subreg can't handle: > > lowpart_subreg (V4SFmode, operands[0], DFmode); > > and > > lowpart_subreg (V2DFmode, operands[0], SFmode); > > subreg conversions and will return NULL_RTX for these cases. I suppose the patch here is ok at least from my initial test.
[Bug gcov-profile/113157] compilation error in PGO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113157 --- Comment #2 from Andrew Pinski --- That is this works: [apinski@xeond2 pr113157]$ gcc --coverage -o test 1.c 2.c -O3 [apinski@xeond2 pr113157]$ ./test [apinski@xeond2 pr113157]$ gcc -O3 -fprofile-use -o test 1.c 2.c
[Bug gcov-profile/113157] compilation error in PGO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113157 Andrew Pinski changed: What|Removed |Added Keywords||diagnostic --- Comment #1 from Andrew Pinski --- >1.c:7:1: error: corrupted profile info: profile data is not flow-consistent This is because you different options while compiling the 2 versions of the applications. Yes the diagnostic should be better though.
[Bug testsuite/113167] [14 Regression] gcc.dg/tree-ssa/gen-vect-26.c started failing many targets after recent change
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113167 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from Andrew Pinski --- Fixed.
[Bug testsuite/113167] [14 Regression] gcc.dg/tree-ssa/gen-vect-26.c started failing many targets after recent change
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113167 --- Comment #4 from GCC Commits --- The trunk branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:200531d5b9fb99eca2b0d6b8d1e42d176413225f commit r14-6861-g200531d5b9fb99eca2b0d6b8d1e42d176413225f Author: Andrew Pinski Date: Thu Dec 28 20:26:01 2023 -0800 Fix gen-vect-26.c testcase after loops with multiple exits [PR113167] This fixes the gcc.dg/tree-ssa/gen-vect-26.c testcase by adding `#pragma GCC novector` in front of the loop that is doing the checking of the result. We only want to test the first loop to see if it can be vectorize. Committed as obvious after testing on x86_64-linux-gnu with -m32. gcc/testsuite/ChangeLog: PR testsuite/113167 * gcc.dg/tree-ssa/gen-vect-26.c: Mark the test/check loop as novector. Signed-off-by: Andrew Pinski
[Bug testsuite/113167] [14 Regression] gcc.dg/tree-ssa/gen-vect-26.c started failing many targets after recent change
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113167
--- Comment #3 from Andrew Pinski ---
Oh it is not on either x86_64 or aarch64:
/* { dg-do run { target vect_cmdline_needed } } */
[Bug testsuite/113167] [14 Regression] gcc.dg/tree-ssa/gen-vect-26.c started failing many targets after recent change
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113167 Andrew Pinski changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #2 from Andrew Pinski --- I will fix it (and also fix the testcase for aarch64, adding -mgeneral-regs-only ).
[Bug testsuite/113167] [14 Regression] gcc.dg/tree-ssa/gen-vect-26.c started failing many targets after recent change
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113167 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |14.0 Last reconfirmed||2023-12-29 Component|tree-optimization |testsuite Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Keywords||testsuite-fail --- Comment #1 from Andrew Pinski --- Just the testcase needs to be fixed/changed and added: #pragma GCC novector in front of the check loop. Note the testcase was already failing on aarch64 which is why it was not noticed by Tamar.
[Bug tree-optimization/113167] New: [14 Regression] gcc.dg/tree-ssa/gen-vect-26.c started failing many targets after recent change
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113167 Bug ID: 113167 Summary: [14 Regression] gcc.dg/tree-ssa/gen-vect-26.c started failing many targets after recent change Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: law at gcc dot gnu.org Target Milestone: --- Many targets are now seeing this failure: FAIL: gcc.dg/tree-ssa/gen-vect-26.c scan-tree-dump-times vect "Alignment of access forced using peeling" 1 Which has been bisected to: commit 01f4251b8775c832a92d55e2df57c9ac72eaceef (HEAD) Author: Tamar Christina Date: Sun Dec 24 19:18:12 2023 + middle-end: Support vectorization of loops with multiple exits. Hi All, This patch adds initial support for early break vectorization in GCC. In other words it implements support for vectorization of loops with multiple exits. The support is added for any target that implements a vector cbranch optab, this includes both fully masked and non-masked targets. [ ... ] The regression is seen on just about every cross target I'm testing. So just to pick one, fr30-elf. Since this is a scan failure, you don't need a full toolchain to reproduce, just the compiler proper.
[Bug target/113133] [14 Regression] ICE: SIGSEGV in mark_label_nuses(rtx_def*) (emit-rtl.cc:3896) with -O -fno-tree-ter -mavx512f -march=barcelona
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113133 --- Comment #6 from Haochen Jiang --- Aha, I see what happened. x/ymm16+ are usable for AVX512F w/o AVX512VL and that is why I added that to allow them. Let me find a way to see if we can fix this.
[Bug target/113133] [14 Regression] ICE: SIGSEGV in mark_label_nuses(rtx_def*) (emit-rtl.cc:3896) with -O -fno-tree-ter -mavx512f -march=barcelona
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113133 --- Comment #5 from Haochen Jiang --- (In reply to Uroš Bizjak from comment #3) > This patch also fixes the failure: > > --cut here-- > diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md > index ca6dbf42a6d..cdb9ddc4eb3 100644 > --- a/gcc/config/i386/i386.md > +++ b/gcc/config/i386/i386.md > @@ -5210,7 +5210,7 @@ (define_split > && optimize_insn_for_speed_p () > && reload_completed > && (!EXT_REX_SSE_REG_P (operands[0]) > - || TARGET_AVX512VL || TARGET_EVEX512)" > + || TARGET_AVX512VL)" > [(set (match_dup 2) > (float_extend:V2DF >(vec_select:V2SF > --cut here-- Hmm, it looks weird I added EVEX512 near AVX512VL, checking why I am doing that.
[Bug go/113143] Remove usage of ucontext.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113143 --- Comment #11 from Alexander von Gluck --- Hm.. Could you point me to where Linux is using the (get/set/swap)context calls? I still haven't found them in the codebase. I don't want to miss any edge cases if I work up a patch.
[Bug middle-end/113130] `abs(a) == b` could be expanded as `(a == b || a == -b)`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113130
--- Comment #2 from Andrew Pinski ---
Oh right but the following testcase it should be valid to do and not worry
about INT_MIN either:
```
int f(int a, unsigned short c)
{
// c = 1;
int b = a > 0 ? a : -a;
return b == c;
}
int f1(int a, unsigned short c)
{
// c = 1;
return a == -c || a == c;
}
```
[Bug middle-end/113130] `abs(a) == b` could be expanded as `(a == b || a == -b)`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113130 --- Comment #1 from Joseph S. Myers --- Note that the first example (and the suggested one with ABS_EXPR) has undefined behavior for a == INT_MIN, while the second has undefined behavior for c == INT_MIN (and is also not equivalent to the first for negative c).
[Bug libstdc++/113159] More robust std::sort for silly comparator functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113159 --- Comment #5 from Andrew Pinski --- (In reply to Jan Engelhardt from comment #4) > >And in upcoming Glibc-2.39 there will be a major reimplementation of qsort > > Even so, a recent commit strongly suggests that sticking to array bounds > remains important: So IIRC the reasoning is because of bugs in older (current as of a month ago even) versions of LLVM which crashes on a comparison with itself. Basically broken comparison functions are forcing workarounds really. Note GCC uses its own sort function due which is designed to detect the brokeness of comparison functions even; see PR 109187, PR 90282, PR 87281, PR 84345, etc.
[Bug libstdc++/113159] More robust std::sort for silly comparator functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113159 Jan Engelhardt changed: What|Removed |Added CC||fweimer at redhat dot com --- Comment #4 from Jan Engelhardt --- >And in upcoming Glibc-2.39 there will be a major reimplementation of qsort Even so, a recent commit strongly suggests that sticking to array bounds remains important: commit b9390ba93676c4b1e87e218af5e7e4bb596312ac Author: Florian Weimer Date: Mon Dec 4 06:35:56 2023 +0100 stdlib: Fix array bounds protection in insertion sort phase of qsort
[Bug c/113166] RISC-V: Redundant move instructions in RVV intrinsic codes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113166
--- Comment #1 from JuzheZhong ---
Suspect it is subreg issue again.
#include "riscv_vector.h"
void foo (void *in, void *out, int x)
{
vint32m2_t dup = __riscv_vmv_v_x_i32m2 (x, 8);
vint32m2x4_t tuple1 = __riscv_vlseg4e32_v_i32m2x4 (in, 8);
vint32m2x4_t tuple2 = __riscv_vlseg4e32_v_i32m2x4 (in + 16, 8);
vint32m2_t tmp1 = __riscv_vadd_vv_i32m2 (dup, __riscv_vget_v_i32m2x4_i32m2
(tuple2, 0), 8);
vint32m2_t tmp2 = __riscv_vmul_vv_i32m2 (tmp1, __riscv_vget_v_i32m2x4_i32m2
(tuple1, 0), 8);
tmp1 = __riscv_vmul_vv_i32m2 (tmp1, __riscv_vget_v_i32m2x4_i32m2 (tuple1,
1), 8);
vint32m2_t tmp3 = __riscv_vadd_vv_i32m2 (dup, __riscv_vget_v_i32m2x4_i32m2
(tuple2, 2), 8);
vint32m2_t tmp4 = __riscv_vmul_vv_i32m2 (tmp3, __riscv_vget_v_i32m2x4_i32m2
(tuple1, 2), 8);
vint32m2_t tmp9 = __riscv_vmul_vv_i32m2 (tmp3, __riscv_vget_v_i32m2x4_i32m2
(tuple1, 3), 8);
vint32m2_t tmp5 = __riscv_vadd_vv_i32m2_tu (tmp1, tmp9, tmp9, 8);
vint32m2_t tmp6 = __riscv_vadd_vv_i32m2_tu (tmp2, tmp9, tmp9, 8);
vint32m2_t tmp7 = __riscv_vadd_vv_i32m2_tu (tmp3, tmp9, tmp9, 8);
vint32m2_t tmp8 = __riscv_vadd_vv_i32m2_tu (tmp4, tmp9, tmp9, 8);
vint32m2x4_t create = __riscv_vcreate_v_i32m2x4 (tmp5, tmp6, tmp7, tmp8);
__riscv_vsseg4e32_v_i32m2x4 (out, create, 8);
//__riscv_vse32_v_i32m2 (out, tmp5, 8);
//__riscv_vse32_v_i32m2 (out + 16, tmp6, 8);
//__riscv_vse32_v_i32m2 (out + 32, tmp7, 8);
//__riscv_vse32_v_i32m2 (out + 64, tmp8, 8);
}
has move instructions.
But
#include "riscv_vector.h"
void foo (void *in, void *out, int x)
{
vint32m2_t dup = __riscv_vmv_v_x_i32m2 (x, 8);
vint32m2x4_t tuple1 = __riscv_vlseg4e32_v_i32m2x4 (in, 8);
vint32m2x4_t tuple2 = __riscv_vlseg4e32_v_i32m2x4 (in + 16, 8);
vint32m2_t tmp1 = __riscv_vadd_vv_i32m2 (dup, __riscv_vget_v_i32m2x4_i32m2
(tuple2, 0), 8);
vint32m2_t tmp2 = __riscv_vmul_vv_i32m2 (tmp1, __riscv_vget_v_i32m2x4_i32m2
(tuple1, 0), 8);
tmp1 = __riscv_vmul_vv_i32m2 (tmp1, __riscv_vget_v_i32m2x4_i32m2 (tuple1,
1), 8);
vint32m2_t tmp3 = __riscv_vadd_vv_i32m2 (dup, __riscv_vget_v_i32m2x4_i32m2
(tuple2, 2), 8);
vint32m2_t tmp4 = __riscv_vmul_vv_i32m2 (tmp3, __riscv_vget_v_i32m2x4_i32m2
(tuple1, 2), 8);
vint32m2_t tmp9 = __riscv_vmul_vv_i32m2 (tmp3, __riscv_vget_v_i32m2x4_i32m2
(tuple1, 3), 8);
vint32m2_t tmp5 = __riscv_vadd_vv_i32m2_tu (tmp1, tmp9, tmp9, 8);
vint32m2_t tmp6 = __riscv_vadd_vv_i32m2_tu (tmp2, tmp9, tmp9, 8);
vint32m2_t tmp7 = __riscv_vadd_vv_i32m2_tu (tmp3, tmp9, tmp9, 8);
vint32m2_t tmp8 = __riscv_vadd_vv_i32m2_tu (tmp4, tmp9, tmp9, 8);
__riscv_vse32_v_i32m2 (out, tmp5, 8);
__riscv_vse32_v_i32m2 (out + 16, tmp6, 8);
__riscv_vse32_v_i32m2 (out + 32, tmp7, 8);
__riscv_vse32_v_i32m2 (out + 64, tmp8, 8);
}
No move instructions
[Bug c/113166] New: RISC-V: Redundant move instructions in RVV intrinsic codes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113166
Bug ID: 113166
Summary: RISC-V: Redundant move instructions in RVV intrinsic
codes
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: ---
https://godbolt.org/z/rMaz9jqej
#include "riscv_vector.h"
void foo (void *in, void *out, int x)
{
vint32m2_t dup = __riscv_vmv_v_x_i32m2 (x, 8);
vint32m2x4_t tuple1 = __riscv_vlseg4e32_v_i32m2x4 (in, 8);
vint32m2x4_t tuple2 = __riscv_vlseg4e32_v_i32m2x4 (in + 16, 8);
vint32m2_t tmp1 = __riscv_vadd_vv_i32m2 (dup, __riscv_vget_v_i32m2x4_i32m2
(tuple2, 0), 8);
vint32m2_t tmp2 = __riscv_vmul_vv_i32m2 (tmp1, __riscv_vget_v_i32m2x4_i32m2
(tuple1, 0), 8);
tmp1 = __riscv_vmul_vv_i32m2 (tmp1, __riscv_vget_v_i32m2x4_i32m2 (tuple1,
1), 8);
vint32m2_t tmp3 = __riscv_vadd_vv_i32m2 (dup, __riscv_vget_v_i32m2x4_i32m2
(tuple2, 2), 8);
vint32m2_t tmp4 = __riscv_vmul_vv_i32m2 (tmp3, __riscv_vget_v_i32m2x4_i32m2
(tuple1, 2), 8);
vint32m2_t tmp9 = __riscv_vmul_vv_i32m2 (tmp3, __riscv_vget_v_i32m2x4_i32m2
(tuple1, 3), 8);
vint32m2_t tmp5 = __riscv_vnmsub_vv_i32m2 (__riscv_vget_v_i32m2x4_i32m2
(tuple1, 0), tmp9,tmp9, 8);
vint32m2_t tmp6 = __riscv_vmacc_vv_i32m2 (__riscv_vget_v_i32m2x4_i32m2
(tuple1, 1), tmp9,tmp9, 8);
vint32m2_t tmp7 = __riscv_vnmsac_vv_i32m2 (__riscv_vget_v_i32m2x4_i32m2
(tuple1, 2), tmp9,tmp9, 8);
vint32m2_t tmp8 = __riscv_vmacc_vv_i32m2 (__riscv_vget_v_i32m2x4_i32m2
(tuple1, 3), tmp9,tmp9, 8);
vint32m2x4_t create = __riscv_vcreate_v_i32m2x4 (tmp5, tmp6, tmp7, tmp8);
__riscv_vsseg4e32_v_i32m2x4 (out, create, 8);
}
GCC:
foo:
addia5,a0,16
vsetivlizero,8,e32,m2,ta,ma
vlseg4e32.v v16,(a5)
vlseg4e32.v v8,(a0)
vmv.v.x v2,a2
vadd.vv v2,v2,v20
vmul.vv v2,v2,v14
vmv.v.v v4,v8
vnmsub.vv v4,v2,v2
vmv.v.v v18,v10
vmacc.vvv18,v2,v2
vmv2r.v v16,v4
vmv.v.v v20,v12
vnmsac.vv v20,v2,v2
vmv.v.v v22,v14
vmacc.vvv22,v2,v2
vsseg4e32.v v16,(a1)
ret
Clang:
foo:# @foo
vsetivlizero, 8, e32, m2, ta, ma
addia3, a0, 16
vlseg4e32.v v8, (a3)
vlseg4e32.v v14, (a0)
vmv.v.x v8, a2
vadd.vv v8, v8, v12
vmul.vv v8, v8, v20
vnmsub.vv v14, v8, v8
vmacc.vvv16, v8, v8
vnmsac.vv v18, v8, v8
vmadd.vvv8, v8, v20
vmv.v.v v20, v8
vsseg4e32.v v14, (a1)
ret
[Bug tree-optimization/113120] during GIMPLE pass: bitintlower ICE: SIGSEGV with _BitInt() at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113120 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2023-12-28 --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug target/110899] RFE: Attributes preserve_most and preserve_all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110899 --- Comment #13 from Andrew Pinski --- Seems to be most of this should not implemented this way but rather an IPA RA pass (which GCC already does but not always and definitely not across IPA boundaries).
[Bug tree-optimization/113134] gcc does not version loops with early break conditions that don't have side-effects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113134 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement Component|c |tree-optimization
[Bug fortran/113165] Code containing more than one type declaration for a variable results in confusing error messages from compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113165
--- Comment #2 from kargl at gcc dot gnu.org ---
With the attached example code and the patch at the end of this
message, gfortran can be changes to identify both lines of code.
Fixing the run-on errors when -fimplicit-none is used is left as
an exercise for a new contributor or will be ignored until such
time as someone closes this bug report.
% gfcx -c e.f90
e.f90:3:30:
3 | double precision a,b,c,d,f,g
| 1
4 | integer i,j,k,l
5 | double precision d,q,r ! 'd' was already declared as double
prec.
|2
Error: Symbol ‘d’ declared at (1) already has basic type of REAL and cannot
appear in the declaration at (2)
diff --git a/gcc/fortran/symbol.cc b/gcc/fortran/symbol.cc
index a6078bc608a..7fa1839323b 100644
--- a/gcc/fortran/symbol.cc
+++ b/gcc/fortran/symbol.cc
@@ -2015,8 +2015,9 @@ gfc_add_type (gfc_symbol *sym, gfc_typespec *ts, locus
*where)
gfc_error ("Symbol %qs at %L already has basic type of %s",
sym->ns->proc_name->name, where, gfc_basic_typename (type));
else
- gfc_error ("Symbol %qs at %L already has basic type of %s", sym->name,
- where, gfc_basic_typename (type));
+ gfc_error ("Symbol %qs declared at %L already has basic type of %s "
+ "and cannot appear in the declaration at %L", sym->name,
+ >declared_at, gfc_basic_typename (type), where);
return false;
}
[Bug target/110934] m68k: ICE with -fzero-call-used-regs=all compiling openssh 9.3p2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110934 Andrew Pinski changed: What|Removed |Added CC||ats-gccbugs at offog dot org --- Comment #10 from Andrew Pinski --- *** Bug 113086 has been marked as a duplicate of this bug. ***
[Bug target/113086] m68k: ICE at emit-rtl.cc:2287 with -fzero-call-used-regs=all -fPIE compiling openssh 9.6p1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113086 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #2 from Andrew Pinski --- Dup of bug 110934. *** This bug has been marked as a duplicate of bug 110934 ***
[Bug target/113086] m68k: ICE at emit-rtl.cc:2287 with -fzero-call-used-regs=all -fPIE compiling openssh 9.6p1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113086 Mikael Pettersson changed: What|Removed |Added CC||mikpelinux at gmail dot com --- Comment #1 from Mikael Pettersson --- Bisected to the same rev. as PR110934, and fixed by the same proposed patch. Please mark it as a duplicate of PR110934.
[Bug fortran/81615] save-temps and gfortran produces *.f90 files instead of *.i or *i90 files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81615 --- Comment #22 from GCC Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:2cb93e6686e4af5725d8c919cf19f535a7f3aa33 commit r14-6857-g2cb93e6686e4af5725d8c919cf19f535a7f3aa33 Author: Rimvydas Jasinskas Date: Sat Dec 23 18:59:09 2023 + Fortran: Add Developer Options mini-section to documentation Separate out -fdump-* options to the new section. Sort by option name. While there, document -save-temps intermediates. gcc/fortran/ChangeLog: PR fortran/81615 * invoke.texi: Add Developer Options section. Move '-fdump-*' to it. Add small examples about changed '-save-temps' behavior. Signed-off-by: Rimvydas Jasinskas
[Bug target/113133] [14 Regression] ICE: SIGSEGV in mark_label_nuses(rtx_def*) (emit-rtl.cc:3896) with -O -fno-tree-ter -mavx512f -march=barcelona
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113133 Uroš Bizjak changed: What|Removed |Added CC||haochen.jiang at intel dot com --- Comment #4 from Uroš Bizjak --- Caused by r14-4499-gc1eef66baa8dde706d7ea6921648e6016dc7c93d
[Bug target/113133] [14 Regression] ICE: SIGSEGV in mark_label_nuses(rtx_def*) (emit-rtl.cc:3896) with -O -fno-tree-ter -mavx512f -march=barcelona
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113133 Uroš Bizjak changed: What|Removed |Added Target Milestone|--- |14.0 --- Comment #3 from Uroš Bizjak --- This patch also fixes the failure: --cut here-- diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md index ca6dbf42a6d..cdb9ddc4eb3 100644 --- a/gcc/config/i386/i386.md +++ b/gcc/config/i386/i386.md @@ -5210,7 +5210,7 @@ (define_split && optimize_insn_for_speed_p () && reload_completed && (!EXT_REX_SSE_REG_P (operands[0]) - || TARGET_AVX512VL || TARGET_EVEX512)" + || TARGET_AVX512VL)" [(set (match_dup 2) (float_extend:V2DF (vec_select:V2SF --cut here--
[Bug target/113133] [14 Regression] ICE: SIGSEGV in mark_label_nuses(rtx_def*) (emit-rtl.cc:3896) with -O -fno-tree-ter -mavx512f -march=barcelona
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113133
--- Comment #2 from Uroš Bizjak ---
Another testcase:
--cut here--
void
foo1 (double *d, float f)
{
register float x __asm ("xmm16") = f;
asm volatile ("" : "+v" (x));
*d = x;
}
void
foo2 (float *f, double d)
{
register double x __asm ("xmm16") = d;
asm volatile ("" : "+v" (x));
*f = x;
}
--cut here--
[Bug target/113133] [14 Regression] ICE: SIGSEGV in mark_label_nuses(rtx_def*) (emit-rtl.cc:3896) with -O -fno-tree-ter -mavx512f -march=barcelona
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113133 Uroš Bizjak changed: What|Removed |Added Last reconfirmed||2023-12-28 Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |ubizjak at gmail dot com --- Comment #1 from Uroš Bizjak --- Created attachment 56962 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56962=edit Proposed patch Patch in testing. lowpart_subreg can't handle: lowpart_subreg (V4SFmode, operands[0], DFmode); and lowpart_subreg (V2DFmode, operands[0], SFmode); subreg conversions and will return NULL_RTX for these cases.
[Bug libstdc++/113160] Const valarray (g)slice and indirect_array fail to match valarray in template functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113160 --- Comment #4 from Jonathan Wakely --- Or more precisely, you can't deduce a const valarray from it.
[Bug libstdc++/113160] Const valarray (g)slice and indirect_array fail to match valarray in template functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113160 --- Comment #3 from Jonathan Wakely --- > Any function returning a valarray is permitted to return an object > of another type, provided all the const member functions of valarray > are also applicable to this type. This means you can do v[0] on the type, it doesn't mean you can convert it to a const valarray&
[Bug libstdc++/113159] More robust std::sort for silly comparator functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113159 Alexander Monakov changed: What|Removed |Added CC||amonakov at gcc dot gnu.org --- Comment #3 from Alexander Monakov --- Can you outline what would merge criteria for such an enhancement look like? If it comes at a cost of increased code complexity and runtime overhead, what sacrifice is acceptable in the name of increased robustness?
[Bug target/113161] Add a special "ramfunc" attribute for sections in the linker script (*.ld files)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113161 Andrew Pinski changed: What|Removed |Added Keywords||diagnostic Severity|normal |enhancement --- Comment #1 from Andrew Pinski --- The Linux kernel handles this without an attribute via an external program that checks the section after the compiling. Maybe for your use case you could reuse that ...
[Bug libstdc++/113159] More robust std::sort for silly comparator functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113159 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2023-12-28 Ever confirmed|0 |1 Resolution|INVALID |--- Status|RESOLVED|NEW --- Comment #2 from Jonathan Wakely --- I disagree, it's a perfectly valid wish. But somebody needs to work on it, or nothing will happen and it will just stay open forever.
[Bug middle-end/113164] [missed optimization] struct fields should not alias
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113164 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement Keywords||alias, missed-optimization
[Bug tree-optimization/113137] [14 regression] Failed bootstrap with -O3 -march=znver2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113137
--- Comment #10 from Tamar Christina ---
Ok, so this bug is simply fixed by:
diff --git a/gcc/tree-vect-loop.cc b/gcc/tree-vect-loop.cc
index f51ae3e719e..e7a5917bc4c 100644
--- a/gcc/tree-vect-loop.cc
+++ b/gcc/tree-vect-loop.cc
@@ -976,7 +976,8 @@ vec_init_loop_exit_info (class loop *loop)
if (number_of_iterations_exit_assumptions (loop, exit, _desc,
NULL)
&& !chrec_contains_undetermined (niter_desc.niter))
{
- if (!niter_desc.may_be_zero || !candidate)
+ tree may_be_zero = niter_desc.may_be_zero;
+ if ((may_be_zero && integer_zerop (may_be_zero)) || !candidate)
candidate = exit;
}
}
because niter_desc.may_be_zero is not a boolean but instead a tree that encodes
a boolean.
Due to this we were forcing much more complicated loops than required. However
we *should* be able to handle these complicated loops since we don't know when
they'll occur.. so I'll post a companion patch to fix those too.
[Bug target/110934] m68k: ICE with -fzero-call-used-regs=all compiling openssh 9.3p2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110934 --- Comment #9 from Mikael Pettersson --- Created attachment 56961 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56961=edit proposed fix, only tested on the given test case so far
[Bug fortran/113165] Code containing more than one type declaration for a variable results in confusing error messages from compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113165 kargl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P5 CC||kargl at gcc dot gnu.org Severity|normal |enhancement --- Comment #1 from kargl at gcc dot gnu.org --- You are hitting a run-on error caused by the first reported error. If you are compiling old code or code you are currently writing or code with a questionable pedigree, use the -fmax-errors=1 option. For the record, your bug report is confusing ;-) Because it includes error messages associated with your attached example: program multDecls double precision a,b,c,d,f,g integer i,j,k,l double precision d,q,r ! 'd' was already declared as double prec. d = 65536.0d0 r = sqrt(d) print *,' r = ',r,' p = ',p end program but you refer to netlib code with a duplicate 't' declaration. Due to the first error about 'd', the rest of the declaration is discarded. The result is that 'q,r' have not been declared and so have implicit types. The option '-fimplicit-none' is telling you about this problem. Fix the first error and the run-on errors go away. Note, "Error: Symbol 'd' at (1) already has basic type of REAL" simply means that 'd' has been typed as a REAL entity irrespective of the kind. It does not mean that 'd' has been given a single precision type of REAL(4). I suppose someone could change the error message to a more generic "Error: Symbol 'd' at (1) has already been declared." or some such wording.
[Bug target/110934] m68k: ICE with -fzero-call-used-regs=all compiling openssh 9.3p2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110934 --- Comment #8 from Mikael Pettersson --- The generic code synthesizes a move from CONST0_RTX (XFmode) to an XFmode FP reg, and that causes the ice. Forcing the mode of both to SFmode or DFmode avoids the ice and generates sane-looking code. The XFmode comes from the generic code's use of regno_reg_rtx[regno] (in zcur_select_mode_rtx). I'm not sure if overriding TARGET_ZERO_CALL_USED_REGS on m68k is the right thing to do, or if it only masks a deeper problem within the backend.
[Bug fortran/113165] New: Code containing more than one type declaration for a variable results in confusing error messages from compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113165 Bug ID: 113165 Summary: Code containing more than one type declaration for a variable results in confusing error messages from compiler Product: gcc Version: 11.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: xecej4 at outlook dot com Target Milestone: --- Created attachment 56960 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56960=edit Fixed form Fortran77 source file that causes compiler to issue confusing messages Some old Fortran codes (e.g., www.netlib.org/ode/epsode.f ) may contain duplicate declarations of some variables. Lines 1239-1241 of epsode.f: double precision eps, epsj, h, hmax, hmin, pw, save1, save2, 1 ss, t, uround, ymax double precision d, r, r0, t, yj The variable t is declared twice, albeit with the same type and kind. Gfortran correctly flags this error, but seems to go farther and mark the variable t as implicitly typed single precision REAL, causing the issuing a number of misleading error messages when the concerned variable is used in expressions later on in the program unit. I enclose a short program to illustrate. Please compile the program with (a) no options, (b) with -Wall and (c) with -fimplicit-none. Case (c) results in: muldecl.f:4:24: 4 | double precision d,q,r ! 'd' was already declared as double prec. |1 Error: Symbol 'd' at (1) already has basic type of REAL muldecl.f:7:7: 7 | r = sqrt(d) | 1 Error: Symbol 'r' at (1) has no IMPLICIT type I suspect that the multiple declaration of d has caused even the unrepeated declaration of r to be tainted.
[Bug middle-end/113164] New: [missed optimization] struct fields should not alias
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113164
Bug ID: 113164
Summary: [missed optimization] struct fields should not alias
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: powerboat9.gamer at gmail dot com
Target Milestone: ---
I have the following code
> struct sss {
> int a;
> int b;
> };
>
> int foo(struct sss *a, struct sss *b) {
> return >a == >b;
> }
When I compile it with
> gcc -c -O3 -Wall -Wextra test.c
I get
> :
>0: 48 83 c6 04 add$0x4,%rsi
>4: 31 c0 xor%eax,%eax
>6: 48 39 fecmp%rdi,%rsi
>9: 0f 94 c0sete %al
>c: c3 ret
, but GCC should be able to infer that the two pointers being compared can not
alias.
[Bug tree-optimization/113137] [14 regression] Failed bootstrap with -O3 -march=znver2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113137 --- Comment #9 from Tamar Christina --- Ok, have a working patch but it's a bit ugly, working on cleaning it up.
[Bug middle-end/113163] [14 Regression][GCN] ICE in vect_peel_nonlinear_iv_init, at tree-vect-loop.cc:9420
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113163 --- Comment #8 from Tamar Christina --- Created attachment 56959 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56959=edit nonlinear IV
[Bug middle-end/113163] [14 Regression][GCN] ICE in vect_peel_nonlinear_iv_init, at tree-vect-loop.cc:9420
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113163 Tamar Christina changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Priority|P3 |P1 Last reconfirmed||2023-12-28 Assignee|unassigned at gcc dot gnu.org |tnfchris at gcc dot gnu.org --- Comment #7 from Tamar Christina --- ok, managed to reproduce using a cross cc1. This seems to happen because the vectorizer decides to use partial vectors to vectorize the loop and the target picks a nonlinear induction step which we can't support for early breaks. The attached patch fixes it by rejecting these kind of inductions when partial vectors are forced. I'll submit the patch for when maintainers are back from holidays.
[Bug preprocessor/108900] [libcpp] cpp gives wrong line number information with a file huge number of lines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108900 --- Comment #3 from Libin Dang --- For the uploaded test case, `-fdump-internal-locations' gives the following output: ORDINARY MAP: 9 location_t interval: 274912 <= loc < 1342178464 file: header3.h starting at line: 1 column and range bits: 12 column bits: 7 range bits: 5 reason: 0 (LC_ENTER) included from location: 270816 (in ordinary map 8) header3.h: 1|loc:274912|header3 begins |44 |9900011133 |47047036036926 |46802468024680 header3.h: 2|loc:279008|header3 begins |99 |0011133344 |47036036926925 |02468024680246 ... header3.h:327613|loc:1342173664|header3 begins |33 |67778889990001 |92692582581481 |68024680246802 header3.h:327614|loc:1342177760|#include "header2.h" |7778 |78889990001112223334 |92582581481470470360 |24680246802468024680 However, location 1342173664 (0x41e0) < LINE_MAP_MAX_LOCATION_WITH_PACKED_RANGES (0x5000) but location 1342177760 (0x51e0) > LINE_MAP_MAX_LOCATION_WITH_PACKED_RANGES, therefore these two locations should not in the same line map. In linemap_line_start() of libcpp/line-map.cc, if it does not create new line map (add_map is false), it will return the following new location: r = set->highest_line + (line_delta << map->m_column_and_range_bits); and this location will be included in the last ordinary map, even that location is greater than LINE_MAP_MAX_LOCATION_WITH_PACKED_RANGES and therefore should be in a new line map. The following patch can fix this issue: --- a/libcpp/line-map.cc +++ b/libcpp/line-map.cc @@ -860,7 +860,9 @@ linemap_line_start (line_maps *set, linenum_type to_line, || (highest > LINE_MAP_MAX_LOCATION_WITH_PACKED_RANGES && map->m_range_bits > 0) || (highest > LINE_MAP_MAX_LOCATION_WITH_COLS - && (set->max_column_hint || highest >= LINE_MAP_MAX_LOCATION))) + && (set->max_column_hint || highest >= LINE_MAP_MAX_LOCATION)) + || ((set->highest_line + (line_delta << map->m_column_and_range_bits)) + > LINE_MAP_MAX_LOCATION_WITH_PACKED_RANGES)) add_map = true; else max_column_hint = set->max_column_hint; After applied this change, the `-fdump-internal-locations' options gives the following results: ORDINARY MAP: 9 location_t interval: 274912 <= loc < 1342174176 file: header3.h starting at line: 1 column and range bits: 12 column bits: 7 range bits: 5 reason: 0 (LC_ENTER) included from location: 270816 (in ordinary map 8) header3.h: 1|loc:274912|header3 begins |44 |9900011133 |47047036036926 |46802468024680 header3.h: 2|loc:279008|header3 begins |99 |0011133344 |47036036926925 |02468024680246 ... header3.h:327613|loc:1342173664|header3 begins |33 |67778889990001 |92692582581481 |68024680246802 ORDINARY MAP: 10 location_t interval: 1342174176 <= loc < 1342178272 file: header3.h starting at line: 327614 column and range bits: 12 column bits: 7 range bits: 5 reason: 2 (LC_RENAME) included from location: 270816 (in ordinary map 8) header3.h:327614|loc:1342174176|#include "header2.h" | |2223335556667778 |04703603692692582581 |80246802468024680246
[Bug target/110934] m68k: ICE with -fzero-call-used-regs=all compiling openssh 9.3p2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110934 --- Comment #7 from Mikael Pettersson --- The issue appears to be the clearing of FP regs. If I add an m68k-specific version of TARGET_ZERO_CALL_USED_REGS which handles integer (address and data) regs but skips FP regs, then the test case compiles fine.
[Bug c++/113124] g++ should relax designated initialiser rules for trivial classes (read: C structures) and C arrays.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113124 --- Comment #8 from Xi Ruoyao --- (In reply to Alexey Dobriyan from comment #7) > > fancy C++ extension > > It is not fancy. > > C99 initialisers is the only feature where Modern C beats Modern C++. Fancy or not you should ask the standard committee first. If they say "hey this is useful but we'd like to see an implementation first" we can add it as an extension.
[Bug middle-end/113163] [14 Regression][GCN] ICE in vect_peel_nonlinear_iv_init, at tree-vect-loop.cc:9420
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113163 --- Comment #6 from Tobias Burnus --- and for that condition, we have: 3375 if (!integer_onep (*step_vector)) (gdb) p debug_tree(*step_vector) constant 8>
[Bug middle-end/113163] [14 Regression][GCN] ICE in vect_peel_nonlinear_iv_init, at tree-vect-loop.cc:9420
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113163
--- Comment #5 from Tobias Burnus ---
While higher at the call stack:
#3 0x0148714f in vect_transform_loop
(loop_vinfo=loop_vinfo@entry=0x350f2a0,
loop_vectorized_call=loop_vectorized_call@entry=0x0)
at src/gcc-mainline/gcc/tree-vect-loop.cc:11911
11911 epilogue = vect_do_peeling (loop_vinfo, niters, nitersm1,
_vector,
(gdb) p debug_tree(niters)
constant 6>
One level down:
#2 0x01498154 in vect_do_peeling
(loop_vinfo=loop_vinfo@entry=0x350f2a0, niters=,
niters@entry=0x77bb2030,
nitersm1=nitersm1@entry=0x77bb2c78,
niters_vector=niters_vector@entry=0x7fffda60,
step_vector=step_vector@entry=0x7fffda68,
niters_vector_mult_vf_var=niters_vector_mult_vf_var@entry=0x7fffda70,
th=, check_profitability=,
niters_no_overflow=, advance=)
at src/gcc-mainline/gcc/tree-vect-loop-manip.cc:3399
3399vect_update_ivs_after_vectorizer (loop_vinfo,
niters_vector_mult_vf,
where niters_vector_mult_vf is ssa_name that fails in the assert.
The variable seems to be generated a few lines up in the same function (line
3375 and following):
if (!integer_onep (*step_vector))
{
/* On exit from the loop we will have an easy way of calcalating
NITERS_VECTOR / STEP * STEP. Install a dummy definition
until then. */
niters_vector_mult_vf = make_ssa_name (TREE_TYPE (*niters_vector));
SSA_NAME_DEF_STMT (niters_vector_mult_vf) = gimple_build_nop ();
*niters_vector_mult_vf_var = niters_vector_mult_vf;
}
else
vect_gen_vector_loop_niters_mult_vf (loop_vinfo, *niters_vector,
_vector_mult_vf);
[Bug middle-end/113163] [14 Regression][GCN] ICE in vect_peel_nonlinear_iv_init, at tree-vect-loop.cc:9420
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113163 --- Comment #4 from Tamar Christina --- Hmm so can't seem to reproduce it with x86_64 or aarch64. let me build a --target=amdgcn-amdhsa
[Bug middle-end/113163] [14 Regression][GCN] ICE in vect_peel_nonlinear_iv_init, at tree-vect-loop.cc:9420
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113163 --- Comment #3 from Tamar Christina --- Thanks, taking a look.
[Bug middle-end/113163] [14 Regression][GCN] ICE in vect_peel_nonlinear_iv_init, at tree-vect-loop.cc:9420
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113163 --- Comment #2 from Tobias Burnus --- Created attachment 56958 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56958=edit Reduced testcase ( $ amdgcn-amdhsa-gcc -g -O2 inp5.i -march=gfx900 during GIMPLE pass: vect inp5.i: In function '_l64a_r': inp5.i:4:1: internal compiler error: in vect_peel_nonlinear_iv_init, at tree-vect-loop.cc:9420 4 | _l64a_r (struct _reent *rptr, | ^~~ 0x94cc17 vect_peel_nonlinear_iv_init(gimple**, tree_node*, tree_node*, tree_node*, vect_induction_op_type) /net/build5-fossa-cs/scratch/tburnus/fsf.mainline.x86_64-linux-gnu-amdgcn/src/gcc-mainline/gcc/tree-vect-loop.cc:9420 0x148bb04 vect_update_ivs_after_vectorizer src/gcc-mainline/gcc/tree-vect-loop-manip.cc:2267 0x1498153 vect_do_peeling(_loop_vec_info*, tree_node*, tree_node*, tree_node**, tree_node**, tree_node**, int, bool, bool, tree_node**) src/gcc-mainline/gcc/tree-vect-loop-manip.cc:3399 0x148714e vect_transform_loop(_loop_vec_info*, gimple*) src/gcc-mainline/gcc/tree-vect-loop.cc:11911 0x14c9544 vect_transform_loops src/gcc-mainline/gcc/tree-vectorizer.cc:1006 0x14c9bc3 try_vectorize_loop_1 src/gcc-mainline/gcc/tree-vectorizer.cc:1152 0x14c9bc3 try_vectorize_loop src/gcc-mainline/gcc/tree-vectorizer.cc:1182 0x14ca224 execute src/gcc-mainline/gcc/tree-vectorizer.cc:1298 * * * Breakpoint 1, vect_peel_nonlinear_iv_init (stmts=0x7fffd698, init_expr=0x77a56948, skip_niters=0x77bb8798, step_expr=0x77a64ba0, induction_type=vect_step_op_shr) at src/gcc-mainline/gcc/tree-vect-loop.cc:9420 9420 gcc_assert (TREE_CODE (skip_niters) == INTEGER_CST); (gdb) p debug_tree(skip_niters) unit-size align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x77b5e3f0 precision:32 min max > def_stmt GIMPLE_NOP version:54> $2 = void
[Bug middle-end/113163] [14 Regression][GCN] ICE in vect_peel_nonlinear_iv_init, at tree-vect-loop.cc:9420
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113163 Tamar Christina changed: What|Removed |Added CC||tnfchris at gcc dot gnu.org --- Comment #1 from Tamar Christina --- Hi, This does not contain enough information for me to try to reproduce the issue. Can you give me the full target triple, compile flag and how the compiler was configured? A reproducer would be helpful too.
[Bug c++/113124] g++ should relax designated initialiser rules for trivial classes (read: C structures) and C arrays.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113124 --- Comment #7 from Alexey Dobriyan --- > fancy C++ extension It is not fancy. C99 initialisers is the only feature where Modern C beats Modern C++.
[Bug middle-end/113163] New: [14 Regression][GCN] ICE in vect_peel_nonlinear_iv_init, at tree-vect-loop.cc:9420
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113163 Bug ID: 113163 Summary: [14 Regression][GCN] ICE in vect_peel_nonlinear_iv_init, at tree-vect-loop.cc:9420 Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org CC: tamar.christina at arm dot com Target Milestone: --- Target: amdgcn-amdhsa The ICE happens when building Newlib with the GCN compiler: during GIMPLE pass: vect In file included from src/accel_newlib-mainline/newlib/libc/stdlib/l64a.c:24: src/accel_newlib-mainline/newlib/libc/include/stdlib.h: In function 'l64a': src/accel_newlib-mainline/newlib/libc/include/stdlib.h:195:9: internal compiler error: in vect_peel_nonlinear_iv_init, at tree-vect-loop.cc:9420 195 | char * l64a (long __input); | ^~~~
[Bug tree-optimization/113144] [14 regression] ICE when building dpkg-1.21.15 in verify_dominators (error: dominator of 9 should be 48, not 12)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113144 David Binderman changed: What|Removed |Added CC||dcb314 at hotmail dot com --- Comment #7 from David Binderman --- I see this one also, while building libmpg. foundBugs $ ../results/bin/gcc -c -w -O3 bug993.c foundBugs $ ../results/bin/gcc -c -w -O3 -march=znver3 bug993.c src/libmpg123/format.c: In function ‘enc_chan_fit’: src/libmpg123/format.c:188:12: error: dominator of 70 should be 206, not 3 src/libmpg123/format.c:188:12: error: dominator of 71 should be 206, not 3 during GIMPLE pass: vect src/libmpg123/format.c:188:12: internal compiler error: in verify_dominators, at dominance.cc:1194
[Bug c++/113124] g++ should relax designated initialiser rules for trivial classes (read: C structures) and C arrays.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113124 Xi Ruoyao changed: What|Removed |Added CC||xry111 at gcc dot gnu.org --- Comment #6 from Xi Ruoyao --- Today we really don't want to introduce fancy C++ extensions. Have you sent this as a proposal to the standard committee? FWIW the Linux kernel code base is not relevant because Linus has absolutely no intention to allow using C++ there.
[Bug c/113162] RISC-V: Unexpected register spillings in vectorized codes and intrinsic codes that have subregs.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113162
--- Comment #1 from JuzheZhong ---
We can have this following reduced intrinsic codes to represent the subreg
issue:
https://godbolt.org/z/KfvT7hjnz
#include "riscv_vector.h"
void foo (void *in, void *out, int x)
{
vint32m2_t dup = __riscv_vmv_v_x_i32m2 (x, 8);
vint32m2x4_t tuple1 = __riscv_vlseg4e32_v_i32m2x4 (in, 8);
vint32m2x4_t tuple2 = __riscv_vlseg4e32_v_i32m2x4 (in + 16, 8);
vint32m2_t tmp1 = __riscv_vadd_vv_i32m2 (dup, __riscv_vget_v_i32m2x4_i32m2
(tuple2, 0), 8);
vint32m2_t tmp2 = __riscv_vmul_vv_i32m2 (tmp1, __riscv_vget_v_i32m2x4_i32m2
(tuple1, 0), 8);
tmp1 = __riscv_vmul_vv_i32m2 (tmp1, __riscv_vget_v_i32m2x4_i32m2 (tuple1,
1), 8);
vint32m2_t tmp3 = __riscv_vadd_vv_i32m2 (dup, __riscv_vget_v_i32m2x4_i32m2
(tuple2, 2), 8);
vint32m2_t tmp4 = __riscv_vmul_vv_i32m2 (tmp3, __riscv_vget_v_i32m2x4_i32m2
(tuple1, 2), 8);
vint32m2_t tmp9 = __riscv_vmul_vv_i32m2 (tmp3, __riscv_vget_v_i32m2x4_i32m2
(tuple1, 3), 8);
vint32m2_t tmp5 = __riscv_vnmsub_vv_i32m2 (tmp9,
__riscv_vget_v_i32m2x4_i32m2 (tuple2, 1), tmp2, 8);
vint32m2_t tmp6 = __riscv_vmacc_vv_i32m2 (tmp1,
__riscv_vget_v_i32m2x4_i32m2 (tuple1, 0), tmp3, 8);
vint32m2_t tmp7 = __riscv_vnmsac_vv_i32m2 (tmp4,
__riscv_vget_v_i32m2x4_i32m2 (tuple2, 3), tmp4, 8);
vint32m2_t tmp8 = __riscv_vmacc_vv_i32m2 (tmp3,
__riscv_vget_v_i32m2x4_i32m2 (tuple2, 3), __riscv_vget_v_i32m2x4_i32m2 (tuple1,
2), 8);
vint32m2x4_t create = __riscv_vcreate_v_i32m2x4 (tmp5, tmp6, tmp7, tmp8);
__riscv_vsseg4e32_v_i32m2x4 (out, create, 8);
}
GCC:
foo:
csrrt0,vlenb
sllit1,t0,1
addia5,a0,16
vsetivlizero,8,e32,m2,ta,ma
sub sp,sp,t1
vlseg4e32.v v8,(a0)
vlseg4e32.v v24,(a5)
vmv.v.x v2,a2
csrrt0,vlenb
vadd.vv v4,v2,v24
vadd.vv v2,v2,v28
vmul.vv v0,v4,v10
vmul.vv v16,v2,v12
vmul.vv v4,v4,v8
vs2r.v v16,0(sp)
sllit1,t0,1
vmul.vv v6,v2,v14
vmv.v.v v18,v0
vmacc.vvv18,v2,v8
vnmsub.vv v6,v26,v4
vmv.v.v v22,v2
vmacc.vvv22,v30,v12
vl2re32.v v4,0(sp)
vmv2r.v v16,v6
vnmsub.vv v4,v30,v4
vmv2r.v v20,v4
vsseg4e32.v v16,(a1)
add sp,sp,t1
jr ra
Clang:
foo:# @foo
vsetivlizero, 8, e32, m2, ta, ma
addia3, a0, 16
vlseg4e32.v v8, (a3)
vlseg4e32.v v16, (a0)
vmv.v.x v24, a2
vadd.vv v8, v24, v8
vmul.vv v26, v8, v16
vmul.vv v4, v8, v18
vadd.vv v8, v24, v12
vmul.vv v6, v8, v20
vmul.vv v2, v8, v22
vnmsub.vv v2, v10, v26
vmacc.vvv4, v8, v16
vnmsub.vv v6, v14, v6
vmacc.vvv8, v20, v14
vsseg4e32.v v2, (a1)
ret
With lehua's patch:
foo:
addia5,a0,16
vsetivlizero,8,e32,m2,ta,ma
vlseg4e32.v v8,(a0)
vlseg4e32.v v24,(a5)
vmv.v.x v2,a2
vadd.vv v4,v2,v24
vadd.vv v2,v2,v28
vmul.vv v10,v4,v10
vmul.vv v14,v2,v14
vmul.vv v4,v4,v8
vmul.vv v6,v2,v12
vmv.v.v v16,v14
vnmsub.vv v16,v26,v4
vmv.v.v v18,v10
vmacc.vvv18,v2,v8
vmv.v.v v20,v6
vnmsub.vv v20,v30,v6
vmv.v.v v22,v2
vmacc.vvv22,v30,v12
vsseg4e32.v v16,(a1)
ret
No spillings, but has some redundant vmv.v.v which should be other issues.
[Bug c/113162] New: RISC-V: Unexpected register spillings in vectorized codes and intrinsic codes that have subregs.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113162
Bug ID: 113162
Summary: RISC-V: Unexpected register spillings in vectorized
codes and intrinsic codes that have subregs.
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: ---
This following case:
int f[12][100];
void foo (int v)
{
for (int r = 0; r < 100; r += 4)
{
int i = r + 1;
f[0][r] = f[1][r] * (f[2][r] + v) - f[1][i] * (f[2][i]);
f[0][i] = f[1][r] * (f[2][i]) + f[1][i] * (f[2][r] + v);
f[0][r+2] = f[1][r+2] * (f[2][r+2] + v) - f[1][i+2] * (f[2][i+2]);
f[0][i+2] = f[1][r+2] * (f[2][i+2]) + f[1][i+2] * (f[2][r+2] + v);
}
}
using dynamic LMUL, GCC chooses LMUL = 2 to generate the vectorized codes:
lui a5,%hi(f)
addia5,a5,%lo(f)
addia3,a5,800
addia4,a5,400
vsetivlizero,8,e32,m2,ta,ma
addisp,sp,-32
vlseg4e32.v v8,(a4)
vlseg4e32.v v16,(a3)
vmv.v.x v2,a0
vadd.vv v6,v2,v16
vmul.vv v24,v6,v10
vmul.vv v6,v6,v8
vs2r.v v24,0(sp)
addia3,a5,928
vmv.v.v v24,v18
vnmsub.vv v24,v10,v6
addia4,a5,528
vl2re32.v v6,0(sp)
vmacc.vvv6,v18,v8
vadd.vv v4,v2,v20
vmv2r.v v26,v6
vmul.vv v0,v4,v12
vmul.vv v4,v4,v14
vmv.v.v v28,v22
vnmsub.vv v28,v14,v0
vmv.v.v v30,v4
vmacc.vvv30,v22,v12
vsseg4e32.v v24,(a5)
vlseg4e32.v v8,(a4)
vlseg4e32.v v16,(a3)
vadd.vv v6,v2,v16
vmul.vv v24,v6,v10
vmul.vv v6,v6,v8
vs2r.v v24,0(sp)
addia6,a5,128
vmv.v.v v24,v18
vnmsub.vv v24,v10,v6
addia0,a5,1056
vl2re32.v v6,0(sp)
addia1,a5,656
vmacc.vvv6,v18,v8
vadd.vv v4,v2,v20
vmv2r.v v26,v6
vmul.vv v0,v4,v12
vmul.vv v4,v4,v14
vmv.v.v v28,v22
vnmsub.vv v28,v14,v0
vmv.v.v v30,v4
vmacc.vvv30,v22,v12
vsseg4e32.v v24,(a6)
vlseg4e32.v v8,(a1)
vlseg4e32.v v16,(a0)
vadd.vv v6,v2,v16
vmul.vv v24,v6,v10
vmul.vv v6,v6,v8
vs2r.v v24,0(sp)
vadd.vv v4,v2,v20
vmv.v.v v24,v18
vnmsub.vv v24,v10,v6
vmul.vv v0,v4,v12
vl2re32.v v6,0(sp)
vmv.v.v v28,v22
vnmsub.vv v28,v14,v0
vmacc.vvv6,v18,v8
vmul.vv v4,v4,v14
vmv2r.v v26,v6
vmv.v.v v30,v4
vmacc.vvv30,v22,v12
addia2,a5,256
addia3,a5,1184
addia4,a5,784
addia5,a5,384
vsseg4e32.v v24,(a2)
vsetivlizero,1,e32,m2,ta,ma
vlseg4e32.v v8,(a4)
vlseg4e32.v v16,(a3)
vadd.vv v4,v2,v16
vadd.vv v2,v2,v20
vmul.vv v0,v4,v10
vmul.vv v6,v2,v12
vmul.vv v4,v4,v8
vmul.vv v2,v2,v14
vmv.v.v v24,v10
vnmsub.vv v24,v18,v4
vmv.v.v v26,v0
vmacc.vvv26,v8,v18
vmv.v.v v28,v14
vnmsub.vv v28,v22,v6
vmv.v.v v30,v2
vmacc.vvv30,v12,v22
vsseg4e32.v v24,(a5)
addisp,sp,32
jr ra
There are redundant spillings (vs2r.v and vl2re32.v) which causes worse
performance on real hardware comparing with default LMUL (LMUL = 1).
After investigations, I find it is not dynamic LMUL cost model issue.
Actually, dynamic LMUL cost model works well and chooses the perfect LMUL = 2
for this case.
The spillings are redundant because we lack subreg liveness tracking in
IRA/LRA,
so RA consider this situation has many alloco conflict.
Confirm with this following series lehua's subreg patch:
https://patchwork.ozlabs.org/project/gcc/list/?series=381823
fix this issue perfectly:
vsetivlizero,8,e32,m2,ta,ma
vmv.v.x v2,a0
lui a5,%hi(f)
addia5,a5,%lo(f)
addia4,a5,400
vlseg4e32.v v8,(a4)
addia4,a5,800
vlseg4e32.v v16,(a4)
vadd.vv v4,v2,v16
vmul.vv v6,v4,v8
vmul.vv v16,v4,v10
vadd.vv v4,v2,v20
vmul.vv v20,v4,v12
vmul.vv v4,v4,v14
vmv.v.v v24,v18
vnmsub.vv v24,v10,v6
vmv.v.v v26,v16
vmacc.vvv26,v18,v8
vmv.v.v v28,v22
vnmsub.vv v28,v14,v20
vmv.v.v v30,v4
vmacc.vvv30,v22,v12
vsseg4e32.v v24,(a5)
addia4,a5,528
vlseg4e32.v v8,(a4)
addia4,a5,928
vlseg4e32.v v16,(a4)
[Bug c/113134] gcc does not version loops with early break conditions that don't have side-effects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113134
--- Comment #17 from JuzheZhong ---
(In reply to Tamar Christina from comment #16)
> >
> > I wonder whether ARM SVE can also use this approach VEC_EXTRACT with index =
> > 0.
>
> Perhaps, I'll look into it thanks. though this is ofcourse only applicable
> when the mask comes from whilelo.
>
> In the future when we get to loops such as:
>
> for (int i = ..;;)
> {
> if (a)
> {
>
> if (b)
> return i;
> }
> }
>
> the reduction would come from the first active element of the mask created
> by the condition a and not the whilelo.
If the mask comes from a condition, VEC_EXTRACT approach is definitely
incorrect.
However, look into vectorizable_live_operation_1:
The mask should always come from whilo instruction (or say it is always loop
mask):
tree mask = vect_get_loop_mask (loop_vinfo, ,
_VINFO_MASKS (loop_vinfo),
1, vectype, 0);
So I think it should be correct using VEC_EXTRACT with index = 0.
But if we look into vectorizable_early_break which will handle mask come from
condition, that is another story.
[Bug target/113161] New: Add a special "ramfunc" attribute for sections in the linker script (*.ld files)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113161 Bug ID: 113161 Summary: Add a special "ramfunc" attribute for sections in the linker script (*.ld files) Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: kirdyankinsp at gmail dot com Target Milestone: --- In embedded systems (microcontrollers), time-critical functions (for example, functions used in interrupts) are often copied from slow FLASH memory to RAM at startup for faster execution. How to do it: https://www.st.com/resource/en/application_note/dm00083249-use-stm32f3-stm32g4-ccm-sram-with-iar-ewarm-keil-mdk-arm-and-gnu-based -toolchains-stmicroelectronics.pdf In this case, a problem is possible: inside such a function, a function located in slow (Flash) memory can be called. Which the programmer certainly doesn’t want. If programmer copies a function into RAM, he of course wants everything that this function performs to be in RAM too. I propose to add a warning output about calling a function located in slow memory from a function located in fast memory. Here's how it works in the IAR compiler: "C:foo.c",44 Warning[Ta023]: Call to a non __ramfunc function (foo()) from within a __ramfunc function foo2(); I think for this it is necessary to add a special attribute for sections in the linker script, which will indicate to the linker that all functions in this section must call functions from the same section, otherwise they will issue a warning.
[Bug libstdc++/113159] More robust std::sort for silly comparator functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113159 Xi Ruoyao changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED CC||xry111 at gcc dot gnu.org --- Comment #1 from Xi Ruoyao --- Glibc qsort had been slower than std::sort. And in upcoming Glibc-2.39 there will be a major reimplementation of qsort, now it's unclear if it will still keep the behavior you want. Anyway this shouldn't be something we should rely on. Thus I don't think this is valid.
