https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113779
--- Comment #3 from Miro Kropacek ---
> I wonder if the code we emit is measurably slower though? It's possibly
a little bit larger due to the two IV increments.
It's definitely slower as both offsets next to the An registers generate a
separa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113337
--- Comment #3 from GCC Commits ---
The master branch has been updated by Jonathan Yong :
https://gcc.gnu.org/g:16774daa597f7633ae2f64efef20cad744b877b9
commit r14-8819-g16774daa597f7633ae2f64efef20cad744b877b9
Author: Matteo Italia
Date: W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113359
--- Comment #10 from Richard Biener ---
I see the 'pair' type is marked TYPE_CXX_ODR_P, I'd say you should see a
ODR type violation diagnostic, and if you don't, this means we force different
alias sets for both? Not sure - Honza added this stu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113765
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113700
Rainer Orth changed:
What|Removed |Added
URL||https://gcc.gnu.org/piperma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113700
--- Comment #11 from Iain Sandoe ---
(In reply to Rainer Orth from comment #10)
> Patch posted.
FWIW Darwin is, indeed, also affected and I have patches in progress to resolve
it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113781
Bug ID: 113781
Summary: Bug box on array initialisation with iterated
aggregate component
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113700
--- Comment #12 from GCC Commits ---
The master branch has been updated by Rainer Orth :
https://gcc.gnu.org/g:c5f48b5fdde849759d0e3b4effd9352a2399d6f9
commit r14-8820-gc5f48b5fdde849759d0e3b4effd9352a2399d6f9
Author: Rainer Orth
Date: Tue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113700
Rainer Orth changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113735
--- Comment #4 from Aldy Hernandez ---
Created attachment 57335
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57335&action=edit
Proposed patch
Patch in testing.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113735
--- Comment #5 from Jakub Jelinek ---
(In reply to Aldy Hernandez from comment #4)
> Created attachment 57335 [details]
> Proposed patch
>
> Patch in testing.
The testcase should at least use /* { dg-do compile { target bitint } } */
and ideal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113735
--- Comment #6 from Aldy Hernandez ---
Created attachment 57336
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57336&action=edit
Proposed patch #2
Thanks for the suggestion Jakub.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109559
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
Bug 24639 depends on bug 109559, which changed state.
Bug 109559 Summary: [12/13/14 Regression] Unexpected -Wmaybe-uninitialized
warning when inlining with system header
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109559
What|Rem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113753
Jakub Jelinek changed:
What|Removed |Added
Attachment #57327|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113359
--- Comment #11 from Jan Hubicka ---
If there are two ODR types with same ODR name one with integer and other with
pointer types third field, then indeed we should get ODR warning and give up on
handling them as ODR types for type merging.
So d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113763
--- Comment #11 from Richard Sandiford ---
Currently away so can't try it myself, but how about just using an ad-hoc
structure instead?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113763
--- Comment #12 from Jakub Jelinek ---
(In reply to Richard Sandiford from comment #11)
> Currently away so can't try it myself, but how about just using an ad-hoc
> structure instead?
Yeah, I can do that too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86879
Paul Cercueil changed:
What|Removed |Added
CC||paul at crapouillou dot net
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113763
Jakub Jelinek changed:
What|Removed |Added
Attachment #57334|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113763
--- Comment #14 from Richard Sandiford ---
AFAIK, the constructor shouldn't be necessary. (And without it, the whole
thing would fit on one line.) LGTM (and preapproved) otherwise. Thanks for
doing this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112577
--- Comment #2 from GCC Commits ---
The master branch has been updated by Tejas Belagod :
https://gcc.gnu.org/g:ca04e7a2e1b08ed02e22e2656ba6032099195856
commit r14-8821-gca04e7a2e1b08ed02e22e2656ba6032099195856
Author: Tejas Belagod
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113782
Bug ID: 113782
Summary: constexpr on std::initializer_list, std::pair and
std::tuple is non-conforming for C++11
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112577
Tejas Belagod changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113763
--- Comment #15 from Jonathan Wakely ---
Yup, no constructor needed, just make it an aggregate.
I've created PR 113782 for the non-conforming constexpr in libstdc++.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113763
Jakub Jelinek changed:
What|Removed |Added
Attachment #57338|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112858
Jonathan Wakely changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |aoliva at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113749
--- Comment #1 from Gaius Mulley ---
Thanks for the bug report - I suspect this requires the same bug fix as
PR 112920 - gm2 hangs in the type resolver. Although the hang in this PR is in
the bootstrap tool - they both use the same type resolvi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96710
--- Comment #3 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #0)
> Of course the ideal would be for WG14 to accept
> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2425.pdf and then we can
> just say is_integer<__int128> is
with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r14-8817-20240205212943-gc5d34912ad5-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.1 20240206 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113784
Bug ID: 113784
Summary: Specialize std::numeric_limits for _Float64x and
friends
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Prio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113784
Jonathan Wakely changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113703
--- Comment #5 from Richard Biener ---
It's going wrong in iv_elimination_compare_lt which tries to exactly handle
this kind of loop:
We aim to handle the following situation:
sometype *base, *p;
int a, b, i;
i = a;
p = p_0 = b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113759
--- Comment #7 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:760a1a5b5e427707357ca1fa858c4561258972df
commit r14-8823-g760a1a5b5e427707357ca1fa858c4561258972df
Author: Jakub Jelinek
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113736
--- Comment #6 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:483c061d699309d58a1b28ce5c00ee9b55a7365c
commit r14-8824-g483c061d699309d58a1b28ce5c00ee9b55a7365c
Author: Jakub Jelinek
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110676
--- Comment #6 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:d3eac7d96de790df51859f63c13838f153b416de
commit r14-8825-gd3eac7d96de790df51859f63c13838f153b416de
Author: Jakub Jelinek
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110676
Jakub Jelinek changed:
What|Removed |Added
Summary|[11/12/13/14 Regression]|[11/12/13 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113759
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113736
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113774
--- Comment #1 from Zdenek Sojka ---
Created attachment 57341
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57341&action=edit
another testcase, failing at -O1
I didn't check if the PR113753 patch fixes this.
Output:
$ x86_64-pc-linux-gn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113724
--- Comment #1 from Tobias Burnus ---
Debugging shows:
In gimplify_adjust_omp_clauses
(line numbers are off by 1 as I have a #pragma GCC optimize("O0") on top of the
file):
13717 groups = omp_gather_mapping_groups (list_p);
...
13720
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113759
--- Comment #9 from Roger Sayle ---
Many thanks Jakub. Sorry again for the inconvenience.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113359
--- Comment #12 from Jakub Jelinek ---
Just going from the demangled name of
std::pair > > const,
Context*>
it would surprise me if it was ODR violation in the testcase, because class
Context
is only defined in Timer.ii, not in the other preproc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113359
--- Comment #13 from rguenther at suse dot de ---
On Tue, 6 Feb 2024, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113359
>
> --- Comment #12 from Jakub Jelinek ---
> Just going from the demangled name of
> s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113779
--- Comment #4 from Mikael Pettersson ---
I'm not sure this is an m68k bug. I tried several targets that have
auto-increment addressing modes (m68k, pdp11, msp430, vax, aarch64) and none of
them would use auto-increment for this test case.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113779
--- Comment #5 from Miro Kropacek ---
I have been told that one of the reasons why post-incrementing modes are not
supported / preferred these days is that they halt the CPU pipeline (of course,
totally not applicable on m68k). So with the offse
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113785
Bug ID: 113785
Summary: c-c++-common/asan/swapcontext-test-1.c FAILs
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: san
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113786
Bug ID: 113786
Summary: cppcheck: return value from find_if not properly
checked ?
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113779
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110176
--- Comment #12 from GCC Commits ---
The releases/gcc-13 branch has been updated by Richard Biener
:
https://gcc.gnu.org/g:d4216cc2c879ecbdc4df6a2db67f6b6afd7a7d68
commit r13-8287-gd4216cc2c879ecbdc4df6a2db67f6b6afd7a7d68
Author: Richard Biene
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110221
--- Comment #6 from GCC Commits ---
The releases/gcc-13 branch has been updated by Richard Biener
:
https://gcc.gnu.org/g:7c67939ec384425a3d7383dfb4fb39aa7e9ad20a
commit r13-8288-g7c67939ec384425a3d7383dfb4fb39aa7e9ad20a
Author: Richard Biener
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112495
--- Comment #6 from GCC Commits ---
The releases/gcc-13 branch has been updated by Richard Biener
:
https://gcc.gnu.org/g:e22e3ee80f6b83d1f7a7d92be3c3d3f16e56fa17
commit r13-8289-ge22e3ee80f6b83d1f7a7d92be3c3d3f16e56fa17
Author: Richard Biener
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112505
--- Comment #7 from GCC Commits ---
The releases/gcc-13 branch has been updated by Richard Biener
:
https://gcc.gnu.org/g:9895fc7ab14f4cf571071184877f130b7bd0a59b
commit r13-8290-g9895fc7ab14f4cf571071184877f130b7bd0a59b
Author: Richard Biener
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112618
--- Comment #4 from GCC Commits ---
The releases/gcc-13 branch has been updated by Richard Biener
:
https://gcc.gnu.org/g:016ca45dcba40ed73869caf37f09023fa7fca5f8
commit r13-8291-g016ca45dcba40ed73869caf37f09023fa7fca5f8
Author: Richard Biener
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110243
--- Comment #16 from Richard Biener ---
Backporting to GCC 13 causes gcc.dg/tree-ssa/ldist-17.c to FAIL.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112618
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
Bug 53947 depends on bug 112618, which changed state.
Bug 112618 Summary: [13 Regression] internal compiler error: in
expand_MASK_CALL, at internal-fn.cc:4529
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112618
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111478
Richard Biener changed:
What|Removed |Added
Summary|[12/13 Regression] aarch64 |[12 Regression] aarch64 SVE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57346
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113787
Bug ID: 113787
Summary: [14 Regression] Wrong code at -O with ipa-modref on
aarch64
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113787
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113787
--- Comment #2 from Andrew Pinski ---
Also try -fno-ivopts .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86918
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113787
--- Comment #3 from Alex Coplan ---
(In reply to Jakub Jelinek from comment #1)
> Why do you think it is a 14 Regression?
> Seems r12-5166 works fine while r12-6600 already doesn't, so that would make
> it [12/13/14 Regression], no?
Well on the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113787
--- Comment #4 from Alex Coplan ---
Same with the head of the GCC 12 branch, but I agree it isn't a [14 Regression]
as I can reproduce the issue with basepoints/gcc-14, so maybe something was
backported to 12/13 that is making it latent on the b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113787
Jakub Jelinek changed:
What|Removed |Added
Last reconfirmed||2024-02-06
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113787
--- Comment #6 from Andrew Pinski ---
(In reply to Jakub Jelinek from comment #5)
> My bisection points to r12-5915-ge93809f62363ba4b233858005aef652fb550e896
Which means it is related to bug 110702 .
Again try -fno-ivopts . I suspect ivopts is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113787
--- Comment #7 from Alex Coplan ---
(In reply to Andrew Pinski from comment #6)
> (In reply to Jakub Jelinek from comment #5)
> > My bisection points to r12-5915-ge93809f62363ba4b233858005aef652fb550e896
>
> Which means it is related to bug 110
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94231
Marek Polacek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96090
Marek Polacek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99387
--- Comment #4 from Marek Polacek ---
This PR seems to have been fixed by r12-6773:
commit 09845ad7569bac27c3a1dc7b410d9df764d2ca06
Author: Patrick Palka
Date: Thu Jan 20 09:25:49 2022 -0500
c++: CTAD inside alias template [PR91911, PR10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113763
--- Comment #17 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:df9f6b934886f51c0c07220d1ee38874b69646c7
commit r14-8828-gdf9f6b934886f51c0c07220d1ee38874b69646c7
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113763
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112875
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113612
Marek Polacek changed:
What|Removed |Added
Priority|P4 |P2
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113612
--- Comment #3 from Marek Polacek ---
(gdb) up
#1 0x01120e27 in get_partial_spec_bindings (tmpl=,
spec_tmpl=, args=)
at /home/mpolacek/src/gcc/gcc/cp/pt.cc:25888
25888 = TI_ARGS (get_template_info (DECL_TEMPLATE_RESULT (s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113787
--- Comment #8 from Jan Hubicka ---
I will take a look. Mod-ref only reuses the code detecting errneous paths in
ssa-split-paths, so that code will get confused, too. It makes sense for ivopts
to compute difference of two memory allocations, bu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113612
--- Comment #4 from Marek Polacek ---
It was freed here in duplicate_decls:
#1 0x012f535d in ggc_free (p=0x7fffea210e10) at
/home/mpolacek/src/gcc/gcc/ggc-page.cc:1630
#2 0x00e971b2 in duplicate_decls (newdecl=,
olddecl=,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113756
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113756
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113787
--- Comment #9 from Andrew Pinski ---
_57 = &MEM[(int *)0B + _56 + _55 * 1];
*_57 = _14;
The fix for PR 110702 must not have been enough.
Or rather this part of the explanation was fully true:
```
The patch below
recognizes the fallbac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113786
Jonathan Wakely changed:
What|Removed |Added
Blocks||87403
Severity|normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113788
Bug ID: 113788
Summary: Deducing this is broken with structured binding
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94231
--- Comment #3 from GCC Commits ---
The trunk branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:1befe47f64bf0b964be90730e2cbef550cb6d2b7
commit r14-8830-g1befe47f64bf0b964be90730e2cbef550cb6d2b7
Author: Marek Polacek
Date: Tue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94231
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113677
--- Comment #4 from Andrew Pinski ---
Note it is not just about constants either.
Take:
```
#define vect64 __attribute__((vector_size(8) ))
#define vect128 __attribute__((vector_size(16) ))
vect128 unsigned int f(vect64 unsigned int a, vect64 u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113788
Marek Polacek changed:
What|Removed |Added
Last reconfirmed||2024-02-06
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113678
--- Comment #2 from Andrew Pinski ---
Noticed the same with:
```
void f(unsigned char *a, unsigned char *b, unsigned char *c)
{
unsigned char t[8];
t[0] = a[0];
t[1] = a[1];
t[2] = a[2];
t[3] = a[3];
t[4] = b[0];
t[5] = b[1];
t[6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113788
--- Comment #1 from Jakub Jelinek ---
Seems it is far more cases where we allow it:
struct S { int a, b; };
struct U {
void foo () { this int g = 1; }
};
this auto h = 1;
int
main ()
{
S s = { 1, 2 };
short t[3] = { 3, 4, 5 };
this auto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113788
--- Comment #2 from Marek Polacek ---
Yes, seems that currently we only check that it's the first specifier:
/* Special case for "this" specifier, indicating a parm is an xobj parm.
The "this" specifier must be the first specifie
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113788
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113678
--- Comment #3 from Andrew Pinski ---
Note the SLP that happens in connection with the loop vectorizer actually does
a decent job ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113788
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113789
Bug ID: 113789
Summary: ICE on P2266/C++23 `decltype(throw x)` where x is
move-eligible parameter
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: norm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113734
--- Comment #6 from Tamar Christina ---
The reason for the miscompile popping up is this change from the previous patch
diff --git a/gcc/tree-vect-data-refs.cc b/gcc/tree-vect-data-refs.cc
index 109d4ce5192..df3eab2e8d5 100644
--- a/gcc/tree-ve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106882
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |13.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101165
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |13.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113789
Andrew Pinski changed:
What|Removed |Added
Keywords||ice-on-valid-code
--- Comment #1 from A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113789
Marek Polacek changed:
What|Removed |Added
Last reconfirmed||2024-02-06
Assignee|unassigne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113789
Marek Polacek changed:
What|Removed |Added
Summary|ICE on P2266/C++23 |[13/14 Regression] ICE on
1 - 100 of 159 matches
Mail list logo
