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

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

[Uros Bizjak]

[-- Attachment #1: Type: text/plain, Size: 1007 bytes --]

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

[-- Attachment #2: sysinfo.go.diff --]
[-- Type: application/octet-stream, Size: 2293 bytes --]

--- sysinfo.go	2011-03-30 22:02:20.000000000 +0200
+++ sysinfo.go.fixed	2011-03-30 21:33:55.000000000 +0200
@@ -810,7 +810,6 @@
 const _SO_TIMESTAMPING = 37
 const _SCM_TIMESTAMPING = _SO_TIMESTAMPING
 const _SO_RXQ_OVFL = 40
-const _SOCK_NONBLOCK = 0x40000000
 const _IN_CLASSA_NET = 0xff000000
 const _IN_CLASSA_NSHIFT = 24
 const _IN_CLASSA_HOST = (0xffffffff & ^_IN_CLASSA_NET)
@@ -3748,7 +3747,6 @@
 const SOCK_DCCP = _SOCK_DCCP
 const SOCK_PACKET = _SOCK_PACKET
 const SOCK_CLOEXEC = _SOCK_CLOEXEC
-const SOCK_NONBLOCK = _SOCK_NONBLOCK
 const IPPROTO_IP = _IPPROTO_IP
 const IPPROTO_HOPOPTS = _IPPROTO_HOPOPTS
 const IPPROTO_ICMP = _IPPROTO_ICMP
@@ -3834,6 +3832,7 @@
 const PTRACE_EVENT_EXEC = _PTRACE_EVENT_EXEC
 const PTRACE_EVENT_VFORK_DONE = _PTRACE_EVENT_VFORK_DONE
 const PTRACE_EVENT_EXIT = _PTRACE_EVENT_EXIT
+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; }
 type Size_t _size_t
 type Ssize_t _ssize_t
 type Offset_t _off64_t
@@ -3849,7 +3848,7 @@
 type Timespec_sec_t int64
 type Timespec_nsec_t int64
 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; _f0 struct { Atime Timespec; }; _f1 struct { Mtime Timespec; }; _f2 struct { Ctime Timespec; }; __unused [2+1]int64; }
+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; Atime Timespec; Mtime Timespec; Ctime Timespec; __unused [2+1]int64; }
 type Dirent struct { Ino uint64; Off int64; Reclen uint16; Type uint8; Name [255+1]byte; }
 type DIR _DIR
 type Rusage struct { Utime Timeval; Stime Timeval; Maxrss int64; Ixrss int64; Idrss int64; Isrss int64; Minflt int64; Majflt int64; Nswap int64; Inblock int64; Oublock int64; Msgsnd int64; Msgrcv int64; Nsignals int64; Nvcsw int64; Nivcsw int64; }

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

[Rainer Orth]

Uros Bizjak <ubizjak@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 */
	long	tv_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

[Ian Lance Taylor]

On Wed, Mar 30, 2011 at 1:12 PM, Uros Bizjak <ubizjak@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

[Ian Lance Taylor]

Rainer Orth <ro@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 */
> 	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?

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

On Sat, Apr 2, 2011 at 1:17 AM, Ian Lance Taylor <iant@google.com> wrote:
> Rainer Orth <ro@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 */
>>       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 - sysinfo.go fixup

[Rainer Orth]

Ian,

> Rainer Orth <ro@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 */
>> 	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.

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

[Ian Lance Taylor]

[-- Attachment #1: Type: text/plain, Size: 1021 bytes --]

Rainer Orth <ro@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  <iant@google.com>

	* godump.c (go_format_type): Use exported Go name for anonymous
	field name.



[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: patch --]
[-- Type: text/x-diff, Size: 402 bytes --]

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

[Uros Bizjak]

On Fri, Apr 22, 2011 at 1:39 AM, Ian Lance Taylor <iant@google.com> wrote:
> Rainer Orth <ro@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  <iant@google.com>
>
>        * 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

[Ian Lance Taylor]

Uros Bizjak <ubizjak@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; }

> 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

[Ian Lance Taylor]

[-- Attachment #1: Type: text/plain, Size: 659 bytes --]

Uros Bizjak <ubizjak@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


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: patch --]
[-- Type: text/x-diff, Size: 542 bytes --]

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

[Ian Lance Taylor]

[-- Attachment #1: Type: text/plain, Size: 288 bytes --]

Uros Bizjak <ubizjak@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.

Ian


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: patch --]
[-- Type: text/x-diff, Size: 557 bytes --]

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

[Uros Bizjak]

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

[Ian Lance Taylor]

Uros Bizjak <ubizjak@gmail.com> writes:

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

[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

[Ian Lance Taylor]

Mike Stump <mikestump@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]

