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=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=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=112618
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Known to work|
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
--- 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
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
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
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
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
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=113786
Bug ID: 113786
Summary: cppcheck: return value from find_if not properly
checked ?
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
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:
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
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=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
>
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
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=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=113774
--- Comment #1 from Zdenek Sojka ---
Created attachment 57341
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57341=edit
another testcase, failing at -O1
I didn't check if the PR113753 patch fixes this.
Output:
$ x86_64-pc-linux-gnu-gcc
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=113759
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
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=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:
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:
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:
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 =
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=113784
Bug ID: 113784
Summary: Specialize std::numeric_limits for _Float64x and
friends
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
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=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>
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
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=113763
Jakub Jelinek changed:
What|Removed |Added
Attachment #57338|0 |1
is obsolete|
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=112577
Tejas Belagod changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
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
--- 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:
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=113763
Jakub Jelinek changed:
What|Removed |Added
Attachment #57334|0 |1
is obsolete|
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
--- 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=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=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
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=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
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=113735
--- Comment #6 from Aldy Hernandez ---
Created attachment 57336
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57336=edit
Proposed patch #2
Thanks for the suggestion Jakub.
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
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=edit
Proposed patch
Patch in testing.
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=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=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 #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=113700
Rainer Orth changed:
What|Removed |Added
URL||https://gcc.gnu.org/piperma
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=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
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:
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
101 - 159 of 159 matches
Mail list logo
