https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102519
--- Comment #21 from Aldy Hernandez ---
However, if you care to test a patch, I'd be happy to review it.
On Thu, Sep 30, 2021 at 7:49 AM aldot at gcc dot gnu.org
wrote:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102519
>
> Bernhard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102519
--- Comment #20 from Aldy Hernandez ---
Doesn't make a difference. If the blocks are stale, they need to be
reconstructed anyhow. It's preexisting behavior in VRP anyhow.
I heard you the first time ;-).
On Thu, Sep 30, 2021 at 7:49 AM aldot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102519
Bernhard Reutner-Fischer changed:
What|Removed |Added
CC||aldot at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102537
Bug ID: 102537
Summary: Objective-C: can't use >= USE_FIXUP_BEFORE paths for
non-Darwin
Product: gcc
Version: 10.3.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102536
Bug ID: 102536
Summary: [modules] ICE Error reporting routines re-entered
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102535
Bug ID: 102535
Summary: __is_trivially_constructible rejects some trivial
cases in aggregate initializations
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102169
HaoChen Gui changed:
What|Removed |Added
CC||guihaoc at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80454
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed|2017-08-01 00:00:00 |2021-9-29
Severity|normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68725
--- Comment #4 from Andrew Pinski ---
The copy on the stack is correct as the variable is considered a local variable
and has its address taken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71188
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed|2017-07-29 00:00:00 |2021-9-29
Severity|normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101104
--- Comment #9 from Peter Bergner ---
(In reply to Patrick McGehearty from comment #8)
> Thanks again for helping this fix move forward.
If you have another patch you want me to test, just send it to me and I'll kick
it off.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102519
--- Comment #18 from David Edelsohn ---
Yea! That fixes the *worst* of the memory growth problem for me.
It still is growing, but much more slowly. RSS now grows from 569788 to 642076
for the final function, instead of 783896 before it died
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102519
--- Comment #17 from Jeffrey A. Law ---
Consider that pre-approved.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102527
--- Comment #11 from Aldy Hernandez ---
This looks mighty suspicious ;-)
diff --git a/gcc/tree-vrp.c b/gcc/tree-vrp.c
index 69a3ab0ea9d..c24c67f8874 100644
--- a/gcc/tree-vrp.c
+++ b/gcc/tree-vrp.c
@@ -4408,6 +4408,7 @@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102519
--- Comment #16 from Aldy Hernandez ---
On Wed, Sep 29, 2021 at 10:46 PM dje at gcc dot gnu.org
wrote:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102519
>
> --- Comment #15 from David Edelsohn ---
> I annotated execute_vrp_threader() to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101104
--- Comment #8 from Patrick McGehearty
---
Thanks for the run.
On the plus side, I would expect FAIL or PASS to be consistent
for all optimization levels, so that's actually good that
they all match now.
I'm either I'm mistaken about the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102534
--- Comment #3 from Andrew Pinski ---
With -O1 or -O2 (and -g2), there are no .loc for line 6 at all.
There might not be anything that can be done for that case as inlining removes
it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102534
Andrew Pinski changed:
What|Removed |Added
Summary|RFE epilog is not reliably |RFE epilog is not reliably
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102534
Andrew Pinski changed:
What|Removed |Added
Summary|RFE epilog is not reliably |RFE epilog is not reliably
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102285
--- Comment #8 from qinzhao at gcc dot gnu.org ---
the ICE is triggered by the following IR:
MEM[(int[0:D.1993] *)] = .DEFERRED_INIT (16, 2, 1);
which is transformed from the original IR:
(*fb.1_9) = .DEFERRED_INIT (16, 2, 1);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102534
Bug ID: 102534
Summary: RFE epilog is not reliably a statement
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102527
--- Comment #10 from Rainer Orth ---
(In reply to Aldy Hernandez from comment #6)
> The attached patch adds a separate TV_* timer to see the actual break down
> for VRP and the VRP threader.
>
> Could you incorporate this patch and run the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102527
--- Comment #9 from Rainer Orth ---
Created attachment 51522
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51522=edit
insn-emit.ii -ftime-report output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101104
--- Comment #7 from Peter Bergner ---
(In reply to Peter Bergner from comment #6)
> Ah, the v5 patch. I'll bootstrap and regtest the patch and report back.
Building with and without the patch, I'm seeing:
+FAIL:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102521
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102527
--- Comment #8 from Rainer Orth ---
Created attachment 51521
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51521=edit
i386-pc-solaris2.11 insn-emit.ii
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102527
--- Comment #7 from Rainer Orth ---
(In reply to Aldy Hernandez from comment #4)
> Can it be reproduced on a cross? If so, could you post the .ii file with
> your include file peculiarities?
I haven't tried, but expect it should work,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102510
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102519
--- Comment #15 from David Edelsohn ---
I annotated execute_vrp_threader() to call getrusage() and print the size of
RSS around each call to threader.thread_jumps(). It consistently is growing,
but not in the threader itself. Was the former
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102507
--- Comment #1 from CVS Commits ---
The master branch has been updated by Indu Bhagat :
https://gcc.gnu.org/g:d6a87d96d7473cbd2404d5dcc7eef36a7f53b2b2
commit r12-3972-gd6a87d96d7473cbd2404d5dcc7eef36a7f53b2b2
Author: Indu Bhagat
Date: Wed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101985
--- Comment #4 from Kunwar Maheep Singh ---
(In reply to Bill Schmidt from comment #3)
> Kunwar, can you please tell us (if you don't mind) where the problem was
> detected? Since we're changing behavior of the intrinsic, we'll need to
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102458
--- Comment #13 from anlauf at gcc dot gnu.org ---
Corrected patch that addresses the remaining issue (for valid code):
https://gcc.gnu.org/pipermail/fortran/2021-September/056599.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101104
--- Comment #6 from Peter Bergner ---
(In reply to Patrick McGehearty from comment #5)
> I submitted a patch that I believe resolves the issue on Aug 27, 2021
> and pinged the gcc-patches list on Sept 8, 2021. Allowing for the
> 'distraction'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102533
G. Steinmetz changed:
What|Removed |Added
Keywords||ice-on-invalid-code,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102533
Bug ID: 102533
Summary: ICE in gfc_set_backend_locus, at fortran/trans.c:1861
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102456
--- Comment #2 from G. Steinmetz ---
It compiles when using "size(shape(x))" as a synonym for "rank(x)".
And indeed, that scalar x (from image 1) has rank 0.
$ cat z2.f90
program p
type t
integer :: a
end type
type(t) :: x[*]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102532
G. Steinmetz changed:
What|Removed |Added
Keywords||ice-on-invalid-code
--- Comment #1 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102532
Bug ID: 102532
Summary: [10/11/12 Regression] ICE in gfc_get_corank, at
fortran/expr.c:5769
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92586
--- Comment #10 from epagone ---
Bug persists in version 11.1.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102501
Aldy Hernandez changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102501
--- Comment #3 from CVS Commits ---
The master branch has been updated by Aldy Hernandez :
https://gcc.gnu.org/g:24e30f485bc80c823393d8fc62b65f860230e04b
commit r12-3970-g24e30f485bc80c823393d8fc62b65f860230e04b
Author: Aldy Hernandez
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98731
Jonathan Wakely changed:
What|Removed |Added
CC||miladfarca at gmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102531
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |DUPLICATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101104
--- Comment #5 from Patrick McGehearty
---
(In reply to Peter Bergner from comment #4)
> So what is the status here? Are we just waiting for another patch to be
> submitted or it has been submitted and we're waiting on a review?
I submitted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102104
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
Ever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102520
--- Comment #3 from CVS Commits ---
The master branch has been updated by Harald Anlauf :
https://gcc.gnu.org/g:5e2adfeed21ee584a82cdcdfa7eed41202eb67cd
commit r12-3967-g5e2adfeed21ee584a82cdcdfa7eed41202eb67cd
Author: Harald Anlauf
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101283
Indu Bhagat changed:
What|Removed |Added
CC||ibhagat at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79094
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102519
--- Comment #14 from David Edelsohn ---
I tried the patch, but, unfortunately, it exceeds the memory limit in the same
manner.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102528
--- Comment #1 from Mathias Stearn ---
Sorry, there was a typo in the initial code. I forgot the trivial
implementation of await_resume(). (D'oh!)
Now I can see that test() is just a ret instruction, but there is still a lot
of dead code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102531
Bug ID: 102531
Summary: std::hash does not work correctly on Big Endian
platforms
Product: gcc
Version: 8.4.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102519
--- Comment #13 from Aldy Hernandez ---
Created attachment 51520
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51520=edit
avoid CFG and SSA updates when possible
The VRP threader is updating SSAs and CFG even if nothing changes. This
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102359
--- Comment #2 from qinzhao at gcc dot gnu.org ---
(In reply to Richard Biener from comment #1)
> Confirmed. So we end with '&__closure->__this' which indeed isn't an lvalue.
>
> The issue here is that we are initializing the VAR_DECL 'this'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102530
--- Comment #3 from Jason Merrill ---
A simpler alternative would be to warn about any non-extended temporaries in an
initializer. This would have both more false positives and fewer false
negatives.
If the temporary is passed by value or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102530
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2021-09-29
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102530
--- Comment #1 from Jason Merrill ---
https://wg21.link/cwg900 and https://wg21.link/ewg120 deal with temporary
lifetime issues with range-for. But they involve reference-like classes rather
than C++ reference types; I suppose the warning also
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102519
--- Comment #12 from David Edelsohn ---
GCC non-quiet mode shows:
...
g_31_31_16 f_31_31_17 g_31_31_17 f_31_31_23 g_31_31_23 f_31_31_24 g_31_31_24
f_31_31_25 g_31_31_25 f_31_31_29 g_31_31_29 f_31_31_30 g_31_31_30 f_31_31_31
g_31_31_31
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102530
Bug ID: 102530
Summary: Warn about non-extended temporary passed to a function
returning a reference in temp-extending context
Product: gcc
Version: 12.0
Status:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102445
Bug 102445 depends on bug 84110, which changed state.
Bug 84110 Summary: Null character in regex throws std::regex_error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84110
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84110
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102445
Bug 102445 depends on bug 102480, which changed state.
Bug 102480 Summary: std::regex fails to match ^ when match_prev_avail is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102480
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102480
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |INVALID
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102519
--- Comment #11 from David Edelsohn ---
tree VRP threader : 0.25 ( 2%) 0.03 ( 1%) 0.76 ( 1%)
7804k ( 2%)
Despite that report output, prior to the two patches ending with
ef1e524fd87a679f5da06116029c66a84daac80
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102529
Patrick Palka changed:
What|Removed |Added
Ever confirmed|0 |1
Assignee|unassigned at gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102527
--- Comment #6 from Aldy Hernandez ---
The attached patch adds a separate TV_* timer to see the actual break down for
VRP and the VRP threader.
Could you incorporate this patch and run the problematic file with ./cc1
-ftime-report -O2? I'd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102519
--- Comment #10 from Aldy Hernandez ---
The attached patch adds a separate TV_* timer to see the actual break down for
VRP and the VRP threader.
Could you incorporate this patch and run the problematic file with ./cc1
-ftime-report -O2? I'd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102519
--- Comment #9 from Aldy Hernandez ---
Created attachment 51519
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51519=edit
patch to help diagnose issue with -ftime-report
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102527
--- Comment #5 from Aldy Hernandez ---
Created attachment 51518
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51518=edit
patch to help diagnose issue with -ftime-report
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102477
--- Comment #3 from Zdenek Sojka ---
Created attachment 51517
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51517=edit
different testcase failing at -O without __builtin_shufflevector()
$ x86_64-pc-linux-gnu-gcc -O testcase.c
during
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102529
Bug ID: 102529
Summary: ctad for aliases fails in the presence of constraints
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102527
--- Comment #4 from Aldy Hernandez ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #3)
> > --- Comment #2 from Aldy Hernandez ---
> > (In reply to David Edelsohn from comment #1)
> >> Confirmed.
> >
> > I don't have access to an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102519
--- Comment #8 from Aldy Hernandez ---
(In reply to David Edelsohn from comment #7)
> Have you tried a native PPC64LE Linux build?
>
> AIX defaults to 32 bit, and it's big endian. I wouldn't expect that to
> affect the memory usage, but I'm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102528
Bug ID: 102528
Summary: Unable to inline even trivial coroutines
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102527
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #2 from Aldy Hernandez ---
> (In reply to David Edelsohn from comment #1)
>> Confirmed.
>
> I don't have access to an i386-solaris box.
... and there's none in the cfarm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95567
Patrick Palka changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102527
--- Comment #2 from Aldy Hernandez ---
(In reply to David Edelsohn from comment #1)
> Confirmed.
I don't have access to an i386-solaris box.
David, how were you able to reproduce?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102527
David Edelsohn changed:
What|Removed |Added
CC||dje at gcc dot gnu.org
Ever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102519
--- Comment #7 from David Edelsohn ---
Have you tried a native PPC64LE Linux build?
AIX defaults to 32 bit, and it's big endian. I wouldn't expect that to affect
the memory usage, but I'm mentioning it.
Did you try to compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102527
Rainer Orth changed:
What|Removed |Added
Target Milestone|--- |12.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102527
Bug ID: 102527
Summary: [12 regression] out of memory compiling insn-emit.c
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102516
--- Comment #3 from Christophe Lyon ---
The target name is armeb-linux-gnueabi or armeb-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102480
--- Comment #2 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:f38cd3bdb4cd429a5f7082ea91793a59b37d47b9
commit r12-3963-gf38cd3bdb4cd429a5f7082ea91793a59b37d47b9
Author: Jonathan Wakely
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84110
--- Comment #3 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:b701e1f8f6870c0f8cb4050674da489101dd05a5
commit r12-3961-gb701e1f8f6870c0f8cb4050674da489101dd05a5
Author: Jonathan Wakely
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102516
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|WAITING
--- Comment #2 from Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102517
Richard Biener changed:
What|Removed |Added
Assignee|rguenth at gcc dot gnu.org |rearnsha at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102517
--- Comment #3 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:b34fa88becb6367229074f25ef9e2de6f4594b58
commit r12-3959-gb34fa88becb6367229074f25ef9e2de6f4594b58
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102517
--- Comment #2 from Richard Biener ---
FAIL: gcc:gcc.dg/dg.exp=gcc.dg/pr78408-1.c scan-tree-dump-times fab1 "after
previous" 17
here we perform the desired optimization earlier in FRE. I'll adjust the
testcase to make 'S' size not power of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102482
--- Comment #7 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #6)
> The warning should not trigger if the constructor takes the initializer_list
> by non-const lvalue reference.
I think this change to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102482
--- Comment #6 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #5)
> True, but approximately nobody writes constructors taking a non-const lvalue
> reference to std::initializer_list, so this corner case doesn't seem very
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102482
Jonathan Wakely changed:
What|Removed |Added
CC||dmalcolm at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81402
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2021-09-29
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80756
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=15
Andrew Pinski changed:
What|Removed |Added
CC||yzhang1985 at gmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61417
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=15
Andrew Pinski changed:
What|Removed |Added
CC||cyb70289 at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102526
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102526
Bug ID: 102526
Summary: Failed to link simd code if -O0
Product: gcc
Version: 9.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102504
--- Comment #3 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:d3e7bb15e28c554bf4484a912f3b9c18c60ec68f
commit r12-3955-gd3e7bb15e28c554bf4484a912f3b9c18c60ec68f
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102519
--- Comment #6 from Aldy Hernandez ---
(In reply to Andrew Pinski from comment #5)
> (In reply to Aldy Hernandez from comment #4)
> > Is there any way of reproducing this on a cross? I've been waiting 15
> > minutes for a "git fetch" on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102519
--- Comment #5 from Andrew Pinski ---
(In reply to Aldy Hernandez from comment #4)
> Is there any way of reproducing this on a cross? I've been waiting 15
> minutes for a "git fetch" on gcc111.fsffrance.org or gcc119.fsffrance.org.
> I'll
1 - 100 of 105 matches
Mail list logo
