[Bug c/84100] [7 Regression] Function __attribute__((optimize(align-loops=32))) gives spurious warning and is ignored

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84100

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to work|6.4.0                       |
   Target Milestone|7.4                         |9.0
            Summary|[7 Regression] Function     |[7 Regression] Function
                   |__attribute__((optimize(ali |__attribute__((optimize(ali
                   |gn-loops=32))) gives        |gn-loops=32))) gives
                   |spurious warning            |spurious warning and is
                   |                            |ignored
      Known to fail|                            |6.4.0, 8.0

--- Comment #10 from Martin Liška <marxin at gcc dot gnu.org> ---
Ok, so I've spent quite some time on it and it's not easy. Problem is that we
have default values for max skips that live here:

flags.h:
struct target_flag_state {
  /* Values of the -falign-* flags: how much to align labels in code.
     0 means `use default', 1 means `don't align'.
     For each variable, there is an _log variant which is the power
     of two not less than the variable, for .align output.  */
  int x_align_loops_log;
  int x_align_loops_max_skip;
  int x_align_jumps_log;
  int x_align_jumps_max_skip;
  int x_align_labels_log;
  int x_align_labels_max_skip;
  int x_align_functions_log;

  /* The excess precision currently in effect.  */
  enum excess_precision x_flag_excess_precision;
};

which is a target structure. Currently ix86_default_align is called as
ix86_override_options_after_change hook. But problem with the hook is that we
are unable to distinguish between an option set by used (-falign-function=xyz),
or whether the default value was set in ix86_default_align after options were
processed.

That said, the proper solution should be have both values as field of 'struct
gcc_options'. That's probably done in
https://gcc.gnu.org/ml/gcc-patches/2017-04/msg00720.html which was not merged
yet.

I'll return to it in next stage1.