Commit Graph

206 Commits

Author SHA1 Message Date
Sylvestre Ledru 56799837a4 Update __VERSION__ to remove the hardcoded 4.2.1 version
Summary:
Just like in https://reviews.llvm.org/D56803
for -dumpversion

Reviewers: rnk

Reviewed By: rnk

Subscribers: dexonsmith, lebedev.ri, hubert.reinterpretcast, xbolva00, fedor.sergeev, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D63048

llvm-svn: 366091
2019-07-15 17:47:22 +00:00
Sylvestre Ledru 8f1d7d1c55 consistency in the release notes
llvm-svn: 366024
2019-07-14 18:25:09 +00:00
Sylvestre Ledru 21a92a8a55 This reverts commit 632a36bfcfc8273c1861f04ff6758d863c47c784.
Some targets such as Python 2.7.16 still use VERSION in
their builds. Without VERSION defined, the source code
has syntax errors.

Reverting as it will probably break many other things.

Noticed by Sterling Augustine

llvm-svn: 365992
2019-07-13 06:27:35 +00:00
Sylvestre Ledru 603580216f Remove __VERSION__
Summary:
It has been introduced in 2011 for gcc compat:
ad1a4c6e89
it is probably time to remove it


Reviewers: rnk, dexonsmith

Reviewed By: rnk

Subscribers: dschuff, aheejin, fedor.sergeev, arphaman, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D64062

llvm-svn: 365962
2019-07-12 21:45:08 +00:00
Sylvestre Ledru b2a549d7cf Add AlignConsecutiveMacros to the clang release notes
llvm-svn: 365445
2019-07-09 08:45:55 +00:00
Don Hinton 9b2d96024a [docs] Fix another bot error by setting highlight language of objc code-block to objc instead of c++.
llvm-svn: 363521
2019-06-16 19:15:04 +00:00
Kristina Brooks c0eb8a9825 Add __FILE_NAME__ to ReleaseNotes. NFC
Added it under C language changes as a nonstandard
extension for the time being.

llvm-svn: 362581
2019-06-05 03:47:02 +00:00
Akira Hatanaka 59839124f4 Add a release note entry for the change made in r362034.
llvm-svn: 362464
2019-06-03 23:48:14 +00:00
Nico Weber 833c5abbce Add release note entries for recent typo correction changes
Differential Revision: https://reviews.llvm.org/D62523

llvm-svn: 361824
2019-05-28 14:04:48 +00:00
Eric Christopher 030b17db66 Temporarily revert "Change -gz and -Wa,--compress-debug-sections to use gABI compression (SHF_COMPRESSED)"
This affects users of older (pre 2.26) binutils in such a way that they can't necessarily
work around it as it doesn't support the compress option on the command line. Reverting
to unblock them and we can revisit whether to make this change now or fix how we want
to express the option.

This reverts commit bdb21337e6e1732c9895966449c33c408336d295/r360403.

llvm-svn: 360703
2019-05-14 19:40:42 +00:00
Fangrui Song bdb21337e6 Change -gz and -Wa,--compress-debug-sections to use gABI compression (SHF_COMPRESSED)
Since July 15, 2015 (binutils-gdb commit
19a7fe52ae3d0971e67a134bcb1648899e21ae1c, included in 2.26), gas
--compress-debug-sections=zlib (gcc -gz) means zlib-gabi:
SHF_COMPRESSED. Before that it meant zlib-gnu (.zdebug).

clang's -gz was introduced in rC306115 (Jun 2017) to indicate zlib-gnu. It
is 2019 now and it is not unreasonable to assume users of the new
feature to have new linkers (ld.bfd/gold >= 2.26, lld >= rLLD273661).

Change clang's default accordingly to improve standard conformance.
zlib-gnu becomes out of fashion and gets poorer toolchain support.
Its mangled names confuse tools and are more likely to cause problems.

Reviewed By: compnerd

Differential Revision: https://reviews.llvm.org/D61689

llvm-svn: 360403
2019-05-10 02:08:21 +00:00
Sylvestre Ledru 5f163c7e2e Add to the release notes the fact that UninitializedObject checker is now
considered as stable

llvm-svn: 359350
2019-04-26 21:46:33 +00:00
Sylvestre Ledru 90dbbdbc95 update the release notes after the change of 'clang -dumpversion'
llvm-svn: 356983
2019-03-26 09:48:23 +00:00
Paul Hoad ccc6f838f7 [clang-format][NFC] correct the release notes
Move the clang-format notes to the correct section

