https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110760
Richard Biener changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
L
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110612
--- Comment #4 from David Binderman ---
(In reply to David Malcolm from comment #3)
> Thanks for filing this.
You are welcome.
> I believe all of these should be fixed by the above commit; please let me
> know if any such warnings remain.
I d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110742
--- Comment #13 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:9a8782e63790842d1bfa03e12eecf73c4aaeb1f8
commit r14-2697-g9a8782e63790842d1bfa03e12eecf73c4aaeb1f8
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110742
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80574
--- Comment #11 from CVS Commits ---
The trunk branch has been updated by Andrew Pinski :
https://gcc.gnu.org/g:6d449531a60b56ed0f4aeb640aa9e46e4ec35208
commit r14-2698-g6d449531a60b56ed0f4aeb640aa9e46e4ec35208
Author: Andrew Pinski
Date: Th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88540
--- Comment #8 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:9f8f37f5490076b10436993fb90d18092a960922
commit r14-2699-g9f8f37f5490076b10436993fb90d18092a960922
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80874
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2023-07-21
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80574
--- Comment #12 from Andrew Pinski ---
Note the original example in comment #0 is now optimized for GCC 14 but only at
the RTL level rather than the gimple level.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110741
Kewen Lin changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Assignee|unassigned at g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110759
--- Comment #11 from Francois-Xavier Coudert ---
Thanks Andrew for fixing it, my mistake. Apologies to everyone.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110741
Kewen Lin changed:
What|Removed |Added
CC||bergner at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110761
Bug ID: 110761
Summary: No warning for an uninitialized variable when used
within its own initialization
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110755
--- Comment #5 from Jakub Jelinek ---
A big hammer solution might be to treat flag_rounding_math in frange::set the
same as
!HONOR_SIGNED_ZEROS, i.e. always extend [0, x] ranges to [-0, x] and [y, -0] to
[y, 0]
because we don't know what the rou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106952
Richard Biener changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110170
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|REOPENED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67962
--- Comment #4 from Richard Biener ---
(In reply to Andrew Pinski from comment #3)
> Mine, but for gcc 13. The main problem I see if two cmov might be slower
> than a branch on x86_64 processors.
Two cmov definitely, a min/max pair not.
Now, p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110754
--- Comment #6 from Martin Uecker ---
One should check whether there is a similar issue with atomics, at least
regarding accidentally introducing memory ordering or so.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110755
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=110762
Bug ID: 110762
Summary: inappropriate use of SSE (or AVX) insns for v2sf mode
operations
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110717
--- Comment #11 from Jakub Jelinek ---
To handle this in generic code, I think expand_expr_real_2 woiuld need to
notice this case of << operand of arithmetic >> by same amount and tell that to
expand_variable_shift -> expand_shift_1 -> expand_bi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110762
--- Comment #1 from Richard Biener ---
So what's the issue? That this is wrong for -ftrapping-math? Or that the
return value has undefined contents in the upper half? (I don't think the
ABI specifies how V2SF is returned)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110762
Richard Biener changed:
What|Removed |Added
Keywords||wrong-code
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110761
Richard Biener changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110762
--- Comment #3 from Uroš Bizjak ---
(In reply to Richard Biener from comment #1)
> So what's the issue? That this is wrong for -ftrapping-math? Or that the
> return value has undefined contents in the upper half? (I don't think the
> ABI spec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110762
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110763
Bug ID: 110763
Summary: FAIL: gcc.dg/ubsan/object-size-dyn.c -O2 execution
test
Product: gcc
Version: 13.1.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110762
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102854
Tobias Burnus changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110764
Bug ID: 110764
Summary: [12/13/14 Regression] False positive -Warray-bounds
warning swapping std::thread::id
Product: gcc
Version: 12.3.1
Status: UNCONFIRMED
K
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110762
--- Comment #6 from Richard Biener ---
(In reply to Segher Boessenkool from comment #5)
> (In reply to Richard Biener from comment #2)
> > The
> >
> >(insn 13 4 14 2 (set (reg:V2SF 20 xmm0 [orig:91 x2 ] [91])
> > (vec_select:V2SF (r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110762
--- Comment #7 from Richard Biener ---
I guess for the specific usage we need to wrap this in an UNSPEC?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110762
--- Comment #8 from Richard Biener ---
OTOH the set isn't noop for the xmm0 hardreg (it zeros the upper parts)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110717
--- Comment #12 from Segher Boessenkool ---
(In reply to Jakub Jelinek from comment #9)
> Wonder how many important targets provide double-word shift patterns vs.
> ones which expand it through generic code.
Very long ago rs6000 had special cod
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110762
--- Comment #9 from jbeulich at suse dot com ---
(In reply to Richard Biener from comment #1)
> So what's the issue? That this is wrong for -ftrapping-math?
Even without that option MXCSR may be modified for reasons contained to just
the upper
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110762
--- Comment #10 from Uroš Bizjak ---
(In reply to Richard Biener from comment #7)
> I guess for the specific usage we need to wrap this in an UNSPEC?
Probably, so a MOVQ xmm, xmm insn should be emitted for __builtin_ia32_storelps
(AKA _mm_store
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110762
--- Comment #11 from Richard Biener ---
(In reply to Richard Biener from comment #2)
> The
>
>(insn 13 4 14 2 (set (reg:V2SF 20 xmm0 [orig:91 x2 ] [91])
> (vec_select:V2SF (reg:V4SF 20 xmm0 [94])
> (parallel [
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110762
--- Comment #12 from Richard Biener ---
_mm_storel_pi could be implemented using __builtin_shufflevector these days.
Which shows exactly the same issue:
typedef float __attribute__((vector_size(8))) v2sf_t;
typedef float __attribute__((vector_s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110077
--- Comment #18 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #17 from Jonathan Wakely ---
> I hope this is fixed now.
It is indeed. Thanks a lot.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110765
Bug ID: 110765
Summary: [13 regression] constraints on parameters of derived
type in CRTP base
Product: gcc
Version: 13.1.1
Status: UNCONFIRMED
Severity: norma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110651
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE Uni-Bielefeld.DE> ---
>> --- Comment #1 from Iain Sandoe ---
>> (In reply to Rainer Orth from comment #0)
>>> When bootstrappin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41320
--- Comment #5 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:8cbdb2e4d64461d8a19e033bd33b585187059d8a
commit r14-2708-g8cbdb2e4d64461d8a19e033bd33b585187059d8a
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41320
Richard Biener changed:
What|Removed |Added
Resolution|--- |WONTFIX
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55266
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
Bug 53947 depends on bug 55266, which changed state.
Bug 55266 Summary: vector expansion: 24 movs for 4 adds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55266
What|Removed |Added
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88670
Bug 88670 depends on bug 55266, which changed state.
Bug 55266 Summary: vector expansion: 24 movs for 4 adds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55266
What|Removed |Added
---
--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
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
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=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=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=84361
Richard Biener changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRME
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=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=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=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=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 #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 #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=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=110077
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Status|REOPENED
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=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=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=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=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
ithms: zlib
gcc version 14.0.0 20230721 (experimental) (GCC)
$
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.
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=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=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=102989
Jakub Jelinek changed:
What|Removed |Added
Attachment #55592|0 |1
is obsolete|
> 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=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
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=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=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=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=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=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=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=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=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=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=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=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=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=110756
Andrew Pinski changed:
What|Removed |Added
CC||seurer at gcc dot gnu.org
--- Comment #
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=110770
Andrew Pinski changed:
What|Removed |Added
Target||bpf
Severity|normal
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=110769
Andrew Pinski changed:
What|Removed |Added
Depends on||110641
--- Comment #1 from Andrew Pinsk
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=110766
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
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=110768
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization
Target Milestone|
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=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=110764
--- Comment #2 from Andrew Pinski ---
So reading the original bug report, it is almost definitely an incorrectly
reduced testcase.
1 - 100 of 145 matches
Mail list logo
