https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110380
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110375
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110327
--- Comment #1 from Andrew Pinski ---
What is interesting is that the call to foo is still there on the gimple level
in GCC 11, it is only on the RTL level it is able to be removed
What I see missing on the gimple level on the trunk is a j
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110375
--- Comment #2 from Giuseppe D'Angelo ---
(In reply to Andrew Pinski from comment #1)
> The code is undefined,
Sure, although there are C++ proposals to make it well-defined /
implementatiopn-defined (see
https://www.open-std.org/jtc1/sc22/wg21
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110375
--- Comment #3 from Andrew Pinski ---
(In reply to Giuseppe D'Angelo from comment #2)
> (In reply to Andrew Pinski from comment #1)
> > The code is undefined,
>
> Sure, although there are C++ proposals to make it well-defined /
> implementatiop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #13 from Jürgen Reuter ---
I changed the component from fortran to tree-optimization, as the problematic
commit during that week was in that component. The only commit in the fortran
component turns out to be unproblematic.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79173
--- Comment #26 from Marc Glisse ---
(In reply to CVS Commits from comment #22)
> While the design of these builtins in clang is questionable,
> rather than being say
> unsigned __builtin_addc (unsigned, unsigned, bool, bool *)
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87281
--- Comment #14 from Jan-Benedict Glaw ---
Still observable as of a8994014041:
[...]
ia64-linux-gcc -Wp,-MMD,kernel/.kallsyms.o.d -nostdinc -I./arch/ia64/include
-I./arch/ia64/include/generated -I./include -I./arch/ia64/include/uapi
-I./arch/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109456
--- Comment #13 from Xi Ruoyao ---
(In reply to gccriscvuser from comment #12)
> Updating the documentation is good, but there should also be an error
> diagnostic, right?
It would be a backward-incompatible change. IMO it's perfectly legal to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79173
--- Comment #27 from Jakub Jelinek ---
Given that the builtins exist for 10 years already, I think changing it for
them is too late, though they don't seem to take backwards compatibility as
seriously.
They don't document the [0, 1] restriction a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110375
--- Comment #4 from Giuseppe D'Angelo ---
(In reply to Andrew Pinski from comment #3)
> (In reply to Giuseppe D'Angelo from comment #2)
> > (In reply to Andrew Pinski from comment #1)
> > > The code is undefined,
> >
> > Sure, although there ar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109456
--- Comment #14 from Xi Ruoyao ---
(In reply to Andreas Schwab from comment #10)
> Or "other ABI-mandated fixed roles". This also includes return value
> registers.
Hmm, even "ABI-mandated fixed roles" is not enough. For example, or RISC-V we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #14 from Jürgen Reuter ---
Did anybody manage to reproduce this?
Download https://whizard.hepforge.org/downloads/?f=whizard-3.1.2.tar.gz
You need OCaml as a prerequisite, though.
Then configure, make,
cd tests/functional_tests
make
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC|anlauf at gmx dot de |
--- Comment #15 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79173
--- Comment #28 from Vincent Lefèvre ---
(In reply to Jakub Jelinek from comment #27)
> Given that the builtins exist for 10 years already, I think changing it for
> them is too late, though they don't seem to take backwards compatibility as
> se
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79173
--- Comment #29 from Jakub Jelinek ---
(In reply to Vincent Lefèvre from comment #28)
> (In reply to Jakub Jelinek from comment #27)
> > Given that the builtins exist for 10 years already, I think changing it for
> > them is too late, though they
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110380
--- Comment #2 from Gašper Ažman ---
-fprofile-constexpr is perfectly fine :), as long as it gets a filename
argument for the output; build automation will be thankful.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110388
Bug ID: 110388
Summary: wrong code with on x86_64-linux-gnu
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-opt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110389
Bug ID: 110389
Summary: wrong code at -Os and -O2 with "-fno-tree-ch
-fno-expensive-optimizations -fno-ivopts
-fno-tree-loop-ivcanon" on x86_64-linux-gnu
Product: gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110390
Bug ID: 110390
Summary: ICE on valid code on x86_64-linux-gnu with
sel-scheduling: in
av_set_could_be_blocked_by_bookkeeping_p, at
sel-sched.cc:3609
Pro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110388
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
--- Comment #1 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110388
Zhendong Su changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #16 from Jürgen Reuter ---
It seems that it is this function where the NaNs appear:
function mult_mod (a, b, c, m) result (v)
real(default), intent(in) :: a
real(default), intent(in) :: b
real(default), intent(in) :: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #17 from Jürgen Reuter ---
How would I set up such a bisection for the n git commits between June 12 to
June 19? Unfortunately, I cannot really get a small reproducer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79173
--- Comment #30 from Vincent Lefèvre ---
(In reply to Jakub Jelinek from comment #29)
> (In reply to Vincent Lefèvre from comment #28)
> > What do you mean by "the first additions will be less optimized"? (If you
> > don't know anything about the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79173
--- Comment #31 from Jakub Jelinek ---
(In reply to Vincent Lefèvre from comment #30)
> (In reply to Jakub Jelinek from comment #29)
> > (In reply to Vincent Lefèvre from comment #28)
> > > What do you mean by "the first additions will be less op
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110391
Bug ID: 110391
Summary: wrong code at -O2 and -O3 with "on x86_64-linux-gnu
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Comp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110391
Zhendong Su changed:
What|Removed |Added
Summary|wrong code at -O2 and -O3 |wrong code at -O2 and -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110317
--- Comment #1 from Zhendong Su ---
Here is another related reproducer that only needs -fselective-scheduling2.
It affects 13.* and later.
Compiler Explorer: https://godbolt.org/z/zY7vMh9rj
[593] % gcctk -v
Using built-in specs.
COLLECT_GCC=g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92220
--- Comment #5 from Xi Ruoyao ---
Unfortunately the value range info is not available in the frontend :(.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92220
--- Comment #6 from Xi Ruoyao ---
(In reply to Xi Ruoyao from comment #5)
> Unfortunately the value range info is not available in the frontend :(.
Here "value range info" means the info from the VRP pass. For this case we can
specially check M
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110392
Bug ID: 110392
Summary: ICE at -O3 with "-w -O3 -Wall -fno-tree-vrp
-fno-tree-dominator-opts -fno-tree-copy-prop
-fno-tree-fre -fno-tree-ccp -fno-tree-forwprop": in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #18 from anlauf at gcc dot gnu.org ---
(In reply to Jürgen Reuter from comment #17)
> How would I set up such a bisection for the n git commits between June 12 to
> June 19? Unfortunately, I cannot really get a small reproducer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110393
Bug ID: 110393
Summary: ICE at -O3 with "-fselective-scheduling2 -fPIC": in
move_op_ascend, at sel-sched.cc:6150
Product: gcc
Version: unknown
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #19 from Jürgen Reuter ---
(In reply to anlauf from comment #18)
> (In reply to Jürgen Reuter from comment #17)
> > How would I set up such a bisection for the n git commits between June 12 to
> > June 19? Unfortunately, I cannot rea
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #20 from anlauf at gcc dot gnu.org ---
If that doesn't help: there appear to be recent optimizations for divmod.
Try declaring a1, a2 as volatile.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105212
--- Comment #2 from Honki Tonk ---
The error still occurs with version 13.1.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110392
Andrew Pinski changed:
What|Removed |Added
Summary|ICE at -O3 with "-w -O3 |ICE at -O3 with "-O3 -Wall
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110392
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110391
Andrew Pinski changed:
What|Removed |Added
Summary|wrong code at -O2 and -O3 |[12/13/14 Regression] wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110389
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110394
Bug ID: 110394
Summary: Lambda capture receives wrong value
Product: gcc
Version: 13.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110394
--- Comment #1 from jackyguo18 at hotmail dot com ---
Created attachment 55396
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55396&action=edit
.ii file which triggers the bug
I couldn't attach the original .ii file, so I had to compress i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110395
Bug ID: 110395
Summary: GCOV stuck in an infinite loop with large std::array
Product: gcc
Version: 9.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110394
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110394
--- Comment #3 from Andrew Pinski ---
You can also try -fno-lifetime-dse to see if you get the behavior you were
expecting too. Though I am not sure it will help extend the lifetime of the
temporary here ...
https://gcc.gnu.org/onlinedocs/gcc-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110394
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
--- Comment #4 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82943
--- Comment #13 from Alexander Westbrooks ---
I sent in the patch to those emails. Hopefully now the ball will start rolling
and I can slowly get this packaged into a legitimate fix. I'll post updates
here as I receive them.
The patch is below,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #21 from anlauf at gcc dot gnu.org ---
I forgot to mention that you need to check that the location where a symptom
is seen sometimes may not be the location of the cause.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110360
--- Comment #12 from anlauf at gcc dot gnu.org ---
(In reply to anlauf from comment #11)
> Created attachment 55393 [details]
> Patch to truncate string argument longer than 1
>
> This truncates the string to length 1 and appears to work on x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110360
--- Comment #13 from CVS Commits ---
The master branch has been updated by Harald Anlauf :
https://gcc.gnu.org/g:3f97d10aa1ff5984d6fd657f246d3f251b254ff1
commit r14-2064-g3f97d10aa1ff5984d6fd657f246d3f251b254ff1
Author: Harald Anlauf
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82943
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #22 from Jürgen Reuter ---
(In reply to anlauf from comment #21)
> I forgot to mention that you need to check that the location where a symptom
> is seen sometimes may not be the location of the cause.
Indeed, I think you are right
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110396
Bug ID: 110396
Summary: Compile-time hog with -O2 and -O3
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #23 from anlauf at gcc dot gnu.org ---
You could check the input arguments for validity, e.g. using ieee_is_finite
from the intrinsic ieee_arithmetic module.
use, intrinsic :: ieee_arithmetic, only: ieee_is_finite
...
if (.not.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110396
Andrew Pinski changed:
What|Removed |Added
Component|c++ |tree-optimization
--- Comment #1 from A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102253
Andrew Pinski changed:
What|Removed |Added
CC||luydorarko at vusra dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110396
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102253
--- Comment #4 from Andrew Pinski ---
VRP/ranger uses SCEV now so it might even be worse, the testcase from PR 110396
has that behavior too.
++ --disable-werror
--disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0 20230624 (experimental) [master r14-924-gd709841ae0f] (GCC)
[604] %
[604] % gcctk -O3 -fsel-sched-pipelining -fschedule-insns
-fselective-scheduling2 -fPIC small.c
during RTL pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102253
--- Comment #5 from Andrew Pinski ---
On the trunk with the original testcase here we get:
tree copy headers : 12.16 ( 19%) 0.01 ( 2%) 21.57 ( 28%)
771k ( 0%)
(I suspect the rest is due to not setting release checking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108678
--- Comment #3 from Brecht Sanders
---
Any pointers on which files to edit in order to support aarch64-mingw ?
I think it won't require reinventing the wheel as it will probably be a mix of
existing *-mingw and aarch64-* stuff...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110394
--- Comment #5 from jackyguo18 at hotmail dot com ---
@Andrew Pinski - Thanks, just confirmed that that was the issue.
Why doesn't GCC choose to delete the function (thus causing the weird
behaviour) early at lower optimization levels?
Seems ki
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110394
jackyguo18 at hotmail dot com changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolut
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110394
--- Comment #7 from Andrew Pinski ---
(In reply to jackyguo18 from comment #6)
> @Andrew Pinski - Thanks, just confirmed that that was the issue.
>
> Why doesn't GCC choose to delete the function (thus causing the weird
> behaviour) early at lo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110397
Bug ID: 110397
Summary: types may not be defined in parameter types leads to
ICE
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
Pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110344
Jason Merrill changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110344
--- Comment #3 from Jason Merrill ---
Version of the paper testcase that just adds constexpr, that we currently
reject:
#include
struct Sheep {
constexpr std::string_view speak() const noexcept { return "Baa"; }
};
struct Cow {
constex
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110397
--- Comment #1 from Andrew Pinski ---
Note here is the odd thing about this issue, it only shows up some of the time.
You can reproduce it 100% of the time if you use -fdump-tree-original .
Also don't need the include of iostream (though if usin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93788
Andrew Pinski changed:
What|Removed |Added
CC||stevenxia990430 at gmail dot
com
--- Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110397
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109986
--- Comment #3 from Ivan Sorokin ---
I tried to investigate why GCC is able to simplify `(a | b) ^ a` and `(a | ~b)
^ a` from comment 2, but not similarly looking `(~a | b) ^ a` from comment 0.
`(a | b) ^ a` matches the following pattern from m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78904
--- Comment #18 from CVS Commits ---
The master branch has been updated by Roger Sayle :
https://gcc.gnu.org/g:8f6c747c8638d4c3c47ba2d4c8be86909e183132
commit r14-2065-g8f6c747c8638d4c3c47ba2d4c8be86909e183132
Author: Roger Sayle
Date: Sat J
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110395
--- Comment #1 from Andrew Pinski ---
On the trunk it takes no time at all:
[apinski@xeond2 upstream-gcc-git]$ ~/upstream-gcc/bin/g++ t.cc --coverage
[apinski@xeond2 upstream-gcc-git]$ LD_LIBRARY_PATH=~/upstream-gcc/lib64 ./a.out
[apinski@xeond
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110395
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110395
--- Comment #3 from Andrew Pinski ---
Note it is not an infinite loop, just many basic blocks (over 4 of them)
causing the performance to be very very slow.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79173
--- Comment #32 from Vincent Lefèvre ---
(In reply to Jakub Jelinek from comment #31)
> (In reply to Vincent Lefèvre from comment #30)
> > (In reply to Jakub Jelinek from comment #29)
> > > I mean that if the compiler can't see it is in [0, 1], i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110373
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44384
Andrew Pinski changed:
What|Removed |Added
CC||siddhesh at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77294
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110398
Bug ID: 110398
Summary: Program_Error sem_eval.adb:4635 explicit raise
Product: gcc
Version: 13.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110371
--- Comment #4 from Hongtao.liu ---
I'll take a look.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110399
Bug ID: 110399
Summary: pointer substraction causes coredump with ftrapv on
edge case
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110399
--- Comment #1 from Andrew Pinski ---
32 bit, w1=2
w2=2
w3=2
w4=0
w5=2
Program received signal SIGABRT, Aborted.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110399
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=13421
Andrew Pinski changed:
What|Removed |Added
CC||baiwfg2 at gmail dot com
--- Comment #16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110371
--- Comment #5 from Hongtao.liu ---
Reproduced with
typedef struct dest
{
double m[3][3];
} dest;
typedef struct src
{
int m[3][3];
} src;
void
foo (dest *a, src* s)
{
for (int i = 0; i != 3; i++)
for (int j = 0; j != 3; j++)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110371
--- Comment #6 from Hongtao.liu ---
(In reply to Thiago Jung Bauermann from comment #0)
> Created attachment 55387 [details]
> Output of running gfortran with -freport-bug
>
> In today's trunk (tested commit 33ebb0dff9bb "configure: Implement
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110371
--- Comment #7 from Hongtao.liu ---
(In reply to Hongtao.liu from comment #6)
> (In reply to Thiago Jung Bauermann from comment #0)
> > Created attachment 55387 [details]
> > Output of running gfortran with -freport-bug
> >
> > In today's trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110237
--- Comment #9 from Hongtao.liu ---
> So we can simply clear only MEM_EXPR (and MEM_OFFSET), that cuts off the
> problematic part of alias analysis. Together with UNSPEC this might be
> enough to fix things.
>
Note maskstore won't optimized t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110309
--- Comment #3 from CVS Commits ---
The master branch has been updated by hongtao Liu :
https://gcc.gnu.org/g:c79476da46728e2ab17e0e546262d2f6377081aa
commit r14-2070-gc79476da46728e2ab17e0e546262d2f6377081aa
Author: liuhongt
Date: Tue Jun
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110309
--- Comment #4 from Hongtao.liu ---
Fixed for GCC14.
Note: unspec is not added to maskstore since vpblendd doesn't support memeory
dest, so there's no chance for a maskstore be optimized to vpblendd?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110400
Bug ID: 110400
Summary: Reuse vector register for both scalar and vector
value.
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Prior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110148
--- Comment #3 from cuilili ---
I reproduced S1244 regression on znver3.
Src code:
for (int i = 0; i < LEN_1D-1; i++)
{
a[i] = b[i] + c[i] * c[i] + b[i] * b[i] + c[i];
d[i] = a[i] + a[i+1];
}
---
94 matches
Mail list logo
