On Sun, Mar 18, 2018 at 09:18:34AM +0100, Nguyễn Thái Ngọc Duy wrote: > The set of extra warnings we enable when DEVELOPER has to be > conservative because we can't assume any compiler version the > developer may use. Detect the compiler version so we know when it's > safe to enable -Wextra and maybe more.
Hrm, I was planning to expand my patch into a series. In particular, in my experiments some of those warnings do not need to be disabled under -Wextra (I tested going back to gcc 5 and clang 4.0). I think it's worth splitting up the boilerplate changes from the decisions on individual warnings, because I suspect we'll need to revise the latter going forward. I also noticed that all of those options seem to go back at least to gcc-5. It makes me wonder how much we even need this version-detecting framework. There are one or two "clang vs gcc" things I've found, but I haven't found a case where old versions of gcc don't support a particular option. IOW, could we get away with just adding these to the DEVELOPER knob and assuming that people who use it have a reasonably modern gcc or clang setup? That's more or less what the existing knobs do. But I didn't follow whether there was any earlier discussion on specific problems. > -dumpversion does not work correctly for clang. So I use "-v" instead > which seems to produce the same output for both gcc and clang (with a > minor difference in freebsd where it says "FreeBSD clang" instead of > just "clang"). Not sure if it helps your "cc on debian" case though Heh. At first I was confused, as it seems to work for me: $ clang-4.0 -dumpversion 4.2.1 But then I tried this: $ clang-5.0 -dumpversion 4.2.1 Whoops. It returns the same value up through clang 7. -Peff
