https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84842
--- Comment #14 from Alexander Monakov ---
Thanks. I think the root cause on this x86_64 testcase is different.
Arseny, in the meantime if by chance you have another x86_64 variant of this
failure that doesn't require -funroll-all-loops, please
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85275
--- Comment #3 from Richard Biener ---
Author: rguenth
Date: Mon Apr 30 07:23:36 2018
New Revision: 259754
URL: https://gcc.gnu.org/viewcvs?rev=259754&root=gcc&view=rev
Log:
2018-04-30 Richard Biener
PR tree-optimization/28364
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28364
--- Comment #33 from Richard Biener ---
Author: rguenth
Date: Mon Apr 30 07:23:36 2018
New Revision: 259754
URL: https://gcc.gnu.org/viewcvs?rev=259754&root=gcc&view=rev
Log:
2018-04-30 Richard Biener
PR tree-optimization/28364
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85275
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28364
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85556
Richard Biener changed:
What|Removed |Added
Keywords||documentation,
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85557
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85558
Richard Biener changed:
What|Removed |Added
Keywords||ice-on-invalid-code
Status|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85560
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
Status|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85563
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
Component|c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85567
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85571
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85571
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |9.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85571
--- Comment #2 from Richard Biener ---
Author: rguenth
Date: Mon Apr 30 08:18:03 2018
New Revision: 259755
URL: https://gcc.gnu.org/viewcvs?rev=259755&root=gcc&view=rev
Log:
2018-04-30 Richard Biener
PR bootstrap/85571
* Make
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85180
--- Comment #16 from romain.naour at smile dot fr ---
Hi,
gcc 7.3.0 is affected by this bug but only on microblaze architecture, see [1].
Do you plan to backport this patch on gcc 7.x?
It is safe to do so without take the risk to break something
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85429
--- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #7 from Ian Lance Taylor ---
> Do you think you could work out a patch that handles the various different
> cases?
Sure, if I can figure out how to determine whether or no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85557
--- Comment #2 from Evgeniy Shcherbina ---
There is 2 parameter calculations: "first" and "second", no matter what is
evaluated first or second, the "first" parameter should be initialized with `i
= 1`, and "second" with `i = 2`. So "first" shoul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85180
--- Comment #17 from Richard Biener ---
(In reply to romain.naour from comment #16)
> Hi,
>
> gcc 7.3.0 is affected by this bug but only on microblaze architecture, see
> [1].
> Do you plan to backport this patch on gcc 7.x?
> It is safe to do s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
--- Comment #42 from Andrew Haley ---
On 04/29/2018 05:42 PM, rguenther at suse dot de wrote:>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
>
> --- Comment #41 from rguenther at suse dot de ---
> On April 29, 2018 1:51:58 PM GMT+02:00, "a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
--- Comment #43 from Richard Biener ---
(In reply to Andrew Haley from comment #42)
> On 04/29/2018 05:42 PM, rguenther at suse dot de wrote:>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
> >
> > --- Comment #41 from rguenther at suse do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85572
Bug ID: 85572
Summary: faster code for absolute value of __v2di
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85571
--- Comment #3 from Richard Biener ---
Not yet fixed. As we compare LTO bytecode but that includes the .opts section
we now have -f[no-]checking there... We can't remove it there since we of
course want to have different settings at link-time.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85571
--- Comment #4 from Richard Biener ---
contrib/compare-debug strips off LTO sections but that would leave us with a
no-op compare. On any target using non-native sections just stripping
.gnu.lto_.opts
will be difficult in such script, so we'd ne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
--- Comment #44 from Davin McCall ---
> Well, perhaps not, but this is the language specification.
The "one special guarantee" clause appears in the section describing union
member access via the "." or "->" operators, implying that it only appl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85571
--- Comment #5 from Richard Biener ---
The following should work:
Index: config/bootstrap-lto.mk
===
--- config/bootstrap-lto.mk (revision 259755)
+++ config/bootstrap-lto.mk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85571
--- Comment #6 from Richard Biener ---
Or more sophisticated allow to override/amend what we compare in the .mk
snippets
and compare $(exeext) instead of ($objext) for bootstrap-lto.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85571
--- Comment #7 from Richard Biener ---
Created attachment 44041
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44041&action=edit
patch
Like this. Will fail as well because cc1 will differ (does not differ without
LTO).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85572
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85571
--- Comment #8 from Richard Biener ---
So even w/o the -f[no-]checking flags I see then when comparing stage2 and
stage3 cc1:
> readelf -S /abuild/rguenther/obj/prev-gcc/cc1 | grep -C 1 .text
0008 0008 AX 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85571
--- Comment #9 from Jan Hubicka ---
>
> so different BB re-ordering / partitioning?
That would be probably best visible from bb-reorder dumps. However...
>
> For example in the case of gengtype from stage2/stage3 .text has the same size
> but
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85573
Bug ID: 85573
Summary: gcc 7.3.0 cannot compile recent LLVM for AMD GPU
shaders
Product: gcc
Version: 7.3.0
Status: UNCONFIRMED
Severity: normal
Prior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85573
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85571
--- Comment #10 from Richard Biener ---
On the gcc-8 branch cc1 and friends compare OK so this is a recent regression.
Will try with checking enabled to be extra sure. Then there are only few
changes on trunk that are suspicious.
+/* Compare t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85573
Manuel Lauss changed:
What|Removed |Added
CC||manuel.lauss at googlemail dot
com
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85573
--- Comment #3 from Sylvain Bertrand ---
On Mon, Apr 30, 2018 at 12:43:04PM +, manuel.lauss at googlemail dot com
wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85573
>
> Manuel Lauss changed:
>
>What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85573
--- Comment #4 from Jonathan Wakely ---
7.3.1 will never be released, it's a post-7.3.0 and pre-7.4.0 development
snapshot.
If you are getting segfaults from snapshots now and you don't report them then
the final release is likely to have the sa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85574
Bug ID: 85574
Summary: [9 Regression] LTO bootstapped binaries differ
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: needs-bisection
Severity: normal
P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85574
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |9.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85557
Jonathan Wakely changed:
What|Removed |Added
Keywords||wrong-code
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77840
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63707
Jonathan Wakely changed:
What|Removed |Added
CC||mosra at centrum dot cz
--- Comment #9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70395
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63707
--- Comment #10 from Jonathan Wakely ---
Testcase from PR 70395
struct NonCopyable {
NonCopyable(const NonCopyable&) = delete;
NonCopyable(NonCopyable&&) = delete;
NonCopyable& operator=(const NonCopyable&) = delete;
NonCopyable& operato
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54835
--- Comment #17 from Jonathan Wakely ---
Jason, should this be FIXED instead of SUSPENDED?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85575
Bug ID: 85575
Summary: Acceptance of invalid code: ordering of declaration
statements with implicit typing
Product: gcc
Version: 8.0.1
Status: UNCONFIRMED
Sever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85576
Bug ID: 85576
Summary: A template union containing a friend function causes
non-template type used as a template error
Product: gcc
Version: 9.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85576
Jonathan Wakely changed:
What|Removed |Added
Keywords||rejects-valid
Status|UNCON
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85577
Bug ID: 85577
Summary: list-initialization chooses initializer-list
constructor
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Keywords: rejects-valid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85577
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85574
Jan Hubicka changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84829
--- Comment #14 from joseph at codesourcery dot com ---
As I said in comment#10, I think the solution is to remove the specs
making -mieee-fp imply -lieee. (Principally the spec in gnu-user.h. I
don't think this should depend on what libc is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81405
--- Comment #5 from David Malcolm ---
Author: dmalcolm
Date: Mon Apr 30 15:01:56 2018
New Revision: 259768
URL: https://gcc.gnu.org/viewcvs?rev=259768&root=gcc&view=rev
Log:
Use char_span for return type of location_get_source_line
location_get
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61982
--- Comment #18 from Jason Merrill ---
Author: jason
Date: Mon Apr 30 15:21:01 2018
New Revision: 259772
URL: https://gcc.gnu.org/viewcvs?rev=259772&root=gcc&view=rev
Log:
PR c++/61982 - dead stores to destroyed objects.
gcc/cp/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61982
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85573
--- Comment #5 from Sylvain Bertrand ---
On Mon, Apr 30, 2018 at 01:02:20PM +, redi at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85573
>
> --- Comment #4 from Jonathan Wakely ---
> 7.3.1 will never be released, i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85557
--- Comment #4 from Evgeniy Shcherbina ---
Jonathan, yes it *should* be called as foo(1, 2) but the result is as if it is
called as foo(1, 1).
--- Comment #5 from Evgeniy Shcherbina ---
Jonathan, yes it *should* be called as foo(1, 2) but the r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85557
--- Comment #4 from Evgeniy Shcherbina ---
Jonathan, yes it *should* be called as foo(1, 2) but the result is as if it is
called as foo(1, 1).
--- Comment #5 from Evgeniy Shcherbina ---
Jonathan, yes it *should* be called as foo(1, 2) but the r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85557
--- Comment #6 from Jonathan Wakely ---
Yes that's why I confirmed the bug by changing the status to NEW.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
--- Comment #45 from Andrew Haley ---
(In reply to Davin McCall from comment #44)
> > Well, perhaps not, but this is the language specification.
>
> The "one special guarantee" clause appears in the section describing union
> member access via t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
--- Comment #46 from James Kuyper Jr.
---
(In reply to Andrew Haley from comment #42)
...
> In order to use type-based alias analysis in any LTO framework it's
> necessary to save type information, and this is just more type
> information. ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85575
--- Comment #1 from Jürgen Reuter ---
Ok, after discussion on the Intel Forum I found out that this is based on
Section 7.1.11p7 of the f2008 standard , Specification expression:
A variable in a specication expression shall have its type an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
--- Comment #47 from Andrew Haley ---
(In reply to Richard Biener from comment #43)
> (In reply to Andrew Haley from comment #42)
> >
> > So, if any union types with a common initial sequence are declared
> > anywhere in a program, then their me
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
--- Comment #48 from James Kuyper Jr.
---
(In reply to Davin McCall from comment #44)
> > Well, perhaps not, but this is the language specification.
>
> The "one special guarantee" clause appears in the section describing union
> member access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
--- Comment #49 from Andrew Haley ---
(In reply to James Kuyper Jr. from comment #46)
> (In reply to Andrew Haley from comment #42)
> ...
> > In order to use type-based alias analysis in any LTO framework it's
> > necessary to save type informati
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
--- Comment #50 from Andrew Haley ---
(In reply to Andrew Haley from comment #49)
>
> Perhaps so, yes, but in practice it'd be pretty hard to do that.
> Functions can only be defined in the other scope,
Should be "the outer scope"
> and there'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85572
--- Comment #2 from Jakub Jelinek ---
Created attachment 44042
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44042&action=edit
gcc8-pr85572.patch
Untested fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85578
Bug ID: 85578
Summary: broken links in
gcc-8.0.1-RC-20180427/INSTALL/specific.html, and out
of date prerequisites.html
Product: gcc
Version: 8.0.1
Sta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
--- Comment #51 from James Kuyper Jr.
---
(In reply to Andrew Haley from comment #49)
> (In reply to James Kuyper Jr. from comment #46)
> > (In reply to Andrew Haley from comment #42)
> > ...
> > > In order to use type-based alias analysis in an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85575
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85305
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85574
--- Comment #2 from rguenther at suse dot de ---
On April 30, 2018 5:01:30 PM GMT+02:00, "hubicka at gcc dot gnu.org"
wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85574
>
>Jan Hubicka changed:
>
> What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85429
--- Comment #9 from Ian Lance Taylor ---
I suppose if worst comes to worst we can try it both ways.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85039
Jason Merrill changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58063
Jason Merrill changed:
What|Removed |Added
Status|NEW |RESOLVED
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84701
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85579
Bug ID: 85579
Summary: [9 regression] SIGSEV in fortran test case
gfortran.dg/pr51434.f90 starting with r259754
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Se
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85579
seurer at gcc dot gnu.org changed:
What|Removed |Added
Target||powerpc64*-*-*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
--- Comment #52 from Davin McCall ---
(In reply to James Kuyper Jr. from comment #48)
> > The "one special guarantee" clause appears in the section describing union
> > member access via the "." or "->" operators, implying that it only applies
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
--- Comment #53 from James Kuyper Jr.
---
(In reply to Davin McCall from comment #52)
> (In reply to James Kuyper Jr. from comment #48)
> > > The "one special guarantee" clause appears in the section describing union
> > > member access via the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68397
--- Comment #6 from emsr at gcc dot gnu.org ---
Author: emsr
Date: Mon Apr 30 19:51:13 2018
New Revision: 259777
URL: https://gcc.gnu.org/viewcvs?rev=259777&root=gcc&view=rev
Log:
2018-04-30 Edward Smith-Rowland <3dw...@verizon.net>
PR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85580
Bug ID: 85580
Summary: "conflicting C language linkage declaration" warning
for variables with identical names in `extern "C"`
functions
Product: gcc
Version: 8.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85580
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84701
--- Comment #4 from Jason Merrill ---
Author: jason
Date: Mon Apr 30 21:21:32 2018
New Revision: 259780
URL: https://gcc.gnu.org/viewcvs?rev=259780&root=gcc&view=rev
Log:
PR c++/84701 - unsigned typeof.
* decl.c (grokdeclarator)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85305
--- Comment #1 from Jason Merrill ---
Author: jason
Date: Mon Apr 30 21:21:25 2018
New Revision: 259779
URL: https://gcc.gnu.org/viewcvs?rev=259779&root=gcc&view=rev
Log:
PR c++/85305 - pack in lambda init-capture.
* parser.c (c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85305
Jason Merrill changed:
What|Removed |Added
Known to work||9.0
--- Comment #2 from Jason Merrill -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85305
Jason Merrill changed:
What|Removed |Added
Target Milestone|--- |9.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84701
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85580
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77485
Bug 77485 depends on bug 33562, which changed state.
Bug 33562 Summary: [6 Regression] aggregate DSE disabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33562
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33562
Jeffrey A. Law changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85581
Bug ID: 85581
Summary: implied DO not initializing array as expected
Product: gcc
Version: 6.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85523
--- Comment #5 from David Malcolm ---
Author: dmalcolm
Date: Tue May 1 00:10:10 2018
New Revision: 259783
URL: https://gcc.gnu.org/viewcvs?rev=259783&root=gcc&view=rev
Log:
Add gcc_rich_location::add_fixit_insert_formatted
This patch adds a su
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85523
--- Comment #6 from David Malcolm ---
Candidate patch:
https://gcc.gnu.org/ml/gcc-patches/2018-05/msg1.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69968
David Malcolm changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |dmalcolm at gcc dot
gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
--- Comment #54 from Davin McCall ---
(In reply to James Kuyper Jr. from comment #53)
> [...] However, because those
> pointers are passed to f(), which does dereference them, f() does accesses
> those members, and it does so via the use of the '
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85547
--- Comment #5 from Walter Spector ---
Turns out my third case, in comment #2, is incorrect. To correct it, line 5
should read:
path = (/ 'xyz/' /)
With this correction, my current trunk snapshot works ok. (Doesn't apply to
the first two ex
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
--- Comment #55 from James Kuyper Jr.
---
> ou need, at a minimum, to modify "accesses via" to
> "accesses directly via", in order to convey your intended meaning.
(In reply to Davin McCall from comment #54)
> (In reply to James Kuyper Jr. from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81274
--- Comment #2 from Peter Cordes ---
The stray LEA bug seems to be fixed in current trunk (9.0.0 20180429), at least
for this testcase. Gcc's stack-alignment strategy seems to be improved overall
(not copying the return address when not needed),
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85582
Bug ID: 85582
Summary: wrong code at -O1 and above on x86_64-linux-gnu in
32-bit mode
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
99 matches
Mail list logo
