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

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.

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

Commit Message

Comments

Patch