On Sat, 27 Jan 2018, Jakub Jelinek wrote: > Hi! > > Honza reported today on IRC that we spent (again) significant time > of empty file compilation computing preprocessor *_MAX/*_MIN etc. macros. > In 2010 I've added lazy computation for these, only when they are first used > except for -dD, but reserved just 12 entries for those, as only > FLT/DBL/LDBL prefixed macros (4 times for each kind) were needed at that > point. In 2016 for PR32187 Joseph has added a bunch of other kinds and > because there is no space in the array reserved for those, they are > evaluated right away, which is quite expensive. > > The following patch makes them lazy again. > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
Rather than hardcoding a number 36 I'd rather it used an explicit computation (with explanatory comment) such as 4 * (3 + NUM_FLOATN_NX_TYPES) (if that is indeed a safe value to use to guarantee covering all these types). -- Joseph S. Myers jos...@codesourcery.com