ARM FreeBSD fix bootstrap

Hi all,

the commit for PR68617 broke boostrap on armv6*-*-freebsd*.

We still have unaligned_access = 0 on armv6 here on FreeBSD.

The commit from the above PR overrides my SUBTARGET_OVERRIDE_OPTIONS I 
called in arm_option_override. And it sets the unaligned_access to 1.

The attached patch fixes this, bootstrap ongoing but passed the breaking 
stage where genmddeps bus errored.

Is this patch ok for trunk once bootstrap completes?

TIA,
Andreas

2015-12-22  Andreas Tobler  <andreast@gcc.gnu.org>

	* config/arm/freebsd.h (SUBTARGET_OVERRIDE_OPTIONS): Adjust to
	check unaligned_access on the gcc_options set.
	* config/arm/arm.c (arm_option_override): Move
	SUBTARGET_OVERRIDE_OPTIONS from here to
	(arm_option_override_internal).

On 22/12/15 19:53, Andreas Tobler wrote:
> Hi all,
> 
> the commit for PR68617 broke boostrap on armv6*-*-freebsd*.
> 
> We still have unaligned_access = 0 on armv6 here on FreeBSD.
> 
> The commit from the above PR overrides my SUBTARGET_OVERRIDE_OPTIONS I
> called in arm_option_override. And it sets the unaligned_access to 1.
> 
> The attached patch fixes this, bootstrap ongoing but passed the breaking
> stage where genmddeps bus errored.
> 
> Is this patch ok for trunk once bootstrap completes?
> 
> TIA,
> Andreas
> 
> 2015-12-22  Andreas Tobler  <andreast@gcc.gnu.org>
> 
>     * config/arm/freebsd.h (SUBTARGET_OVERRIDE_OPTIONS): Adjust to
>     check unaligned_access on the gcc_options set.
>     * config/arm/arm.c (arm_option_override): Move
>     SUBTARGET_OVERRIDE_OPTIONS from here to
>     (arm_option_override_internal).
> 

Moving this hunk to a different place potentially affects VXWORKS (the
only other target that uses this hook).  I'd like to see confirmation
from the VxWorks maintainers (Nathan?) that this doesn't cause any
problems for them.  If it does, then I think you need to create a new
subtarget hook (SUBTARGET_OVERRIDE_INTERNAL_OPTIONS?) and change FreeBSD
to use that rather than the existing hook.

R.

> 
> x_opts_unaligned.diff
> 
> 
> Index: config/arm/freebsd.h
> ===================================================================
> --- config/arm/freebsd.h	(revision 231903)
> +++ config/arm/freebsd.h	(working copy)
> @@ -122,8 +122,8 @@
>  
>  #define SUBTARGET_OVERRIDE_OPTIONS		\
>  do {						\
> -    if (unaligned_access)			\
> -	unaligned_access = 0;			\
> +    if (opts->x_unaligned_access)		\
> +	opts->x_unaligned_access = 0;		\
>  } while (0)
>  
>  #undef MAX_SYNC_LIBFUNC_SIZE
> Index: config/arm/arm.c
> ===================================================================
> --- config/arm/arm.c	(revision 231903)
> +++ config/arm/arm.c	(working copy)
> @@ -2954,6 +2954,10 @@
>    /* Thumb2 inline assembly code should always use unified syntax.
>       This will apply to ARM and Thumb1 eventually.  */
>    opts->x_inline_asm_unified = TARGET_THUMB2_P (opts->x_target_flags);
> +
> +#ifdef SUBTARGET_OVERRIDE_OPTIONS
> +  SUBTARGET_OVERRIDE_OPTIONS;
> +#endif
>  }
>  
>  /* Fix up any incompatible options that the user has specified.  */
> @@ -2976,10 +2980,6 @@
>    if (global_options_set.x_arm_tune_option)
>      arm_selected_tune = &all_cores[(int) arm_tune_option];
>  
> -#ifdef SUBTARGET_OVERRIDE_OPTIONS
> -  SUBTARGET_OVERRIDE_OPTIONS;
> -#endif
> -
>    if (arm_selected_arch)
>      {
>        if (arm_selected_cpu)
>

On 12/23/15 05:22, Richard Earnshaw (lists) wrote:

>> 2015-12-22  Andreas Tobler  <andreast@gcc.gnu.org>
>>
>>      * config/arm/freebsd.h (SUBTARGET_OVERRIDE_OPTIONS): Adjust to
>>      check unaligned_access on the gcc_options set.
>>      * config/arm/arm.c (arm_option_override): Move
>>      SUBTARGET_OVERRIDE_OPTIONS from here to
>>      (arm_option_override_internal).
>>
>
> Moving this hunk to a different place potentially affects VXWORKS (the
> only other target that uses this hook).  I'd like to see confirmation
> from the VxWorks maintainers (Nathan?) that this doesn't cause any
> problems for them.  If it does, then I think you need to create a new
> subtarget hook (SUBTARGET_OVERRIDE_INTERNAL_OPTIONS?) and change FreeBSD
> to use that rather than the existing hook.


thanks for thinking of that.  Off hand I can't see this being a problem, and if 
we discover it is, we can address it then.

nathan