Re: [patch, mips, testsuite] Fix test to handle optimizations
On 10/08/2012 11:15 AM, Mike Stump wrote:
On Oct 8, 2012, at 9:16 AM, Steve Ellcey wrote:
The gcc.target/mips/ext_ins.c was failing in little endian mode on MIPS because
the compiler is smart enough now to see that 'c' is uninitialized and it can
insert the field 'a' into 'c' with a shift and a full store instead of an
insert because the store just overwrites unintialized data. I changed the
code to force the compiler to preserve the other fields of 'c' and that makes
it use the insert instruction in both big and little endian modes.
Tested on mips-mti-elf.
OK to checkin?
Ok.
I don't think this is the proper fix for this.
Use of BBIT{0,1} instructions will always be smaller than the
alternative. So disabling the test for -Os doesn't fix the problem the
test is designed to find.
The real problem is that some optimizer is broken. Instead of disabling
the tests, can we fix the problem instead?
The goal of the testsuite should be to detect problems, not yield clean
results.
If Richard disagrees with me, then I would defer to him.
David Daney
Re: [patch, mips, testsuite] Fix test to handle optimizations
Really I meant this in reply to the 'Fix
gcc.target/mips/octeon-bbit-2.c for -Os' thread. Sorry for confusing
the issue here.
I don't really have an objection to this one.
David Daney
On 10/08/2012 11:28 AM, David Daney wrote:
On 10/08/2012 11:15 AM, Mike Stump wrote:
On Oct 8, 2012, at 9:16 AM, Steve Ellcey wrote:
The gcc.target/mips/ext_ins.c was failing in little endian mode on
MIPS because
the compiler is smart enough now to see that 'c' is uninitialized and
it can
insert the field 'a' into 'c' with a shift and a full store instead
of an
insert because the store just overwrites unintialized data. I
changed the
code to force the compiler to preserve the other fields of 'c' and
that makes
it use the insert instruction in both big and little endian modes.
Tested on mips-mti-elf.
OK to checkin?
Ok.
I don't think this is the proper fix for this.
Use of BBIT{0,1} instructions will always be smaller than the
alternative. So disabling the test for -Os doesn't fix the problem the
test is designed to find.
The real problem is that some optimizer is broken. Instead of disabling
the tests, can we fix the problem instead?
The goal of the testsuite should be to detect problems, not yield clean
results.
If Richard disagrees with me, then I would defer to him.
David Daney
Many warnings in MIPS port (Was: [PATCH] [MIPS] microMIPS gcc support)
On 03/23/2013 02:07 AM, Richard Sandiford wrote: "Moore, Catherine" writes: 2013-03-21 Catherine Moore * config/mips/constraints.md (u, Udb7 Uead, Uean, Uesp, Uib3, Uuw6, Usb4, ZS, ZT, ZU, ZV, ZW): New constraints. * config/mip/predicates.md (lwsp_swsp_operand, lw16_sw16_operand, lhu16_sh16_operand, lbu16_operand, sb16_operand, db4_operand, db7_operand, ib3_operand, sb4_operand, ub4_operand, uh4_operand, uw4_operand, uw5_operand, uw6_operand, addiur2_operand, addiusp_operand, andi16_operand): New predicates. * config/mips/mips.md (compression): New attribute. (enabled): New attribute. (length): Consider compression in computing length. (shift_compression): New code attribute. (*add3): New operands. Record compression. (sub3): Likewise. (one_cmpl2): Likewise. (*and3): Likewise. (*ior3): Likewise. (unnamed pattern for xor): Likewise. (*zero_extend2): Likewise. (*3): Likewise. (*mov_internal: Likewise. * config/mips/mips-protos.h (mips_signed_immediate_p): New. (mips_unsigned_immediate_p): New. (umips_lwsp_swsp_address_p): New. (m16_based_address_p): New. * config/mips/mips-protos.h (mips_signed_immediate_p): New prototype. (mips_unsigned_immediate_p): New prototype. (lwsp_swsp_address_p): New prototype. (m16_based_address_p): New prototype. * config/mips/mips.c (mips_unsigned_immediate_p): New function. (mips_signed_immediate_p): New function. (m16_based_address_p): New function. (lwsp_swsp_address_p): New function. (mips_print_operand_punctuation): Recognize short delay slot insns for microMIPS.add3" OK. Thanks for your patience through all this. Now the framework's been sorted out, the review process for future encoding patches should be much less painful. Richard I just tried to bootstrap on o32 Debian. This system has binutils 2.20.1. Here is a sample of the resulting failure when building the libjava target libs: . . . /home/daney/gccsvn/build/./gcc/xgcc -B/home/daney/gccsvn/build/./gcc/ -B/usr/local/mips-unknown-linux-gnu/bin/ -B/usr/local/mips-unknown-linux-gnu/lib/ -isystem /usr/local/mips-unknown-linux-gnu/include -isystem /usr/local/mips-unknown-linux-gnu/sys-include -DHAVE_CONFIG_H -I. -I../../../../trunk/libjava/libltdl -g -O2 -minterlink-mips16 -c ../../../../trunk/libjava/libltdl/ltdl.c -fPIC -DPIC -o .libs/ltdl.o /tmp/cckECtVQ.s: Assembler messages: /tmp/cckECtVQ.s:12: Warning: Tried to set unrecognized symbol: nomicromips /tmp/cckECtVQ.s:115: Warning: Tried to set unrecognized symbol: nomicromips /tmp/cckECtVQ.s:161: Warning: Tried to set unrecognized symbol: nomicromips . . . There are literally thousands and thousands of these warnings. David Daney
Re: Many warnings in MIPS port (Was: [PATCH] [MIPS] microMIPS gcc support)
On 04/12/2013 10:55 AM, Moore, Catherine wrote: -Original Message- From: Maciej W. Rozycki [mailto:ma...@codesourcery.com] Sent: Friday, April 12, 2013 1:03 PM To: David Daney Cc: Moore, Catherine; gcc-patches@gcc.gnu.org; Richard Sandiford Subject: Re: Many warnings in MIPS port (Was: [PATCH] [MIPS] microMIPS gcc support) On Fri, 12 Apr 2013, David Daney wrote: I just tried to bootstrap on o32 Debian. This system has binutils 2.20.1. Here is a sample of the resulting failure when building the libjava target libs: . . . /home/daney/gccsvn/build/./gcc/xgcc - B/home/daney/gccsvn/build/./gcc/ -B/usr/local/mips-unknown-linux-gnu/bin/ -B/usr/local/mips-unknown-linux-gnu/lib/ -isystem /usr/local/mips-unknown-linux-gnu/include -isystem /usr/local/mips-unknown-linux-gnu/sys-include -DHAVE_CONFIG_H -I. -I../../../../trunk/libjava/libltdl -g -O2 -minterlink-mips16 -c ../../../../trunk/libjava/libltdl/ltdl.c -fPIC -DPIC -o .libs/ltdl.o /tmp/cckECtVQ.s: Assembler messages: /tmp/cckECtVQ.s:12: Warning: Tried to set unrecognized symbol: nomicromips /tmp/cckECtVQ.s:115: Warning: Tried to set unrecognized symbol: nomicromips /tmp/cckECtVQ.s:161: Warning: Tried to set unrecognized symbol: nomicromips . . . There are literally thousands and thousands of these warnings. Thanks for the report, I guess GCC should: 1. Detect in its `configure' script if GAS supports the pseudo-op and refrain from producing it if it does not (or actually perhaps it may never produce it by default as GAS defaults to the nomicromips mode anyway); we have precedents for that already. Configure was modified as part of the micromips patch to detect support for the .set micromips pseudo op. Do you have a configure log? Here is the relevant fragment: . . . configure:25761: checking assembler for .micromips support configure:25770: /usr/bin/as-o conftest.o conftest.s >&5 conftest.s: Assembler messages: conftest.s:1: Warning: Tried to set unrecognized symbol: micromips configure:25773: $? = 0 configure:25784: result: yes . . . Since it is a warning, it succeeds. I think you need to adjust the test so that it fails if there is a warning.
Re: [Patch] [MIPS] Fix Many warnings in MIPS port (Was: [PATCH] [MIPS] microMIPS gcc support)
On 04/12/2013 03:07 PM, Moore, Catherine wrote: Hi David, Please try the attached patch. Is this OK to checkin? I don't think it is correct... Thanks, Catherine 2013-04-12 Catherine Moore * configure.ac (.micromips support): Add --fatal-warnings option. * configure: Regenerate. [...] Index: configure.ac === --- configure.ac(revision 197936) +++ configure.ac(working copy) @@ -4051,6 +4051,12 @@ LCF0: [AC_DEFINE(HAVE_AS_NO_SHARED, 1, [Define if the assembler understands -mno-shared.])]) +gcc_GAS_CHECK_FEATURE([.micromips support], + gcc_cv_as_micromips_support,,[--fatal-warnings], + [.set micromips],, + [AC_DEFINE(HAVE_GAS_MICROMIPS, 1, + [Define if your assembler supports the .set micromips directive])]) + There is already an existing check. Just modify that one instead of adding a duplicate. Something like the attached (untested) gcc_GAS_CHECK_FEATURE([.gnu_attribute support], gcc_cv_as_mips_gnu_attribute, [2,18,0],, [.gnu_attribute 4,1],, I didn't have time to test this yet. I may try Monday. David Daney Index: gcc/configure.ac === --- gcc/configure.ac (revision 197836) +++ gcc/configure.ac (working copy) @@ -4058,7 +4058,7 @@ [Define if your assembler supports .gnu_attribute.])]) gcc_GAS_CHECK_FEATURE([.micromips support], - gcc_cv_as_micromips_support,,, + gcc_cv_as_micromips_support,,[--fatal-warnings], [.set micromips],, [AC_DEFINE(HAVE_GAS_MICROMIPS, 1, [Define if your assembler supports the .set micromips directive])])
Re: [Patch] [MIPS] Fix Many warnings in MIPS port (Was: [PATCH] [MIPS] microMIPS gcc support)
On 04/14/2013 01:27 PM, Moore, Catherine wrote:
-Original Message-
From: David Daney [mailto:ddaney.c...@gmail.com]
Sent: Friday, April 12, 2013 7:29 PM
To: Moore, Catherine
Cc: Rozycki, Maciej; gcc-patches@gcc.gnu.org; Richard Sandiford
Subject: Re: [Patch] [MIPS] Fix Many warnings in MIPS port (Was: [PATCH]
[MIPS] microMIPS gcc support)
On 04/12/2013 03:07 PM, Moore, Catherine wrote:
Hi David,
Please try the attached patch. Is this OK to checkin?
I don't think it is correct...
And you would be right. I attached the wrong patch. Try this one instead:
Index: configure
===
--- configure (revision 197950)
+++ configure (working copy)
@@ -17830,7 +17830,7 @@
lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
lt_status=$lt_dlunknown
cat > conftest.$ac_ext <<_LT_EOF
-#line 17831 "configure"
+#line 17833 "configure"
#include "confdefs.h"
#if HAVE_DLFCN_H
@@ -17936,7 +17936,7 @@
lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
lt_status=$lt_dlunknown
cat > conftest.$ac_ext <<_LT_EOF
-#line 17937 "configure"
+#line 17939 "configure"
#include "confdefs.h"
#if HAVE_DLFCN_H
@@ -25766,7 +25766,7 @@
gcc_cv_as_micromips_support=no
if test x$gcc_cv_as != x; then
$as_echo '.set micromips' > conftest.s
-if { ac_try='$gcc_cv_as $gcc_cv_as_flags -o conftest.o conftest.s >&5'
+if { ac_try='$gcc_cv_as $gcc_cv_as_flags --fatal-warnings -o conftest.o
conftest.s >&5'
{ { eval echo "\"\$as_me\":${as_lineno-$LINENO}: \"$ac_try\""; } >&5
(eval $ac_try) 2>&5
ac_status=$?
Index: configure.ac
===
--- configure.ac(revision 197950)
+++ configure.ac(working copy)
@@ -4058,7 +4058,7 @@
[Define if your assembler supports .gnu_attribute.])])
gcc_GAS_CHECK_FEATURE([.micromips support],
- gcc_cv_as_micromips_support,,,
+ gcc_cv_as_micromips_support,,[--fatal-warnings],
[.set micromips],,
[AC_DEFINE(HAVE_GAS_MICROMIPS, 1,
[Define if your assembler supports the .set micromips directive])])
Sorry for the confusion.
Catherine
Your e-mail client mangled it as Content-Transfer-Encoding:
quoted-printable, so I had to manually apply it. But after doing that,
it does seem to have the desired effect.
So I would say: Please apply it (After getting somebody to approve it).
Thanks,
David Daney
Re: Go patch committed: Update Go library
On 11/02/2011 10:54 AM, Ian Lance Taylor wrote:
Rainer Orth writes:
All go and libgo execution tests are failing for me with this patch on
x86_64-unknown-linux-gnu (CentOS 5.5, I think):
output is:
/var/gcc/regression/trunk/2.6.18-gcc-gas-gld/build/x86_64-unknown-linux-gnu/./li
bgo/.libs/libgo.so: undefined reference to `inotify_init1'
/var/gcc/regression/trunk/2.6.18-gcc-gas-gld/build/x86_64-unknown-linux-gnu/./li
bgo/.libs/libgo.so: undefined reference to `fallocate'
/var/gcc/regression/trunk/2.6.18-gcc-gas-gld/build/x86_64-unknown-linux-gnu/./li
bgo/.libs/libgo.so: undefined reference to `sync_file_range'
collect2: error: ld returned 1 exit status
FAIL: go.go-torture/execute/array-1.go compilation, -O0
I assume that CentOS 5.5 uses some version of glibc before version 2.6.
The three functions you mention are not supported in older versions of
glibc. Fortunately, they are not called anywhere else in the library,
so this patch takes the easy way out and simply removes them.
Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu.
Committed to mainline.
On Linux you also have iopl and ioperm which are x86 only.
On MIPS we fail because of those. I was going to create a patch to move
those two to libcall_linux_{386,amd64}.go. An alternative would be to
remove them too.
David Daney
Re: MIPS testsuite patch for --with-synci configurations
On 06/11/2012 12:30 PM, Steve Ellcey wrote: This patch is to fix MIPS failures that occcur when configuring GCC with the -with-synci option. In this case GCC will generate the synci instruction by default if on a MIPS architecture that supports it . When on an architecture that does not support synci, GCC will not generate it by default but it does generate a warning saying that it is not doing so and that warning is causing tests that explicitly specify a MIPS architecture that does not support synci but do not explicitly turn off synci to fail with an extra, unexpected warning. I initially looked at changing GCC to remove the warning but that did not look workable, see http://gcc.gnu.org/ml/gcc/2012-06/msg00100.html for more details. This patch addes the -mno-synci flag to MIPS tests that specify an architecture that does not support synci, thus getting rid of the warning message and making the tests pass. Tested with the mips-linux-gnu and mips-sde-elf targets both with and without --with-synci on the GCC configuration. OK to checkin? I wonder if it would make more sense to modify the testsuite driver to take care of this. It seems like the set of files with the -mno-synci annotation could easily become different than the set that requires it. David Daney Steve Ellcey sell...@mips.com 2012-06-11 Steve Ellcey * gcc.target/mips/call-saved-1.c: Add -mno-synci flag. * gcc.target/mips/call-saved-2.c: Ditto. * gcc.target/mips/call-saved-3.c: Ditto. * gcc.target/mips/clear-cache-2.c: Ditto. * gcc.target/mips/ext-8.c: Ditto. * gcc.target/mips/extend-2.c: Ditto. * gcc.target/mips/fix-r4000-1.c: Ditto. * gcc.target/mips/fix-r4000-10.c: Ditto. * gcc.target/mips/fix-r4000-11.c: Ditto. * gcc.target/mips/fix-r4000-12.c: Ditto. * gcc.target/mips/fix-r4000-2.c: Ditto. * gcc.target/mips/fix-r4000-3.c: Ditto. * gcc.target/mips/fix-r4000-4.c: Ditto. * gcc.target/mips/fix-r4000-5.c: Ditto. * gcc.target/mips/fix-r4000-6.c: Ditto. * gcc.target/mips/fix-r4000-7.c: Ditto. * gcc.target/mips/fix-r4000-8.c: Ditto. * gcc.target/mips/fix-r4000-9.c: Ditto. * gcc.target/mips/fix-vr4130-1.c: Ditto. * gcc.target/mips/fix-vr4130-2.c: Ditto. * gcc.target/mips/fix-vr4130-3.c: Ditto. * gcc.target/mips/fix-vr4130-4.c: Ditto. * gcc.target/mips/fpr-moves-1.c: Ditto. * gcc.target/mips/fpr-moves-2.c: Ditto. * gcc.target/mips/loongson-muldiv-1.c: Ditto. * gcc.target/mips/loongson-muldiv-2.c: Ditto. * gcc.target/mips/loongson-shift-count-truncated-1.c: Ditto. * gcc.target/mips/loongson-simd.c: Ditto. * gcc.target/mips/loongson3a-muldiv-1.c: Ditto. * gcc.target/mips/loongson3a-muldiv-2.c: Ditto. * gcc.target/mips/madd-1.c: Ditto. * gcc.target/mips/madd-2.c: Ditto. * gcc.target/mips/madd-5.c: Ditto. * gcc.target/mips/madd-6.c: Ditto. * gcc.target/mips/madd-7.c: Ditto. * gcc.target/mips/madd-8.c: Ditto. * gcc.target/mips/maddu-1.c: Ditto. * gcc.target/mips/maddu-2.c: Ditto. * gcc.target/mips/msub-1.c: Ditto. * gcc.target/mips/msub-2.c: Ditto. * gcc.target/mips/msub-5.c: Ditto. * gcc.target/mips/msub-6.c: Ditto. * gcc.target/mips/msub-7.c: Ditto. * gcc.target/mips/msub-8.c: Ditto. * gcc.target/mips/msubu-1.c: Ditto. * gcc.target/mips/msubu-2.c: Ditto. * gcc.target/mips/nmadd-1.c: Ditto. * gcc.target/mips/nmadd-2.c: Ditto. * gcc.target/mips/nmadd-3.c: Ditto. * gcc.target/mips/no-smartmips-ror-1.c: Ditto. * gcc.target/mips/pr34831.c: Ditto. * gcc.target/mips/r10k-cache-barrier-10.c: Ditto. * gcc.target/mips/r3900-mult.c: Ditto. * gcc.target/mips/rsqrt-1.c: Ditto. * gcc.target/mips/rsqrt-2.c: Ditto. * gcc.target/mips/rsqrt-3.c: Ditto. * gcc.target/mips/rsqrt-4.c: Ditto. * gcc.target/mips/sb1-1.c: Ditto. * gcc.target/mips/vr-mult-1.c: Ditto. * gcc.target/mips/vr-mult-2.c: Ditto. [...]
Re: [PATCH] Fix ctrstuff.c with init_array support
On 12/05/2011 07:38 PM, H.J. Lu wrote: On Mon, Dec 5, 2011 at 5:42 PM, Andrew Pinski wrote: Hi, Like the .ctors array, __do_global_dtors_aux_fini_array_entry and __frame_dummy_init_array_entry arrays need a specific alignment. This patch fixes those two arrays. This patch fixes the bootstrap on mips64-linux-gnu. Bootstrapped on mips64-linux-gnu. Bootstrapped and tested on x86-linux-gnu with no regressions. Thanks, Andrew Pinski libgcc/ChangeLog: * crtstuff.c (__do_global_dtors_aux_fini_array_entry): Align to the size of func_ptr. (__frame_dummy_init_array_entry): Likewise. .eh_frame section has similar problem: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27576 But you have known about that for over five years and x86_64 still seems to work, so it must not really be hurting anything. Andrew's patch fixes bad code in libgcc which causes bootstrap breakage on MIPS when used with recent binutils releases. So I would propose that it be considered as-is, without changing the .eh_frame bits. If someone wants to change the .eh_frame things in crtstuff.c, they are free to do that, but it shouldn't really be gating factor for this patch. David Daney
[Patch libgo]: Move Iopl and Ioperm to 368/amd64 specific libcall_linux_*.go files.
Ian,
As discussed several months ago, libgo will not run on mips because it
references the x86 specific system calls iopl() and ioperm(). These
system calls do not exist in mips*-linux, so we move them to new
368/amd64 specific libcall_linux_*.go files.
The attached patch was tested on x86_64-linux-gnu with no libgo
failures. There are still some other problems with mips*-linux, but
this makes forward progress.
It is unclear what kind of change log is required, so I do not supply one.
Cavium, Inc. should now have a corporate contributor license agreement
on file, so I think you can commit this upstream if acceptable.
Thanks,
David Daney
Index: go/syscall/libcall_linux_amd64.go
===
--- go/syscall/libcall_linux_amd64.go (revision 0)
+++ go/syscall/libcall_linux_amd64.go (revision 0)
@@ -0,0 +1,13 @@
+// Copyright 2011 The Go Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style
+// license that can be found in the LICENSE file.
+
+// GNU/Linux library calls amd64 specific.
+
+package syscall
+
+//sys Ioperm(from int, num int, on int) (errno int)
+//ioperm(from _C_long, num _C_long, on int) int
+
+//sys Iopl(level int) (errno int)
+//iopl(level int) int
Index: go/syscall/libcall_linux_386.go
===
--- go/syscall/libcall_linux_386.go (revision 0)
+++ go/syscall/libcall_linux_386.go (revision 0)
@@ -0,0 +1,13 @@
+// Copyright 2011 The Go Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style
+// license that can be found in the LICENSE file.
+
+// GNU/Linux library calls 386 specific.
+
+package syscall
+
+//sys Ioperm(from int, num int, on int) (errno int)
+//ioperm(from _C_long, num _C_long, on int) int
+
+//sys Iopl(level int) (errno int)
+//iopl(level int) int
Index: go/syscall/libcall_linux.go
===
--- go/syscall/libcall_linux.go (revision 182179)
+++ go/syscall/libcall_linux.go (working copy)
@@ -207,12 +207,6 @@ func PtraceDetach(pid int) (errno int) {
// //sysnb Gettid() (tid int)
// //gettid() Pid_t
-//sys Ioperm(from int, num int, on int) (errno int)
-//ioperm(from _C_long, num _C_long, on int) int
-
-//sys Iopl(level int) (errno int)
-//iopl(level int) int
-
// FIXME: mksysinfo linux_dirent
//Or just abandon this function.
// //sys Getdents(fd int, buf []byte) (n int, errno int)
Re: [RFC 4.8] use ip+cfa to identify unwind frames, if possible
On 02/16/2012 02:12 PM, Richard Henderson wrote: [...] index 1c19f8b..59d4560 100644 --- a/gcc/config/mips/mips.h +++ b/gcc/config/mips/mips.h @@ -2920,3 +2920,15 @@ extern GTY(()) struct target_globals *mips16_globals; with arguments ARGS. */ #define PMODE_INSN(NAME, ARGS) \ (Pmode == SImode ? NAME ## _si ARGS : NAME ## _di ARGS) + +/* For mips32 mode we have bits 0 and 1 zero free, but for mips16 mode, + bit 0 indicates mips16 mode, and bit 1 is thence meaningful. Thus + the only "free" bits would be at the top of the address space. + Can we trust that we'll never try to unwind in kernel mode? */ That's too bad. I guess if we ever want to unwind in kernel mode, we can say no mips16 and switch it to a low-order bit for that application. Or write our own unwinder. David Daney
Re: [RFC 4.8] use ip+cfa to identify unwind frames, if possible
On 02/16/2012 03:32 PM, Richard Sandiford wrote: David Daney writes: On 02/16/2012 02:12 PM, Richard Henderson wrote: [...] Thanks for the patch. index 1c19f8b..59d4560 100644 --- a/gcc/config/mips/mips.h +++ b/gcc/config/mips/mips.h @@ -2920,3 +2920,15 @@ extern GTY(()) struct target_globals *mips16_globals; with arguments ARGS. */ #define PMODE_INSN(NAME, ARGS) \ (Pmode == SImode ? NAME ## _si ARGS : NAME ## _di ARGS) + +/* For mips32 mode we have bits 0 and 1 zero free, but for mips16 mode, + bit 0 indicates mips16 mode, and bit 1 is thence meaningful. Thus + the only "free" bits would be at the top of the address space. + Can we trust that we'll never try to unwind in kernel mode? */ That's too bad. I guess if we ever want to unwind in kernel mode, we can say no mips16 and switch it to a low-order bit for that application. Or write our own unwinder. I suppose the problem is that baremetal often runs in kernel mode. (Normal mips*-elf gdbsim testing works that way.) But I think we'd be fine if we restrict the IP matching to non-MIPS16 mode. GCC doesn't have any other special RA save registers, and now's a good time to say that such a thing won't be allowed in MIPS16 or microMIPS code (or in anything, probably). So maybe we could set private_1 to (IP | 2) when (IP& 3) == 0, and leave it at 0 otherwise. It's then a forced unwind unless (IP& 3) == 2. Not as elegant as the single bit though. Just off the top of my head (with out actually looking at the code). Is there anything that could be done with the register zero save slot (if it even exists)? Richard
Re: Remove obsolete Tru64 UNIX V5.1B support
On 03/06/2012 05:14 AM, Rainer Orth wrote: "Joseph S. Myers" writes: There's one particular issue: the change to java/io/File.java required my to regenerate the .class file in classpath. I've used Sun javac -target 1.5 for that and hope I got it right. I'd have expected regeneration to use GCJ built to use ECJ, though I don't know. I've never tried this. Given that the .class file lives below libjava/classpath and has to be synced with upstream Classpath anyway, I hope the Java maintainers will take care of that. This it documented (although perhaps badly) in install/configure.html You should use --enable-java-maintainer-mode, this will cause the build to use ecj and gjavah to regenerate all the generated files in the 'standard' manner. At least with the javac-built File.class I had no libjava testsuite failures. It probably results in a usable .class file, but is error prone and not very reproducible. David Daney
Re: [patch] Disable static build for libjava
On 07/07/2011 09:27 AM, Matthias Klose wrote:
As discussed at the Google GCC gathering, disable the build of static libraries
in libjava, which should cut the build time of libjava by 50%. The static
libjava build isn't useful out of the box, and I don't see it packaged by Linux
distributions either.
The AC_PROG_LIBTOOL check is needed to get access to the enable_shared macro.
I'm unsure about the check in the switch construct. Taken from libtool.m4, and
determining the value of enable_shared_with_static_runtimes.
Ok for the trunk?
2011-07-07 Matthias Klose
* Makefile.def (target_modules/libjava): Pass
$(libjava_disable_static).
* configure.ac: Check for libtool, pass --disable-static
in libjava_disable_static.
* Makefile.in: Regenerate.
* configure: Likewise.
My autoconf fu is not what it used to be. It is fine if static
libraries are disabled by default, but it should be possible to enable
them from the configure command line. It is unclear to me if this patch
does that.
Also I would like to go on record as disagreeing with the statement that
'static libjava build isn't useful out of the box'
David Daney
Index: Makefile.def
===
--- Makefile.def(revision 175963)
+++ Makefile.def(working copy)
@@ -132,7 +132,8 @@
target_modules = { module= winsup; };
target_modules = { module= libgloss; no_check=true; };
target_modules = { module= libffi; };
-target_modules = { module= libjava; raw_cxx=true; };
+target_modules = { module= libjava; raw_cxx=true;
+ extra_configure_flags="$(libjava_disable_static)"; };
target_modules = { module= zlib; };
target_modules = { module= boehm-gc; };
target_modules = { module= rda; };
Index: configure.ac
===
--- configure.ac(revision 175963)
+++ configure.ac(working copy)
@@ -443,6 +443,16 @@
;;
esac
+AC_PROG_LIBTOOL
+if test x$enable_shared = xyes ; then
+ case $host_cpu in
+ cygwin* | mingw* | pw32* | cegcc*)
+;;
+ *)
+libjava_disable_static=--disable-static
+ esac
+fi
+AC_SUBST(libjava_disable_static)
# Disable libmudflap on some systems.
if test x$enable_libmudflap = x ; then
Re: [patch] Disable static build for libjava
On 07/07/2011 09:57 AM, Matthias Klose wrote: On 07/07/2011 06:51 PM, David Daney wrote: On 07/07/2011 09:27 AM, Matthias Klose wrote: As discussed at the Google GCC gathering, disable the build of static libraries in libjava, which should cut the build time of libjava by 50%. The static libjava build isn't useful out of the box, and I don't see it packaged by Linux distributions either. The AC_PROG_LIBTOOL check is needed to get access to the enable_shared macro. I'm unsure about the check in the switch construct. Taken from libtool.m4, and determining the value of enable_shared_with_static_runtimes. Ok for the trunk? 2011-07-07 Matthias Klose * Makefile.def (target_modules/libjava): Pass $(libjava_disable_static). * configure.ac: Check for libtool, pass --disable-static in libjava_disable_static. * Makefile.in: Regenerate. * configure: Likewise. My autoconf fu is not what it used to be. It is fine if static libraries are disabled by default, but it should be possible to enable them from the configure command line. It is unclear to me if this patch does that. no. I assume an extra option --enable-static-libjava would be needed. Not being a libjava maintainer, I cannot force you to add something like that as part of the patch, but I think it would be a good idea. Also I would like to go on record as disagreeing with the statement that 'static libjava build isn't useful out of the box' I remember that there were some restrictions with the static library. but maybe I'm wrong. There are restrictions, but it is still useful for some embedded environments. David Daney
[Patch] libgo support for mips{,64}-linux-gnu
Ian,
This is the patch I am using to be able to build libgo in GCC.
See:
http://gcc.gnu.org/ml/gcc-testresults/2011-04/msg02325.html
MIPS/Linux support is not perfect, but this is a start. I'm not sure
what the mechanics of applying the patch are, but I think you need to do
something with it.
2011-04-25 David Daney Index: mksysinfo.sh
===
--- mksysinfo.sh(revision 172872)
+++ mksysinfo.sh(working copy)
@@ -261,6 +261,16 @@ if test "$regs" != ""; then
echo "type PtraceRegs struct {$nregs }" >> ${OUT}
fi
+# MIPS/Linux is special with respect to PTRACE_GETREGS.
+if grep -q -e '^const _mips ' gen-sysinfo.go \
+ && grep -q -e '^const _linux ' gen-sysinfo.go ; then
+ if grep -q -e '__MIPS_SIM = __ABIO32' gen-sysinfo.go ; then
+ echo "type PtraceRegs [EF_SIZE / 4]uint32" >> ${OUT}
+ else
+ echo "type PtraceRegs [EF_SIZE / 8]uint64" >> ${OUT}
+ fi
+fi
+
# Some basic types.
echo 'type Size_t _size_t' >> ${OUT}
echo "type Ssize_t _ssize_t" >> ${OUT}
Index: syscalls/syscall_linux_mipsn32.go
===
--- syscalls/syscall_linux_mipsn32.go (revision 0)
+++ syscalls/syscall_linux_mipsn32.go (revision 0)
@@ -0,0 +1,15 @@
+// syscall_linux_mipsn32.go -- GNU/Linux MIPS n32 ABI specific support
+
+// Copyright 2011 The Go Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style
+// license that can be found in the LICENSE file.
+
+package syscall
+
+func (r *PtraceRegs) PC() uint64 {
+ return r[EF_CP0_EPC];
+}
+
+func (r *PtraceRegs) SetPC(pc uint64) {
+ r[EF_CP0_EPC] = pc;
+}
Index: syscalls/syscall_linux_mipsn64.go
===
--- syscalls/syscall_linux_mipsn64.go (revision 0)
+++ syscalls/syscall_linux_mipsn64.go (revision 0)
@@ -0,0 +1,15 @@
+// syscall_linux_mipsn64.go -- GNU/Linux MIPS n64 ABI specific support
+
+// Copyright 2011 The Go Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style
+// license that can be found in the LICENSE file.
+
+package syscall
+
+func (r *PtraceRegs) PC() uint64 {
+ return r[EF_CP0_EPC];
+}
+
+func (r *PtraceRegs) SetPC(pc uint64) {
+ r[EF_CP0_EPC] = pc;
+}
Index: syscalls/syscall_linux_mipso32.go
===
--- syscalls/syscall_linux_mipso32.go (revision 0)
+++ syscalls/syscall_linux_mipso32.go (revision 0)
@@ -0,0 +1,15 @@
+// syscall_linux_mipso32.go -- GNU/Linux MIPS o32 ABI specific support
+
+// Copyright 2011 The Go Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style
+// license that can be found in the LICENSE file.
+
+package syscall
+
+func (r *PtraceRegs) PC() uint64 {
+ return uint64(r[EF_CP0_EPC]);
+}
+
+func (r *PtraceRegs) SetPC(pc uint64) {
+ r[EF_CP0_EPC] = uint32(pc);
+}
Index: go/debug/proc/regs_linux_mipsn32.go
===
--- go/debug/proc/regs_linux_mipsn32.go (revision 0)
+++ go/debug/proc/regs_linux_mipsn32.go (revision 0)
@@ -0,0 +1,100 @@
+// Copyright 2011 The Go Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style
+// license that can be found in the LICENSE file.
+
+package proc
+
+import (
+ "os"
+ "strconv"
+ "syscall"
+)
+
+type _MipsRegs struct {
+ regs syscall.PtraceRegs
+ setter func(*syscall.PtraceRegs) os.Error
+}
+
+var names = []string{
+ "zero",
+ "at",
+ "v0",
+ "v1",
+ "a0",
+ "a1",
+ "a2",
+ "a3",
+ "a4",
+ "a5",
+ "a6",
+ "a7",
+ "t0",
+ "t1",
+ "t2",
+ "t3",
+ "s0",
+ "s1",
+ "s2",
+ "s3",
+ "s4",
+ "s5",
+ "s6",
+ "s7",
+ "t8",
+ "t9",
+ "k0",
+ "k1",
+ "gp",
+ "sp",
+ "s8",
+ "ra",
+ "lo",
+ "hi",
+ "pc",
+}
+
+func (r *_MipsRegs) PC() Word { return Word(r.regs[syscall.EF_CP0_EPC]) }
+
+func (r *_MipsRegs) SetPC(val Word) os.Error {
+ r.regs[syscall.EF_CP0_EPC] = uint64(int64(int32(val)))
+ return r.setter(&r.regs)
+}
+
+func (r *_MipsRegs) Link() Word { return Word(r.regs[syscall.EF_REG31]) }
+
+func (r *_MipsRegs) SetLink(val Word) os.Error {
+r.regs[sysca
