[Bug target/115169] [14/15 regression] ICE in loongarch bootstrap with checking: RTL check: expected code 'reg', have 'const_int' in rhs_regno, at rtl.h:1934
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115169 Xi Ruoyao changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Xi Ruoyao --- Fixed. For the SIGILL issue note that in GCC 14 the default of -march is raised from loongarch64 to la64v1.0 which implies LSX. So I'd suggest to check if CPU_HAS_LSX is enabled in the kernel configuration first.
[Bug web/115183] GCCGO appears twice at https://gcc.gnu.org/onlinedocs/14.1.0/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115183 Xi Ruoyao changed: What|Removed |Added Status|UNCONFIRMED |NEW CC||xry111 at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2024-05-22 --- Comment #1 from Xi Ruoyao --- Confirmed as obvious.
[Bug target/115176] rbit pattern should use bitreverse rtl now
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115176
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
--- Comment #2 from Xi Ruoyao ---
LoongArch currently has:
(define_insn "bitrev_4b"
[(set (match_operand:SI 0 "register_operand" "=r")
(unspec:SI [(match_operand:SI 1 "register_operand" "r")]
UNSPEC_BITREV_4B))]
""
"bitrev.4b\t%0,%1"
[(set_attr "type" "unknown")
(set_attr "mode" "SI")])
(define_insn "bitrev_8b"
[(set (match_operand:DI 0 "register_operand" "=r")
(unspec:DI [(match_operand:DI 1 "register_operand" "r")]
UNSPEC_BITREV_8B))]
""
"bitrev.8b\t%0,%1"
[(set_attr "type" "unknown")
(set_attr "mode" "DI")])
Maybe we can make them something like (subreg:DI (bitreverse:V8QI (subreg:QI
(match...) 0)) 0) instead. And LoongArch also has bitrev.{w/d} instructions
but GCC doesn't know them yet. I plan to add them after PR50481 is
implemented.
[Bug target/114978] [14/15 regression] 548.exchange2_r 14%-28% regressions on Loongarch64 after gcc 14 snapshot 20240317
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114978 --- Comment #21 from Xi Ruoyao --- (In reply to chenglulu from comment #19) > diff --git a/gcc/config/loongarch/loongarch.cc > b/gcc/config/loongarch/loongarch.cc > index e7835ae34ae..6a808cb0a5c 100644 > --- a/gcc/config/loongarch/loongarch.cc > +++ b/gcc/config/loongarch/loongarch.cc > @@ -2383,7 +2383,7 @@ loongarch_address_insns (rtx x, machine_mode mode, > bool might_split_p) > return factor; > >case ADDRESS_REG_REG: > - return factor; > + return factor * 3; > >case ADDRESS_CONST_INT: > return lsx_p ? 0 : factor; > > With this patch, -march=la464 has a score of 11.9. > However, the specific revision plan has not yet been decided. Hmm are ldx and stx really so slow?
[Bug target/115169] [14/15 regression] ICE in loongarch bootstrap with checking: RTL check: expected code 'reg', have 'const_int' in rhs_regno, at rtl.h:1934
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115169 Xi Ruoyao changed: What|Removed |Added Status|NEW |ASSIGNED
[Bug target/115169] [14/15 regression] ICE in loongarch bootstrap with checking: RTL check: expected code 'reg', have 'const_int' in rhs_regno, at rtl.h:1934
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115169 Xi Ruoyao changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |xry111 at gcc dot gnu.org --- Comment #6 from Xi Ruoyao --- I'll take a look.
[Bug target/114978] [14/15 regression] 548.exchange2_r 14%-28% regressions on Loongarch64 after gcc 14 snapshot 20240317
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114978 Xi Ruoyao changed: What|Removed |Added Keywords|needs-bisection |missed-optimization --- Comment #17 from Xi Ruoyao --- Strangely PR114074 is a wrong-code (instead of missed-optimization) and reverting its fix seems improving performance for other targets...
[Bug middle-end/115037] Unused std::vector is not optimized away.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115037 Xi Ruoyao changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #7 from Xi Ruoyao --- . *** This bug has been marked as a duplicate of bug 109442 ***
[Bug libstdc++/109442] Dead local copy of std::vector not removed from function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109442 Xi Ruoyao changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #18 from Xi Ruoyao --- *** Bug 115037 has been marked as a duplicate of this bug. ***
[Bug middle-end/115037] Unused std::vector is not optimized away.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115037 Xi Ruoyao changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=109442 CC||xry111 at gcc dot gnu.org --- Comment #5 from Xi Ruoyao --- Isn't this an exact dup of PR109442?
[Bug target/115014] GCC generates incorrect instructions for addressing the data segment through EBP register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115014
--- Comment #11 from Xi Ruoyao ---
(In reply to Andrew Pinski from comment #10)
> int f(int *a)
> {
> int b;
> size_t t = (size_t)
> size_t t1 = (size_t)a;
> return *(int*)(((size_t))+(t-t1));
> }
>
> Is kinda of valid c but might fail with your definition.
The result of integer-to-pointer conversion is implementation-defined, so it's
not necessarily valid if the implementation has segmented memory.
[Bug target/115014] GCC generates incorrect instructions for addressing the data segment through EBP register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115014
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
--- Comment #5 from Xi Ruoyao ---
(In reply to Martin Doucha from comment #2)
> (In reply to Andrew Pinski from comment #1)
> > I am not so sure this is wanted. GCC assumes a flat memory system for stack
> > and normal memory accesses .
>
> This is certainly not wanted in the most common case where the flat memory
> assumption is correct. But it should be used for compiling embedded binaries
> with -ffreestanding argument.
No, "Freestanding Environment" has a very specific meaning in the C standard.
If we must add this it'd be a separate -m{something} argument.
[Bug driver/114980] [14/15 Regression] -fdiagnostics-urls=never does not suppress URLs in `'-Werror=' argument '-Werror=...' not valid for ...` warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114980 Xi Ruoyao changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #12 from Xi Ruoyao --- Fixed for 14/15.
[Bug target/114978] [14/15 regression] 548.exchange2_r 14%-28% regressions on Loongarch64 after gcc 14 snapshot 20240317
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114978 --- Comment #13 from Xi Ruoyao --- (In reply to Chen Chen from comment #12) > No. I used system default gcc. AOSC backports *many* changes not in upstream GCC 13.2 to their "13.2": https://github.com/AOSC-Dev/aosc-os-abbs/tree/stable/core-devel/gcc/01-runtime/patches So the default GCC is simply not GCC 13.2.
[Bug testsuite/115001] [14/15 Regression] pr109062.c fails on hybrid Intel CPU
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115001 Xi Ruoyao changed: What|Removed |Added Summary|pr109062.c fails on hybrid |[14/15 Regression] |Intel CPU |pr109062.c fails on hybrid ||Intel CPU Target Milestone|--- |14.2
[Bug testsuite/115001] New: pr109062.c fails on hybrid Intel CPU
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115001 Bug ID: 115001 Summary: pr109062.c fails on hybrid Intel CPU Product: gcc Version: 14.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: xry111 at gcc dot gnu.org Target Milestone: --- Since r14-4571 GOMP_SPINCOUNT defaults to 1 on hybrid Intel CPUs, but pr109062.c is not updated for the change.
[Bug target/114978] [14/15 regression] 548.exchange2_r 14%-28% regressions on Loongarch64 after gcc 14 snapshot 20240317
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114978 --- Comment #9 from Xi Ruoyao --- (In reply to chenglulu from comment #8) > diff --git a/gcc/config/loongarch/loongarch-def.cc > b/gcc/config/loongarch/loongarch-def.cc > index e8c129ce643..f27284cb20a 100644 > --- a/gcc/config/loongarch/loongarch-def.cc > +++ b/gcc/config/loongarch/loongarch-def.cc > @@ -111,11 +111,7 @@ loongarch_rtx_cost_data::loongarch_rtx_cost_data () > tune targets (i.e. -mtune=native while PRID does not correspond to > any known "-mtune" type). */ > array_tune loongarch_cpu_rtx_cost_data = > - array_tune () > -.set (CPU_LA664, > - loongarch_rtx_cost_data () > - .movcf2gr_ (COSTS_N_INSNS (1)) > - .movgr2cf_ (COSTS_N_INSNS (1))); > + array_tune (); But why? Isn't movcf2gr and movgr2cf one-cycle on LA664?
[Bug driver/114980] [14/15 Regression] -fdiagnostics-urls=never does not suppress URLs in `'-Werror=' argument '-Werror=...' not valid for ...` warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114980 Xi Ruoyao changed: What|Removed |Added Keywords||patch --- Comment #9 from Xi Ruoyao --- https://gcc.gnu.org/pipermail/gcc-patches/2024-May/651026.html
[Bug driver/114980] [14/15 Regression] -fdiagnostics-urls=never does not suppress URLs in `'-Werror=' argument '-Werror=...' not valid for ...` warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114980 Xi Ruoyao changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=67640 --- Comment #8 from Xi Ruoyao --- Very similar to PR67640.
[Bug other/114980] [14/15 Regression] -fdiagnostics-urls=never does not suppress URLs in `'-Werror=' argument '-Werror=...' not valid for ...` warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114980
Xi Ruoyao changed:
What|Removed |Added
Last reconfirmed||2024-05-08
Assignee|unassigned at gcc dot gnu.org |xry111 at gcc dot
gnu.org
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0 |1
--- Comment #7 from Xi Ruoyao ---
Patch only tested barely:
diff --git a/gcc/opts-common.cc b/gcc/opts-common.cc
index 4a2dff243b0..2d1e86ff94f 100644
--- a/gcc/opts-common.cc
+++ b/gcc/opts-common.cc
@@ -1152,6 +1152,7 @@ prune_options (struct cl_decoded_option
**decoded_options,
unsigned int options_to_prepend = 0;
unsigned int Wcomplain_wrong_lang_idx = 0;
unsigned int fdiagnostics_color_idx = 0;
+ unsigned int fdiagnostics_urls_idx = 0;
/* Remove arguments which are negated by others after them. */
new_decoded_options_count = 0;
@@ -1185,6 +1186,12 @@ prune_options (struct cl_decoded_option
**decoded_options,
++options_to_prepend;
fdiagnostics_color_idx = i;
continue;
+ case OPT_fdiagnostics_urls_:
+ gcc_checking_assert (i != 0);
+ if (fdiagnostics_urls_idx == 0)
+ ++options_to_prepend;
+ fdiagnostics_urls_idx = i;
+ continue;
default:
gcc_assert (opt_idx < cl_options_count);
@@ -1248,6 +1255,12 @@ keep:
= old_decoded_options[fdiagnostics_color_idx];
new_decoded_options_count++;
}
+ if (fdiagnostics_urls_idx != 0)
+ {
+ new_decoded_options[argv_0 + options_prepended++]
+ = old_decoded_options[fdiagnostics_urls_idx];
+ new_decoded_options_count++;
+ }
gcc_checking_assert (options_to_prepend == options_prepended);
}
[Bug other/114980] [14/15 Regression] -fdiagnostics-urls=never does not suppress URLs in `'-Werror=' argument '-Werror=...' not valid for ...` warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114980 --- Comment #6 from Xi Ruoyao --- Looks like when the driver invokes cc1, -fdiagnostics-urls=never seems always after -W... options: $ echo "" | LANG= ./gcc/xgcc -fdiagnostics-urls=never -Wtarget-lifetime -x c - -B gcc -v -c Reading specs from gcc/specs COLLECT_GCC=./gcc/xgcc Target: x86_64-pc-linux-gnu Configured with: ../gcc/configure --prefix=/usr LD=ld --enable-languages=c,c++ --enable-default-pie --enable-default-ssp --disable-multilib --disable-bootstrap --disable-fixincludes --with-system-zlib --enable-host-pie Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 15.0.0 20240507 (experimental) (GCC) COLLECT_GCC_OPTIONS='-fdiagnostics-urls=never' '-Wtarget-lifetime' '-B' 'gcc' '-v' '-c' '-mtune=generic' '-march=x86-64' gcc/cc1 -quiet -v -iprefix /home/xry111/git-repos/gcc-build/gcc/../lib/gcc/x86_64-pc-linux-gnu/15.0.0/ -isystem gcc/include -isystem gcc/include-fixed - -quiet -dumpbase - -mtune=generic -march=x86-64 -Wtarget-lifetime -version -fdiagnostics-urls=never -o /tmp/ccqETyrO.s cc1: warning: command-line option '-Wtarget-lifetime' is valid for Fortran but not for C ... ...
[Bug other/114980] [14/15 Regression] -fdiagnostics-urls=never does not suppress URLs in `'-Werror=' argument '-Werror=...' not valid for ...` warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114980
--- Comment #5 from Xi Ruoyao ---
(In reply to Andrew Pinski from comment #4)
> -fdiagnostics-plain-output does:
> /* If you have changed the default diagnostics output, and this new
> output is not appropriately "plain" (e.g., the change needs to
> be
> undone in order for the testsuite to work properly), then
> please do
> the following:
> 1. Add the necessary option to undo the new behavior to
> the array below.
> 2. Update the documentation for -fdiagnostics-plain-output
> in invoke.texi. */
> const char *const expanded_args[] = {
> "-fno-diagnostics-show-caret",
> "-fno-diagnostics-show-line-numbers",
> "-fdiagnostics-color=never",
> "-fdiagnostics-urls=never",
> "-fdiagnostics-path-format=separate-events",
> "-fdiagnostics-text-art-charset=none"
> };
The problem is -fdiagnostics-urls=never itself seems not working.
Note that if I invoke cc1 directly and put -fdiagnostics-urls=never *before*
the offending option:
echo "" | LANG= ./gcc/cc1 -fdiagnostics-urls=never -Wtarget-lifetime -x c -
cc1: warning: command-line option '-Wtarget-lifetime' is valid for Fortran but
not for C
It works. But if I put it *after* the offending option:
echo "" | LANG= ./gcc/cc1 -Wtarget-lifetime -fdiagnostics-urls=never -x c -
cc1: warning: command-line option '-Wtarget-lifetime' is valid for Fortran but
not for C
-Wtarget-lifetime in the message becomes a link.
However if I invoke the driver (xgcc) -fdiagnostics-urls=never just does not
work no matter before -Wtarget-lifetime or after it.
[Bug other/114980] [14/15 Regression] -fdiagnostics-urls=never does not suppress URLs in `'-Werror=' argument '-Werror=...' not valid for ...` warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114980 --- Comment #3 from Xi Ruoyao --- (In reply to Andrew Pinski from comment #2) > I have not seen this failure ... Yes it's strange. I didn't see the failures building 14.1.0-RC1 but I saw them building 14.1.0, though RC1 definitely outputs the hyperlink like 14.1.0.
[Bug other/114980] [14/15 Regression] -fdiagnostics-urls=never does not suppress URLs in `'-Werror=' argument '-Werror=...' not valid for ...` warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114980 --- Comment #1 from Xi Ruoyao --- Also happens for "command-line option ... is valid for ... but not for ..." warnings: $ env -i PATH=$PATH TERM=xterm-256colors cc hw.c -fdiagnostics-urls=never -Wtarget-lifetime cc1: warning: command-line option '-Wtarget-lifetime' is valid for Fortran but not for C -Wtarget-lifetime has become a hyperlink.
[Bug other/114980] New: [14/15 Regression] -fdiagnostics-urls=never does not suppress URLs in `'-Werror=' argument '-Werror=...' not valid for ...` warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114980
Bug ID: 114980
Summary: [14/15 Regression] -fdiagnostics-urls=never does not
suppress URLs in `'-Werror=' argument '-Werror=...'
not valid for ...` warnings
Product: gcc
Version: 14.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: xry111 at gcc dot gnu.org
Target Milestone: ---
$ cat hw.c
#include
int
main ()
{
printf ("Hello, world.\n");
}
$ env -i PATH=$PATH TERM=xterm-256colors LANG= cc hw.c -fdiagnostics-urls=never
-Werror=target-lifetime
cc1: warning: '-Werror=' argument '-Werror=target-lifetime' is not valid for C
But with GCC 14.1.0 the "-Werror" and "-Werror=target-lifetime" are hyperlinks.
This causes several test failures like:
spawn -ignore SIGHUP /home/xry111/sources/lfs/gcc-14.1.0/build/gcc/xgcc
-B/home/xry111/sources/lfs/gcc-14.1.0/build/gcc/
/home/xry111/sources/lfs/gcc-14.1.0/gcc/testsuite/gcc.dg/pr91172.c
-fdiagnostics-plain-output -Werror=target-lifetime -S -o pr91172.s
cc1: warning:
'^[]8;;https://gcc.gnu.org/onlinedocs/gcc-14.1.0/gcc/Warning-Options.html#index-Werror^G-Werror=^[]8;;^G'
argument
'^[]8;;https://gcc.gnu.org/onlinedocs/gcc-14.1.0/gcc/Warning-Options.html#index-Werror^G-Werror=target-lifetime^[]8;;^G'
is not valid for C
FAIL: gcc.dg/pr91172.c at line 3 (test for warnings, line )
FAIL: gcc.dg/pr91172.c (test for excess errors)
Excess errors:
cc1: warning:
'^[]8;;https://gcc.gnu.org/onlinedocs/gcc-14.1.0/gcc/Warning-Options.html#index-Werror^G-Werror=^[]8;;^G'
argument
'^[]8;;https://gcc.gnu.org/onlinedocs/gcc-14.1.0/gcc/Warning-Options.html#index-Werror^G-Werror=target-lifetime^[]8;;^G'
is not valid for C
[Bug target/114978] [14/14 regression] 548.exchange2_r 14%-28% regressions on Loongarch64 after gcc 14 snapshot 20240317
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114978 --- Comment #4 from Xi Ruoyao --- s/suspicious/skeptical/
[Bug target/114978] [14/14 regression] 548.exchange2_r 14%-28% regressions on Loongarch64 after gcc 14 snapshot 20240317
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114978 Xi Ruoyao changed: What|Removed |Added Target||loongarch64-*-* Component|fortran |target --- Comment #3 from Xi Ruoyao --- Changed component to target for now. I'm suspicious about the 10% regression on x86_64. IIRC there are already multiple bug reports complaining some 5% SPEC regression on x86_64, so I'll be really surprised if there is really a 10% regression on x86_64 but it's not already reported.
[Bug fortran/114978] [14/14 regression] 548.exchange2_r 14%-28% regressions on Loongarch64 after gcc 14 snapshot 20240317
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114978 Xi Ruoyao changed: What|Removed |Added Keywords||needs-bisection --- Comment #2 from Xi Ruoyao --- I don't have a SPEC access so I cannot confirm or dis-confirm the issue.
[Bug target/114848] loongarch: epilogue in _Unwind_RaiseException corrupts return value due to __builtin_eh_return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114848 Xi Ruoyao changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |12.4 Status|UNCONFIRMED |RESOLVED --- Comment #8 from Xi Ruoyao --- Fixed for 12 and 13.
[Bug target/114861] [14/15 Regression] LoongArch: ICE building the kernel with -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114861 Xi Ruoyao changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Xi Ruoyao --- Fixed for 15 and 14.
[Bug target/114861] [14/15 Regression] LoongArch: ICE building the kernel with -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114861 Xi Ruoyao changed: What|Removed |Added Last reconfirmed||2024-04-26 Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Keywords||patch Assignee|unassigned at gcc dot gnu.org |xry111 at gcc dot gnu.org --- Comment #6 from Xi Ruoyao --- https://gcc.gnu.org/pipermail/gcc-patches/2024-April/650077.html
[Bug target/114861] LoongArch: ICE building the kernel with -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114861
Xi Ruoyao changed:
What|Removed |Added
Keywords|needs-reduction |ice-on-valid-code
--- Comment #5 from Xi Ruoyao ---
Reduced test case:
long evcn, attr_collapse_range_vbo, attr_collapse_range_bytes;
unsigned short flags;
int attr_collapse_range_ni_0_0;
int *attr_collapse_range_mi;
unsigned attr_collapse_range_svcn, attr_collapse_range_vcn1;
void ni_insert_nonresident(unsigned, unsigned short, int **);
int mi_pack_runs(int);
int attr_collapse_range(void) {
_Bool __trans_tmp_1;
int run = attr_collapse_range_ni_0_0;
unsigned evcn1, vcn, end;
short a_flags = flags;
__trans_tmp_1 = flags & (32768 | 1);
if (__trans_tmp_1)
return 2;
vcn = attr_collapse_range_vbo;
end = attr_collapse_range_bytes;
evcn1 = evcn;
for (;;)
if (attr_collapse_range_svcn >= end) {
unsigned eat, next_svcn = mi_pack_runs(42);
attr_collapse_range_vcn1 = (vcn ? vcn: attr_collapse_range_svcn);
eat = (0 < end) - attr_collapse_range_vcn1;
mi_pack_runs(run - eat);
if (next_svcn + eat)
ni_insert_nonresident(evcn1 - eat - next_svcn, a_flags,
_collapse_range_mi);
} else
return 42;
}
[Bug target/114861] LoongArch: ICE building the kernel with -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114861 --- Comment #4 from Xi Ruoyao --- (In reply to Jakub Jelinek from comment #3) > m for register_operand??? Hmm indeed, the m alternative should be removed. I must had been sleeping when I typed it...
[Bug target/114861] LoongArch: ICE building the kernel with -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114861 Xi Ruoyao changed: What|Removed |Added Priority|P3 |P2 --- Comment #2 from Xi Ruoyao --- It seems we are missing a constraint for bstrins__for_mask: diff --git a/gcc/config/loongarch/loongarch.md b/gcc/config/loongarch/loongarch.md index a316c8fb820..0c86f27e768 100644 --- a/gcc/config/loongarch/loongarch.md +++ b/gcc/config/loongarch/loongarch.md @@ -1543,9 +1543,9 @@ (define_insn "and3_extended" (set_attr "mode" "")]) (define_insn_and_split "*bstrins__for_mask" - [(set (match_operand:GPR 0 "register_operand") - (and:GPR (match_operand:GPR 1 "register_operand") -(match_operand:GPR 2 "ins_zero_bitmask_operand")))] + [(set (match_operand:GPR 0 "register_operand" "=r,r") + (and:GPR (match_operand:GPR 1 "register_operand" "r,m") +(match_operand:GPR 2 "ins_zero_bitmask_operand" "i,i")))] "" "#" "" This fixes the ICE on the attached test case. I still need to review other splits and make a reduced test case.
[Bug target/114861] LoongArch: ICE building the kernel with -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114861 --- Comment #1 from Xi Ruoyao --- Created attachment 58044 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58044=edit Preprocessed source
[Bug target/114861] New: LoongArch: Fail to build the kernel with -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114861
Bug ID: 114861
Summary: LoongArch: Fail to build the kernel with -Os
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: xry111 at gcc dot gnu.org
Target Milestone: ---
drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c: In function ‘gfx_v6_0_hw_init’:
drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c:3144:1: error: could not split insn
(insn:TI 1764 67 1745 (set (mem/c:DI (reg/f:DI 3 $r3) [707 %sfp+-80 S8 A64])
(and:DI (reg/v:DI 28 $r28 [orig:422 raster_config ] [422])
(const_int -50331649 [0xfcff])))
"drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c":1386:21 111 {*bstrins_di_for_mask}
(nil))
during RTL pass: final
drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c:3144:1: internal compiler error: in
final_scan_insn_1, at final.cc:2807
0x6fdffe _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../gcc/gcc/rtl-error.cc:108
0x68dc4b final_scan_insn_1
../../gcc/gcc/final.cc:2807
0xb38398 final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
../../gcc/gcc/final.cc:2886
0xb3858f final_1
../../gcc/gcc/final.cc:1977
0xb39096 rest_of_handle_final
../../gcc/gcc/final.cc:4239
0xb39096 execute
../../gcc/gcc/final.cc:4317
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug target/114848] loongarch: epilogue in _Unwind_RaiseException corrupts return value due to __builtin_eh_return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114848 Xi Ruoyao changed: What|Removed |Added Summary|longarch: epilogue in |loongarch: epilogue in |_Unwind_RaiseException |_Unwind_RaiseException |corrupts return value due |corrupts return value due |to __builtin_eh_return |to __builtin_eh_return --- Comment #3 from Xi Ruoyao --- (In reply to Andrew Pinski from comment #2) > (In reply to Xi Ruoyao from comment #1) > > Hmm, AFAIK this should be already fixed with r14-6440? > > > > I cannot reproduce it with r14-9823 but maybe it has regressed again in the > > recent weeks. > > Oh I only tested gcc 13.2.0. If it is fixed you can close it. Hmm it looks like we need a backport to releases/gcc-13 (and 12?) I thought the bug was introduced by my shrink-wrap change (r14-545) so I didn't proposed a backport. But it seems I was wrong and the bug exists even before r14-545.
[Bug target/114848] longarch: epilogue in _Unwind_RaiseException corrupts return value due to __builtin_eh_return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114848 Xi Ruoyao changed: What|Removed |Added CC||xry111 at gcc dot gnu.org --- Comment #1 from Xi Ruoyao --- Hmm, AFAIK this should be already fixed with r14-6440? I cannot reproduce it with r14-9823 but maybe it has regressed again in the recent weeks.
[Bug target/113235] SMHasher SHA3-256 benchmark is almost 40% slower vs. Clang (not enough complete loop peeling)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113235 --- Comment #13 from Xi Ruoyao --- (In reply to David Malcolm from comment #10) > (In reply to Jan Hubicka from comment #4) > > I keep mentioning to Larabel that he should use -fno-semantic-interposition, > > but he doesn't. > > Possibly a silly question, but how about changing the default in GCC 15? > What proportion of users actually make use of -fsemantic-interposition ? At least if building Glibc with -fno-semantic-interposition, several tests will fail. I've not figured out if they are test-suite issues or real issues though.
[Bug demangler/114830] c++filt stack overflows in rust demangler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114830 Xi Ruoyao changed: What|Removed |Added CC||xry111 at gcc dot gnu.org --- Comment #3 from Xi Ruoyao --- There was a GSoC project making the demangler non recursive in 2021, but it unfortunately failed. So with a recursive demangler this thing just happens...
[Bug c/114808] Qualified void return type is not diagnosed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114808 Xi Ruoyao changed: What|Removed |Added CC||xry111 at gcc dot gnu.org Resolution|FIXED |INVALID --- Comment #10 from Xi Ruoyao --- So this is not a valid bug report considering DR 423.
[Bug rtl-optimization/114800] redundant set-zero when initiate a struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114800 Xi Ruoyao changed: What|Removed |Added CC||xry111 at gcc dot gnu.org --- Comment #1 from Xi Ruoyao --- (In reply to absoler from comment #0) > such code is compiled as: (gcc-13.2.0 -O2, regression [11/12/13/trunk]) The regression marker isn't true. It looks like the redundant zeroing has been there even in GCC 4.8.1. GCC 4.7 fails to compile the test case. And IIRC there is already an report complaining some redundant zeroing like this...
[Bug c/114773] Raw string literals are not supported in C89 mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114773 Xi Ruoyao changed: What|Removed |Added Resolution|FIXED |INVALID --- Comment #6 from Xi Ruoyao --- Oops, the mouse scroll wheel is too sensitive and I selected the wrong resolution :(.
[Bug c/114773] Raw string literals are not supported in C89 mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114773 Xi Ruoyao changed: What|Removed |Added CC||xry111 at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #5 from Xi Ruoyao --- Then this isn't a valid bug report.
[Bug rust/113499] crab1 fails to link when configuring with --disable-plugin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113499 Xi Ruoyao changed: What|Removed |Added CC||xry111 at gcc dot gnu.org --- Comment #7 from Xi Ruoyao --- (In reply to Richard Biener from comment #3) > (In reply to Richard Biener from comment #2) > > Re-confirmed. Can be reproduced both on a glibc 2.31 and glibc 2.38 system > > with > > It does work with glibc 2.38, so only glibc 2.31 fails this (and possibly > other OS). In Glibc 2.34 libdl was merged into libc, thus it only fails with Glibc < 2.34.
[Bug middle-end/114700] Front-end optimization generates wrong code with -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114700 --- Comment #13 from Xi Ruoyao --- And IIRC there are various suggestion saying "if you want -fwrapv, you are likely actually wanting -fsanitize=signed-integer-overflow" and some plan deprecating -fwrapv. So it's more important to fix the sanitizer issue.
[Bug middle-end/114700] Front-end optimization generates wrong code with -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114700 Xi Ruoyao changed: What|Removed |Added Summary|Front-end optimization |Front-end optimization |generates wrong code with |generates wrong code with |-ftrapv.|-fsanitize=undefined CC||xry111 at gcc dot gnu.org --- Comment #10 from Xi Ruoyao --- (In reply to Richard Biener from comment #9) > That that GCC doesn't promise that -ftrapv preserves all overflows and > traps, it merely guarantees that all overflows that actually happen trap. > So GCC is fine to contract some expressions where the overall number of > overflows can only > decrease. > > That's not a bug with -ftrapv. > > It is considered a bug with -fsanitize=undefined though. So modifying the subject.
[Bug target/113233] LoongArch: target options from LTO objects not respected during linking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113233 Xi Ruoyao changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |14.0 --- Comment #15 from Xi Ruoyao --- (In reply to Yang Yujie from comment #14) > Is it not really necessary for now, since there is no LSX/LASX support in > GCC 12 / 13? So closing the ticket as fixed.
[Bug target/113233] LoongArch: target options from LTO objects not respected during linking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113233 --- Comment #13 from Xi Ruoyao --- Will we back port the fix to 13 and 12?
[Bug libstdc++/114645] std::chrono::current_zone ignores $TZ on Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114645 --- Comment #10 from Xi Ruoyao --- > rust's `chrono` Note that this is really a bad example because of CVE-2020-26235.
[Bug middle-end/93041] GCC 10 removes an infinite loop and causes a null pointer to dereferenced
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93041 Xi Ruoyao changed: What|Removed |Added CC||xry111 at gcc dot gnu.org --- Comment #12 from Xi Ruoyao --- (In reply to Ganton from comment #11) > A related assigned task is: > [C++26] P2809R3 - Trivial infinite loops are not undefined behavior > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114462 Note that even with P2809R3 the test case in this ticket is still invalid, as explained in comment 9.
[Bug target/110027] [11/12/13/14 regression] Misaligned vector store on detect_stack_use_after_return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110027 Xi Ruoyao changed: What|Removed |Added CC||teodor_spaeren at riseup dot net --- Comment #16 from Xi Ruoyao --- *** Bug 114637 has been marked as a duplicate of this bug. ***
[Bug sanitizer/114637] Problems when compiling with both undefined and address sanitizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114637 Xi Ruoyao changed: What|Removed |Added CC||xry111 at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Xi Ruoyao --- This is almost an exact dup of #113053, and #113053 is marked as a dup of #110027 despite not related to vector types. *** This bug has been marked as a duplicate of bug 110027 ***
[Bug c++/114638] Hang and Memory Consumption Increase during Compilation with Recursive Template Instantiation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114638 Xi Ruoyao changed: What|Removed |Added CC||xry111 at gcc dot gnu.org --- Comment #1 from Xi Ruoyao --- The test case is just a "compiler bomb" and I don't know if we can do anything better.
[Bug target/112919] LoongArch: Alignments in tune parameters are not precise and they regress performance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112919 Xi Ruoyao changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #23 from Xi Ruoyao --- So fixed.
[Bug target/113233] LoongArch: target options from LTO objects not respected during linking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113233 Xi Ruoyao changed: What|Removed |Added Target Milestone|12.4|---
[Bug target/113233] LoongArch: target options from LTO objects not respected during linking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113233 Xi Ruoyao changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #11 from Xi Ruoyao --- I misunderstood the last change and this is not fixed: https://gcc.gnu.org/pipermail/gcc-patches/2024-April/648921.html
[Bug lto/114574] [14 regression] ICE when building curl with LTO (fld_incomplete_type_of, at ipa-free-lang-data.cc:257) since r14-9763
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114574 Xi Ruoyao changed: What|Removed |Added CC||xry111 at gcc dot gnu.org Priority|P1 |P3 --- Comment #24 from Xi Ruoyao --- So no longer a P1.
[Bug c/114597] [GCC-14] Miscompilation of pointer assignment with inline assembly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114597
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
--- Comment #4 from Xi Ruoyao ---
(In reply to wierton from comment #3)
> Thanks a lot, I have checked it out.
>
> I'm still somewhat confused. Does the difference in compilation stem from
> GCC interpreting "=m" and "=r" differently, leading it to assume that once
> "n.p" is declared as an output operand without matched input declaration
> (eg. "=m" expects "m", "=r" expects "r"), its value is expected to change?
>
> ```
> asm("":"=m"(n.p):"r"(n.p)); // n.p is expected to change
> asm("":"=r"(n.p):"r"(n.p)); // n.p can retain its value
> asm("":"=m"(n.p):"m"(n.p)); // n.p can retain its value
> ```
I believe the second form is still incorrect and it just works by luck. To
ensure it work you have to do:
asm("mov %1,%0":"=r"(n.p):"r"(n.p));
Or
asm("":"+r"(n.p));
Not so sure about the third form.
[Bug target/114590] [14 Regression] FAIL: gcc.target/i386/apx-ndd-ti-shift.c (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114590 Xi Ruoyao changed: What|Removed |Added Status|RESOLVED|WAITING CC||xry111 at gcc dot gnu.org Resolution|MOVED |--- --- Comment #2 from Xi Ruoyao --- Jan Beulich believe the issue is in GCC. Reopen as "waiting".
[Bug target/112919] LoongArch: Alignments in tune parameters are not precise and they regress performance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112919 --- Comment #20 from Xi Ruoyao --- (In reply to chenglulu from comment #19) > (In reply to Xi Ruoyao from comment #18) > > (In reply to chenglulu from comment #17) > > > > > The results of spec2006 on LA464 are: > > > -falign-labels=4 -falign-functions=32 -falign-loops=16 -falign-jumps=16 > > > > Would you send a patch for them or prefer I to do it? > > I'll send a patch tomorrow. Ping. I'd like to do another system rebuild after this patch lands for verifying GCC 14.
[Bug target/113233] LoongArch: target options from LTO objects not respected during linking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113233 Xi Ruoyao changed: What|Removed |Added Target Milestone|--- |12.4 Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #10 from Xi Ruoyao --- So fixed for all branches.
[Bug tree-optimization/114511] [11/12/13/14 Regression] Missed optimization: x = -y; x = c + x + y; ==> x=c;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114511 Xi Ruoyao changed: What|Removed |Added Ever confirmed|0 |1 Keywords||needs-bisection Known to work||7.1.0 Known to fail||8.1.0 Status|UNCONFIRMED |NEW Last reconfirmed||2024-03-28 CC||xry111 at gcc dot gnu.org Summary|[Regression] Missed |[11/12/13/14 Regression] |optimization: x = -y; x = c |Missed optimization: x = |+ x + y; ==> x=c; |-y; x = c + x + y; ==> x=c; --- Comment #1 from Xi Ruoyao --- Confirmed.
[Bug lto/114505] static archives built with gcc --without-zstd cause ICE when read by gcc with zstd support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114505 Xi Ruoyao changed: What|Removed |Added Keywords||needs-reduction --- Comment #5 from Xi Ruoyao --- (In reply to Andrew Pinski from comment #3) > THis should not case should not being ICE and should be handled correctly. I > am thinking something else is wrong. > > Now the opposite direction is definitely should be a fatal_error instead of > an internal_error. I'm pretty sure I've seen the ICE before (when I forgot to strip the LTO sections from a fat LTO archive built by a "GCC w/o zstd" to produce a non-LTO archive). Just need to find a test case...
[Bug lto/114505] static archives built with gcc --without-zstd cause ICE when read by gcc with zstd support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114505 Xi Ruoyao changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2024-03-28 CC||xry111 at gcc dot gnu.org Ever confirmed|0 |1 Keywords||lto --- Comment #1 from Xi Ruoyao --- Confirmed as I've seen it before. At least we should turn it into a "normal" error message instead of ICE. But note that even "downgrading the compression algorithm" is supported, it won't really help rolling-release distros. When GCC itself is upgraded with a LTO API version change, all previous LTO static archives will be unusable anyway. Generally the distros should not ship LTO static archives at all.
[Bug rtl-optimization/114452] Functions invoked through compile-time table of function pointers not inlined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114452 Xi Ruoyao changed: What|Removed |Added Status|REOPENED|NEW Keywords||missed-optimization
[Bug target/112919] LoongArch: Alignments in tune parameters are not precise and they regress performance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112919 --- Comment #18 from Xi Ruoyao --- (In reply to chenglulu from comment #17) > The results of spec2006 on LA464 are: > -falign-labels=4 -falign-functions=32 -falign-loops=16 -falign-jumps=16 Would you send a patch for them or prefer I to do it?
[Bug target/104817] mips: ICE in mips_output_move, at config/mips/mips.cc:5323 with -fzero-call-used-regs=all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104817 Xi Ruoyao changed: What|Removed |Added CC||qing.zhao at oracle dot com --- Comment #3 from Xi Ruoyao --- Hi Qing, Any progress on the https://gcc.gnu.org/pipermail/gcc-patches/2022-March/592002.html stuff? We just got another complain about -fzero-call-used-regs= on mips today... (PR114466) and let's make another try to solve it (maybe for GCC 15).
[Bug tree-optimization/114464] [14 regression] ICE when building tdscpp-20240212
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114464 Xi Ruoyao changed: What|Removed |Added CC||xry111 at gcc dot gnu.org --- Comment #4 from Xi Ruoyao --- Interestingly, this only happens when N % 16 == 0.
[Bug target/114466] mips: ICE during RTL pass: zero_call_used_regs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114466 Xi Ruoyao changed: What|Removed |Added CC||xry111 at gcc dot gnu.org --- Comment #5 from Xi Ruoyao --- -fzero-call-used-regs=all is just completely broken on mips as at now. Please don't use it for mips.
[Bug tree-optimization/114465] "x % const1 % const2" should be optimized if const1 % const2 == 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114465 Xi Ruoyao changed: What|Removed |Added Severity|normal |enhancement Keywords||missed-optimization
[Bug tree-optimization/114465] New: "x % const1 % const2" should be optimized if const1 % const2 == 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114465
Bug ID: 114465
Summary: "x % const1 % const2" should be optimized if const1 %
const2 == 0
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: xry111 at gcc dot gnu.org
Target Milestone: ---
int test(int x) { return x % 114514 % 1847; }
This should be optimized as-is
int test(int x) { return x % 1847; }
[Bug rtl-optimization/114452] Functions invoked through compile-time table of function pointers not inlined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114452
--- Comment #3 from Xi Ruoyao ---
(In reply to Paweł Bylica from comment #2)
> I don't think this is related to lambdas. The following is also not
> optimized:
>
>
> using F = int (*)(int) noexcept;
>
> inline int impl(int x) noexcept { return x; }
>
> void test(int z[2]) noexcept {
> static constexpr F fs[]{
> impl,
> impl,
> };
>
> for (int i = 0; i < 2; ++i) {
> z[i] = fs[i](z[i]);
> }
> }
>
> https://godbolt.org/z/9hPbzo4Px
The analysis of PR111573 says:
"So we fail to inline since ipa-prop fails to track the constant function
address. I think this is really common in typical lambda function usage"
"fails to track the constant function address" applies for normal functions
too.
[Bug ipa/111573] lambda functions often not inlined and optimized out
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111573 Xi Ruoyao changed: What|Removed |Added CC||chfast at gmail dot com --- Comment #3 from Xi Ruoyao --- *** Bug 114452 has been marked as a duplicate of this bug. ***
[Bug rtl-optimization/114452] Functions invoked through compile-time table of function pointers not inlined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114452 Xi Ruoyao changed: What|Removed |Added CC||xry111 at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Xi Ruoyao --- Dup. *** This bug has been marked as a duplicate of bug 111573 ***
[Bug middle-end/114449] bswap64 not optimized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114449 Xi Ruoyao changed: What|Removed |Added Keywords||missed-optimization Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2024-03-24 --- Comment #4 from Xi Ruoyao --- (In reply to Pali Rohár from comment #2) > Interesting... I was expecting that some -O3 or better -Ofast option tells > gcc to optimize the code as much as possible. Yes this is a bug. I'm only providing some clue about why this happens, not meaning we should rely on some #pragma to get the expected result. But generally unrolling loops too much pessimizes the code, so increase the default unrolling factor is a no-go. We need to invent some cleverer thing for this.
[Bug middle-end/114449] bswap64 not optimized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114449 Xi Ruoyao changed: What|Removed |Added CC||xry111 at gcc dot gnu.org --- Comment #1 from Xi Ruoyao --- Adding #pragma GCC unroll 8 for the loop makes it optimized. IIRC by default GCC only unroll loops with a factor of 4 so it's not "fully" unrolled w/o the pragma.
[Bug c++/114439] [14 Regression] icu4c-73.2 build failure: invalid initializer for array member with initialization of array of struct containing arrays since r14-9622
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114439 Xi Ruoyao changed: What|Removed |Added Priority|P3 |P1 --- Comment #3 from Xi Ruoyao --- To me this should be a P1 as the compiler is rejecting trivial valid code...
[Bug target/114441] Relocation issues when compiling with -O1,-O2,and -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114441
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
--- Comment #4 from Xi Ruoyao ---
(In reply to Yang Wang from comment #3)
> (In reply to Andrew Pinski from comment #1)
> > This is not a GCC bug,
> >
> > You need to use -mcmodel=large if you have huge statically allocated arrays.
> >
> > The default -mcmodel=medium does not support more than 2GB size arrays
> >
> > See
> > https://gcc.gnu.org/onlinedocs/gcc-13.2.0/gcc/x86-Options.html#index-
> > mcmodel_003dlarge-3
>
> Thanks for your reply! Indeed, the compilation was successful when either
> the -mcmodel=medium or -mcmodel=large was enabled. However, I'm still
> curious why it can be compiled successfully at the -O3 optimization level
> when the default -mcmodel=small is enabled? As far as I know, the -O3
> optimization level is the highest.
Because the entire `c` function is optimized to empty. Note that `c` always
invokes undefined behavior:
t.cc: In function 'void c()':
t.cc:10:30: warning: iteration 1 invokes undefined behavior
[-Waggressive-loop-optimizations]
10 | a[d][e][f][g][i] = 2;
| ~^~~
t.cc:9:32: note: within this loop
9 | for (size_t i = 0; i < 16; ++i)
| ~~^~~~
So the compiler is allowed to optimize it into nothing.
A test case without undefined behavior:
#include
int a[1][1][1][1][1];
short b[6268435456];
void c() {
a[0][0][0][0][0] = 114514;
}
int main() {}
fails at -O3 too.
Also note that -O levels are for optimizing the *valid* programs, not for
debugging the compiler. It's wrong to report bugs solely because of "different
behaviors with different -O levels" (without analysing the validity of the test
case).
[Bug c++/114421] arm-none-eabi thumb -Os (and -O2) incorrectly optimizes out needed class member call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114421 Xi Ruoyao changed: What|Removed |Added CC||xry111 at gcc dot gnu.org --- Comment #3 from Xi Ruoyao --- (In reply to Earle F. Philhower, III from comment #2) > Thanks very much for the fast explanation. For reference of others who > might hit this, I see references to C11 6.8.5 pp 6 online (but of course > it's an ISO document so not freely available). > > "An iteration statement whose controlling expression is not a constant > expression, that performs no input/output operations, does not access > volatile objects, and performs no synchronization or atomic operations in > its body, controlling expression, or (in the case of a for statement) its > expression-3, may be assumed by the implementation to terminate." For this topic C++ is actually more strict than C so referring the C standard may be still misleading. In C++ there is no "the controlling expression is a constant expression" exempt, so even while (true); can be optimized out. AFAIK GCC does not optimize away while (true); in C++, but Clang is actively doing this. There is a WG21 paper to add the constant expression exemption for C++ like C (I cannot remember its N ID though).
[Bug target/114407] Typo 'enabing' in loongarch-opts.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114407 Xi Ruoyao changed: What|Removed |Added Resolution|--- |FIXED CC||xry111 at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED --- Comment #2 from Xi Ruoyao --- Fixed, thanks for report!
[Bug tree-optimization/89163] Missed optimization: sar and shr equivalent for non-negative numbers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89163 Xi Ruoyao changed: What|Removed |Added CC||xry111 at gcc dot gnu.org --- Comment #3 from Xi Ruoyao --- Maybe we can at least perform the canonization for shifting a constant as 114406 requests.
[Bug tree-optimization/89163] Missed optimization: sar and shr equivalent for non-negative numbers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89163 Xi Ruoyao changed: What|Removed |Added CC||Explorer09 at gmail dot com --- Comment #2 from Xi Ruoyao --- *** Bug 114406 has been marked as a duplicate of this bug. ***
[Bug middle-end/114406] Optimizations with ">>", div, mod and mul where operands are all positive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114406 Xi Ruoyao changed: What|Removed |Added Resolution|--- |DUPLICATE CC||xry111 at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED --- Comment #1 from Xi Ruoyao --- Dup. *** This bug has been marked as a duplicate of bug 89163 ***
[Bug target/114175] [13/14] Execution test failures on gcc.dg/c23-stdarg-6.c on multiple targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114175 --- Comment #40 from Xi Ruoyao --- mips patch: https://gcc.gnu.org/pipermail/gcc-patches/2024-March/648070.html (tested with -mabi=64)
[Bug middle-end/59863] const array in function is placed on stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59863 Xi Ruoyao changed: What|Removed |Added CC||xry111 at gcc dot gnu.org See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=114206 --- Comment #10 from Xi Ruoyao --- Note that if we take a pointer to such an array this optimization will be invalid. And unfortunately the mis-optimization is already happening (even for non-const arrays) with some strange command line switch combinations. See PR114206.
[Bug analyzer/114285] Use of uninitialized value when copying a struct field by field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114285 Xi Ruoyao changed: What|Removed |Added CC||xry111 at gcc dot gnu.org --- Comment #9 from Xi Ruoyao --- (In reply to Antoni from comment #8) > Created attachment 57726 [details] > Reproducer using union > > I tried switching to a union and I still get the same error. > > A union is used by std::optional, so I would assume that this should work. > Or is copying uninitialized memory via a union also UB? Yes. std::optional copy constructor is not a default copy constructor. It does not copy if the input is nullopt.
[Bug target/112470] [11/12/13/14 regression] [AARCH64] stack-protector vulnerability fixing solution impact code size and performance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112470 --- Comment #14 from Xi Ruoyao --- (In reply to Jakub Jelinek from comment #13) > So, is there anything we should do about this PR, or just close it as > necessary outcome of trying to be more secure when user asked for it? At least it shouldn't be a "P1 critical."
[Bug target/114175] [13/14] Execution test failures on gcc.dg/c23-stdarg-6.c on multiple targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114175 --- Comment #36 from Xi Ruoyao --- Do we need a backport to releases/gcc-13?
[Bug target/114175] [13/14] Execution test failures on gcc.dg/c23-stdarg-6.c on multiple targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114175 --- Comment #28 from Xi Ruoyao --- LoongArch patch (tested): https://gcc.gnu.org/pipermail/gcc-patches/2024-March/647928.html
[Bug target/114175] [13/14] RISC-V: Execution test failures on gcc.dg/c23-stdarg-6.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114175 Xi Ruoyao changed: What|Removed |Added Target|riscv, loongarch, x86_64|riscv, loongarch, x86_64, ||mips --- Comment #26 from Xi Ruoyao --- Comment 14 test case also fails with GCC 13.2 on mips64el, but not aarch64.
[Bug tree-optimization/114363] inconsistent optimization of pow(x,2)+pow(y,2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114363 Xi Ruoyao changed: What|Removed |Added Resolution|--- |INVALID CC||xry111 at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED --- Comment #2 from Xi Ruoyao --- (In reply to Harald van Dijk from comment #1) > This is, I believe, correct. Before C++11, calling std::pow with float and > int arguments, it returned a float. As of C++11, it returns a double. > > If the result of pow(x,2) is immediately converted to float, then it is a > valid optimisation to convert it to x*x: that is guaranteed to produce the > exact same result. But if it isn't, then converting to x*x loses accuracy > and alters the result. Thus invalid. > You can call std::powf instead of std::pow to avoid the promotion to double. Or add -std=c++98.
[Bug sanitizer/113430] [11/12/13 only] Trivial program segfaults intermittently with ASAN with large CONFIG_ARCH_MMAP_RND_BITS in kernel configuration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113430 --- Comment #12 from Xi Ruoyao --- (In reply to Dimitrij Mijoski from comment #8) > This bug manifested at large on Github Actions CI/CI system in the last few > days most likely because Ubuntu's kernel also got updated to use 32 random > bits. Here is the bug report > https://github.com/actions/runner-images/issues/9491 . It would be a good > idea to backport the fix. But then backporting the fix here won't really help because Ubuntu is not building GCC from the upstream release branch. Ubuntu maintainers could just apply the patch downstream when they decide to increase random bits anyway, not sure why they didn't.
[Bug target/114175] [13/14] RISC-V: Execution test failures on gcc.dg/c23-stdarg-6.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114175 --- Comment #22 from Xi Ruoyao --- (In reply to Sam James from comment #21) > (In reply to Xi Ruoyao from comment #20) > > Also failing on LoongArch. > > The testcase from comment 19 or the test? > > Not sure if we should move the comment 19 issue into its own PR? The c23-stdarg-6.c test itself. Though I guess comment 19 test case will fail too.
[Bug target/114175] [13/14] RISC-V: Execution test failures on gcc.dg/c23-stdarg-6.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114175 Xi Ruoyao changed: What|Removed |Added CC||xry111 at gcc dot gnu.org --- Comment #20 from Xi Ruoyao --- Also failing on LoongArch.
[Bug tree-optimization/110992] [13/14 Regression] missed VRP optimization due to transformation of `a & -zero_one_valued_p` into `a * zero_one_valued_p`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110992 Xi Ruoyao changed: What|Removed |Added CC||xry111 at gcc dot gnu.org See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=26 --- Comment #14 from Xi Ruoyao --- (In reply to Jeffrey A. Law from comment #13) > So like the other bug involving multiplies against objects with a known > range [0,1], we should very seriously consider turning the multiply into a > conditional move. ie x * b where b is known to have the range [0,1] we can > turn that into > > dest = b ? x : 0 > > Some processors that don't have generalized conditional moves do have > conditional zero instructions. ie, zicond on RISC-V. It's PR26.
[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163 Bug 26163 depends on bug 114281, which changed state. Bug 114281 Summary: [14 Regression] Multiple 2-10% exec time regressions of 465.tonto since r14-9193-ga0b1798042d033 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114281 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE
[Bug tree-optimization/114269] [14 Regression] Multiple 3-27% exec time regressions of 434.zeusmp since r14-9193-ga0b1798042d033
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114269 --- Comment #2 from Xi Ruoyao --- *** Bug 114281 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/114281] [14 Regression] Multiple 2-10% exec time regressions of 465.tonto since r14-9193-ga0b1798042d033
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114281
Xi Ruoyao changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |DUPLICATE
CC||xry111 at gcc dot gnu.org
--- Comment #1 from Xi Ruoyao ---
(In reply to Filip Kastl from comment #0)
> Our LNT instance has detected that runtime of benchmark 465.tonto from the
> SPEC 2006 suite regressed on all of our machines (aarch64 ampere altra,
> intel skylake, amd zen{2,3,4}) on most configurations by 2-10%.
>
> One example: Zen4 -Ofast -flto -march=native (regressed by 10%)
> https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=992.230.0
>
> I've bisected the example configuration to r14-9193-ga0b1798042d033 (Richard
> Biener: tree-optimization/114074 - CHREC multiplication and undefined
> overflow).
>
> There have been two other SPEC benchmarks regressions reported that also got
> bisected to this commit -- pr114269, pr114238. I assume that all of these
> have the same cause.
Please don't open more tickets unless you are assuming they do *not* have the
same cause.
*** This bug has been marked as a duplicate of bug 114269 ***
[Bug target/112919] LoongArch: Alignments in tune parameters are not precise and they regress performance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112919 --- Comment #15 from Xi Ruoyao --- > Hi，Ruoyao: > > The results of spec2006 on 3A6000 were obtained, I removed the more volatile > test items, '-falign-loops=8 -falign-functions=8 -falign-jumps=32 > -falign-lables=4' this set of parameters got the highest score. This is the > same combination of parameters as the coremark tested by Xu Chenghua. > > The test of the 3A5000 will also be completed around the 15th of this month, > so I want to change the code after the test results of the 3a5000 are out. > What do you think? Ok to me. I'm getting some different results on LA664: 22031.284424 Compiler flags : -O2 -falign-labels=4 -falign-functions=8 -falign-loops=8 -falign-jumps=32 -DPERFORMANCE_RUN=1 -lrt vs the "best" one: 22075.055188 Compiler flags : -O2 -falign-labels=4 -falign-functions=32 -falign-loops=16 -falign-jumps=8 -DPERFORMANCE_RUN=1 -lrt maybe such a 0.1% difference is some random fluctuation, or hardware or kernel configuration difference anyway.
