[Darwin] Do not enable -fvar-tracking at -O0

Hi,

this is a regression present on the mainline and 4.7 branch.  -fvar-tracking 
is automatically enabled on Darwin when -g is passed, including at -O0.  This 
results in bloated and incomplete debug info.

This comes from a latent issue in the handling of flag_var_tracking_uninit in 
the Darwin back-end, which wasn't updated for the new option machinery.

Tested on x86_64-apple-darwin10.8.0, OK for mainline and 4.7 branch?


2012-11-09  Eric Botcazou  <ebotcazou@adacore.com>

	* common.opt (fvar-tracking-uninit): Document.
	* toplev.c (process_options): Fix handling of flag_var_tracking_uninit.
	* config/darwin.c (darwin_override_options): Likewise.

On Fri, Nov 09, 2012 at 10:42:45AM +0100, Eric Botcazou wrote:
> Hi,
> 
> this is a regression present on the mainline and 4.7 branch.  -fvar-tracking 
> is automatically enabled on Darwin when -g is passed, including at -O0.  This 
> results in bloated and incomplete debug info.
> 
> This comes from a latent issue in the handling of flag_var_tracking_uninit in 
> the Darwin back-end, which wasn't updated for the new option machinery.

Eric,
   Is this a hack around the underlying problem on darwin or the implementation
of the same approach used on other targets? If the former, shouldn't we have a
PR opened to properly fix this in the long term?
             Jack

> 
> Tested on x86_64-apple-darwin10.8.0, OK for mainline and 4.7 branch?
> 
> 
> 2012-11-09  Eric Botcazou  <ebotcazou@adacore.com>
> 
> 	* common.opt (fvar-tracking-uninit): Document.
> 	* toplev.c (process_options): Fix handling of flag_var_tracking_uninit.
> 	* config/darwin.c (darwin_override_options): Likewise.
> 
> 
> -- 
> Eric Botcazou
> Index: toplev.c
> ===================================================================
> --- toplev.c	(revision 193322)
> +++ toplev.c	(working copy)
> @@ -1416,12 +1416,15 @@ process_options (void)
>    /* If the user specifically requested variable tracking with tagging
>       uninitialized variables, we need to turn on variable tracking.
>       (We already determined above that variable tracking is feasible.)  */
> -  if (flag_var_tracking_uninit)
> +  if (flag_var_tracking_uninit == 1)
>      flag_var_tracking = 1;
>  
>    if (flag_var_tracking == AUTODETECT_VALUE)
>      flag_var_tracking = optimize >= 1;
>  
> +  if (flag_var_tracking_uninit == AUTODETECT_VALUE)
> +    flag_var_tracking_uninit = flag_var_tracking;
> +
>    if (flag_var_tracking_assignments == AUTODETECT_VALUE)
>      flag_var_tracking_assignments = flag_var_tracking
>        && !(flag_selective_scheduling || flag_selective_scheduling2);
> Index: common.opt
> ===================================================================
> --- common.opt	(revision 193322)
> +++ common.opt	(working copy)
> @@ -2189,6 +2189,10 @@ fvar-tracking-assignments-toggle
>  Common Report Var(flag_var_tracking_assignments_toggle) Optimization
>  Toggle -fvar-tracking-assignments
>  
> +; Positive if we should track uninitialized variables, negative if
> +; we should run the var-tracking pass only to discard debug
> +; annotations.  When flag_var_tracking_uninit == AUTODETECT_VALUE it
> +; will be set according to flag_var_tracking.
>  fvar-tracking-uninit
>  Common Report Var(flag_var_tracking_uninit) Optimization
>  Perform variable tracking and also tag variables that are uninitialized
> Index: config/darwin.c
> ===================================================================
> --- config/darwin.c	(revision 193322)
> +++ config/darwin.c	(working copy)
> @@ -3038,12 +3038,12 @@ darwin_override_options (void)
>        darwin_emit_branch_islands = true;
>      }
>  
> -  if (flag_var_tracking
> +  if (flag_var_tracking_uninit == 0
>        && generating_for_darwin_version >= 9
>        && (flag_gtoggle ? (debug_info_level == DINFO_LEVEL_NONE)
>        : (debug_info_level >= DINFO_LEVEL_NORMAL))
>        && write_symbols == DWARF2_DEBUG)
> -    flag_var_tracking_uninit = 1;
> +    flag_var_tracking_uninit = flag_var_tracking;
>  
>    if (MACHO_DYNAMIC_NO_PIC_P)
>      {

>    Is this a hack around the underlying problem on darwin or the
> implementation of the same approach used on other targets? If the former,
> shouldn't we have a PR opened to properly fix this in the long term?

Neither, it's a fix and other targets don't care about -fvar-tracking-uninit.

On Nov 9, 2012, at 1:42 AM, Eric Botcazou <ebotcazou@adacore.com> wrote:
> this is a regression present on the mainline and 4.7 branch.  -fvar-tracking 
> is automatically enabled on Darwin when -g is passed, including at -O0.  This 
> results in bloated and incomplete debug info.

> OK for mainline and 4.7 branch?

Ok.

Thank you Jack, almost missed this.