https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95357
Bug ID: 95357
Summary: [11 Regression] ICE in vect_get_constant_vectors, at
tree-vect-slp.c:3655
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: ice-on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95357
Martin Liška changed:
What|Removed |Added
Last reconfirmed||2020-05-27
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95311
--- Comment #1 from Martin Liška ---
@Jason: I would like to do a merge of libsanitizer but this issue is blocking
me right now. One can't do a UBSAN bootstrap right now.
Can you please take a look?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95358
Bug ID: 95358
Summary: [11 Regression] ICE in exact_div, at poly-int.h:2162
since r11-564-g79f0451c67e8ed56
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95358
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95335
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |11.0
Assignee|unassigned at g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95336
Richard Biener changed:
What|Removed |Added
Keywords||wrong-code
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95359
Bug ID: 95359
Summary: Failure to optimize printfs with extraneous arguments
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95338
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87005
David Malcolm changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95340
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |10.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95341
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
--- Comment #4 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95342
Richard Biener changed:
What|Removed |Added
Priority|P3 |P4
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95344
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95348
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2020-05-27
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
Richard Biener changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
Ke
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95356
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95353
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |10.2
Component|middle-end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95242
--- Comment #5 from Daniel Krügler ---
(In reply to Jonathan Wakely from comment #4)
> It's consteval, the throw is there to make it not a constant expression and
> give an error if anything except 0 is used. i.e. it can never throw, it
> either
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95355
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |11.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95357
Richard Biener changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
Ta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95358
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95285
--- Comment #6 from Bu Le ---
(In reply to Wilco from comment #4)
> (In reply to Bu Le from comment #3)
> > (In reply to Wilco from comment #2)
> Well the question is whether we're talking about more than 4GB of code or
> more than 4GB of data.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65181
Tobias Burnus changed:
What|Removed |Added
Keywords||openacc
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95242
--- Comment #6 from Jonathan Wakely ---
It was just a sketch to show the idea.
Obviously the real thing would need noexcept, but we have a regression test for
that. How to construct it is what's relevant here.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95146
--- Comment #6 from Tobias Burnus ---
(In reply to Thomas Koenig from comment #5)
> Moving to the non-traditional C preprocessor will cause havoc with
> the // operator in Fortran.
> c = 'a' // 'b' would then be turned into c = 'a', probably not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95315
--- Comment #3 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:baff22c48bdee9cb644b7336bf6f20f799531507
commit r11-653-gbaff22c48bdee9cb644b7336bf6f20f799531507
Author: Jakub Jelinek
Date: Wed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95340
Martin Liška changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95339
Martin Liška changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95338
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95352
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
Sta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95355
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95314
--- Comment #7 from David Malcolm ---
Created attachment 48615
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48615&action=edit
Non-reproducing attempt at a reproducer
I attempted to reproduce this, but was unsuccessful. I'm attaching wha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
--- Comment #2 from Jonathan Wakely ---
Using
auto t = new(p) std::uint64_t;
std::memcpy(t, std::launder(storage), sizeof(storage));
return t;
also prevents GCC from propagating the dynamic type of p to t.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95354
--- Comment #2 from Jonathan Wakely ---
Allowing the attribute on individual parameters might be nice though.
I hate the fact that for C++ member functions the first parameter is the
implicit 'this' pointer which always has to be non-null anyway
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95285
--- Comment #7 from Bu Le ---
(In reply to Wilco from comment #5)
> (In reply to Bu Le from comment #0)
>
> Also it would be much more efficient to have a relocation like this if you
> wanted a 48-bit PC-relative offset:
>
> adrpx0, bar1.27
gcc-bugsWe Attempted to deliver your item on MAY 27. 2020 but could not
complete the delivery because the dispatch rider did not have access to the
location due to covid19 pandemic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95348
Martin Liška changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
Target Miles
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95354
--- Comment #3 from Haoxin Tu ---
I see. Are there any cases that can trigger the UB of nonnull-attribute? I
doubt the usage of “-fsanitize=nonnull-attribute” in GCC...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88398
--- Comment #27 from Jiu Fu Guo ---
(In reply to Wilco from comment #13)
> So to add some real numbers to the discussion, the average number of
> iterations is 4.31. Frequency stats (16 includes all iterations > 16 too):
>
> 1: 29.0
> 2: 4.2
> 3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
--- Comment #3 from rguenther at suse dot de ---
On Wed, 27 May 2020, redi at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
>
> --- Comment #2 from Jonathan Wakely ---
> Using
>
> auto t = new(p) std::uint64_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95356
--- Comment #2 from Richard Biener ---
So we get v4si for the vector type but the operand is long long int:
3683gcc_assert (vector_type
3684&& types_compatible_p (vector_type,
3685
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95285
--- Comment #8 from Wilco ---
(In reply to Bu Le from comment #6)
> (In reply to Wilco from comment #4)
> > (In reply to Bu Le from comment #3)
> > > (In reply to Wilco from comment #2)
>
> > Well the question is whether we're talking about more
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88398
--- Comment #28 from Jiu Fu Guo ---
(In reply to Jiu Fu Guo from comment #27)
> > 12: 1.2
> > 13: 0.9
> > 14: 0.8
> > 15: 0.7
> > 16: 2.1
> >
>
> Find one interesting thing:
> If using widen reading for the run which > 16 iterations, we can se
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66159
Jonathan Wakely changed:
What|Removed |Added
Keywords||patch
--- Comment #7 from Jonathan Wak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95358
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95356
--- Comment #3 from Richard Biener ---
*** Bug 95358 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95357
Richard Biener changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95356
--- Comment #4 from Richard Biener ---
*** Bug 95357 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95360
Bug ID: 95360
Summary: inconsistent behaviors at -O0
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95360
--- Comment #1 from Yibiao Yang ---
Created attachment 48616
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48616&action=edit
the binary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95285
--- Comment #9 from Wilco ---
(In reply to Bu Le from comment #7)
> (In reply to Wilco from comment #5)
> > (In reply to Bu Le from comment #0)
> >
> > Also it would be much more efficient to have a relocation like this if you
> > wanted a 48-bi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95360
--- Comment #2 from Jonathan Wakely ---
(In reply to Yibiao Yang from comment #0)
> As showed, Line 6 is hit first and then hit Line 7 with stepi.
> However, when using step, gdb is first hit Line 7 and then hit Line 6.
> This is an inconsistent
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95354
--- Comment #4 from Jonathan Wakely ---
(In reply to Haoxin Tu from comment #3)
> I see. Are there any cases that can trigger the UB of nonnull-attribute? I
> doubt the usage of “-fsanitize=nonnull-attribute” in GCC...
Yes, just use the attribut
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95315
--- Comment #4 from Arseny Solokha ---
(In reply to Jakub Jelinek from comment #2)
> Created attachment 48603 [details]
> gcc11-pr95315.patch
>
> Untested fix.
@@ -1823,6 +1850,12 @@ omp_resolve_declare_variant (tree base)
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95315
--- Comment #5 from Jakub Jelinek ---
(In reply to Arseny Solokha from comment #4)
> Shouldn't there be
>
> if (!node_removal_hook_holder)
> node_removal_hook_holder
> = symtab->add_cgraph_removal_hook (…
>
> instead?
Of course, go
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95361
Bug ID: 95361
Summary: Segfault when generating an epilogue for a
partly-shrinked-wrapped SVE frame
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: ice
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95361
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Last reconfirmed||2020-05-27
Sta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95355
--- Comment #2 from Uroš Bizjak ---
This is pre-exsisting problem.
There are a couple of wrong %q modifiers in vpmov* insn templates:
--cut here--
diff --git a/gcc/config/i386/sse.md b/gcc/config/i386/sse.md
index fde65391d7d..1cf1b8cea3b 10064
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
--- Comment #4 from Jonathan Wakely ---
I don't know the answer, and I don't know why it's useful to try this anyway.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95295
--- Comment #7 from rguenther at suse dot de ---
On Wed, 27 May 2020, vsevolod.livinskij at frtk dot ru wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95295
>
> --- Comment #6 from Vsevolod Livinskiy ---
> Thank you for such a quick fix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95335
--- Comment #2 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:a5d8d86e8a72736bfd8a2ce8aa427dec896a442e
commit r11-657-ga5d8d86e8a72736bfd8a2ce8aa427dec896a442e
Author: Richard Biener
Date: W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95335
Richard Biener changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88398
Wilco changed:
What|Removed |Added
CC||wilco at gcc dot gnu.org
--- Comment #29 from Wi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95362
Bug ID: 95362
Summary: [11 regression] pr34457-1.c fails on arm since
ga746f952abb78af9db28a7f3bce442e113877c9c
Product: gcc
Version: 11.0
Status: UNCONFIRMED
S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95362
Christophe Lyon changed:
What|Removed |Added
Summary|[11 regression] pr34457-1.c |[11 regression] pr34457-1.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95363
Bug ID: 95363
Summary: [11 regression] bb-slp-pr95271.c fails on arm since
gc0e27f72358794692e367363940c6383e9ad1e45
Product: gcc
Version: 11.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95336
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95354
--- Comment #5 from Haoxin Tu ---
(In reply to Jonathan Wakely from comment #4)
> (In reply to Haoxin Tu from comment #3)
> > I see. Are there any cases that can trigger the UB of nonnull-attribute? I
> > doubt the usage of “-fsanitize=nonnull-at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95362
Martin Liška changed:
What|Removed |Added
Last reconfirmed||2020-05-27
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95336
--- Comment #9 from Erick Ochoa ---
(In reply to Martin Liška from comment #8)
> I've just tried current gcc-10 branch tip and I can't reproduce it with:
> -mtune=emag -O3 -flto=16
>
> Can you please attach complete build log?
Hi,
I was able t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 95336, which changed state.
Bug 95336 Summary: [10/11 Regression] Bad code gen omnetpp_r aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95336
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95336
Martin Liška changed:
What|Removed |Added
Resolution|--- |INVALID
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95360
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95359
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
Last reconfir
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95285
--- Comment #10 from Bu Le ---
> Fortran already has -fstack-arrays to decide between allocating arrays on
> the heap or on the stack.
I tried the flag with my example. The fstack-array seems cannot move the array
in the bss to the heap. The pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95356
--- Comment #5 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:764ef40ba185ef9245a209ba9260d1e50bec6934
commit r11-658-g764ef40ba185ef9245a209ba9260d1e50bec6934
Author: Richard Biener
Date: W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95356
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92606
Martin Liška changed:
What|Removed |Added
Assignee|marxin at gcc dot gnu.org |unassigned at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95314
--- Comment #8 from bouanto at zoho dot com ---
Created attachment 48617
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48617&action=edit
Small example to reproduce the bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95360
--- Comment #3 from Tom de Vries ---
(In reply to Yibiao Yang from comment #0)
> Breakpoint 1, main () at small.c:5
> 5 for (; d<1; d++)
> (gdb) stepi
> 0x004011545 for (; d<1; d++)
> (gdb) stepi
> 0x0040115a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95314
--- Comment #9 from bouanto at zoho dot com ---
Actually, it seems I was wrong on the conditions to reproduce this issue.
I managed to create a small example to reproduce the issue.
I attached it to the bug report.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95285
--- Comment #11 from Bu Le ---
> You're right, we need an extra add, so it's like this:
>
> adrpx0, bar1.2782
> movk x1, :high32_47:bar1.2782
> add x0, x0, x1
> add x0, x0, :lo12:bar1.2782
>
> > (By the way, the high32_47 relocati
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95337
--- Comment #1 from Nathan Sidwell ---
Oops, I ran my installed compiler, and on this machine that's still 9.3. On
trunk we get one diagnostic. Ignoring the other deprecated reason.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95337
--- Comment #2 from Jonathan Wakely ---
The duplicate "dob" was probably fixed by r10-7159 for PR 67960.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95285
--- Comment #12 from Wilco ---
(In reply to Bu Le from comment #10)
> > Fortran already has -fstack-arrays to decide between allocating arrays on
> > the heap or on the stack.
>
> I tried the flag with my example. The fstack-array seems cannot m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95362
Martin Liška changed:
What|Removed |Added
Target|arm aarch64 |arm, aarch64, x86_64
--- Comment #2 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95314
David Malcolm changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95295
--- Comment #8 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:6c8e16aea85286721eb5689f9bcae09d36003cb1
commit r11-660-g6c8e16aea85286721eb5689f9bcae09d36003cb1
Author: Richard Biener
Date: W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95285
--- Comment #13 from Wilco ---
(In reply to Bu Le from comment #11)
>
> > You're right, we need an extra add, so it's like this:
> >
> > adrpx0, bar1.2782
> > movkx1, :high32_47:bar1.2782
> > add x0, x0, x1
> > add x0, x0,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88398
--- Comment #30 from Jiu Fu Guo ---
(In reply to Wilco from comment #29)
> (In reply to Jiu Fu Guo from comment #28)
> > >
> > > Find one interesting thing:
> > > If using widen reading for the run which > 16 iterations, we can see the
> > > per
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95360
--- Comment #4 from Tom de Vries ---
I compiled the test-case:
...
$ gcc-10 -O0 -g small.c
...
And did the stepi scenario:
...
$ gdb a.out -batch -ex start $(for n in $(seq 1 7); do echo -ex si; done)
Temporary breakpoint 1 at 0x400496: file sma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95285
--- Comment #14 from Bu Le ---
> > Anyway, my point is that the size of single data does't affact the fact that
> > medium code model is missing in aarch64 and aarch64 is lack of PIC large
> > code model.
>
> What is missing is efficient support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95360
--- Comment #5 from Yibiao Yang ---
(In reply to Tom de Vries from comment #3)
> (In reply to Yibiao Yang from comment #0)
> > Breakpoint 1, main () at small.c:5
> > 5 for (; d<1; d++)
> > (gdb) stepi
> > 0x00401154 5 for (;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88398
--- Comment #31 from Wilco ---
(In reply to Jiu Fu Guo from comment #30)
> (In reply to Wilco from comment #29)
> > The key question remains whether it is legal to assume the limit implies the
> > memory is valid and use wider accesses.
> If un
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95360
--- Comment #6 from Yibiao Yang ---
(In reply to Jonathan Wakely from comment #2)
> (In reply to Yibiao Yang from comment #0)
> > As showed, Line 6 is hit first and then hit Line 7 with stepi.
> > However, when using step, gdb is first hit Line 7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95364
Bug ID: 95364
Summary: [Regression] contrib/gcc_update -r 8712 no longer
works
Product: gcc
Version: 10.1.1
Status: UNCONFIRMED
Severity: normal
Prior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95366
Bug ID: 95366
Summary: TYPE IS(character(*)) no longer matches
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95365
Bug ID: 95365
Summary: [11 Regression] Broken gcov since
r11-627-g1dedc12d186a1108
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Pri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95365
Martin Liška changed:
What|Removed |Added
Last reconfirmed||2020-05-27
Status|UNCONFIRMED
1 - 100 of 203 matches
Mail list logo