https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114750
Bug ID: 114750
Summary: converting load/store of simd fails compilation on ARM
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Comp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114748
--- Comment #6 from Christophe Lyon ---
(In reply to Andrew Pinski from comment #1)
> The last time aclocal.m4 had an include for override.m4 was
> r9-3776-g22e052725189a4 .
IIUC that commit actually removed the include for override.m4 ?
> Ar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114750
Matthias Kretz (Vir) changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |mkretz at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103312
Paul Thomas changed:
What|Removed |Added
CC||pault at gcc dot gnu.org
Assign
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103696
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |12.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114748
--- Comment #7 from Christophe Lyon ---
So yes indeed at r14-5423-gfbe4e64365ec7f, autoreconf will generate the same
contents, but starting at r14-5424-gdb50aea6259545 we get this discrepancy.
We can probably commit the "fixed" version, but sho
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114751
Bug ID: 114751
Summary: .gcda:stamp mismatch with notes file
Product: gcc
Version: 11.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: gcov-prof
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=17951
--- Comment #2 from Richard Biener ---
Created attachment 57970
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57970&action=edit
not quite working patch
Some TLC to all this might make fixing easier. This is a start (at fixing, not
TLC).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=23096
Richard Biener changed:
What|Removed |Added
Status|NEW |WAITING
--- Comment #2 from Richard Bie
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114752
Bug ID: 114752
Summary: AVR: internal compiler error. Unknown mode:
const_double:DF
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: minor
Pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114752
Georg-Johann Lay changed:
What|Removed |Added
Priority|P3 |P5
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114743
--- Comment #2 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:299d14a54672a4d12c1abbe4031a732bb56cddaa
commit r14-1-g299d14a54672a4d12c1abbe4031a732bb56cddaa
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114743
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114750
--- Comment #1 from GCC Commits ---
The master branch has been updated by Matthias Kretz :
https://gcc.gnu.org/g:0fc7f3c6adc8543f55ec35b309016d9d9c4ddd35
commit r14-10001-g0fc7f3c6adc8543f55ec35b309016d9d9c4ddd35
Author: Matthias Kretz
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114752
--- Comment #1 from GCC Commits ---
The master branch has been updated by Georg-Johann Lay :
https://gcc.gnu.org/g:909c6faf2c726178d115726e56304eac91cff6e9
commit r14-10003-g909c6faf2c726178d115726e56304eac91cff6e9
Author: Georg-Johann Lay
Da
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114749
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114432
Stefan Schulze Frielinghaus changed:
What|Removed |Added
Last reconfirmed||2024-4-17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96865
Jeevitha changed:
What|Removed |Added
CC||jeevitha at gcc dot gnu.org
--- Comment #1 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82731
Hongtao Liu changed:
What|Removed |Added
CC||liuhongt at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114751
--- Comment #1 from Richard Biener ---
>From reading what the gcov code does it somehow means that the gcda and gcno
files were not created consistently.
You can use gcov-dump to check the stamp, for an example pair I have around
I see consiste
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114752
--- Comment #2 from GCC Commits ---
The releases/gcc-13 branch has been updated by Georg-Johann Lay
:
https://gcc.gnu.org/g:ca7d454804045a39d10a9b1f691a940aeacdf25b
commit r13-8616-gca7d454804045a39d10a9b1f691a940aeacdf25b
Author: Georg-Johann
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114752
Georg-Johann Lay changed:
What|Removed |Added
Target Milestone|--- |13.3
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114749
--- Comment #2 from GCC Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:bf2b5231312e1cea45732cb8df6ffa2b2c9115b6
commit r14-10005-gbf2b5231312e1cea45732cb8df6ffa2b2c9115b6
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82731
--- Comment #4 from Hongtao Liu ---
(In reply to Hongtao Liu from comment #3)
> Looks like ix86_vect_estimate_reg_pressure doesn't work here, taking a look.
Oh, ix86_vect_estimate_reg_pressure is only for loop, BB vectorizer only use
ix86_builti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114749
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |13.3
Summary|[14] RISC-V rv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82731
--- Comment #5 from Richard Biener ---
We do not BB vectorize gathers I think (ISTR some "loop" uses in the
infrastructure, not too difficult to fix I guess).
In the end the problem is RTL expansion of the CTOR and then lack of
combine?
Look at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114751
--- Comment #2 from Gejoe ---
For me, it is like this (just keeping the sample filenames as such but the
values are real ones shown while checking with gcov-dump) :
$gcov-dump ./obj-dir-path/src-file.gcda
./obj-dir-path/src-file.gcda:data:magi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114745
Gaius Mulley changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114753
Bug ID: 114753
Summary: from_chars aborts with -m32 -ftrapv when passed
-9223372036854775808
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82731
--- Comment #6 from Richard Biener ---
That's ix86_expand_vector_init_interleave which for QI inner_mode extends
to SImode, likely because it tries to work with just SSE2?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114753
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114753
--- Comment #2 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #1)
> With __val = 9223372036854775808LL __sign = -1LL
Oops, that should be __val = 9223372036854775808ULL and __sign = -1
i.e.
int main()
{
unsigned long lon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114753
Richard Biener changed:
What|Removed |Added
Keywords||wrong-code
Component|c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82731
--- Comment #7 from Hongtao Liu ---
(In reply to Hongtao Liu from comment #4)
> (In reply to Hongtao Liu from comment #3)
> > Looks like ix86_vect_estimate_reg_pressure doesn't work here, taking a look.
>
> Oh, ix86_vect_estimate_reg_pressure is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114753
Richard Biener changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114432
--- Comment #2 from Stefan Schulze Frielinghaus
---
Fails for function alog.active_logger.logging_taskT and trace 2 whose heads are
(gdb) call debug(ti->head)
(code_label 48 573 49 152 (nil) [2 uses])
(gdb) call debug(ti->eh_head)
(insn 57 76
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114432
--- Comment #3 from Stefan Schulze Frielinghaus
---
Created attachment 57971
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57971&action=edit
dwarf2cfi dump for alog-active_logger.adb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114753
--- Comment #5 from Jakub Jelinek ---
I wouldn't call it a hack, I'd say it is the right fix.
Though, we have tons of those in internal-fn.cc
ops.code = MULT_EXPR;
ops.code = MULT_EXPR;
ops.code = MULT_EXPR;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114753
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114754
Bug ID: 114754
Summary: [OpenMP] Missing 'uses_allocators' diagnostic
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: accepts-invalid, diagnostic, openmp
Severi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90181
Petr Skocik changed:
What|Removed |Added
CC||pskocik at gmail dot com
--- Comment #16 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105841
Haojian Wu changed:
What|Removed |Added
CC||hokein.wu at gmail dot com
--- Comment #15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114748
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114634
Jakub Jelinek changed:
What|Removed |Added
Summary|[11/12/13/14 Regression]|[11/12/13 Regression] Crash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114741
Jeffrey A. Law changed:
What|Removed |Added
CC||law at gcc dot gnu.org
Prior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114709
Jeffrey A. Law changed:
What|Removed |Added
Priority|P3 |P2
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114677
Jeffrey A. Law changed:
What|Removed |Added
Priority|P3 |P2
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113956
Jeffrey A. Law changed:
What|Removed |Added
CC||law at gcc dot gnu.org
Prior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114741
--- Comment #7 from Wilco ---
(In reply to Tamar Christina from comment #6)
> and the exact armv9-a cost model you quoted, also does the right codegen.
> https://godbolt.org/z/obafoT6cj
>
> There is just an inexplicable penalty being applied to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114741
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=114416
--- Comment #10 from Jakub Kulik ---
Sorry for longer response.
I asked internally again and was told by a colleague who was in the room when
the spec was created, that: "the intent was (and is) that the individual
elements/atoms/fundamental ty
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114416
--- Comment #11 from Jakub Kulik ---
> This is a bit of circular reasoning but, if the rule had been crystal clear,
> GCC would have implemented it at some point during the last quarter of
> century.
I see. I guess it's also not a common enough
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114748
--- Comment #9 from GCC Commits ---
The master branch has been updated by Christophe Lyon :
https://gcc.gnu.org/g:a9fefbf71726bb0ce89c79e547ab3319af3227a8
commit r14-10006-ga9fefbf71726bb0ce89c79e547ab3319af3227a8
Author: Christophe Lyon
Date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114748
Christophe Lyon changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114738
--- Comment #5 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:57056146f4ffc5ea347c03e37e1e2c7cd99261d0
commit r14-10007-g57056146f4ffc5ea347c03e37e1e2c7cd99261d0
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96865
Peter Bergner changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113964
--- Comment #5 from Martin Jambor ---
(In reply to Richard Biener from comment #2)
> No, I think the issue is that ESRA leaves e.f0 alone:
>
> e$f3_7 = e.f3;
> e$f0$f4_8 = e.f0.f4;
> _1 = e$f0$f4_8;
> _2 = (unsigned char) _1;
> e$f3_9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96865
Peter Bergner changed:
What|Removed |Added
Known to fail||12.0, 13.0, 14.0
--- Comment #2 from Pet
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114509
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69031
Peter Bergner changed:
What|Removed |Added
CC||bergner at gcc dot gnu.org
S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85099
Bug 85099 depends on bug 69031, which changed state.
Bug 69031 Summary: ICE: in hash_rtx_cb, at cse.c:2533 with -fPIC
-fselective-scheduling and __builtin_setjmp()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69031
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96865
Segher Boessenkool changed:
What|Removed |Added
CC||abel at ispras dot ru
--- Comment #
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.1 20240417 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96865
--- Comment #4 from Segher Boessenkool ---
Well, I wanted to add Alex as well, but BZ does not allow that? Says he does
not exist?
Is there some other mail address than that mentioned in MAINTAINERS, the one he
usually uses, that works, maybe @
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114739
Paul Thomas changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114676
--- Comment #13 from Andreas Krebbel ---
We will go and fix PyTorch instead. Although it is not clearly documented, the
way PyTorch uses the builtin right now is probably not what was intended. It is
pretty clear that the element type pointer ne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=23096
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |WORKSFORME
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22348
Bug 22348 depends on bug 23096, which changed state.
Bug 23096 Summary: Wrong folding for FLOOR_MOD_EXPR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=23096
What|Removed |Added
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114676
--- Comment #14 from Jakub Jelinek ---
(In reply to Andreas Krebbel from comment #13)
> We will go and fix PyTorch instead. Although it is not clearly documented,
> the way PyTorch uses the builtin right now is probably not what was
> intended.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114755
Jakub Jelinek changed:
What|Removed |Added
Last reconfirmed||2024-04-17
Assignee|unassigne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114756
Bug ID: 114756
Summary: [14] RISC-V rv32imc miscompile with -fdata-sections
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108760
--- Comment #5 from Michael Levine ---
I submitted a patch for this today, see either the gcc-patches or the libstdc++
mailing lists for the subject: [PATCH] libstdc++: Fix std::ranges::iota is not
included in numeric [PR108760]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114756
--- Comment #1 from Andrew Pinski ---
lui a5,%hi(n)
lw a2,%lo(n)(a5)
lw a3,%lo(n+4)(a5)
vs:
lui a5,%hi(.LANCHOR0)
addia5,a5,%lo(.LANCHOR0)
lw a2,0(a5)
lw a3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100604
Andrew Pinski changed:
What|Removed |Added
CC||patrick at rivosinc dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114756
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114756
--- Comment #3 from Andrew Pinski ---
Basically what is happening is the linker relaxation code is turning it into
something which is wrong. But GCC's invalid use of %lo(n+4)(a5) with a
(invalid) corresponding %hi(n) is confusing the relaxation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100604
--- Comment #8 from Andrew Pinski ---
Note this linker relaxation code could be more forgiving here and not producing
"wrong-code" but GCC should be fixed still.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114177
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114757
Bug ID: 114757
Summary: [ASAN] ASAN miscalculates size of region when building
the JDK
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114757
--- Comment #1 from Sonia Zaldana Calles ---
Created attachment 57975
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57975&action=edit
debug log file
Contains a .txt file with the debug log.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114757
Andrew Pinski changed:
What|Removed |Added
Component|other |tree-optimization
Blocks|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108678
--- Comment #10 from Brecht Sanders ---
What is the status of GCC support for aarch64-w64-mingw32 ?
I just tried GCC 14 snapshot 20240414 and it looks like it's still not
supported.
Build fails with:
*** Configuration aarch64-w64-mingw32 not s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108678
--- Comment #11 from Andrew Pinski ---
(In reply to Brecht Sanders from comment #10)
> What is the status of GCC support for aarch64-w64-mingw32 ?
>
> I just tried GCC 14 snapshot 20240414 and it looks like it's still not
> supported.
>
> Buil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114757
--- Comment #3 from Sonia Zaldana Calles ---
Created attachment 57976
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57976&action=edit
ZMarkStack.ii
Preprocessed file for ZMarkStack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114757
--- Comment #4 from Sonia Zaldana Calles ---
Command to compile zMarkStack.cpp
( /usr/bin/rm -f
/home/szaldana/jdk/build/linux-x86_64-server-release/hotspot/variant-server/libjvm/objs/zMarkStack.o.log
&& /usr/bin/g++ -MMD -MF
/home/szaldana/jd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114757
Andrew Pinski changed:
What|Removed |Added
Status|WAITING |UNCONFIRMED
Ever confirmed|1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112976
--- Comment #2 from Andrew Pinski ---
Note gimple_assign_nontemporal_move_p is just for non temporal stores. There is
no code handling non-temporal loads (which do exist on some targets, aarch64
for an example).
I will also add a comment to tha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114758
Bug ID: 114758
Summary: The layout of a std::vector reports a warning
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114759
Bug ID: 114759
Summary: Power: multiple issues with -mrop-protect
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114759
Peter Bergner changed:
What|Removed |Added
CC||dje at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112976
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114758
--- Comment #1 from Chris Lalancette ---
I should also mention that this doesn't happen with gcc 12.3 or earlier. It
seems to only have started happening with gcc 13.1 and 13.2.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114749
--- Comment #4 from JuzheZhong ---
Hi, Patrick.
It seems that Richard didn't append the testcase in the patch.
Could you send a patch to add the testcase for RISC-V port ?
Thangks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114759
--- Comment #2 from Segher Boessenkool ---
> 1. We always define the __ROP_PROTECT__ predefined macro when using
> -mrop-protect, even when we've silently disabled ROP protection because of a
> too old -mcpu=CPU value. We should only emit __R
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114760
Bug ID: 114760
Summary: traling zero count detection failure
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114758
--- Comment #2 from Jonathan Wakely ---
It's just yet another occurrence of false positive -Wstringop-overflow
warnings, it has nothing to do with vector being special.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114746
--- Comment #1 from Vincent Lefèvre ---
There is the same issue with constant floating-point expressions.
Consider the following program given at
https://github.com/llvm/llvm-project/issues/89128
#include
#include
static double const_init
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114746
Vincent Lefèvre changed:
What|Removed |Added
Summary|With FLT_EVAL_METHOD = 2, |With FLT_EVAL_METHOD = 2,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114760
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114729
--- Comment #10 from Vineet Gupta ---
Debug update -fsched-verbose=99 dumps (they are reay verbose)
For the insn/regs under consideration, the canonical pre-scheduled sequence
with ideal live-range (but non-ideal load-to-use delay) is f
1 - 100 of 117 matches
Mail list logo
