https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65783
--- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org ---
*** Bug 65784 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65784
Andrew Pinski pinskia at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62182
--- Comment #5 from Marek Polacek mpolacek at gcc dot gnu.org ---
(In reply to Arnaud Bienner from comment #3)
One thing that doesn't work is turning on this warning using
-Wunused-comparison parameter. But surprisingly, turning it off with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65784
Bug ID: 65784
Summary: after reload, the memrefs_conflict_p is unreliable?
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65783
Bug ID: 65783
Summary: after reload, the memrefs_conflict_p is unreliable?
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65780
--- Comment #10 from Jakub Jelinek jakub at gcc dot gnu.org ---
(In reply to H.J. Lu from comment #9)
Created attachment 35327 [details]
A different patch
On x86, this issue only shows up with PIE. Here is a different
patch to treat common
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65786
Andrew Pinski pinskia at gcc dot gnu.org changed:
What|Removed |Added
Severity|critical|normal
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63633
Georg-Johann Lay gjl at gcc dot gnu.org changed:
What|Removed |Added
Status|RESOLVED|REOPENED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65443
--- Comment #16 from vries at gcc dot gnu.org ---
ping:
- https://gcc.gnu.org/ml/gcc-patches/2015-04/msg00763.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65777
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Target||x86_64-*-*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65783
--- Comment #3 from Jason wangjiefeng at huawei dot com ---
when sched1 the RTL is as follows:
(note 4 1 3 2 [bb 2] NOTE_INSN_BASIC_BLOCK)
(note 3 4 10 2 NOTE_INSN_FUNCTION_BEG)
(note 10 3 12 2 NOTE_INSN_DELETED)
(note 12 10 20 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65773
--- Comment #9 from Jan Hubicka hubicka at gcc dot gnu.org ---
Bill,
you can track inlining with -fdump-tree-einline (early inliner) and
-fdump-ipa-inline (the greedy inliner)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697
--- Comment #27 from mwahab at gcc dot gnu.org ---
(In reply to Andrew Macleod from comment #25)
My opinion:
1) is undesirable... even though it could possibly accelerate the conversion
of legacy sync to atomic calls... I fear it would
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65786
--- Comment #3 from Ingo Josopait josopait at goopax dot com ---
Yes, you are right. Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65549
--- Comment #22 from Ferdinand ferdinandw+gcc at gmail dot com ---
Now that I understand the bug, of course I notice (too late) that my way of
setting -g0 wasn't taking effect in the beta tree, the way it was before. So
that explains that, but
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65773
--- Comment #10 from Jakub Jelinek jakub at gcc dot gnu.org ---
For better analysis, I'll note that the:
@@ -5846,13 +5848,13 @@ virtual void llvm::AArch64InstrInfo::loa
D.391854.SubReg_TargetFlags = 0;
D.391854.ParentMI = 0B;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65781
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54714
vehre at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64950
--- Comment #4 from vries at gcc dot gnu.org ---
ping^2:
- https://gcc.gnu.org/ml/gcc-patches/2015-04/msg00796.html
- https://gcc.gnu.org/ml/gcc-patches/2015-04/msg00797.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65780
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65785
Bug ID: 65785
Summary: libgo TestIPv4MulticastListener test fails on machine
with no network connection
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697
--- Comment #30 from mwahab at gcc dot gnu.org ---
(In reply to James Greenhalgh from comment #28)
Which leaves 3). From Andrew's two proposed solutions:
a) introduce an additional memory model... MEMMODEL_SYNC or something
which is even
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65780
--- Comment #11 from Jakub Jelinek jakub at gcc dot gnu.org ---
And, shouldn't common_maybe_local for i?86/x86_64 be
!flag_pic || (TARGET_64BIT HAVE_LD_PIE_COPYRELOC != 0)
? What about other targets that are known to generate COPY relocations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65774
--- Comment #2 from Richard Biener rguenth at gcc dot gnu.org ---
Created attachment 35329
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35329action=edit
pach that might fix the issue
Hmm, can't reproduce with a cross - but eventually this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63633
Georg-Johann Lay gjl at gcc dot gnu.org changed:
What|Removed |Added
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65657
Georg-Johann Lay gjl at gcc dot gnu.org changed:
What|Removed |Added
Keywords||wrong-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697
--- Comment #28 from James Greenhalgh jgreenhalgh at gcc dot gnu.org ---
(In reply to torvald from comment #24)
I think we need to at least clarify the documentation of __atomic, probably
also of __sync; we might also have to change the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697
--- Comment #29 from mwahab at gcc dot gnu.org ---
(In reply to mwahab from comment #27)
(In reply to Andrew Macleod from comment #25)
My opinion:
1) is undesirable... even though it could possibly accelerate the conversion
of legacy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54714
--- Comment #3 from Dominique d'Humieres dominiq at lps dot ens.fr ---
...
The ICE is fixed in gcc 6.0 instead the error message
...
is printed. I deem the pr therefore as fixed.
For the record, it has been fixed between revisions r220436
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65786
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65781
--- Comment #4 from Richard Biener rguenth at gcc dot gnu.org ---
Sure.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65783
--- Comment #2 from Richard Biener rguenth at gcc dot gnu.org ---
How does the RTL look like after reload?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65773
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |5.0
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65774
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697
--- Comment #26 from mwahab at gcc dot gnu.org ---
(In reply to torvald from comment #21)
(In reply to Andrew Haley from comment #20)
(In reply to mwahab from comment #19)
(In reply to Andrew Haley from comment #18)
It looks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65786
Bug ID: 65786
Summary: Wrong code when using decltype to specify the return
type
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: critical
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65786
--- Comment #4 from Marc Glisse glisse at gcc dot gnu.org ---
Compiling with -Wall -O prints:
w.cc: In function ‘int main()’:
w.cc:45:13: warning: ‘anonymous’ is used uninitialized in this function
[-Wuninitialized]
cout d.data endl; //
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65778
--- Comment #2 from Richard Biener rguenth at gcc dot gnu.org ---
Thus technically INVALID?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65779
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |5.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65549
Ferdinand ferdinandw+gcc at gmail dot com changed:
What|Removed |Added
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65780
--- Comment #13 from H.J. Lu hjl.tools at gmail dot com ---
(In reply to Jakub Jelinek from comment #11)
And, shouldn't common_maybe_local for i?86/x86_64 be
!flag_pic || (TARGET_64BIT HAVE_LD_PIE_COPYRELOC != 0)
? What about other targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65773
--- Comment #14 from James Molloy james.molloy at arm dot com ---
Hi,
For completeness, I just fixed this in LLVM r235088
(http://reviews.llvm.org/rL235088).
Cheers,
James
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65780
--- Comment #20 from H.J. Lu hjl.tools at gmail dot com ---
(In reply to Jakub Jelinek from comment #16)
(In reply to H.J. Lu from comment #13)
Check flag_pic isn't necessary. For non-PIC, the same code sequence
and relocation are used to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697
--- Comment #34 from Andrew Macleod amacleod at redhat dot com ---
However, I guess some people relying on data races in their programs could
(mis?)understand the __sync_lock_release semantics to mean that it is a
means to get the equivalent
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65749
--- Comment #3 from Yury Gribov y.gribov at samsung dot com ---
@Kostya: I suggest to mention this in ASan FAQ.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65749
Yury Gribov y.gribov at samsung dot com changed:
What|Removed |Added
CC||y.gribov at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65780
--- Comment #15 from H.J. Lu hjl.tools at gmail dot com ---
(In reply to Jakub Jelinek from comment #10)
(In reply to H.J. Lu from comment #9)
Created attachment 35327 [details]
A different patch
On x86, this issue only shows up with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65780
--- Comment #16 from Jakub Jelinek jakub at gcc dot gnu.org ---
(In reply to H.J. Lu from comment #13)
Check flag_pic isn't necessary. For non-PIC, the same code sequence
and relocation are used to access defined and undefined symbols, common
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65780
--- Comment #18 from H.J. Lu hjl.tools at gmail dot com ---
(In reply to Jakub Jelinek from comment #10)
(In reply to H.J. Lu from comment #9)
Created attachment 35327 [details]
A different patch
On x86, this issue only shows up with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65780
--- Comment #12 from Jakub Jelinek jakub at gcc dot gnu.org ---
I've tried the #c0 testcase with gcc 5.1 rc and binutils 2.25 on various linux
architectures. On armv7hl, x86_64, s390 and s390x no errors are reported for
both normal executable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65773
James Molloy james.molloy at arm dot com changed:
What|Removed |Added
CC||james.molloy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65780
--- Comment #17 from Jakub Jelinek jakub at gcc dot gnu.org ---
(In reply to H.J. Lu from comment #15)
Can we find a tectase with initialized COMMON variable and compile
it as PIE?
I don't know where initialized DECL_COMMON could come from,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697
--- Comment #32 from torvald at gcc dot gnu.org ---
(In reply to James Greenhalgh from comment #28)
(In reply to torvald from comment #24)
3) We could do something just on ARM (and scan other arcs for similar
issues). That's perhaps the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59124
Georg Müller georgmueller at gmx dot net changed:
What|Removed |Added
CC||georgmueller
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65773
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65773
--- Comment #12 from Andrew Pinski pinskia at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #11)
So, the source in question is:
const MachineInstrBuilder MI = BuildMI(MBB, MBBI, DL, get(Opc))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65774
--- Comment #3 from Andreas Schwab sch...@linux-m68k.org ---
wi::sext has undefined behaviour with offset == 0.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697
--- Comment #31 from Andrew Macleod amacleod at redhat dot com ---
(In reply to mwahab from comment #30)
(In reply to James Greenhalgh from comment #28)
I don't think this is particularly onerous for a target. The tough part in
all of this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64277
--- Comment #23 from Richard Biener rguenth at gcc dot gnu.org ---
Author: rguenth
Date: Thu Apr 16 12:03:11 2015
New Revision: 222146
URL: https://gcc.gnu.org/viewcvs?rev=222146root=gccview=rev
Log:
2015-04-16 Richard Biener rguent...@suse.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65774
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65774
--- Comment #5 from Richard Biener rguenth at gcc dot gnu.org ---
Author: rguenth
Date: Thu Apr 16 12:10:34 2015
New Revision: 222147
URL: https://gcc.gnu.org/viewcvs?rev=222147root=gccview=rev
Log:
2015-04-16 Richard Biener rguent...@suse.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65780
--- Comment #14 from H.J. Lu hjl.tools at gmail dot com ---
(In reply to Jakub Jelinek from comment #10)
(In reply to H.J. Lu from comment #9)
Created attachment 35327 [details]
A different patch
On x86, this issue only shows up with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65780
H.J. Lu hjl.tools at gmail dot com changed:
What|Removed |Added
Attachment #35327|0 |1
is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65764
Marek Polacek mpolacek at gcc dot gnu.org changed:
What|Removed |Added
CC||mpolacek at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65780
--- Comment #21 from Jakub Jelinek jakub at gcc dot gnu.org ---
I've repeated my test on the various architectures, this time with additional
readelf -Ws test | grep optopt
if the link succeeds. And indeed, x86_64 with recent linker is the only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697
--- Comment #33 from mwahab at gcc dot gnu.org ---
(In reply to torvald from comment #32)
(In reply to James Greenhalgh from comment #28)
(In reply to torvald from comment #24)
3) We could do something just on ARM (and scan other arcs for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65780
H.J. Lu hjl.tools at gmail dot com changed:
What|Removed |Added
Attachment #35330|0 |1
is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65780
--- Comment #24 from H.J. Lu hjl.tools at gmail dot com ---
Created attachment 35332
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35332action=edit
A patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65780
--- Comment #23 from Jakub Jelinek jakub at gcc dot gnu.org ---
(In reply to H.J. Lu from comment #22)
Created attachment 35331 [details]
A patch
I am testing this.
+static bool
+ix86_binds_local_p (const_tree exp)
+{
+ return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57472
Marek Polacek mpolacek at gcc dot gnu.org changed:
What|Removed |Added
CC||mpolacek at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65749
--- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org ---
For the purpose of looking up the address in line table etc. IMNSHO the
subtraction of 1 is needed (that is what gcc unwinder does too, except for
signal frames where the pc must be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65780
--- Comment #25 from Jakub Jelinek jakub at gcc dot gnu.org ---
Comment on attachment 35332
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35332
A patch
An non-external
shouldn't this be
A non-external
?
Other than that LGTM, but I'd prefer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697
--- Comment #36 from mwahab at gcc dot gnu.org ---
(In reply to Andrew Macleod from comment #31)
Targets that don't need special sync patterns (ie most of them) simply don't
provide them. The expanders see no sync pattern and use SEQ_CST,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64363
Ilya Enkovich ienkovich at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65771
--- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org ---
Created attachment 35334
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35334action=edit
gcc5-pr65771.patch
Untested fix. Though, of course this is too risky for the 5 branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65780
--- Comment #27 from Jakub Jelinek jakub at gcc dot gnu.org ---
(In reply to H.J. Lu from comment #26)
Created attachment 35333 [details]
A patch with updated comments
Found a couple of issues, here is incremental diff, mostly formatting
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65780
H.J. Lu hjl.tools at gmail dot com changed:
What|Removed |Added
Attachment #35333|0 |1
is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65780
H.J. Lu hjl.tools at gmail dot com changed:
What|Removed |Added
Attachment #35332|0 |1
is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64805
Ilya Enkovich ienkovich at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65676
--- Comment #7 from Kirill Yukhin kyukhin at gcc dot gnu.org ---
Author: kyukhin
Date: Thu Apr 16 14:24:51 2015
New Revision: 222149
URL: https://gcc.gnu.org/viewcvs?rev=222149root=gccview=rev
Log:
gcc/
PR target/65676
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65771
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
Component|target |debug
--- Comment #8 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65779
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63854
Bug 63854 depends on bug 64003, which changed state.
Bug 64003 Summary: valgrind complains about get_attr_length_nobnd in
insn-attrtab.c from i386.md
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64003
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64003
Ilya Enkovich ienkovich at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65771
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65771
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Target|arm-linux-gnueabihf |
--- Comment #7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697
--- Comment #35 from James Greenhalgh jgreenhalgh at gcc dot gnu.org ---
(In reply to torvald from comment #32)
(In reply to James Greenhalgh from comment #28)
This also gives us an easier route to fixing any issues with the
acquire/release
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63995
Ilya Enkovich ienkovich at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831
--- Comment #45 from Dominique d'Humieres dominiq at lps dot ens.fr ---
Created attachment 34942 [details]
Better patch
Sorry for the delay, but I noticed this new patch only yesterday!-(
I'm not working on this, so I'm attaching the current
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50800
Jason Merrill jason at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65777
--- Comment #3 from raj rajendray_14 at yahoo dot co.in ---
I'm using Intel Compiler version 15.0 and the update 2. Both has the similar
issue and it could be because the libraries from the GCC version installed. I
tried setting stack size to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65789
Bug ID: 65789
Summary: cannot convert calling convention
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65789
--- Comment #1 from Kevin Puetz puetzk at puetzk dot org ---
Created attachment 35340
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35340action=edit
example using a free function pointer - works as expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65787
Bill Schmidt wschmidt at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65535
--- Comment #5 from Andreas Tobler andreast at gcc dot gnu.org ---
Here my patch:
https://gcc.gnu.org/ml/gcc-patches/2015-04/msg00839.html
I do not like to hardcode a version number. Would mean to update when needed..
The important thing here
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65787
--- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org ---
Though, len is used just in one place, so perhaps even better just remove the
{}s and use
if (XVECLEN (op, 0) != 2)
return 0;
and drop len variable alltogether, it will
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65787
--- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org ---
The formatting looks weird, look how the case UNSPEC: is formatted -
{ goes below case PARALLEL:, two columns to the right, then another two columns
to the right the body of the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65780
--- Comment #35 from H.J. Lu hjl.tools at gmail dot com ---
Created attachment 35341
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35341action=edit
The final patch with variable name change and updated comments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65788
Bug ID: 65788
Summary: [6 Regression] 416.gamess in SPEC CPU 2006 failed to
build
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65787
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |5.0
1 - 100 of 113 matches
Mail list logo
