Re: [RFC PATCH, go]: Port to ALPHA arch - sysinfo.go fixup
Uros Bizjak ubiz...@gmail.com writes: On Tue, Jul 5, 2011 at 7:17 PM, Mike Stump mikest...@comcast.net wrote: Please note that we set -mieee flag to compile .go files from library and also we add this flag to default testsuite compile flags. Ick, I think this patch might be expedient, but, wrong. Ian will have to think about it and decide. This is something I come up with after a lot of staring into build system: 2011-07-06 Uros Bizjak ubiz...@gmail.com * mt-alphaieee (GOCFLAGS_FOR_TARGET): Add -mieee. This patch by itself does not fix go testsuite failures, although the library is now OK. Additional patch is needed to pass GOCFLAGS to the compiler when checking the package. I will submit it separately. Tested on alphaev68-pc-linux-gnu. OK for mainline? Uros. Index: config/mt-alphaieee === --- config/mt-alphaieee (revision 175904) +++ config/mt-alphaieee (working copy) @@ -1,2 +1,3 @@ CFLAGS_FOR_TARGET += -mieee CXXFLAGS_FOR_TARGET += -mieee +GOCFLAGS_FOR_TARGET += -mieee This seems like a reasonable patch to me, but technically speaking it is incomplete. Go should have IEEE floating point behaviour by default. I believe Java is the same. Ideally there would be a target-independent way for a frontend to request this mode by default. It's a little bit odd because as far as I know every other backend does default to proper IEEE arithmetic, and only deviates when using -ffast-math or equivalent. Anyhow, it's hard for me to care all that much about the Alpha, so I will approve this patch. It's clearly better than the current situation, and it follows what other languages are doing. Thanks. Ian
Re: [RFC PATCH, go]: Port to ALPHA arch - sysinfo.go fixup
On Wed, Jul 6, 2011 at 7:34 PM, Ian Lance Taylor i...@google.com wrote: This seems like a reasonable patch to me, but technically speaking it is incomplete. Go should have IEEE floating point behaviour by default. I believe Java is the same. Ideally there would be a target-independent way for a frontend to request this mode by default. It's a little bit odd because as far as I know every other backend does default to proper IEEE arithmetic, and only deviates when using -ffast-math or equivalent. sh*-*-* also needs -mieee to handle NaN Inf, spu-*-* simply doesn't support them. Uros.
Re: [RFC PATCH, go]: Port to ALPHA arch - sysinfo.go fixup
On Wed, Jun 1, 2011 at 7:49 PM, Ian Lance Taylor i...@google.com wrote:
One problem remains in the libgo testsuite: certain tests have to be
compiled with -mieee, otherwise FPE is generated for unordered values.
Any suggestions, where -mieee should be placed?
That's an interesting question. I think that ideally we would like
-mieee to become the default when using gccgo.
If the language spec requires it, then it should go into gcc/go. See
java_post_options:
static bool
java_post_options (const char **pfilename)
{
/* Excess precision other than fast requires front-end
support. */
if (flag_excess_precision_cmdline == EXCESS_PRECISION_STANDARD
TARGET_FLT_EVAL_METHOD_NON_DEFAULT)
sorry (-fexcess-precision=standard for Java);
flag_excess_precision_cmdline = EXCESS_PRECISION_FAST;
Sure, the Go frontend does stuff like that too. But of course the Go
frontend can't directly set -mieee, because -mieee is a machine
dependent option.
so, you could check the setting and reset any flag that should be off
or error out on incompatible flags. I'd like to think we could get
more milage out of making a flag like -mieee be machine independent
and then ports could just check the base flag for validating machine
specific flags. Certainly alpha isn't the only port that has -mieee.
There are likely to be very few flags promoted because of this, ieee
being the most obvious example.
What I think you are suggesting here is another approach: Alpha should
set -mieee based on a machine-independent option, and then the Go
frontend can set that option instead. I'm fine with that approach too.
I don't think we currently have a machine-independent option which
corresponds to the Alpha -mieee option. According to the documentation,
-mieee does two things: adds support for NaN and infinity, and adds
support for denormal numbers. The first is the -fno-finite-math-only
option, which is actually the default for other targets. The second has
no machine independent option as far as I know.
Attached patch also does the trick for me. Please note that we set
-mieee flag to compile .go files from library and also we add this
flag to default testsuite compile flags.
Using this patch, I was able to fix all floating point exceptions
errors from libgo testsuite.
What remains is a couple of unrelated failures in the testsuite:
Epoll unexpected fd=0
pollServer: unexpected wakeup for fd=0 mode=w
panic: test timed out
../../../gcc-svn/trunk/libgo/testsuite/gotest: line 388: 7123 Aborted
./a.out -test.short -test.timeout=$timeout $@
FAIL: http
gmake[2]: *** [http/check] Error 1
2011/07/05 18:43:28 Test RPC server listening on 127.0.0.1:50334
2011/07/05 18:43:28 Test HTTP RPC server listening on 127.0.0.1:49010
2011/07/05 18:43:28 rpc.Serve: accept:accept tcp 127.0.0.1:50334:
Resource temporarily unavailable
FAIL: rpc
gmake[2]: *** [rpc/check] Error 1
2011/07/05 18:44:22 Test WebSocket server listening on 127.0.0.1:40893
Epoll unexpected fd=0
pollServer: unexpected wakeup for fd=0 mode=w
panic: test timed out
../../../gcc-svn/trunk/libgo/testsuite/gotest: line 388: 12993 Aborted
./a.out -test.short -test.timeout=$timeout $@
FAIL: websocket
gmake[2]: *** [websocket/check] Error 1
../../../gcc-svn/trunk/libgo/testsuite/gotest: line 388: 13945
Segmentation fault ./a.out -test.short -test.timeout=$timeout
$@
FAIL: compress/flate
gmake[2]: *** [compress/flate/check] Error 1
Any ideas how to attack these?
Uros.
Index: configure
===
--- configure (revision 175840)
+++ configure (working copy)
@@ -616,6 +616,7 @@
USING_SPLIT_STACK_FALSE
USING_SPLIT_STACK_TRUE
SPLIT_STACK
+IEEE_FLAGS
OSCFLAGS
GO_DEBUG_PROC_REGS_OS_ARCH_FILE
GO_SYSCALLS_SYSCALL_OS_ARCH_FILE
@@ -10913,7 +10914,7 @@
lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
lt_status=$lt_dlunknown
cat conftest.$ac_ext _LT_EOF
-#line 10916 configure
+#line 10917 configure
#include confdefs.h
#if HAVE_DLFCN_H
@@ -11019,7 +11020,7 @@
lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
lt_status=$lt_dlunknown
cat conftest.$ac_ext _LT_EOF
-#line 11022 configure
+#line 11023 configure
#include confdefs.h
#if HAVE_DLFCN_H
@@ -13580,6 +13581,13 @@
esac
+case ${host_cpu} in
+ alpha*)
+IEEE_FLAGS=-mieee
+;;
+esac
+
+
{ $as_echo $as_me:${as_lineno-$LINENO}: checking whether -fsplit-stack is
supported 5
$as_echo_n checking whether -fsplit-stack is supported... 6; }
if test ${libgo_cv_c_split_stack_supported+set} = set; then :
Index: Makefile.in
===
--- Makefile.in (revision 175840)
+++ Makefile.in (working copy)
@@ -365,6 +365,7 @@
GO_DEBUG_PROC_REGS_OS_ARCH_FILE = @GO_DEBUG_PROC_REGS_OS_ARCH_FILE@
GO_SYSCALLS_SYSCALL_OS_ARCH_FILE = @GO_SYSCALLS_SYSCALL_OS_ARCH_FILE@
GREP = @GREP@
+IEEE_FLAGS = @IEEE_FLAGS@
Re: [RFC PATCH, go]: Port to ALPHA arch - sysinfo.go fixup
On Jul 5, 2011, at 9:51 AM, Uros Bizjak ubiz...@gmail.com wrote: Attached patch also does the trick for me. Please note that we set -mieee flag to compile .go files from library and also we add this flag to default testsuite compile flags. Ick, I think this patch might be expedient, but, wrong. Ian will have to think about it and decide.
Re: [RFC PATCH, go]: Port to ALPHA arch - sysinfo.go fixup
On Tue, Jul 5, 2011 at 7:17 PM, Mike Stump mikest...@comcast.net wrote: On Jul 5, 2011, at 9:51 AM, Uros Bizjak ubiz...@gmail.com wrote: Attached patch also does the trick for me. Please note that we set -mieee flag to compile .go files from library and also we add this flag to default testsuite compile flags. Ick, I think this patch might be expedient, but, wrong. Ian will have to think about it and decide. Well, this is how libgfortran handles -mieee in SH case. Uros.
Re: [RFC PATCH, go]: Port to ALPHA arch - sysinfo.go fixup
On Tue, May 31, 2011 at 8:08 PM, Ian Lance Taylor i...@google.com wrote: Uros Bizjak ubiz...@gmail.com writes: (BTW: Original calculation of Ctime_ns has a cut'n'paste error, stat.Ctime.Nsec should be used instead of stat.Atime.Nsec). Thanks. Fixed like so. Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu. Committed to mainline. Using your latest fixes, I was able to compile libgo on alphaev68-pc-linux-gnu out of the box, without any additional patches. One problem remains in the libgo testsuite: certain tests have to be compiled with -mieee, otherwise FPE is generated for unordered values. Any suggestions, where -mieee should be placed? Thanks, Uros.
Re: [RFC PATCH, go]: Port to ALPHA arch - sysinfo.go fixup
Uros Bizjak ubiz...@gmail.com writes:
On Tue, May 31, 2011 at 8:08 PM, Ian Lance Taylor i...@google.com wrote:
Uros Bizjak ubiz...@gmail.com writes:
(BTW: Original calculation of Ctime_ns has a cut'n'paste error,
stat.Ctime.Nsec should be used instead of stat.Atime.Nsec).
Thanks. Fixed like so. Bootstrapped and ran Go testsuite on
x86_64-unknown-linux-gnu. Committed to mainline.
Using your latest fixes, I was able to compile libgo on
alphaev68-pc-linux-gnu out of the box, without any additional patches.
Cool.
One problem remains in the libgo testsuite: certain tests have to be
compiled with -mieee, otherwise FPE is generated for unordered values.
Any suggestions, where -mieee should be placed?
That's an interesting question. I think that ideally we would like
-mieee to become the default when using gccgo. Users could still use
-mno-ieee (well, they could if there were such an option) but it seems
that for Go -mieee ought to be on by default. I'm not sure whether it
would be more appropriate to do that in code in gcc/go or in code in
gcc/config/alpha.
In gcc/go it would require some sort of #ifdef, or a new target hook.
In gcc/config/alpha one approach would be defining DRIVER_SELF_SPECS in
alpha.h with %{.go:-mieee}.
Thoughts?
Ian
Re: [RFC PATCH, go]: Port to ALPHA arch - sysinfo.go fixup
On Jun 1, 2011, at 7:37 AM, Ian Lance Taylor wrote:
One problem remains in the libgo testsuite: certain tests have to be
compiled with -mieee, otherwise FPE is generated for unordered values.
Any suggestions, where -mieee should be placed?
That's an interesting question. I think that ideally we would like
-mieee to become the default when using gccgo.
If the language spec requires it, then it should go into gcc/go. See
java_post_options:
static bool
java_post_options (const char **pfilename)
{
/* Excess precision other than fast requires front-end
support. */
if (flag_excess_precision_cmdline == EXCESS_PRECISION_STANDARD
TARGET_FLT_EVAL_METHOD_NON_DEFAULT)
sorry (-fexcess-precision=standard for Java);
flag_excess_precision_cmdline = EXCESS_PRECISION_FAST;
so, you could check the setting and reset any flag that should be off or error
out on incompatible flags. I'd like to think we could get more milage out of
making a flag like -mieee be machine independent and then ports could just
check the base flag for validating machine specific flags. Certainly alpha
isn't the only port that has -mieee. There are likely to be very few flags
promoted because of this, ieee being the most obvious example.
Re: [RFC PATCH, go]: Port to ALPHA arch - sysinfo.go fixup
Mike Stump mikest...@comcast.net writes:
On Jun 1, 2011, at 7:37 AM, Ian Lance Taylor wrote:
One problem remains in the libgo testsuite: certain tests have to be
compiled with -mieee, otherwise FPE is generated for unordered values.
Any suggestions, where -mieee should be placed?
That's an interesting question. I think that ideally we would like
-mieee to become the default when using gccgo.
If the language spec requires it, then it should go into gcc/go. See
java_post_options:
static bool
java_post_options (const char **pfilename)
{
/* Excess precision other than fast requires front-end
support. */
if (flag_excess_precision_cmdline == EXCESS_PRECISION_STANDARD
TARGET_FLT_EVAL_METHOD_NON_DEFAULT)
sorry (-fexcess-precision=standard for Java);
flag_excess_precision_cmdline = EXCESS_PRECISION_FAST;
Sure, the Go frontend does stuff like that too. But of course the Go
frontend can't directly set -mieee, because -mieee is a machine
dependent option.
so, you could check the setting and reset any flag that should be off
or error out on incompatible flags. I'd like to think we could get
more milage out of making a flag like -mieee be machine independent
and then ports could just check the base flag for validating machine
specific flags. Certainly alpha isn't the only port that has -mieee.
There are likely to be very few flags promoted because of this, ieee
being the most obvious example.
What I think you are suggesting here is another approach: Alpha should
set -mieee based on a machine-independent option, and then the Go
frontend can set that option instead. I'm fine with that approach too.
I don't think we currently have a machine-independent option which
corresponds to the Alpha -mieee option. According to the documentation,
-mieee does two things: adds support for NaN and infinity, and adds
support for denormal numbers. The first is the -fno-finite-math-only
option, which is actually the default for other targets. The second has
no machine independent option as far as I know.
Ian
Re: [RFC PATCH, go]: Port to ALPHA arch - sysinfo.go fixup
Uros Bizjak ubiz...@gmail.com writes:
This still doesn't fix the build for alpha due to extra struct. From
sysinfo.go:
type Timespec struct { Sec Timespec_sec_t; Nsec Timespec_nsec_t; }
type Stat_t struct { Dev uint64; Ino uint64; Rdev uint64; Size int64;
Blocks uint64; Mode uint32; Uid uint32; Gid uint32; Blksize uint32;
Nlink uint32; __pad0 int32; Go0 struct { Atime Timespec; }; Go1 struct
{ Mtime Timespec; }; Go2 struct { Ctime Timespec; }; __unused
[2+1]int64; }
I finally got back to this. I think this patch should fix this problem.
Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu.
Committed to mainline.
Ian
diff -r 0785cb0479d8 -r 23e3bdca9ee3 libgo/mksysinfo.sh
--- a/libgo/mksysinfo.sh Fri May 27 15:31:49 2011 -0700
+++ b/libgo/mksysinfo.sh Tue May 31 11:05:02 2011 -0700
@@ -358,6 +358,7 @@
-e 's/\([^a-zA-Z0-9_]\)_timespec_t\([^a-zA-Z0-9_]\)/\1Timespec\2/g' \
-e 's/\([^a-zA-Z0-9_]\)_timespec\([^a-zA-Z0-9_]\)/\1Timespec\2/g' \
-e 's/\([^a-zA-Z0-9_]\)_timestruc_t\([^a-zA-Z0-9_]\)/\1Timestruc\2/g' \
+ -e 's/Godump_[0-9] struct { \([^;]*;\) };/\1/g' \
${OUT}
# The directory searching types.
Re: [RFC PATCH, go]: Port to ALPHA arch - sysinfo.go fixup
Rainer Orth r...@cebitec.uni-bielefeld.de writes:
Here's the error I run into:
/vol/gcc/src/hg/trunk/irix/libgo/go/os/file.go:432:12: error: incompatible
types in assignment (implicit assignment of 'syscall.Timeval' hidden field
'_f0')
/vol/gcc/src/hg/trunk/irix/libgo/go/os/file.go:433:12: error: incompatible
types in assignment (implicit assignment of 'syscall.Timeval' hidden field
'_f0')
/vol/gcc/src/hg/trunk/irix/libgo/go/os/file.go:434:37: error: argument 2 has
incompatible type (implicit assignment of 'syscall.Timeval' hidden field
'_f0')
make[8]: *** [os/os.lo] Error 1
What does the line for timeval look like in gen-sysinfo.go?
I get
type Timeval struct { _f0 int32; Sec Timeval_sec_t; Usec Timeval_usec_t; }
Thanks. I fixed this problem with this patch. Bootstrapped and ran Go
testsuite on x86_64-unknown-linux-gnu. Committed to mainline.
Ian
2011-04-21 Ian Lance Taylor i...@google.com
* godump.c (go_format_type): Use exported Go name for anonymous
field name.
Index: gcc/godump.c
===
--- gcc/godump.c (revision 172331)
+++ gcc/godump.c (working copy)
@@ -675,7 +675,7 @@ go_format_type (struct godump_container
{
char buf[100];
- obstack_grow (ob, _f, 2);
+ obstack_grow (ob, Godump_, 2);
snprintf (buf, sizeof buf, %d, i);
obstack_grow (ob, buf, strlen (buf));
i++;
Re: [RFC PATCH, go]: Port to ALPHA arch - sysinfo.go fixup
On Wed, Mar 30, 2011 at 1:12 PM, Uros Bizjak ubiz...@gmail.com wrote: d) The definition of type Stat_t struct also includes additional struct and this confuses compilation. This seems like something that we could teach mksysinfo.sh to handle. What does the struct look like in gen-sysinfo.go? Ian
Re: [RFC PATCH, go]: Port to ALPHA arch - sysinfo.go fixup
Rainer Orth r...@cebitec.uni-bielefeld.de writes:
I've got a similar issue on IRIX 6.5: sys/time.h has
struct timeval {
#if _MIPS_SZLONG == 64
__int32_t :32;
#endif
time_t tv_sec; /* seconds */
longtv_usec;/* and microseconds */
};
which causes the 64-bit libgo build to break.
I don't immediately see why that would break anything. For a case like
this I would expect layout_decl to turn the first field into an ordinary
non-bit-field anyhow.
What does the line for timeval look like in gen-sysinfo.go?
It would be good to have a generic solution for this problem which will
probably return on other platforms.
Unfortunately I have not been able to think of a generic solution. The
basic problem is that we need to get Go representations of structures
that the libc functions use, and we need to have names for the fields
that the library can use. The -fdump-go-spec= option can give us the Go
representations. The trick is getting the names for the fields.
Ian
Re: [RFC PATCH, go]: Port to ALPHA arch - sysinfo.go fixup
Uros Bizjak ubiz...@gmail.com writes:
d) The definition of type Stat_t struct also includes additional
struct and this confuses compilation.
I've got a similar issue on IRIX 6.5: sys/time.h has
struct timeval {
#if _MIPS_SZLONG == 64
__int32_t :32;
#endif
time_t tv_sec; /* seconds */
longtv_usec;/* and microseconds */
};
which causes the 64-bit libgo build to break.
It would be good to have a generic solution for this problem which will
probably return on other platforms.
Rainer
--
-
Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [RFC PATCH, go]: Port to ALPHA arch - sysinfo.go fixup
On Wed, Mar 30, 2011 at 9:58 PM, Uros Bizjak ubiz...@gmail.com wrote: Hello! Attached ports go to ALPHA architecture. There are however several problems with the build: a) Bootstrap compare failure in the gcc/go directory due to binutils bug [1], fixed in latest binutils SVN, use --disable-bootstrap b) alpha doesn't define struct user_regs_struct from which type PtraceRegs is derived. I have manually created PtraceRegs from pt_regs structure and patched generated libgo/sysinfo.go in build directory after the build broke. However - the comment from sys/user.h says that this file is for GDB and GDB only... c) some weird issue with double definition of const _SOCK_NONBLOCK in gen-sysinfo.go and consequently sysinfo.go. d) The definition of type Stat_t struct also includes additional struct and this confuses compilation. Attached is a fixup of sysinfo.go that is neded for successful build. Apply this fixup after build breaks and restart build. Uros. sysinfo.go.diff Description: Binary data
