Re: [RFC PATCH, go]: Port to ALPHA arch - sysinfo.go fixup

2011-07-06 Thread Uros Bizjak 
On Wed, Jul 6, 2011 at 7:34 PM, Ian Lance Taylor  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

2011-07-06 Thread Ian Lance Taylor 
Uros Bizjak  writes:

> On Tue, Jul 5, 2011 at 7:17 PM, Mike Stump  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  
>
>   * 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

2011-07-06 Thread Uros Bizjak 
On Tue, Jul 5, 2011 at 7:17 PM, Mike Stump  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  

* 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

Re: [RFC PATCH, go]: Port to ALPHA arch - sysinfo.go fixup

2011-07-05 Thread Ian Lance Taylor 
Uros Bizjak  writes:

> 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?

None of these look familiar to me.

An "Epoll unexpected fd" error means that epoll returned information
about a file descriptor which the program didn't ask about.  Not sure
why that would happen.  Particularly for fd 0, since epoll is only used
for network connections, which fd 0 presumably is not.

The way to look into these is to cd to TARGET/libgo and run "make
GOTESTFLAGS=--keep http/check" (or whatever/check).  That will leave a
directory gotest in your libgo directory.  The executable a.out in
that directory is the test case.  You can debug the test case using gdb
in more or less the usual way.  It's a bit painful to set breakpoints by
function name, but setting breakpoints by file:line works fine.
Printing variables works as well as it ever does, but the variables are
printed in C form rather than Go form.

Ian

Re: [RFC PATCH, go]: Port to ALPHA arch - sysinfo.go fixup

2011-07-05 Thread Uros Bizjak 
On Tue, Jul 5, 2011 at 7:17 PM, Mike Stump  wrote:
> On Jul 5, 2011, at 9:51 AM, Uros Bizjak  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

2011-07-05 Thread Mike Stump 
On Jul 5, 2011, at 9:51 AM, Uros Bizjak  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

2011-07-05 Thread Uros Bizjak 
On Wed, Jun 1, 2011 at 7:49 PM, 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.

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

Re: [RFC PATCH, go]: Port to ALPHA arch - sysinfo.go fixup

2011-06-01 Thread Ian Lance Taylor 
Mike Stump  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

2011-06-01 Thread Mike Stump 
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

2011-06-01 Thread Ian Lance Taylor 
Uros Bizjak  writes:

> On Tue, May 31, 2011 at 8:08 PM, Ian Lance Taylor  wrote:
>> Uros Bizjak  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

2011-06-01 Thread Uros Bizjak 
On Tue, May 31, 2011 at 8:08 PM, Ian Lance Taylor  wrote:
> Uros Bizjak  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

2011-05-31 Thread Ian Lance Taylor 
Uros Bizjak  writes:

> On Sat, Apr 2, 2011 at 1:09 AM, Ian Lance Taylor  wrote:
>> On Wed, Mar 30, 2011 at 12:58 PM, Uros Bizjak  wrote:
>>>
>>> Attached ports go to ALPHA architecture.
>>
>> Thanks!
>>
>> Committed.
>>
>>
>>> 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...
>>
>> libgo uses it to support ptrace, which in effect is the same as what
>> gdb does.  If mksysinfo.sh is unable to provide any definition for the
>> structure, then the choices are either to patch up mksysinfo.sh so
>> that it works, or to simply define the structure in
>> libgo/syscalls/syscall_linux_alpha.go.  it is unlikely to change so
>> the latter seems acceptable if patching mksysinfo is too hard.
>
> Attached patch implements this suggestion and builds libgo without problems.

Committed.  Thanks.

Ian

Re: [RFC PATCH, go]: Port to ALPHA arch - sysinfo.go fixup

2011-05-31 Thread Ian Lance Taylor 
Uros Bizjak  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.

Ian

diff -r 23e3bdca9ee3 libgo/go/os/stat.go
--- a/libgo/go/os/stat.go	Tue May 31 11:05:02 2011 -0700
+++ b/libgo/go/os/stat.go	Tue May 31 11:07:24 2011 -0700
@@ -25,7 +25,7 @@
 	fi.Blocks = int64(stat.Blocks)
 	fi.Atime_ns = int64(stat.Atime.Sec)*1e9 + int64(stat.Atime.Nsec)
 	fi.Mtime_ns = int64(stat.Mtime.Sec)*1e9 + int64(stat.Mtime.Nsec)
