https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91406
Bug ID: 91406
Summary: gcc -Q -v lies about what flags are enabled
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: driver
Assignee: unassigned at gcc dot gnu.org
Reporter: sje at gcc dot gnu.org
Target Milestone: ---
If you run 'gcc -Q -v x.c' and look at the 'options enabled:' list, it is not
accurate. For example, on aarch64 it will show '-fprefetch-loop-arrays' which
is not on by default for a generic aarch64 compiles (even at -O3). The problem
is that this flag is initialized to -1 and it might be overridden by
aarch64_override_options_internal in some cases to turn it on but if it is not
overridden it stays at -1 and then option_enabled (opts-common.c) checks
to see if it is zero or not-zero and if not-zero it returns true and says it
is enabled. Note that in this case the compiler will not actually generate
prefetch instructions because the gate function is checking for 'x > 0', not
'x != 0' like option_enabled does.
This can affect any option in commons.opt (or elsewhere) that is initialized to
-1. There are also flags that are initialized to 1 but probably should not
show up if compiling at -O0 because in that case the pass that would check the
flag is never called, such as -faggressive-loop-optimizations for example. If
you run a '-Q -v -O0' compilation on x86 the list of enabled options will
include -faggressive-loop-optimizations which I am sure is not actually run. I
guess you could claim it is enabled but not run, but that seems unhelpful.
I could fix the specific aarch64 '-fprefetch-loop-arrays' bug by having
aarch64_override_options_internal set the prefetch flag to 0 in those cases
where it is not setting it to 1. That way it would never be -1 when
option_enabled checks it, but I am not sure this the right/best fix.
