https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114085
Bug ID: 114085
Summary: Internal (cross) compiler error when building
libstdc++ for the H8/300 family
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114084
--- Comment #2 from Andrew Pinski ---
Here is another testcase, the only use of _BitInt is in the cast, everything
else is a bitfield:
```
struct a
{
unsigned t:(sizeof(int)*8-1);
};
typedef unsigned _BitInt(sizeof(int)*8-1) ub31;
struct a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114037
Xi Ruoyao changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114084
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
Andreas Krebbel changed:
What|Removed |Added
CC||stefansf at linux dot ibm.com
---
ssion algorithms: zlib zstd
gcc version 14.0.1 20240223 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114054
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113749
Gaius Mulley changed:
What|Removed |Added
Attachment #57516|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111289
John David Anglin changed:
What|Removed |Added
CC||danglin at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103433
Andrew Pinski changed:
What|Removed |Added
See Also||https://github.com/llvm/llv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114069
Andrew Pinski changed:
What|Removed |Added
Depends on||103433
See Also|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66499
--- Comment #6 from Jerry DeLisle ---
This is an interesting puzzle. I took the -fdump-tree-original output of
compiling the test case and edited out all except the initialization of the two
variables char1 and char2.
I lined these up so we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112375
Andrew Pinski changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114069
Andrew Pinski changed:
What|Removed |Added
See Also||https://github.com/llvm/llv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114069
Andrew Pinski changed:
What|Removed |Added
Summary|Type punning RISC-V vectors |Type punning RISC-V and SVE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114082
Andrew Pinski changed:
What|Removed |Added
CC||dmalcolm at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114082
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113749
--- Comment #4 from Gaius Mulley ---
Created attachment 57516
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57516=edit
Proposed fix
Here is a proposed patch. The bug fix changes the FIO module to use the target
O_RDONLY, O_WRONLY,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114083
--- Comment #4 from Maciej W. Rozycki ---
The flag enables the use of the conditional-move operations even with
hardware that has no support for such operations, hence unconditionally.
Such operations, where unavailable, are then synthesized as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114024
--- Comment #4 from GCC Commits ---
The master branch has been updated by Harald Anlauf :
https://gcc.gnu.org/g:80d126ba99f4b9bc64d4861b3c4bae666497f2d4
commit r14-9160-g80d126ba99f4b9bc64d4861b3c4bae666497f2d4
Author: Steve Kargl
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114028
--- Comment #3 from GCC Commits ---
The master branch has been updated by Robin Dapp :
https://gcc.gnu.org/g:85c12ae8b80902ed46c97f33dbb61533e07f2905
commit r14-9159-g85c12ae8b80902ed46c97f33dbb61533e07f2905
Author: Robin Dapp
Date: Thu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114083
Jonathan Wakely changed:
What|Removed |Added
CC||macro at orcam dot me.uk
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77504
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114083
--- Comment #2 from Roland Illig ---
I don't understand why the word 'unconditionally' is necessary or useful here.
Isn't the option -mmovcc by itself already a condition? That would make the
word 'unconditionally' wrong.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114083
--- Comment #1 from Andrew Pinski ---
This is not a play on words though. The flag enables the use of "conditional
moves" always (unconditionally).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114082
--- Comment #1 from Roland Illig ---
If you decide to keep the guidelines, here are a few ideas:
* Use the simplest English you can, while still being precise.
* Don't try to be funny. (See #114083 for a possible case)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114083
Bug ID: 114083
Summary: Possible word play on conditional/unconditional
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: documentation
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66874
--- Comment #5 from Andreas Schwab ---
If the unwinder crashes you have either incorrect unwind info or a corrupted
stack. Neither should be papered over.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114082
Bug ID: 114082
Summary: Guidelines for options are empty
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: documentation
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77504
Walter Spector changed:
What|Removed |Added
CC||w6ws at earthlink dot net
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114081
Tamar Christina changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |tnfchris at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114081
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114081
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114081
--- Comment #4 from Andrew Pinski ---
(In reply to Sam James from comment #1)
> I can reproduce with: gcc -c ./ext/filter/filter.i -march=znver2
> -fno-vect-cost-model -O3.
`-O3 -fno-vect-cost-model -mavx2` is enough with my reduced testcase.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114081
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114081
--- Comment #2 from Andrew Pinski ---
Created attachment 57515
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57515=edit
Reduced
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114068
--- Comment #14 from Tamar Christina ---
patch submitted
https://gcc.gnu.org/pipermail/gcc-patches/2024-February/646415.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113083
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113083
--- Comment #8 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:fdf9df9d55802e1d8ff0bd14585ea61b2bb9d798
commit r14-9158-gfdf9df9d55802e1d8ff0bd14585ea61b2bb9d798
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114081
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |14.0
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114078
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114073
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66874
--- Comment #4 from Sam James ---
I was just going off "incorrect debug info" in comment 0 given it's the only
thing I changed recently. If not, then I've got no idea.
If I were sure it were dwz, I'd file a bug there ;)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66874
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114077
--- Comment #5 from Andrew Pinski ---
This fixes patch causes the code to be rejected:
```
diff --git a/gcc/function.cc b/gcc/function.cc
index 5ffd438475e..7a0f7faa2d7 100644
--- a/gcc/function.cc
+++ b/gcc/function.cc
@@ -242,7 +242,7 @@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66874
Sam James changed:
What|Removed |Added
CC||arsen at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114077
Andrew Pinski changed:
What|Removed |Added
See Also|https://gcc.gnu.org/bugzill |
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114080
--- Comment #9 from Jakub Jelinek ---
Note, most not too old compilers handle small constant size memcpy as an
efficient way to load/store unaligned values and it is also portable. So,
instead of
*dstp = *srcp ^ *bufp;
if all those can be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114077
--- Comment #2 from Andrew Pinski ---
Oh yes because I am building without `--enable-checking=release` .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114077
--- Comment #3 from Andrew Pinski ---
#5 0x0110cb3f in simplify_const_unary_operation (code=ZERO_EXTEND,
mode=E_DImode, op=0x776e0440, op_mode=E_SImode) at
../../gcc/simplify-rtx.cc:2131
2131 result = wide_int::from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114077
--- Comment #1 from Andrew Pinski ---
I get a different ICE:
t5.c: In function ‘foo’:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113986
--- Comment #4 from Wilco ---
Patch: https://gcc.gnu.org/pipermail/gcc-patches/2024-February/646408.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114080
--- Comment #8 from Chris Rapier ---
My apologies for misunderstanding and for coming across as aggressive in my
last response. This section of the code is about 15 years old so it hasn't,
obviously, been subject to a close enough review until
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114081
--- Comment #1 from Sam James ---
I can reproduce with: gcc -c ./ext/filter/filter.i -march=znver2
-fno-vect-cost-model -O3.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114081
Bug ID: 114081
Summary: [14 regression] ICE in verify_dominators when building
php-8.3.3 (error: dominator of 16 should be 111, not
3)
Product: gcc
Version:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114080
--- Comment #7 from Andrew Pinski ---
(In reply to Chris Rapier from comment #5)
> So what you are saying is that behaviour *has* changed and what was a valid
> operation for 15 years is now invalid. I'm not mad about that. I just needed
> to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114080
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114080
--- Comment #5 from Chris Rapier ---
So what you are saying is that behaviour *has* changed and what was a valid
operation for 15 years is now invalid. I'm not mad about that. I just needed to
know.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113059
--- Comment #27 from Sam James ---
Can someone sanity-check me on this by trying the instructions at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114079#c0?
I think I can still hit the original crash, it's just flaky (it might pass
sometimes).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113059
--- Comment #26 from Sam James ---
*** Bug 114079 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114079
Sam James changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114080
--- Comment #4 from Jonathan Wakely ---
You could have checked this very easily using -fsanitize=undefined just like it
asks you to at https://gcc.gnu.org/bugs/ and at the top of the page when you
created this bug.
dst is 512-bit aligned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114080
--- Comment #3 from Jakub Jelinek ---
The testcase segfaults since r13-1607-gc3ed9e0d6e96d8697e4bab994f8acbc5506240ee
when the backend started using more aggressively vector instructions for
operations like the 128-bit logical ops, but that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114080
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114080
--- Comment #1 from Jakub Jelinek ---
That is undefined behavior, __int128/__int128_t/__uint128_t needs 16-byte
alignment.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114080
Bug ID: 114080
Summary: Inconsistent handling of 128bit ints between GCC
versions
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
*To be removed from our mailing list, please respond to this message with
UNSUBSCRIBE in the subject line*
--
**
11th INTERNATIONAL SCHOOL ON DEEP LEARNING
(and the Future of Artificial Intelligence)
DeepLearn 2024
Porto – Maia,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114070
--- Comment #7 from Richard Biener ---
Created attachment 57512
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57512=edit
patch I am testing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114010
--- Comment #10 from Manolis Tsamis ---
(In reply to ptomsich from comment #9)
> (In reply to Manolis Tsamis from comment #0)
> > E.g. another loop, non canonicalized names:
> >
> > .L120:
> > ldr q30, [x0], 16
> > moviv29.2s,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113205
--- Comment #12 from Richard Sandiford ---
Created attachment 57511
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57511=edit
Candidate patch
Sorry for the very slow response on this. I'm testing the attached.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114076
--- Comment #2 from Jiang An ---
The "templatization" trick also works for GCC.
https://godbolt.org/z/8PeMMzsbb
```
template
struct holder {
holder() = default;
constexpr ~holder() {
static_assert(sizeof(T) || true);
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113205
Richard Sandiford changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114076
Jiang An changed:
What|Removed |Added
CC||de34 at live dot cn
--- Comment #1 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114079
--- Comment #1 from Sam James ---
I'll bisect it now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114010
--- Comment #9 from ptomsich at gcc dot gnu.org ---
(In reply to Manolis Tsamis from comment #0)
> E.g. another loop, non canonicalized names:
>
> .L120:
> ldr q30, [x0], 16
> moviv29.2s, 0
> ld2 {v26.16b -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104850
Jiang An changed:
What|Removed |Added
CC||de34 at live dot cn
--- Comment #5 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114079
Bug ID: 114079
Summary: [14 regression] fftw fails tests again with -O3
-march=znver2 -m32
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112922
Richard Sandiford changed:
What|Removed |Added
Resolution|--- |FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 112922, which changed state.
Bug 112922 Summary: [14 Regression] 465.tonto from SPECFP 2006 fails train run
on Aarch64-linux with -O2 and -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112922
What
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113295
Richard Sandiford changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 113295, which changed state.
Bug 113295 Summary: [14 Regression] SPEC 2006 416.gamess miscompares on Aarch64
when built with -Ofast -mcpu=native since
g:2f46e3578d45ff060a0a329cb39d4f52878f9d5a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113613
Richard Sandiford changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113613
--- Comment #8 from GCC Commits ---
The trunk branch has been updated by Richard Sandiford :
https://gcc.gnu.org/g:ff442719cdb64c9df9d069af88e90d51bee6fb56
commit r14-9157-gff442719cdb64c9df9d069af88e90d51bee6fb56
Author: Richard Sandiford
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113295
--- Comment #8 from GCC Commits ---
The trunk branch has been updated by Richard Sandiford :
https://gcc.gnu.org/g:9f105cfdc1bca6c9224384b3044c4ca5894e1e4c
commit r14-9156-g9f105cfdc1bca6c9224384b3044c4ca5894e1e4c
Author: Richard Sandiford
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113295
--- Comment #7 from GCC Commits ---
The trunk branch has been updated by Richard Sandiford :
https://gcc.gnu.org/g:8a16e06da97f51574cfad17e2cece2e58571305d
commit r14-9155-g8a16e06da97f51574cfad17e2cece2e58571305d
Author: Richard Sandiford
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114062
--- Comment #3 from dave.anglin at bell dot net ---
On 2024-02-23 4:09 a.m., doko at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114062
>
> --- Comment #2 from Matthias Klose ---
> this is seen when building with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114078
Bug ID: 114078
Summary: operator new and operator delete are incorrectly
acceptable as explicit object member functions
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108120
Richard Earnshaw changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108120
--- Comment #7 from GCC Commits ---
The releases/gcc-11 branch has been updated by Richard Earnshaw
:
https://gcc.gnu.org/g:98032b3e320a5b63309d6a843f6e97fb0506953a
commit r11-11251-g98032b3e320a5b63309d6a843f6e97fb0506953a
Author: Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108120
--- Comment #6 from GCC Commits ---
The releases/gcc-12 branch has been updated by Richard Earnshaw
:
https://gcc.gnu.org/g:0de82d2c2ec0b7ed65a1122884feab40f90c0483
commit r12-10174-g0de82d2c2ec0b7ed65a1122884feab40f90c0483
Author: Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114075
--- Comment #5 from jchrist at linux dot ibm.com ---
Just sent a v2 of the patch including your suggested test and updated the
commit message.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105645
Julian Waters changed:
What|Removed |Added
CC||tanksherman27 at gmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114075
--- Comment #4 from jchrist at linux dot ibm.com ---
(In reply to Jakub Jelinek from comment #2)
> Ah, there is
> https://gcc.gnu.org/pipermail/gcc-patches/2024-February/645928.html
> but that didn't come up with a testcase.
> Not sure if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114068
--- Comment #13 from Tamar Christina ---
Created attachment 57510
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57510=edit
candidate-patch1.patch
candidate patch being tested.
I was hoping to correct it during peeling itself when the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114070
--- Comment #6 from Richard Biener ---
So we vectorize this to
_97 = vect__4.15_91 == { 0, 0 };
vect_patt_8.17_98 = VEC_COND_EXPR <_97, { 1, 1 }, { 0, 0 }>;
_102 = vect__5.16_93 != { 0, 0 };
vect_patt_19.18_103 = VEC_COND_EXPR <_102, {
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114074
Jakub Jelinek changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108120
Richard Earnshaw changed:
What|Removed |Added
Summary|[11/12/13 Regression] ICE: |[11/12 Regression] ICE: in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114070
--- Comment #5 from Richard Biener ---
Further reduced:
int unresolved(unsigned dirmask, unsigned mask, int *unresolved_n)
{
for (int i = 0; i < 1024; i++) {
mask |= 1;
if (!unresolved_n[i] || unresolved_n[i] & 7)
dirmask
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108120
--- Comment #5 from GCC Commits ---
The releases/gcc-13 branch has been updated by Richard Earnshaw
:
https://gcc.gnu.org/g:f78d1b9c26c2def0e9c54610e73e21f91b5eb05b
commit r13-8359-gf78d1b9c26c2def0e9c54610e73e21f91b5eb05b
Author: Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114075
--- Comment #3 from Jakub Jelinek ---
(In reply to Jakub Jelinek from comment #1)
> In r14-321 this wasn't vectorized, in r14-322 it is with vf 2, but the
> floating point addition is performed in some weird unsigned long operation
> instead:
>
1 - 100 of 141 matches
Mail list logo
