headers
Ian Lance Taylor | 1 Apr 2011 01:03
Picon
Favicon
Gravatar

libgo patch committed: Set name of test when using DejaGNU

This libgo patch sets the name of the test correctly when using DejaGNU
to run the libgo testsuite.  Bootstrapped and ran libgo testsuite on
x86_64-unknown-linux-gnu.  Committed to mainline.

Ian
Attachment (foo.patch): text/x-diff, 2280 bytes
Permalink | Reply | 0 comments |
headers
Ian Lance Taylor | 1 Apr 2011 01:04
Picon
Favicon
Gravatar

Re: Fix remaining libgo testsuite failures on Solaris 2

I believe that all of these issues have now been fixed.  Thanks.

Ian

Rainer Orth <ro <at> CeBiTec.Uni-Bielefeld.DE> writes:

> The recent merge of libgo from upstream broke bootstrap with Go on
> Solaris: unless _XOPEN_SOURCE is defined as 400 or above, struct msghdr
> has no msg_control, msg_controllen, and msg_flags members, but uses
> msg_accrights and msg_accrightslen instead.
>
> I've fixed this (and the bootstrap) like this in mksysinfo.sh:
>
> diff -r 77ad95adb9e1 libgo/mksysinfo.sh
> --- a/libgo/mksysinfo.sh	Sun Jan 23 23:05:50 2011 +0100
> +++ b/libgo/mksysinfo.sh	Sun Jan 23 23:08:31 2011 +0100
>  <at>  <at>  -57,7 +57,8  <at>  <at> 
>  #include <unistd.h>
>  EOF
>  
> -${CC} -D_GNU_SOURCE -fdump-go-spec=gen-sysinfo.go -S -o sysinfo.s sysinfo.c
> +#${CC} -D_GNU_SOURCE -fdump-go-spec=gen-sysinfo.go -S -o sysinfo.s sysinfo.c
> +${CC} -std=gnu99 -D_XOPEN_SOURCE=600 -D__EXTENSIONS__ -fdump-go-spec=gen-sysinfo.go -S -o
sysinfo.s sysinfo.c
>  
>  echo 'package syscall' > ${OUT}
>  
> I think we really need to introduce the target_triplet arg to
> mksysinfo.sh again which I already had in my original Solaris libgo
> patch.  I really doubt that we can find macros which make those
(Continue reading)

Permalink | Reply | 0 comments |
headers
Richard Henderson | 1 Apr 2011 01:04
Picon
Favicon

Re: [PATCH 3/6] Allow jumps in epilogues

On 03/31/2011 03:07 PM, Bernd Schmidt wrote:
> No, it's used - but it looks like I forgot to quilt refresh and the
> final.c changes weren't included. New patch below. After this patch, the
> whole function is processed before final, and rather than emitting cfi
> directives immediately, we create these notes which cause the directives
> to be emitted during final.

Ah, much better.  I had wondered what I was missing.

> This probably shouldn't be committed separately when these changes go
> in, as (I think) it breaks -freorder-blocks-and-partition as well as the
> code in i386.c; it's split out simply to show an intermediate stage.

Sure.

> Yes, this falls under "inefficient CFI insns". I wanted to post a
> preliminary proof-of-concept patch set now which generates
> correct(-looking) output, but not necessarily optimized output. Not
> quite sure yet how to tackle this but I'll think of something.

Ok, I'll go ahead and apply all the patches locally and see what the
output actually looks like.  Perhaps I'll have more suggestions.

r~
Permalink | Reply | 0 comments |
headers
Ian Lance Taylor | 1 Apr 2011 01:10
Picon
Favicon
Gravatar

Re: Fix remaining libgo testsuite failures on Solaris 2

I believe that all of these issues have been handled.  Thanks.

Ian

Rainer Orth <ro <at> CeBiTec.Uni-Bielefeld.DE> writes:

