https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101571
Bug ID: 101571
Summary: DestroyGuard used by the ranges::uninitialized family
should use addressof()
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101550
--- Comment #2 from amatej at redhat dot com ---
I have: glibc-2.33.9000-43.fc35.x86_64.
Yes that is possible, I have just tried it in a container with:
glibc-2.33-20.fc34.x86_64 and gcc-11.1.1-3.fc34.x86_64 and it doesn't reproduce
there.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101504
H.J. Lu changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |hjl.tools at gmail dot
com
Ever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101393
--- Comment #11 from Alan Modra ---
Preserving certain -m gas options goes back to this patch:
https://sourceware.org/pipermail/binutils/2008-January/054935.html
Given the number of ppc micros around with differing functional units, it is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101570
Bug ID: 101570
Summary: [12 Regression] ICE in
maybe_reconstruct_from_def_stmt, at
analyzer/analyzer.cc:133
Product: gcc
Version: unknown
Status:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101569
Bug ID: 101569
Summary: [GCOV] Wrong coverage caused by callee format.
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101547
David Malcolm changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101522
David Malcolm changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101547
--- Comment #1 from CVS Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:893b12cc12877aca1c9df6272123b26eddf12722
commit r12-2460-g893b12cc12877aca1c9df6272123b26eddf12722
Author: David Malcolm
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101522
--- Comment #2 from CVS Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:87bd75cd49aac68e90bd9b6b5e14582d6e0ccafa
commit r12-2459-g87bd75cd49aac68e90bd9b6b5e14582d6e0ccafa
Author: David Malcolm
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78219
--- Comment #8 from kargl at gcc dot gnu.org ---
(In reply to kargl from comment #7)
> diff --git a/gcc/fortran/match.c b/gcc/fortran/match.c
> index d148de3e3b5..d7668f6a928 100644
> --- a/gcc/fortran/match.c
> +++ b/gcc/fortran/match.c
> @@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83953
--- Comment #4 from kargl at gcc dot gnu.org ---
The original test case also appears to now work.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83953
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101568
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |12.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101568
Bug ID: 101568
Summary: [12 regression] g++.dg/ipa/pr82352.C fails after
r12-2338
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101393
--- Comment #10 from Segher Boessenkool ---
(In reply to Franz Sirl from comment #9)
> (In reply to Segher Boessenkool from comment #8)
> > I don't think it is a good idea to add workaround upon workaround to avoid
> > some of the not-so-useful
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101567
Bug ID: 101567
Summary: Gcc incorrectly allows co_await operator inside
catch-block
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100682
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|--- |11.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101550
--- Comment #1 from David Malcolm ---
Thanks for filing this bug.
What version of glibc are you using?
This looks similar to PR 101081 in that I think it's dependent on the exact
uses of __attribute__((malloc)) within stdio.h.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101564
--- Comment #5 from Steve Kargl ---
On Wed, Jul 21, 2021 at 08:37:02PM +, anlauf at gcc dot gnu.org wrote:
>
> --- Comment #4 from anlauf at gcc dot gnu.org ---
> Patch: https://gcc.gnu.org/pipermail/fortran/2021-July/056264.html
>
OK.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101564
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101536
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101522
David Malcolm changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95483
H.J. Lu changed:
What|Removed |Added
CC||jbeulich at suse dot com
--- Comment #5 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88035
H.J. Lu changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101566
--- Comment #8 from Jonathan Wakely ---
(In reply to Dale Weiler from comment #5)
> This is curious, omitting `decltype(auto)` for get, as in just `auto` seems
> to work around the issue as well.
>
> template
> constexpr auto get(T tuple) {
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101534
Andrew Pinski changed:
What|Removed |Added
URL|https://gcc.gnu.org/piperma |https://gcc.gnu.org/piperma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101566
--- Comment #7 from Dale Weiler ---
Yeah the code example is invalid, there is a reference to a temporary,
decltype(auto) on *ptr produces reference type, somehow I thought it produced
the value type, sorry for the confusion.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101566
Dale Weiler changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101564
--- Comment #3 from kargl at gcc dot gnu.org ---
(In reply to anlauf from comment #2)
> The %kind was introduced probably in r9, so likely not a real regression.
>
> I am testing the following patch:
>
> diff --git a/gcc/fortran/resolve.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101564
--- Comment #2 from anlauf at gcc dot gnu.org ---
The %kind was introduced probably in r9, so likely not a real regression.
I am testing the following patch:
diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101564
kargl at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P4
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40380
--- Comment #6 from Jonathan Wakely ---
My doxygen patch was merged, so we can start to use SHOW_HEADERFILE and
@headerfile to do this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101566
--- Comment #5 from Dale Weiler ---
(In reply to Dale Weiler from comment #4)
> (In reply to Andrew Pinski from comment #3)
> > (In reply to Dale Weiler from comment #2)
> > > Ah, passing `T&` here instead of T does appear to avoid the issue,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101531
Bill Schmidt changed:
What|Removed |Added
Target Milestone|11.2|11.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101531
Bill Schmidt changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88035
--- Comment #3 from Sunil Pandey ---
I added _mm512_reduce_round_pd() and bunch of other missing intrinsic last
year.
commit 93103603fd66a9fcf3ea2d8b52657e4b2496f544
Author: Sunil K Pandey
Date: Wed Oct 14 11:36:39 2020 -0700
x86: Add
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101565
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101566
--- Comment #4 from Dale Weiler ---
(In reply to Andrew Pinski from comment #3)
> (In reply to Dale Weiler from comment #2)
> > Ah, passing `T&` here instead of T does appear to avoid the issue, the
> > question now becomes why does
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101531
--- Comment #2 from CVS Commits ---
The master branch has been updated by William Schmidt :
https://gcc.gnu.org/g:133aa7e54f77fdc15c311ecb52decfb3f52e179c
commit r12-2451-g133aa7e54f77fdc15c311ecb52decfb3f52e179c
Author: Bill Schmidt
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101566
--- Comment #3 from Andrew Pinski ---
(In reply to Dale Weiler from comment #2)
> Ah, passing `T&` here instead of T does appear to avoid the issue, the
> question now becomes why does -fsanitize=undefined find nothing, and is the
> return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101566
--- Comment #2 from Dale Weiler ---
(In reply to Andrew Pinski from comment #1)
> f.0_1 = f_8(D);
> tuple = t;
> _11 = __ts#2;
> tuple ={v} {CLOBBER};
>
>
> template
> constexpr decltype(auto) get(T tuple) { return *tuple(Get{}); }
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101566
--- Comment #1 from Andrew Pinski ---
f.0_1 = f_8(D);
tuple = t;
_11 = __ts#2;
tuple ={v} {CLOBBER};
template
constexpr decltype(auto) get(T tuple) { return *tuple(Get{}); }
I think the above function (get) is broken and is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101494
Martin Sebor changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101562
--- Comment #2 from Andrew Pinski ---
669 /* Insert WIDTH bits from Y into X starting at START. */
670 wide_int
671 wi::insert (const wide_int , const wide_int , unsigned int start,
672 unsigned int width)
673 {
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101566
Bug ID: 101566
Summary: gcc miscompiles lambda used as tuple-like object
applied to function for call
Product: gcc
Version: unknown
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101562
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2021-07-21
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101494
Martin Sebor changed:
What|Removed |Added
Last reconfirmed||2021-07-21
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101565
Bug ID: 101565
Summary: ICE in gfc_simplify_image_index, at
fortran/simplify.c:8234
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101564
Bug ID: 101564
Summary: ICE in resolve_allocate_deallocate, at
fortran/resolve.c:8169
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101563
Bug ID: 101563
Summary: ICE in lookup_template_class_1, at cp/pt.c:10184
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101562
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |9.5
Component|c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101562
Bug ID: 101562
Summary: [9/10/11/12 Regression] ICE in insert, at
wide-int.cc:682
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #275 from dave.anglin at bell dot net ---
On 2021-07-21 12:55 p.m., me at larbob dot org wrote:
> Here's `disas $pc-256,$pc+256`'s output.
Maybe r47 contains garbage.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101561
H.J. Lu changed:
What|Removed |Added
Known to work||12.0
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101549
H.J. Lu changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101561
Bug ID: 101561
Summary: -msse4 -mno-crc32 doesn't disable CRC32 intrinsics
Product: gcc
Version: 11.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101549
--- Comment #1 from CVS Commits ---
The master branch has been updated by H.J. Lu :
https://gcc.gnu.org/g:7aa28dbc371cf3c09c05c68672b00d9006391595
commit r12-2440-g7aa28dbc371cf3c09c05c68672b00d9006391595
Author: H.J. Lu
Date: Wed Jul 21
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101393
--- Comment #9 from Franz Sirl ---
(In reply to Segher Boessenkool from comment #8)
> I don't think it is a good idea to add workaround upon workaround to avoid
> some of the not-so-useful behaviours of -many. Instead, we should just
> not use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101558
--- Comment #2 from Franco Corbelli ---
Thank you, I spend about two days tinkering with Ubuntu's default compiler.
At least I know I'm not completely crazy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #274 from Larkin Nickle ---
Created attachment 51190
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51190=edit
disas of cc1 with more context
Here's `disas $pc-256,$pc+256`'s output.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101379
Martin Sebor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101514
--- Comment #4 from CVS Commits ---
The master branch has been updated by Harald Anlauf :
https://gcc.gnu.org/g:c2b15fe27e6a0e42b108111d51acce69628593b4
commit r12-2439-gc2b15fe27e6a0e42b108111d51acce69628593b4
Author: Harald Anlauf
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101559
--- Comment #4 from Jakub Jelinek ---
You can make the compiler believe it could use computed goto to that label but
actually not do that, say by
void *volatile ptr = &
int volatile cond = 0;
if (cond)
goto *ptr;
But even this would
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101379
--- Comment #10 from CVS Commits ---
The master branch has been updated by Martin Sebor :
https://gcc.gnu.org/g:b937dbf2577e0fa3018c562312da7b08bbe72d70
commit r12-2438-gb937dbf2577e0fa3018c562312da7b08bbe72d70
Author: Martin Sebor
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #273 from John Buddery ---
If you go back a bit further, is there a speculative load of one of those
registers
(probably r47 / r59 ) ?
A speculative load will have a .s I think.
I believe ILL_REGNAT should actually be a SEGV, not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101469
--- Comment #6 from Rin Okuyama ---
(In reply to Rin Okuyama from comment #3)
> If that peephole is removed, GCC 10.3 generates working codes.
>
> NetBSD/shle built by this compiler works fine as far as I can see.
> I'm carrying out full
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101553
--- Comment #2 from Tamar Christina ---
Thanks, I didn't see the patch, I've pinged the maintainers.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101542
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101560
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101560
Andrew Pinski changed:
What|Removed |Added
Summary|ICE building 526.blender_r |[12 Regression] ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101393
Segher Boessenkool changed:
What|Removed |Added
CC||amodra at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101560
Bug ID: 101560
Summary: ICE building 526.blender_r with -Ofast -flto
-march=znver2 since r12-1958-gedafb35bdad
Product: gcc
Version: 12.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96963
Andrew Pinski changed:
What|Removed |Added
CC||franco at francocorbelli dot
com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101558
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101559
--- Comment #3 from Joël Porquet ---
Thanks for the quick replies and the clear explanation!
I'm a little bummed because this construct enabled me to write --what I
considered to be-- clean code for a bootloader. As shown below, I could
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101542
--- Comment #4 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:8edb61420502c62fa2cccdd98876a9aa039b72a6
commit r12-2437-g8edb61420502c62fa2cccdd98876a9aa039b72a6
Author: Jonathan Wakely
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #272 from Larkin Nickle ---
(In reply to dave.anglin from comment #271)
> On 2021-07-21 2:32 a.m., me at larbob dot org wrote:
> > Reading symbols from
> > /home/larbob/Projects/build-gcc/builds/gcc-11.1.0/.o/./prev-gcc/cc1...BFD:
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28581
Andreas Schwab changed:
What|Removed |Added
CC||joel.porquet at gmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101559
Andreas Schwab changed:
What|Removed |Added
Resolution|INVALID |DUPLICATE
--- Comment #2 from Andreas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101557
--- Comment #4 from Federico Kircheis ---
Indeed.
I just checked the latest versions.
I wonder if there is a common cause that makes this recursive data structure
harder to evaluate at compile time.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101557
--- Comment #3 from Andrew Pinski ---
(In reply to Federico Kircheis from comment #2)
> clang does not reject it:
>
> https://godbolt.org/z/8Mq1e3o3j
clang 11 does reject it but clang 12 does NOT reject it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101557
--- Comment #2 from Federico Kircheis ---
clang does not reject it:
https://godbolt.org/z/8Mq1e3o3j
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101379
Martin Sebor changed:
What|Removed |Added
CC||tnfchris at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101553
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101559
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |INVALID
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101393
Franz Sirl changed:
What|Removed |Added
Attachment #51164|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101559
Bug ID: 101559
Summary: RISCV -- incorrect label address when using -O2
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100493
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2021-07-21
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101557
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101527
--- Comment #3 from 康桓瑋 ---
(In reply to Jonathan Wakely from comment #2)
> I find it surprising, but the CWG consensus seems to be that a friend
> defined inline in the class body is "a member declaration of the befriended
> class".
Hey
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #271 from dave.anglin at bell dot net ---
On 2021-07-21 2:32 a.m., me at larbob dot org wrote:
> Reading symbols from
> /home/larbob/Projects/build-gcc/builds/gcc-11.1.0/.o/./prev-gcc/cc1...BFD:
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101558
Bug ID: 101558
Summary: Abnormal behavior with -O3 : warning: writing 8 bytes
into a region of size 0 [-Wstringop-overflow=]
Product: gcc
Version: og10 (devel/omp/gcc-10)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101557
Bug ID: 101557
Summary: the value of '' is not usable in a constant
expression
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101539
--- Comment #3 from Jakub Jelinek ---
I think the implementation of is_corresponding_member heavily depends on
layout-compatibility ensuring the same sizes and alignments of the members,
otherwise
any comparison of the OFFSET_TYPE values (which
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91602
Serge Belyshev changed:
What|Removed |Added
Keywords||patch
--- Comment #15 from Serge
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101555
--- Comment #1 from Wilson Snyder ---
Created attachment 51187
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51187=edit
Examples and runtimes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87743
H.J. Lu changed:
What|Removed |Added
CC||skpgkp2 at gmail dot com
--- Comment #8 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101556
Bug ID: 101556
Summary: [GCOV] Wrong coverage that may be caused by "ASM" and
"volatile"
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101555
Bug ID: 101555
Summary: Compile slowdown in tree PRE
Product: gcc
Version: 9.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
1 - 100 of 157 matches
Mail list logo
