https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65780
--- Comment #10 from Jakub Jelinek ---
(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 symbol defined local
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65783
--- Comment #2 from Richard Biener ---
How does the RTL look like after reload?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65781
--- Comment #4 from Richard Biener ---
Sure.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65780
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65779
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |5.0
Summary|undefined local
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65778
--- Comment #2 from Richard Biener ---
Thus technically INVALID?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65777
Richard Biener changed:
What|Removed |Added
Target||x86_64-*-*
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65773
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |5.0
--- Comment #8 from Richard Biener
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65774
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65780
--- Comment #11 from Jakub Jelinek ---
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 in this
case for non-P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65783
--- Comment #3 from Jason ---
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 NOTE_INSN_DELETED)
(insn 20 12 2 2 (set (reg/f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65781
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #5
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 loo
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=65774
--- Comment #2 from Richard Biener ---
Created attachment 35329
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35329&action=edit
pach that might fix the issue
Hmm, can't reproduce with a cross - but eventually this accesses uninitialized
m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65773
--- Comment #9 from Jan Hubicka ---
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=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
Pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65786
Andrew Pinski changed:
What|Removed |Added
Severity|critical|normal
--- Comment #1 from Andrew Pinski
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=65657
Georg-Johann Lay changed:
What|Removed |Added
Keywords||wrong-code
Target|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63633
Georg-Johann Lay changed:
What|Removed |Added
CC||jonathan.creekmore@synapse-
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 in
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=63633
Georg-Johann Lay changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
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=65697
--- Comment #28 from James Greenhalgh ---
(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 implementation of __sync
> builtins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65549
Ferdinand changed:
What|Removed |Added
CC||ferdinandw+gcc at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54714
--- Comment #3 from Dominique d'Humieres ---
> ...
> 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 (2015-02-05, ICE)
and r
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 l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65786
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65786
--- Comment #3 from Ingo Josopait ---
Yes, you are right. Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65786
--- Comment #4 from Marc Glisse ---
Compiling with -Wall -O prints:
w.cc: In function ‘int main()’:
w.cc:45:13: warning: ‘’ is used uninitialized in this function
[-Wuninitialized]
cout << d.data << endl; // bad: d.data == some random numbe
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65773
--- Comment #10 from Jakub Jelinek ---
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;
D.391854.Contents.ImmVal = 0;
- ll
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65549
--- Comment #22 from Ferdinand ---
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 still this crash is happening with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65773
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65773
--- Comment #12 from Andrew Pinski ---
(In reply to Jakub Jelinek from comment #11)
> So, the source in question is:
> const MachineInstrBuilder &MI = BuildMI(MBB, MBBI, DL, get(Opc))
> .addReg(DestReg, get
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65780
--- Comment #12 from Jakub Jelinek ---
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 and PIE, for i686 PIE link
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65780
--- Comment #13 from H.J. Lu ---
(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 that are known to gen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65773
James Molloy changed:
What|Removed |Added
CC||james.molloy at arm dot com
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65780
--- Comment #14 from H.J. Lu ---
(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 PIE. Here is a diffe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65774
--- Comment #3 from Andreas Schwab ---
wi::sext has undefined behaviour with offset == 0.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697
--- Comment #31 from Andrew Macleod ---
(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 is figuring out the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65780
--- Comment #15 from H.J. Lu ---
(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 PIE. Here is a diffe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65780
--- Comment #16 from Jakub Jelinek ---
(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
> or not.
What do you
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65773
--- Comment #14 from James Molloy ---
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 #17 from Jakub Jelinek ---
(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, but this spot
certainly i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65780
--- Comment #18 from H.J. Lu ---
(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 PIE. Here is a diffe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65780
H.J. Lu changed:
What|Removed |Added
Attachment #35327|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65780
--- Comment #20 from H.J. Lu ---
(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 access defined and unde
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=65764
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64277
--- Comment #23 from Richard Biener ---
Author: rguenth
Date: Thu Apr 16 12:03:11 2015
New Revision: 222146
URL: https://gcc.gnu.org/viewcvs?rev=222146&root=gcc&view=rev
Log:
2015-04-16 Richard Biener
PR tree-optimization/64277
* tre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65774
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65774
--- Comment #5 from Richard Biener ---
Author: rguenth
Date: Thu Apr 16 12:10:34 2015
New Revision: 222147
URL: https://gcc.gnu.org/viewcvs?rev=222147&root=gcc&view=rev
Log:
2015-04-16 Richard Biener
PR tree-optimization/65774
* tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65780
--- Comment #21 from Jakub Jelinek ---
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 one
where optopt is defin
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59124
Georg Müller changed:
What|Removed |Added
CC||georgmueller at gmx dot net
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697
--- Comment #34 from Andrew Macleod ---
> 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 of a C11 release *fence*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65780
H.J. Lu changed:
What|Removed |Added
Attachment #35330|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65780
--- Comment #23 from Jakub Jelinek ---
(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 default_binds_local_p_3 (exp, fla
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57472
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65749
Yury Gribov changed:
What|Removed |Added
CC||y.gribov at samsung dot com
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65749
--- Comment #3 from Yury Gribov ---
@Kostya: I suggest to mention this in ASan FAQ.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65749
--- Comment #4 from Jakub Jelinek ---
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 on the faulting or asynchr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65780
--- Comment #24 from H.J. Lu ---
Created attachment 35332
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35332&action=edit
A patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65780
--- Comment #25 from Jakub Jelinek ---
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 another pair of eyes on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65780
H.J. Lu changed:
What|Removed |Added
Attachment #35332|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697
--- Comment #35 from James Greenhalgh ---
(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 __sync primitives (__sync_
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_C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65779
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64805
Ilya Enkovich changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64363
Ilya Enkovich changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63995
Ilya Enkovich changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
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 changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65771
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65771
Jakub Jelinek changed:
What|Removed |Added
Target|arm-linux-gnueabihf |
--- Comment #7 from Jakub Jelinek ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65676
--- Comment #7 from Kirill Yukhin ---
Author: kyukhin
Date: Thu Apr 16 14:24:51 2015
New Revision: 222149
URL: https://gcc.gnu.org/viewcvs?rev=222149&root=gcc&view=rev
Log:
gcc/
PR target/65676
* config/i386/i386.c (fixup_modeless_const
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 k
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65771
--- Comment #9 from Jakub Jelinek ---
Created attachment 35334
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35334&action=edit
gcc5-pr65771.patch
Untested fix. Though, of course this is too risky for the 5 branch at this
point, and givin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65780
--- Comment #27 from Jakub Jelinek ---
(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
improvements,
and in the cas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65780
H.J. Lu changed:
What|Removed |Added
Attachment #35333|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831
--- Comment #45 from Dominique d'Humieres ---
> 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 patch in my work tree,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50800
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
Depends on|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65780
--- Comment #29 from Jeffrey A. Law ---
Oh how I wish all this stuff was better documented, both in the GCC sources and
at a higher level in some linkers/loaders documentation.
ix86_binds_local_p needs a function comment. I think with a functio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65780
H.J. Lu changed:
What|Removed |Added
Attachment #35335|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65780
--- Comment #31 from H.J. Lu ---
(In reply to Jeffrey A. Law from comment #29)
> Oh how I wish all this stuff was better documented, both in the GCC sources
> and at a higher level in some linkers/loaders documentation.
>
> ix86_binds_local_p ne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65780
--- Comment #32 from Jeffrey A. Law ---
HJ, you're missing my point. I need to understand the meaning of the variable
defined_locally to move forward with the patch. Is it a must property (ie, if
true, the symbol is always defined locally), or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65780
--- Comment #33 from H.J. Lu ---
(In reply to Jeffrey A. Law from comment #32)
> HJ, you're missing my point. I need to understand the meaning of the
> variable defined_locally to move forward with the patch. Is it a must
> property (ie, if tru
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65787
Bug ID: 65787
Summary: [5.1 regression] Miscompile due to bad vector swap
optimization for little endian
Product: gcc
Version: 5.1.0
Status: UNCONFIRMED
Keyword
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65787
Bill Schmidt changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
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
Prior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65787
--- Comment #1 from Bill Schmidt ---
Created attachment 35338
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35338&action=edit
Proposed patch
Attached patch appears to solve the problem, but I still need to do regression
testing.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65787
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|--- |5.0
Summary|[5.1 regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65535
--- Comment #5 from Andreas Tobler ---
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 is, if you build a cross com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65777
--- Comment #3 from raj ---
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 unlimited, 190 MB to 16 GB, none wo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65780
--- Comment #34 from Jakub Jelinek ---
(In reply to Jeffrey A. Law from comment #29)
> What I'm trying to wrap my head around is what "defined_locally" really
> means. Is it a "must" or "maybe" property when it gets set in
> default_binds_local_
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 ---
Created attachment 35340
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35340&action=edit
example using a free function pointer - works as expected
1 - 100 of 108 matches
Mail list logo
