date:20101119

Re: Adding Leon processor to the SPARC list of processors

2010-11-19 Thread 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 there is a simple way to achieve both multilib and singlelib?

You can pass --disable-multilib at configure time.

-- 
Eric Botcazou

Re: Boostrap fails on i386-pc-solaris2.10 - libquadmath error

2010-11-19 Thread Rainer Orth

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
>>   (`.la') to add to LIBRARY.
>> 
>>  The `LIBRARY_LDFLAGS' variable is the place to list additional
>>   libtool linking flags, such as `-version-info', `-static', and a lot
>>   more.  *Note Link mode: (libtool)Link mode.
>> 
>> There's nothing about external libraries specified with just -l in
>> the first sentence about _LIBADD.
>
> Well, later, in `Program and Library Variables', there is:
>
>  `_LDADD' and `_LIBADD' are inappropriate for passing
>  program-specific linker flags (except for `-l', `-L', `-dlopen'
>  and `-dlpreopen').  Use the `_LDFLAGS' variable for this purpose.
>
> which hints at that -l is OK here.  But independently of what's in the
> Automake manual, it is impossible to solve the ordering issues for
> static linking at the autotools level if -l can not be passed to
> _LIBADD, so we should improve the Automake manual if that is not
> explicit enough.

I'd appreciate that.

>> As I said, I could be persuaded to change this, but right now my primary
>> interest is to get Solaris back to bootstrap land ASAP, and with less
>> than 13000 testsuite failures ;-(
>
> Does this have to do anything with the issue at hand?

The -lm in _LIBADD currently breaks the bootstrap.  Unless there are
strong objections, I'll shortly commit a patch to move it to _LDFLAGS
for the time being (and fix the various issues with the quadmath.map-sun
target at the same time).

The testsuite failures are caused by some change in gcc/testsuite/lib;
haven't yet looked which one.

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: Adding Leon processor to the SPARC list of processors

2010-11-19 Thread Joern Rennecke


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 there is a simple way to achieve both multilib and singlelib?


You can pass --disable-multilib at configure time.


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.

But once you have different people wanting a different single library, this
approach is not longer sufficient.
Also, it might happen that someone doesn't want one multilib dimension, but
they want to keep another one.
E.g. they might say they don't want to support these different
architecture variants, but they need support for both endiannesses (Or you
might hear: hard and soft float, or glibc and uClibc.)

Re: How can I tell if BB can reach EXIT_BLOCK_PTR?

2010-11-19 Thread 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.

Ian

Re: How can I tell if BB can reach EXIT_BLOCK_PTR?

2010-11-19 Thread Joern Rennecke


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 halting problem.

E.g. it is not generally correct to move an idempotent side effect out of a
loop to a postdominator; you first have to prove that the loop terminates.

Re: Boostrap fails on i386-pc-solaris2.10 - libquadmath error

2010-11-19 Thread Rainer Orth

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) libgcc_s.so.1 at runtime, due to a bug in the
>> construction of LD_LIBRARY_PATH in the testsuite.  This worked before
>> and is broken now, due to the libquadmath patch.
>
> I am not sure the bug is the same, but they are related. Both are about
> finding the .spec file at run time; once for the installed system and once

No, they are not: LD_LIBRARY_PATH is only relevant for finding shared
objects at runtime and completely irrelevant to the compiler driver's
search for .spec files.

> for the test-suite run. My plan is first to fix the first issue, namely
> where the compiler searches for the library and then to revisit the test
> suite issue.
>
> The changes made can be shown via:
>svn diff -r166824:166825 gcc/testsuite/lib/gfortran.exp
>
> The changes are needed if the compiler is not installed, i.e. the libraries
> are only in the build directory. In this case "gfortran" (the driver) needs
> to be able to find the libgfortran.spec file based on the passed
> -L. The patch (cf. svn diff) is doing this, but seems to break the
> test suite in some cases.

>From a quick look, there seem to be several problems:

* libquadmath/.libs is added with -L and to LD_LIBRARY_PATH both if
  libquadmath.a and again if libquadmath.${shlib_ext} exist.  This would
  explain why we see the unnecessary doubling of libquadmath/.libs in
  LD_LIBRARY_PATH.

* Unfortunately, this doesn't take the multilib subdir into account,
  which is wrong for the non-default multilib.

* Something seems to have been broken wrt. to
  gcc-set-multilib-library-path since, as I wrote, gcc/amd64 isn't added
  to LD_LIBRARY_PATH, which breaks all execution tests for the
  non-default multilibs.

I'll further check what's going on here, adding a couple of log
statements to investigate.

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: Boostrap fails on i386-pc-solaris2.10 - libquadmath error

2010-11-19 Thread Tobias Burnus

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 files are used only by the driver - and neither by the
proper compiler (f951, cc1, etc.) nor by the generated executable.
However, besides the compiled in files, the driver also reads spec files
when it is run. That happens, e.g., for linking OpenMP (-fopenmp) or
since the addition of libquadmath for running "gfortran". See your self:
Run:

echo "end" > test.f90
gfortran -v -fopenmp test.f90 2>&1 |grep -i spec

On my system that gives:

Using built-in specs.
Reading specs from
/projects/tob/gcc-trunk/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../libgfortran.spec

rename spec lib to liborig
Reading specs from
/projects/tob/gcc-trunk/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../lib64/libgomp.spec

[Side note: See the /lib/ instead of /lib64/? That's the driver bug I am
talking about.]

And the compiler driver ("gfortran") needs to find the libgfortran.spec
file - otherwise, it simply aborts with an error message. As the
compiler might not be installed, if one runs the test suite, the .spec
file needs to be found by the compiler, e.g., by adding -L to
the .spec file.

No, they are not: LD_LIBRARY_PATH is only relevant for finding shared
objects at runtime and completely irrelevant to the compiler driver's
search for .spec files.

Well, the LD_LIBRARY_PATH is not wrong because of the .spec file itself.
However, it is seemingly wrong because of a side effect in the patch
makes sure that the .spec file is found -- or because something goes
wrong with finding libquadmath. In any case, without the patch
"gfortran" simply aborts - that the LD_LIBRARY_PATH is correct, does not
help then.

The changes made can be shown via:
svn diff -r166824:166825 gcc/testsuite/lib/gfortran.exp

> From a quick look, there seem to be several problems:

* libquadmath/.libs is added with -L and to LD_LIBRARY_PATH both if
libquadmath.a and again if libquadmath.${shlib_ext} exist. This would
explain why we see the unnecessary doubling of libquadmath/.libs in
LD_LIBRARY_PATH.

Granted. Though, shouldn't that also occur for libgfortran.*? Those
lines are copied from above.

* Unfortunately, this doesn't take the multilib subdir into account,
which is wrong for the non-default multilib.

I am not sure how it works for libgfortran (in the lines before
libquadmath). But as written, in terms of the .spec file there is also a
bug with regards to the driver, which I would like to fix first before
looking at the issues in gcc/testsuite/lib.

Tobias

Method to test all sse2 calls?

2010-11-19 Thread David Mathog

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 test all 200 odd _mm_* SSE2 functions to make sure that they
actually work right.  Presumably such a thing must be included in the
gcc distribution, so that a new build can be verified to work properly.
 However I have no clue where it would be or how to use it.  Can
somebody please point me in the right direction?

Thank you,

David Mathog
mat...@caltech.edu
Manager, Sequence Analysis Facility, Biology Division, Caltech

Re: Adding Leon processor to the SPARC list of processors

2010-11-19 Thread Eric Botcazou

> 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 straightforward: LEON is an implementation 
of the SPARC-V8 architecture so --with-cpu=v8 and --with-float=hard.

> Also, it might happen that someone doesn't want one multilib dimension, but
> they want to keep another one.

Indeed, being able to partially disable multilibs would be nice.

-- 
Eric Botcazou

Go frontend merge status

2010-11-19 Thread Ian Lance Taylor

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/2010-11/msg01963.html


Add Go support to config-ml.in:

http://gcc.gnu.org/ml/gcc-patches/2010-11/msg02033.html


Joseph Myers has reviewed the code in gcc/go.  Ralf Wildenhaus has
reviewed the libgo Makefile.am and configure.ac.

I believe that I have addressed all comments I've seen so far about the
merge.  The only possibly outstanding one that I can find regards the
coding conventions.  The intent of the code is to follow the conventions
at http://gcc.gnu.org/wiki/CppConventions , though those have admittedly
not been finalized, except that no space is used between a function name
and a left parenthesis.


If anybody would care to review the rest of the libgo directory outside
of the libgo/go subdirectory, that would be helpful.

Besides the new gcc/go and libgo directories, there are also three new
files in gcc/testsuite/lib: go.exp, go-torture.exp, and go-dg.exp, and
there are three new directories in gcc/testsuite: go.go-torture, go.dg,
and go.test.


I don't plan to send out any more individual patches for approval.  My
plan is to commit the rest of the Go code to mainline shortly after the
above three build machinery patches are approved.  Please let me know if
you have any objections to this plan.

Ian

Re: Adding Leon processor to the SPARC list of processors

2010-11-19 Thread Joel Sherrill


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 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 straightforward: LEON is an implementation
of the SPARC-V8 architecture so --with-cpu=v8 and --with-float=hard.


Also, it might happen that someone doesn't want one multilib dimension, but
they want to keep another one.

Indeed, being able to partially disable multilibs would be nice.




--
Joel Sherrill, Ph.D. Director of Research&  Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available (256) 722-9985

Should "restrictness" be preserved over function linling and casting?

2010-11-19 Thread Bingfeng Mei

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 data;
  data = *b;
  store_int (a, b);
  data = *(b+1);
  store_int (a, b + 1);
}

Currently, trunk GCC generates following code (compile with
-fschedule-insns -O2). Obviously, restrict is effective here
even with inlining

foo:
.LFB1:
movl(%rsi), %edx
movl4(%rsi), %eax
movl%edx, (%rdi)
movl%eax, 4(%rdi)
ret

I am not very good at reading standard text. Does this
behaviour conform to standard?

Additionally, should "restrictness" be preserved over casting?
If I modify store_int to as follows (store 64-bit now).

static int store_int (int *a, int data)
{
  *(long long *)a = data;
}

GCC generates code that "restrict" is still effective. 
foo:
.LFB1:
movslq  (%rsi), %rdx
movslq  4(%rsi), %rax
movq%rdx, (%rdi)
movq%rax, 4(%rdi)
ret

Does this conform to standard?

Cheers,
Bingfeng

Re: Adding Leon processor to the SPARC list of processors

2010-11-19 Thread Eric Botcazou

> 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 
default target sparc-leon-elf (and maybe sparc-leon-linux if we want one).

-- 
Eric Botcazou

Re: RFC: semi-automatic hookization

2010-11-19 Thread Nathan Froyd

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 into two variables.
> 
> I don't know how we want to get there, but it seems to me that the place
> we want to end up is with the target hooks defined to take an argument
> of type struct cumulative_args * (or a better name if we can think of
> one).  We could consider moving the struct definition into CPU.c, and
> having the target structure just report the size, or perhaps a combined
> allocation/INIT_CUMULATIVE_ARGS function.

FWIW, this is basically what I proposed here:

http://gcc.gnu.org/ml/gcc-patches/2010-06/msg02527.html

I have gotten stalled on the INIT_* macros because the documentation and
the practices of individual backends do not seem to agree and I have not
taken the time to sit down and hammer out agreement.  (I don't think
attempting hookization of those macros would be appropriate for stage
3.)  I was a little uncertain how to handle the allocation issues; I
think specifying that the INIT_* hooks allocate them from a known place
(heap, obstack, or alloc_pool) is probably sufficient.

-Nathan

P.S.: Updated: RFA: Fix middle-end/46500 (void * encapsulated)

2010-11-19 Thread Joern Rennecke


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 of which is for
the target port code, too.

If it helps the review process, I could decouple the middle-end end the
target part, by checking config/${cpu_type}/${cpu_type}.c if it mentions
cumulative_args_t, and set a macro if that is the case.

Then for unconverted ports, target.h can continue to include "tm.h" and do:
typedef CUMULATIVE_ARGS *cumulative_args_t;

to provide backward compatibility.

Re: Method to test all sse2 calls?

2010-11-19 Thread Ian Lance Taylor

"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 whatever that can
> be used to test all 200 odd _mm_* SSE2 functions to make sure that they
> actually work right.  Presumably such a thing must be included in the
> gcc distribution, so that a new build can be verified to work properly.
>  However I have no clue where it would be or how to use it.  Can
> somebody please point me in the right direction?

I admire your respect for our software engineering processes.  I hope it
is warranted.

The tests you are looking for is in gcc/testsuite/gcc.target/i386.  The
tests are driven by the DejaGNU driver script i386.exp in that
directory.

Ian

Re: Should "restrictness" be preserved over function linling and casting?

2010-11-19 Thread Xinliang David Li

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 function.

The above does apply to your case. Ininling of store_int into foo is
irrelevant to the aliasing attribute here.

David

On Fri, Nov 19, 2010 at 9:12 AM, Bingfeng Mei  wrote:
> 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 data;
>  data = *b;
>  store_int (a, b);
>  data = *(b+1);
>  store_int (a, b + 1);
> }
>
> Currently, trunk GCC generates following code (compile with
> -fschedule-insns -O2). Obviously, restrict is effective here
> even with inlining
>
> foo:
> .LFB1:
>        movl    (%rsi), %edx
>        movl    4(%rsi), %eax
>        movl    %edx, (%rdi)
>        movl    %eax, 4(%rdi)
>        ret
>
> I am not very good at reading standard text. Does this
> behaviour conform to standard?
>
> Additionally, should "restrictness" be preserved over casting?
> If I modify store_int to as follows (store 64-bit now).
>
> static int store_int (int *a, int data)
> {
>  *(long long *)a = data;
> }
>
> GCC generates code that "restrict" is still effective.
> foo:
> .LFB1:
>        movslq  (%rsi), %rdx
>        movslq  4(%rsi), %rax
>        movq    %rdx, (%rdi)
>        movq    %rax, 4(%rdi)
>        ret
>
> Does this conform to standard?
>
> Cheers,
> Bingfeng
>
>

