On Tue, Aug 30, 2016 at 11:30 PM, Nathan Hjelm <hje...@me.com> wrote: > The best way to put this is his compiler defaults to --std=gnu89. That gives > him about 90% of what we require from C99 but has weirdness like __restrict. > The real solution is the list of functions that are called out on link and > spot fixing with the gnu_inline attribute if -fgnu89-inline does not work.
I'll try to reply to both crossing replies Lets not use "my compiler" and just reference clang since it's the equivalent in this case. (dramatic bold for fun) Both clang and "my compiler" actually ***default[1]*** to ***c99*** and support c99 very well. (In fact I'd be surprised if gcc was more strict than us in c99 mode) http://clang.llvm.org/compatibility.html [1] The exception to this is cases where during install we detect c99 is broken (SLES10/old-glibc) and in those cases we disable c99 flags and turn on c89 by default, almost similar to gcc, but without that weird gnu89-inline thing, which they did I guess to work-around glibc and have fake c99 "support") Where you guys may catch/question/confuse me and clang - is if c89 mode we may not be strictly disabling all of c99. (tbh I've never tested how much is actually disabled in clang). So this could be a case of c89 mode isn't nuking everything and only "just enough". (peren and the popular conformance suites don't have a lot of negative tests coverage, so I'd have to write a bunch of tests to confirm this) _______________________________________________ devel mailing list devel@lists.open-mpi.org https://rfd.newmexicoconsortium.org/mailman/listinfo/devel
