However I also want a singlelib version to be able to compile. When
createing a glibc crosscompiler, compiling 4 version of glibc makes it
inpracticable. And crosscompiling user space apps I dont want the need to
supply the extra switches explicitly all the time.
Maybe there is a simple way
Ralf Wildenhues ralf.wildenh...@gmx.de writes:
the Automake manual can be read otherwise: ch. 8.3.7 `_LIBADD',
`_LDFLAGS', and `_LIBTOOLFLAGS' states:
As shown in previous sections, the `LIBRARY_LIBADD' variable should be
used to list extra libtool objects (`.lo' files) or libtool
Quoting Eric Botcazou ebotca...@adacore.com:
However I also want a singlelib version to be able to compile. When
createing a glibc crosscompiler, compiling 4 version of glibc makes it
inpracticable. And crosscompiling user space apps I dont want the need to
supply the extra switches explicitly
H.J. Lu hjl.to...@gmail.com writes:
Given a basic block BB, is there a way to tell if it will reach
EXIT_BLOCK_PTR?
Seems like you should be able to use dominated_by_p.
Ian
Quoting Ian Lance Taylor i...@google.com:
H.J. Lu hjl.to...@gmail.com writes:
Given a basic block BB, is there a way to tell if it will reach
EXIT_BLOCK_PTR?
Seems like you should be able to use dominated_by_p.
Unless he wants to know if it will *actually* reach EXIT_BLOCK_PTR,
in which
Tobias Burnus bur...@net-b.de writes:
No, finding libgfortran.spec at compile time works - it is all about
finding it at run time.
pardon me: AFAIK the spec files are *only* used by the compiler driver,
not at runtime of the resulting executables.
while my issue is about
finding the right
On 11/19/2010 03:41 PM, Rainer Orth wrote:
Tobias Burnusbur...@net-b.de writes:
No, finding libgfortran.spec at compile time works - it is all about
finding it at run time.
pardon me: AFAIK the spec files are *only* used by the compiler driver,
not at runtime of the resulting executables.
Hi,
I just finished coding a software implementation of emmintrin.h. It
removes all of the builtins and uses inlined C functions instead. This
is to allow SSE2 based code to run, albeit slowly, on machines without
SSE2 support. I am looking for a program, script, or whatever that can
be used
Yes, if all the people who want only one set of libraries agree on what
that set shall be (or this can be selected with existing configure flags),
this is the simplest way.
Yes, this can be selected at configure time with --with-cpu and --with-float.
The default configuration is also
The Go frontend is nearly ready to merge to mainline. It is pending
approval of these patches to the build machinery:
Set poststage1_ldflags for all builds:
http://gcc.gnu.org/ml/gcc-patches/2010-11/msg01639.html
Add Go support to top level configure/make:
Daniel,
How do you see this impacting the sparc-rtems target?
We have v7/v8 with HW and SW FP multilibs now and
leon is important to us. :-D
--joel
On 11/19/2010 10:53 AM, Eric Botcazou wrote:
Yes, if all the people who want only one set of libraries agree on what
that set shall be (or this
Hello,
I have been struggling with GCC's restrict implementation. One question is:
should restrictness be preserved over function inlining? For example, in
the following code:
static int store_int (int *a, int data)
{
*a = data;
}
void foo (int * __restrict a, int *__restrict b)
{
int
How do you see this impacting the sparc-rtems target?
We have v7/v8 with HW and SW FP multilibs now and
leon is important to us. :-D
Note that LEON will also be available as mere default cpu, i.e. you'll be able
to configure sparc-rtems --with-tune=leon. The new multilib stuff is for the
On Tue, Nov 16, 2010 at 06:23:32AM -0800, Ian Lance Taylor wrote:
Joern Rennecke amyl...@spamcop.net writes:
Before I go and make all these target changes test them, is there at
least agreemwent that this is the right approach, i.e replacing
CUMULATIVE_ARG *
with void *, and splitting up
Quoting Joern Rennecke amyl...@spamcop.net:
This is an update to this patch:
http://gcc.gnu.org/ml/gcc-patches/2010-11/msg01769.html
At 160 KB, this patch has become somewhat largish.
The breakdown is approximately 30 KB target independent code, 120 KB
target port code in gcc/config, and 10
David Mathog mat...@caltech.edu writes:
I just finished coding a software implementation of emmintrin.h. It
removes all of the builtins and uses inlined C functions instead. This
is to allow SSE2 based code to run, albeit slowly, on machines without
SSE2 support. I am looking for a
A good optimizing compiler tries hard to preserve restrict aliasing of
a callee function in its inline instance, and this is usually a hard
problem because the use of restrict qualified pointers are now mixed
with the caller context. In many cases, the compiler may choose not
to inline the
On Nov 19, 2010, at 11:53, Eric Botcazou wrote:
Yes, if all the people who want only one set of libraries agree on what
that set shall be (or this can be selected with existing configure flags),
this is the simplest way.
Yes, this can be selected at configure time with --with-cpu and
Bingfeng Mei b...@broadcom.com writes:
Currently, trunk GCC generates following code (compile with
-fschedule-insns -O2). Obviously, restrict is effective here
even with inlining
I am not very good at reading standard text. Does this
behaviour conform to standard?
Yes. The restrict
Ian,
The current gccgo branch (at r166931) fails to bootstrap on
x86_64-apple-darwin10
using...
../gccgo/configure --prefix=/Users/howarth/dist --with-gmp=/sw --with-ppl=/sw
--with-cloog=/sw --with-mpc=/sw --with-libiconv-prefix=/sw --with-system-zlib
--x-includes=/usr/X11R6/include
Ian,
It seems that go-go.c needs to be more portable. This issue apparently was
addressed in gcc/boehm-gc/pthread_stop_world.c with...
/*
* We use signals to stop threads during GC.
*
* Suspended threads wait in signal handler for SIG_THR_RESTART.
* That's more portable than semaphores or
Jack Howarth howa...@bromo.med.uc.edu writes:
The current gccgo branch (at r166931) fails to bootstrap on
x86_64-apple-darwin10
using...
Thanks for trying it. If you fix that problem, you're going to have
other problems too.
Specifically, I know that it's going to fail to create a
On Fri, Nov 19, 2010 at 12:16:43PM -0800, Ian Lance Taylor wrote:
Jack Howarth howa...@bromo.med.uc.edu writes:
The current gccgo branch (at r166931) fails to bootstrap on
x86_64-apple-darwin10
using...
Thanks for trying it. If you fix that problem, you're going to have
other
Jack Howarth howa...@bromo.med.uc.edu writes:
Actually, darwin doesn't use the boehm-gc/pthread_stop_world.c containing
the SIGRTMIN code. There is an entirely separate boehm-gc/darwin_stop_world.c
for the thread handling on darwin. While boehm-gc/pthread_stop_world.c is
compiled on
Hello there,
We have launched a new GCC mirror server offering HTTP access.
http://mirrors-us.seosue.com/gcc/
The server is located in Tampa, FL, United States.
The update is scheduled twice a week.
Thanks in advance for listing us.
---
with best regards,
Peter Vrzak
Epos Media Ltd.
On Fri, Nov 19, 2010 at 01:23:14PM -0800, Ian Lance Taylor wrote:
Jack Howarth howa...@bromo.med.uc.edu writes:
Actually, darwin doesn't use the boehm-gc/pthread_stop_world.c containing
the SIGRTMIN code. There is an entirely separate
boehm-gc/darwin_stop_world.c
for the thread
Jack Howarth howa...@bromo.med.uc.edu writes:
ps Is there a list of targets that the go compiler has been built on?
It's been built and tested on x86 and x86_64 GNU/Linux and RTEMS.
Ian
Il 17/11/2010 21.06, Tobias Burnus ha scritto:
Why does everyone think that I and Fortran have something to do with it
if something breaks?* ;-)
The issue is known and a fix, which seemingly works on Darwin, exists.
See: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46510
Angelo Graziosi wrote:
On Fri, Nov 19, 2010 at 10:46 PM, Ian Lance Taylor i...@google.com wrote:
Jack Howarth howa...@bromo.med.uc.edu writes:
ps Is there a list of targets that the go compiler has been built on?
It's been built and tested on x86 and x86_64 GNU/Linux and RTEMS.
Huh, I wonder why we have frontends
Richard Guenther richard.guent...@gmail.com writes:
Huh, I wonder why we have frontends that do not even build for all
primary hosts.
Because the perfect is the enemy of the good.
Btw, bugzilla needs a Go and a libgo component.
Yes, it's on the list for after the merge, following Joseph
On Fri, Nov 19, 2010 at 01:23:14PM -0800, Ian Lance Taylor wrote:
Jack Howarth howa...@bromo.med.uc.edu writes:
Actually, darwin doesn't use the boehm-gc/pthread_stop_world.c containing
the SIGRTMIN code. There is an entirely separate
boehm-gc/darwin_stop_world.c
for the thread
Jack Howarth howa...@bromo.med.uc.edu writes:
where you have...
void
__go_scanstacks (void (*scan) (unsigned char *, int64_t))
in gccgo/libgo/runtime/go-go.c but...
void__go_scanstacks(void (*scan)(byte *, int64));
in gccgo/libgo/runtime/runtime.h.
Thanks. I don't know why this
On Fri, Nov 19, 2010 at 03:59:40PM -0800, Ian Lance Taylor wrote:
Jack Howarth howa...@bromo.med.uc.edu writes:
where you have...
void
__go_scanstacks (void (*scan) (unsigned char *, int64_t))
in gccgo/libgo/runtime/go-go.c but...
void__go_scanstacks(void (*scan)(byte *,
Jack Howarth howa...@bromo.med.uc.edu writes:
Actually that wasn't the fix. The change...
void
-__go_scanstacks (void (*scan) (byte *, int64_t))
+__go_scanstacks (void (*scan) (unsigned char *, int64))
Thanks. Sorry for misunderstanding. I committed the change from
int64_t to int64.
Hi,
On Fri, Nov 19, 2010 at 2:55 PM, Jack Howarth howa...@bromo.med.uc.edu wrote:
Ian,
The current gccgo branch (at r166931) fails to bootstrap on
x86_64-apple-darwin10
using...
../gccgo/configure --prefix=/Users/howarth/dist --with-gmp=/sw --with-ppl=/sw
--with-cloog=/sw
Hi,
On Fri, Nov 19, 2010 at 10:17 PM, Arnaud Lacombe lacom...@gmail.com wrote:
Hi,
On Fri, Nov 19, 2010 at 2:55 PM, Jack Howarth howa...@bromo.med.uc.edu
wrote:
Ian,
The current gccgo branch (at r166931) fails to bootstrap on
x86_64-apple-darwin10
using...
../gccgo/configure
Hi,
On Fri, Nov 19, 2010 at 10:43 PM, Arnaud Lacombe lacom...@gmail.com wrote:
ok, this last one is a classic use of non-standard extension of GNU
sed I should be able to fix it. It might not be clean, though.
Here we go, most redefinition fixed by the attached patch.
Remaining error are:
* Arnaud Lacombe wrote on Sat, Nov 20, 2010 at 05:58:13AM CET:
--- a/libgo/mksysinfo.sh
+++ b/libgo/mksysinfo.sh
@@ -79,7 +79,7 @@ grep '^const _E' gen-sysinfo.go | \
# The O_xxx flags.
grep '^const _\(O\|F\|FD\)_' gen-sysinfo.go | \
- sed -e 's/^\(const \)_\(\(O\|F\|FD\)_[^=
Hi,
On Fri, Nov 19, 2010 at 11:58 PM, Arnaud Lacombe lacom...@gmail.com wrote:
[...]
continuing to dig for other errors.
One nits; is there any reason to use `__xpg_strerror_r()' which is not
POSIX, versus 'strerror_r()' [0] ?
// FIXME: The name is only right for glibc.
func
Hi,
On Fri, Nov 19, 2010 at 11:58 PM, Arnaud Lacombe lacom...@gmail.com wrote:
sysinfo.go:2874:13: error: use of undefined type 'func___sighandler_t'
gen-sysinfo.go has :
// type ___sighandler_t func*(int32)
It may not like the * as the following:
package main
import fmt
type ___sighandler_t
Hi,
On Fri, Nov 19, 2010 at 5:55 PM, Richard Guenther
richard.guent...@gmail.com wrote:
On Fri, Nov 19, 2010 at 10:46 PM, Ian Lance Taylor i...@google.com wrote:
Jack Howarth howa...@bromo.med.uc.edu writes:
ps Is there a list of targets that the go compiler has been built on?
It's been
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40436
Jan Hubicka hubicka at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |WAITING
---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46554
Summary: Less inlining leads to CSiBE regression
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46555
Summary: PHI RTL expansion leads to CSiBE regression
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46547
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46547
--- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2010-11-19
08:46:46 UTC ---
Actually, reading that comment again it, the conversion warnings are probably
emitted during convert_for_assignment and thus the earlier c_fully_fold is
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46526
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46556
Summary: Code size regression in struct access
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46526
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jason at gcc dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46523
--- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2010-11-19
09:47:19 UTC ---
Created attachment 22453
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22453
reduced testcase
autoreduced testcase.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46526
--- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2010-11-19
09:55:10 UTC ---
Created attachment 22454
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22454
gcc46-pr46526.patch
Possible fix. Not sure how often C++ FE tries to modify
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46526
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46297
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46535
--- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2010-11-19
10:17:03 UTC ---
Created attachment 22455
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22455
reduced testcase
Reduced with
Index: gcc/ipa-inline.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46535
--- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2010-11-19
10:18:02 UTC ---
It looks like we are inlining a recursive virtual call and get confused in
that process.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46557
Summary: [4.6 Regression] ICE in
cgraph_will_be_removed_from_program_if_no_direct_calls
, at cgraph.c:2820
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46557
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45789
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46552
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46554
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46555
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
I thought partial inlining would maybe fix this? Otherwise it's really a
case that needs IP analysis.
Not with -Os, we really know that it will optimize away.
Honza
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46554
--- Comment #2 from Jan Hubicka hubicka at ucw dot cz 2010-11-19 10:57:57 UTC
---
I thought partial inlining would maybe fix this? Otherwise it's really a
case that needs IP analysis.
Not with -Os, we really know that it will optimize away.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46544
--- Comment #2 from Sebastian Mach phresnel at gmail dot com 2010-11-19
11:13:49 UTC ---
(In reply to comment #1)
Thanks for clarifiying.
As you can clearly see
It wasn't that clear to me. As a user of g++ and C++, and as a programmer, I am
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46544
--- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2010-11-19
11:20:17 UTC ---
I understand ;) As a general rule, if you see in the code mentioned a DR XXX.
YYY, with _GLIBCXX_RESOLVE_LIB_DEFECTS before, it means we are
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45789
--- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2010-11-19
11:57:26 UTC ---
Author: rguenth
Date: Fri Nov 19 11:57:21 2010
New Revision: 166936
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=166936
Log:
2010-11-19 Richard
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45789
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46558
Summary: dbgcnt.c messages not marked for translation
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
AssignedTo:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46559
Summary: libstdc++ link FAILs with -flto
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Keywords: lto
Severity: normal
Priority: P3
Component: middle-end
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46547
--- Comment #6 from joseph at codesourcery dot com joseph at codesourcery dot
com 2010-11-19 13:01:35 UTC ---
My inclination is that the problem is a missing check of
in_late_binary_op. Specifically, that c_common_truthvalue_conversion
should
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46560
Summary: libstdc++ execute FAILs with -flto
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Keywords: lto, wrong-code
Severity: normal
Priority: P3
Component:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46561
Summary: [4.6 Regression] -fcompare-debug failure (length) with
-O2 -ftree-vectorize -ftree-parallelize-loops
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46544
--- Comment #4 from Sebastian Mach phresnel at gmail dot com 2010-11-19
13:12:10 UTC ---
(In reply to comment #3)
As a general rule, if you see in the code mentioned a DR XXX.
YYY, with _GLIBCXX_RESOLVE_LIB_DEFECTS before, it means we are
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46558
--- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2010-11-19
13:16:04 UTC ---
Hm. debug counters are for debugging only thus I don't think we need to
translate strings there (much as we don't translate comments in GCC code
or stuff
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46561
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46547
--- Comment #7 from H.J. Lu hjl.tools at gmail dot com 2010-11-19 13:18:21
UTC ---
It is caused by revision 46547:
http://gcc.gnu.org/ml/gcc-cvs/2009-03/msg00761.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46547
--- Comment #8 from H.J. Lu hjl.tools at gmail dot com 2010-11-19 13:18:55
UTC ---
It is caused by revision 145254:
http://gcc.gnu.org/ml/gcc-cvs/2009-03/msg00761.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46558
--- Comment #2 from joseph at codesourcery dot com joseph at codesourcery dot
com 2010-11-19 13:22:23 UTC ---
On Fri, 19 Nov 2010, rguenth at gcc dot gnu.org wrote:
Hm. debug counters are for debugging only thus I don't think we need to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43925
Rainer Orth ro at gcc dot gnu.org changed:
What|Removed |Added
Target|mips-sgi-irix6.5|mips-sgi-irix6.5,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46510
--- Comment #16 from Jack Howarth howarth at nitro dot med.uc.edu 2010-11-19
13:48:45 UTC ---
I can confirm that removing the gcc_assert (!DECL_EXTERNAL (decl)) as suggested
in comment 8 does eliminate the bootstrap failures without regressions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46561
H.J. Lu hjl.tools at gmail dot com changed:
What|Removed |Added
CC||irar at il dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46557
H.J. Lu hjl.tools at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46562
Summary: CCP currently needs iteration for a[i]
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46562
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46549
Ralf Wildenhues rwild at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45888
Ralf Wildenhues rwild at gcc dot gnu.org changed:
What|Removed |Added
CC||anhvofrcaus at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46562
--- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2010-11-19
15:57:32 UTC ---
SCCVN also fails to recognize a[i_1] as constant.
I'll add a get_addr_base_and_unit_offset variant with a callback to valueize
SSA names. That should
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46563
Summary: link with -lgcc when creating a shared lib
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: driver
AssignedTo:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46563
--- Comment #1 from christophe.lyon at st dot com 2010-11-19 16:05:16 UTC ---
Created attachment 22458
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22458
shared lib C++ source
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46563
--- Comment #2 from Andrew Haley aph at gcc dot gnu.org 2010-11-19 16:09:00
UTC ---
If you try linking with -lgcc_s -lgcc, does everything then work?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46564
Summary: [4.6 Regression] ICE: in decl_constant_var_p, at
cp/decl2.c:3562 on invalid recursive initialization
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46563
--- Comment #3 from christophe.lyon at st dot com 2010-11-19 16:12:11 UTC ---
Yes. I did find this workaround myself, but I was very surprised I had to do it
manually.
(As I said, the problem arised when building QT, and I guess I'm not the first
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45830
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46565
Summary: [4.5/4.6 Regression] ICE: SIGSEGV in pop_tinst_level
(pt.c:7513) with -gstabs -g on invalid code
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46565
Zdenek Sojka zsojka at seznam dot cz changed:
What|Removed |Added
Keywords||ice-on-invalid-code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46563
Mikael Pettersson mikpe at it dot uu.se changed:
What|Removed |Added
CC||mikpe at it dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46563
--- Comment #5 from christophe.lyon at st dot com 2010-11-19 16:49:05 UTC ---
I am not sure what you mean about libgcc_s.so linker script.
But I think the difference is that I am cross-compiling.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46547
Joseph S. Myers jsm28 at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46563
--- Comment #6 from Andrew Haley aph at gcc dot gnu.org 2010-11-19 17:30:35
UTC ---
I am cross-compiling too.
Try this:
$ cat /home/aph/x-arm/install/arm-linux-gnueabi/lib/libgcc_s.so
/* GNU ld script
Use the shared library, but some
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46563
--- Comment #7 from Mikael Pettersson mikpe at it dot uu.se 2010-11-19
17:38:35 UTC ---
The example works for me also with a cross built from gcc-4.5.1 with
--enable-shared --enable-languages=c,c++.
armv5tel-unknown-linux-gnueabi-g++ atomic.cxx
1 - 100 of 156 matches
Mail list logo
