> 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
Ralf Wildenhues 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 libraries
>> (`.
Quoting Eric Botcazou :
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 t
"H.J. Lu" 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 :
"H.J. Lu" 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 case this is a form of the halti
Tobias Burnus 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 (64-bit) li
On 11/19/2010 03:41 PM, Rainer Orth wrote:
Tobias Burnus 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.
Well, the spec fi
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 to
> 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 straig
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:
http://gcc.gnu.org/ml/gcc-patches/2
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 c
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 da
> 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 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 x_rtl int
Quoting Joern Rennecke :
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 KB ChangeLog, most o
"David Mathog" 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 program, script, or
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 functio
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" 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 qualifier promise
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 --x-libr
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 c
Jack Howarth 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 .go_export
section because
On Fri, Nov 19, 2010 at 12:16:43PM -0800, Ian Lance Taylor wrote:
> Jack Howarth 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.
>
Jack Howarth 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 darwin, the code in it is s
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 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.
Jack Howarth 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 wrote:
> Jack Howarth 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 that do not even build for all
pri
Richard Guenther 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 Myers's
checklist. Thanks
On Fri, Nov 19, 2010 at 01:23:14PM -0800, Ian Lance Taylor wrote:
> Jack Howarth 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.
Jack Howarth 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 causes an error o
On Fri, Nov 19, 2010 at 03:59:40PM -0800, Ian Lance Taylor wrote:
> Jack Howarth 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));
>
Jack Howarth 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.
> /var/tmp//ccVFZHcc
Hi,
On Fri, Nov 19, 2010 at 2:55 PM, Jack Howarth 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 --with-mpc=/sw --with-libiconv-
Hi,
On Fri, Nov 19, 2010 at 10:17 PM, Arnaud Lacombe wrote:
> Hi,
>
> On Fri, Nov 19, 2010 at 2:55 PM, Jack Howarth
> wrote:
>> Ian,
>> The current gccgo branch (at r166931) fails to bootstrap on
>> x86_64-apple-darwin10
>> using...
>>
>> ../gccgo/configure --prefix=/Users/howarth/dist --wit
Hi,
On Fri, Nov 19, 2010 at 10:43 PM, Arnaud Lacombe 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:
sysinfo.go:3034:6:
* 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 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 libc_strerror_r(int, *byte, Size_
Hi,
On Fri, Nov 19, 2010 at 11:58 PM, Arnaud Lacombe 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 func(int32)
fu
Hi,
On Fri, Nov 19, 2010 at 5:55 PM, Richard Guenther
wrote:
> On Fri, Nov 19, 2010 at 10:46 PM, Ian Lance Taylor wrote:
>> Jack Howarth 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.
>
41 matches
Mail list logo
