2017-09-22 9:11 GMT+02:00 Janne Blomqvist <blomqvist.ja...@gmail.com>: > On Fri, Sep 22, 2017 at 8:02 AM, Janus Weil <ja...@gcc.gnu.org> wrote: >> Thanks, Steve. I'm attaching the updated ChangeLog and the two test >> cases for the two new flags. Since this appears to be a somewhat >> controversial feature, I'll wait two more days to allow for others to >> contribute their feedback (positive or negative). I'll commit on >> Sunday if I hear nothing until then. > > Well, if you're actively soliciting bikeshedding, here goes:
I'm not soliciting anything. I'm giving people a fair chance to comment. What you make out of that is completely up to you. > Since we're about to have several -fdefault-real-N flags, would it > make sense to instead make a single flag -fdefault-real=SOMEVALUE I don't think that's a good idea, for several reasons: 1) We're probably not going to have much more N values (adding a single one is tough enough of a job apparently, plus the list of supported real kinds is very much limited anyway). 2) The syntax you're proposing is inconsistent with other flags like -fdefault-integer-8, -fdefault-double-8. I'm sure we don't want to change all of them. 3) That kind of syntax is not even used in other flags like -ffree-line-length-n, where the range of possible values is potentially much larger. > And since the standard requires that double precision variables are > twice as big as reals, in the absence of an explicit -fdefault-double= > flag, would it make sense to have -fdefault-real=N imply > -fdefault-double=[2*N or if that isn't supported on the target, the > largest supported real kind]? That's basically the behavior I tried to implement in my current patch (although I notice now that you're not necessarily getting the largest real kind, if 16 is not supported). Cheers, Janus