> Rainer Orth <ro <at> CeBiTec.Uni-Bielefeld.DE> writes:
>
>> The recent merge of libgo from upstream broke bootstrap with Go on
>> Solaris: unless _XOPEN_SOURCE is defined as 400 or above, struct msghdr
>> has no msg_control, msg_controllen, and msg_flags members, but uses
>> msg_accrights and msg_accrightslen instead.
>>
>> I've fixed this (and the bootstrap) like this in mksysinfo.sh:
>>
>> diff -r 77ad95adb9e1 libgo/mksysinfo.sh
>> --- a/libgo/mksysinfo.sh	Sun Jan 23 23:05:50 2011 +0100
>> +++ b/libgo/mksysinfo.sh	Sun Jan 23 23:08:31 2011 +0100
>>  <at>  <at>  -57,7 +57,8  <at>  <at> 
>>  #include <unistd.h>
>>  EOF
>>  
>> -${CC} -D_GNU_SOURCE -fdump-go-spec=gen-sysinfo.go -S -o sysinfo.s sysinfo.c
>> +#${CC} -D_GNU_SOURCE -fdump-go-spec=gen-sysinfo.go -S -o sysinfo.s sysinfo.c
>> +${CC} -std=gnu99 -D_XOPEN_SOURCE=600 -D__EXTENSIONS__ -fdump-go-spec=gen-sysinfo.go -S -o
sysinfo.s sysinfo.c
>>  
>>  echo 'package syscall' > ${OUT}
>>  
>> I think we really need to introduce the target_triplet arg to
(Continue reading)

Permalink | Reply | 0 comments |
headers
Joseph S. Myers | 1 Apr 2011 01:40

Split up toplevel library-disabling cases

This patch, relative to a tree with
<http://gcc.gnu.org/ml/gcc-patches/2011-03/msg02027.html> (pending
review) applied, continues toplevel configure cleanup by splitting the
disabling of some libraries into separate case statements for those
libraries.  Separating the logic like this brings things closer to the
desired state of this configuration being in fragments in
subdirectories rather than hardcoded directly in the toplevel
configure script, as well as making it easier to clean up this logic
where the directory disabling is not in fact appropriate.

Specifically, this separates out code for target-libssp,
target-libiberty, target-libstdc++-v3 and Fortran, so covering all GCC
target-library or language disabling except that related to Java
(which is most in need of cleanup, but also the most complicated and
so best dealt with separately).

The logic for what is disabled where is kept unchanged - including the
peculiar logic for target-libiberty (sometimes skipdirs is set or
appended to, sometimes noconfigdirs) - where I think the right fix
will end up being removing target-libiberty support completely, but
don't plan to work on that.  The only changes to what would be
disabled where are: two cases, for ip2k-*-* and picochip-*-*, that
disable target-libiberty are moved completely to the separate case
statement (rather than leaving empty cases behind), so in the general
case statement those targets will now fall through to *-*-* and
disable libgcj, which is OK since ip2k-*-* has no GCC support at all
and picochip has no libffi port so can't actually build Java; in the
libstdc++-v3 case statement, the target pattern for disabling
libstdc++-v3 on WinCE was adjusted to match exactly GCC's supported
targets for CE.
(Continue reading)

Permalink | Reply | 5 comments |
headers
Ian Lance Taylor | 1 Apr 2011 01:57
Picon
Favicon
Gravatar

Re: [build] Support libgo on IRIX 6.5 (PR go/47515)

On Thu, Feb 3, 2011 at 7:06 AM, Rainer Orth <ro <at> cebitec.uni-bielefeld.de> wrote:

> 2011-01-30  Rainer Orth  <ro <at> CeBiTec.Uni-Bielefeld.DE>
>
>        PR go/47515
>        * configure.ac (GOOS): Handle *-*-irix6*.
>        * configure: Regenerate.
>        * Makefile.am (go_os_sys_file): Use go/os/sys_uname.go on IRIX.
>        * Makefile.in: Regenerate.
>        * mksysinfo.sh (sysinfo.c) [__sgi__]: Define _XOPEN_SOURCE.
>        [__sgi__]: Include <sys/bsd_types.h>.
>        Allow for _timespec_t, __timespec.
>        * go/debug/proc/proc_irix.go: New file.
>        * syscalls/syscall_irix.go: New file.