[-- Attachment #1: Type: text/plain, Size: 3714 bytes --]

On Wed, Jun 1, 2011 at 7:49 PM, Ian Lance Taylor <iant@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.

[-- Attachment #2: a.diff.txt --]
[-- Type: text/plain, Size: 4050 bytes --]

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@
 INSTALL = @INSTALL@
 INSTALL_DATA = @INSTALL_DATA@
 INSTALL_PROGRAM = @INSTALL_PROGRAM@
@@ -1916,7 +1917,9 @@
 	runtime/go-main.c
 
 LTLDFLAGS = $(shell $(SHELL) $(top_srcdir)/../libtool-ldflags $(LDFLAGS))
-AM_GOCFLAGS = $(STRINGOPS_FLAG)
+
+# Some targets require additional compiler options for IEEE compatibility.
+AM_GOCFLAGS = $(STRINGOPS_FLAG) $(IEEE_FLAGS)
 GOCOMPILE = $(GOC) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_GOCFLAGS) $(GOCFLAGS)
 LTGOCOMPILE = $(LIBTOOL) --tag GO --mode=compile $(GOC) $(INCLUDES) \
 	$(AM_GOCFLAGS) $(GOCFLAGS)
@@ -1937,7 +1940,7 @@
 
 # Check a package.
 CHECK = \
-	GC="$(GOC) -L `${PWD_COMMAND}` -L `${PWD_COMMAND}`/.libs"; \
+	GC="$(GOC) $(IEEE_FLAGS) -L `${PWD_COMMAND}` -L `${PWD_COMMAND}`/.libs"; \
 	export GC; \
 	RUNTESTFLAGS="$(RUNTESTFLAGS)"; \
 	export RUNTESTFLAGS; \
Index: testsuite/Makefile.in
===================================================================
--- testsuite/Makefile.in	(revision 175840)
+++ testsuite/Makefile.in	(working copy)
@@ -88,6 +88,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@
 INSTALL = @INSTALL@
 INSTALL_DATA = @INSTALL_DATA@
 INSTALL_PROGRAM = @INSTALL_PROGRAM@
Index: configure.ac
===================================================================
--- configure.ac	(revision 175840)
+++ configure.ac	(working copy)
@@ -279,6 +279,14 @@
 esac
 AC_SUBST(OSCFLAGS)
 
+dnl Some targets require additional compiler options for NaN/Inf.
+case "${host_cpu}" in
+  alpha*)
+    IEEE_FLAGS="-mieee"
+    ;;
+esac
+AC_SUBST(IEEE_FLAGS)
+
 dnl Use -fsplit-stack when compiling C code if available.
 AC_CACHE_CHECK([whether -fsplit-stack is supported],
 [libgo_cv_c_split_stack_supported],
Index: Makefile.am
===================================================================
--- Makefile.am	(revision 175840)
+++ Makefile.am	(working copy)
@@ -1595,6 +1595,10 @@
 
 GOCFLAGS = $(CFLAGS)
 AM_GOCFLAGS = $(STRINGOPS_FLAG)
+
+# Some targets require additional compiler options for IEEE compatibility.
+AM_GOCFLAGS += $(IEEE_FLAGS)
+
 GOCOMPILE = $(GOC) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_GOCFLAGS) $(GOCFLAGS)
 
 LTGOCOMPILE = $(LIBTOOL) --tag GO --mode=compile $(GOC) $(INCLUDES) \
@@ -1619,7 +1623,7 @@
 
 # Check a package.
 CHECK = \
-	GC="$(GOC) -L `${PWD_COMMAND}` -L `${PWD_COMMAND}`/.libs"; \
+	GC="$(GOC) $(IEEE_FLAGS) -L `${PWD_COMMAND}` -L `${PWD_COMMAND}`/.libs"; \
 	export GC; \
 	RUNTESTFLAGS="$(RUNTESTFLAGS)"; \
 	export RUNTESTFLAGS; \

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

[Mike Stump]

On Jul 5, 2011, at 9:51 AM, Uros Bizjak <ubizjak@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

[Uros Bizjak]

On Tue, Jul 5, 2011 at 7:17 PM, Mike Stump <mikestump@comcast.net> wrote:
> On Jul 5, 2011, at 9:51 AM, Uros Bizjak <ubizjak@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

[Ian Lance Taylor]

Uros Bizjak <ubizjak@gmail.com> 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 gotestNNNN 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

[Uros Bizjak]

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

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

[Ian Lance Taylor]

Uros Bizjak <ubizjak@gmail.com> writes:

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

[Uros Bizjak]

On Wed, Jul 6, 2011 at 7:34 PM, Ian Lance Taylor <iant@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.