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.