In case `@import Foo.Private` fails because the submodule doesn't exist,
look for `Foo_Private` (if available) and build/load that module
instead. In that process emit a warning and tell the user about the
assumption.
The intention here is to assist all existing private modules owners
(in ObjC and Swift) to migrate to the new `Foo_Private` syntax.
rdar://problem/36023940
llvm-svn: 321342
Summary: Adds BeforeExecute method to PrecompiledPreamble to be called
before Execute(). This method can be overriden.
Patch by William Enright.
Reviewers: malaperle, ilya-biryukov
Reviewed By: ilya-biryukov
Subscribers: arphaman, cfe-commits, ilya-biryukov
Differential Revision: https://reviews.llvm.org/D41365
llvm-svn: 321189
There are 2 parts to getting the -fassociative-math command-line flag translated to LLVM FMF:
1. In the driver/frontend, we accept the flag and its 'no' inverse and deal with the
interactions with other flags like -ffast-math -fno-signed-zeros -fno-trapping-math.
This was mostly already done - we just need to translate the flag as a codegen option.
The test file is complicated because there are many potential combinations of flags here.
Note that we are matching gcc's behavior that requires 'nsz' and no-trapping-math.
2. In codegen, we map the codegen option to FMF in the IR builder. This is simple code and
corresponding test.
For the motivating example from PR27372:
float foo(float a, float x) { return ((a + x) - x); }
$ ./clang -O2 27372.c -S -o - -ffast-math -fno-associative-math -emit-llvm | egrep 'fadd|fsub'
%add = fadd nnan ninf nsz arcp contract float %0, %1
%sub = fsub nnan ninf nsz arcp contract float %add, %2
So 'reassoc' is off as expected (and so is the new 'afn' but that's a different patch).
This case now works as expected end-to-end although the underlying logic is still wrong:
$ ./clang -O2 27372.c -S -o - -ffast-math -fno-associative-math | grep xmm
addss %xmm1, %xmm0
subss %xmm1, %xmm0
We're not done because the case where 'reassoc' is set is ignored by optimizer passes. Example:
$ ./clang -O2 27372.c -S -o - -fassociative-math -fno-signed-zeros -fno-trapping-math -emit-llvm | grep fadd
%add = fadd reassoc float %0, %1
$ ./clang -O2 27372.c -S -o - -fassociative-math -fno-signed-zeros -fno-trapping-math | grep xmm
addss %xmm1, %xmm0
subss %xmm1, %xmm0
Differential Revision: https://reviews.llvm.org/D39812
llvm-svn: 320920
This mimics FileCheck's --check-prefixes option.
The default prefix is "expected". That is, "-verify" is equivalent to
"-verify=expected".
The goal is to permit exercising a single test suite source file with different
compiler options producing different sets of diagnostics. While cpp can be
combined with the existing -verify to accomplish the same goal, source is often
easier to maintain when it's not cluttered with preprocessor directives or
duplicate passages of code. For example, this patch also rewrites some existing
clang tests to demonstrate the benefit of this feature.
Patch by Joel E. Denny, thanks!
Differential Revision: https://reviews.llvm.org/D39694
llvm-svn: 320908
The frontend currently groups diagnostics from the command line according to
diagnostic level, but that places all notes last. Fix that by emitting such
diagnostics in the order they were generated.
Patch by Joel E. Denny, thanks!
Differential Revision: https://reviews.llvm.org/D40995
llvm-svn: 320904
Summary:
Revision D38639 needs this commit in order to properly make open
definition calls on include statements work.
Patch by William Enright.
Reviewers: malaperle, krasimir, bkramer, ilya-biryukov
Reviewed By: malaperle, ilya-biryukov
Subscribers: cfe-commits, arphaman, ilya-biryukov
Differential Revision: https://reviews.llvm.org/D39375
llvm-svn: 320804
This adds a new command line option -mprefer-vector-width to specify a preferred vector width for the vectorizers. Valid values are 'none' and unsigned integers. The driver will check that it meets those constraints. Specific supported integers will be managed by the targets in the backend.
Clang will take the value and add it as a new function attribute during CodeGen.
This represents the alternate direction proposed by Sanjay in this RFC: http://lists.llvm.org/pipermail/llvm-dev/2017-November/118734.html
The syntax here matches gcc, though gcc treats it as an x86 specific command line argument. gcc only allows values of 128, 256, and 512. I'm not having clang check any values.
Differential Revision: https://reviews.llvm.org/D40230
llvm-svn: 320419
As reported in llvm bugzilla 32377.
Here’s a patch to add preinclude of stdc-predef.h.
The gcc documentation says “On GNU/Linux, <stdc-predef.h> is pre-included.” See https://gcc.gnu.org/gcc-4.8/porting_to.html;
The preinclude is inhibited with –ffreestanding.
Basically I fixed the failing test cases by adding –ffreestanding which inhibits this behavior.
I fixed all the failing tests, including some in extra/test, there's a separate patch for that which is linked here
Note: this is a recommit after a test failure took down the original (r318669)
Patch By: mibintc
Differential Revision: https://reviews.llvm.org/D34158
llvm-svn: 320391
This adds -std=c17, -std=gnu17, and -std=iso9899:2017 as language mode flags for C17 and updates the value of __STDC_VERSION__ to the value based on the C17 FDIS. Given that this ballot cannot succeed until 2018, it is expected that we (and GCC) will add c18 flags as aliases once the ballot passes.
llvm-svn: 320089
This definition is similar to __WCHAR_MAX__, except that it applies to
wint_t. It's also documented as being supported by GCC 4.5 and later.
llvm-svn: 319746
Fedora27 is using a new version of glibc that refers to the _Float128 type. This
patch adds that name as an alias to float128. I also added some predefined macro
values for the digits, mantissa, epilon, etc (FloatMacros). For the test case, I
copied an existing float128 test. This functionality needs work long term, but
it should be sufficient to tread water for a while. At Intel we have test
servers running our LLVM compiler with various open source workloads, the server
has been upgraded to Fedora27 so many workloads are failing due to _Float128.
Patch-By: mibintc
Differential Revision: https://reviews.llvm.org/D40673
llvm-svn: 319703
Summary:
The -fxray-always-emit-customevents flag instructs clang to always emit
the LLVM IR for calls to the `__xray_customevent(...)` built-in
function. The default behaviour currently respects whether the function
has an `[[clang::xray_never_instrument]]` attribute, and thus not lower
the appropriate IR code for the custom event built-in.
This change allows users calling through to the
`__xray_customevent(...)` built-in to always see those calls lowered to
the corresponding LLVM IR to lay down instrumentation points for these
custom event calls.
Using this flag enables us to emit even just the user-provided custom
events even while never instrumenting the start/end of the function
where they appear. This is useful in cases where "phase markers" using
__xray_customevent(...) can have very few instructions, must never be
instrumented when entered/exited.
Reviewers: rnk, dblaikie, kpw
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D40601
llvm-svn: 319388
This is a re-apply of r319294.
adds -fseh-exceptions and -fdwarf-exceptions flags
clang will check if the user has specified an exception model flag,
in the absense of specifying the exception model clang will then check
the driver default and append the model flag for that target to cc1
-fno-exceptions has a higher priority then specifying the model
move __SEH__ macro definitions out of Targets into InitPreprocessor
behind the -fseh-exceptions flag
move __ARM_DWARF_EH__ macrodefinitions out of verious targets and into
InitPreprocessor behind the -fdwarf-exceptions flag and arm|thumb check
remove unused USESEHExceptions from the MinGW Driver
fold USESjLjExceptions into a new GetExceptionModel function that
gives the toolchain classes more flexibility with eh models
Reviewers: rnk, mstorsjo
Differential Revision: https://reviews.llvm.org/D39673
llvm-svn: 319297
adds -fseh-exceptions and -fdwarf-exceptions flags
clang will check if the user has specified an exception model flag,
in the absense of specifying the exception model clang will then check
the driver default and append the model flag for that target to cc1
clang cc1 assumes dwarf is the default if none is passed
and -fno-exceptions has a higher priority then specifying the model
move __SEH__ macro definitions out of Targets into InitPreprocessor
behind the -fseh-exceptions flag
move __ARM_DWARF_EH__ macrodefinitions out of verious targets and into
InitPreprocessor behind the -fdwarf-exceptions flag and arm|thumb check
remove unused USESEHExceptions from the MinGW Driver
fold USESjLjExceptions into a new GetExceptionModel function that
gives the toolchain classes more flexibility with eh models
Reviewers: rnk, mstorsjo
Differential Revision: https://reviews.llvm.org/D39673
llvm-svn: 319294
Summary: Preambles are large and we should avoid copying them.
Reviewers: bkramer, klimek
Reviewed By: bkramer
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D40302
llvm-svn: 318945
This is an instrumentation flag that's similar to
-finstrument-functions, but it only inserts calls on function entry, the
calls are inserted post-inlining, and they don't take any arugments.
This is intended for users who want to instrument function entry with
minimal overhead.
(-pg would be another alternative, but forces frame pointer emission and
affects link flags, so is probably best left alone to be used for
generating gcov data.)
Differential revision: https://reviews.llvm.org/D40276
llvm-svn: 318785
As reported in llvm bugzilla 32377.
Here’s a patch to add preinclude of stdc-predef.h.
The gcc documentation says “On GNU/Linux, <stdc-predef.h> is pre-included.”
See https://gcc.gnu.org/gcc-4.8/porting_to.html;
The preinclude is inhibited with –ffreestanding.
Basically I fixed the failing test cases by adding –ffreestanding which inhibits
this behavior.
I fixed all the failing tests, including some in extra/test, there's a separate
patch for that which is linked here
Patch By: mibintc
Differential Revision: https://reviews.llvm.org/D34158
llvm-svn: 318669
Summary:
These preambles are built by ASTUnit and clangd. Previously, preambles
were always stored on disk.
In-memory preambles are routed back to the compiler as virtual files in
a custom VFS.
Interface of ASTUnit does not allow to use in-memory preambles, as
ASTUnit::CodeComplete receives FileManager as a parameter, so we can't
change VFS used by the compiler inside the CodeComplete method.
A follow-up commit will update clangd in clang-tools-extra to use
in-memory preambles.
Reviewers: klimek, sammccall, bkramer
Reviewed By: klimek
Subscribers: ioeric, cfe-commits
Differential Revision: https://reviews.llvm.org/D39842
llvm-svn: 318411
This updates -mcount to use the new attribute names (LLVM r318195), and
switches over -finstrument-functions to also use these attributes rather
than inserting instrumentation in the frontend.
It also adds a new flag, -finstrument-functions-after-inlining, which
makes the cygprofile instrumentation get inserted after inlining rather
than before.
Differential Revision: https://reviews.llvm.org/D39331
llvm-svn: 318199
Added support for regcall as default calling convention. Also added code to
exclude main when applying default calling conventions.
Patch-By: eandrews
Differential Revision: https://reviews.llvm.org/D39210
llvm-svn: 317268
Summary:
This change allows generalizing pointers in type signatures used for
cfi-icall by enabling the -fsanitize-cfi-icall-generalize-pointers flag.
This works by 1) emitting an additional generalized type signature
metadata node for functions and 2) llvm.type.test()ing for the
generalized type for translation units with the flag specified.
This flag is incompatible with -fsanitize-cfi-cross-dso because it would
require emitting twice as many type hashes which would increase artifact
size.
Reviewers: pcc, eugenis
Reviewed By: pcc
Subscribers: kcc
Differential Revision: https://reviews.llvm.org/D39358
llvm-svn: 317044
GCC tries to shorten system headers in depfiles using its real path
(resolving components like ".." and following symlinks). Mimic this
feature to ensure that the Ninja build tool detects the correct
dependencies when a symlink changes directory levels, see
https://github.com/ninja-build/ninja/issues/1330
An option to disable this feature is added in case "these changed header
paths may conflict with some compilation environments", see
https://gcc.gnu.org/ml/gcc-patches/2012-09/msg00287.html
Note that the original feature request for GCC
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52974) also included paths
preprocessed output (-E) and diagnostics. That is not implemented now
since I am not sure if it breaks something else.
Differential Revision: https://reviews.llvm.org/D37954
llvm-svn: 316193
It'd be better that they are #cmakedefine01 rather than #cmakedefine.
(#if FOO rather than #if defined(FOO))
Then we can find missing #include "clang/Config/config.h" in the future.
Differential Revision: https://reviews.llvm.org/D35541
llvm-svn: 316061
This comes up when pre-processing standalone .s files containing
hash-prefixed comments. The pre-processor should skip the unknown
directive and not emit an extra newline as we were doing.
Fixes PR34950
llvm-svn: 315953
Currently all the consecutive bitfields are wrapped as a large integer unless there is unamed zero sized bitfield in between. The patch provides an alternative manner which makes the bitfield to be accessed as separate memory location if it has legal integer width and is naturally aligned. Such separate bitfield may split the original consecutive bitfields into subgroups of consecutive bitfields, and each subgroup will be wrapped as an integer. Now This is all controlled by an option -ffine-grained-bitfield-accesses. The alternative of bitfield access manner can improve the access efficiency of those bitfields with legal width and being aligned, but may reduce the chance of load/store combining of other bitfields, so it depends on how the bitfields are defined and actually accessed to choose when to use the option. For now the option is off by default.
Differential revision: https://reviews.llvm.org/D36562
llvm-svn: 315915
This feature is not (yet) approved by the C++ committee, so this is liable to
be reverted or significantly modified based on committee feedback.
No functionality change intended for existing code (a new type must be defined
in namespace std to take advantage of this feature).
llvm-svn: 315662
Summary:
It was previsouly set only in ASTUnit, but it should be set for all client of
PrecompiledPreamble.
Reviewers: erikjv, bkramer, klimek
Reviewed By: bkramer
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D38617
llvm-svn: 315212
Move the logic for determining the `wchar_t` type information into the
driver. Rather than passing the single bit of information of
`-fshort-wchar` indicate to the frontend the desired type of `wchar_t`
through a new `-cc1` option of `-fwchar-type` and indicate the
signedness through `-f{,no-}signed-wchar`. This replicates the current
logic which was spread throughout Basic into the
`RenderCharacterOptions`.
Most of the changes to the tests are to ensure that the frontend uses
the correct type. Add a new test set under `test/Driver/wchar_t.c` to
ensure that we calculate the proper types for the various cases.
llvm-svn: 315126
Bruno Cardoso Lopes