https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93116
--- Comment #2 from Andrew Pinski ---
So the biggest issue here is that if we use nop_convert here, we will need to
check for vectors and use view_convert instead of convert in the resulting
output for the patterns.
like what is done for:
/* Fol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54904
Andrew Pinski changed:
What|Removed |Added
Assignee|pinskia at gcc dot gnu.org |unassigned at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109921
--- Comment #11 from Andreas Ziegler ---
Tested successfully cross-compiling for
x86_64-buildroot-linux-uclibc w/o locale
Regression tests successful for
i586-buildroot-linux-uclibc w/o locale
aarch64-buildroot-linux-musl w/ locale
(us
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110066
--- Comment #6 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #5)
> Can you try reverting r13-923-g2d546ff69455f7deadab and try GCC 13 again?
That looks like the only thing that changed between GCC 12 and GCC 13 for
crtbeginT.o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110066
--- Comment #5 from Andrew Pinski ---
Can you try reverting r13-923-g2d546ff69455f7deadab and try GCC 13 again?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110734
--- Comment #4 from Julian Waters ---
My mistake, I forgot to mention that it was indeed inside a function body. I
can't seem to figure out what in parser.cc is causing this bug, anything on
your end?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56590
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization
Severity|n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52628
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90656
--- Comment #1 from Andrew Pinski ---
I suspect this has been fixed already via PR 91269 / PR 91854 .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85180
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |8.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90414
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88556
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization
Severity|n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88502
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110775
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2023-07-22
Summary|arm-openw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110775
Bug ID: 110775
Summary: arm-openwrt-linux-uclibcgnueabi bug
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110774
--- Comment #5 from Brian Bi ---
Partial ordering is different from partial specialization. Partial ordering
selects a best viable function in certain cases where two viable functions are
both instantiated from templates.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110774
--- Comment #4 from Andrew Pinski ---
But these function declarations are not partial specializations as far as I
know.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110774
--- Comment #3 from Andrew Pinski ---
Take:
```
template
struct A { typedef char* type; };
template char* f1(T, char*); // #1
template long* f1(T*, typename A::type*); // #2
char *t;
char **t1;
long* p0;
long *p1 = f1(p0, t1); // choses #2
ch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110774
--- Comment #2 from Andrew Pinski ---
Actually 0 vs nullptr is the same:
```
template
struct A { typedef char* type; };
template char* f1(T, char*); // #1
template long* f1(T*, typename A::type*); // #2
long* p1 = f1(p1, nullptr); // #3
```
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110774
--- Comment #1 from Andrew Pinski ---
The literal 0 is the issue ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110774
Bug ID: 110774
Summary: Ambiguous partial ordering with non-dependent function
parameter type
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Keywords: reject
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110772
--- Comment #4 from Andrew Pinski ---
Note 10.5.0 was the last release in the GCC 10.x series, can you test out GCC
11.4.0 out?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110772
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110773
Andrew Pinski changed:
What|Removed |Added
Component|target |middle-end
--- Comment #1 from Andrew P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110772
--- Comment #2 from Andrew Pinski ---
I am trying to understand what you think is wrong here?
lsrsr3, r3, #7
means logical shift right by 7 and compare against 0.
Also this is big-endian arm so the order of bit fields will be different th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110773
Bug ID: 110773
Summary: [Aarch64] crash (SIGBUS) due to atomic instructions on
under-aligned memory
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53100
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed|2021-08-06 00:00:00 |2023-7-21
--- Comment #5 from Andrew Pin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110772
--- Comment #1 from Roland Illig ---
Created attachment 55599
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55599&action=edit
precompiled code that works as intended
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110772
Bug ID: 110772
Summary: strange code generated for bit-field access
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81558
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2023-07-21
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110764
--- Comment #9 from Jonathan Wakely ---
(In reply to Andrew Pinski from comment #2)
> So reading the original bug report, it is almost definitely an incorrectly
> reduced testcase.
Oops, yes, sorry for not noticing that before filling the bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110768
--- Comment #1 from Andrew Pinski ---
3) optimize_size logic is now different. Originally we started duplicating
iff the first conditional was known to be true by ranger query, but then
we used same limits as for -O2.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110748
--- Comment #13 from Andrew Pinski ---
You could also look at how aarch64 implemented a similar thing (not just for
-0.0 but for many other constants too):
r8-2248-ga217096563e356fa03c .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110727
--- Comment #2 from Thiago Jung Bauermann
---
Thanks! I confirmed that I can't reproduce the problem anymore in trunk.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110764
--- Comment #8 from Maxim Egorushkin ---
It was supposed to be one comment, but I kept clicking "save changes" button
because it provided no visual feedback that the comment was being posted.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110764
--- Comment #7 from Maxim Egorushkin ---
> Can you provide the preprocessed source? Since I can't seem to reproduce it
> with the above.
It should be compiled with "-pthread -std=gnu++14 -O3 -Wall -Wextra -Werror" to
trigger the warning/error.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110764
--- Comment #6 from Maxim Egorushkin ---
> Can you provide the preprocessed source? Since I can't seem to reproduce it
> with the above.
It should be compiled with "-pthread -std=gnu++14 -O3 -Wall -Wextra -Werror" to
trigger the warning/error.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110764
--- Comment #5 from Andrew Pinski ---
(In reply to Maxim Egorushkin from comment #3)
> The original correct reproduction:
>
> #include
> #include
>
> void g(int);
>
> void f() {
> std::vector threads(1);
> threads[0] = std::thread(g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109365
David Malcolm changed:
What|Removed |Added
CC||dmalcolm at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110764
--- Comment #4 from Maxim Egorushkin ---
Full context: https://github.com/max0x7ba/atomic_queue/issues/55
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110764
Maxim Egorushkin changed:
What|Removed |Added
CC||maxim.yegorushkin at gmail dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110748
--- Comment #12 from Vineet Gupta ---
> void znd(double *d) { *d = -0.0; }
> void znf(float *f) { *f = -0.0; }
The rough approach I'm thinking of is to
(1) Introduce a constraint for -0.0 and perhaps a predicate as well for
"*movdf_hardfloat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110748
--- Comment #11 from Vineet Gupta ---
There's a variation which can be optimized as well and seems non trivial to
implement
Now it is the negative constant -0.0 to be stored to mem. In bit notation this
has a single sign bit set thus can be opt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110742
--- Comment #15 from Thiago Jung Bauermann
---
Thanks! I confirmed that I can't reproduce the problem anymore in trunk.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110748
--- Comment #10 from Vineet Gupta ---
The fix for handling +0.0 is posted to list - really trivial.
https://gcc.gnu.org/pipermail/gcc-patches/2023-July/625217.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110764
--- Comment #2 from Andrew Pinski ---
So reading the original bug report, it is almost definitely an incorrectly
reduced testcase.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110764
--- Comment #1 from Andrew Pinski ---
hmm, this code seems like undefined code. If I change 1 to 2 as you are
accessing 2 elements via operator[], there is no warning ...
The warning seems correct and even says 1 bounds is above the array bound
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102051
--- Comment #4 from Harris Hancock ---
Created attachment 55597
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55597&action=edit
Reduced example which reproduces the ICE
I'm attaching the reduced example from Vitali's first Compiler Explo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110768
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization
Target Milestone|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102051
Harris Hancock changed:
What|Removed |Added
CC||harris.hancock at gmail dot com
--- Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110766
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110766
Andrew Pinski changed:
What|Removed |Added
Summary|ICE on valid code at -O3 on |[14 Regression] ICE on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110769
Andrew Pinski changed:
What|Removed |Added
Depends on||110641
--- Comment #1 from Andrew Pinsk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110641
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110770
Andrew Pinski changed:
What|Removed |Added
Target||bpf
Severity|normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110771
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110756
Andrew Pinski changed:
What|Removed |Added
CC||seurer at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110669
--- Comment #11 from CVS Commits ---
The master branch has been updated by Roger Sayle :
https://gcc.gnu.org/g:cfe53af09364d94fb86013f85ef598a1d47e0657
commit r14-2721-gcfe53af09364d94fb86013f85ef598a1d47e0657
Author: Roger Sayle
Date: Fri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110699
--- Comment #2 from CVS Commits ---
The master branch has been updated by Roger Sayle :
https://gcc.gnu.org/g:cfe53af09364d94fb86013f85ef598a1d47e0657
commit r14-2721-gcfe53af09364d94fb86013f85ef598a1d47e0657
Author: Roger Sayle
Date: Fri J
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110771
Bug ID: 110771
Summary: [14 regression] g++.dg/gomp/pr58567.C fails after
r14-2655-g92d1425ca78040
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: nor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110757
--- Comment #2 from Martin Jambor ---
The second slow-down of 4.5% was caused by r14-2546-g061f74c06735e1:
061f74c06735e1fa35b910ae0bcf01b61a74ec23 is the first bad commit
commit 061f74c06735e1fa35b910ae0bcf01b61a74ec23
Author: Jan Hubicka
Dat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110770
--- Comment #1 from CVS Commits ---
The master branch has been updated by Cupertino Miranda :
https://gcc.gnu.org/g:77d0f9ec3809b4d2e32c36069b6b9239d301c030
commit r14-2720-g77d0f9ec3809b4d2e32c36069b6b9239d301c030
Author: Cupertino Miranda
D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110770
Bug ID: 110770
Summary: bpf: add pseudoc assembly dialect
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110382
--- Comment #3 from Marek Polacek ---
(In reply to Marek Polacek from comment #2)
> Note that changing
> double a = 0;
> to
> double a = 0.;
> gets rid of the ICE!
...because the latter means the {} is reduced_constant_expression_p and
TREE_CON
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110653
--- Comment #21 from Jonathan Wakely ---
(In reply to dave.anglin from comment #20)
> The stoll and stoull tests pass when dg-require-string-conversions is 1.
> The stold test
> fails, I think because it returns LDBL_MAX instead of HUGE_VALL (i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110653
--- Comment #20 from dave.anglin at bell dot net ---
On 2023-07-19 6:10 a.m., redi at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110653
>
> --- Comment #17 from Jonathan Wakely ---
> (In reply to Jonathan Wakely from c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110106
--- Comment #5 from CVS Commits ---
The trunk branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:e36d1994051122fc6e1f8c728fbd109a59e0a822
commit r14-2717-ge36d1994051122fc6e1f8c728fbd109a59e0a822
Author: Marek Polacek
Date: Tu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110316
--- Comment #3 from Andrew Pinski ---
See https://gcc.gnu.org/pipermail/gcc-patches/2023-July/625180.html thread too
which is exactly about this issue.
Basically what is happening is after inlining, there is now fused multiple
subtract being us
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110727
--- Comment #1 from CVS Commits ---
The master branch has been updated by Jan Hubicka :
https://gcc.gnu.org/g:a31ef26b056d0c4f0a9f08b6eb81456ea257298e
commit r14-2716-ga31ef26b056d0c4f0a9f08b6eb81456ea257298e
Author: Jan Hubicka
Date: Fri J
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110382
--- Comment #2 from Marek Polacek ---
Cleaned-up test:
struct S {
double a = 0;
};
constexpr double
g ()
{
S arr[1];
S s = arr[0];
return s.a;
}
int main() { return g (); }
Note that changing
double a = 0;
to
double a = 0.;
gets rid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110757
Martin Jambor changed:
What|Removed |Added
CC||jamborm at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110758
--- Comment #2 from Jan Hubicka ---
> I suspect this is most likely the profile updates changes ...
Quite possibly. The goal of this excercise is to figure out if there are
some bugs in profile estimate or whether passes somehow preffer broken
p
> I suspect this is most likely the profile updates changes ...
Quite possibly. The goal of this excercise is to figure out if there are
some bugs in profile estimate or whether passes somehow preffer broken
profile or if it is just back luck.
Looking at sphinx and fatigue it seems that LRA really
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989
Jakub Jelinek changed:
What|Removed |Added
Attachment #55592|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110717
--- Comment #14 from Andrew Pinski ---
(In reply to Segher Boessenkool from comment #13)
> So. Before expand we have
>
> _6 = (__int128) x_3(D);
> x.0_1 = _6 << 59;
> _2 = x.0_1 >> 59;
Jakub is trying to emulate this using shifts but t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110717
--- Comment #13 from Segher Boessenkool ---
So. Before expand we have
_6 = (__int128) x_3(D);
x.0_1 = _6 << 59;
_2 = x.0_1 >> 59;
_4 = (__int128 unsigned) _2;
return _4;
That should have been optimised better :-(
The RTL code it ex
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110066
Aurelien Jarno changed:
What|Removed |Added
CC||aurelien at aurel32 dot net
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110765
--- Comment #2 from Hannes Hauswedell ---
Thanks for the quick reply. I agree it is the same problem.
ithms: zlib
gcc version 14.0.0 20230721 (experimental) (GCC)
$
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110765
Patrick Palka changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109751
Patrick Palka changed:
What|Removed |Added
CC||h2+bugs at fsfe dot org
--- Comment #22
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110768
Bug ID: 110768
Summary: [14 Regression] Dead Code Elimination Regression since
r14-2623-gc11a3aedec2
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110756
--- Comment #3 from Patrick Palka ---
Whoops, sorry for not catching this.. I agree with Andrew, and your proposed
patch looks good to me FWIW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110751
--- Comment #20 from rsandifo at gcc dot gnu.org
---
(In reply to Richard Biener from comment #19)
> Sure, I can kind of see the usefulness elsewhere. Just for this particular
> issue it doesn't seem necessary to sit down and design this when
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110762
--- Comment #15 from jbeulich at suse dot com ---
(In reply to Richard Biener from comment #12)
> _mm_storel_pi could be implemented using __builtin_shufflevector these days.
> Which shows exactly the same issue:
(also related to comment 10) I d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110077
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Status|REOPENED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109921
Bug 109921 depends on bug 110077, which changed state.
Bug 110077 Summary: [14 regression] libstdc++-abi/abi_check FAILs on Solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110077
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110751
--- Comment #19 from Richard Biener ---
(In reply to rsand...@gcc.gnu.org from comment #18)
> I'd understood LLVM's undef as essentially being “unspecified”, or
> “unspecified bit-pattern” to quote the docs. It doesn't indicate undefined
> beha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110762
--- Comment #14 from Alexander Monakov ---
That seems undesirable in light of comment #4, you'd risk creating a situation
when -fno-trapping-math is unpredictably slower when denormals appear in dirty
upper halves.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110751
--- Comment #18 from rsandifo at gcc dot gnu.org
---
I'd understood LLVM's undef as essentially being “unspecified”, or “unspecified
bit-pattern” to quote the docs. It doesn't indicate undefined behaviour in the
C/C++ sense:
Undefined value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110762
--- Comment #13 from Uroš Bizjak ---
I think we should put all partial vector V2SF operations under
!flag_trapping_math.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
Bug 53947 depends on bug 84361, which changed state.
Bug 84361 Summary: Fails to use vfmaddsub* for complex multiplication
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84361
What|Removed |Added
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81904
--- Comment #3 from Richard Biener ---
*** Bug 84361 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54939
Bug 54939 depends on bug 84361, which changed state.
Bug 84361 Summary: Fails to use vfmaddsub* for complex multiplication
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84361
What|Removed |Added
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84361
Richard Biener changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37021
Bug 37021 depends on bug 54939, which changed state.
Bug 54939 Summary: Very poor vectorization of loops with complex arithmetic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54939
What|Removed |Added
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
Bug 53947 depends on bug 54939, which changed state.
Bug 54939 Summary: Very poor vectorization of loops with complex arithmetic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54939
What|Removed |Added
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54939
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110767
Bug ID: 110767
Summary: vec_{fm,}{addsub,subadd} are missing for AVX512 modes
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compo
--enable-checking=yes --prefix=/local/suz-local/software/local/gcc-trunk
--enable-sanitizers --enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0 20230721 (experimental) [master r14-924-gd709841ae0f] (GCC)
[525
1 - 100 of 145 matches
Mail list logo