Re: Adding Leon processor to the SPARC list of processors

2010-11-19 Thread Geert Bosch

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 --with-float.
> 
> The default configuration is also straightforward: LEON is an implementation 
> of the SPARC-V8 architecture so --with-cpu=v8 and --with-float=hard.

There is LEON2, which is V7, and LEON3/LEON4, which are V8.
While LEON3 can support all of V8 in hardware, LEON3 is a 
configurable system-on-a-chip, targetting both FPGAs and ASICs, 
where users can configure and  synthesize different aspects of
the CPU:

* CONFIG_PROC_NUM: The number of processor cores.

* CONFIG_IU_V8MULDIV: Implements V8 multiply and divide instructions
  UMUL, UMULCC, SMUL, SMULCC, UDIV, UDIVCC, SDIV, SDIVCC.
  Costs about 8k gates.

* CONFIG_IU_MUL_MAC: Implements the SPARC V8e UMAC/SMAC
  (multiply-accumulate) instructions with a 40-bits accumulator

* CONFIG_FPU_ENABLE: Enable or disable floating point unit

Apart from these settings that determine wether instructions are
present at all, other settings allow selection of FPU implementation
(trading off between cycle count, area and timing), such as:

* CONFIG_IU_MUL_LATENCY_2: Implementation options for the integer multiplier.
  TypeImplementation  issue-rate/latency
  2-clocks32x32 pipelined multiplier 1/2 
  4-clocks16x16 standard multiplier  4/4
  5-clocks16x16 pipelined multiplier 4/5

