https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88771
Martin Liška changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88785
Bug ID: 88785
Summary: ICE in as_a, at machmode.h:353
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88778
--- Comment #1 from Uroš Bizjak ---
This is due to nonexistent SCmode patterns. I guess that movsc pattern is
needed here.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88763
--- Comment #9 from Marius Messerschmidt ---
Created attachment 45397
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45397&action=edit
Basic testcase
As there where some more issues in the example I provided, I added it as an
attachment. N
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88763
--- Comment #8 from Marius Messerschmidt ---
Oh minor error from my side, the "BAD LINE" should of course be above the
if/return block otherwise it would work just fine.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88763
--- Comment #7 from Marius Messerschmidt ---
Thanks a lot for working on this!
A simple example would be the following:
-- CODE ---
int calc(int x, int y, int *flag)
{
if(flag > 5)
return x + y;
els
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88784
Bug ID: 88784
Summary: Middle end is missing some optimizations about
unsigned
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88750
--- Comment #33 from Jürgen Reuter ---
(In reply to Iain Sandoe from comment #32)
> (In reply to Jürgen Reuter from comment #31)
> > Then I get tons of duplicate symbol lines.
>
> ah well, not so simple then,
>
> then I think the next step is f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88783
--- Comment #1 from tfx ---
I use latest binutils.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88783
Bug ID: 88783
Summary: integer overflow in libiberty, heap overflow will be
triggered
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81452
--- Comment #3 from Martin Sebor ---
There is -Walloc-zero. If we want a separate knob for just it then maybe
-Wrealloc-zero.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81452
--- Comment #2 from Eric Gallager ---
any ideas for a name for this proposed warning?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50229
Eric Gallager changed:
What|Removed |Added
Target Milestone|6.4 |7.4
--- Comment #31 from Eric Gallager
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53215
--- Comment #5 from Eric Gallager ---
(In reply to Jonathan Wakely from comment #4)
>
> We could probably teach the compiler to warn about unused results of
> anything with attribute__((malloc))
That would probably be a good thing to do anyways
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88767
Li Jia He changed:
What|Removed |Added
CC||amker at gcc dot gnu.org
--- Comment #9 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88777
--- Comment #4 from Alan Modra ---
Created attachment 45395
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45395&action=edit
fix
This patch results in exactly the same gcc/insn-*.[ch] on hppa-linux as
reverting r267666, and identical test-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88763
--- Comment #6 from David Malcolm ---
Candidate patch for porting to the dump_* API:
https://gcc.gnu.org/ml/gcc-patches/2019-01/msg00512.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88376
kargl at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88376
--- Comment #4 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Thu Jan 10 01:11:51 2019
New Revision: 267793
URL: https://gcc.gnu.org/viewcvs?rev=267793&root=gcc&view=rev
Log:
2019-01-09 Steven G. Kargl
PR fortran/88376
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88777
Alan Modra changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|amodra at gcc d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86322
kargl at gcc dot gnu.org changed:
What|Removed |Added
Known to work|8.1.0 |
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88782
Bug ID: 88782
Summary: Crash when mixing make_shared from gcc <= 8.2 with
make_shared from gcc >= 8.3
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88750
--- Comment #32 from Iain Sandoe ---
(In reply to Jürgen Reuter from comment #31)
> Then I get tons of duplicate symbol lines.
ah well, not so simple then,
then I think the next step is for you to identify the last working revision of
the comp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88781
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88781
Bug ID: 88781
Summary: [meta-bug] bogus/missing -Wstringop-truncation
warnings
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86343
--- Comment #3 from ian at gcc dot gnu.org ---
Author: ian
Date: Wed Jan 9 23:38:55 2019
New Revision: 267789
URL: https://gcc.gnu.org/viewcvs?rev=267789&root=gcc&view=rev
Log:
PR go/86343
* go-gcc.cc (Gcc_backend::set_placehold
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59345
Thomas Koenig changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88780
Bug ID: 88780
Summary: Wstringop-truncation
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88779
David Malcolm changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |dmalcolm at gcc dot
gnu.org
Ta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88779
Bug ID: 88779
Summary: No fix-it hints for misspelled member initializers
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88777
--- Comment #2 from dave.anglin at bell dot net ---
I also see the same in my last build:
/home/dave/gnu/gcc/objdir/./prev-gcc/xgcc
-B/home/dave/gnu/gcc/objdir/./prev-gcc
/ -B/home/dave/opt/gnu/gcc/gcc-9/hppa-linux-gnu/bin/
-B/home/dave/opt/gnu/g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88750
--- Comment #31 from Jürgen Reuter ---
Then I get tons of duplicate symbol lines.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88750
--- Comment #30 from Iain Sandoe ---
well, what I'm trying to achieve is that the exe (with libstdc++ linked in)
provides all the symbols.
it's -Wl,-export_dynamic with an underscore, no a hyphen
you might need to add -Wl,-all_load too (to make
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88772
--- Comment #3 from Eric Botcazou ---
> I just wiped the build to start a clean build from scratch, but I remember
> checking this and it was "no". I can confirm it in ~1 hour
Can you confirm that we're talking about the 32-bit multilib of libgc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88750
--- Comment #29 from Jürgen Reuter ---
-rdynamic doesn't change anything, and ld doesn't understand -export-dynamic.
I am a bit confused what to do now, as we have a workaround, i.e. using -static
instead of -static-libtool-libs as libtool flag.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88450
Eric Botcazou changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #20 from Eric Botcazou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88775
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16615
sandra at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6
--- Comment #5 from emsr at gcc dot gnu.org ---
Right. fma is irrelevant.
I will wind up with sqrt(1 + __lo).
I won't hope that max * __scale == 1 here but just add 1. And why waste the
partial sort?
New patch tomorrow a.m. (I guess I'm too lat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88763
--- Comment #5 from David Malcolm ---
Marius: do you have a simple testcase which demonstrates an area where the log
could be improved?
[I'm testing a patch right now which ports things to the dump_* API, and thus
should make the existing dump m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16615
--- Comment #15 from sandra at gcc dot gnu.org ---
Author: sandra
Date: Wed Jan 9 21:46:45 2019
New Revision: 267787
URL: https://gcc.gnu.org/viewcvs?rev=267787&root=gcc&view=rev
Log:
2019-01-09 Sandra Loosemore
PR other/16615 [5/5]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16615
--- Comment #14 from sandra at gcc dot gnu.org ---
Author: sandra
Date: Wed Jan 9 21:44:56 2019
New Revision: 267786
URL: https://gcc.gnu.org/viewcvs?rev=267786&root=gcc&view=rev
Log:
2019-01-09 Sandra Loosemore
PR other/16615 [4/5]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16615
--- Comment #13 from sandra at gcc dot gnu.org ---
Author: sandra
Date: Wed Jan 9 21:41:36 2019
New Revision: 267785
URL: https://gcc.gnu.org/viewcvs?rev=267785&root=gcc&view=rev
Log:
2019-01-09 Sandra Loosemore
PR other/16615 [3/5]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16615
--- Comment #12 from sandra at gcc dot gnu.org ---
Author: sandra
Date: Wed Jan 9 21:39:49 2019
New Revision: 267784
URL: https://gcc.gnu.org/viewcvs?rev=267784&root=gcc&view=rev
Log:
2019-01-09 Sandra Loosemore
PR other/16615 [2/5]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88777
Jeffrey A. Law changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16615
--- Comment #11 from sandra at gcc dot gnu.org ---
Author: sandra
Date: Wed Jan 9 21:37:45 2019
New Revision: 267783
URL: https://gcc.gnu.org/viewcvs?rev=267783&root=gcc&view=rev
Log:
2019-01-09 Sandra Loosemore
PR other/16615 [1/5]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88778
Bug ID: 88778
Summary: Odd Complex float load
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88777
Bug ID: 88777
Summary: [9 Regression] Out-of-range offsets building glibc
test-tgmath2.c for hppa-linux-gnu
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88750
--- Comment #28 from Iain Sandoe ---
I wonder what would happen if you add -rdynamic (or -Wl,-export_dynamic) to the
main exe in the static link case, perhaps that would ensure that the libstdc++
symbols get resolved from there.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88776
--- Comment #1 from Harald Anlauf ---
I wrote "loss of data" because the second (valid) namelist could not be
properly read because of stat /= 0.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88776
Bug ID: 88776
Summary: Namelist read from stdin: loss of data
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88774
--- Comment #1 from joseph at codesourcery dot com ---
Although the wording is different in the two cases (and the rule for
return types is newer), I think qualifiers on function parameters should
be considered as not part of the type just as w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88775
Bug ID: 88775
Summary: [8/9 Regression] Optimize std::string assignment
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88750
--- Comment #27 from Iain Sandoe ---
JFTR, I did an experiment with a trivial hot/cold partitioned object and ld64
from XCode10.1.
Yes, it complains - but it still publishes the symbol as a weak extern.
I looked a bit harder at the symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88762
ensadc at mailnesia dot com changed:
What|Removed |Added
CC||ensadc at mailnesia dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88761
ensadc at mailnesia dot com changed:
What|Removed |Added
CC||ensadc at mailnesia dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68426
Thomas Koenig changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68426
--- Comment #6 from Thomas Koenig ---
Author: tkoenig
Date: Wed Jan 9 20:31:07 2019
New Revision: 267781
URL: https://gcc.gnu.org/viewcvs?rev=267781&root=gcc&view=rev
Log:
2019-01-09 Thomas Koenig
PR fortran/68426
* simplify
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78782
Uroš Bizjak changed:
What|Removed |Added
CC||hjl.tools at gmail dot com
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87314
--- Comment #3 from Marc Glisse ---
It isn't just with malloc, the following are not optimized either.
int f(){ int a; return &a=="hello"; }
int g(){ return "bye"=="hello"; }
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88450
--- Comment #19 from Jakub Jelinek ---
And, finally found the reason why r266345 causes the wrong-code.
The problem is that the align_dynamic_address instructions are emitted at
whatever spot in the function asked for the temporary slot, those in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88774
Bug ID: 88774
Summary: Qualification of parameters does not change a function
type: Bug or standard defect?
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severi
Hi,
How about targeting customer base of QAD and SAP Users for your Marketing
and sales needs? Please let me know.
This file includes– Company name, Website, Contact name (First, Middle,
Last), Title, Direct email address, Phone, Postal address, Industry, SIC
codes, Employee size, Revenue size an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739
--- Comment #38 from rsandifo at gcc dot gnu.org
---
Created attachment 45392
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45392&action=edit
patch that changes get_ref_base_and_extent for bare SSA_NAMEs
(In reply to Wilco from comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88714
--- Comment #5 from Mikael Pettersson ---
With -da -fdump-tree-all, stage1 and stage2 output starts to differ in
043t.profile_estimate and then more visibly in 130t.pre:
diff -ru stage1/sort.i.043t.profile_estimate
stage2/sort.i.043t.profile_est
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88765
Segher Boessenkool changed:
What|Removed |Added
Target|powerpc64le-linux-gnu |powerpc*-*-*
Status|UNC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88765
--- Comment #2 from Segher Boessenkool ---
What exact options are needed here?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88727
Eric Gallager changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88765
--- Comment #1 from Segher Boessenkool ---
So in the first example, why is the branch not forwarded already?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88766
--- Comment #8 from Jakub Jelinek ---
A C proof of concept:
--- gcc/c/c-parser.c.jj 2019-01-07 09:47:33.187515618 +0100
+++ gcc/c/c-parser.c2019-01-09 19:15:05.216756760 +0100
@@ -4624,6 +4624,11 @@ c_parser_braced_init (c_parser *parser,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88766
--- Comment #7 from Jakub Jelinek ---
As for the GCC diagnostic pragma, we need it to be a deferred pragma, have no
idea how else could we handle that when it is not visible in the token stream.
And, if it is visible in the token stream, accepti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739
--- Comment #37 from Wilco ---
(In reply to rsand...@gcc.gnu.org from comment #35)
> Yeah, the expr.c patch makes the original testcase work, but we still fail
> for:
That's the folding in ccp1 after inlining, which will require a similar fix.
T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88766
Martin Sebor changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88773
Bug ID: 88773
Summary: statement expression returning a cast treated as an
lvalue
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Prior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88576
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739
--- Comment #36 from Eric Botcazou ---
> Like Wilco says, the torture test seems to pass with an unpatched compiler
> (but seems like a good thing to have anyway).
Likewise on SPARC at any optimization level.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88766
--- Comment #5 from joseph at codesourcery dot com ---
On Wed, 9 Jan 2019, msebor at gcc dot gnu.org wrote:
> I don't disagree with the conclusion about the validity of this test case but
> there are examples where GCC does treat a statement exp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78782
--- Comment #1 from Jeffrey Walton ---
Also documented in the Intel Intrinsics Guide at
https://software.intel.com/sites/landingpage/IntrinsicsGuide/#text=_mm_loadu_si64.
According to the guide, the intrinsic is the movq instruction.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88766
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88766
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88739
--- Comment #34 from Wilco ---
With just the expr.c patch the gcc regression tests all pass on big-endian
AArch64. Interestingly this includes the new torture test, ie. it does not
trigger the union bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88769
--- Comment #4 from joseph at codesourcery dot com ---
Errors for infinite arguments to math.h functions are generally documented
in Annex F; 7.12.1 just says "an implementation may define additional
domain errors, provided that such errors are
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88772
--- Comment #2 from Andoni ---
(In reply to Eric Botcazou from comment #1)
> What's the result of the configure check of libgcc for SJLJ? It should be
> visible in the config.log file in the libgcc build directory:
>
> whether the compiler is c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88763
--- Comment #4 from David Malcolm ---
(In reply to Marius Messerschmidt from comment #3)
> Sorry but I do not fully understand what you mean. Do you suggest using
> different command line arguments?
I believe Richard is referring to the internal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88766
--- Comment #2 from joseph at codesourcery dot com ---
Yes, I think that (a) a statement expression is not an lvalue and (b) if
it were (or if the code were changed to move the unary '&' inside the
statement expression), the code would be takin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88771
--- Comment #5 from Martin Sebor ---
That said, the size range in the warning output is wrong. It should be just
4294967295. The warning should probably also be changed to -Wstringop-overflow
which diagnoses both out-of-bounds writes and reads.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88771
--- Comment #4 from Martin Sebor ---
The warning is triggered by the excessive size argument in the strncpy call.
The excessive size makes the call invalid regardless of the values of the two
pointer arguments.
This happens both with the reduce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88572
--- Comment #13 from Will Wray ---
Re-reviewing, I notice that the patch I posted in comment #9
now rejects nested empty-brace scalar init:
int i{{}};
which was previously accepted. So we'll need a decision on this too.
Clang rejects with -p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88539
Nick Clifton changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88772
Eric Botcazou changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86979
--- Comment #10 from Alexander Monakov ---
As discussed with Andrew offline, the real problem is creating a path where
stack pointer is decremented twice - that is really not supposed to happen (so
the issue could appear even in absence of REG_AR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88450
--- Comment #18 from Jakub Jelinek ---
Created attachment 45391
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45391&action=edit
gcc9-pr88450.patch
Untested patch that does that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88450
--- Comment #17 from Jakub Jelinek ---
Though, the more I look at it, the more I'm for reversion of the patch + deal
with it in the assign_stack_local caller that needs that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87836
--- Comment #30 from Gary Mills ---
A build of gcc-7 on SPARC just completed successfully with a much larger
configuration:
$
/export/home/mills/Downloads/code/oi-userland/components/developer/gcc-7/gcc-7.3.0/configure
CC=/usr/gcc/4.9/bin/gcc CX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80042
Eric Gallager changed:
What|Removed |Added
CC||per at pz dot se
--- Comment #6 from Eri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88769
Eric Gallager changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84010
--- Comment #20 from James Clarke ---
(In reply to Eric Botcazou from comment #19)
> > Ah, great, thanks, that's indeed a nicer way of writing the patterns.
>
> You're welcome. Don't hesitate to ping next time I drop the ball for so
> long.
I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84010
--- Comment #19 from Eric Botcazou ---
> Ah, great, thanks, that's indeed a nicer way of writing the patterns.
You're welcome. Don't hesitate to ping next time I drop the ball for so long.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84010
Eric Botcazou changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
1 - 100 of 183 matches
Mail list logo