llvm-svn: 356821
2019-03-22 22:47:34 +00:00
Paul Hoad cbb726d0c5 [clang-format] Add basic support for formatting C# files
Summary:

This revision adds basic support for formatting C# files with clang-format, I know the barrier to entry is high here  so I'm sending this revision in to test the water as to whether this might be something we'd consider landing.

Tracking in Bugzilla as:
https://bugs.llvm.org/show_bug.cgi?id=40850

Justification:
C# code just looks ugly in comparison to the C++ code in our source tree which is clang-formatted.

I've struggled with Visual Studio reformatting to get a clean and consistent style, I want to format our C# code on saving like I do now for C++ and i want it to have the same style as defined in our .clang-format file, so it consistent as it can be with C++.  (Braces/Breaking/Spaces/Indent etc..)

Using clang format without this patch leaves the code in a bad state, sometimes when the BreakStringLiterals is set, it  fails to compile.

Mostly the C# is similar to Java, except instead of JavaAnnotations I try to reuse the TT_AttributeSquare.

Almost the most valuable portion is to have a new Language in order to partition the configuration for C# within a common .clang-format file, with the auto detection on the .cs extension. But there are other C# specific styles that could be added later if this is accepted. in particular how  `{ set;get }` is formatted.

Reviewers: djasper, klimek, krasimir, benhamilton, JonasToth

Reviewed By: klimek

Subscribers: llvm-commits, mgorny, jdoerfert, cfe-commits

Tags: #clang, #clang-tools-extra

Differential Revision: https://reviews.llvm.org/D58404

llvm-svn: 356662
2019-03-21 13:09:22 +00:00
Paul Hoad 7c6ce35c1d [clang-format][NFC] fix release notes build issue
build issue from r356613

llvm-svn: 356615
2019-03-20 21:02:12 +00:00
Paul Hoad 701a0d7e47 [clang-format] BeforeHash added to IndentPPDirectives
Summary:
The option BeforeHash added to IndentPPDirectives.
Fixes Bug 36019. https://bugs.llvm.org/show_bug.cgi?id=36019

Reviewers: djasper, klimek, krasimir, sammccall, mprobst, Nicola, MyDeveloperDay

Reviewed By: klimek, MyDeveloperDay

Subscribers: kadircet, MyDeveloperDay, mnussbaum, geleji, ufna, cfe-commits

Patch by to-mix.

Differential Revision: https://reviews.llvm.org/D52150

llvm-svn: 356613
2019-03-20 20:49:43 +00:00
Shoaib Meenai 20e7c0c450 [clang] Add install targets for API headers
Add an install target for clang's API headers, which allows them to be
included in distributions. The install rules already existed, but they
lacked a component and a target, making them only accessible via a full
install. These headers are useful for writing clang-based tooling, for
example. They're the clang equivalent to the llvm-headers target and
complement the clang-libraries target.

Differential Revision: https://reviews.llvm.org/D58317

llvm-svn: 355853
2019-03-11 18:53:57 +00:00
Shoaib Meenai 5be71faf4b [build] Rename clang-headers to clang-resource-headers
Summary:
The current install-clang-headers target installs clang's resource
directory headers. This is different from the install-llvm-headers
target, which installs LLVM's API headers. We want to introduce the
corresponding target to clang, and the natural name for that new target
would be install-clang-headers. Rename the existing target to
install-clang-resource-headers to free up the install-clang-headers name
for the new target, following the discussion on cfe-dev [1].

I didn't find any bots on zorg referencing install-clang-headers. I'll
send out another PSA to cfe-dev to accompany this rename.

[1] http://lists.llvm.org/pipermail/cfe-dev/2019-February/061365.html

Reviewers: beanz, phosek, tstellar, rnk, dim, serge-sans-paille

Subscribers: mgorny, javed.absar, jdoerfert, #sanitizers, openmp-commits, lldb-commits, cfe-commits, llvm-commits

Tags: #clang, #sanitizers, #lldb, #openmp, #llvm

Differential Revision: https://reviews.llvm.org/D58791

