On 27/02/14 07:50, Mingjie Xing wrote:
Hello,
I'm wondering if it's a good idea to turn on some warnings by default
(or even promote them to error), such as -Wreturn-type on C. This
would help programmers to avoid some mistakes.
Regards,
Mingjie
Personally, I think gcc should issue a
On 27/02/2014 07:50, Mingjie Xing wrote:
Hello,
I'm wondering if it's a good idea to turn on some warnings by default
(or even promote them to error), such as -Wreturn-type on C. This
would help programmers to avoid some mistakes.
I am writing a patch for this specific change but it is a
Over the years there has been a great deal of traffic on these lists
caused by misunderstandings of GCC's inline assembler. That's partly
because it's inherently tricky, but the existing documentation needs
to be improved.
dw limegreenso...@yahoo.com has done a fairly thorough reworking of
the
Andrew Haley a...@redhat.com writes:
Over the years there has been a great deal of traffic on these lists
caused by misunderstandings of GCC's inline assembler. That's partly
because it's inherently tricky, but the existing documentation needs
to be improved.
dw limegreenso...@yahoo.com has
On 27/02/14 11:07, Andrew Haley wrote:
Over the years there has been a great deal of traffic on these lists
caused by misunderstandings of GCC's inline assembler. That's partly
because it's inherently tricky, but the existing documentation needs
to be improved.
dw limegreenso...@yahoo.com has
On Thu, 2014-02-27 at 10:14 +0100, David Brown wrote:
On 27/02/14 07:50, Mingjie Xing wrote:
Hello,
I'm wondering if it's a good idea to turn on some warnings by default
(or even promote them to error), such as -Wreturn-type on C. This
would help programmers to avoid some mistakes.
Hi all,
We have recently ran into a performance/code size regression on ARM
targets after transition from GCC 4.7 to GCC 4.8 (this regression is
also present in 4.9).
The following code snippet uses Linux-style compiler barriers to protect
memory writes:
#define barrier() __asm__
I've been hacking on a prototype that generates matching and
simplification code from a meta-description. The goal is
to provide a single source of transforms currently spread
over the compiler, mostly fold-const.c, gimple-fold.c and
tree-ssa-forwprop.c. Another goal is to make these
After some investigation, we discovered that this behavior is caused by
big hammer in gcc/cse.c:
/* A volatile ASM or an UNSPEC_VOLATILE invalidates everything. */
if (NONJUMP_INSN_P (insn)
volatile_insn_p (PATTERN (insn)))
flush_hash_table ();
This code (introduced
On Thu, Feb 27, 2014 at 4:02 PM, Eric Botcazou ebotca...@adacore.com wrote:
After some investigation, we discovered that this behavior is caused by
big hammer in gcc/cse.c:
/* A volatile ASM or an UNSPEC_VOLATILE invalidates everything. */
if (NONJUMP_INSN_P (insn)
Richard Biener wrote:
If this behavior is not intended, what would be the best way to fix
performance? I could teach GCC to not remove constant RTXs in
flush_hash_table() but this is probably very naive and won't cover some
corner-cases.
That could be a good starting point though.
Though
On Mon, 2014-02-24 at 11:54 -0800, Linus Torvalds wrote:
On Mon, Feb 24, 2014 at 10:53 AM, Paul E. McKenney
paul...@linux.vnet.ibm.com wrote:
Good points. How about the following replacements?
3. Adding or subtracting an integer to/from a chained pointer
results in
On Thu, Feb 27, 2014 at 7:37 AM, Torvald Riegel trie...@redhat.com wrote:
I agree that just considering syntactic properties of the program seems
to be insufficient. Making it instead depend on whether there is a
semantic dependency due to a value being necessary to compute a
result seems
Yury Gribov y.gri...@samsung.com writes:
Richard Biener wrote:
If this behavior is not intended, what would be the best way to fix
performance? I could teach GCC to not remove constant RTXs in
flush_hash_table() but this is probably very naive and won't cover some
corner-cases.
That could
On 27/02/14 16:36, Yury Gribov wrote:
Richard Biener wrote:
If this behavior is not intended, what would be the best way to fix
performance? I could teach GCC to not remove constant RTXs in
flush_hash_table() but this is probably very naive and won't cover some
corner-cases.
That could be a
Hi,
On Thu, 27 Feb 2014, Richard Sandiford wrote:
[... many cases where 'volatile' in asm doesn't inhibit optimizations
...]
We do nothing this draconian for a normal function call, which could
easily use a volatile asm internally. IMO anything that isn't flushed
for a call shouldn't be
Hi Evgeny,
As i said, I'm working for source-to-source generation for my master
thesis. But my compiler can transform from C to CUDA not PTX now :)
For further information, I uploaded https://github.com/grypp/macc-omp4
my documents and code samples regarding my master thesis. I also added
my
Andrew Haley a...@redhat.com writes:
Over the years there has been a great deal of traffic on these lists
caused by misunderstandings of GCC's inline assembler. That's partly
because it's inherently tricky, but the existing documentation needs
to be improved.
dw limegreenso...@yahoo.com
On Thu, Feb 27, 2014 at 04:37:33PM +0100, Torvald Riegel wrote:
xagsmtp2.20140227154925.3...@vmsdvm9.vnet.ibm.com
On Mon, 2014-02-24 at 11:54 -0800, Linus Torvalds wrote:
On Mon, Feb 24, 2014 at 10:53 AM, Paul E. McKenney
paul...@linux.vnet.ibm.com wrote:
Good points. How about the
On Thu, Feb 27, 2014 at 09:01:40AM -0800, Linus Torvalds wrote:
On Thu, Feb 27, 2014 at 7:37 AM, Torvald Riegel trie...@redhat.com wrote:
I agree that just considering syntactic properties of the program seems
to be insufficient. Making it instead depend on whether there is a
semantic
On Thu, Feb 27, 2014 at 09:50:21AM -0800, Paul E. McKenney wrote:
On Thu, Feb 27, 2014 at 04:37:33PM +0100, Torvald Riegel wrote:
xagsmtp2.20140227154925.3...@vmsdvm9.vnet.ibm.com
On Mon, 2014-02-24 at 11:54 -0800, Linus Torvalds wrote:
On Mon, Feb 24, 2014 at 10:53 AM, Paul E. McKenney
On Thu, Feb 27, 2014 at 11:06 AM, Paul E. McKenney
paul...@linux.vnet.ibm.com wrote:
3. The comparison was against another RCU-protected pointer,
where that other pointer was properly fetched using one
of the RCU primitives. Here it doesn't matter which pointer
Yury Gribov schrieb:
Richard Biener wrote:
If this behavior is not intended, what would be the best way to fix
performance? I could teach GCC to not remove constant RTXs in
flush_hash_table() but this is probably very naive and won't cover some
corner-cases.
That could be a good starting
Hi Güray!
Giving some pointers here (but this is not a complete list), to
announcements and a few discussion threads, that should already answer
some of your questions, give an idea who's currently working on what:
http://news.gmane.org/find-root.php?message_id=%3C51879F4E.10402%40samsung.com%3E,
On Thu, Feb 27, 2014 at 11:47:08AM -0800, Linus Torvalds wrote:
On Thu, Feb 27, 2014 at 11:06 AM, Paul E. McKenney
paul...@linux.vnet.ibm.com wrote:
3. The comparison was against another RCU-protected pointer,
where that other pointer was properly fetched using one
Snapshot gcc-4.8-20140227 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.8-20140227/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.8 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
On Thu, Feb 27, 2014 at 09:50:21AM -0800, Paul E. McKenney wrote:
On Thu, Feb 27, 2014 at 04:37:33PM +0100, Torvald Riegel wrote:
xagsmtp2.20140227154925.3...@vmsdvm9.vnet.ibm.com
On Mon, 2014-02-24 at 11:54 -0800, Linus Torvalds wrote:
On Mon, Feb 24, 2014 at 10:53 AM, Paul E. McKenney
On 2/27/2014 4:11 AM, Richard Sandiford wrote:
Andrew Haley a...@redhat.com writes:
Over the years there has been a great deal of traffic on these lists
caused by misunderstandings of GCC's inline assembler. That's partly
because it's inherently tricky, but the existing documentation needs
to
On 2/27/2014 9:35 AM, Andi Kleen wrote:
Andrew Haley a...@redhat.com writes:
Over the years there has been a great deal of traffic on these lists
caused by misunderstandings of GCC's inline assembler. That's partly
because it's inherently tricky, but the existing documentation needs
to be
On 2/27/2014 4:22 AM, Kyrill Tkachov wrote:
On 27/02/14 11:07, Andrew Haley wrote:
Over the years there has been a great deal of traffic on these lists
caused by misunderstandings of GCC's inline assembler. That's partly
because it's inherently tricky, but the existing documentation needs
to
dw limegreenso...@yahoo.com writes:
What would you say to something like this:
Since GCC does not parse the asm, it has no visibility of any static
variables or functions it references. This may result in those
symbols getting discarded by GCC as unused. To avoid this problem,
list the
asm volatile + memory clobber should be the last resort barrier, if you skip
this out of the compiler or change its semantics (pinned by the current
documentation) at will, it's not unlikely you break existing code in favour
or saving some poor instructions.
Problem is that there is no
Hello!
This code (introduced in
http://gcc.gnu.org/viewcvs/gcc?view=revisionrevision=193802) aborts
CSE after seeing a volatile inline asm.
Note that introduced is not really correct here, the code had been
there for a long time but it was treating some volatile asms as
barriers and
dw limegreenso...@yahoo.com writes:
On 2/27/2014 4:11 AM, Richard Sandiford wrote:
Andrew Haley a...@redhat.com writes:
Over the years there has been a great deal of traffic on these lists
caused by misunderstandings of GCC's inline assembler. That's partly
because it's inherently tricky,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59223
--- Comment #4 from Marek Polacek mpolacek at gcc dot gnu.org ---
Author: mpolacek
Date: Thu Feb 27 08:05:21 2014
New Revision: 208196
URL: http://gcc.gnu.org/viewcvs?rev=208196root=gccview=rev
Log:
PR middle-end/59223
* tree-ssa-uninit.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59223
Marek Polacek mpolacek at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60354
Bug ID: 60354
Summary: fails to demangle _Z3fooIPUlvE_EvT_
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60355
Bug ID: 60355
Summary: C519 of Fortran 2008 for BIND attribute not enforced
Product: gcc
Version: 4.8.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60353
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |4.9.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55113
--- Comment #14 from Richard Biener rguenth at gcc dot gnu.org ---
(In reply to pmatos from comment #13)
(In reply to Richard Biener from comment #11)
If double_type_node is FE dependent then it needs treatment in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60349
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60348
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60347
--- Comment #6 from Richard Biener rguenth at gcc dot gnu.org ---
Maybe add the testcases to the testsuite?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60295
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55113
--- Comment #15 from pmatos at gcc dot gnu.org ---
(In reply to Richard Biener from comment #14)
See above - if that works I'd prefer that.
Makes sense. Thanks Richard. I will give that a try and if everything looks ok
I will prepare a patch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59308
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P1
---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59487
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59925
--- Comment #2 from Richard Biener rguenth at gcc dot gnu.org ---
Somewhat unconclusive without a testcase. Does it meanwhile work by accident?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60133
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60147
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60150
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60169
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60315
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60306
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Keywords||wrong-code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60353
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Keywords||rejects-valid
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60334
janus at gcc dot gnu.org changed:
What|Removed |Added
CC||janus at gcc dot gnu.org
---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60334
--- Comment #2 from Antony Lewis antony at cosmologist dot info ---
I looked for a while for a reproducible crash, which wasn't easy - mostly
behaviour was errratic crashes - I was using 4.9 trunk from a week ago. But
there was definitely a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59487
--- Comment #7 from GGanesh Ganesh.Gopalasubramanian at amd dot com ---
Richard! With gcc version 4.9.0 20140224, I could see a gap between
with/without -fwhole-program.
with -fwhole-program : time ./rnflowWhPr
real0m26.184s
user
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59487
--- Comment #8 from rguenther at suse dot de rguenther at suse dot de ---
On Thu, 27 Feb 2014, Ganesh.Gopalasubramanian at amd dot com wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59487
--- Comment #7 from GGanesh
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60348
--- Comment #2 from Nach nachms+gcc at gmail dot com ---
(In reply to Richard Biener from comment #1)
It works for me. What does ldd test show? Do you have the static
libstdc++/libgcc installed (Debian may package those separately?)
ldd test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60349
Domani Hannes ssbssa at yahoo dot de changed:
What|Removed |Added
CC||ssbssa at yahoo dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60348
--- Comment #3 from Marc Glisse glisse at gcc dot gnu.org ---
man nm:
U The symbol is undefined.
u The symbol is a unique global symbol. This is a GNU extension
[...]
The program does run fine for me with exactly the same
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60356
Bug ID: 60356
Summary: Compiler segfault instead of error about module
procedure / procedure with an explicit interface
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60356
--- Comment #1 from Mike mvondomaros at gmail dot com ---
Created attachment 32223
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32223action=edit
example that causes the segfault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60348
--- Comment #4 from Nach nachms+gcc at gmail dot com ---
(In reply to Marc Glisse from comment #3)
man nm:
U The symbol is undefined.
u The symbol is a unique global symbol. This is a GNU
extension [...]
The
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60289
Mike mvondomaros at gmail dot com changed:
What|Removed |Added
CC||mvondomaros at gmail
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60348
--- Comment #5 from Marc Glisse glisse at gcc dot gnu.org ---
(In reply to Nach from comment #4)
The issue isn't that it can't run on a machine with a proper libstdc++
installed, the issue is that -static-libstdc++ is broken, meaning the binary
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60348
--- Comment #6 from Nach nachms+gcc at gmail dot com ---
Does compiling with: -fuse-ld=gold -Wl,--no-gnu-unique
help? Seems like your old system (ld.so?) gets confused by the new feature.
Doing so, there are no longer any u symbols appearing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60348
--- Comment #7 from Nach nachms+gcc at gmail dot com ---
Upon further testing, -fuse-ld=gold by itself without -Wl,--no-gnu-unique
appears to get the job done.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60353
Jason Merrill jason at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60348
--- Comment #8 from Marc Glisse glisse at gcc dot gnu.org ---
gold also produces the unique symbols. Main difference I can think of is
visible in the output of file test:
ELF 64-bit LSB executable, x86-64, version 1 (SYSV)
ELF 64-bit LSB
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60341
--- Comment #8 from Steve Chapel schapel at umich dot edu ---
Yes, it's a regression from earlier versions of gfortran. I have verified that
with the workaround, Nonmem 6.2.0 compiles and runs properly with optimization
using gfortran 4.8.1 and
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15606
--- Comment #8 from nicolas.boulenguez at free dot fr ---
Confirmed on 4.9-20140218.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15614
--- Comment #5 from nicolas.boulenguez at free dot fr ---
Confirmed on 4.9-20140218
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15615
--- Comment #5 from nicolas.boulenguez at free dot fr ---
Fixed in 4.9-20140218.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15799
--- Comment #9 from nicolas.boulenguez at free dot fr ---
Fixed in 4.9-20140218
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60255
--- Comment #5 from Antony Lewis antony at cosmologist dot info ---
The patch generated a SIGSEGV in test code (which works with ifort), but could
be another unrelated issue.
Here's another simple test case for the original issue:
program test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15800
--- Comment #6 from nicolas.boulenguez at free dot fr ---
confirm 4.9-20140218
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15840
--- Comment #5 from nicolas.boulenguez at free dot fr ---
confirm 4.9-20140218
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15843
--- Comment #6 from nicolas.boulenguez at free dot fr ---
confirm 4.9-20140218
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15844
--- Comment #4 from nicolas.boulenguez at free dot fr ---
confirm 4.9-20140218
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15845
--- Comment #4 from nicolas.boulenguez at free dot fr ---
confirm 4.9-20140218
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60348
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|WAITING |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60336
--- Comment #15 from Jason Merrill jason at gcc dot gnu.org ---
(In reply to Andrew Pinski from comment #7)
No this testcase is not valid at all. See
http://gcc.gnu.org/onlinedocs/gcc-4.8.2/gcc/Empty-Structures.html#Empty-
Structures where it
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15917
--- Comment #6 from nicolas.boulenguez at free dot fr ---
4.9.0 20140218 (experimental) [trunk rev 207856] (x86_64-linux-gnu) GCC error
in gnat_to_gnu_entity, at ada/gcc-interface/decl.c:568
Error detected at test_70.adb:18:9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16075
--- Comment #4 from nicolas.boulenguez at free dot fr ---
confirm 4.9-20140218
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16076
--- Comment #4 from nicolas.boulenguez at free dot fr ---
confirm 4.9-20140218
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16077
--- Comment #4 from nicolas.boulenguez at free dot fr ---
confirmed 4.9-20140218
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60357
Bug ID: 60357
Summary: structure constructor with unspecified values for
allocatable components
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60348
Nach nachms+gcc at gmail dot com changed:
What|Removed |Added
Status|RESOLVED|REOPENED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60348
--- Comment #11 from Richard Biener rguenth at gcc dot gnu.org ---
(In reply to Nach from comment #10)
While you may be marking this as invalid, isn't there a serious issue here?
Shouldn't -static-libstdc++ work without any special flags?
But
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59487
--- Comment #9 from GGanesh Ganesh.Gopalasubramanian at amd dot com ---
Other options are -Ofast -funroll-loops -fpeel-loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60358
Bug ID: 60358
Summary: [patch] ARM support broken for Haiku
Product: gcc
Version: 4.8.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: driver
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60358
--- Comment #1 from Alexander von Gluck kallisti5 at unixzen dot com ---
Created attachment 32225
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32225action=edit
rev2
an additional resolution path. This one may be better, however
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60348
--- Comment #12 from Nach nachms+gcc at gmail dot com ---
Isn't the whole point of -static-libstdc++ is to remove the dependency of
libstdc++ from the binary? Even without the option, it does indeed work fine on
the system it was compiled on.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60348
--- Comment #13 from Richard Biener rguenth at gcc dot gnu.org ---
(In reply to Nach from comment #12)
Isn't the whole point of -static-libstdc++ is to remove the dependency of
libstdc++ from the binary? Even without the option, it does indeed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60348
--- Comment #14 from Nach nachms+gcc at gmail dot com ---
(In reply to Richard Biener from comment #13)
If you want to target old dynamic linkers then you have to disable support
for GCC features that exploit features of new dynamic linkers.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60348
--- Comment #15 from Richard Biener rguenth at gcc dot gnu.org ---
(In reply to Nach from comment #14)
(In reply to Richard Biener from comment #13)
If you want to target old dynamic linkers then you have to disable support
for GCC features
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60336
H.J. Lu hjl.tools at gmail dot com changed:
What|Removed |Added
CC||hjl.tools at gmail
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60348
--- Comment #16 from Andreas Schwab sch...@linux-m68k.org ---
If you want to build for old systems you need to use the old tools from those
old systems and the output will still work on newer systems (backward
compatiblity). New tools are using
1 - 100 of 242 matches
Mail list logo
