On Wed, Aug 7, 2013 at 4:54 PM, Joseph S. Myers <jos...@codesourcery.com> wrote: > On Sun, 4 Aug 2013, Andi Kleen wrote: > >> Richard Biener <richard.guent...@gmail.com> writes: >> > >> > The patch fails to add documentation. >> >> That seems like a feature, it's likely not useful for the general >> public. More for specialized tools that automatically search >> for the best tuning. > > If such a tool is not part of GCC itself, then it is a user of GCC and > documentation should be provided for those writing such a tool. > > Options should be undocumented in very limited cases such as multiple > variant spellings where only one should be used but others are accepted > because they were historically, or whether the user interface to an option > is separate from the internal option passed to cc1 (the documentation is > of options as passed to the driver, but the .opt file may describe options > passed to cc1 as a result of other options being passed to the driver), or > the option really is only for use within the build of GCC itself. > Otherwise, the strong presumption is that all options should be > documented, with appropriate caveats as applicable about the cases where > an option is useful. >
Fair enough. I will add the documentation in a followup patch which also implements H.J's proposal -mno-default and cleans up the initial tuning array to be always in sync with new enums. >> > And I am nervous about testing >> > coverage - is this considered a development option only or are random >> > combinations expected to work in all situations? I expect not, thus >> > this looks like a dangerous option? >> >> When it's undocumented it doesn't need to work in every situation? > > No input files and command-line arguments whatsoever to the driver should > result in ICEs, including undocumented options. True -- if ICEs are found, we should fix them. thanks, David > > -- > Joseph S. Myers > jos...@codesourcery.com
