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 Thu, Oct 08, 2015 at 12:38:15AM -0700, Garrett Cooper wrote:
> 
> > 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 ;/..

Your statement does not make any sense.  Re-read what I tell above.
The __other field is not written by code, the code does not change
by the matter of being run on Intel or AMD processors.  It just happens
so that on one of your system the stack are seems to be zero, while on
another, it does not.