[all-commits] [llvm/llvm-project] aebee6: [clang] Do not clear FP pragma stack when instanti...
Nikita Popov via All-commits
all-commits at lists.llvm.org
Tue Nov 14 00:28:40 PST 2023
Branch: refs/heads/release/17.x
Home: https://github.com/llvm/llvm-project
Commit: aebee698ef16a4346c669e9f940c6dbf2247b7ef
https://github.com/llvm/llvm-project/commit/aebee698ef16a4346c669e9f940c6dbf2247b7ef
Author: Serge Pavlov <sepavloff at gmail.com>
Date: 2023-11-14 (Tue, 14 Nov 2023)
Changed paths:
M clang/include/clang/Sema/Sema.h
A clang/test/Sema/PR69717.cpp
Log Message:
-----------
[clang] Do not clear FP pragma stack when instantiating functions (#70646)
When instantiation function, a call to Sema::resetFPOption was used to
set the FP options associated with AST node. However this function also
cleared FP pragma stack, and it is incorrect. Template instantiation
takes place on AST representation and semantic information like the FP
pragma stack should not affect it. This was a reason for miscompilation
in some cases.
To make the Sema interface more consistent, now `resetFPOptions` does
not clear FP pragma stack anymore. It is cleared in
`FpPragmaStackSaveRAII`, which is used in parsing only.
This change must fix https://github.com/llvm/llvm-project/issues/69717
(Problems with float_control pragma stack in Clang 17.x).
(cherry picked from commit f6f625f4c6c3cbeb8cf6b889cdafc848dd4cb117)
Commit: e666be92b44b65af7e8cee4402a5de4e8f3622f6
https://github.com/llvm/llvm-project/commit/e666be92b44b65af7e8cee4402a5de4e8f3622f6
Author: Serge Pavlov <sepavloff at gmail.com>
Date: 2023-11-14 (Tue, 14 Nov 2023)
Changed paths:
M clang/test/Sema/PR69717.cpp
Log Message:
-----------
[clang] Run test on x86 only
The test Sema/PR69717.cpp fails on platforms that do not support
pragma float_control. So run this test on x86 only.
(cherry picked from commit 93ae26331592f41bf2b1d10b048743d80c468385)
Commit: 42f8800b720fa4948155fed029200ba6aad01655
https://github.com/llvm/llvm-project/commit/42f8800b720fa4948155fed029200ba6aad01655
Author: antoine moynault <antoine.moynault at linaro.org>
Date: 2023-11-14 (Tue, 14 Nov 2023)
Changed paths:
M clang/test/Sema/PR69717.cpp
Log Message:
-----------
[clang] fix test PR69717.cpp (#72134)
Test still fail on ARM machine (no float_control support)
(cherry picked from commit 5fdb70be7b0a1340a7ebdeb94ab073e466fc4aa6)
Commit: 0a1274224ef8928507b8e50c19ea25e62a7a3bf3
https://github.com/llvm/llvm-project/commit/0a1274224ef8928507b8e50c19ea25e62a7a3bf3
Author: Jan Kokemüller <jan.kokemueller at gmail.com>
Date: 2023-11-14 (Tue, 14 Nov 2023)
Changed paths:
M libcxx/include/__expected/expected.h
M libcxx/test/std/utilities/expected/expected.expected/assign/emplace.intializer_list.pass.cpp
M libcxx/test/std/utilities/expected/expected.expected/assign/emplace.pass.cpp
M libcxx/test/std/utilities/expected/expected.expected/ctor/ctor.convert.copy.pass.cpp
M libcxx/test/std/utilities/expected/expected.expected/ctor/ctor.convert.move.pass.cpp
M libcxx/test/std/utilities/expected/expected.expected/ctor/ctor.copy.pass.cpp
M libcxx/test/std/utilities/expected/expected.expected/ctor/ctor.default.pass.cpp
M libcxx/test/std/utilities/expected/expected.expected/ctor/ctor.inplace.pass.cpp
M libcxx/test/std/utilities/expected/expected.expected/ctor/ctor.inplace_init_list.pass.cpp
M libcxx/test/std/utilities/expected/expected.expected/ctor/ctor.move.pass.cpp
M libcxx/test/std/utilities/expected/expected.expected/ctor/ctor.u.pass.cpp
M libcxx/test/std/utilities/expected/expected.expected/ctor/ctor.unexpect.pass.cpp
M libcxx/test/std/utilities/expected/expected.expected/ctor/ctor.unexpect_init_list.pass.cpp
M libcxx/test/std/utilities/expected/expected.expected/ctor/ctor.unexpected.copy.pass.cpp
M libcxx/test/std/utilities/expected/expected.expected/ctor/ctor.unexpected.move.pass.cpp
M libcxx/test/std/utilities/expected/expected.expected/observers/has_value.pass.cpp
M libcxx/test/std/utilities/expected/expected.expected/swap/free.swap.pass.cpp
M libcxx/test/std/utilities/expected/expected.expected/swap/member.swap.pass.cpp
M libcxx/test/std/utilities/expected/expected.void/ctor/ctor.convert.copy.pass.cpp
M libcxx/test/std/utilities/expected/expected.void/ctor/ctor.convert.move.pass.cpp
M libcxx/test/std/utilities/expected/expected.void/ctor/ctor.copy.pass.cpp
M libcxx/test/std/utilities/expected/expected.void/ctor/ctor.move.pass.cpp
M libcxx/test/std/utilities/expected/expected.void/ctor/ctor.unexpect.pass.cpp
M libcxx/test/std/utilities/expected/expected.void/ctor/ctor.unexpect_init_list.pass.cpp
M libcxx/test/std/utilities/expected/expected.void/ctor/ctor.unexpected.copy.pass.cpp
M libcxx/test/std/utilities/expected/expected.void/ctor/ctor.unexpected.move.pass.cpp
M libcxx/test/std/utilities/expected/expected.void/observers/has_value.pass.cpp
M libcxx/test/std/utilities/expected/expected.void/swap/free.swap.pass.cpp
M libcxx/test/std/utilities/expected/expected.void/swap/member.swap.pass.cpp
M libcxx/test/std/utilities/expected/types.h
Log Message:
-----------
[libc++] Fix UB in <expected> related to "has value" flag (#68552) (#68733)
The calls to std::construct_at might overwrite the previously set
__has_value_ flag in the case where the flag is overlapping with
the actual value or error being stored (since we use [[no_unique_address]]).
To fix this issue, this patch ensures that we initialize the
__has_value_ flag after we call std::construct_at.
Fixes #68552
(cherry picked from commit 134c91595568ea1335b22e559f20c1a488ea270e)
Commit: 12c6ee8fd2046c85ae9693105288fcd749b90733
https://github.com/llvm/llvm-project/commit/12c6ee8fd2046c85ae9693105288fcd749b90733
Author: Nikita Popov <npopov at redhat.com>
Date: 2023-11-14 (Tue, 14 Nov 2023)
Changed paths:
M llvm/lib/Transforms/IPO/GlobalOpt.cpp
Log Message:
-----------
[GlobalOpt] Cache whether CC is changeable (#71381)
The hasAddressTaken() call in hasOnlyColdCalls() has quadratic
complexity if there are many cold calls to a function: We're going to
visit each call of the function, and then for each of them iterate all
the users of the function.
We've recently encountered a case where GlobalOpt spends more than an
hour in these hasAddressTaken() checks when full LTO is used.
Avoid this by moving the hasAddressTaken() check into hasChangeableCC()
and caching its result, so it is only computed once per function.
(cherry picked from commit e360a16fee2dc3cb632ace556fb715832f488a90)
Commit: 98bfdac5ce82d1679f8af9a57501471812ab68d7
https://github.com/llvm/llvm-project/commit/98bfdac5ce82d1679f8af9a57501471812ab68d7
Author: Nikita Popov <npopov at redhat.com>
Date: 2023-11-14 (Tue, 14 Nov 2023)
Changed paths:
M llvm/lib/CodeGen/BranchFolding.cpp
Log Message:
-----------
[BranchFolding] Remove dubious assert from operator< (#71639)
`MergePotentialElts::operator<` asserts that the two elements being
compared are not equal. However, sorting functions are allowed to invoke
the comparison function with equal arguments (though they usually don't
for efficiency reasons).
There is an existing special-case that disables the assert if
_GLIBCXX_DEBUG is used, which may invoke the comparator with equal args
to verify strict weak ordering. I believe libc++ also has strict weak
ordering checks under some options nowadays.
Recently, #71312 was reported, where a change to glibc's qsort_r
implementation can also result in comparison between equal elements.
>From what I understood, this is an inefficiency that will be fixed on
the glibc side as well, but I think at this point we should just remove
this assertion.
Fixes https://github.com/llvm/llvm-project/issues/71312.
(cherry picked from commit 74a76a288562c486f377121855ef7db0386e0e43)
Compare: https://github.com/llvm/llvm-project/compare/529aa6eadb27...98bfdac5ce82
More information about the All-commits
mailing list