zfs/config/always-no-aggressive-loop-o...

dnl #
dnl # Check if gcc supports -fno-aggressive-loop-optimizations
dnl #
AC_DEFUN([ZFS_AC_CONFIG_ALWAYS_NO_AGGRESSIVE_LOOP_OPTIMIZATIONS], [
	AC_MSG_CHECKING([for -fno-aggressive-loop-optimizations support])

	saved_flags="$CFLAGS"
	CFLAGS="$CFLAGS -fno-aggressive-loop-optimizations"

	AC_RUN_IFELSE([AC_LANG_PROGRAM([], [])], [
		NO_AGGRESSIVE_LOOP_OPTIMIZATIONS=-fno-aggressive-loop-optimizations
		AC_MSG_RESULT([yes])
	], [
		NO_AGGRESSIVE_LOOP_OPTIMIZATIONS=
		AC_MSG_RESULT([no])
	])

	CFLAGS="$saved_flags"
	AC_SUBST([NO_AGGRESSIVE_LOOP_OPTIMIZATIONS])
])
Disable GCCs aggressive loop optimization 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. One way to resolve the issue would be to cast the array to a pointer and fix all the iterators that might break. The only loop where it is known to cause a problem is 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 caused 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 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 31. This problem causes an assert to be hit in a simple "zdb tank" when built with --enable-debug. However, this approach was not taken because we need to be absolutely sure we catch all instances of this unwanted optimization. Therefore, the build system has been updated to detect if GCC supports the aggressive loop optimization. If it does the optimization will be explicitly disabled using the -fno-aggressive-loop-optimization option. Original-fix-by: Tim Chase <tim@chase2k.com> Signed-off-by: Tim Chase <tim@chase2k.com> Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Closes #2010 Closes #2051 2014-01-14 17:39:13 +00:00			`dnl #`
			`dnl # Check if gcc supports -fno-aggressive-loop-optimizations`
			`dnl #`
			`AC_DEFUN([ZFS_AC_CONFIG_ALWAYS_NO_AGGRESSIVE_LOOP_OPTIMIZATIONS], [`
			`AC_MSG_CHECKING([for -fno-aggressive-loop-optimizations support])`

			`saved_flags="$CFLAGS"`
			`CFLAGS="$CFLAGS -fno-aggressive-loop-optimizations"`

			`AC_RUN_IFELSE([AC_LANG_PROGRAM([], [])], [`
			`NO_AGGRESSIVE_LOOP_OPTIMIZATIONS=-fno-aggressive-loop-optimizations`
			`AC_MSG_RESULT([yes])`
			`], [`
			`NO_AGGRESSIVE_LOOP_OPTIMIZATIONS=`
			`AC_MSG_RESULT([no])`
			`])`

			`CFLAGS="$saved_flags"`
			`AC_SUBST([NO_AGGRESSIVE_LOOP_OPTIMIZATIONS])`
			`])`