[m-rev.] For review: Fix crashes in parallel grades with gcc 4.6+ (bug #294)

[Julien Fischer]

Hi Paul,

On Thu, 5 Sep 2013, Paul Bone wrote:

> For review by Julien (I've been discussing the bug with him already).  I
> propose to commit this to the release branch.

The only reason 13.05.2 hasn't been released is you told me to wait for
this.

> Fix crashes in parallel grades with gcc 4.6+ (bug #294)

I suggest s/fix/workaround/ since fixing this properly would require
understanding exactly why it's not working.

> configure.ac:
>    Test for and enable --fno-reorder-functions which fixes this issue.
> ---
> configure.ac | 33 +++++++++++++++++++++++++++++++++
> 1 file changed, 33 insertions(+)
>
> diff --git a/configure.ac b/configure.ac
> index 1a01d5e..a1c0d53 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -918,6 +918,17 @@ else
>     CFLAGS_FOR_NO_MOVE_LOOP_INVARIANTS=
> fi
>
> +AC_MSG_CHECKING(whether we can use -fno-reorder-functions)
> +if $CC -fno-reorder-functions -c conftest.c \
> +    </dev/null >&AC_FD_CC 2>&1
> +then
> +    AC_MSG_RESULT(yes)
> +    CFLAGS_FOR_NO_REORDER_FUNCTIONS="-fno-reorder-functions"
> +else
> +    AC_MSG_RESULT(no)
> +    CFLAGS_FOR_NO_REORDER_FUNCTIONS=""
> +fi
> +
> rm -f conftest*
>
> #-----------------------------------------------------------------------------#
> @@ -2421,6 +2432,11 @@ AC_SUBST(MR_DARWIN_SETJMP_WORKAROUND)
> # For x86, x86-64 and possibly other architectures, when using non-local
> # gotos with gcc 4.x we need `-fno-move-loop-invariants'.
> #
> +# For x86-64 and possibly other architectures, when using gcc specific
> +# features and parallelism with gcc 4.6 and 4.7 (and possibly future
> +# versions), we need -fno-reorder-functions.  We don't yet know exactly

That comment should say *why* we need to use -fno-reorder-functions,
e.g. otherwise programs built in parallel grades with stack segments can
cause segmentation faults ...

> +# which grades are affected.
> +#
> # For alpha, mips, and ARM, and probably on other architectures, when using
> # non-local gotos we need -fomit-frame-pointer, otherwise when compiling
> # with --no-c-optimize we run into a problem similar to the one above:
> @@ -2541,6 +2557,23 @@ case "$ac_cv_prog_gcc" in yes)
>     esac
>     ;;
> esac
> +
> +# Determine if $CFLAGS_FOR_NO_REORDER_FUNCTIONS is needed.
> +case "$C_COMPILER_TYPE" in
> +    # Check if the option is not required, and otherwise include the option.
> +    # No need to check gcc < 3.3 as the option didn't exist.
> +    gcc_3 | gcc_4_1* | gcc_4_2* | gcc_4_3* | gcc_4_4* | gcc_4_5*)

I think the first alternative there should be "gcc_3*".
C_COMPILER_TYPE will never match against "gcc_3".

> +        ;;
> +    *)
> +        # DIsable this in both sets of CFLAGS.  Right now we only know that

s/DIsable/Disable.

> +        # this makes asm_fast.gc.par.stseg work.  There is at least one
> +        # other bug affecting reg.gc.par.stseg so I can't yet determine if
> +        # this also affects that grade.  See bug #294.

However, I suggest:

 	   # XXX Pass -fno-reorder-functions when using GCC 4.6 onwards
 	   # with the global register or non-local goto extensions.
 	   # This works around problems in *.par.stseg* grades.
 	   # (See bug #294 for further details.)

Cheers,
Julien.