------- Comment #5 from eric dot estievenart at free dot fr 2010-05-21 18:00 ------- 44209 > The manual documents... > We will accept patches fixing any missing/mistaken entries. That's not the point ! This manual section could (and should) be generated from the output of -show-warnings or similar
> You could also propose some warnings to be moved to Wextra/Wall Neither ! > See also the option -fdiagnostics-show-option. I know it well, it is always in my cflags. This is because a specific warning had no diagnostic that I logged #44209 and consequently this ER. > It would be extremely useful to go through the manual and... > perhaps provide a "Wparanoid" setting that includes all those warnings. That's a better name than Wevery. Wmaniac would be smart too ;-) But it's not time for voting ! > Instead of -show-warnings, I would propose to extend the current > --help=warnings --verbose. --help=warnings has its own purpose, and it is indeed useful, but it does not show the effects of a given commandline on the whole set of available warnings (which also depends on the language) > However, that would mean documenting within GCC the > relations between the warnings options. That by itself (even without the > output) would be EXTREMELY useful if done properly, that is, by adding the > information to the *.opt files that define the flags. > I can provide pointers on how this could be implemented. Thank you, I'll certainly need some help on the following points: - which branch I should start working on (4.4, 4.5, ...) so that it has good chances to be accepted, and could be integrated into released subversions without too many hassle - which front-ends I should target beside C/C++ - which files to look at first considering the problem. - if there are things in the developper docs (or rather which are not in the developper docs) which could help me. For the dev itself, I should be able to handle it. Honestly I have not yet had a look at the code neither at the architecture, but I guess I will find a common module shared by the front-ends, compiler, etc. I'll see if I can first spot / force compile-time warnings for the calls to a function like log_warning(...) if the warning is not linked to a diagnostic, extend the api, ... > A follow-up patch could even fill the details of > the manual from that information automatically! That's indeed my intent ! > So, I think yes, we are interested in any of the above, so if you are > interested in providing patches, choose something small to start with (some > small documentation patch to the manual), and ask whatever you want. You may > ask here or write to me directly. Thank you again, but if I start on that, I expect to go to the end, so patching the manual would be a loss of time since all would be generated after. I don't have so much time to spend on it, I just expect to do it in a clean and efficient way. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44210
