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.
>
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 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_
* 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 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:
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 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-
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
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:
> 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 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.
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 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
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:
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
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.
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.
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
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:
>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
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
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
"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
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
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
"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
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
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
> 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
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
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
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
> 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
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
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
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
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
"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 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
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
>> (`.
> 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
41 matches
Mail list logo
