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=110762
Richard Biener changed:
What|Removed |Added
Keywords||wrong-code
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110755
Richard Biener changed:
What|Removed |Added
CC||aldyh 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=110762
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
---
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
---
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
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
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
>
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=106952
Richard Biener changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org,
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
--- 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=110741
Kewen Lin changed:
What|Removed |Added
CC||bergner 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=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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110761
Richard Biener changed:
What|Removed |Added
Resolution|--- |INVALID
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=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=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=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=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=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
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=84361
Richard Biener changed:
What|Removed |Added
Resolution|--- |DUPLICATE
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=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=110768
Bug ID: 110768
Summary: [14 Regression] Dead Code Elimination Regression since
r14-2623-gc11a3aedec2
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity:
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110741
Kewen Lin changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Assignee|unassigned at
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
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
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
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=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=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=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=110765
Patrick Palka changed:
What|Removed |Added
Resolution|--- |DUPLICATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109751
Patrick Palka changed:
What|Removed |Added
CC||h2+bugs at fsfe dot org
--- Comment
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
--- 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 #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=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:
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
--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
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=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,
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
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=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
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:
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=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 ->
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=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
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
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=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:
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=102989
Jakub Jelinek changed:
What|Removed |Added
Attachment #55592|0 |1
is obsolete|
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
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
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
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
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
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
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
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
> 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
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
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
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=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:
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
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=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
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
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
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=edit
Reduced example which reproduces the ICE
I'm attaching the reduced example from Vitali's first Compiler Explorer
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 #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=81558
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2023-07-21
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:
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=110774
Bug ID: 110774
Summary: Ambiguous partial ordering with non-dependent function
parameter type
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Keywords:
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=110775
Bug ID: 110775
Summary: arm-openwrt-linux-uclibcgnueabi bug
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgcc
1 - 100 of 146 matches
Mail list logo
