I don't know if this is correct, but this is what we currently do.
More discussion in PR27108 and PR27435 and D27618.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@316250 91177308-0d34-0410-b5e6-96231b3b80d8
constant expressions.
We permit array-to-pointer decay on such arrays, but disallow pointer
arithmetic (since we do not know whether it will have defined behavior).
This is based on r311970 and r301822 (the former by me and the latter by Robert
Haberlach). Between then and now, two things have changed: we have committee
feedback indicating that this is indeed the right direction, and the code
broken by this change has been fixed.
This is necessary in C++17 to continue accepting certain forms of non-type
template argument involving arrays of unknown bound.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@316245 91177308-0d34-0410-b5e6-96231b3b80d8
In some cases the compiler can deduce the length of an array section
as constants. With this information, VLAs can be avoided in place of
a constant sized array or even a scalar value if the length is 1.
Example:
int a[4], b[2];
pragma omp parallel reduction(+: a[1:2], b[1:1])
{ }
For chained array sections, this optimization is restricted to cases
where all array sections except the last have a constant length 1.
This trivially guarantees that there are no holes in the memory region
that needs to be privatized.
Example:
int c[3][4];
pragma omp parallel reduction(+: c[1:1][1:2])
{ }
Differential Revision: https://reviews.llvm.org/D39136
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@316229 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Change clang-refactor default behavior to print the new code after refactoring
(instead of editing the source files), which would make it easier to use
and debug the refactoring action.
Reviewers: arphaman, ioeric
Reviewed By: arphaman
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D39092
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@316212 91177308-0d34-0410-b5e6-96231b3b80d8
NetBSD uses `long int` for `intptr_t` on ARM. This was changed in SVN
r316046, referenced against other compilers. However, NetBSD's
reference was incorrect as the current clang behaviour is more
up-to-date. Restore the original behaviour for that target.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@316204 91177308-0d34-0410-b5e6-96231b3b80d8
This patch breaks users using -fno-canonical-prefixes, for whom resolving
symlinks is not acceptable.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@316195 91177308-0d34-0410-b5e6-96231b3b80d8
In function GetIntrinsic, not all types are covered. Types double and long long are missed, type long is wrongly treated same as int, it should be same as long long. These problems cause compiler crashes when compiling code in PR31161. This patch fixed the problem.
Differential Revision: https://reviews.llvm.org/D38820
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@316179 91177308-0d34-0410-b5e6-96231b3b80d8
instantiation declarations if they are usable from constant expressions.
We are permitted to instantiate in these cases, and required to do so in order
to have an initializer available for use within constant evaluation.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@316136 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This patch enables sorting the full block of using declarations when
some line is affected.
Reviewers: djasper
Reviewed By: djasper
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D39024
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@316130 91177308-0d34-0410-b5e6-96231b3b80d8
consecutive statements
This commit adds a CodeRangeASTSelection value to the refactoring library. This
value represents a set of selected statements in one body of code.
Differential Revision: https://reviews.llvm.org/D38835
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@316104 91177308-0d34-0410-b5e6-96231b3b80d8
This patch has the following changes
A new flag "-mhvx-length={64B|128B}" is introduced to specify the length of the vector.
Previously we have used "-mhvx-double" for 128 Bytes. This adds the target-feature "+hvx-length{64|128}b"
The "-mhvx" flag must be provided on command line to enable HVX for Hexagon. If no -mhvx-length flag
is specified, a default length is picked from the arch mentioned in this priority order from either -mhvx=vxx
or -mcpu. For v60 and v62 the default length is 64 Byte. For unknown versions, the length is 128 Byte. The
-mhvx flag adds the target-feature "+hvxv{hvx_version}"
The 64 Byte mode is soon going to be deprecated. A warning is emitted if 64 Byte is enabled. A warning is
still emitted for the default 64 Byte as well. This warning can be suppressed with a -Wno flag.
The "-mhvx-double" and "-mno-hvx-double" flags are deprecated. A warning is emitted if the driver sees
them on commandline. "-mhvx-double" is an alias to "-mhvx-length=128B"
The compilation will error out if -mhvx-length is specified with out an -mhvx/-mhvx= flag
The macro HVX_LENGTH is defined and is set to the length of the vector.
Eg: #define HVX_LENGTH 64
The macro HVX_ARCH is defined and is set to the version of the HVX.
Eg: #define HVX_ARCH 62
Differential Revision: https://reviews.llvm.org/D38852
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@316102 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
* Support rename alias.
* Add unittests for renaming alias.
* Don't generate fixes for the SourceLocations that are invalid or in temporary
buffer, otherwise crash would be happened when generating AtomicChanges.
Reviewers: ioeric
Reviewed By: ioeric
Subscribers: klimek, mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D39043
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@316074 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@316061 91177308-0d34-0410-b5e6-96231b3b80d8
instantiation, follow lexical parents not semantic ones: we want to find the
module where the pattern was written.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@316055 91177308-0d34-0410-b5e6-96231b3b80d8
Darwin and OpenBSD are the only platforms which use `long int` for
`__INTPTR_TYPE__`. The other platforms use `int` in 32-bit, and `long
int` on 64-bit (except for VMS and Windows which are LLP64). Adjust the
type definitions to match the platform definitions. We now generate the
same definition as GCC on all the targets.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@316046 91177308-0d34-0410-b5e6-96231b3b80d8
Remove an option to use a reference type (on by default!) since a
non-reference type is always needed for creating expressions, functions
with multiple boolean parameters are very hard to use, and in general it
was just a booby trap for further crashes.
Furthermore, generalize call_once test case to fix some of the crashes mentioned
https://bugs.llvm.org/show_bug.cgi?id=34869
Also removes std::call_once crash.
Differential Revision: https://reviews.llvm.org/D39015
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@316041 91177308-0d34-0410-b5e6-96231b3b80d8
Masud Rahman