Functions using stdcall, fastcall, or vectorcall with C linkage mangle
in the size of the parameter pack. Calculating the size of the pack
requires the parameter types to complete, which may require template
instantiation.
Previously, we would crash during IRgen when requesting the size of
incomplete or uninstantiated types, as in this reduced example:
struct Foo;
void __fastcall bar(struct Foo o);
void (__fastcall *fp)(struct Foo) = &bar;
Reported in Chromium here: https://crbug.com/971245
Differential Revision: https://reviews.llvm.org/D62975
llvm-svn: 363000
Summary:
The `%diff_plist` lit substitution invokes `diff` with a non-portable
`-I` option. The intended effect can be achieved by normalizing the
inputs to `diff` beforehand. Such normalization can be done with
`grep -Ev`, which is also used by other tests.
This patch applies the change (adjusted for review comments) described
in http://lists.llvm.org/pipermail/cfe-dev/2019-April/061904.html
mechanically to the cases where the output file is piped to
`%diff_plist` via `tail`. `%diff_plist` is then, being unused, removed.
The changes were applied via a script.
Reviewers: NoQ, sfertile, xingxue, jasonliu, daltenty
Subscribers: xazax.hun, baloghadamsoftware, szepet, a.sidorin, mikhail.ramalho, Szelethus, donat.nagy, dkrupp, Charusso, jsji, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D62951
llvm-svn: 362998
Summary:
The `%diff_plist` lit substitution invokes `diff` with a non-portable
`-I` option. The intended effect can be achieved by normalizing the
inputs to `diff` beforehand. Such normalization can be done with
`grep -Ev`, which is also used by other tests.
This patch applies the change (adjusted for review comments) described
in http://lists.llvm.org/pipermail/cfe-dev/2019-April/061904.html
mechanically to the cases where the output file is piped to
`%diff_plist` via `cat`.
The changes were applied via a script, except that
`clang/test/Analysis/NewDelete-path-notes.cpp` and
`clang/test/Analysis/plist-macros-with-expansion.cpp` were each adjusted
for the line-continuation on the relevant `RUN` step.
Reviewers: NoQ, sfertile, xingxue, jasonliu, daltenty
Subscribers: xazax.hun, baloghadamsoftware, szepet, a.sidorin, mikhail.ramalho, Szelethus, donat.nagy, dkrupp, Charusso, jsji, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D62950
llvm-svn: 362996
Summary:
The `%diff_plist` lit substitution invokes `diff` with a non-portable
`-I` option. The intended effect can be achieved by normalizing the
inputs to `diff` beforehand. Such normalization can be done with
`grep -Ev`, which is also used by other tests.
This patch applies the change (adjusted for review comments) described
in http://lists.llvm.org/pipermail/cfe-dev/2019-April/061904.html to the
specific case shown in the list message. Mechanical changes to the other
affected files will follow in later patches.
Reviewers: NoQ, sfertile, xingxue, jasonliu, daltenty
Reviewed By: NoQ
Subscribers: xazax.hun, baloghadamsoftware, szepet, a.sidorin, mikhail.ramalho, Szelethus, donat.nagy, dkrupp, Charusso, jsji, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D62949
llvm-svn: 362994
Summary:
As suggested in the review of D62949, this patch updates the plist
output to have a newline at the end of the file. This makes it so that
the plist output file qualifies as a POSIX text file, which increases
the consumability of the generated plist file in relation to various
tools.
Reviewers: NoQ, sfertile, xingxue, jasonliu, daltenty
Reviewed By: NoQ, xingxue
Subscribers: jsji, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D63041
llvm-svn: 362992
Summary:
vertical-line is not a BRE special character.
POSIX.1-2017 XBD Section 9.3.2 indicates that the interpretation of `\|`
is undefined. This patch uses EREs instead.
Additionally, the pattern is further fixed so that `SIZEOF` and `WIDTH`
macros are checked.
Reviewers: jlebar, daltenty, xingxue, jasonliu, tra
Reviewed By: tra
Subscribers: jfb, jsji, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D63029
llvm-svn: 362991
The recently added cooperlake CPU has made our already ugly switch statement even worse. There's a CPU exclusion list around the bf16 feature in the cooper lake block. I worry that we'll have to keep adding new CPUs to that until bf16 intercepts a client space CPU. We have several other exclusion lists in other parts of the switch due to skylakeserver, cascadelake, and cooperlake not having sgx. Another for cannonlake not having clwb but having all other features from skx.
This removes all these special ifs at the cost of some duplication of features and a goto. I've copied all of the skx features into either cannonlake or icelakeclient(for clwb). And pulled sklyakeserver, cascadelake, and cooperlake out of the main inheritance chain into their own chain. At the end of skylakeserver we merge back into the main chain at skylakeclient but below sgx. I think this is at least easier to follow.
Differential Revision: https://reviews.llvm.org/D63018
llvm-svn: 362965
As suggested in the review for D62949, this patch pre-normalizes the
reference expected output plist files by removing lines containing
fields for which we expect differences that should be ignored.
llvm-svn: 362877
Seems like a logical extension to me - and of interest because it might
help reduce the debug info size of libc++ by applying this attribute to
type traits that have a disproportionate debug info cost compared to the
benefit (& possibly harm/confusion) they cause users.
llvm-svn: 362856
Summary:
We're using the clang static analyzer together with a number of
custom analyses in our CI system to ensure that certain invariants
are statiesfied for by the code every commit. Unfortunately, there
currently doesn't seem to be a good way to determine whether any
analyzer warnings were emitted, other than parsing clang's output
(or using scan-build, which then in turn parses clang's output).
As a simpler mechanism, simply add a `-analyzer-werror` flag to CC1
that causes the analyzer to emit its warnings as errors instead.
I briefly tried to have this be `Werror=analyzer` and make it go
through that machinery instead, but that seemed more trouble than
it was worth in terms of conflicting with options to the actual build
and special cases that would be required to circumvent the analyzers
usual attempts to quiet non-analyzer warnings. This is simple and it
works well.
Reviewed-By: NoQ, Szelethusw
Differential Revision: https://reviews.llvm.org/D62885
llvm-svn: 362855
Summary:
Add output to `llvm::errs()` when `-ftime-trace` option is enabled,
add regression test checking this option works as expected.
Reviewers: thakis, aganea
Subscribers: cfe-commits, llvm-commits
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D61914
........
Breaks buildbots - @anton-afanasyev please can you take a look?
llvm-svn: 362816
Summary:
It is useful to build with _XOPEN_SOURCE defined on AIX, enabling X/Open
and POSIX compatibility mode, to work around stray macros and other
bugs in the headers provided by the system and build compiler.
This patch adds the config to cmake to build with _XOPEN_SOURCE defined
on AIX with a few exceptions. Google Test internals require access to
platform specific thread info constructs on AIX so in that case we build
with _ALL_SOURCE defined instead. Libclang also uses header which needs
_ALL_SOURCE on AIX so we leave that as is as well.
We also add building on AIX with the large file API and doing CMake
header checks with X/OPEN definitions so the results are consistent with
the environment that will be present in the build.
Reviewers: hubert.reinterpretcast, xingxue, andusy
Reviewed By: hubert.reinterpretcast
Subscribers: mgorny, jsji, cfe-commits, llvm-commits
Tags: #llvm, #clang
Differential Revision: https://reviews.llvm.org/D62533
llvm-svn: 362808
If MVE is present at all, then the macro __ARM_FEATURE_MVE is defined
to a value which has bit 0 set for integer MVE, and bit 1 set for
floating-point MVE.
(Floating-point MVE implies integer MVE, so if this macro is defined
at all then it will be set to 1 or 3, never 2.)
Patch mostly by Simon Tatham
Differential Revision: https://reviews.llvm.org/D60710
llvm-svn: 362806
Summary:
Add output to `llvm::errs()` when `-ftime-trace` option is enabled,
add regression test checking this option works as expected.
Reviewers: thakis, aganea
Subscribers: cfe-commits, llvm-commits
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D61914
llvm-svn: 362792
Change D60691 caused some knock-on failures that weren't caught by the
existing tests. Firstly, selecting a CPU that should have had a
restricted FPU (e.g. `-mcpu=cortex-m4`, which should have 16 d-regs
and no double precision) could give the unrestricted version, because
`ARM::getFPUFeatures` returned a list of features including subtracted
ones (here `-fp64`,`-d32`), but `ARMTargetInfo::initFeatureMap` threw
away all the ones that didn't start with `+`. Secondly, the
preprocessor macros didn't reliably match the actual compilation
settings: for example, `-mfpu=softvfp` could still set `__ARM_FP` as
if hardware FP was available, because the list of features on the cc1
command line would include things like `+vfp4`,`-vfp4d16` and clang
didn't realise that one of those cancelled out the other.
I've fixed both of these issues by rewriting `ARM::getFPUFeatures` so
that it returns a list that enables every FP-related feature
compatible with the selected FPU and disables every feature not
compatible, which is more verbose but means clang doesn't have to
understand the dependency relationships between the backend features.
Meanwhile, `ARMTargetInfo::handleTargetFeatures` is testing for all
the various forms of the FP feature names, so that it won't miss cases
where it should have set `HW_FP` to feed into feature test macros.
That in turn caused an ordering problem when handling `-mcpu=foo+bar`
together with `-mfpu=something_that_turns_off_bar`. To fix that, I've
arranged that the `+bar` suffixes on the end of `-mcpu` and `-march`
cause feature names to be put into a separate vector which is
concatenated after the output of `getFPUFeatures`.
Another side effect of all this is to fix a bug where `clang -target
armv8-eabi` by itself would fail to set `__ARM_FEATURE_FMA`, even
though `armv8` (aka Arm v8-A) implies FP-Armv8 which has FMA. That was
because `HW_FP` was being set to a value including only the `FPARMV8`
bit, but that feature test macro was testing only the `VFP4FPU` bit.
Now `HW_FP` ends up with all the bits set, so it gives the right
answer.
Changes to tests included in this patch:
* `arm-target-features.c`: I had to change basically all the expected
results. (The Cortex-M4 test in there should function as a
regression test for the accidental double-precision bug.)
* `arm-mfpu.c`, `armv8.1m.main.c`: switched to using `CHECK-DAG`
everywhere so that those tests are no longer sensitive to the order
of cc1 feature options on the command line.
* `arm-acle-6.5.c`: been updated to expect the right answer to that
FMA test.
* `Preprocessor/arm-target-features.c`: added a regression test for
the `mfpu=softvfp` issue.
Reviewers: SjoerdMeijer, dmgreen, ostannard, samparker, JamesNagurne
Reviewed By: ostannard
Subscribers: srhines, javed.absar, kristof.beyls, hiraditya, cfe-commits, llvm-commits
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D62998
llvm-svn: 362791
These builtins should work with immediate or variable shift operand for
gcc compatibility.
Differential Revision: https://reviews.llvm.org/D62850
llvm-svn: 362786
Summary:
- when a method is not available because of the target value kind (e.g. an &&
method on a Foo& variable), then don't offer it.
- when a method is effectively shadowed by another method from the same class
with a) an identical argument list and b) superior qualifiers, then don't
offer it.
Reviewers: ilya-biryukov
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D62582
llvm-svn: 362785
most / all other Expr subclasses.
This reinstates r362551, reverted in r362597, with a fix to a bug that
caused MemberExprs to sometimes have a null FoundDecl after a round-trip
through an AST file.
llvm-svn: 362756
Summary:
Other macros are used to declare namespaces, and should thus be handled
similarly. This is the case for crpcut's TESTSUITE macro, or for
unittest-cpp's SUITE macro:
TESTSUITE(Foo) {
TEST(MyFirstTest) {
assert(0);
}
} // TESTSUITE(Foo)
This patch deals with this cases by introducing a new option to specify
lists of namespace macros. Internally, it re-uses the system already in
place for foreach and statement macros, to ensure there is no impact on
performance.
Reviewers: krasimir, djasper, klimek
Reviewed By: klimek
Subscribers: acoomans, cfe-commits, klimek
Tags: #clang
Differential Revision: https://reviews.llvm.org/D37813
llvm-svn: 362740
Summary: `change()` is an all purpose function; the revision adds simple shortcuts for the specific operations of inserting (before/after) or removing source.
Reviewers: ilya-biryukov
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D62621
llvm-svn: 362707
Summary:
LSan is currently being ported to Emscripten and mostly works.
Enabling the support in upstream would simplify testing.
Patch by Guanzhong Chen.
Reviewers: tlively, aheejin
Reviewed By: aheejin
Subscribers: dschuff, sbc100, jgravelle-google, sunfish, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D62830
llvm-svn: 362667
LLVM IR recently added a Type parameter to the byval Attribute, so that
when pointers become opaque and no longer have an element type the
information will still be present in IR.
For now the Type parameter is optional (which is why Clang didn't need
this change at the time), but it will become mandatory soon.
llvm-svn: 362652
Summary: This patch cleans up a duplicate use of TestingSupport library.
Subscribers: mgorny, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D62924
llvm-svn: 362637
Summary:
In DistributionExample.cmake be sure we use a LTO
capable linker, the easiest to choose is lld.
Reviewers: beanz
Reviewed By: beanz
Patch By: winksaville
Subscribers: mgorny, mehdi_amini, inglorion, dexonsmith, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D62279
llvm-svn: 362624
As reported in https://bugs.llvm.org/show_bug.cgi?id=42113, there are a
number of locations in Clang where it is assumed that exception
specifications are only valid in C++ mode. Since the original
justification for the NoThrow Exception Specifier Type was C++ related,
this patch just makes C mode use the attribute-based nothrow handling.
Additionally, I noticed that the handling of non-prototype functions
regressed the behavior of the nothrow attribute, in part because it is
was listed in the function type macro(which I did in the previous
patch). In reality, it should only be doing so in a conditional nature,
so this patch removes it there and puts it directly in the switch to be
handled correctly.
llvm-svn: 362607
References to arbitrary address spaces can't always be bound to
temporaries. This change extends the reference binding logic to
check that the address space of a temporary can be implicitly
converted to the address space in a reference when temporary
materialization is performed.
Differential Revision: https://reviews.llvm.org/D61318
llvm-svn: 362604
Now, when clang processes an argument of the form "-march=foo+x+y+z",
then instead of calling getArchExtFeature() for each of the extension
names "x", "y", "z" and appending the returned string to its list of
low-level subtarget features, it will call appendArchExtFeatures()
which does the appending itself.
The difference is that appendArchExtFeatures can add _more_ than one
low-level feature name to the output feature list if it has to, and
also, it gets told some information about what base architecture and
CPU the extension is going to go with, which means that "+fp" can now
mean something different for different CPUs. Namely, "+fp" now selects
whatever the _default_ FPU is for the selected CPU and/or
architecture, as defined in the ARM_ARCH or ARM_CPU_NAME macros in
ARMTargetParser.def.
On the clang side, I adjust DecodeARMFeatures to call the new
appendArchExtFeatures function in place of getArchExtFeature. This
means DecodeARMFeatures needs to be passed a CPU name and an ArchKind,
which meant changing its call sites to make those available, and also
sawing getLLVMArchSuffixForARM in half so that you can get an ArchKind
enum value out of it instead of a string.
Also, I add support here for the extension name "+fp.dp", which will
automatically look through the FPU list for something that looks just
like the default FPU except for also supporting double precision.
Differential Revision: https://reviews.llvm.org/D60697
llvm-svn: 362601
Reid Kleckner