-	fi.Ctime_ns = int64(stat.Ctime.Sec)*1e9 + int64(stat.Atime.Nsec)
+	fi.Ctime_ns = int64(stat.Ctime.Sec)*1e9 + int64(stat.Ctime.Nsec)
 	for i := len(name)-1; i >= 0; i-- {
 		if name[i] == '/' {
 			name = name[i+1:]

Re: [RFC PATCH, go]: Port to ALPHA arch - sysinfo.go fixup

2011-05-31 Thread Ian Lance Taylor 
Uros Bizjak  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

2011-05-02 Thread Ian Lance Taylor 
Uros Bizjak  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; }

> Is there a solution for this problem?

I haven't fixed it yet but I think the way to fix it is to edit
mksysinfo.sh to strip out the unexpected structs.

Ian

Re: [RFC PATCH, go]: Port to ALPHA arch - sysinfo.go fixup

2011-05-02 Thread Uros Bizjak 
On Fri, Apr 22, 2011 at 1:39 AM, Ian Lance Taylor  wrote:
> Rainer Orth  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  
>
>        * godump.c (go_format_type): Use exported Go name for anonymous
>        field name.

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; }

Following patch enables the build to proceed:

Index: go/os/stat.go
===
--- go/os/stat.go   (revision 173234)
+++ go/os/stat.go   (working copy)
@@ -23,9 +23,9 @@
fi.Size = int64(stat.Size)
fi.Blksize = int64(stat.Blksize)
fi.Blocks = int64(stat.Blocks)
-   fi.Atime_ns = int64(stat.Atime.Sec)*1e9 + int64(stat.Atime.Nsec)
-   fi.Mtime_ns = int64(stat.Mtime.Sec)*1e9 + int64(stat.Mtime.Nsec)
-   fi.Ctime_ns = int64(stat.Ctime.Sec)*1e9 + int64(stat.Atime.Nsec)
+   fi.Atime_ns = int64(stat.Go0.Atime.Sec)*1e9 + int64(stat.Go0.Atime.Nsec)
+   fi.Mtime_ns = int64(stat.Go1.Mtime.Sec)*1e9 + int64(stat.Go1.Mtime.Nsec)
+   fi.Ctime_ns = int64(stat.Go2.Ctime.Sec)*1e9 + int64(stat.Go2.Ctime.Nsec)
for i := len(name)-1; i >= 0; i-- {
if name[i] == '/' {
name = name[i+1:]

(BTW: Original calculation of Ctime_ns has a cut'n'paste error,
stat.Ctime.Nsec should be used instead of stat.Atime.Nsec).

Is there a solution for this problem?

Uros.

Re: [RFC PATCH, go]: Port to ALPHA arch - sysinfo.go fixup

2011-04-21 Thread Ian Lance Taylor 
Rainer Orth  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  

* 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

2011-04-07 Thread Rainer Orth 
Ian,

> Rainer Orth  writes:
>
>> I've got a similar issue on IRIX 6.5:  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.

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; }

Rainer

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

Re: [RFC PATCH, go]: Port to ALPHA arch - sysinfo.go fixup

2011-04-03 Thread Uros Bizjak 
On Sat, Apr 2, 2011 at 1:17 AM, Ian Lance Taylor  wrote:
> Rainer Orth  writes:
>
>> I've got a similar issue on IRIX 6.5:  has
>>
>> struct timeval {
>> #if _MIPS_SZLONG == 64
>>       __int32_t :32;
>> #endif
>>       time_t  tv_sec;         /* seconds */
>>       long    tv_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?

For Alpha, it looks like this:

type _timeval struct { tv_sec int64; tv_usec int64; }

where struct stat, as defined in bits/stat.h looks like:

struct stat
  {
...
int __pad0; /* Real padding.  */
__ST_TIME(a);   /* Time of last access.  */
__ST_TIME(m);   /* Time of last modification.  */
__ST_TIME(c);   /* Time of last status change.  */
long __unused[3];
  };

with __ST_TIME defined as:

#ifdef __USE_MISC
# if __GNUC_PREREQ(3,3)
#  define __ST_TIME(X)  \
__extension__ union {   \
struct timespec st_##X##tim;\
struct {\
__time_t st_##X##time;  \
unsigned long st_##X##timensec; \
};  \
}
# else
#  define __ST_TIME(X) struct timespec st_##X##tim
#  define st_atime st_atim.tv_sec
#  define st_mtime st_mtim.tv_sec
#  define st_ctime st_ctim.tv_sec
# endif
#else
# define __ST_TIME(X)   \
__time_t st_##X##time;  \
unsigned long st_##X##timensec
#endif

This results in:

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; _f0 struct { Atime Timespec; }; _f1 struct
{ Mtime Timespec; }; _f2 struct { Ctime Timespec; }; __unused
[2+1]int64; }

Uros.

Re: [RFC PATCH, go]: Port to ALPHA arch

2011-04-03 Thread Uros Bizjak 
On Sat, Apr 2, 2011 at 1:09 AM, Ian Lance Taylor  wrote:
> On Wed, Mar 30, 2011 at 12:58 PM, Uros Bizjak  wrote:
>>
>> Attached ports go to ALPHA architecture.
>
> Thanks!
>
> Committed.
>
>
>> 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...
>
> libgo uses it to support ptrace, which in effect is the same as what
> gdb does.  If mksysinfo.sh is unable to provide any definition for the
> structure, then the choices are either to patch up mksysinfo.sh so
> that it works, or to simply define the structure in
> libgo/syscalls/syscall_linux_alpha.go.  it is unlikely to change so
> the latter seems acceptable if patching mksysinfo is too hard.

Attached patch implements this suggestion and builds libgo without problems.

>> c) some weird issue with double definition of "const _SOCK_NONBLOCK"
>> in gen-sysinfo.go and consequently sysinfo.go.
>
> The code in gcc/godump.c uses a hash table to keep this from
> happening; I'm not sure why that is not working in this case.  Is
> SOCK_NONBLOCK both a #define macro and an enum value?

