On Wed, 14 Jan 2015, Sandra Loosemore wrote: > What would you think about reorganizing this section to add some subsections > grouping options by purpose, instead? E.g., loop optimizations, > floating-point optimizations, inlining, LTO, profiling options, etc? The > section is almost 60 pages long in the printed manual and adding some > structure would probably make it easier for users to find things.
For the floating-point options the classification as optimization options is a bit questionable anyway; they're more like language dialect options (with some dialects being more optimizable than others). But while you might have divisions such as (language dialect options, options such as LTO or profiling that may affect your build system, non-semantic options that are quite likely to be useful in normal use, miscellaneous options enabled by -On that it probably only makes sense to turn on and off individually when debugging the compiler), organizing the manual that way could have issues with closely related options falling in different categories. (E.g. -Ofast is like the other -O options, but also changes the language dialect by enabling -ffast-math. -fno-strict-aliasing can be used as a language dialect option, but unless you're doing that sort of aliasing it's an option it doesn't make much sense to turn on or off on its own rather than through -O2. -fmerge-all-constants is a language dialect option, but is naturally described next to the non-semantic option -fmerge-constants.) -- Joseph S. Myers jos...@codesourcery.com
