https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92657
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
Status|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92663
--- Comment #6 from fiesh at zefix dot tv ---
My suggestion would be to uniformly include the information about whether a bug
has been closed, irrespective of its nature. So yes, un-optimal code
generation might also be listed, and I think the us
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61414
Eric Gallager changed:
What|Removed |Added
URL||https://gcc.gnu.org/ml/gcc-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46558
Eric Gallager changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92667
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70477
--- Comment #9 from Eric Gallager ---
*** Bug 92668 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92668
Eric Gallager changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92649
--- Comment #5 from Jiangning Liu ---
Unrolling 1024 iterations would increase code size a lot, so usually we don't
do that. 1024 is only an example. Without knowing we could eliminate most of
them, we don't really want to do loop unrolling, I gu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92651
--- Comment #5 from Hongyu Wang ---
(In reply to Jakub Jelinek from comment #3)
> Do you mean r274481 rather than r277481, right?
Yes. Thanks for your correction.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92651
--- Comment #4 from Hongyu Wang ---
(In reply to Richard Biener from comment #2)
> Btw, which variant is actually the fastest for you? abs expansion doesn't
> do any cost comparison but just uses direct abs, max and then the xor with
> shift as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92668
--- Comment #3 from joseph at codesourcery dot com ---
Isn't this the same as bug 70477?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92668
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92668
Martin Sebor changed:
What|Removed |Added
Keywords||diagnostic
Summary|-Wtautologi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92569
Thomas Koenig changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92569
--- Comment #12 from Thomas Koenig ---
Author: tkoenig
Date: Mon Nov 25 22:26:26 2019
New Revision: 278710
URL: https://gcc.gnu.org/viewcvs?rev=278710&root=gcc&view=rev
Log:
Fix EOF handling for arrays.
2019-11-25 Thomas Koenig
Harald An
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92668
Bug ID: 92668
Summary: -Wtautological-compare warns for macros that expand to
the same symbol
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92629
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=92667
Bug ID: 92667
Summary: spurious missing sentinel in function call with a
local sentinel variable
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92666
--- Comment #2 from Martin Sebor ---
The check_function_restrict() function is called to do the -Wrestrict checking.
It's called conditionally, from check_function_arguments(), when warn_restrict
is nonzero. When called, the function calls fold
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92663
--- Comment #5 from Jonathan Wakely ---
True, but I still think the list needs to be compiled in to the binaries
statically. If that gave incorrect results in some cases (because a bug was
thought to be fixed when the static list was generated, b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92442
--- Comment #8 from Jason Merrill ---
(In reply to Richard Biener from comment #5)
> There are also quite many _name_ duplicates refering to different DIEs! Like
> 178 copies of 'std::is_same_v' and others:
std::*_v are variable templates, so t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92656
--- Comment #1 from Andrew Pinski ---
Hmm, this comes from coremarks (what a bad benchmark).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92656
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization
Severity|n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92666
Martin Sebor changed:
What|Removed |Added
Summary|bogus |[10 Regression] bogus
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92666
Martin Sebor changed:
What|Removed |Added
Keywords||diagnostic
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92666
Bug ID: 92666
Summary: bogus -Wunused-but-set-variable in gcov.c with
-Wno-restrict
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92663
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92663
--- Comment #3 from Jonathan Wakely ---
(In reply to Eric Gallager from comment #2)
> This sounds like it could be dangerous from a security context... currently
> no network connection is needed to use gcc, it would be a major
> disappointment i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92533
--- Comment #5 from Tobias Burnus ---
(In reply to Tobias Burnus from comment #4)
> Probably somewhere in module.c's gfc_use_module.
That's actually to early. gfc_use_module is run after all use statements have
been processed while the public/pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89549
--- Comment #17 from Dávid Bolvanský ---
Check few lines above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89549#c8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92569
--- Comment #11 from Thomas Koenig ---
Author: tkoenig
Date: Mon Nov 25 20:04:28 2019
New Revision: 278702
URL: https://gcc.gnu.org/viewcvs?rev=278702&root=gcc&view=rev
Log:
Fix EOF handling for arrays.
2019-11-25 Thomas Koenig
Haral
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92665
--- Comment #4 from Andrew Pinski ---
(In reply to Wilco from comment #3)
> I think it's because many intrinsics in arm_neon.h still use asm which
> inhibits most optimizations.
NO in this case it is not.
Take:
#include "arm_neon.h"
float64x1_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89549
--- Comment #16 from Jakub Jelinek ---
Of course there is, -Wno-misleading-indentation or use line breaks from time to
time. With >= 4KB long lines, the user clearly doesn't care about indentation,
so the warning doesn't make sense.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85678
Eric Gallager changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85678
--- Comment #13 from Florian Weimer ---
(In reply to Wilco from comment #12)
> Giving errors on old-style code by default sounds like a good idea. We could
> add -std=legacy similar to Fortran to support building old K&R code (and
> that would en
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92629
--- Comment #3 from anlauf at gcc dot gnu.org ---
Author: anlauf
Date: Mon Nov 25 19:50:38 2019
New Revision: 278699
URL: https://gcc.gnu.org/viewcvs?rev=278699&root=gcc&view=rev
Log:
2019-11-25 Harald Anlauf
PR fortran/92629
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92663
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92665
Wilco changed:
What|Removed |Added
CC||wilco at gcc dot gnu.org
--- Comment #3 from Wil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92661
--- Comment #5 from Peter Bergner ---
(In reply to jos...@codesourcery.com from comment #4)
> My suggestion for the target-specific built-in functions would be:
>
> * builtin_function_type in rs6000-call.c should detect the case of a
> DECIMAL_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92665
--- Comment #2 from Andrew Pinski ---
Created attachment 47356
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47356&action=edit
Patch which I wrote for GCC 7.3
I have to double check if it applies directly as I had other patches in this
ar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85678
--- Comment #12 from Wilco ---
(In reply to David Brown from comment #11)
> Changing the default to "-fno-common" (and ideally
> "-Werror=strict-prototypes -Werror=old-style-declaration
> -Werror=missing-parameter-type") would have a lot smaller
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92538
Erick Ochoa changed:
What|Removed |Added
CC||erick.ochoa@theobroma-syste
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89549
--- Comment #15 from Dávid Bolvanský ---
But there is no way to silence this "note".
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92665
Andrew Pinski changed:
What|Removed |Added
Target||aarch64-linux-gnu
Status|UNC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91786
--- Comment #1 from Jonathan Wakely ---
Author: redi
Date: Mon Nov 25 19:01:58 2019
New Revision: 278697
URL: https://gcc.gnu.org/viewcvs?rev=278697&root=gcc&view=rev
Log:
PR libstdc++/91786 fix compilation error with Clang
PR libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92665
Bug ID: 92665
Summary: [AArch64] low lanes select not optimized out for vmlal
intrinsics
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89549
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92663
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
--- Comment #1 from Andrew P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92646
--- Comment #5 from Andrew Pinski ---
Looks like multi-arch is not being auto-detected correctly.
Try adding --enable-multiarch .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90264
Jakub Jelinek changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86172
Bug 86172 depends on bug 90264, which changed state.
Bug 90264 Summary: [9/10 Regression] -Wnull-dereference QoI issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90264
What|Removed |Added
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85678
--- Comment #11 from David Brown ---
Reliance on -fcommon has not been correct or compatible with any C standard (I
don't think it was even right for K&R C). If the code is written correctly
(with at most one definition of all externally linked
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92533
--- Comment #4 from Tobias Burnus ---
Created attachment 47354
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47354&action=edit
Parsing-only patch – TODO: resolve PUBLIC/PRIVATE + handle example of comment 1
First patch. Need to resolve us
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92651
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92586
epagone changed:
What|Removed |Added
Blocks||19276
--- Comment #3 from epagone ---
Convert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92648
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85678
--- Comment #10 from David Binderman ---
(In reply to Jonathan Wakely from comment #9)
> C89 6.7p4 looks equivalent to C99 6.9p5, so I don't see why -std=c89 should
> imply -fcommon.
To reduce costs in upgrading to post-revision 278509 compilers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92661
--- Comment #4 from joseph at codesourcery dot com ---
The design in the target-independent compiler is that the functions that
get called when processing builtins.def notice that the type involved is
error_mark_node (which in turn gets set whe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85678
--- Comment #9 from Jonathan Wakely ---
C89 6.7p4 looks equivalent to C99 6.9p5, so I don't see why -std=c89 should
imply -fcommon. It's just as bad in C89 as in later standards.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92641
--- Comment #3 from joseph at codesourcery dot com ---
The C front end explicitly tracks VLA size expressions in type names in
casts and ensures they are evaluated at an appropriate point using a
C_MAYBE_CONST_EXPR (which later turns into a COM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85678
--- Comment #8 from Wilco ---
(In reply to David Binderman from comment #7)
> (In reply to David Brown from comment #0)
> > Surely it is time to make "-fno-common" the default, at least when a modern
> > C standard is specified indicating that th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85678
David Binderman changed:
What|Removed |Added
CC||dcb314 at hotmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92664
Bug ID: 92664
Summary: Wrong .debug_line section information when compiling
stdin input with -g3
Product: gcc
Version: 7.2.1
Status: UNCONFIRMED
Severity: norma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92661
--- Comment #3 from David Edelsohn ---
An alternate work-around is
Index: tree.c
===
--- tree.c (revision 278691)
+++ tree.c (working copy)
@@ -10334,7 +10334,7 @@
uint
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90835
--- Comment #22 from Iain Sandoe ---
(In reply to Jürgen Reuter from comment #21)
> (In reply to Iain Sandoe from comment #20)
> > As of XCode 11.3beta, the contained SDK works OK:
> >
> > https://gcc.gnu.org/ml/gcc-testresults/2019-11/msg01439.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92661
--- Comment #2 from David Edelsohn ---
A crude work-around to allow GCC to bootstrap and show the extent of the
problem, I need the following patches to comment out all decimal builtins.
Index: rs6000-call.c
=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61414
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90835
--- Comment #21 from Jürgen Reuter ---
(In reply to Iain Sandoe from comment #20)
> As of XCode 11.3beta, the contained SDK works OK:
>
> https://gcc.gnu.org/ml/gcc-testresults/2019-11/msg01439.html
>
> We still have the underlying problems - w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92663
Bug ID: 92663
Summary: Add __gcc_has_bug or __gcc_bug_fixed
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92662
--- Comment #2 from Jonathan Wakely ---
I'm pretty sure GCC 9 is correct. It started to be rejected with r269602:
PR c++/86521 - wrong overload resolution with ref-qualifiers.
Here we were wrongly treating binding a const lvalue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92662
--- Comment #1 from Michael Matz ---
I _think_ a reduced program would be this:
-
template struct remove_ref { typedef _Tp type; };
template struct remove_ref<_Tp&> { typedef _Tp type; };
template struct r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92662
Bug ID: 92662
Summary: change in gcc 8 vs 9: call of overloaded
‘basic_string()’ is
ambiguous
Product: gcc
Version: 9.2.1
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69089
Tom de Geus changed:
What|Removed |Added
CC||tom at geus dot me
--- Comment #7 from Tom
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92661
David Edelsohn changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92661
Bug ID: 92661
Summary: [10 Regression] AIX bootstrap failure with
builtin-types.def change
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: blocker
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92645
--- Comment #9 from Richard Biener ---
Thanks a lot. So besides the following mismatch for SLP
_24 = MEM[base: src_22(D), index: ivtmp.20_267, offset: 0B];
_97 = (unsigned char) _24;
_98 = (short unsigned int) _97;
_99 = BIT_FIELD_REF <
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92050
--- Comment #7 from Tobias Burnus ---
Author: burnus
Date: Mon Nov 25 14:33:32 2019
New Revision: 278689
URL: https://gcc.gnu.org/viewcvs?rev=278689&root=gcc&view=rev
Log:
Fortran] PR 92050 - fix ICE with -fcheck=all
Backport from mainl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92657
--- Comment #3 from Adhemerval Zanella
---
(In reply to Adhemerval Zanella from comment #2)
> (In reply to Andrew Pinski from comment #1)
> > Again, this is not due to tree-ch at all. This is due to the code motion
> > passes move invariant loa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92657
--- Comment #2 from Adhemerval Zanella
---
(In reply to Andrew Pinski from comment #1)
> Again, this is not due to tree-ch at all. This is due to the code motion
> passes move invariant load/stores out of the loop. Tree-ch pass just allows
> t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92657
--- Comment #1 from Andrew Pinski ---
Again, this is not due to tree-ch at all. This is due to the code motion
passes move invariant load/stores out of the loop. Tree-ch pass just allows
those passes to work.
All three (gcse, tree pre and tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92658
--- Comment #1 from Richard Biener ---
It looks like there are already some avx512 patterns matching this but they
are not visible to the RTL expanders.
(define_insn "zero_extendv8qiv8hi2"
[(set (match_operand:V8HI 0 "register_operand" "=x,v")
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92642
--- Comment #3 from Jonathan Wakely ---
No, not necessarily.
extern const int n; // defined in another file
auto i = 1 << n;
void f(const int n)
{
auto i = 1 << n;
}
Not all const variables are compile-time constants.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92659
Jonathan Wakely changed:
What|Removed |Added
Keywords||diagnostic
Severity|normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92660
Bug ID: 92660
Summary: overflow warning message enhancement
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92659
Bug ID: 92659
Summary: Suggestions for bitshift
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92653
--- Comment #1 from Martin Liška ---
Author: marxin
Date: Mon Nov 25 13:57:00 2019
New Revision: 278686
URL: https://gcc.gnu.org/viewcvs?rev=278686&root=gcc&view=rev
Log:
Comment too strict checking assert.
2019-11-25 Martin Liska
P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92642
--- Comment #2 from Jonny Grant ---
(In reply to Jonathan Wakely from comment #1)
> (A) seems pointless in this case, it's right there in the caret diagnostic.
>
> The type size_t is irrelevant.
>
> IMO a better testcase would be:
>
> const in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92645
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91985
Joseph S. Myers changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91985
--- Comment #2 from Joseph S. Myers ---
Author: jsm28
Date: Mon Nov 25 13:45:42 2019
New Revision: 278684
URL: https://gcc.gnu.org/viewcvs?rev=278684&root=gcc&view=rev
Log:
Prevent all uses of DFP when unsupported (PR c/91985).
Code that direct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92658
Bug ID: 92658
Summary: x86 lacks vector extend / truncate
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92654
--- Comment #5 from fiesh at zefix dot tv ---
Thank you for your offer. The original translation unit is a whopping 20MB and
took about 3 days to reduce ;-)
I changed the file and the interestingness test to make sure clang compiles it.
It's ru
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90835
--- Comment #20 from Iain Sandoe ---
As of XCode 11.3beta, the contained SDK works OK:
https://gcc.gnu.org/ml/gcc-testresults/2019-11/msg01439.html
We still have the underlying problems - which need to be addressed (so please
don't close this P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92445
Eric Gallager changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90835
Eric Gallager changed:
What|Removed |Added
CC||juergen.reuter at desy dot de
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92123
--- Comment #15 from Jakub Jelinek ---
I think other fn spec attributes in trans-decl.c should be checked.
E.g. for internal_pack, I see ".r", when the function sometimes returns a
pointer to a field pointed by the first argument. The address of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92657
Bug ID: 92657
Summary: High stack usage due ftree-ch
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60228
steffen.seckler at tum dot de changed:
What|Removed |Added
CC||steffen.seckler at tum dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92649
--- Comment #4 from Richard Biener ---
(In reply to Jiangning Liu from comment #3)
> It is a stupid test, but it is simplified from a real application.
>
> To solve even more complicated scenario, this simple case needs to be
> addressed first.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48188
--- Comment #4 from Zdenek Sojka ---
Doesn't seem to crash since at least gcc-7
1 - 100 of 157 matches
Mail list logo
