summaryrefslogtreecommitdiffstats
path: root/clang/test/Frontend/gnu-inline.c
Commit message (Collapse)AuthorAgeFilesLines
* Don't accept -std= values that would switch us to a different source language.Richard Smith2017-04-261-1/+3
| | | | | | | | | | | | | | | | | | | | | We already prohibited this in most cases (in r130710), but had some bugs in our enforcement of this rule. Specifically, this prevents the following combinations: * -x c -std=clN.M, which would previously effectively act as if -x cl were used, despite the input being a C source file. (-x cl -std=cNN continues to be disallowed.) * -x c++ -std=cuda, which would previously select C++98 + CUDA, despite that not being a C++ standard. (-x cuda -std=c++NN is still permitted, and selects CUDA with the given C++ standard as its base language. -x cuda -std=cuda is still supported with the meaning of CUDA + C++98.) * -x renderscript -std=c++NN, which would previously form a hybrid "C++ with RenderScript extensions" language. We could support such a thing, but shouldn't do so by accident. llvm-svn: 301497
* Make GNUInline consistent with whether we use traditional GNU inline semantics.Peter Collingbourne2015-05-131-0/+15
Previously we were setting LangOptions::GNUInline (which controls whether we use traditional GNU inline semantics) if the language did not have the C99 feature flag set. The trouble with this is that C++ family languages also do not have that flag set, so we ended up setting this flag in C++ modes (and working around it in a few places downstream by also checking CPlusPlus). The fix is to check whether the C89 flag is set for the target language, rather than whether the C99 flag is cleared. This also lets us remove most CPlusPlus checks. We continue to test CPlusPlus when deciding whether to pre-define the __GNUC_GNU_INLINE__ macro for consistency with GCC. There is a change in semantics in two other places where we weren't checking both CPlusPlus and GNUInline (FunctionDecl::doesDeclarationForceExternallyVisibleDefinition and FunctionDecl::isInlineDefinitionExternallyVisible), but this change seems to put us back into line with GCC's semantics (test case: test/CodeGen/inline.c). While at it, forbid -fgnu89-inline in C++ modes, as GCC doesn't support it, it didn't have any effect before, and supporting it just makes things more complicated. Differential Revision: http://reviews.llvm.org/D9333 llvm-svn: 237299
OpenPOWER on IntegriCloud