@@ -65,12 +65,24 @@ void check_fseek(void) {
fclose(fp);
}
+void check_fseeko(void) {
balazske wrote:
If we have these null pointer tests for all functions, `vfprintf` and `vfscanf`
could be added too.
https://github.com/llvm/llvm-project/pull/82476
_
https://github.com/balazske commented:
I have only small observations.
https://github.com/llvm/llvm-project/pull/82476
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1862,6 +1862,17 @@ class StringLiteral final
llvm_unreachable("Unsupported character width!");
}
+ // Get code unit but preserve sign info.
+ int64_t getCodeUnitS(size_t I, uint64_t BitWidth) const {
Fznamznon wrote:
FYI
https://github.com/llvm/l
@@ -685,9 +685,22 @@ class TransferVisitor : public
ConstStmtVisitor {
// `S->inits()` contains all the initializer expressions, including the
// ones for direct base classes.
-auto Inits = S->inits();
+ArrayRef Inits = S->inits();
size_t InitIdx = 0;
+
@@ -0,0 +1,265 @@
+Pointer Authentication
+==
+
+.. contents::
+ :local:
+
+Introduction
+
+
+Pointer authentication is a technology which offers strong probabilistic
protection against exploiting a broad class of memory bugs to take control of
@@ -0,0 +1,265 @@
+Pointer Authentication
+==
+
+.. contents::
+ :local:
+
+Introduction
+
+
+Pointer authentication is a technology which offers strong probabilistic
protection against exploiting a broad class of memory bugs to take control of
@@ -0,0 +1,265 @@
+Pointer Authentication
+==
+
+.. contents::
+ :local:
+
+Introduction
+
+
+Pointer authentication is a technology which offers strong probabilistic
protection against exploiting a broad class of memory bugs to take control of
ahmedbougacha wrote:
Updated, tried to address all the comments; let me know if I missed something!
https://github.com/llvm/llvm-project/pull/65996
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo
nickdesaulniers wrote:
Looks like the linter is upset with pre-existing changes. ok2land. Are you
able to merge this @overmighty or do you need us to?
https://github.com/llvm/llvm-project/pull/82359
___
cfe-commits mailing list
cfe-commits@lists.llvm
nikic wrote:
FYI this change adds some overhead (about 0.2% for O0) builds
(http://llvm-compile-time-tracker.com/compare.php?from=046682ef88a254443e8620bfd48b35bfa0a83809&to=440b1743ee0c8bfb7bf0c4b503bde5ab9af88dc0&stat=instructions:u).
Is it possible to avoid it for people not using API notes?
shahidiqbal13 wrote:
Hi @cor3ntin to review the updated fix, will format it later
https://github.com/llvm/llvm-project/pull/80976
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
vzakhari wrote:
I do not think the Windows CI failure has anything to do with my changes. I am
going to merge this.
https://github.com/llvm/llvm-project/pull/82832
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin
hokein wrote:
> Sorry for missing this!
>
> Would be nice to have a testcase but I see it's hard to get into the crashing
> state (maybe even not possible via clang). Seems worthwhile to be robust to
> such conditions and getDefaultArgRange appears less fragile.
This fix was needed for the in
felipepiovezan wrote:
> > This seems akin to running clang-format on the entire project, which last
> > time we talked about still faced opposition
>
> My impression (I admit I haven't reviewed the whole thread lately) is that
> the opposition has mostly to do with how clang-format mangles som
@@ -10598,10 +10598,36 @@ QualType
Sema::DeduceTemplateSpecializationFromInitializer(
if (TemplateName.isDependent())
return SubstAutoTypeDependent(TSInfo->getType());
- // We can only perform deduction for class templates.
+ // We can only perform deduction for class
https://github.com/erichkeane commented:
We probably need an entry in ReleaseNotes.rst here as well.
https://github.com/llvm/llvm-project/pull/77890
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listin
@@ -10598,10 +10598,36 @@ QualType
Sema::DeduceTemplateSpecializationFromInitializer(
if (TemplateName.isDependent())
return SubstAutoTypeDependent(TSInfo->getType());
- // We can only perform deduction for class templates.
+ // We can only perform deduction for class
@@ -10598,10 +10598,36 @@ QualType
Sema::DeduceTemplateSpecializationFromInitializer(
if (TemplateName.isDependent())
return SubstAutoTypeDependent(TSInfo->getType());
- // We can only perform deduction for class templates.
+ // We can only perform deduction for class
barcharcraz wrote:
> Is it feasible to create a migration path from the static runtime to the
> dynamic runtime? As written, this requires users to update their ASan builds
> at the same time that they take this update. Is it possible to leave the
> static runtime behind, create a migration pa
https://github.com/erichkeane commented:
Clang changes look fine, but I don't have the expertise to review the LLVM
changes, so whoever reviews LLVM feel free to 'approve' when you're ready.
https://github.com/llvm/llvm-project/pull/79035
___
cfe-comm
egorzhdan wrote:
Oh, thanks @nikic for that data point. Let me try to avoid the overhead, I'll
put up a patch tomorrow morning.
https://github.com/llvm/llvm-project/pull/78445
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.
dwblaikie wrote:
Commit without precommit review is fine, especially from a code owner - if you
only wanted the PR for automated precommit checking, you can add the
`skip-precommit-approval` to indicate that the PR isn't intended for precommit
review. But, yeah, otherwise it's good that if som
urnathan wrote:
> Yeah, LLVM supports changing subtarget options on a per-function basis. We
> would presumably make the query based on the global setting.
>
> Anyway, getting this information from LLVM doesn't seem tractable in the
> short-to-medium term; it's just unfortunate.
Thinking furt
@@ -0,0 +1,178 @@
+//=== PolymorphicPtrArithmetic.cpp --*- C++
-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Ap
@@ -0,0 +1,178 @@
+//=== PolymorphicPtrArithmetic.cpp --*- C++
-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Ap
@@ -0,0 +1,178 @@
+//=== PolymorphicPtrArithmetic.cpp --*- C++
-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Ap
jwanggit86 wrote:
@arsenm Any comments on the LLVM side?
https://github.com/llvm/llvm-project/pull/79035
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -78,6 +78,13 @@ class CodeGenOptions : public CodeGenOptionsBase {
SRCK_InRegs// Small structs in registers (-freg-struct-return).
};
+ enum ComplexArgumentConventionKind {
+CMPLX_Default,
+CMPLX_OnStack,
diggerlin wrote:
it looks you de
https://github.com/AMS21 created https://github.com/llvm/llvm-project/pull/83055
A definition like this:
```cpp
template
void f(T &&) = delete;
```
would previously generate the the following output:
```sh
:2:12: warning: forwarding reference parameter '' is never forwarded
inside the functi
llvmbot wrote:
@llvm/pr-subscribers-clang-tools-extra
Author: None (AMS21)
Changes
A definition like this:
```cpp
template
void f(T &&) = delete;
```
would previously generate the the following output:
```sh
:2:12: warning: forwarding reference parameter '' is never
overmighty wrote:
@nickdesaulniers I need someone to merge this for me, I don't have write/push
access. Thanks.
https://github.com/llvm/llvm-project/pull/82359
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mail
https://github.com/egorzhdan created
https://github.com/llvm/llvm-project/pull/83057
This fixes a few breakages introduced during upstreaming – please see each
commit for details.
>From dae96657bee753a96bc41e8cde3ca81e082d82cb Mon Sep 17 00:00:00 2001
From: Egor Zhdan
Date: Mon, 26 Feb 2024 2
llvmbot wrote:
@llvm/pr-subscribers-clang
Author: Egor Zhdan (egorzhdan)
Changes
This fixes a few breakages introduced during upstreaming – please see each
commit for details.
---
Full diff: https://github.com/llvm/llvm-project/pull/83057.diff
2 Files Affected:
- (modified) clang/lib/
llvmbot wrote:
@llvm/pr-subscribers-clang
Author: Timothy Herchen (anematode)
Changes
Will resolve https://github.com/llvm/llvm-project/issues/66059 . GCC's behavior
in the case of inlining
(https://gcc.gnu.org/onlinedocs/gcc/Return-Address.html) is that a caller's
return/frame address
