On Sep 27, 2013, at 4:38 AM, Bram Moolenaar <[email protected]> wrote:
> > Kazunobu Kuriyama wrote: > >> Attached is a patch which was made to suppress some compiler warning >> put out by a recent version of clang. >> >> I'm on Mac OS X 10.8.5 and upgraded Xcode from 4.6.x to 5.0 a few days >> ago. With that IDE, a new version of clang came and, when I had it >> compile vim, it was complaining: >> >> clang: warning: argument unused during compilation: '-fno-strength-reduce' >> >> Hmm, it looks like the day is coming when the widely known '-O2 >> -fno-strength-reduce' used over a decade finally comes to an end... >> (No?) >> >> Anyway, the patch modifies src/configure.in in such a way that the >> resulting configure script checks the version number of clang in use, >> if it is actually used in the process of configuration, and then >> adjusts CFLAGS accordingly; if the version number is higher enough, >> the optimization flag -fno-strength-reduce is excluded from CFLAGS; >> otherwise, it is left as it was. >> >> After applying the patch, please do 'make autoconf' for yourself. I >> think it would be safer than offering a patch against 'configure' >> itself. > > Did clang really support -fno-strength-reduce at some point? I'm afraid I'm not a right person who can definitively answer to that question; I only know clang-2.6 and after. Instead, let me explain the intent of the patch a little more. The version check in the patch didn't mean that the argument had to be passed to older clang by all means. I just wanted to let all the things, except suppressing the warning issued by new clang, remain the same, so that the patch wouldn't break anything previously working well. I'd like you to note that previous versions of clang have accepted the argument without issuing any warning and have produced workable executables. I guess that's why no one has made any attempt to drop the argument so far. The argument may be unnecessary but is harmless to older clang at any rate. > Also, older clang versions are buggy anyway. So perhaps we can just > drop that argument whenever clang is used? I have one thing to note: program names and '-dumpversion' is not necessarily helpful to distinguish clang from gcc for some cases. For example, the "gcc" of the latest release version of Xcode is a front-end of clang. So you can't distinguish it from clang through '-dumpversion' because it returns the same string, say "4.2.1", for both of "gcc" and clang. It looks to me that only the string returned by '--version' can be used for correct detection. In this point of view, I think the code used for the assignment of CHECK_IF_CC_IS_CLANG or something similar to that is still useful for the purpose, though I don't insist there's no way other than that. Regards, KK -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