* CONFIG_IU_LDELAY: One cycle load delay for best performance, or 2-cycles
  to improve timing at the cost of about 5% reduced performance.

CONFIG_FPU_ENABLE Y/N would correspond to --with-float=hard/soft, and
I believe setting CONFIG_IU_V8MULDIV to Y/N requires --with-cpu=V8/V7,
is that correct? I think it would make sense to build these as multilibs,
so the user can experiment to find out performance impacts of
the various hardware configurations on generated code.

I wonder if it also would be worthwhile to have compiler options
for fpu=fast/slow and multiply=fast/slow, so we can schedule
appropriately. For the FPU, issue-rate/latency are as follows:
  GR FPU:  1/4, with FDIV? 16 and FSQRT? 24 cycles,
non-pipelined on separate unit
  GR FPU Lite: 8/8, with FDIVS/FDIVD/FSQRTS/FSQRTD 31/57/46/57 cycles,
non-pipelined on same unit

While the FPU Lite is not pipelined, integer instructions can be
executed in parallel with a FPU instruction as long as no new FPU
instructions are pending.

  -Geert

Re: Should "restrictness" be preserved over function linling and casting?

2010-11-19 Thread Ian Lance Taylor

"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 promises that a function will not modify
the data to which the pointer points by using a different unrelated
pointer (a pointer which is not based on the restricted pointer, as
defined in C99 6.7.3.1).  That holds throughout the function, even if
the function calls other functions.

