https://github.com/urnathan closed
https://github.com/llvm/llvm-project/pull/89055
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/urnathan updated
https://github.com/llvm/llvm-project/pull/89055
>From 9ab483f3451bfcaa7968c5f1cf7115144522f58a Mon Sep 17 00:00:00 2001
From: Nathan Sidwell
Date: Mon, 1 Apr 2024 16:15:12 -0400
Subject: [PATCH 1/3] [clang] Remove class layout scissor
---
https://github.com/urnathan updated
https://github.com/llvm/llvm-project/pull/89055
>From db5e6456f26ea9b859d3ff24161d7494d58bb7e1 Mon Sep 17 00:00:00 2001
From: Nathan Sidwell
Date: Mon, 1 Apr 2024 16:15:12 -0400
Subject: [PATCH 1/3] [clang] Remove class layout scissor
---
urnathan wrote:
ping?
https://github.com/llvm/llvm-project/pull/89055
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/urnathan ready_for_review
https://github.com/llvm/llvm-project/pull/89055
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/urnathan updated
https://github.com/llvm/llvm-project/pull/89055
>From db5e6456f26ea9b859d3ff24161d7494d58bb7e1 Mon Sep 17 00:00:00 2001
From: Nathan Sidwell
Date: Mon, 1 Apr 2024 16:15:12 -0400
Subject: [PATCH 1/2] [clang] Remove class layout scissor
---
https://github.com/urnathan created
https://github.com/llvm/llvm-project/pull/89055
Now that `accumulateBitfields` does the correct clipping, we don't need the
scissor any more -- `checkBitfieldClipping` can compute its location directly.
>From db5e6456f26ea9b859d3ff24161d7494d58bb7e1 Mon Sep
https://github.com/urnathan closed
https://github.com/llvm/llvm-project/pull/87090
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
urnathan wrote:
@rjmccall can you take a look at this? as the description says, this turns out
to not be NFC, but important on (probably only) LP64 machines.
https://github.com/llvm/llvm-project/pull/87090
___
cfe-commits mailing list
https://github.com/urnathan closed
https://github.com/llvm/llvm-project/pull/73263
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/urnathan closed
https://github.com/llvm/llvm-project/pull/87238
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/urnathan ready_for_review
https://github.com/llvm/llvm-project/pull/87238
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -330,6 +331,8 @@ class LLVM_LIBRARY_VISIBILITY MipsTargetInfo : public
TargetInfo {
IsMicromips = true;
else if (Feature == "+mips32r6" || Feature == "+mips64r6")
HasUnalignedAccess = true;
+ else if (Feature == "+strict-align")
+
urnathan wrote:
Be aware of bug #87227 and PR #87238 to address that
https://github.com/llvm/llvm-project/pull/65742
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/urnathan converted_to_draft
https://github.com/llvm/llvm-project/pull/87090
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/urnathan created
https://github.com/llvm/llvm-project/pull/87238
This fixes #87227 My change to bitfield access unit allocation (#65742) causes
an ICE for a corner case of vbase allocation: a class where an unshared (i.e.
not the nearly-empty base optimization) vbase is
urnathan wrote:
#65742 is committed, so MIPS' TargetInfo will need adjusting to propagate the
unaligned capability. See 7df79ababee8
https://github.com/llvm/llvm-project/pull/85174
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
urnathan wrote:
Sigh, clipTailPadding is still needed, because of no_unique_address and empty
base placement. Will update.
https://github.com/llvm/llvm-project/pull/87090
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://github.com/urnathan created
https://github.com/llvm/llvm-project/pull/87090
This follows on from PR65742. As I suspected clipTailPadding's functionality
can be moved into accumulateBitfields; it has sufficient information now. It
turns out that clipTailPadding was undoing some of the
urnathan wrote:
Committed, expect tailclipping cleanup PR soon
https://github.com/llvm/llvm-project/pull/65742
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/urnathan closed
https://github.com/llvm/llvm-project/pull/65742
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Author: Nathan Sidwell
Date: 2024-03-29T09:35:31-04:00
New Revision: 7df79ababee8d03b27bbaba1aabc2ec4ea14143e
URL:
https://github.com/llvm/llvm-project/commit/7df79ababee8d03b27bbaba1aabc2ec4ea14143e
DIFF:
Author: Nathan Sidwell
Date: 2024-03-29T09:35:31-04:00
New Revision: a8ca4abfcfa98d28ec46ee497e1fc5e91f8e1ad6
URL:
https://github.com/llvm/llvm-project/commit/a8ca4abfcfa98d28ec46ee497e1fc5e91f8e1ad6
DIFF:
urnathan wrote:
@rjmccall thanks, here is an update with those changes. I've collapsed it to
the 3 commits mentioned earlier
1) Tests marked up for the current behaviour
2) TargetInfo strict/flexible alignment load predicate
3) The new algorithm
@@ -439,82 +444,247 @@
CGRecordLowering::accumulateBitFields(RecordDecl::field_iterator Field,
Members.push_back(MemberInfo(bitsToCharUnits(StartBitOffset),
MemberInfo::Field, nullptr, *Field));
}
-return;
+return Field;
urnathan wrote:
Sorry to push another update, but I realized the LimitOffset computation could
be sunk to the point of use, and therefore not computed in all cases.
https://github.com/llvm/llvm-project/pull/65742
___
cfe-commits mailing list
urnathan wrote:
@rjmccall here is a rebase an update, which I think addresses all your
comments. I did make some material changes though:
1) I removed the Volatile handling. I was always a little uncomfortable with it
because it didn't affect the access units of a non-volatile bitfield that
@@ -439,82 +444,194 @@
CGRecordLowering::accumulateBitFields(RecordDecl::field_iterator Field,
Members.push_back(MemberInfo(bitsToCharUnits(StartBitOffset),
MemberInfo::Field, nullptr, *Field));
}
-return;
+return Field;
@@ -439,82 +444,194 @@
CGRecordLowering::accumulateBitFields(RecordDecl::field_iterator Field,
Members.push_back(MemberInfo(bitsToCharUnits(StartBitOffset),
MemberInfo::Field, nullptr, *Field));
}
-return;
+return Field;
urnathan wrote:
@rjmccall here's a refactoring along the lines you suggested. Once one stops
worrying about rescanning when the next access unit fails to accumulate into
the current one, things get simpler. The compiler should be able to turn the
boolean conditional flow within the loop body
urnathan wrote:
This update
* moves the creation and installation of the BitFieldAccessUnit objects into
CGRecordLowering.
* adds aarch64 and arm darwin target tests, as those have different layout
rules (let me know if I've missed something here).
* Simplifies the checking of barriers -- an
@@ -394,33 +412,155 @@ void CGRecordLowering::accumulateFields() {
: getStorageType(*Field),
*Field));
++Field;
-} else {
- ++Field;
}
}
}
-void
-CGRecordLowering::accumulateBitFields(RecordDecl::field_iterator Field,
-
@@ -394,33 +412,155 @@ void CGRecordLowering::accumulateFields() {
: getStorageType(*Field),
*Field));
++Field;
-} else {
- ++Field;
}
}
}
-void
-CGRecordLowering::accumulateBitFields(RecordDecl::field_iterator Field,
-
urnathan wrote:
> >
>
> Thinking further, several (AArch64, ARM & Loongson) targets have a
> 'HasUnaligned' bool in their TargetInfo objects. Perhaps the way forwards is
> to promote that to the base TargetInfo and just use that, rather than the
> bitfield-specific field I added (which just
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
@@ -132,6 +132,7 @@ class LLVM_LIBRARY_VISIBILITY LoongArch64TargetInfo
: LoongArchTargetInfo(Triple, Opts) {
LongWidth = LongAlign = PointerWidth = PointerAlign = 64;
IntMaxType = Int64Type = SignedLong;
+HasCheapUnalignedBitfieldAccess = true;
https://github.com/urnathan closed
https://github.com/llvm/llvm-project/pull/82874
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/urnathan updated
https://github.com/llvm/llvm-project/pull/82874
>From 792c608cc55d89552cf86d058796825a1f428f5d Mon Sep 17 00:00:00 2001
From: Nathan Sidwell
Date: Fri, 2 Feb 2024 08:01:21 -0500
Subject: [PATCH] [clang][NFC] constify or staticify some fns
These functions do
Author: Nathan Sidwell
Date: 2024-02-24T12:25:08-05:00
New Revision: 8e22fffc85b36784146041499b716cec74285660
URL:
https://github.com/llvm/llvm-project/commit/8e22fffc85b36784146041499b716cec74285660
DIFF:
https://github.com/urnathan edited
https://github.com/llvm/llvm-project/pull/82874
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/urnathan created
https://github.com/llvm/llvm-project/pull/82874
As mentioned in PR https://github.com/llvm/llvm-project/pull/65742, these
functions do not alter the object -- and on one case don't even need it. Thus
marking them static or const as appropriate. I constified
@@ -95,8 +95,6 @@ static bool TypeHasMayAlias(QualType QTy) {
/// Check if the given type is a valid base type to be used in access tags.
static bool isValidBaseType(QualType QTy) {
- if (QTy->isReferenceType())
-return false;
urnathan wrote:
would you
@@ -132,6 +132,7 @@ class LLVM_LIBRARY_VISIBILITY LoongArch64TargetInfo
: LoongArchTargetInfo(Triple, Opts) {
LongWidth = LongAlign = PointerWidth = PointerAlign = 64;
IntMaxType = Int64Type = SignedLong;
+HasCheapUnalignedBitfieldAccess = true;
urnathan wrote:
> On the target hook, it's a shame we can't easily get this information from
> LLVM. I believe it's already there — `TargetLowering` has an
> `allowsMisalignedMemoryAccesses` method that includes some approximation of
> how fast a particular access would be. In practice, it
urnathan wrote:
> On the LLVM side, there's very little interesting logic; it's basically just
> walking the tree of metadata nodes generated by clang. See
> https://llvm.org/docs/LangRef.html#tbaa-node-semantics . The hard part of the
> refactoring would just be adding an abstraction for the
urnathan wrote:
@rjmccall thanks for your comments. Here's a reimplementation using a single
loop -- the downside is that we may end up repeating the initial grouping scan,
if we search more than 1 Access Unit ahead and fail to find a 'good' access
unit. This update changes the algorithm
@@ -376,33 +377,41 @@ void CGRecordLowering::lowerUnion(bool isNoUniqueAddress)
{
}
void CGRecordLowering::accumulateFields() {
- for (RecordDecl::field_iterator Field = D->field_begin(),
- FieldEnd = D->field_end();
-Field != FieldEnd;)
@@ -95,8 +95,6 @@ static bool TypeHasMayAlias(QualType QTy) {
/// Check if the given type is a valid base type to be used in access tags.
static bool isValidBaseType(QualType QTy) {
- if (QTy->isReferenceType())
-return false;
urnathan wrote:
This is
urnathan wrote:
Can someone please review this?
https://github.com/llvm/llvm-project/pull/65742
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
urnathan wrote:
@efriedma-quic this naming ok?
https://github.com/llvm/llvm-project/pull/73263
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
urnathan wrote:
ping?
https://github.com/llvm/llvm-project/pull/65742
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
urnathan wrote:
ping?
https://github.com/llvm/llvm-project/pull/73263
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
urnathan wrote:
> > > FWIW the GCC doc is
> > > https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wstrict-aliasing_003dn
> > > It says for Level 3 "If optimization is enabled, it also runs in the
> > > back end, where it deals with multiple statement cases using
> > >
@@ -498,3 +498,137 @@
CodeGenTBAA::mergeTBAAInfoForMemoryTransfer(TBAAAccessInfo DestInfo,
// access type regardless of their base types.
return TBAAAccessInfo::getMayAliasInfo();
}
+
+// Determine the aliasing kind bit-converting from type Src to type Dst.
@@ -37,6 +38,27 @@ class ASTConsumer {
friend class SemaConsumer;
+public:
+ /// Allow type-based aliasing information to be interrogated by the AST
+ /// producer (for diagnostics).
+ class TypeAliasing {
urnathan wrote:
Oh, we also endup deriving
urnathan wrote:
> I'd tend to prefer to keep the simpler name for the external interface, and
> use a more complicated one for use within the class. So maybe introduce
> getValidBaseTypeInfo().
This naming scheme better?
https://github.com/llvm/llvm-project/pull/73263
urnathan wrote:
Rebased
https://github.com/llvm/llvm-project/pull/65742
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/urnathan closed
https://github.com/llvm/llvm-project/pull/74893
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/urnathan ready_for_review
https://github.com/llvm/llvm-project/pull/74893
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/urnathan created
https://github.com/llvm/llvm-project/pull/74893
An 8 bit bitfield with preferred bool type? Seems confused.
>From f7cac332123f6ea6c78dcffbcac2d58f356b6396 Mon Sep 17 00:00:00 2001
From: Nathan Sidwell
Date: Fri, 8 Dec 2023 17:43:22 -0500
Subject: [PATCH]
urnathan wrote:
> I'm planning to take a closer look at this when I have more time. Sorry I
> haven't been more responsive here.
When might that be?
https://github.com/llvm/llvm-project/pull/65742
___
cfe-commits mailing list
@@ -0,0 +1,192 @@
+// RUN: %clang_cc1 %s -O0 -Wstrict-aliasing -S -o %t -verify=quiet
+// RUN: %clang_cc1 %s -O2 -Wstrict-aliasing=0 -S -o %t -verify=quiet
+// RUN: %clang_cc1 %s -O2 -Wno-strict-aliasing -S -o %t -verify=quiet
+// RUN: %clang_cc1 %s -O2 -Wstrict-aliasing=1 -S -o
https://github.com/urnathan updated
https://github.com/llvm/llvm-project/pull/74155
>From 89c05618bb75fd073343046f3b54bde5f2254719 Mon Sep 17 00:00:00 2001
From: Nathan Sidwell
Date: Wed, 15 Nov 2023 15:27:16 -0500
Subject: [PATCH 1/6] [clang] Strict aliasing warning ala GCC [PR50066]
This
@@ -128,6 +128,10 @@ class DiagnosticOptions : public
RefCountedBase{
/// whether -Wsystem-headers is enabled on a per-module basis.
std::vector SystemHeaderWarningsModules;
+ /// Level of scrutiny reinterpret_casts get for type-unsafe aliasing
+ /// checks. Requires
https://github.com/urnathan edited
https://github.com/llvm/llvm-project/pull/74155
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
urnathan wrote:
> Thank you for your efforts! I scratched the surface a bit; not qualified to
> do an in-depth review. Can you also add a release note?
Thanks for your comments. A release note is added.
https://github.com/llvm/llvm-project/pull/74155
urnathan wrote:
> FWIW the GCC doc is
> https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wstrict-aliasing_003dn
> It says for Level 3 "If optimization is enabled, it also runs in the back
> end, where it deals with multiple statement cases using flow-sensitive
> points-to
urnathan wrote:
> Making Sema pull the TBAA info out of clang/lib/CodeGen is a layering
> violation (and probably breaks if we aren't actually generating code). If we
> need some notion of "aliasing" in Sema, we should pull the relevant code into
> clang/lib/AST.
That's unfortunate. The
@@ -2026,6 +2027,137 @@ static TryCastResult TryConstCast(Sema ,
ExprResult ,
return TC_Success;
}
+// We're dereferencing E, either by turning into an RValue, or by dereferencing
+// it. Check whether it's a deref of a reinterpret cast that has aliasing
+// issues.
+void
@@ -498,3 +498,137 @@
CodeGenTBAA::mergeTBAAInfoForMemoryTransfer(TBAAAccessInfo DestInfo,
// access type regardless of their base types.
return TBAAAccessInfo::getMayAliasInfo();
}
+
+// Determine the aliasing kind bit-converting from type Src to type Dst.
@@ -498,3 +498,137 @@
CodeGenTBAA::mergeTBAAInfoForMemoryTransfer(TBAAAccessInfo DestInfo,
// access type regardless of their base types.
return TBAAAccessInfo::getMayAliasInfo();
}
+
+// Determine the aliasing kind bit-converting from type Src to type Dst.
https://github.com/urnathan updated
https://github.com/llvm/llvm-project/pull/74155
>From 89c05618bb75fd073343046f3b54bde5f2254719 Mon Sep 17 00:00:00 2001
From: Nathan Sidwell
Date: Wed, 15 Nov 2023 15:27:16 -0500
Subject: [PATCH 1/5] [clang] Strict aliasing warning ala GCC [PR50066]
This
https://github.com/urnathan edited
https://github.com/llvm/llvm-project/pull/74155
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/urnathan ready_for_review
https://github.com/llvm/llvm-project/pull/74155
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/urnathan closed
https://github.com/llvm/llvm-project/pull/73264
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/urnathan created
https://github.com/llvm/llvm-project/pull/74155
This implements -Wstrict-aliasing(=[123])? along the same lines as GCC. It's
not 100% the same for reasons expanded on below. The default is level 3, and I
have verified that bootstrapping does not trigger any
urnathan wrote:
You knew this ping was coming, right?
https://github.com/llvm/llvm-project/pull/65742
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
urnathan wrote:
sure, like so?
https://github.com/llvm/llvm-project/pull/73263
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/urnathan updated
https://github.com/llvm/llvm-project/pull/73263
>From 2a312ddadae91ea52b184edaa0d19495c6e0f4a3 Mon Sep 17 00:00:00 2001
From: Nathan Sidwell
Date: Wed, 22 Nov 2023 20:45:38 -0500
Subject: [PATCH 1/2] [clang][NFC] Adjust TBAA Base Info API
I noticed a couple
@@ -418,14 +418,20 @@ llvm::MDNode *CodeGenTBAA::getBaseTypeInfo(QualType QTy) {
return nullptr;
const Type *Ty = Context.getCanonicalType(QTy).getTypePtr();
- if (llvm::MDNode *N = BaseTypeMetadataCache[Ty])
-return N;
- // Note that the following helper call
https://github.com/urnathan updated
https://github.com/llvm/llvm-project/pull/73264
>From e4c92cd687782743ba939becf7ea8862eea6a108 Mon Sep 17 00:00:00 2001
From: Nathan Sidwell
Date: Thu, 23 Nov 2023 11:30:12 -0500
Subject: [PATCH 1/2] [clang] Avoid recalculating TBAA base type info
I noticed
https://github.com/urnathan ready_for_review
https://github.com/llvm/llvm-project/pull/73264
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/urnathan ready_for_review
https://github.com/llvm/llvm-project/pull/73263
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/urnathan closed
https://github.com/llvm/llvm-project/pull/70499
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/urnathan created
https://github.com/llvm/llvm-project/pull/73264
I noticed that TBAA BaseTypeMetadataCache can legitimately store null values,
but it also uses that to mean 'no entry'. Thus nullptr entries get continually
recalculated. (AFAICT null entries can never become
https://github.com/urnathan created
https://github.com/llvm/llvm-project/pull/73263
I noticed a couple of minor issues with CodeGenTBAA::getBaseTypeInfo.
1) isValidBaseType explicitly checks for a reference type to return false, but
then also returns false for all non-record types. Just
urnathan wrote:
I'm going to break this apart, as I've realized this has conflated two separate
problems.
https://github.com/llvm/llvm-project/pull/70499
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://github.com/urnathan closed
https://github.com/llvm/llvm-project/pull/71170
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
urnathan wrote:
thanks @yonghong-song!
Taking the opportunity for a ping :)
https://github.com/llvm/llvm-project/pull/65742
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/urnathan ready_for_review
https://github.com/llvm/llvm-project/pull/71170
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/urnathan edited
https://github.com/llvm/llvm-project/pull/71170
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/urnathan updated
https://github.com/llvm/llvm-project/pull/71170
>From 9b5cb1ac8d4b9a2aaa4c06e41620e38b6c3cae8c Mon Sep 17 00:00:00 2001
From: Nathan Sidwell
Date: Thu, 2 Nov 2023 18:14:05 -0400
Subject: [PATCH 1/3] Fix python escapes
With Fedora 39, I encountered 2 new
https://github.com/urnathan updated
https://github.com/llvm/llvm-project/pull/71170
>From 9b5cb1ac8d4b9a2aaa4c06e41620e38b6c3cae8c Mon Sep 17 00:00:00 2001
From: Nathan Sidwell
Date: Thu, 2 Nov 2023 18:14:05 -0400
Subject: [PATCH 1/2] Fix python escapes
With Fedora 39, I encountered 2 new
https://github.com/urnathan created
https://github.com/llvm/llvm-project/pull/71170
With Fedora 39, I encountered 2 new python warnings:
/home/nathan/gh/llvm/push/strict-aliasing/clang/lib/Tooling/DumpTool/generate_cxx_src_locs.py:28:
SyntaxWarning: invalid escape sequence '\*'
urnathan wrote:
> One very brief note: in the comments in the code, you might want to
> distinguish between the semantic width of a bitfield (i.e. the C standard
> notion of a "memory location", which has ABI significance), vs. the accesses
> we choose to generate (we don't need to generate
https://github.com/urnathan ready_for_review
https://github.com/llvm/llvm-project/pull/70499
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/urnathan closed
https://github.com/llvm/llvm-project/pull/69739
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/urnathan closed
https://github.com/llvm/llvm-project/pull/70149
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
urnathan wrote:
@jdoerfert thanks for that, here's an update that focusses the check-not more
precisely.
https://github.com/llvm/llvm-project/pull/69739
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://github.com/urnathan updated
https://github.com/llvm/llvm-project/pull/69739
>From bb391aa466577f4187af6b284ee5107090778a03 Mon Sep 17 00:00:00 2001
From: Nathan Sidwell
Date: Fri, 20 Oct 2023 11:43:08 -0400
Subject: [PATCH 1/2] [clang] Robustify open mp test
If the source path
1 - 100 of 183 matches
Mail list logo