Yes, SOCK_NONBLOCK is defined in bits/sock.h as

--cut here--
enum __socket_type
{
#undef SOCK_NONBLOCK
  SOCK_NONBLOCK = 0x4000/* Atomically mark descriptor(s) as
   non-blocking.  */
#define SOCK_NONBLOCK SOCK_NONBLOCK
};

/* Get socket manipulation related informations from kernel headers.  */
#include "asm/socket.h"
--cut here--

asm/socket.h:

--cut here--
/* O_NONBLOCK clashes with the bits used for socket types.  Therefore we
 *  have to define SOCK_NONBLOCK to a different value here.
 */
#define SOCK_NONBLOCK   0x4000
--cut here--

Processing bits/socket.h with -fdumo-go-spec= , we get:

// unknowndefine SOCK_NONBLOCK SOCK_NONBLOCK
const _SOCK_NONBLOCK = 0x4000
const _SOCK_NONBLOCK = 1073741824

>
>> The test results from "make -k check" in libgo directory are quite 
>> encouraging:
>
> Yes.
>
>> FAIL: cmath
>> panic: runtime error: integer divide by zero or floating point error
>
> This is peculiar--it looks like there is something systematically
> causing a division by zero.  I wonder what it could be.

I will try to analyse these failures. Perhaps these failures are due
to the fact that alpha needs -mieee to handle NaN and Inf values (a
FPE is generated otherwise).

Thanks,
Uros.
Index: libgo/syscalls/syscall_linux_alpha.go
===
--- libgo/syscalls/syscall_linux_alpha.go   (revision 171911)
+++ libgo/syscalls/syscall_linux_alpha.go   (working copy)
@@ -6,6 +6,38 @@
 
 package syscall
 
