[gccgo] weird constant values in sysinfo.go

[Xiangdong JI]

Hello,

The .go files generated during building gccgo seem to have a few constants with weird values, for example:

// sysinfo.go (on x86-64, latest gcc-9 trunk)

const ___FLT128_MAX__ = 1.1

const ___FLT32X_DENORM_MIN__ = 1.1

as a comparison, gollvm generates expected values.

Could it be caused by incorrect building setting? 

Thanks. 

[Than McIntosh]

Hi,

Thanks for the heads-up. 

I also see what you're seeing for my build, and this is a mystery for me as well.

The libgo makefile generates "sysinfo.go" by running the C compiler on a source that includes various system headers, so as to capture Go versions of C-specific constants and types. This is done using the -fdump-go-spec=<outfile> command line option.

I ran GCC under the debugger and looked at the value for FLT128_MAX at the point where the go-dumpspec code executes, and it is indeed "1.1", so I don't think this is a bug in the Go-specific code.  What's more surprising is that when I start with the same compile command used to generate the Go file, remove "-fdump-go-spec, and add in "-E -dM", I do see a correct definition for FLT128_MAX (very weird). 

Given that Go doesn't use float128, I'm not sure it will really matter a whole lot in the long run, but it is a surprising oddity.

Thanks, Than

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/b808ccdd-023c-4b95-9db0-2a00b3435735%40googlegroups.com.

[Xiangdong JI]

Thanks for looking into the issue, previously I thought it was a setting issue of my environment as both the two and a few others were set to 1.1.  

Inspired by your debugging, it turns out 'cpp' will delay the evaluation of a few macros of float point value, in function builtin_define_with_hex_fp_value (c-cppbuiltin.c).

Just a hack, passing option '-dN' to the command line for generating tmp-gen-sysinfo.go sort of works, 20 out of the 28 constants in tmp-gen-sysinfo.go having the value "1.1" are assigned desired values, while the other 8 are marked "unknowndefine", perhaps adding the dump-go-spec flag check is a better solution. 

Enclosing the two versions of tmp-gen-sysinfo.go.  

//code snippet in gcc-9.1.0/gcc/c-family/c-cppbuiltin.c

1643          /* This is very expensive, so if possible expand them lazily.  */

1644          if (lazy_hex_fp_value_count < LAZY_HEX_FP_VALUES_CNT

1645              && flag_dump_macros == 0

1646              && !cpp_get_options (parse_in)->traditional)

1647            {

1648              if (lazy_hex_fp_value_count == 0)

1649                cpp_get_callbacks (parse_in)->user_lazy_macro = lazy_hex_fp_value;

1650              sprintf (buf2, fp_cast, "1.1");

1651              sprintf (buf1, "%s=%s", macro, buf2);

On Tuesday, August 13, 2019 at 8:59:45 PM UTC+8, Than McIntosh wrote:

Hi,

Thanks for the heads-up. 

I also see what you're seeing for my build, and this is a mystery for me as well.

The libgo makefile generates "sysinfo.go" by running the C compiler on a source that includes various system headers, so as to capture Go versions of C-specific constants and types. This is done using the -fdump-go-spec=<outfile> command line option.

I ran GCC under the debugger and looked at the value for FLT128_MAX at the point where the go-dumpspec code executes, and it is indeed "1.1", so I don't think this is a bug in the Go-specific code.  What's more surprising is that when I start with the same compile command used to generate the Go file, remove "-fdump-go-spec, and add in "-E -dM", I do see a correct definition for FLT128_MAX (very weird). 

Given that Go doesn't use float128, I'm not sure it will really matter a whole lot in the long run, but it is a surprising oddity.

Thanks, Than

On Mon, Aug 12, 2019 at 11:21 PM Xiangdong JI <xiang...@arm.com> wrote:

Hello,

The .go files generated during building gccgo seem to have a few constants with weird values, for example:

// sysinfo.go (on x86-64, latest gcc-9 trunk)

const ___FLT128_MAX__ = 1.1

const ___FLT32X_DENORM_MIN__ = 1.1

as a comparison, gollvm generates expected values.

Could it be caused by incorrect building setting? 

Thanks. 

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.

To unsubscribe from this group and stop receiving emails from it, send an email to golan...@googlegroups.com.

[Ian Lance Taylor]

Per later discussion, this problem is fixed by this patch.
Bootstrapped and ran full testsuite on x86_64-pc-linux-gnu.

OK for mainline?

Ian


2019-08-20 Ian Lance Taylor <ia...@golang.org>

* c-cppbuiltin.c (builtin_define_with_hex_fp_value): Always expand
when using -fgo-dump-spec.

[Xiangdong JI]

Thanks a lot, Ian. the schedule is fine. 

On Wednesday, August 21, 2019 at 7:37:10 AM UTC+8, Ian Lance Taylor wrote:

[Ian Lance Taylor]

Ping Joseph Myers as C frontend maintainer.

Ian

[Joseph Myers]

On Tue, 3 Sep 2019, Ian Lance Taylor wrote:

> > * c-cppbuiltin.c (builtin_define_with_hex_fp_value): Always expand
> > when using -fgo-dump-spec.
>
> Ping Joseph Myers as C frontend maintainer.

This patch is OK.

--
Joseph S. Myers
jos...@codesourcery.com