Work around GCC 4.8 aggressive loop optimization.

[dweeezil]

GCC >+ 4.8's aggressive loop optimization breaks some of the iterators
over the dn_blkptr[] pseudo-array in dnode_phys. Since dn_blkptr[] is
defined as a single-element array, GCC believes an iterator can only
access index 0 and will unroll the loop into a single iteration.

This commit works around the optimization by casting the array to a
pointer and is definitely a hack. It fixes all obvious iterators that
might break, however, the only loop where it was known to cause problems
was this loop in dmu_objset_write_ready():

    for (i = 0; i < dnp->dn_nblkptr; i++)
            bp->blk_fill += dnp->dn_blkptr[i].blk_fill;

In the common case where dn_nblkptr is 3, the loop is only executed a
single time and "i" is equal to 1 following the loop.

The specific breakage cause by this problem is that the blk_fill of
root block pointers wouldn't be set properly when more than one blkptr
is in use (when no indrect blocks are needed).

The simple reproducing sequence is:

zpool create tank /tank.img
zdb -ddddd tank 0

and notice that "fill=31", however, there are two L0 indirect blocks with
"F=31" and "F=5". The fill count should be 36 rather than 35. This problem
causes an assert to be hit in a simple "zdb tank" when built with --enable-debug.

[dweeezil]

I don't seriously expect my hack in this pull request to wind up as the production solution, however, it is something that works in the mean time for systems what use gcc 4.8. I suspect it's going to be a better idea to simply compile everything with -fno-aggressive-loop-optimizations. I'm mainly submitting this pull request to trigger an issue related to the problem and to present a workaround.

[behlendorf]

@dweeezil As hacks go I've seen far worse. But what worries me is that in fact there are move cases in the code like this. We should just outright disable aggressive loop optimization if this is a problem. This can be done in a similar way to ZFS_AC_CONFIG_ALWAYS_NO_UNUSED_BUT_SET_VARIABLE and then added in to Rules.am. If you like, I can propose a patch to the build system for this.

[dweeezil]

@behlendorf If you could, please, that would be appreciated. I'm not terribly good with the autotools system (but I did look into it for this issue). We'd like to add -fno-aggressive-loop-optimizations to all builds when gcc >= 4.8 is in use.

So far, I've not found any other variable-sized arrays that will cause this problem. GCC Does The Right Thing when the variable array is the last member of the structure. That said, however, it's definitely a timebomb waiting to go off.

Matt Ahrens contacted me in a reply to my posting of this on the OpenZFS developers list that it might be a proper fix to convert the end of the dnode_phys_t to a union:

union {
  blkptr_t dn_blkptr[3];
  struct {
    blkptr_t dn_blkptr[1];
    uint8_t dn_bonus[DN_MAX_BONUSLEN];
  } dn_with_bonus;
  struct {
    blkptr_t dn_blkptr[1];
    uint8_t dn_bonus[DN_MAX_BONUSLEN - sizeof (blkptr_t)];
    blkptr_t dn_spill;
  } dn_with_spill;
} dn_u;

Of course, that would likely require changing a whole lot of code.

[behlendorf]

@dweeezil Can you please review #2051. It implements the build system changes to disable aggressive loop optimization we discussed. It still may be nice to rework the code as a union to avoid the issue but as you said that likely requires changing a whole lot of code.