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

[Garrett Cooper]

> On Oct 8, 2015, at 00:24, Konstantin Belousov <kostikbel at gmail.com> wrote:
> 
> 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.

Hi kib!

Ok -- that's what my gut was telling me when I was reading the spec, but I needed a second opinion. Interesting how Intel leaves the __other field alone and AMD [opterons] don't ;/..

Thanks :)!
-NGie