Re: Problems with packages on a netbsd-6 sparc

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

> Looking at it in gdb it certainly looks like a mis-aligned access.
> But, I'm not sure what "<optimized out>" means.

> 0x00024e24 in make_pwitem (pw=0x204a7aa8, name=0x0) at ./pwutil.c:178
> 178         memcpy(newpw, pw, sizeof(struct passwd));
> (gdb) print newpw
> $1 = <optimized out>
> (gdb) print pw
> $2 = (const struct passwd *) 0x204a7aa8

It means the variable is not stored anywhere at that point, because the
optimizer determined it didn't need to exist.  Most likely it has gone
dead (in the data-flow sense), but I can imagine other possibilities.

I'm not sure why you think this means it's misaligned.  While I'm not
certain, I think sparc32 has no types requiring stricter than 8-byte
alignment, meaning 204a7aa8 is suitably aligned for anything.  Looking
at struct passwd, I don't see any types there which I would expect to
be wider than 8 bytes, though, admittedly, I'm not looking at the -6
<pwd.h>.

> I'll take a look at the code directly, but I still don't understand
> how it could be a code bug, rather than an optimizer bug, that only
> shows when code is optimized.

Code that depends on things C does not promise will not infrequently
"work" when unoptimized but break when optimized, or vice versa.  But,
in such a case, the problem is the code depending on something not
promised, not a bug in the optimizer.

As a simple example of code which is likely to change its behaviour
when optimiized even with a non-buggy optimizer, consider

        a = arr[i++] + arr[i++];

This is off in undefined-behaviour weeds (it violates 6.5 #2), and the
machine code it compiles to, if it compiles at all, is (formally)
permitted to behave in any way it pleases.  This includes producing
different behaviour depending on the time of day, the geographical
location of the user, or...whether optimization was turned on.

Admittedly, behaviour depending on the user's location is unlikely,
since few implementations have access to that information, but it is
permitted by the language spec.  Bringing it back to _likely_ results,
it is reasonably likely that an uoptimized compile might produce the
equivalent of

        tmp1 = arr[i++];
        tmp2 = arr[i++];
        a = tmp1 + tmp2;

while an optimized compile might produce the equivalent of

        a = arr[i] + arr[i];
        i += 2;

or

        i += 2;
        a = arr[i-1] + arr[i-1];

or even

        a = arr[i] + arr[i];
        i ++;

Depending on what the code's author intended, any of these might
constitute "working" in the sense of producing the desired effect, with
others "breaking".  Yet this is not a bug in the optimizer; it's a bug
in the code.

/~\ The ASCII                             Mouse
\ / Ribbon Campaign
 X  Against HTML                mouse%rodents-montreal.org@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B