llvm-svn: 355340
2019-03-04 21:19:53 +00:00
Alexey Bataev c2dc4d4aef [DOCS]Support for emission of the debug info for the Cuda devices, NFC.
llvm-svn: 353214
2019-02-05 20:38:36 +00:00
Leonard Chan 009f9e8231 [Sema] Fix Modified Type in address_space AttributedType
This is a fix for https://reviews.llvm.org/D51229 where we pass the
address_space qualified type as the modified type of an AttributedType. This
change now instead wraps the AttributedType with either the address_space
qualifier or a DependentAddressSpaceType.

Differential Revision: https://reviews.llvm.org/D55447

llvm-svn: 351997
2019-01-24 00:11:35 +00:00
Hans Wennborg a5f7e5b8dc ReleaseNotes: remove openmp notes from r351580
They were for the 8.0 branch, and have been committed there in r351839.

llvm-svn: 351841
2019-01-22 17:01:39 +00:00
Kelvin Li f345b0c0b9 [OPENMP][DOCS] Release notes/OpenMP support updates, NFC.
Differential Revision: https://reviews.llvm.org/D56733

llvm-svn: 351580
2019-01-18 19:57:37 +00:00
Hans Wennborg 1fe469ae6c Bump the trunk version to 9.0.0svn
llvm-svn: 351320
2019-01-16 10:57:02 +00:00
Roman Lebedev bd1c087019 [clang][UBSan] Sanitization for alignment assumptions.
Summary:
UB isn't nice. It's cool and powerful, but not nice.
Having a way to detect it is nice though.
[[ https://wg21.link/p1007r3 | P1007R3: std::assume_aligned ]] / http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1007r2.pdf says:
```
We propose to add this functionality via a library function instead of a core language attribute.
...
If the pointer passed in is not aligned to at least N bytes, calling assume_aligned results in undefined behaviour.
```

This differential teaches clang to sanitize all the various variants of this assume-aligned attribute.

Requires D54588 for LLVM IRBuilder changes.
The compiler-rt part is D54590.

This is a second commit, the original one was r351105,
which was mass-reverted in r351159 because 2 compiler-rt tests were failing.

Reviewers: ABataev, craig.topper, vsk, rsmith, rnk, #sanitizers, erichkeane, filcab, rjmccall

Reviewed By: rjmccall

Subscribers: chandlerc, ldionne, EricWF, mclow.lists, cfe-commits, bkramer

Tags: #sanitizers

Differential Revision: https://reviews.llvm.org/D54589

llvm-svn: 351177
2019-01-15 09:44:25 +00:00
Vlad Tsyrklevich 86e68fda3b Revert alignment assumptions changes
Revert r351104-6, r351109, r351110, r351119, r351134, and r351153. These
changes fail on the sanitizer bots.

llvm-svn: 351159
2019-01-15 03:38:02 +00:00
Roman Lebedev 7892c37455 [clang][UBSan] Sanitization for alignment assumptions.
Summary:
UB isn't nice. It's cool and powerful, but not nice.
Having a way to detect it is nice though.
[[ https://wg21.link/p1007r3 | P1007R3: std::assume_aligned ]] / http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1007r2.pdf says:
```
We propose to add this functionality via a library function instead of a core language attribute.
...
If the pointer passed in is not aligned to at least N bytes, calling assume_aligned results in undefined behaviour.
```

This differential teaches clang to sanitize all the various variants of this assume-aligned attribute.

Requires D54588 for LLVM IRBuilder changes.
The compiler-rt part is D54590.

Reviewers: ABataev, craig.topper, vsk, rsmith, rnk, #sanitizers, erichkeane, filcab, rjmccall

Reviewed By: rjmccall

Subscribers: chandlerc, ldionne, EricWF, mclow.lists, cfe-commits, bkramer

Tags: #sanitizers

Differential Revision: https://reviews.llvm.org/D54589

llvm-svn: 351105
2019-01-14 19:09:27 +00:00
Alexey Bataev 2819d4d19c [OPENMP][DOCS]Release notes/OpenMP support updates, NFC.
llvm-svn: 350757
2019-01-09 20:32:56 +00:00
Ilya Biryukov 88aef52a5d Mention changes to libc++ include dir lookup in release notes.
Summary: The change itself landed as r348365, see the comment for more details.

Reviewers: arphaman, EricWF

Reviewed By: arphaman

Subscribers: cfe-commits

Differential Revision: https://reviews.llvm.org/D55322

llvm-svn: 348394
2018-12-05 18:32:05 +00:00
Erich Keane 0a6b5b653e PTH-- Remove feature entirely-
When debugging a boost build with a modified
version of Clang, I discovered that the PTH implementation
stores TokenKind in 8 bits. However, we currently have 368
TokenKinds.

The result is that the value gets truncated and the wrong token
gets picked up when including PTH files. It seems that this will
go wrong every time someone uses a token that uses the 9th bit.

Upon asking on IRC, it was brought up that this was a highly
experimental features that was considered a failure. I discovered
via googling that BoostBuild (mostly Boost.Math) is the only user of
this
feature, using the CC1 flag directly. I believe that this can be
transferred over to normal PCH with minimal effort:
https://github.com/boostorg/build/issues/367

Based on advice on IRC and research showing that this is a nearly
completely unused feature, this patch removes it entirely.

Note: I considered leaving the build-flags in place and making them
emit an error/warning, however since I've basically identified and
warned the only user, it seemed better to just remove them.

Differential Revision: https://reviews.llvm.org/D54547

Change-Id: If32744275ef1f585357bd6c1c813d96973c4d8d9
llvm-svn: 348266
2018-12-04 14:34:09 +00:00
Roman Lebedev 377748fd7b [clang][Parse] Diagnose useless null statements / empty init-statements
Summary:
clang has `-Wextra-semi` (D43162), which is not dictated by the currently selected standard.
While that is great, there is at least one more source of need-less semis - 'null statements'.
Sometimes, they are needed:
```
for(int x = 0; continueToDoWork(x); x++)
  ; // Ugly code, but the semi is needed here.
```

But sometimes they are just there for no reason:
```
switch(X) {
case 0:
  return -2345;
case 5:
  return 0;
default:
  return 42;
}; // <- oops

;;;;;;;;;;; <- OOOOPS, still not diagnosed. Clearly this is junk.
```

Additionally:
```
if(; // <- empty init-statement
   true)
  ;

switch (; // empty init-statement
        x) {
  ...
}

for (; // <- empty init-statement
     int y : S())
  ;
}

As usual, things may or may not go sideways in the presence of macros.
While evaluating this diag on my codebase of interest, it was unsurprisingly
discovered that Google Test macros are *very* prone to this.
And it seems many issues are deep within the GTest itself, not
in the snippets passed from the codebase that uses GTest.

So after some thought, i decided not do issue a diagnostic if the semi
is within *any* macro, be it either from the normal header, or system header.

Fixes [[ https://bugs.llvm.org/show_bug.cgi?id=39111 | PR39111 ]]

Reviewers: rsmith, aaron.ballman, efriedma

Reviewed By: aaron.ballman

Subscribers: cfe-commits

Differential Revision: https://reviews.llvm.org/D52695

llvm-svn: 347339
2018-11-20 18:59:05 +00:00
Roman Lebedev d677c3fc61 [clang][CodeGen] Implicit Conversion Sanitizer: discover the world of CompoundAssign operators
Summary:
As reported by @regehr (thanks!) on twitter (https://twitter.com/johnregehr/status/1057681496255815686),
we (me) has completely forgot about the binary assignment operator.
In AST, it isn't represented as separate `ImplicitCastExpr`'s,
but as a single `CompoundAssignOperator`, that does all the casts internally.
Which means, out of these two, only the first one is diagnosed:
```
auto foo() {
    unsigned char c = 255;
    c = c + 1;
    return c;
}
auto bar() {
    unsigned char c = 255;
    c += 1;
    return c;
}
```
https://godbolt.org/z/JNyVc4

This patch does handle the `CompoundAssignOperator`:
```
int main() {
  unsigned char c = 255;
  c += 1;
  return c;
}
```
```
$ ./bin/clang -g -fsanitize=integer /tmp/test.c && ./a.out
/tmp/test.c:3:5: runtime error: implicit conversion from type 'int' of value 256 (32-bit, signed) to type 'unsigned char' changed the value to 0 (8-bit, unsigned)
    #0 0x2392b8 in main /tmp/test.c:3:5
    #1 0x7fec4a612b16 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x22b16)
    #2 0x214029 in _start (/build/llvm-build-GCC-release/a.out+0x214029)
```

However, the pre/post increment/decrement is still not handled.

Reviewers: rsmith, regehr, vsk, rjmccall, #sanitizers

Reviewed By: rjmccall

Subscribers: mclow.lists, cfe-commits, regehr

Tags: #clang, #sanitizers

Differential Revision: https://reviews.llvm.org/D53949

llvm-svn: 347258
2018-11-19 19:56:43 +00:00
Calixte Denizet f4bf671af7 [Clang] Add options -fprofile-filter-files and -fprofile-exclude-files to filter the files to instrument with gcov (after revert https://reviews.llvm.org/rL346659)
Summary:
the previous patch (https://reviews.llvm.org/rC346642) has been reverted because of test failure under windows.
So this patch fix the test cfe/trunk/test/CodeGen/code-coverage-filter.c.

Reviewers: marco-c

Reviewed By: marco-c

Subscribers: cfe-commits, sylvestre.ledru

Differential Revision: https://reviews.llvm.org/D54600

llvm-svn: 347144
2018-11-17 19:41:39 +00:00
Calixte Denizet 186d5bd874 Revert rL346644, rL346642: the added test test/CodeGen/code-coverage-filter.c is failing under windows
llvm-svn: 346659
2018-11-12 14:57:17 +00:00
Calixte Denizet cedcc73d93 [Clang] Add options -fprofile-filter-files and -fprofile-exclude-files to filter the files to instrument with gcov
Summary:
These options are taking regex separated by colons to filter files.
- if both are empty then all files are instrumented
- if -fprofile-filter-files is empty then all the filenames matching any of the regex from exclude are not instrumented
- if -fprofile-exclude-files is empty then all the filenames matching any of the regex from filter are instrumented
- if both aren't empty then all the filenames which match any of the regex in filter and which don't match all the regex in filter are instrumented
- this patch is a follow-up of https://reviews.llvm.org/D52033

Reviewers: marco-c, vsk

Reviewed By: marco-c, vsk

Subscribers: cfe-commits, sylvestre.ledru

Differential Revision: https://reviews.llvm.org/D52034

llvm-svn: 346642
2018-11-12 09:12:27 +00:00
Hans Wennborg a97c4e3eee Release notes: Mention clang-cl's /Zc:dllexportInlines- flag
llvm-svn: 346640
2018-11-12 08:42:21 +00:00
Jonas Toth aa51ef1287 [clang] try-fix broken documentation builder
llvm-svn: 345737
2018-10-31 17:00:50 +00:00
Roman Lebedev 62debd8055 [clang][ubsan] Implicit Conversion Sanitizer - integer sign change - clang part
This is the second half of Implicit Integer Conversion Sanitizer.
It completes the first half, and finally makes the sanitizer
fully functional! Only the bitfield handling is missing.

Summary:
C and C++ are interesting languages. They are statically typed, but weakly.
The implicit conversions are allowed. This is nice, allows to write code
while balancing between getting drowned in everything being convertible,
and nothing being convertible. As usual, this comes with a price:

```
void consume(unsigned int val);

void test(int val) {
  consume(val);
  // The 'val' is `signed int`, but `consume()` takes `unsigned int`.
  // If val is negative, then consume() will be operating on a large
  // unsigned value, and you may or may not have a bug.

  // But yes, sometimes this is intentional.
  // Making the conversion explicit silences the sanitizer.
  consume((unsigned int)val);
}
```

Yes, there is a `-Wsign-conversion`` diagnostic group, but first, it is kinda
noisy, since it warns on everything (unlike sanitizers, warning on an
actual issues), and second, likely there are cases where it does **not** warn.

The actual detection is pretty easy. We just need to check each of the values
whether it is negative, and equality-compare the results of those comparisons.
The unsigned value is obviously non-negative. Zero is non-negative too.
https://godbolt.org/g/w93oj2

We do not have to emit the check *always*, there are obvious situations
where we can avoid emitting it, since it would **always** get optimized-out.
But i do think the tautological IR (`icmp ult %x, 0`, which is always false)
should be emitted, and the middle-end should cleanup it.

This sanitizer is in the `-fsanitize=implicit-conversion` group,
and is a logical continuation of D48958 `-fsanitize=implicit-integer-truncation`.
As for the ordering, i'we opted to emit the check **after**
`-fsanitize=implicit-integer-truncation`. At least on these simple 16 test cases,
this results in 1 of the 12 emitted checks being optimized away,
as compared to 0 checks being optimized away if the order is reversed.

This is a clang part.
The compiler-rt part is D50251.

Finishes fixing [[ https://bugs.llvm.org/show_bug.cgi?id=21530 | PR21530 ]], [[ https://bugs.llvm.org/show_bug.cgi?id=37552 | PR37552 ]], [[ https://bugs.llvm.org/show_bug.cgi?id=35409 | PR35409 ]].
Finishes partially fixing [[ https://bugs.llvm.org/show_bug.cgi?id=9821 | PR9821 ]].
Finishes fixing https://github.com/google/sanitizers/issues/940.

Only the bitfield handling is missing.

Reviewers: vsk, rsmith, rjmccall, #sanitizers, erichkeane

Reviewed By: rsmith

Subscribers: chandlerc, filcab, cfe-commits, regehr

Tags: #sanitizers, #clang

Differential Revision: https://reviews.llvm.org/D50250

llvm-svn: 345660
2018-10-30 21:58:56 +00:00
Erik Pilkington 7d18094813 Revert "Revert "Support for groups of attributes in #pragma clang attribute""
This reverts commit r345487, which reverted r345486. I think the crashes were
caused by an OOM on the builder, trying again to confirm...

llvm-svn: 345517
2018-10-29 17:38:42 +00:00
Erik Pilkington b287a015e3 Revert "Support for groups of attributes in #pragma clang attribute"
This reverts commit r345486.

Looks like it causes some old versions of GCC to crash, I'll see if I can
work around it and recommit...

llvm-svn: 345487
2018-10-29 03:24:16 +00:00
Erik Pilkington a7cc6b360f Support for groups of attributes in #pragma clang attribute
This commit enables pushing an empty #pragma clang attribute push, then adding
multiple attributes to it, then popping them all with #pragma clang attribute
pop, just like #pragma clang diagnostic. We still support the current way of
adding these, #pragma clang attribute push(__attribute__((...))), by treating it
like a combined push/attribute. This is needed to create macros like:

DO_SOMETHING_BEGIN(attr1, attr2, attr3)
// ...
DO_SOMETHING_END

rdar://45496947

Differential revision: https://reviews.llvm.org/D53621

llvm-svn: 345486
2018-10-29 02:29:21 +00:00
Richard Smith 6822bd79ac PR26547: alignof should return ABI alignment, not preferred alignment
Summary:
- Add `UETT_PreferredAlignOf` to account for the difference between `__alignof` and `alignof`
- `AlignOfType` now returns ABI alignment instead of preferred alignment iff clang-abi-compat > 7, and one uses _Alignof or alignof

Patch by Nicole Mazzuca!

Differential Revision: https://reviews.llvm.org/D53207

llvm-svn: 345419
2018-10-26 19:26:45 +00:00
Richard Smith 8654ae52b0 Add a flag to remap manglings when reading profile data information.
This can be used to preserve profiling information across codebase
changes that have widespread impact on mangled names, but across which
most profiling data should still be usable. For example, when switching
from libstdc++ to libc++, or from the old libstdc++ ABI to the new ABI,
or even from a 32-bit to a 64-bit build.

The user can provide a remapping file specifying parts of mangled names
that should be treated as equivalent (eg, std::__1 should be treated as
equivalent to std::__cxx11), and profile data will be treated as
applying to a particular function if its name is equivalent to the name
of a function in the profile data under the provided equivalences. See
the documentation change for a description of how this is configured.

Remapping is supported for both sample-based profiling and instruction
profiling. We do not support remapping indirect branch target
information, but all other profile data should be remapped
appropriately.

Support is only added for the new pass manager. If someone wants to also
add support for this for the old pass manager, doing so should be
straightforward.

llvm-svn: 344199
2018-10-10 23:13:35 +00:00
Mike Rice 58df1affed [clang-cl, PCH] Support for /Yc and /Yu without filename and #pragma hdrstop
With clang-cl, when the user specifies /Yc or /Yu without a filename
the compiler uses a #pragma hdrstop in the main source file to
determine the end of the PCH. If a header is specified with /Yc or
/Yu #pragma hdrstop has no effect.

The optional #pragma hdrstop filename argument is not yet supported.

Differential Revision: https://reviews.llvm.org/D51391

llvm-svn: 341963
2018-09-11 17:10:44 +00:00
Hans Wennborg 0aa0d91e98 ReleaseNotes: update links to use https
llvm-svn: 341786
2018-09-10 08:51:25 +00:00
Hans Wennborg 3d0d25ddf4 Update docs version and clear release notes after 8.0.0 version bump
llvm-svn: 338557
2018-08-01 14:01:27 +00:00
Roman Lebedev b69ba22773 [clang][ubsan] Implicit Conversion Sanitizer - integer truncation - clang part
Summary:
C and C++ are interesting languages. They are statically typed, but weakly.
The implicit conversions are allowed. This is nice, allows to write code
while balancing between getting drowned in everything being convertible,
and nothing being convertible. As usual, this comes with a price:

```
unsigned char store = 0;

bool consume(unsigned int val);

void test(unsigned long val) {
  if (consume(val)) {
    // the 'val' is `unsigned long`, but `consume()` takes `unsigned int`.
    // If their bit widths are different on this platform, the implicit
    // truncation happens. And if that `unsigned long` had a value bigger
    // than UINT_MAX, then you may or may not have a bug.

    // Similarly, integer addition happens on `int`s, so `store` will
    // be promoted to an `int`, the sum calculated (0+768=768),
    // and the result demoted to `unsigned char`, and stored to `store`.
    // In this case, the `store` will still be 0. Again, not always intended.
    store = store + 768; // before addition, 'store' was promoted to int.
  }

  // But yes, sometimes this is intentional.
  // You can either make the conversion explicit
  (void)consume((unsigned int)val);
  // or mask the value so no bits will be *implicitly* lost.
  (void)consume((~((unsigned int)0)) & val);
}
```

Yes, there is a `-Wconversion`` diagnostic group, but first, it is kinda
noisy, since it warns on everything (unlike sanitizers, warning on an
actual issues), and second, there are cases where it does **not** warn.
So a Sanitizer is needed. I don't have any motivational numbers, but i know
i had this kind of problem 10-20 times, and it was never easy to track down.

The logic to detect whether an truncation has happened is pretty simple
if you think about it - https://godbolt.org/g/NEzXbb - basically, just
extend (using the new, not original!, signedness) the 'truncated' value
back to it's original width, and equality-compare it with the original value.

The most non-trivial thing here is the logic to detect whether this
`ImplicitCastExpr` AST node is **actually** an implicit conversion, //or//
part of an explicit cast. Because the explicit casts are modeled as an outer
`ExplicitCastExpr` with some `ImplicitCastExpr`'s as **direct** children.
https://godbolt.org/g/eE1GkJ

Nowadays, we can just use the new `part_of_explicit_cast` flag, which is set
on all the implicitly-added `ImplicitCastExpr`'s of an `ExplicitCastExpr`.
So if that flag is **not** set, then it is an actual implicit conversion.

As you may have noted, this isn't just named `-fsanitize=implicit-integer-truncation`.
There are potentially some more implicit conversions to be warned about.
Namely, implicit conversions that result in sign change; implicit conversion
between different floating point types, or between fp and an integer,
when again, that conversion is lossy.

One thing i know isn't handled is bitfields.

This is a clang part.
The compiler-rt part is D48959.

Fixes [[ https://bugs.llvm.org/show_bug.cgi?id=21530 | PR21530 ]], [[ https://bugs.llvm.org/show_bug.cgi?id=37552 | PR37552 ]], [[ https://bugs.llvm.org/show_bug.cgi?id=35409 | PR35409 ]].
Partially fixes [[ https://bugs.llvm.org/show_bug.cgi?id=9821 | PR9821 ]].
Fixes https://github.com/google/sanitizers/issues/940. (other than sign-changing implicit conversions)

Reviewers: rjmccall, rsmith, samsonov, pcc, vsk, eugenis, efriedma, kcc, erichkeane

Reviewed By: rsmith, vsk, erichkeane

Subscribers: erichkeane, klimek, #sanitizers, aaron.ballman, RKSimon, dtzWill, filcab, danielaustin, ygribov, dvyukov, milianw, mclow.lists, cfe-commits, regehr

Tags: #sanitizers

Differential Revision: https://reviews.llvm.org/D48958

llvm-svn: 338288
2018-07-30 18:58:30 +00:00
Alexey Bataev c5982fb634 [OPENMP, DOCS] Fixed typo, NFC.
llvm-svn: 338055
2018-07-26 18:40:41 +00:00
Alexey Bataev 3bdd60095f [OPENMP] What's new for OpenMP in clang.
Updated ReleaseNotes + Status of the OpenMP support in clang.

llvm-svn: 338049
2018-07-26 17:53:45 +00:00
Nico Weber f925b33854 fix typo
llvm-svn: 337620
2018-07-20 21:06:41 +00:00