https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113955
--- Comment #2 from YunQiang Su ---
Maybe we can set it as the release target of GCC 15.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114018
Jiang An changed:
What|Removed |Added
CC||de34 at live dot cn
--- Comment #12 from Jia
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113782
Jiang An changed:
What|Removed |Added
CC||de34 at live dot cn
--- Comment #1 from Jian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113955
--- Comment #3 from YunQiang Su ---
-mlra has been set to default since it was added (2014).
So, It is ok for us to remove it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114018
--- Comment #13 from Jakub Jelinek ---
Then I wonder what was the reason for the final LWG3790 revision, the middle
proposed resolution seems to be much more readable and understandable where one
could see exactly what is valid in the synopsis a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114018
--- Comment #14 from Jakub Jelinek ---
Ah, it is described in https://eel.is/c++draft/cmath.syn#2 and probably due to
https://eel.is/c++draft/cmath.syn#3 (so that one can use std::nexttoward(42,
53.0L);
as it has just one floating-point-type arg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113476
--- Comment #7 from Aldy Hernandez ---
Let me see if I can untangle things here. Thanks for chasing
this down, BTW.
Value_Range doesn't need a CTOR because it has an int_range_max which
does have one (courtesy of int_range<>), so things get in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113476
--- Comment #8 from Aldy Hernandez ---
(In reply to Richard Biener from comment #5)
> (In reply to Martin Jambor from comment #4)
> > The right place where to free stuff in lattices post-IPA would be in
> > ipa_node_params::~ipa_node_params() wh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113955
--- Comment #4 from Xi Ruoyao ---
(In reply to YunQiang Su from comment #3)
> -mlra has been set to default since it was added (2014).
> So, It is ok for us to remove it.
Then let's just remove it (maybe after GCC 14 release).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113476
--- Comment #9 from Aldy Hernandez ---
Created attachment 57477
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57477&action=edit
Remove virtual from int_range destructor.
Bootstraps. Tests are pending.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113476
--- Comment #10 from Aldy Hernandez ---
Created attachment 57478
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57478&action=edit
Remove GTY support for vrange and friends
Bootstraps. Tests are pending.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113782
Jonathan Wakely changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113450
--- Comment #14 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #11 from ro at CeBiTec dot Uni-Bielefeld.DE Uni-Bielefeld.DE> ---
>> --- Comment #7 from Jonathan Wakely ---
>> (In reply to Jonathan Wakely from comment #1)
>>> I assum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113295
--- Comment #2 from Tamar Christina ---
bisected to
commit g:2f46e3578d45ff060a0a329cb39d4f52878f9d5a
Author: Richard Sandiford
Date: Thu Dec 14 13:46:16 2023 +
aarch64: Improve handling of accumulators in early-ra
Being very s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113295
--- Comment #3 from Tamar Christina ---
I'm however able to reproduce it at -Ofast alone, no need for `-flto`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113994
Jakub Jelinek changed:
What|Removed |Added
CC||krebbel at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113994
Jakub Jelinek changed:
What|Removed |Added
Summary|Probable C++ code |[13/14 Regression] Probable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113295
Tamar Christina changed:
What|Removed |Added
Keywords|needs-bisection |
Summary|[14 Regression] S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113295
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=113220
--- Comment #4 from GCC Commits ---
The trunk branch has been updated by Richard Sandiford :
https://gcc.gnu.org/g:4f7d4a2cd26673887f45e994a2f367a5c8fcc691
commit r14-9097-g4f7d4a2cd26673887f45e994a2f367a5c8fcc691
Author: Richard Sandiford
Da
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113995
--- Comment #3 from GCC Commits ---
The trunk branch has been updated by Richard Sandiford :
https://gcc.gnu.org/g:ad4df8cd080c9be738f61b5e91cc70a594c4419d
commit r14-9098-gad4df8cd080c9be738f61b5e91cc70a594c4419d
Author: Richard Sandiford
Da
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113220
Richard Sandiford changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113995
Richard Sandiford changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113476
--- Comment #11 from Aldy Hernandez ---
Both patches pass test. Up to the release maintainers to decide if they want
to include them in this release. Otherwise, I'll queue them up for later.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113476
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113450
--- Comment #15 from Jonathan Wakely ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #14)
> Further research has uncovered some interesting facts:
>
> * Neither the SysV SPARC psABI (3rd Edition, 1996) nor the original i386
> psAB
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107071
--- Comment #13 from GCC Commits ---
The master branch has been updated by Tamar Christina :
https://gcc.gnu.org/g:c8c587b854c9e85fc9ce58c8192d532205f0ee1f
commit r14-9104-gc8c587b854c9e85fc9ce58c8192d532205f0ee1f
Author: Tamar Christina
Date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114018
--- Comment #15 from Jonathan Wakely ---
(In reply to Jakub Jelinek from comment #13)
> Then I wonder what was the reason for the final LWG3790 revision, the middle
> proposed resolution seems to be much more readable and understandable where
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113476
--- Comment #13 from Aldy Hernandez ---
(In reply to Jakub Jelinek from comment #12)
> (In reply to Aldy Hernandez from comment #11)
> > Both patches pass test. Up to the release maintainers to decide if they
> > want to include them in this re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114018
--- Comment #16 from Jonathan Wakely ---
We could also just add:
#if __cplusplus > 202002L
template
void
nexttoward(_Tp, long double) = delete;
#endif
The existing overloads would be preferred for float, double, long double and
inte
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114018
--- Comment #17 from Jonathan Wakely ---
Or just:
template
__enable_if_t::value>
nexttoward(_Tp, long double) = delete;
So that it is present for C++11 and so works when _Float32 and _Float64 names
are used instead of the C++23 alias
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114010
--- Comment #4 from Manolis Tsamis ---
Hi Andrew,
Thank for your insights on this. Let me reply to some of your points:
(In reply to Andrew Pinski from comment #1)
> >The most important case I have observed is that the vectorizer can fail or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114018
--- Comment #18 from Jakub Jelinek ---
(In reply to Jonathan Wakely from comment #15)
> void nexttoward(float32_t, long double) = delete;
> void nexttoward(float64_t, long double) = delete;
> void nexttoward(float128_t, long double) = delete;
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114010
--- Comment #5 from Manolis Tsamis ---
Also, I further investigated the codegen difference in the second example (zip
+ umlal vs umull) and it looks to be some sort of RTL ordering + combine issue.
Specifically, when the we expand the RTL for t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113476
--- Comment #14 from Jakub Jelinek ---
Ah, ok, in that case it can wait for stage1.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114018
Jonathan Wakely changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114029
Bug ID: 114029
Summary: -Warray-bounds does not warn for global arrays
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113994
--- Comment #5 from Jakub Jelinek ---
Bisected to r13-1268-g8c99e307b20c502e55c425897fb3884ba8f05882 .
But that just means the bug was latent before that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113988
--- Comment #17 from Jakub Jelinek ---
So, I've tried
--- gcc/gimple-lower-bitint.cc.jj 2024-02-15 09:52:40.999145971 +0100
+++ gcc/gimple-lower-bitint.cc 2024-02-21 12:48:38.704163901 +0100
@@ -5307,12 +5307,15 @@ bitint_large_huge::lowe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113542
Maxim Kuvyrkov changed:
What|Removed |Added
CC||rearnsha at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114030
Bug ID: 114030
Summary: redundant load of inline function's arguments
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113988
--- Comment #18 from Jakub Jelinek ---
Created attachment 57479
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57479&action=edit
gcc14-pr113988.patch
Full untested patch for that variant.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114031
Bug ID: 114031
Summary: gcc rejects valid code with pointer to member field
cast inside a class not completed
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113450
--- Comment #16 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #15 from Jonathan Wakely ---
> (In reply to r...@cebitec.uni-bielefeld.de from comment #14)
>> * When checking clang, there were more surprises:
>>
>> #define __INT8_TYP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113987
Marek Polacek changed:
What|Removed |Added
Keywords||patch
--- Comment #6 from Marek Polacek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114007
Jakub Jelinek changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114032
Bug ID: 114032
Summary: ifcvt may introduce UB calls to __builtin_clz(0)
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114007
--- Comment #14 from Richard Sandiford ---
I might have misunderstood the suggestion and so be arguing against something
that no-one is suggesting, but I think [[__extension__ …]] should accept the
same things for all standard versions (C23, pre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114007
--- Comment #15 from Jakub Jelinek ---
(In reply to Richard Sandiford from comment #14)
> I might have misunderstood the suggestion and so be arguing against
> something that no-one is suggesting, but I think [[__extension__ …]] should
> accept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114032
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113915
--- Comment #13 from Wilco ---
Patch: https://gcc.gnu.org/pipermail/gcc-patches/2024-February/646189.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113476
--- Comment #15 from GCC Commits ---
The master branch has been updated by Martin Jambor :
https://gcc.gnu.org/g:c8742849e22d004b6ab94b3f573639f763e42e3a
commit r14-9115-gc8742849e22d004b6ab94b3f573639f763e42e3a
Author: Martin Jambor
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113476
Martin Jambor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108802
--- Comment #7 from Martin Jambor ---
I have proposed a patch on the mailing list:
https://inbox.sourceware.org/gcc-patches/ri6y1bdx3yg@virgil.suse.cz/T/#u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114031
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114033
Bug ID: 114033
Summary: Failure of test darwin-cfstring1.C
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114033
Francois-Xavier Coudert changed:
What|Removed |Added
Last reconfirmed||2024-02-21
Ever confirmed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114034
Bug ID: 114034
Summary: Failure of tests gcov-dump-{1,2}.C
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114034
Francois-Xavier Coudert changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Target|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114033
--- Comment #1 from Iain Sandoe ---
which actual SDK is this?
you should be able to look at the SDKsettings.plist in the root of the SDK, if
there's any need to discriminate versions with the same name.
(and is it possible to get pre-processed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114035
Bug ID: 114035
Summary: Failure of pr97172-2.c on darwin
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114034
--- Comment #1 from Iain Sandoe ---
let me see if we're adding an extra in the Darwin specs that is covered
elsewhere (sometimes the specs get changed in gcc/gcc.cc and it takes us some
time to sync the ones in darwin.h)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114036
Bug ID: 114036
Summary: Test failure of gcov-14.c on darwin
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114036
Francois-Xavier Coudert changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Target|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114035
Francois-Xavier Coudert changed:
What|Removed |Added
Target||x86_64-apple-darwin23
Last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114036
--- Comment #1 from Iain Sandoe ---
yeah, there is a better way to do this with ld64 (and presumably dyld-ld), my
guess is that this is an anachronism from the ld_classic (v1) days.
We can tell the linker it's OK for a symbol to be undefined -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114036
--- Comment #2 from Iain Sandoe ---
if there are lots of symbols that need to be undefined .. then one can use an
undefined symbols file.
Of course, it does not work if we do not know the symbol names at build-time.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114033
--- Comment #2 from Francois-Xavier Coudert ---
This is latest released version: MacOSX13.3.sdk from CLT 15.1 (on macOS 14.3).
I am attaching the preprocessed source.
The code from CFData.h that is triggering this is:
typedef CF_OPTIONS(CFOpti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114033
--- Comment #3 from Francois-Xavier Coudert ---
Created attachment 57480
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57480&action=edit
Preprocessed source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114036
--- Comment #3 from Francois-Xavier Coudert ---
There's only one symbol we care about here, and its name is known, so I'll make
a patch with your suggestion and test it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114033
--- Comment #4 from Iain Sandoe ---
(In reply to Francois-Xavier Coudert from comment #2)
> This is latest released version: MacOSX13.3.sdk from CLT 15.1 (on macOS
> 14.3).
> I am attaching the preprocessed source.
>
> The code from CFData.h th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114026
--- Comment #3 from GCC Commits ---
The master branch has been updated by Gaius Mulley :
https://gcc.gnu.org/g:161a67b2bee84d8fd5ab7711e411f76221c1ea52
commit r14-9116-g161a67b2bee84d8fd5ab7711e411f76221c1ea52
Author: Gaius Mulley
Date: Wed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114026
Gaius Mulley changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114034
Andrew Pinski changed:
What|Removed |Added
Keywords||testsuite-fail
Component|targe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111960
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111960
--- Comment #7 from Andrew Pinski ---
(In reply to Jakub Jelinek from comment #6)
> Strange, reproduces for me just fine
> /volume/tor/opt/notnfs/gcc-bisect/obj/gcc/cc1.r14-9114 -quiet -O
> --param=max-inline-recursive-depth=100
> -fdump-tre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111960
--- Comment #8 from Jakub Jelinek ---
Ah, not that easily, only in -O0 built compilers, including stage1 of
bootstrapped compilers, stage2/3 don't.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114037
Bug ID: 114037
Summary: ASAN fork should ensure no unwind is in progress
Product: gcc
Version: 12.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Componen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113450
--- Comment #17 from Joseph S. Myers ---
The tests that GCC's internal notion of the types agrees with the headers are
in gcc.dg/c99-stdint-5.c and gcc.dg/c99-stdint-6.c.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114007
--- Comment #16 from Joseph S. Myers ---
I think it's clear that __has_c_attribute(gnu::unused) should only return 1 if
the [[gnu::unused]] syntax is actually parsed. (An unavoidable limitation if it
might return 1 in pre-C23 modes is that if it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111770
--- Comment #2 from Alex Coplan ---
I think to progress this and related cases we need to have .MASK_LOAD defined
to zero in the case that the predicate is false (either unconditionally for all
targets if possible or otherwise conditionally for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108495
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114029
--- Comment #1 from Andrew Pinski ---
Without `const`, GCC warns at -O2 also.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114029
Andrew Pinski changed:
What|Removed |Added
Component|middle-end |c
--- Comment #2 from Andrew Pinski --
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113742
--- Comment #3 from GCC Commits ---
The master branch has been updated by Edwin Lu :
https://gcc.gnu.org/g:3232ebd91ed55b275b9d5a6e8355336382c4afd5
commit r14-9118-g3232ebd91ed55b275b9d5a6e8355336382c4afd5
Author: Edwin Lu
Date: Tue Feb 20
-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r14-9091-20240220194451-g0a6a5f8656c-checking-yes-rtl-df-extra-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.1 20240221 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113867
--- Comment #5 from Tobias Burnus ---
For:
int *q;
#pragma omp target device(y5) map(q, q[:5])
GCC currently generates:
map(tofrom:q [len: 8]) map(tofrom:*q.4_1 [len: 20]) map(attach:q [bias: 0])
Expected:
'alloc:' instead of 'attach:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114024
--- Comment #3 from kargl at gcc dot gnu.org ---
Created attachment 57482
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57482&action=edit
patch
The attached patch fixes this PR. It includes a new testcase
and passes regression testing.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114007
Jakub Jelinek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113295
--- Comment #6 from Richard Sandiford ---
For me the miscompilation is in jkdmem_, where we end up allocating the same
registers to both arms of an fcsel. It sounds like it occurs elsewhere too.
I have a candidate fix, but need to think a bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114023
kargl at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P4
--- Comment #1 from kargl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114038
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111960
--- Comment #9 from Jakub Jelinek ---
Ok, so what I see is a buffer overflow during
97 sprintf (buffer, "%" PRId64 " (%s, freq %.4f)", m_val,
98 profile_quality_display_names[m_quality],
99 to_sreal_s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111960
--- Comment #10 from Jakub Jelinek ---
So, I believe the really problematic change was r14-2389-g3cce8d98f270f48f
which introduced at least in theory the buffer overflow, before that the
maximum string length no matter what m_val was was 62 char
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114039
Bug ID: 114039
Summary: Unroll loops with SSE/AVX intrinsic where an immediate
argument is a loop var
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113249
--- Comment #6 from GCC Commits ---
The master branch has been updated by Edwin Lu :
https://gcc.gnu.org/g:67a29f99cc81384b9245ac5997e47bcf3ff84545
commit r14-9122-g67a29f99cc81384b9245ac5997e47bcf3ff84545
Author: Edwin Lu
Date: Wed Feb 14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113249
--- Comment #7 from GCC Commits ---
The master branch has been updated by Edwin Lu :
https://gcc.gnu.org/g:bc6b42666cfe1467774b942c7afabe480e3b5ccb
commit r14-9123-gbc6b42666cfe1467774b942c7afabe480e3b5ccb
Author: Edwin Lu
Date: Wed Feb 14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114039
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114030
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Summary|redundant load of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114010
--- Comment #6 from ptomsich at gcc dot gnu.org ---
(In reply to Manolis Tsamis from comment #5)
> On of these happens to precede a relevant vector statement and then
> in one case combine does the umlal transformation but in the other not.
Plea
1 - 100 of 121 matches
Mail list logo
