Re: encoding all aliases options in .opt files
Manuel López-Ibáñez lopeziba...@gmail.com writes: aux-infoFILE /* we could accept this to be compatible with some options like -B */ Concatenated option arguments (without separators like '=' or '-') should only ever be used for single character options. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different.
Re: encoding all aliases options in .opt files
On 14 October 2012 13:38, Andreas Schwab sch...@linux-m68k.org wrote: Manuel López-Ibáñez lopeziba...@gmail.com writes: aux-infoFILE /* we could accept this to be compatible with some options like -B */ Concatenated option arguments (without separators like '=' or '-') should only ever be used for single character options. We could make that rule explicit in the options-handling machinery. Cheers, Manuel.
Re: encoding all aliases options in .opt files
On 12 October 2012 17:18, Joseph S. Myers jos...@codesourcery.com wrote: On Fri, 12 Oct 2012, Manuel López-Ibáñez wrote: I am trying to encode the relationship between Wstrict-aliasing and Wstrict-aliasing= in the .opt files, and the same for Wstrict-overflow and Wstrict-overflow=. However, the parameters of Alias() are taken as strings, so we get 3 and WARN_STRICT_OVERFLOW_CONDITIONAL. Do you have a suggestion how to handle this? I don't see what the problem is supposed to be. Yes, the arguments are strings - they describe how one option that the user might pass on the command line is exactly equivalent to another that they might pass (up to and including the latter form of the option being the one that is used when matching specs and multilibs, because the driver does the translation, including working out the canonical textual form of the option, before processing specs against the command line). If -Wstrict-overflow on the command line is equivalent to -Wstrict-overflow=WARN_STRICT_OVERFLOW_CONDITIONAL on the command line, then specify WARN_STRICT_OVERFLOW_CONDITIONAL in the parameters. If it's equivalent to something else, specify something else. My next step would be to handle aliases also when internally generating options, so I can add EnabledBy(Wall) to Wstrict-aliasing. Does this sound ok to you? That seems reasonable. OK. The attached patch implements this. Does the approach look ok? I will write changelog and more comments if it seems reasonable. One thing I don't like is that now we print [-Werror=strict-aliasing=] in diagnostics. Two questions: 1) Are references allowed now that C++ is the default? 2) While fixing this, I was thinking: Why the difference between Joined and Separate? Why not make every function that takes an argument work with and without '=' and with separate argument. It seems we could remove a lot of options this way. What I am proposing is, instead of: aux-info Common Separate Var(aux_info_file_name) -aux-info fileEmit declaration information into file aux-info= Common Joined Alias(aux-info) simply aux-info Common RequiredArgument Var(aux_info_file_name) -aux-info fileEmit declaration information into file and all of these would be accepted: aux-infoFILE /* we could accept this to be compatible with some options like -B */ aux-info=FILE aux-info FILE We have dozens of options like these. Moreover, we could replace: Wstrict-aliasing Common Alias(Wstrict-aliasing=, 3, 0) Warning Warn about code which might break strict aliasing rules Wstrict-aliasing= Common Joined RejectNegative UInteger Var(warn_strict_aliasing) Warning Warn about code which might break strict aliasing rules with: Wstrict-aliasing Common MissingArgument(3) UInteger Var(warn_strict_aliasing) Warning Warn about code which might break strict aliasing rules and all of these will be accepted: Wstrict-aliasing Wno-strict-aliasing Wstrict-aliasing2 Wstrict-aliasing=2 Wstrict-aliasing 2 Werror=strict-aliasing Wno-error=strict-aliasing Cheers, Manuel. lang-enabled-by-with-args.diff Description: Binary data
Re: encoding all aliases options in .opt files
On Sat, Oct 13, 2012 at 11:33 AM, Manuel López-Ibáñez lopeziba...@gmail.com wrote: 1) Are references allowed now that C++ is the default? I'm not sure we addressed those in the coding conventions. I would like to say: 1) const references are always fine; 2) non-const references as local variables are always fine; 3) non-const references as function parameters should never be used without a really excellent reason. The reason is simply that using non-const references as function parameters means that arguments passed to a function can change without any indication, and that is potentially quite confusing. Adding an before an output argument is easy enough, and we're all used to it. Ian
Re: encoding all aliases options in .opt files
On Sat, 13 Oct 2012, Manuel L?pez-Ib??ez wrote: OK. The attached patch implements this. Does the approach look ok? I will write changelog and more comments if it seems reasonable. One Without the comments explaining the semantics of the new functions and their parameters, I'm not going to attempt to reverse-engineer what the approach in question is intended to be and so whether it's reasonable or not. 2) While fixing this, I was thinking: Why the difference between Joined and Separate? Why not make every function that takes an argument work with and without '=' and with separate argument. It seems we could remove a lot of options this way. What I am proposing is, instead of: I see no significant advantage to users in having all these different ways to pass options, and multiple disadvantages: * If you add yet more ways of passing options, then any future overhaul of option handling needs to preserve those in addition to all the others. The fewer ways there are, the fewer constraints on the implementation. * Options like this aux-infoFILE /* we could accept this to be compatible with some options like -B */ are liable to be a pain for anyone, seeing such an option, to work out what is the option name that they might search for to get more information, and what is the argument. * In general, if all users are using an option in the same form it's easier for them to tell that another person really is using the same option rather than something that might be different from the option they are used to. * This also may not work so well with JoinedOrMissing options. Wstrict-aliasing2 Shades of the old -gdwarf2 that once meant DWARF 1, debug level 2, not to be confused with -gdwarf-2. I don't think such cryptic forms should be encouraged. Wstrict-aliasing 2 Ambiguous with the existing -Wstrict-aliasing option followed by a linker input file called 2. -- Joseph S. Myers jos...@codesourcery.com