I committed this patch.

Thanks, and sorry for the delay.

Ian
Permalink | Reply | 0 comments |
headers
Weddington, Eric | 1 Apr 2011 02:10
Favicon

RE: Split up toplevel library-disabling cases


> -----Original Message-----
> From: Joseph Myers [mailto:joseph <at> codesourcery.com]
> Sent: Thursday, March 31, 2011 5:41 PM
> To: gcc-patches <at> gcc.gnu.org
> Cc: bonzini <at> gnu.org; dj <at> redhat.com; neroden <at> gcc.gnu.org;
> aoliva <at> redhat.com; Ralf.Wildenhues <at> gmx.de; chertykov <at> gmail.com;
> aesok <at> post.ru; Weddington, Eric; dje.gcc <at> gmail.com; eager <at> eagercon.com
> Subject: Split up toplevel library-disabling cases
> 
> Target maintainers: I'd like to understand why it is necessary to
> disable libssp for AVR, AIX and Microblaze, and libstdc++-v3 for AVR
> (and what use C++ is on AVR without libstdc++-v3 - do you use another
> C++ library?).  Note that changing libstdc++-v3/acinclude.m4 to build
> only freestanding libraries for a target may be an alternative to
> disabling libstdc++-v3 completely for that system.  If the libraries
> don't need disabling, they shouldn't be disabled, to keep down the
> amount of ad hoc tests for particular targets at toplevel.  If they do
> need disabling, there should be comments to explain why.

Hi Joseph,

Regarding the AVR port, AFAIK, it's just historical. At one point libssp didn't build for the avr, and we
ended up just disabling it so users could build out of the box. I don't recall anyone seriously looked into it.

Yes, we can an do build the c++ compiler for the avr target, and we do have users using it (with an increasing
number of c++ users). Again, AFAIK, libstc++-v3 has never been able to be built for the avr target, and no,
we are not using another c++ library. It's been on our todo list for years to try and solve the build issues,
but, as usual, it's a time and resource issue.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Ian Lance Taylor | 1 Apr 2011 02:17
Picon
Favicon
Gravatar

libgo patch committed: Recognize MIPS ABIs

This libgo patch recognizes the various MIPS ABIs and sets an
appropriate GOARCH value.  Bootstrapped on x86_64-unknown-linux-gnu.
Committed to mainline.

Ian
Attachment (foo.patch): text/x-diff, 1861 bytes
Permalink | Reply | 0 comments |
headers
Ian Lance Taylor | 1 Apr 2011 02:28
Picon
Favicon
Gravatar

Go testsuite patch committed: Recognize MIPS ABIs

This patch to the Go testsuite driver recognizes the MIPS ABIs.  Ran Go
testsuite on x86_64-unknown-linux-gnu.  Committed to mainline.

Ian

2011-03-31  Ian Lance Taylor  <iant <at> google.com>

	* go.test/go-test.exp (go-set-goarch): Recognize MIPS ABIs.
Attachment (foo.patch): text/x-diff, 1032 bytes
Permalink | Reply | 0 comments |
headers
Jerry DeLisle | 1 Apr 2011 02:41
Favicon

Re: [patch, fortran] Fix PR 48352 - regression with ICE with front end optimization

On 03/31/2011 01:28 PM, Thomas Koenig wrote:
> Hello world,
>
> the attached patch fixes a 4.7 regression, PR 48352, where a function
> elimination in the expressions for a DO loop caused an ICE. The ICE was caused
> by interaction of the expression walker with insertion of a statement for a DO
> loop.
>
> Many thanks to Joost for finding the bug and reducing the test case.
>
> To fix the regression, I have disabled this particular optimization for
> expressions within the loop control.
>
> I'd like to overhaul the way that statements are inserted during front end
> optimization, later. This is needed for functions returning arrays with bounds
> not known at compile-time anyway.
>
> Regression-tested. OK for trunk?
>
OK.  Do you plan to open a second PR for this TODO?

Thanks for patch,

Jerry
Permalink | Reply | 1 comment |

Gmane