[all-commits] [llvm/llvm-project] 6a562b: [Tooling/Inclusion] Add std::range symbols in the ...
Vassil Vassilev via All-commits
all-commits at lists.llvm.org
Sun Sep 3 23:30:41 PDT 2023
Branch: refs/heads/release/17.x
Home: https://github.com/llvm/llvm-project
Commit: 6a562bbd51c9ad1ff522d19a0b247595c1f85184
https://github.com/llvm/llvm-project/commit/6a562bbd51c9ad1ff522d19a0b247595c1f85184
Author: Haojian Wu <hokein.wu at gmail.com>
Date: 2023-09-04 (Mon, 04 Sep 2023)
Changed paths:
M clang/lib/Tooling/Inclusions/Stdlib/StdSymbolMap.inc
M clang/tools/include-mapping/gen_std.py
Log Message:
-----------
[Tooling/Inclusion] Add std::range symbols in the mapping.
Fixes https://github.com/llvm/llvm-project/issues/64191
Differential Revision: https://reviews.llvm.org/D156648
(cherry picked from commit 171868dc2cd60c6e3eaeb3861b18ba0e22461291)
Commit: 466677b126855c79a05a1ebc111eea48053ad4ef
https://github.com/llvm/llvm-project/commit/466677b126855c79a05a1ebc111eea48053ad4ef
Author: Martin Storsjö <martin at martin.st>
Date: 2023-09-04 (Mon, 04 Sep 2023)
Changed paths:
M llvm/test/tools/llvm-rc/windres-preproc.test
M llvm/tools/llvm-rc/WindresOpts.td
M llvm/tools/llvm-rc/llvm-rc.cpp
Log Message:
-----------
[llvm-windres] Implement the windres flag --use-temp-file
Whether a temp file or a pipe is used for preprocessing is an
internal detail, this flag has a notable effect on the preprocessing
in GNU windres. Without this flag, GNU windres passes command
arguments as-is to popen(), which means they get evaluated by a
shell without being re-escaped for this case. To mimic this,
llvm-windres has manually tried to unescape arguments.
When GNU windres is given the --use-temp-file flag, it uses a
different API for invoking the preprocessor, and this API takes care
of preserving special characters in the command line arguments.
For users of GNU windres, this means that by using --use-temp-file,
they don't need to do the (quite terrible) double escaping of
quotes/spaces etc.
The xz project uses the --use-temp-file flag when invoking
GNU windres, see
https://github.com/tukaani-project/xz/commit/6b117d3b1fe91eb26d533ab16a2e552f84148d47.
However as llvm-windres didn't implement this flag and just
assumed the GNU windres popen() behaviour, they had to use a
different codepath for llvm-windres.
That separate codepath for llvm-windres broke later when llvm-windres
got slightly more accurate unescaping of lone quotes in
0f4c6b120f21d582ab7c5c4f2b2a475086c34938 /
https://reviews.llvm.org/D146848 (fixing a discrepancy to GNU
windres as found in https://github.com/llvm/llvm-project/issues/57334),
and this was reported in
https://github.com/mstorsjo/llvm-mingw/issues/363.
Not touching the implementation of the --preprocessor option
with respect to the --use-temp-file flag; that option is doubly
tricky as GNU windres changed its behaviour in a backwards incompatible
way recently (and llvm-windres currently matches the old behaviour).
(See
https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=21c33bcbe36377abf01614fb1b9be439a3b6de20,
https://sourceware.org/bugzilla/show_bug.cgi?id=27594 and
https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=5edb8e3f5ad8d74a83fc0df7f6e4514eed0aa77f;hp=3abbafc2aacc6706fea3e3e326e2f08d107c3672
for the behaviour change.)
Differential Revision: https://reviews.llvm.org/D159223
(cherry picked from commit 2bcc0fdc58a220cb9921b47ec8a32c85f2511a47)
Commit: ca372df48a05534d42130e6ecb4f6b275e003a08
https://github.com/llvm/llvm-project/commit/ca372df48a05534d42130e6ecb4f6b275e003a08
Author: hstk30 <htsk30 at gmail.com>
Date: 2023-09-04 (Mon, 04 Sep 2023)
Changed paths:
M llvm/lib/Target/AArch64/AArch64ISelLowering.cpp
A llvm/test/CodeGen/AArch64/arm64-neon-st-lane-aa.ll
A llvm/test/CodeGen/AArch64/multi-vector-load-size.ll
M llvm/test/CodeGen/AArch64/multi-vector-store-size.ll
Log Message:
-----------
[AArch64] Fix arm neon vstx lane memVT size
StN lane memory size set too big lead to alias analysis goes wrong.
Fixes https://github.com/llvm/llvm-project/issues/64696
Differential Revision: https://reviews.llvm.org/D158611
(cherry picked from commit db8f6c009e5a17d304be7404e50eb20b2dd0c75b)
Commit: e04acab63c2682c690790111d688419158f15978
https://github.com/llvm/llvm-project/commit/e04acab63c2682c690790111d688419158f15978
Author: Fangrui Song <i at maskray.me>
Date: 2023-09-04 (Mon, 04 Sep 2023)
Changed paths:
M clang/lib/Driver/Driver.cpp
M clang/lib/Driver/ToolChains/AIX.cpp
M clang/lib/Driver/ToolChains/Arch/X86.cpp
M clang/lib/Driver/ToolChains/Arch/X86.h
M clang/lib/Driver/ToolChains/CommonArgs.cpp
A clang/test/Driver/target-specific.s
M clang/test/Driver/x86-mfpmath.c
Log Message:
-----------
[Driver] Report warnings for unclaimed TargetSpecific options for assembler input
This patch amends D151590 to not error for unlaimed TargetSpecific
options for `-x assembler` input files. This input type causes Driver to
construct tools::ClangAs (-fintegrated-as) or other assemblers (e.g.
tools::gnutools::Assembler) Their ConstructJobs methods, unlike
Clang::ConstructJobs, claim very few options. If an option is unclaimed,
it either leads to a -Wunused-command-line-argument warning or an error
(if `TargetSpecific` is set):
```
% clang '-###' --target=aarch64 -mbranch-protection=bti -c a.s
clang: error: unsupported option '-mbranch-protection=' for target 'aarch64'
```
It seems that downgrading the diagnostic to warning is most useful as
many users use CFLAGS even for `.s` files:
```
clang --target=aarch64 -mbranch-protection=bti -S a.c
clang --target=aarch64 -mbranch-protection=bti -c a.s
```
I decide not to suppress the warning so that
-Wunused-command-line-argument lovers still get a warning, and help
projects use proper ASFLAGS/CFLAGS/etc.
Note: `-mbranch-protection=bti a.S` currently has no warning as `-x assembler-with-cpp`
instructs clangDriver to select tools::Clang and claim most options.
Revert D159010 to demonstrate that we emit a warning for -mfpmath= for
`-x assembler` input.
Modify my AIX cleanup cd18efb61d759405956dbd30e4b5f2720d8e1783 to
add an err_drv_unsupported_opt_for_target.
Reviewed By: thesamesam
Differential Revision: https://reviews.llvm.org/D159173
(cherry picked from commit e9d454d1c195958645fb0948f8b97262e7f8b33a)
Commit: ecea6d6828d6591c80285ffb5c2be1312c201549
https://github.com/llvm/llvm-project/commit/ecea6d6828d6591c80285ffb5c2be1312c201549
Author: Vassil Vassilev <v.g.vassilev at gmail.com>
Date: 2023-09-04 (Mon, 04 Sep 2023)
Changed paths:
M clang/lib/CodeGen/CodeGenModule.cpp
Log Message:
-----------
[CodeGen] First check the kind and then the llvm::Function properties.
This patch fixes valgrind reports from downstream consumers about conditional
jump over uninitialised memory.
The original report:
```[ RUN ] ScopeReflectionTest.IsComplete
==987150== Conditional jump or move depends on uninitialised value(s)
==987150== at 0x1E1128F: clang::CodeGen::CodeGenModule::SetLLVMFunctionAttributesForDefinition(clang::Decl const*, llvm::Function*) (CodeGenModule.cpp:2391)
==987150== by 0x1E4F181: clang::CodeGen::CodeGenModule::EmitGlobalFunctionDefinition(clang::GlobalDecl, llvm::GlobalValue*) (CodeGenModule.cpp:5669)
==987150== by 0x1E4A194: clang::CodeGen::CodeGenModule::EmitGlobalDefinition(clang::GlobalDecl, llvm::GlobalValue*) (CodeGenModule.cpp:3909)
==987150== by 0x1E4A752: clang::CodeGen::CodeGenModule::EmitGlobal(clang::GlobalDecl) (CodeGenModule.cpp:3649)
==987150== by 0x1E532F5: clang::CodeGen::CodeGenModule::EmitTopLevelDecl(clang::Decl*) [clone .part.0] (CodeGenModule.cpp:6563)
==987150== by 0x1B0BEDD: (anonymous namespace)::CodeGeneratorImpl::HandleTopLevelDecl(clang::DeclGroupRef) (ModuleBuilder.cpp:190)
==987150== by 0x1AEA47B: clang::BackendConsumer::HandleTopLevelDecl(clang::DeclGroupRef) (CodeGenAction.cpp:235)
==987150== by 0x101B02F: clang::IncrementalASTConsumer::HandleTopLevelDecl(clang::DeclGroupRef) (IncrementalParser.cpp:52)
==987150== by 0x101ED93: clang::IncrementalParser::ParseOrWrapTopLevelDecl() (IncrementalParser.cpp:276)
==987150== by 0x101FBBC: clang::IncrementalParser::Parse(llvm::StringRef) (IncrementalParser.cpp:342)
==987150== by 0x100E104: clang::Interpreter::Parse(llvm::StringRef) (Interpreter.cpp:360)
==987150== by 0xE734C0: Cpp::Interpreter::Parse(llvm::StringRef) (CppInterOpInterpreter.h:172)
==987150== Uninitialised value was created by a heap allocation
==987150== at 0x844BE63: operator new(unsigned long) (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==987150== by 0x1B0C882: StartModule (ModuleBuilder.cpp:139)
==987150== by 0x1B0C882: clang::CodeGenerator::StartModule(llvm::StringRef, llvm::LLVMContext&) (ModuleBuilder.cpp:360)
==987150== by 0x101C4AF: clang::IncrementalParser::GenModule() (IncrementalParser.cpp:372)
==987150== by 0x101FC0E: clang::IncrementalParser::Parse(llvm::StringRef) (IncrementalParser.cpp:362)
==987150== by 0x100E104: clang::Interpreter::Parse(llvm::StringRef) (Interpreter.cpp:360)
==987150== by 0x100E243: clang::Interpreter::create(std::unique_ptr<clang::CompilerInstance, std::default_delete<clang::CompilerInstance> >) (Interpreter.cpp:279)
==987150== by 0xF2131A: compat::createClangInterpreter(std::vector<char const*, std::allocator<char const*> >&) (Compatibility.h:123)
==987150== by 0xF22AB9: Cpp::Interpreter::Interpreter(int, char const* const*, char const*, std::vector<std::shared_ptr<clang::ModuleFileExtension>, std::allocator<std::shared_ptr<clang::ModuleFileExtension> > > const&, void*, bool) (CppInterOpInterpreter.h:146)
==987150== by 0xF1827A: CreateInterpreter (CppInterOp.cpp:2494)
==987150== by 0xECFA0E: TestUtils::GetAllTopLevelDecls(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::vector<clang::Decl*, std::allocator<clang::Decl*> >&, bool) (Utils.cpp:23)
==987150== by 0xE9CB85: ScopeReflectionTest_IsComplete_Test::TestBody() (ScopeReflectionTest.cpp:71)
==987150== by 0xF0ED0C: void testing::internal::HandleExceptionsInMethodIfSupported<testing::Test, void>(testing::Test*, void (testing::Test::*)(), char const*) (in /home/vvassilev/workspace/builds/scratch/cppyy/InterOp/build-with-clang-repl-release/unittests/CppInterOp/CppInterOpTests)
==987150==
```
Differential revision: https://reviews.llvm.org/D159339
(cherry picked from commit 92246a9be0ba47788ada9621bef58ce7819be526)
Compare: https://github.com/llvm/llvm-project/compare/a612cb0b81d8...ecea6d6828d6
More information about the All-commits
mailing list