> Additionally, should "restrictness" be preserved over casting?

> GCC generates code that "restrict" is still effective. 
> foo:

> Does this conform to standard?

Yes.  Casting a restrict qualified pointer gives you a value based on
the restricted pointer.  It is still true that the data to which it
points may not be modified by an unrelated pointer.

Ian

gccgo branch and darwin

2010-11-19 Thread Jack Howarth

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-libraries=/usr/X11R6/lib 
--enable-languages=c,go --enable-checking=yes

This bootstrap fails at...

libtool: compile:  /Users/howarth/darwin_objdir/./gcc/xgcc 
-B/Users/howarth/darwin_objdir/./gcc/ 
-B/Users/howarth/dist/x86_64-apple-darwin10.5.0/bin/ 
-B/Users/howarth/dist/x86_64-apple-darwin10.5.0/lib/ -isystem 
/Users/howarth/dist/x86_64-apple-darwin10.5.0/include -isystem 
/Users/howarth/dist/x86_64-apple-darwin10.5.0/sys-include -DHAVE_CONFIG_H -I. 
-I../../../gccgo/libgo -I ../../../gccgo/libgo/runtime 
-I../../../gccgo/libgo/../libffi/include -I../libffi/include -pthread 
-fexceptions -fplan9-extensions -Wall -Wextra -Wwrite-strings -Wcast-qual 
-Werror -minline-all-stringops -I ../../../gccgo/libgo/../gcc -I 
../../gcc/include -g -O2 -MT go-eface-compare.lo -MD -MP -MF 
.deps/go-eface-compare.Tpo -c ../../../gccgo/libgo/runtime/go-eface-compare.c 
-o go-eface-compare.o >/dev/null 2>&1
../../../gccgo/libgo/runtime/go-go.c: In function ‘runtime_stoptheworld’:
../../../gccgo/libgo/runtime/go-go.c:379:29: error: ‘SIGRTMIN’ undeclared 
(first use in this function)
../../../gccgo/libgo/runtime/go-go.c:379:29: note: each undeclared identifier 
is reported only once for each function it appears in
../../../gccgo/libgo/runtime/go-go.c: At top level:
../../../gccgo/libgo/runtime/go-go.c:431:1: error: conflicting types for 
‘__go_scanstacks’
../../../gccgo/libgo/runtime/runtime.h:132:6: note: previous declaration of 
‘__go_scanstacks’ was here
../../../gccgo/libgo/runtime/go-go.c: In function ‘runtime_starttheworld’:
../../../gccgo/libgo/runtime/go-go.c:560:29: error: ‘SIGRTMIN’ undeclared 
(first use in this function)
../../../gccgo/libgo/runtime/go-go.c: In function ‘__go_gc_goroutine_init’:
../../../gccgo/libgo/runtime/go-go.c:612:7: error: ‘SIGRTMIN’ undeclared (first 
use in this function)
../../../gccgo/libgo/runtime/go-go.c:612:7: error: left-hand operand of comma 
expression has no effect [-Werror=unused-value]
../../../gccgo/libgo/runtime/go-go.c:614:7: error: left-hand operand of comma 
expression has no effect [-Werror=unused-value]
../../../gccgo/libgo/runtime/go-go.c:621:7: error: left-hand operand of comma 
expression has no effect [-Werror=unused-value]
../../../gccgo/libgo/runtime/go-go.c:623:7: error: left-hand operand of comma 
expression has no effect [-Werror=unused-value]

Hopefully we can fix this before the merge.
  Jack

RE: gccgo branch and darwin

2010-11-19 Thread Jack Howarth

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 condition variables.
 * (We do use sem_post from a signal handler, but that should be portable.)
 *
 * The thread suspension signal SIG_SUSPEND is now defined in gc_priv.h.
 * Note that we can't just stop a thread; we need it to save its stack
 * pointer(s) and acknowledge.
 */

#ifndef SIG_THR_RESTART
#  if defined(GC_HPUX_THREADS) || defined(GC_OSF1_THREADS)
#ifdef _SIGRTMIN
#  define SIG_THR_RESTART _SIGRTMIN + 5
#else
#  define SIG_THR_RESTART SIGRTMIN + 5
#endif
#  else
#   define SIG_THR_RESTART SIGXCPU
#  endif
#endif

  Jack

41 matches

Mail list logo