+type PtraceRegs struct {
+   R0 uint64
+   R1 uint64
+   R2 uint64
+   R3 uint64
+   R4 uint64
+   R5 uint64
+   R6 uint64
+   R7 uint64
+   R8 uint64
+   R19 uint64
+   R20 uint64
+   R21 uint64
+   R22 uint64
+   R23 uint64
+   R24 uint64
+   R25 uint64
+   R26 uint64
+   R27 uint64
+   R28 uint64
+   Hae uint64
+   Trap_a0 uint64
+   Trap_a1 uint64
+   Trap_a2 uint64
+   Ps uint64
+   Pc uint64
+   Gp uint64
+   R16 uint64
+   R17 uint64
+   R18 uint64
+}
+
 func (r *PtraceRegs) PC() uint64 {
return r.Pc;
 }

Re: [RFC PATCH, go]: Port to ALPHA arch - sysinfo.go fixup

2011-04-01 Thread Ian Lance Taylor 
Rainer Orth  writes:

> I've got a similar issue on IRIX 6.5:  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

2011-04-01 Thread Ian Lance Taylor 
On Wed, Mar 30, 2011 at 1:12 PM, Uros Bizjak  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

2011-04-01 Thread Ian Lance Taylor 
On Wed, Mar 30, 2011 at 12:58 PM, Uros Bizjak  wrote:
>
> Attached ports go to ALPHA architecture.

Thanks!

Committed.


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

libgo uses it to support ptrace, which in effect is the same as what
gdb does.  If mksysinfo.sh is unable to provide any definition for the
structure, then the choices are either to patch up mksysinfo.sh so
that it works, or to simply define the structure in
libgo/syscalls/syscall_linux_alpha.go.  it is unlikely to change so
the latter seems acceptable if patching mksysinfo is too hard.

> c) some weird issue with double definition of "const _SOCK_NONBLOCK"
> in gen-sysinfo.go and consequently sysinfo.go.

The code in gcc/godump.c uses a hash table to keep this from
happening; I'm not sure why that is not working in this case.  Is
SOCK_NONBLOCK both a #define macro and an enum value?

> The test results from "make -k check" in libgo directory are quite 
> encouraging:

Yes.

> FAIL: cmath
> panic: runtime error: integer divide by zero or floating point error

This is peculiar--it looks like there is something systematically
causing a division by zero.  I wonder what it could be.

Ian

Re: [RFC PATCH, go]: Port to ALPHA arch - sysinfo.go fixup

2011-03-31 Thread Rainer Orth 
Uros Bizjak  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:  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

2011-03-30 Thread Uros Bizjak 
On Wed, Mar 30, 2011 at 9:58 PM, Uros Bizjak  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

[RFC PATCH, go]: Port to ALPHA arch

2011-03-30 Thread Uros Bizjak 
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.

The test results from "make -k check" in libgo directory are quite encouraging:

PASS: asn1
PASS: big
PASS: bufio
PASS: bytes
FAIL: cmath
panic: runtime error: integer divide by zero or floating point error
../../../gcc-svn/trunk/libgo/testsuite/gotest: line 356:  1637 Aborted
   ./a.out "$@"
PASS: ebnf
PASS: exec
PASS: expvar
PASS: flag
FAIL: fmt
mallocs per Sprintf(""): 1
mallocs per Sprintf("xxx"): 1
mallocs per Sprintf("%x"): 3
mallocs per Sprintf("%x %x"): 4
panic: runtime error: integer divide by zero or floating point error [recovered]
panic: runtime error: integer divide by zero or floating point error
../../../gcc-svn/trunk/libgo/testsuite/gotest: line 356:  2309 Aborted
   ./a.out "$@"
PASS: gob
PASS: html
FAIL: http
../../../gcc-svn/trunk/libgo/testsuite/gotest: line 356:  3133 Segmentation faul
t  ./a.out "$@"
PASS: io
PASS: json
PASS: log
FAIL: math
panic: runtime error: integer divide by zero or floating point error
../../../gcc-svn/trunk/libgo/testsuite/gotest: line 356:  4321 Aborted
   ./a.out "$@"
PASS: mime
PASS: netchan
PASS: os
PASS: patch
PASS: path
PASS: rand
PASS: reflect
PASS: regexp
FAIL: rpc
2011/03/30 21:31:20 Test RPC server listening on 127.0.0.1:47781
2011/03/30 21:31:20 Test HTTP RPC server listening on 127.0.0.1:59606
2011/03/30 21:31:20 rpc.Serve: accept:accept tcp 127.0.0.1:47781: Resource tempo
rarily unavailable
FAIL: runtime
panic: runtime error: integer divide by zero or floating point error
../../../gcc-svn/trunk/libgo/testsuite/gotest: line 356:  5980 Aborted
   ./a.out "$@"
