[PATCH] D75012: [ReleaseNotes] Mention -fmacro-prefix-map and -ffile-prefix-map.

Lekensteyn updated this revision to Diff 246413. Lekensteyn marked 2 inline comments as done. Lekensteyn added a comment. Updated the comment based on @MaskRay's feedback, thanks! This (and the previous) patch were based on release/10.x, I plan to commit it later today since the final tag is

[PATCH] D75012: [ReleaseNotes] Mention -fmacro-prefix-map and -ffile-prefix-map.

Lekensteyn created this revision. Lekensteyn added reviewers: dankm, MaskRay, hans. Herald added a project: clang. Repository: rG LLVM Github Monorepo https://reviews.llvm.org/D75012 Files: clang/docs/ReleaseNotes.rst Index: clang/docs/ReleaseNotes.rst

[PATCH] D49466: Initial implementation of -fmacro-prefix-map and -ffile-prefix-map

Lekensteyn added a comment. Thanks for picking this up again. I've left some nitpicks below in a quick review. The "strict" parameter is not precisely defined, if that is fixed I think this would be ready for merge. Comment at: clang/test/Driver/debug-prefix-map.c:8 +//

[PATCH] D61838: [Sema] Suppress additional warnings for C's zero initializer

This revision was automatically updated to reflect the committed changes. Closed by commit rL366163: [Sema] Suppress additional warnings for Cs zero initializer (authored by Lekensteyn, committed by ). Herald added a project: LLVM. Changed prior to commit:

[PATCH] D61838: [Sema] Suppress additional warnings for C's zero initializer

Lekensteyn accepted this revision. Lekensteyn added a comment. Thanks, I'll push once the build and test pass. Repository: rC Clang CHANGES SINCE LAST ACTION https://reviews.llvm.org/D61838/new/ https://reviews.llvm.org/D61838 ___ cfe-commits

[PATCH] D61838: [Sema] Suppress additional warnings for C's zero initializer

Lekensteyn added a comment. @al3xtjames I was about to commit this but noticed that some others check whether `getInit(0)` is NULL or not before proceeding. Should that be done here as well? If not, why? See for example "Harden InitListExpr::isStringLiteralInit() against getInit() returning

[PATCH] D49466: Initial implementation of -fmacro-prefix-map and -ffile-prefix-map

Lekensteyn added a comment. Hi @dankm, any progress on this feature? The proposed branch off date for Clang 9.0.0 is 18 July 2019: https://lists.llvm.org/pipermail/cfe-dev/2019-June/062628.html Repository: rC Clang CHANGES SINCE LAST ACTION https://reviews.llvm.org/D49466/new/

[PATCH] D61838: [Sema] Suppress additional warnings for C's zero initializer

Lekensteyn added a comment. @rsmith The latest patch version has addressed your feedback, can you confirm that this is ready to be merged? Repository: rC Clang CHANGES SINCE LAST ACTION https://reviews.llvm.org/D61838/new/ https://reviews.llvm.org/D61838

[PATCH] D61838: [Sema] Suppress additional warnings for C's zero initializer

Lekensteyn added a comment. @rsmith Are you happy with the changes, is it ready to be merged? Repository: rC Clang CHANGES SINCE LAST ACTION https://reviews.llvm.org/D61838/new/ https://reviews.llvm.org/D61838 ___ cfe-commits mailing list

[PATCH] D61838: [Sema] Suppress additional warnings for C's zero initializer

Lekensteyn accepted this revision. Lekensteyn added a comment. Verified again! Repository: rC Clang CHANGES SINCE LAST ACTION https://reviews.llvm.org/D61838/new/ https://reviews.llvm.org/D61838 ___ cfe-commits mailing list

[PATCH] D61838: [Sema] Suppress additional warnings for C's zero initializer

Lekensteyn accepted this revision. Lekensteyn added a comment. This revision is now accepted and ready to land. Thanks, I have also verified this patch against the above test case. Repository: rC Clang CHANGES SINCE LAST ACTION https://reviews.llvm.org/D61838/new/

[PATCH] D61838: [Sema] Suppress additional warnings for C's zero initializer

