Comparing behavior of test-fesetenv.c on AMD Opterons and Intel Xeons: running FNSTENV on Opteron -- should it zero out __x87.__other?

[Konstantin Belousov]

On Wed, Oct 07, 2015 at 05:52:56PM -0700, NGie Cooper wrote:
I removed a lot of text which I am unable to parse.

> Assertion failed: (memcmp(&env, FE_DFL_ENV, sizeof(env)) == 0),
> function test_dfl_env, file test-fenv.c, line 136.
> 
> Program received signal SIGABRT, Aborted.
> 0x0000000800b842ca in kill () from /lib/libc.so.7
> (gdb) frame 3
> #3  0x0000000000400ec9 in test_dfl_env () at test-fenv.c:136
> 136             assert(memcmp(&env, FE_DFL_ENV, sizeof(env)) == 0);
> (gdb) p env
> $1 = {__x87 = {__control = 4294902655, __status = 4294901760, __tag =
> 4294967295, __other = "W\224}\200
> \000\004\001\250\244D\201;\000\377\377"}, __mxcsr = 8064}
> (gdb) p ((fenv_t)__fe_dfl_env)
> $2 = {__x87 = {__control = 4294902655, __status = 4294901760, __tag =
> 4294967295, __other = '\000' <repeats 14 times>, "\377\377"}, __mxcsr
> = 8064}

This test is wrong.  The __other member of the struct fenv_t is not filled
by fegetenv(), so it content retains a stack garbage that was there before
the call.  On the other hand, FE_DFL_ENV is explicitely initialized with
zeroes.

Test must be fixed to compare only meaningful fields of two environments.