https://github.com/bwendling updated
https://github.com/llvm/llvm-project/pull/76882
>From ca7a96a40952fe94b916dacc52f07aa90bbdb1e7 Mon Sep 17 00:00:00 2001
From: Bill Wendling
Date: Wed, 3 Jan 2024 13:22:37 -0800
Subject: [PATCH 1/6] [builtin_object_size] Use classes instead of std::pair
(NFC
https://github.com/bwendling updated
https://github.com/llvm/llvm-project/pull/76882
>From ca7a96a40952fe94b916dacc52f07aa90bbdb1e7 Mon Sep 17 00:00:00 2001
From: Bill Wendling
Date: Wed, 3 Jan 2024 13:22:37 -0800
Subject: [PATCH 1/7] [builtin_object_size] Use classes instead of std::pair
(NFC
@@ -187,80 +187,124 @@ Value *lowerObjectSizeCall(
const TargetLibraryInfo *TLI, AAResults *AA, bool MustSucceed,
SmallVectorImpl *InsertedInstructions = nullptr);
-using SizeOffsetType = std::pair;
+/// SizeOffsetType - A base template class for the object size visito
bwendling wrote:
Pinging for after-holidays visibility. :-)
https://github.com/llvm/llvm-project/pull/76348
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/bwendling updated
https://github.com/llvm/llvm-project/pull/76882
>From ca7a96a40952fe94b916dacc52f07aa90bbdb1e7 Mon Sep 17 00:00:00 2001
From: Bill Wendling
Date: Wed, 3 Jan 2024 13:22:37 -0800
Subject: [PATCH 1/9] [builtin_object_size] Use classes instead of std::pair
(NFC
@@ -187,80 +187,132 @@ Value *lowerObjectSizeCall(
const TargetLibraryInfo *TLI, AAResults *AA, bool MustSucceed,
SmallVectorImpl *InsertedInstructions = nullptr);
-using SizeOffsetType = std::pair;
+/// SizeOffsetType - A base template class for the object size visito
https://github.com/bwendling closed
https://github.com/llvm/llvm-project/pull/76882
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
bwendling wrote:
> Hi @bwendling, your change to MemoryBuiltins.h is hitting an error in the
> version of Visual Studio 2019 that we use internally to build:
>
> ```
> C:\j\w\779ddbee\p\llvm\include\llvm/Analysis/MemoryBuiltins.h(217): error
> C2990: 'llvm::SizeOffsetType': non-class template
bwendling wrote:
Actually, that fix was making all of the other builds fail:
```
/b/ml-opt-dev-x86-64-b1/llvm-project/llvm/include/llvm/Analysis/MemoryBuiltins.h:279:47:
error: specialization of ‘llvm::SizeOffsetType’ after instantiation
279 | template friend class SizeOffsetType;
|
@@ -365,6 +365,10 @@ class DefaultFilterCCC final : public
CorrectionCandidateCallback {
template
class DeclFilterCCC final : public CorrectionCandidateCallback {
public:
+ explicit DeclFilterCCC(const IdentifierInfo *Typo = nullptr,
+ NestedNameSpeci
@@ -818,6 +819,189 @@ CodeGenFunction::evaluateOrEmitBuiltinObjectSize(const
Expr *E, unsigned Type,
return ConstantInt::get(ResType, ObjectSize, /*isSigned=*/true);
}
+const FieldDecl *CodeGenFunction::FindFlexibleArrayMemberField(
+ASTContext &Ctx, const RecordDecl *R
@@ -850,6 +1034,13 @@ CodeGenFunction::emitBuiltinObjectSize(const Expr *E,
unsigned Type,
}
}
+ if (IsDynamic) {
+// Emit special code for a flexible array member with the "counted_by"
+// attribute.
+if (Value *V = emitFlexibleArrayMemberSize(E, Type, Res
@@ -944,22 +951,259 @@ static llvm::Value
*getArrayIndexingBound(CodeGenFunction &CGF,
return nullptr;
}
+namespace {
+
+/// \p StructAccessBase returns the base \p Expr of a field access. It returns
+/// either a \p DeclRefExpr, representing the base pointer to the struct,
@@ -1155,15 +1159,14 @@ const FieldDecl
*CodeGenFunction::FindCountedByField(const FieldDecl *FD) {
return nullptr;
auto GetNonAnonStructOrUnion = [](const RecordDecl *RD) {
-while (RD && !RD->getDeclName())
- if (const auto *R = dyn_cast(RD->getDeclContext()))
@@ -818,6 +819,189 @@ CodeGenFunction::evaluateOrEmitBuiltinObjectSize(const
Expr *E, unsigned Type,
return ConstantInt::get(ResType, ObjectSize, /*isSigned=*/true);
}
+const FieldDecl *CodeGenFunction::FindFlexibleArrayMemberField(
+ASTContext &Ctx, const RecordDecl *R
@@ -818,6 +819,189 @@ CodeGenFunction::evaluateOrEmitBuiltinObjectSize(const
Expr *E, unsigned Type,
return ConstantInt::get(ResType, ObjectSize, /*isSigned=*/true);
}
+const FieldDecl *CodeGenFunction::FindFlexibleArrayMemberField(
+ASTContext &Ctx, const RecordDecl *R
@@ -944,22 +951,259 @@ static llvm::Value
*getArrayIndexingBound(CodeGenFunction &CGF,
return nullptr;
}
+namespace {
+
+/// \p StructAccessBase returns the base \p Expr of a field access. It returns
+/// either a \p DeclRefExpr, representing the base pointer to the struct,
@@ -944,22 +951,262 @@ static llvm::Value
*getArrayIndexingBound(CodeGenFunction &CGF,
return nullptr;
}
+namespace {
+
+/// \p StructAccessBase returns the base \p Expr of a field access. It returns
+/// either a \p DeclRefExpr, representing the base pointer to the struct,
@@ -944,22 +951,259 @@ static llvm::Value
*getArrayIndexingBound(CodeGenFunction &CGF,
return nullptr;
}
+namespace {
+
+/// \p StructAccessBase returns the base \p Expr of a field access. It returns
+/// either a \p DeclRefExpr, representing the base pointer to the struct,
@@ -818,6 +819,189 @@ CodeGenFunction::evaluateOrEmitBuiltinObjectSize(const
Expr *E, unsigned Type,
return ConstantInt::get(ResType, ObjectSize, /*isSigned=*/true);
}
+const FieldDecl *CodeGenFunction::FindFlexibleArrayMemberField(
+ASTContext &Ctx, const RecordDecl *R
@@ -818,6 +819,189 @@ CodeGenFunction::evaluateOrEmitBuiltinObjectSize(const
Expr *E, unsigned Type,
return ConstantInt::get(ResType, ObjectSize, /*isSigned=*/true);
}
+const FieldDecl *CodeGenFunction::FindFlexibleArrayMemberField(
+ASTContext &Ctx, const RecordDecl *R
bwendling wrote:
@kees Should be fixed now.
https://github.com/llvm/llvm-project/pull/76348
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -944,22 +951,259 @@ static llvm::Value
*getArrayIndexingBound(CodeGenFunction &CGF,
return nullptr;
}
+namespace {
+
+/// \p StructAccessBase returns the base \p Expr of a field access. It returns
+/// either a \p DeclRefExpr, representing the base pointer to the struct,
@@ -818,6 +819,189 @@ CodeGenFunction::evaluateOrEmitBuiltinObjectSize(const
Expr *E, unsigned Type,
return ConstantInt::get(ResType, ObjectSize, /*isSigned=*/true);
}
+const FieldDecl *CodeGenFunction::FindFlexibleArrayMemberField(
+ASTContext &Ctx, const RecordDecl *R
bwendling wrote:
@kees, the issue should be fixed with the newest push.
https://github.com/llvm/llvm-project/pull/76348
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
bwendling wrote:
> > @kees, the issue should be fixed with the newest push.
>
> Nice! This is so extremely close. It fixed all but 1 instance in the torture
> testing. The remaining seems to be union order sensitive. O_o This
> arrangement still reports non-zero for the `int count_bytes` one,
bwendling wrote:
Like I said, I can fix the `mi->ints` issue. It's when we're trying to ask for
the size of the whole struct with more than one `__counted_by` attribute that
we don't be able to handle.
https://github.com/llvm/llvm-project/pull/76348
bwendling wrote:
@kees Could you supply a pre-processed file and command line? (It should have
been emitted when you got the backtrace.)
https://github.com/llvm/llvm-project/pull/76348
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://li
bwendling wrote:
Never mind. I think I found the issue anyway...
https://github.com/llvm/llvm-project/pull/76348
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
bwendling wrote:
@rapidsna & @nickdesaulniers: Do you have anything to add?
https://github.com/llvm/llvm-project/pull/76348
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
bwendling wrote:
Thanks everyone for their insightful feedback!!
https://github.com/llvm/llvm-project/pull/76348
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/bwendling closed
https://github.com/llvm/llvm-project/pull/76348
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Author: Bill Wendling
Date: 2024-01-10T15:36:33-08:00
New Revision: 4a3fb9ce27dda17e97341f28005a28836c909cfc
URL:
https://github.com/llvm/llvm-project/commit/4a3fb9ce27dda17e97341f28005a28836c909cfc
DIFF:
https://github.com/llvm/llvm-project/commit/4a3fb9ce27dda17e97341f28005a28836c909cfc.diff
bwendling wrote:
Resubmitted with fix. Sorry about the failures:
```
To https://github.com/llvm/llvm-project.git
e8790027b169..164f85db876e main -> main
```
https://github.com/llvm/llvm-project/pull/76348
___
cfe-commits mailing list
cfe-commits@l
Author: Connor Kuehl
Date: 2022-04-08T12:48:30-07:00
New Revision: 3f0587d0c668202bb89d29a25432aa290e551a31
URL:
https://github.com/llvm/llvm-project/commit/3f0587d0c668202bb89d29a25432aa290e551a31
DIFF:
https://github.com/llvm/llvm-project/commit/3f0587d0c668202bb89d29a25432aa290e551a31.diff
Author: Bill Wendling
Date: 2022-04-08T14:42:12-07:00
New Revision: 893e1c18b98d8bbc7b8d7d22cc2c348f65c72ad9
URL:
https://github.com/llvm/llvm-project/commit/893e1c18b98d8bbc7b8d7d22cc2c348f65c72ad9
DIFF:
https://github.com/llvm/llvm-project/commit/893e1c18b98d8bbc7b8d7d22cc2c348f65c72ad9.diff
Author: Bill Wendling
Date: 2022-04-08T16:00:41-07:00
New Revision: e2e6899452998932b37f0fa9e66d104a02abe3e5
URL:
https://github.com/llvm/llvm-project/commit/e2e6899452998932b37f0fa9e66d104a02abe3e5
DIFF:
https://github.com/llvm/llvm-project/commit/e2e6899452998932b37f0fa9e66d104a02abe3e5.diff
Author: Bill Wendling
Date: 2022-04-08T17:04:22-07:00
New Revision: 8d7595be1dd41d7f7470ec90867936ca5e4e0d82
URL:
https://github.com/llvm/llvm-project/commit/8d7595be1dd41d7f7470ec90867936ca5e4e0d82
DIFF:
https://github.com/llvm/llvm-project/commit/8d7595be1dd41d7f7470ec90867936ca5e4e0d82.diff
Author: Bill Wendling
Date: 2022-04-08T17:41:36-07:00
New Revision: 2a2149c754f96376ddf8fed248102dd8e6092a22
URL:
https://github.com/llvm/llvm-project/commit/2a2149c754f96376ddf8fed248102dd8e6092a22
DIFF:
https://github.com/llvm/llvm-project/commit/2a2149c754f96376ddf8fed248102dd8e6092a22.diff
Author: Connor Kuehl
Date: 2022-04-09T13:15:36-07:00
New Revision: 7aa8c38a9e190aea14116028c38b1d9f54cbb0b3
URL:
https://github.com/llvm/llvm-project/commit/7aa8c38a9e190aea14116028c38b1d9f54cbb0b3
DIFF:
https://github.com/llvm/llvm-project/commit/7aa8c38a9e190aea14116028c38b1d9f54cbb0b3.diff
Author: Bill Wendling
Date: 2022-04-09T13:25:25-07:00
New Revision: 77e71bcfde7264466849babaa0e9ccbec51a8a08
URL:
https://github.com/llvm/llvm-project/commit/77e71bcfde7264466849babaa0e9ccbec51a8a08
DIFF:
https://github.com/llvm/llvm-project/commit/77e71bcfde7264466849babaa0e9ccbec51a8a08.diff
Author: Bill Wendling
Date: 2022-04-14T15:41:25-07:00
New Revision: 31ea4798ad0990838ccd27f80ca112f177ce91d9
URL:
https://github.com/llvm/llvm-project/commit/31ea4798ad0990838ccd27f80ca112f177ce91d9
DIFF:
https://github.com/llvm/llvm-project/commit/31ea4798ad0990838ccd27f80ca112f177ce91d9.diff
Author: Bill Wendling
Date: 2022-04-14T16:07:00-07:00
New Revision: 27dead3e3a532625704654a0b66d77f8654d1af2
URL:
https://github.com/llvm/llvm-project/commit/27dead3e3a532625704654a0b66d77f8654d1af2
DIFF:
https://github.com/llvm/llvm-project/commit/27dead3e3a532625704654a0b66d77f8654d1af2.diff
Author: Bill Wendling
Date: 2022-04-14T16:35:41-07:00
New Revision: 8c77a75fb6a82a4cc2182bca89e007e7190a83de
URL:
https://github.com/llvm/llvm-project/commit/8c77a75fb6a82a4cc2182bca89e007e7190a83de
DIFF:
https://github.com/llvm/llvm-project/commit/8c77a75fb6a82a4cc2182bca89e007e7190a83de.diff
Author: Bill Wendling
Date: 2022-04-15T12:29:32-07:00
New Revision: aed923b1246ac38335b222b89594516fcf0d6385
URL:
https://github.com/llvm/llvm-project/commit/aed923b1246ac38335b222b89594516fcf0d6385
DIFF:
https://github.com/llvm/llvm-project/commit/aed923b1246ac38335b222b89594516fcf0d6385.diff
Author: Bill Wendling
Date: 2022-04-15T15:17:07-07:00
New Revision: 2a404cdfd8bc75de593ce0e15fff0a7a0a18ec1c
URL:
https://github.com/llvm/llvm-project/commit/2a404cdfd8bc75de593ce0e15fff0a7a0a18ec1c
DIFF:
https://github.com/llvm/llvm-project/commit/2a404cdfd8bc75de593ce0e15fff0a7a0a18ec1c.diff
Author: Bill Wendling
Date: 2022-04-16T23:24:48-07:00
New Revision: 7f31b4a917d8cc13df5eac4b7f0520639c3a8fff
URL:
https://github.com/llvm/llvm-project/commit/7f31b4a917d8cc13df5eac4b7f0520639c3a8fff
DIFF:
https://github.com/llvm/llvm-project/commit/7f31b4a917d8cc13df5eac4b7f0520639c3a8fff.diff
Author: Bill Wendling
Date: 2022-02-08T17:42:54-08:00
New Revision: deaf22bc0e306bc44c70d2503e9364b5ed312c49
URL:
https://github.com/llvm/llvm-project/commit/deaf22bc0e306bc44c70d2503e9364b5ed312c49
DIFF:
https://github.com/llvm/llvm-project/commit/deaf22bc0e306bc44c70d2503e9364b5ed312c49.diff
Author: Bill Wendling
Date: 2022-02-15T00:06:58-08:00
New Revision: 86bde99a9027f875383e38bfd3a863abae3d0e75
URL:
https://github.com/llvm/llvm-project/commit/86bde99a9027f875383e38bfd3a863abae3d0e75
DIFF:
https://github.com/llvm/llvm-project/commit/86bde99a9027f875383e38bfd3a863abae3d0e75.diff
Author: Bill Wendling
Date: 2022-04-21T19:41:00-07:00
New Revision: a7815d33bf8f955f2a1888abbccf974bd4858f79
URL:
https://github.com/llvm/llvm-project/commit/a7815d33bf8f955f2a1888abbccf974bd4858f79
DIFF:
https://github.com/llvm/llvm-project/commit/a7815d33bf8f955f2a1888abbccf974bd4858f79.diff
Maskray?
On Thu, Apr 21, 2022 at 8:00 PM Nico Weber via Phabricator <
revi...@reviews.llvm.org> wrote:
> thakis added a comment.
>
> Looks like this breaks tests on windows:
> http://45.33.8.238/win/56771/step_7.txt
>
> Please take a look and revert for now if it takes a while to fix.
>
>
> Repos
Author: Bill Wendling
Date: 2022-04-28T12:01:11-07:00
New Revision: 463790bfc70e15f9c23b76f1c53e228b644f8bb1
URL:
https://github.com/llvm/llvm-project/commit/463790bfc70e15f9c23b76f1c53e228b644f8bb1
DIFF:
https://github.com/llvm/llvm-project/commit/463790bfc70e15f9c23b76f1c53e228b644f8bb1.diff
Author: Bill Wendling
Date: 2022-04-29T11:05:09-07:00
New Revision: 6f79700830292d86afec5f3cf5143b00e6f3f1fd
URL:
https://github.com/llvm/llvm-project/commit/6f79700830292d86afec5f3cf5143b00e6f3f1fd
DIFF:
https://github.com/llvm/llvm-project/commit/6f79700830292d86afec5f3cf5143b00e6f3f1fd.diff
Author: Bill Wendling
Date: 2022-05-03T11:23:12-07:00
New Revision: f2639cf3fe46c30ad450cc2533c81eacd4788c33
URL:
https://github.com/llvm/llvm-project/commit/f2639cf3fe46c30ad450cc2533c81eacd4788c33
DIFF:
https://github.com/llvm/llvm-project/commit/f2639cf3fe46c30ad450cc2533c81eacd4788c33.diff
Author: Bill Wendling
Date: 2022-05-19T16:58:28-07:00
New Revision: 6e00a34cdb49ba1d4b72ec274e52260da9c52380
URL:
https://github.com/llvm/llvm-project/commit/6e00a34cdb49ba1d4b72ec274e52260da9c52380
DIFF:
https://github.com/llvm/llvm-project/commit/6e00a34cdb49ba1d4b72ec274e52260da9c52380.diff
https://github.com/bwendling closed
https://github.com/llvm/llvm-project/pull/79366
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/bwendling updated
https://github.com/llvm/llvm-project/pull/80256
>From d08abc7a9454557ffa43fc14611177f2c4e7fba4 Mon Sep 17 00:00:00 2001
From: Bill Wendling
Date: Wed, 31 Jan 2024 13:07:53 -0800
Subject: [PATCH] [Clang] Convert __builtin_dynamic_object_size into a
calculati
https://github.com/bwendling created
https://github.com/llvm/llvm-project/pull/86858
The second argument of __builtin_dynamic_object_size controls whether it
returns the size of the whole object or the closest surrounding object.
For this struct:
struct s {
int foo;
char bar[2][40];
bwendling wrote:
Friendly ping.
https://github.com/llvm/llvm-project/pull/83204
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
bwendling wrote:
Another ping.
https://github.com/llvm/llvm-project/pull/83204
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -26996,18 +26996,38 @@ class, structure, array, or other object.
Arguments:
""
-The ``llvm.objectsize`` intrinsic takes four arguments. The first argument is a
-pointer to or into the ``object``. The second argument determines whether
-``llvm.objectsize`` returns 0
@@ -26996,18 +26996,38 @@ class, structure, array, or other object.
Arguments:
""
-The ``llvm.objectsize`` intrinsic takes four arguments. The first argument is a
-pointer to or into the ``object``. The second argument determines whether
-``llvm.objectsize`` returns 0
@@ -1052,11 +1053,143 @@ CodeGenFunction::emitFlexibleArrayMemberSize(const
Expr *E, unsigned Type,
return Builder.CreateSelect(Cmp, Res, ConstantInt::get(ResType, 0,
IsSigned));
}
+namespace {
+
+/// SubobjectFinder - A simple visitor to find the "sub-object" pointed to b
@@ -26996,18 +26996,38 @@ class, structure, array, or other object.
Arguments:
""
-The ``llvm.objectsize`` intrinsic takes four arguments. The first argument is a
-pointer to or into the ``object``. The second argument determines whether
-``llvm.objectsize`` returns 0
@@ -26996,18 +26996,38 @@ class, structure, array, or other object.
Arguments:
""
-The ``llvm.objectsize`` intrinsic takes four arguments. The first argument is a
-pointer to or into the ``object``. The second argument determines whether
-``llvm.objectsize`` returns 0
@@ -26996,18 +26996,38 @@ class, structure, array, or other object.
Arguments:
""
-The ``llvm.objectsize`` intrinsic takes four arguments. The first argument is a
-pointer to or into the ``object``. The second argument determines whether
-``llvm.objectsize`` returns 0
bwendling wrote:
The first PR attempt was here: https://github.com/llvm/llvm-project/pull/78526
It was NACK'ed because it used the LLVM IR representation of the structure,
which wasn't appropriate. To solve that issue, I chose to expand the
`llvm.objectsize()` builtin to contain the size and o
https://github.com/bwendling edited
https://github.com/llvm/llvm-project/pull/83204
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/bwendling closed
https://github.com/llvm/llvm-project/pull/78526
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/bwendling created
https://github.com/llvm/llvm-project/pull/80256
If we're able to, we convert a call to __builtin_dynamic_object_size into a
calculation. This is a cleaner implementation, and has the potential to improve
optimizations and, especially, inlining, because opti
bwendling wrote:
This is a first step in improving our `__bdos` implementation. It doesn't
address the "sub-object" discussion from the previous PR
(https://github.com/llvm/llvm-project/pull/78526), that will come later on.
This patch takes care of a common use of `__bdos` that can't be calcul
@@ -1051,6 +1052,145 @@ CodeGenFunction::emitFlexibleArrayMemberSize(const Expr
*E, unsigned Type,
return Builder.CreateSelect(Cmp, Res, ConstantInt::get(ResType, 0,
IsSigned));
}
+namespace {
+
+/// \p StructBaseExpr returns the base \p Expr with a structure or union type
https://github.com/bwendling edited
https://github.com/llvm/llvm-project/pull/80256
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/bwendling edited
https://github.com/llvm/llvm-project/pull/80256
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1051,6 +1052,145 @@ CodeGenFunction::emitFlexibleArrayMemberSize(const Expr
*E, unsigned Type,
return Builder.CreateSelect(Cmp, Res, ConstantInt::get(ResType, 0,
IsSigned));
}
+namespace {
+
+/// \p StructBaseExpr returns the base \p Expr with a structure or union type
bwendling wrote:
It matches my understanding too. There are more issues with `__bdos` that arose
due to this discussion and related discussions with the GCC maintainers.
I'm exploring some ways of fixing this issue:
* As @efriedma-quic mentioned, generating the size calculation in the front en
https://github.com/bwendling created
https://github.com/llvm/llvm-project/pull/79366
llvm::Bitfield is a nicer way to represent bitfields in the compiler.
>From 047a96905b4169faf19de30d322943f46cd2fc2a Mon Sep 17 00:00:00 2001
From: Bill Wendling
Date: Wed, 24 Jan 2024 12:09:28 -0800
Subject:
https://github.com/bwendling edited
https://github.com/llvm/llvm-project/pull/79366
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
bwendling wrote:
> I'd like to wait a few weeks before we land it, I'm afraid these changes
> (which do contain some small white spaces-only changes too) might disrupt the
> release process as lot of cherry-picking between main and the llvm18 branch
> are happening and we should minimize the o
bwendling wrote:
It shouldn't be necessary to analyze `uint64_t Storage` directly through a
debugger. It's handled via the `Bitfield` getters and setters. Is that not
sufficient for debugging purposes?
My sinister reason for wanting to do this is that many of the
`const_cast(...)` constructs
bwendling wrote:
> > maybe we could add the subtype as part of the llvm.objectsize intrinsic and
> > use that instead of grappling with the whole object's type
>
> I'm not sure I follow; if you know the object's type, doesn't that mean you
> also know its size?
Not necessarily. If you have so
bwendling wrote:
> > ```c
> > struct x {
> > int a;
> > char foo[2][40];
> > int b;
> > int c;
> > };
> >
> > size_t f(struct x *p, int idx) {
> > return __builtin_dynamic_object_size(&p->foo[idx], 1);
> > }
> > ```
>
> If I'm following correctly, the return here is 0, 40, o
bwendling wrote:
> We've discussed this before, years ago. Previously, the sticking point was:
> how is LLVM going to know what the frontend considers the closest surrounding
> subobject to be? The LLVM type doesn't give you that information, and it
> seems like there's nowhere else that LLVM
bwendling wrote:
> Using anything but the size and alignment of the alloca type in a way that
> affects program semantics is illegal.
I'm sorry, but I don't understand your comment here. Could you supply some
context?
https://github.com/llvm/llvm-project/pull/78526
___
bwendling wrote:
> Perhaps according to the GCC documentation as written. But mode 0 and 1 are
> in general asking for an upper bound on the accessible bytes (that is, an N
> so any.access beyond N bytes is definitely out of bounds), so it seems to me
> that returning -1 is strictly worse than
bwendling wrote:
> @bwendling I think you are reading the GCC docs too pedantically. In
> particular, they also say
> > If there are multiple objects ptr can point to and all of them are known at
> > compile time, the returned number is the maximum of remaining byte counts
> > in those object
bwendling wrote:
> > For unions, clang will use the type of the union member with the largest
> > size as the alloca type, regardless of which union member is active. I
> > haven't tried, but your patch will probably compute the subobject size
> > based on that arbitrarily picked member, rathe
bwendling wrote:
> > > But mode 0 and 1 are in general asking for an upper bound on the
> > > accessible bytes (that is, an N so any.access beyond N bytes is
> > > definitely out of bounds), so it seems to me that returning -1 is
> > > strictly worse than returning 48.
> >
> >
> > It's the s
bwendling wrote:
> Taking a step back, while this patch is not the right direction, we can and
> should do better for the original example. Probably the best way to do that
> is to analyze the operand to `__builtin_[dynamic_]object_size` in the
> frontend and compute a better bound based on th
bwendling wrote:
> > Perhaps we need clarification on what GCC means by "may point to multiple
> > objects" in this instance. To me that means either "get me the size of the
> > largest of these multiple objects" or "size of the smallest." In my eyes,
> > that means pointing to a union field.
bwendling wrote:
> > My answer for the question "what's the semantics of GCC's builtin X?" has
> > always been "whatever GCC does." It's the best we can rely upon. But then
> > we get into situations like this, where you and @nikic have one
> > interpretation of their documentation and I have
bwendling wrote:
> @bwendling is there any plan / possibility for simple expressions (with no
> side effects)? Like:
>
> ```c
> struct libusb_bos_dev_capability_descriptor {
> uint8_t bLength;
> uint8_t bDescriptorType;
> uint8_t bDevCapabilityType;
> uint8_t dev_cap
Yeah. I reverted the push. The correct code should be in Phabricator now.
:-(
On Tue, Jan 7, 2020 at 2:45 PM James Y Knight via Phabricator <
revi...@reviews.llvm.org> wrote:
> jyknight added a comment.
>
> I think you pushed the incorrect change? This was the clang half, but now
> it's showing t
Author: Bill Wendling
Date: 2020-09-24T13:59:42-07:00
New Revision: 34ca5b3392ced08e2320fb4236cca5c7df4ec6e9
URL:
https://github.com/llvm/llvm-project/commit/34ca5b3392ced08e2320fb4236cca5c7df4ec6e9
DIFF:
https://github.com/llvm/llvm-project/commit/34ca5b3392ced08e2320fb4236cca5c7df4ec6e9.diff
Author: Bill Wendling
Date: 2020-09-24T14:34:28-07:00
New Revision: f97b68ef4ddd28a685e502653768c2a34c314cba
URL:
https://github.com/llvm/llvm-project/commit/f97b68ef4ddd28a685e502653768c2a34c314cba
DIFF:
https://github.com/llvm/llvm-project/commit/f97b68ef4ddd28a685e502653768c2a34c314cba.diff
Author: Bill Wendling
Date: 2020-09-24T15:21:28-07:00
New Revision: c9b53b3bf20d20d5752876be32a9e5887c702e53
URL:
https://github.com/llvm/llvm-project/commit/c9b53b3bf20d20d5752876be32a9e5887c702e53
DIFF:
https://github.com/llvm/llvm-project/commit/c9b53b3bf20d20d5752876be32a9e5887c702e53.diff
Author: Bill Wendling
Date: 2022-10-20T11:56:49-07:00
New Revision: b76219b590208c1b539e614247f91481900bd7a1
URL:
https://github.com/llvm/llvm-project/commit/b76219b590208c1b539e614247f91481900bd7a1
DIFF:
https://github.com/llvm/llvm-project/commit/b76219b590208c1b539e614247f91481900bd7a1.diff
Author: Bill Wendling
Date: 2022-10-20T16:08:11-07:00
New Revision: 283e0a81ef35deec46aa231cb8b9d826060f532a
URL:
https://github.com/llvm/llvm-project/commit/283e0a81ef35deec46aa231cb8b9d826060f532a
DIFF:
https://github.com/llvm/llvm-project/commit/283e0a81ef35deec46aa231cb8b9d826060f532a.diff
Author: Bill Wendling
Date: 2022-10-27T10:50:04-07:00
New Revision: 7f93ae808634e33e4dc9bce753c909aa5f9a6eb4
URL:
https://github.com/llvm/llvm-project/commit/7f93ae808634e33e4dc9bce753c909aa5f9a6eb4
DIFF:
https://github.com/llvm/llvm-project/commit/7f93ae808634e33e4dc9bce753c909aa5f9a6eb4.diff
Author: Bill Wendling
Date: 2022-10-06T10:45:41-07:00
New Revision: 7404b855e528f88bf2a395a0a14937ca6812e8d1
URL:
https://github.com/llvm/llvm-project/commit/7404b855e528f88bf2a395a0a14937ca6812e8d1
DIFF:
https://github.com/llvm/llvm-project/commit/7404b855e528f88bf2a395a0a14937ca6812e8d1.diff
201 - 300 of 700 matches
Mail list logo