Lekensteyn added a comment. This looks reasonable to fix the problem at hand, but would it handle nested structures too? struct s1 { short f1; // "int f1" is fine. }; struct s2 { struct s1 f2; int x; }; struct s3 { struct s2 f3; int x; }; struct s2 x1 =

[PATCH] D49466: Initial implementation of -fmacro-prefix-map and -ffile-prefix-map

Lekensteyn added inline comments. Comment at: lib/CodeGen/CGDebugInfo.cpp:607 llvm::DIFile *CUFile = DBuilder.createFile( - remapDIPath(MainFileName), remapDIPath(getCurrentDirname()), CSInfo, + MainFileName, remapDIPath(getCurrentDirname()), CSInfo,

[PATCH] D49466: Initial implementation of -fmacro-prefix-map and -ffile-prefix-map

Lekensteyn added a comment. Changes still look reasonable, but the preceding path (https://reviews.llvm.org/D56769) needs some work. Comment at: lib/CodeGen/CGDebugInfo.cpp:607 llvm::DIFile *CUFile = DBuilder.createFile( - remapDIPath(MainFileName),

[PATCH] D47819: [compiler-rt] [test] Disable sunrpc tests when rpc/xdr.h is missing

Lekensteyn accepted this revision. Lekensteyn added a comment. This revision is now accepted and ready to land. In D47819#1356498 , @mgorny wrote: > PASS: MemorySanitizer-X86_64 :: Linux/sunrpc_bytes.cc (2932 of 6195) > PASS: MemorySanitizer-X86_64 ::

[PATCH] D47819: [compiler-rt] [test] Disable sunrpc tests when rpc/xdr.h is missing

Lekensteyn added a comment. The direction of this patch looks reasonable to me. Is it worth mentioning the issue (https://github.com/google/sanitizers/issues/974) in the commit message? What environment have you tested this in, could you verify that the tests are indeed skipped on a system

[PATCH] D49466: Initial implementation of -fmacro-prefix-map and -ffile-prefix-map

Lekensteyn accepted this revision. Lekensteyn added a comment. Still fine by me, thanks! As for the commit message, perhaps reference: https://bugs.llvm.org/show_bug.cgi?id=38135 Repository: rC Clang CHANGES SINCE LAST ACTION https://reviews.llvm.org/D49466/new/

[PATCH] D49466: Initial implementation of -fmacro-prefix-map and -ffile-prefix-map

Lekensteyn accepted this revision. Lekensteyn added a comment. This revision is now accepted and ready to land. Tests pass here, using it on a large CMake project with a CMAKE_BUILD_TYPE=Debug and c/cxxflags `-ffile-prefix-map=$builddir= -ffile-prefix-map=$srcdir/= -fuse-ld=lld` successfully

[PATCH] D49466: Initial implementation of -fmacro-prefix-map and -ffile-prefix-map

Lekensteyn added a comment. Except one thing, it looks reasonable to me. I'll try to run some tests and report back tomorrow. (Not very familiar with Phabricator either. I still see some comments, hopefully the "Collapse" function does something useful here.) Comment at:

[PATCH] D49466: Initial implementation of -fmacro-prefix-map and -ffile-prefix-map

Lekensteyn added a comment. Could you add more tests to check the error message for bad options (missing `=`): -fdebug-prefix-map=bad -fmacro-prefix-map=bad -ffile-prefix-map=bad FWIW, GCC emits two errors for `-ffile-prefix-map=bad`. Another edge case is `-ffile-prefix-map==foo/`, GCC

[PATCH] D49466: Initial implementation of -fmacro-prefix-map and -ffile-prefix-map

Lekensteyn added a comment. It would be nice to have this for Clang 8.0, the branch date is within 5 days :) Comment at: lib/Driver/ToolChains/Clang.cpp:617 if (Map.find('=') == StringRef::npos) - D.Diag(diag::err_drv_invalid_argument_to_fdebug_prefix_map) << Map; +

[PATCH] D47817: [compiler-rt] [sanitizer_common] Fix using libtirpc on Linux

Lekensteyn added a comment. There appears to be other definitions for HAVE_TIRPC_RPC_XDR_H in lib/sanitizer_common/sanitizer_platform.h lib/sanitizer_common/sanitizer_platform_limits_freebsd.cc While at it, perhaps the `#if HAVE_FOO` could be replaced by `#ifdef HAVE_FOO`? CHANGES SINCE LAST

[PATCH] D54109: [clang-query] continue querying even if files are skipped

Lekensteyn abandoned this revision. Lekensteyn added a comment. This was addressed by https://reviews.llvm.org/D51183 (without new tests though). CHANGES SINCE LAST ACTION https://reviews.llvm.org/D54109/new/ https://reviews.llvm.org/D54109 ___

[PATCH] D54109: [clang-query] continue querying even if files are skipped

Lekensteyn updated this revision to Diff 172747. Lekensteyn retitled this revision from "[clang-query] continue even if files are skipped" to "[clang-query] continue querying even if files are skipped". Lekensteyn added a comment. Changes: - Return 1 (instead of 0) if none of the files could be

[PATCH] D51729: [Tooling] JSONCompilationDatabasePlugin infers compile commands for missing files

Lekensteyn added a comment. In https://reviews.llvm.org/D51729#1288360, @sammccall wrote: > > I'm not entirely sure what to do here. The old behavior works great in > > cases where a complete database is available (produced by CMake). The new > > behavior might work better for clangd (?), but

[PATCH] D51729: [Tooling] JSONCompilationDatabasePlugin infers compile commands for missing files

Lekensteyn added a comment. Before this patch, missing compilation database entries resulted in "Skipping Compile command not found." which is assumed by the tests in this clang-query patch: https://reviews.llvm.org/D54109 After this patch, a command is inferred, but this is not always

[PATCH] D54109: [clang-query] continue even if files are skipped

Lekensteyn added inline comments. Comment at: test/clang-query/database-missing-entry.c:9 +// CHECK: deliberate parsing error +// CHECK: Skipping {{.*[/\\]}}missing.c. Compile command not found. +// CHECK-NOT-EXIST: Error while processing {{.*[/\\]}}missing.c.

[PATCH] D54109: [clang-query] continue even if files are skipped

Lekensteyn created this revision. Lekensteyn added reviewers: cfe-commits, pcc. Like clang-check, continue even if some source files were not found in the compilation database. This makes it possible to do search for matching sources and query files that exist in the compilation db:

[PATCH] D49466: Initial implementation of -fmacro-prefix-map and -ffile-prefix-map

Lekensteyn added inline comments. Comment at: lib/Lex/PPMacroExpansion.cpp:1460 + for (const auto : MacroPrefixMap) +if (Path.startswith(Entry.first)) + return (Twine(Entry.second) + Path.substr(Entry.first.size())).str(); joerg wrote: > Lekensteyn

[PATCH] D49466: Initial implementation of -fmacro-prefix-map and -ffile-prefix-map

Lekensteyn requested changes to this revision. Lekensteyn added a comment. This revision now requires changes to proceed. The functionality looks correct to me, but could you include some tests in test/Driver/ and test/Preprocessor/ just to be sure? test/Driver/debug-prefix-map.c and

[PATCH] D47817: [sanitizer_common] Fix using libtirpc on Linux

Lekensteyn added a comment. In https://reviews.llvm.org/D47817#1155717, @mgorny wrote: > > This would be the first user of pkg-config here. I am not sure if this > > would be the best fix. Usually you cannot (easily) recompile libc and > > override it, but for external libs such as libtirpc

[PATCH] D47817: [sanitizer_common] Fix using libtirpc on Linux

Lekensteyn added a comment. Hi, thank you for the patch. First a disclaimer, I am not familiar with this RPC API at all. This would be the first user of pkg-config here. I am not sure if this would be the best fix. Usually you cannot (easily) recompile libc and override it, but for external

[PATCH] D46522: [clang] cmake: resolve symlinks in ClangConfig.cmake

Lekensteyn added a comment. In https://reviews.llvm.org/D46522#1096847, @kimgr wrote: > I'm interested in this, I've tried for a while to fix the Debian packaging > but I'm completely new to the packaging toolchain, so I'm making slow headway. The Debian clang-5.0 1:5.0.2-2 package already

[PATCH] D46522: [clang] cmake: resolve symlinks in ClangConfig.cmake

Lekensteyn abandoned this revision. Lekensteyn added a comment. Per discussion in https://reviews.llvm.org/D46521, resolving symlinks might introduce issues that are are worse than the issue that was solved here. It seems better to carry this patch downstream (in Debian) since the problem only

[PATCH] D46522: [clang] cmake: resolve symlinks in ClangConfig.cmake

Lekensteyn added reviewers: brad.king, gottesmm, mgorny. Lekensteyn added a comment. Hi, this patch was required to make `find_package(Clang CONFIG)` work when `/usr/lib/llvm/clang-X.Y` was a symlink and is integrated in the Debian packaging. Please have a look, thanks! One unfortunate

[PATCH] D46522: [clang] cmake: resolve symlinks in ClangConfig.cmake

Lekensteyn created this revision. Lekensteyn added a reviewer: sylvestre.ledru. Herald added subscribers: cfe-commits, mgorny. Ensure that symlinks such as /usr/lib/cmake/clang-X.Y (pointing to /usr/lib/llvm-X.Y/lib/cmake/llvm) are resolved. This ensures that CLANG_INSTALL_PREFIX ends up to be

[PATCH] D37954: Try to shorten system header paths when using -MD depfiles

Lekensteyn added a comment. (FWIW, the suggestion to use `FileManager:getCanonicalName` did not work because I have no DirectoryEntry. And `-no-canonical-prefixes` it used very early and stripped from normal options, it seems used for a different purpose. Given the opposition, I think that

[PATCH] D37954: Try to shorten system header paths when using -MD depfiles

Lekensteyn added a comment. In https://reviews.llvm.org/D37954#901878, @rsmith wrote: > In https://reviews.llvm.org/D37954#884029, @Lekensteyn wrote: > > > Any objection for merging these patches? I rebased today (no changes > > needed) and it still passes clang-tests. > > > This is not the way

[PATCH] D37954: Try to shorten system header paths when using -MD depfiles

This revision was automatically updated to reflect the committed changes. Closed by commit rL316193: Try to shorten system header paths when using -MD depfiles (authored by Lekensteyn). Changed prior to commit: https://reviews.llvm.org/D37954?vs=115946=119626#toc Repository: rL LLVM

[PATCH] D37954: Try to shorten system header paths when using -MD depfiles

Lekensteyn added a comment. ping? I'll push it next week if there is no new feedback. https://reviews.llvm.org/D37954 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D37954: Try to shorten system header paths when using -MD depfiles

Lekensteyn added a comment. Any objection for merging these patches? I rebased today (no changes needed) and it still passes clang-tests. https://reviews.llvm.org/D37954 ___ cfe-commits mailing list cfe-commits@lists.llvm.org

[PATCH] D37954: Try to shorten system header paths when using -MD depfiles

Lekensteyn updated this revision to Diff 115946. Lekensteyn retitled this revision from "Expand absolute system header paths when using -MD depfiles" to "Try to shorten system header paths when using -MD depfiles". Lekensteyn edited the summary of this revision. Lekensteyn added a comment.

[PATCH] D37954: Expand absolute system header paths when using -MD depfiles

Lekensteyn added a comment. In https://reviews.llvm.org/D37954#873384, @joerg wrote: > ninja is not the only consumer of this. For human inspection, it can be quite > surprising to see symlinks resolved, i.e. /usr/include/machine on NetBSD. No problem, NetBSD disables this option by default:

[PATCH] D37954: Expand absolute system header paths when using -MD depfiles

Lekensteyn added a comment. In https://reviews.llvm.org/D37954#873373, @joerg wrote: > Resolving the path doesn't necessary shorten the string at all, in many cases > it will be longer. The description was based on the GCC manual page (" When preprocessing, do not shorten system header paths

[PATCH] D37954: Expand absolute system header paths when using -MD depfiles

Lekensteyn added a comment. I tried to contact Simon (the author of the GCC) patch with a question about the -fno-canonical-system-headers, but his Google address is bouncing. GCC has long survived with doing this by default, I wonder if this option could just me omitted, enabling the feature

[PATCH] D37954: Expand absolute system header paths when using -MD depfiles

Lekensteyn created this revision. Herald added a subscriber: klimek. GCC defaults to expanding the dependencies in depfiles, resolving components like ".." and symlinks. Mimic this feature to ensure that the Ninja build tool detects the correct dependencies when a symlink changes directory

[PATCH] D33094: [ASTMatchers] Add clang-query support for equals matcher

This revision was automatically updated to reflect the committed changes. Closed by commit rL305022: [ASTMatchers] Add clang-query support for equals matcher (authored by Lekensteyn). Changed prior to commit: https://reviews.llvm.org/D33094?vs=101817=101967#toc Repository: rL LLVM

[PATCH] D33093: [ASTMatchers] Add support for boolean literals

This revision was automatically updated to reflect the committed changes. Closed by commit rL305020: [ASTMatchers] Add support for boolean literals (authored by Lekensteyn). Changed prior to commit: https://reviews.llvm.org/D33093?vs=98781=101966#toc Repository: rL LLVM

[PATCH] D33135: [ASTMatchers] Add support for floatLiterals

This revision was automatically updated to reflect the committed changes. Closed by commit rL305021: [ASTMatchers] Add support for floatLiterals (authored by Lekensteyn). Changed prior to commit: https://reviews.llvm.org/D33135?vs=101816=101968#toc Repository: rL LLVM

[PATCH] D33094: [ASTMatchers] Add clang-query support for equals matcher

Lekensteyn added inline comments. Comment at: unittests/ASTMatchers/Dynamic/RegistryTest.cpp:545 + .getTypedMatcher(); + EXPECT_TRUE(matches("int x = 'x';", CharStmt)); + EXPECT_FALSE(matches("int x = 120;", CharStmt)); Lekensteyn wrote: > aaron.ballman

[PATCH] D33094: [ASTMatchers] Add clang-query support for equals matcher

Lekensteyn updated this revision to Diff 101817. Lekensteyn marked 7 inline comments as done. Lekensteyn added a comment. diff from previous patch: diff --git a/unittests/ASTMatchers/Dynamic/RegistryTest.cpp b/unittests/ASTMatchers/Dynamic/RegistryTest.cpp index 29fcdec6c1..84e31f721a

[PATCH] D33135: [ASTMatchers] Add support for floatLiterals

Lekensteyn added a comment. Rebased patches on latest clang master (trunk), there were no changes in ASTMatchers. boolean literal patch was unchanged, this floating literal patch was updated to address comments. Comment at:

[PATCH] D33135: [ASTMatchers] Add support for floatLiterals

Lekensteyn updated this revision to Diff 101816. Lekensteyn marked 8 inline comments as done. Lekensteyn added a comment. diff from previous version: diff --git a/include/clang/ASTMatchers/Dynamic/Parser.h b/include/clang/ASTMatchers/Dynamic/Parser.h index 0d0c2ba540..5ec4a9abf4 100644

[PATCH] D33135: [ASTMatchers] Add support for floatLiterals

Lekensteyn added inline comments. Comment at: include/clang/ASTMatchers/Dynamic/VariantValue.h:335 unsigned Unsigned; +double Double; bool Boolean; aaron.ballman wrote: > Lekensteyn wrote: > > aaron.ballman wrote: > > > This may or may not be a

[PATCH] D33094: [ASTMatchers] Add clang-query support for equals matcher

Lekensteyn added inline comments. Comment at: include/clang/ASTMatchers/ASTMatchers.h:3846 + CXXBoolLiteralExpr, + IntegerLiteral), +

[PATCH] D33094: [ASTMatchers] Add clang-query support for equals matcher

Lekensteyn updated this revision to Diff 98917. Lekensteyn marked 9 inline comments as done. Lekensteyn retitled this revision from "[ASTMatchers] Add equals support for integer and boolean literals" to "[ASTMatchers] Add clang-query support for equals matcher". Lekensteyn edited the summary of

[PATCH] D33135: [ASTMatchers] Add support for floatLiterals

Lekensteyn added a comment. By the way, I think that `long double` is less common than long unsigned literals, so changing unsigned to uint64_t might be something more important? Comment at: include/clang/ASTMatchers/Dynamic/Parser.h:25 ///:= true | false +///

[PATCH] D33135: [ASTMatchers] Add support for floatLiterals

Lekensteyn created this revision. Needed to support something like "floatLiteral(equals(1.0))". The parser for floating point numbers is kept simple, so instead of ".1" you have to use "0.1". https://reviews.llvm.org/D33135 Files: include/clang/ASTMatchers/Dynamic/Diagnostics.h

[PATCH] D33093: [ASTMatchers] Add support for boolean literals

Lekensteyn updated this revision to Diff 98781. Lekensteyn edited the summary of this revision. Lekensteyn added a comment. v2: Minor updates (fixed comment: `// ...` to `///

[PATCH] D33094: [ASTMatchers] Add equals support for integer and boolean literals

Lekensteyn added a comment. In https://reviews.llvm.org/D33094#752153, @aaron.ballman wrote: > Please be sure to regenerate the AST matcher documentation as well by running > clang/docs/tools/dump_ast_matchers.py Will do, thanks for the hint. Comment at:

[PATCH] D33094: [ASTMatchers] Add equals support for integer and boolean literals

Lekensteyn created this revision. This allows the clang-query tool to use matchers like "integerLiteral(equals(32))". The equals function is a template, so some special trickery is needed. https://reviews.llvm.org/D33094 Files: include/clang/ASTMatchers/ASTMatchers.h

[PATCH] D33093: [ASTMatchers] Add support for boolean literals

Lekensteyn created this revision. Recognize boolean literals for future extensions ("equals(true)"). Note that a specific VariantValue constructor is added to resolve ambiguity (like "Value = 5") between unsigned and bool. --- Passes

[PATCH] D29827: [AVR] Add -mmcu option to the driver

Lekensteyn updated this revision to Diff 95707. Lekensteyn added a comment. v2: rebase on commit ad25f8b712f1ef99020fcb7b5e31dd95b39c6112 (trunk@300661) Based on the context, the change from lib/Driver/Tools.cpp -> lib/Driver/ToolChains/CommonArgs.cpp seems most appropriate (Gnu.cpp seems to

[PATCH] D29817: [AVR] Fix __AVR_xxx macro definitions

Lekensteyn added a comment. In https://reviews.llvm.org/D29817#674306, @dylanmckay wrote: > Do you have commit access @Lekensteyn? No I do not, please push it for me :-) https://reviews.llvm.org/D29817 ___ cfe-commits mailing list

[PATCH] D29827: [AVR] Add -mmcu option to the driver

Lekensteyn added inline comments. Comment at: include/clang/Driver/Options.td:1613 def mcpu_EQ : Joined<["-"], "mcpu=">, Group; +def mmcu_EQ : Joined<["-"], "mmcu=">, Group; def mdynamic_no_pic : Joined<["-"], "mdynamic-no-pic">, Group; dylanmckay wrote: >

[PATCH] D29817: [AVR] Fix __AVR_xxx macro definitions

Lekensteyn updated this revision to Diff 88025. Lekensteyn marked an inline comment as done. Lekensteyn added a comment. Good catch! I just checked again and confirmed that there is only one line that had this issue (there are no other occurrences of `___"`). https://reviews.llvm.org/D29817

[PATCH] D29827: [AVR] Add -mmcu option to the driver

Lekensteyn added inline comments. Comment at: include/clang/Driver/Options.td:1613 def mcpu_EQ : Joined<["-"], "mcpu=">, Group; +def mmcu_EQ : Joined<["-"], "mmcu=">, Group; def mdynamic_no_pic : Joined<["-"], "mdynamic-no-pic">, Group; jroelofs wrote: > Would

[PATCH] D29827: [AVR] Add -mmcu option to the driver

Lekensteyn created this revision. Add the AVR-specific -mmcu option for compatibility with GCC (GCC does not use -mcpu nor -march for AVR). This option is needed to inform the frontend to define some macros (for example) and the inform the assembler of the allowed features, so add a test to check

[PATCH] D29817: [AVR] Fix __AVR_xxx macro definitions

Lekensteyn updated this revision to Diff 87986. Lekensteyn added a comment. Oops, missed the avrtiny patch. After updating that, it now actually passes the clang-test tests. https://reviews.llvm.org/D29817 Files: lib/Basic/Targets.cpp test/CodeGen/avr/target-cpu-defines/atmega328p.c

[PATCH] D29817: [AVR} Fix __AVR_xxx macro definitions

Lekensteyn added a comment. Without this patch, compilation of a program using avr/io.h fails. Tested with: clang --target=avr -Xclang -target-cpu -Xclang atmega328p -I/usr/avr/include -Os led.c -c -o /dev/null Btw, it seems that avr-libc 2.0.0 also uses `__AVR_ARCH__`, `__AVR_XMEGA__` and

[PATCH] D29817: [AVR} Fix __AVR_xxx macro definitions

Lekensteyn created this revision. The -mmcu option for GCC sets macros like __AVR_ATmega328P__ (with the trailing underscores), be sure to include these underscores for Clangs -mcpu option. See "AVR Built-in Macros" in https://gcc.gnu.org/onlinedocs/gcc/AVR-Options.html