https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94947
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94947
Martin Liška changed:
What|Removed |Added
Known to work||5.4.0
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94937
--- Comment #14 from Martin Liška ---
Created attachment 48448
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48448&action=edit
Reduced test-case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94946
Martin Liška changed:
What|Removed |Added
Keywords|needs-reduction |rejects-valid
--- Comment #1 from Martin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=4210
--- Comment #33 from Vincent Lefèvre ---
(In reply to Niels Möller from comment #32)
> 4. I also wonder what happens if, for some reason, a constant invalid shift
> count is passed through all the way to code generation? Most architectures
> would
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93086
--- Comment #2 from Andrew Pinski ---
I have a patch, in some places I am able to remove some extra varibles, in
others I need to add one. There was an mix use of 0/1 and false/true even in
the same file for the argument of build_nonstandard_int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94937
--- Comment #13 from Christoph ---
I tried to help with reducing the test case, but could not achieve something
substantial.
Then I went back to our test cases and tried to pick the simples one I could
find. I removed as much code from main() as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94937
--- Comment #12 from Christoph ---
Created attachment 48447
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48447&action=edit
output for injection test case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94937
--- Comment #11 from Christoph ---
Created attachment 48446
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48446&action=edit
New, smaller test case (called injection)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94873
--- Comment #14 from Segher Boessenkool ---
So, hrm, we could in principle attach a REG_EQ* note to any single_set
instruction?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94038
Patrick Palka changed:
What|Removed |Added
Summary|Compiling with -Wall causes |[8/9/10 Regression]
|f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94938
Marek Polacek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94038
--- Comment #4 from CVS Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:a700b4a9f18fd6213de51f4259ee9a8ce7eefdbb
commit r11-56-ga700b4a9f18fd6213de51f4259ee9a8ce7eefdbb
Author: Patrick Palka
Date: Mon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94873
--- Comment #13 from Eric Botcazou ---
Since Richard kindly invited me to the party, I feel entitled to voice my
personal opinion :-) which is apparently aligned with Richard's. I think that
we should allow REG_EQUAL notes for insns with exactly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94947
Bug ID: 94947
Summary: -fipa-pta + pthread_once crash
Product: gcc
Version: 9.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ipa
Assi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94918
--- Comment #7 from Eric Botcazou ---
The Ada bits have been installed, but approval from a global maintainer is
needed for the libgcc bits.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94906
--- Comment #2 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:bb27781b64162e1769df15e0c97e8d2145d2d10d
commit r11-53-gbb27781b64162e1769df15e0c97e8d2145d2d10d
Author: Jonathan Wakely
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94918
--- Comment #6 from CVS Commits ---
The releases/gcc-8 branch has been updated by Eric Botcazou
:
https://gcc.gnu.org/g:4b0a1274faa64cbbe3c3b5db1129b3d2b3b530bb
commit r8-10236-g4b0a1274faa64cbbe3c3b5db1129b3d2b3b530bb
Author: Eric Botcazou
Da
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94918
--- Comment #5 from CVS Commits ---
The releases/gcc-9 branch has been updated by Eric Botcazou
:
https://gcc.gnu.org/g:a34b818215174f6cbe46e2e2bfae874fde7aec72
commit r9-8566-ga34b818215174f6cbe46e2e2bfae874fde7aec72
Author: Eric Botcazou
Dat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94918
--- Comment #3 from CVS Commits ---
The master branch has been updated by Eric Botcazou :
https://gcc.gnu.org/g:cc7e4de998cd2a31eb7c834fd427e7f16a99d60a
commit r11-52-gcc7e4de998cd2a31eb7c834fd427e7f16a99d60a
Author: Eric Botcazou
Date: Mon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94918
--- Comment #4 from CVS Commits ---
The releases/gcc-10 branch has been updated by Eric Botcazou
:
https://gcc.gnu.org/g:1c615f4a935b805e3c030d8261452a17efb138ac
commit r10-8091-g1c615f4a935b805e3c030d8261452a17efb138ac
Author: Eric Botcazou
D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94918
Eric Botcazou changed:
What|Removed |Added
Last reconfirmed||2020-05-04
Summary|Ada bootst
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94873
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=4210
--- Comment #32 from Niels Möller ---
I've checked out the gcc sources, to see if I can understand how to move the
warning around. The example input I'm looking at now is
unsigned
shift_dead (unsigned x)
{
if (0)
return x >> 32;
else
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94941
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status|A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94941
--- Comment #3 from CVS Commits ---
The releases/gcc-10 branch has been updated by Richard Sandiford
:
https://gcc.gnu.org/g:688c8da3eb4cc7482f9844e0e87c11f5003bfbef
commit r10-8090-g688c8da3eb4cc7482f9844e0e87c11f5003bfbef
Author: Richard Sand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94941
--- Comment #2 from CVS Commits ---
The master branch has been updated by Richard Sandiford :
https://gcc.gnu.org/g:3af3bec2e4d344bd54a134d8b2263f44d788c3d8
commit r11-50-g3af3bec2e4d344bd54a134d8b2263f44d788c3d8
Author: Richard Sandiford
Date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93366
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot
gnu.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94873
--- Comment #11 from rsandifo at gcc dot gnu.org
---
(In reply to Segher Boessenkool from comment #9)
> "clobber" is a red herring; it is impossible to make a REG_EQ* note for
> a clobber, a clobber does not set a new value (that is the whole po
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94937
Marek Polacek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94873
--- Comment #10 from Segher Boessenkool ---
Oh, and ideally, we would replace the whole REG_EQ* stuff with a more
powerful interface that is to-the-side, not embedded in the instruction
stream. For known exact values, nonzero_bits, known ranges,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94946
Martin Liška changed:
What|Removed |Added
Known to work||9.3.0
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94946
Bug ID: 94946
Summary: [10/11 Regression] error: ‘template
JSC::FunctionPtr::FunctionPtr(returnType (*)())’
cannot be overloaded since r10-7998-g5f1cd1da1a805c3d
Product: gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94743
--- Comment #14 from Richard Earnshaw ---
(In reply to Christophe Lyon from comment #13)
> But, in general (non-interrupt) code, what is supposed to happen if you
> compile for a d32 VFP and run on d16 one ? (and the code uses the extra
> regist
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94873
--- Comment #9 from Segher Boessenkool ---
"clobber" is a red herring; it is impossible to make a REG_EQ* note for
a clobber, a clobber does not set a new value (that is the whole point
of a clobber).
I think we could allow auto-modify, sure, ju
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94937
Martin Liška changed:
What|Removed |Added
Summary|ICE with if constexpr (in |[10/11 Regression] ICE with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94937
--- Comment #9 from Martin Liška ---
Created attachment 48444
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48444&action=edit
Semi-reduced test-case
I'll carry on with the reduction, but it goes down slowly.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94743
--- Comment #13 from Christophe Lyon ---
> > Why do we need a library function for that? It would have to be special with
> > the stack: push FP registers, but do not restore SP, so that the dual
> > restore function can pop them and restore SP.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94940
--- Comment #5 from Martin Liška ---
Thank you for the analysis, I'm gonna report that to qemu guys.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94849
Martin Liška changed:
What|Removed |Added
Resolution|--- |MOVED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94929
--- Comment #6 from Marek Polacek ---
(In reply to David Seifert from comment #5)
> (In reply to Marek Polacek from comment #3)
> > I'm going to backport the fix to 8 if it passes the usual testing.
>
> Hi Marek,
> could you also test the inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94800
Jakub Jelinek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94929
--- Comment #5 from David Seifert ---
(In reply to Marek Polacek from comment #3)
> I'm going to backport the fix to 8 if it passes the usual testing.
Hi Marek,
could you also test the inlined code. Defining some const and then using it
alignas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94929
Marek Polacek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90736
--- Comment #10 from CVS Commits ---
The releases/gcc-8 branch has been updated by Marek Polacek
:
https://gcc.gnu.org/g:f6965321b1c00bfb2b9c8407df56bcf38f096088
commit r8-10235-gf6965321b1c00bfb2b9c8407df56bcf38f096088
Author: Marek Polacek
D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94747
Nathan Sidwell changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94938
--- Comment #2 from Marek Polacek ---
value_dependent_expression_p (called via the new uses_template_parms call)
doesn't expect a non-constant expression. So one possible fix would be:
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -10624,7 +10624,8 @@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94827
Nathan Sidwell changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94795
Uroš Bizjak changed:
What|Removed |Added
Resolution|--- |FIXED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94795
--- Comment #5 from CVS Commits ---
The master branch has been updated by Uros Bizjak :
https://gcc.gnu.org/g:9decd08b7b153a593a0b61e4f5373cb9574a1973
commit r11-45-g9decd08b7b153a593a0b61e4f5373cb9574a1973
Author: Uros Bizjak
Date: Mon May
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94945
Bug ID: 94945
Summary: Missed optimization: Carry chain not recognized in
manually unrolled loop
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94931
--- Comment #7 from Steve Kargl ---
On Mon, May 04, 2020 at 08:23:17AM +, ryofurue at gmail dot com wrote:
>
> But, then the question is, why don't you need the -L option? as in
>
> gfortran -I/usr/include mysourcefile.f -L/usr/lib -lne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94743
--- Comment #12 from Richard Earnshaw ---
(In reply to Christophe Lyon from comment #11)
> (In reply to Richard Earnshaw from comment #10)
> > (In reply to Christophe Lyon from comment #9)
> > > > My initial thoughts are along the lines of...
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94743
--- Comment #11 from Christophe Lyon ---
(In reply to Richard Earnshaw from comment #10)
> (In reply to Christophe Lyon from comment #9)
> > > My initial thoughts are along the lines of...
> > > Only try to save FP registers that this function di
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92177
Richard Biener changed:
What|Removed |Added
Status|REOPENED|ASSIGNED
--- Comment #7 from Richard Bi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94800
Jakub Jelinek changed:
What|Removed |Added
Last reconfirmed||2020-05-04
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94944
Marek Polacek changed:
What|Removed |Added
Last reconfirmed||2020-05-04
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94940
Martin Sebor changed:
What|Removed |Added
Blocks||56456
Summary|[10/11 Regressio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94944
--- Comment #1 from eracpp ---
The example may be simplified further by removing the function parameters:
template
struct B {
void foo() {}
};
template
struct D : B {
void foo() noexcept(noexcept(B::foo())) {}
};
template struct D;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94944
Bug ID: 94944
Summary: compile error accessing member function of dependent
base class template in exception specification
Product: gcc
Version: unknown
Status: UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88759
Patrick Palka changed:
What|Removed |Added
Resolution|--- |FIXED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54366
Bug 54366 depends on bug 88759, which changed state.
Bug 88759 Summary: `decltype(auto)` as return type of abbreviated function
template strips cv-qualifications and referenceness
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88759
Wha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94864
--- Comment #3 from Segher Boessenkool ---
vec_duplicate of vec_select is just a vec_select. Any vec_merge is a
vec_select as well, as you say.
Canonicalisation should make vec_select always.
We probably should have canonicalisation rules for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94929
Marek Polacek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93674
Richard Earnshaw changed:
What|Removed |Added
Resolution|--- |FIXED
Status|REOPENED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94743
--- Comment #10 from Richard Earnshaw ---
(In reply to Christophe Lyon from comment #9)
> > My initial thoughts are along the lines of...
> > Only try to save FP registers that this function directly clobbers.
> What's the point of saving these i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94896
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94775
--- Comment #13 from CVS Commits ---
The releases/gcc-10 branch has been updated by Marek Polacek
:
https://gcc.gnu.org/g:251c85372e088017e79894f50156901d112affee
commit r10-8088-g251c85372e088017e79894f50156901d112affee
Author: Marek Polacek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94775
Marek Polacek changed:
What|Removed |Added
Summary|[8/9 Regression] ICE in |[8/9/10/11 Regression] ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94745
--- Comment #4 from Louis Dionne ---
Thanks for your replies, all. We resolved the problem on our side by not trying
to workaround the lack of error, which means that we might end up passing
`-Wno-foo` to GCC when it's not supported. I think that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94775
--- Comment #12 from CVS Commits ---
The master branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:05be85b649173b10d0bf10255eb15275c2dcf509
commit r11-42-g05be85b649173b10d0bf10255eb15275c2dcf509
Author: Marek Polacek
Date: Mon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94896
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92177
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
Summ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94896
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94925
--- Comment #2 from Fred Krogh ---
I'm unclear on comment 1. Are you saying the code is such that this diagnostic
can not be turned off and that is the way it should be, or that there is an a
problem in gfortran with the if that is guarding the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94907
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93891
--- Comment #6 from Richard Biener ---
Not yet fixed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93891
--- Comment #5 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:367766f40a031ff064857681dc4da3309f0ce57d
commit r11-41-g367766f40a031ff064857681dc4da3309f0ce57d
Author: Richard Biener
Date: Tu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94936
--- Comment #1 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:ec40967f1323069da3a5a45286f71fa4f80926df
commit r11-40-gec40967f1323069da3a5a45286f71fa4f80926df
Author: Jonathan Wakely
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94909
--- Comment #3 from Neil Carlson ---
Richard, this is just a typical declaration of an abstract type. An extension
of this type will have to define the deferred dot_ function with an interface
that happens to match the interface of dot. The dot f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94914
--- Comment #5 from Jakub Jelinek ---
(In reply to Marc Glisse from comment #4)
> I thought we might already simplify (u >> 32) != 0 to u >= cst (other
> possible forms are u != (uint64_t)(uint32_t)u, u & cst != 0, etc, I am
> trying to think whi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39612
Richard Biener changed:
What|Removed |Added
Known to work||11.0
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39612
--- Comment #39 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:f9e1ea10e657af9fb02fafecf1a600740fd34409
commit r11-39-gf9e1ea10e657af9fb02fafecf1a600740fd34409
Author: Richard Biener
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93581
Tobias Burnus changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93581
--- Comment #10 from CVS Commits ---
The releases/gcc-9 branch has been updated by Tobias Burnus
:
https://gcc.gnu.org/g:da710a35525cc7631b778fa4a5cfd20c366c01a4
commit r9-8565-gda710a35525cc7631b778fa4a5cfd20c366c01a4
Author: Tobias Burnus
Da
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93385
--- Comment #33 from CVS Commits ---
The master branch has been updated by Martin Jambor :
https://gcc.gnu.org/g:375a77925c320a273d3b1ef3182f29f31aaa8edf
commit r11-38-g375a77925c320a273d3b1ef3182f29f31aaa8edf
Author: Martin Jambor
Date: Mon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94942
--- Comment #2 from Jakub Jelinek ---
Created attachment 48441
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48441&action=edit
gcc11-pr94942.patch
Untested fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94650
Uroš Bizjak changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78155
Bruno Haible changed:
What|Removed |Added
CC||bruno at clisp dot org
--- Comment #6 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94650
--- Comment #3 from CVS Commits ---
The master branch has been updated by Uros Bizjak :
https://gcc.gnu.org/g:8ea03e9016cbca5a7ee2b4befa4d5c32467b0982
commit r11-37-g8ea03e9016cbca5a7ee2b4befa4d5c32467b0982
Author: Uros Bizjak
Date: Mon May
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94943
Richard Biener changed:
What|Removed |Added
Keywords||rejects-valid
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94743
--- Comment #9 from Christophe Lyon ---
> My initial thoughts are along the lines of...
> Only try to save FP registers that this function directly clobbers.
What's the point of saving these if a callee clobbers other registers?
Shouldn't that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94914
--- Comment #4 from Marc Glisse ---
I thought we might already simplify (u >> 32) != 0 to u >= cst (other possible
forms are u != (uint64_t)(uint32_t)u, u & cst != 0, etc, I am trying to think
which one looks most canonical).
I expect in interes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94942
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94914
--- Comment #3 from Jakub Jelinek ---
Created attachment 48439
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48439&action=edit
gcc11-pr94914.patch
Untested fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94943
Bug ID: 94943
Summary: A module does not export allocatable attribute of
herein arrays.
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
--target=x86_64-pc-linux-gnu
--with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r11-36-20200504110332-g6b5c7ee0df6-checking-yes-rtl-df-extra-amd64
Thread model: posix
Supported LTO compression algorithms
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94903
--- Comment #3 from Richard Biener ---
Feel free to backport, it certainly doesn't have high priority.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94914
Jakub Jelinek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94109
--- Comment #3 from Antony Lewis ---
Although my reduced test in the other id case is one problem, it appears that
is not the only memory leak. Someone tested else on various gcc versions and
still found:
versionmemory leak
7.3.0
1 - 100 of 133 matches
Mail list logo