PASS: scanner
PASS: smtp
PASS: sort
FAIL: strconv
panic: runtime error: integer divide by zero or floating point error
../../../gcc-svn/trunk/libgo/testsuite/gotest: line 356:  6561 Aborted
   ./a.out "$@"
PASS: strings
PASS: sync
PASS: tabwriter
PASS: template
PASS: time
PASS: try
PASS: unicode
PASS: utf16
PASS: utf8
FAIL: websocket
2011/03/30 21:32:19 Test WebSocket server listening on 127.0.0.1:33252
--- FAIL: websocket.TestEcho (0.0 seconds)
dialing dial tcp 127.0.0.1:33252: Connection refused
--- FAIL: websocket.TestEchoDraft75 (0.0 seconds)
dialing dial tcp 127.0.0.1:33252: Connection refused
--- FAIL: websocket.TestWithQuery (0.0 seconds)
dialing dial tcp 127.0.0.1:33252: Connection refused
--- FAIL: websocket.TestWithProtocol (0.0 seconds)
dialing dial tcp 127.0.0.1:33252: Connection refused
--- FAIL: websocket.TestHTTP (0.0 seconds)
Get: error &http.URLError{Op:"Get", URL:"http://127.0.0.1:33252/echo";, E
rror:(*net.OpError)(0xf840026d00)}
--- FAIL: websocket.TestHTTPDraft75 (0.0 seconds)
Get: error &http.URLError{Op:"Get", URL:"http://127.0.0.1:33252/echoDraf
t75", Error:(*net.OpError)(0xf840026c40)}
panic: Dial failed: websocket.Dial ws://127.0.0.1:33252/echo: dial tcp 127.0.0.1
:33252: Connection refused
../../../gcc-svn/trunk/libgo/testsuite/gotest: line 356:  8493 Aborted
   ./a.out "$@"
PASS: xml
PASS: archive/tar
PASS: archive/zip
PASS: compress/bzip2
FAIL: compress/flate
../../../gcc-svn/trunk/libgo/testsuite/gotest: line 356:  9194 Segmentation faul
t  ./a.out "$@"
PASS: compress/gzip
PASS: compress/lzw
PASS: compress/zlib
PASS: container/heap
PASS: container/list
PASS: container/ring
PASS: container/vector
PASS: crypto/aes
PASS: crypto/block
PASS: crypto/blowfish
PASS: crypto/cipher
PASS: crypto/dsa
PASS: crypto/ecdsa
PASS: crypto/elliptic
PASS: crypto/hmac
PASS: crypto/md4
PASS: crypto/md5
PASS: crypto/ocsp
PASS: crypto/openpgp
PASS: crypto/rand
PASS: crypto/rc4
PASS: crypto/ripemd160
PASS: crypto/rsa
PASS: crypto/sha1
PASS: crypto/sha256
PASS: crypto/sha512
PASS: crypto/subtle
PASS: crypto/tls
PASS: crypto/twofish
PASS: crypto/x509
PASS: crypto/xtea
PASS: crypto/openpgp/armor
PASS: crypto/openpgp/packet
PASS: crypto/openpgp/s2k
PASS: debug/dwarf
PASS: debug/elf
PASS: debug/macho
PASS: debug/pe
PASS: encoding/ascii85
PASS: encoding/base32
PASS: encoding/base64
PASS: encoding/binary
PASS: encoding/git85
PASS: encoding/hex
PASS: encoding/line
PASS: encoding/pem
PASS: exp/datafmt
PASS: exp/draw
PASS: exp/eval
PASS: go/parser
PASS: go/printer
PASS: go/scanner
PASS: go/token
PASS: go/typechecker
PASS: hash/adler32
PASS: hash/crc32
PASS: hash/crc64
PASS: hash/fnv
PASS: http/cgi
PASS: image/png
PASS: index/suffixarray
PASS: io/ioutil
PASS: m