https://github.com/bwendling closed
https://github.com/llvm/llvm-project/pull/110487
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Cydox wrote:
No worries
https://github.com/llvm/llvm-project/pull/110487
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
bwendling wrote:
> @bwendling I think you accidentally compiled the wrong branch. Looks like
> that is in `builtin_get_counted_by`, but this PR is in
> `bdos-member-expr-error`
Yeah, sorry about that.
https://github.com/llvm/llvm-project/pull/110487
___
Cydox wrote:
@bwendling I think you accidentally compiled the wrong branch. Looks like that
is in `builtin_get_counted_by`, but this PR is in `bdos-member-expr-error`
https://github.com/llvm/llvm-project/pull/110487
___
cfe-commits mailing list
cfe-co
Cydox wrote:
Interesting. You compiled with `-O2`, I compiled without optimization.
When I compile it with `-O2`, I now get `0`.
I've uploaded a gist with the disassembly generated with
```
clang -mllvm --x86-asm-syntax=intel -S test.c -o ./test-no-optimize.S
```
and
```
clang -O2 -mllvm --x86-
bwendling wrote:
> > I reverted my last commit. This leaves the original patch, which seems to
> > work. @efriedma-quic, would you be okay with this patch while I work to
> > improve the code in follow-up?
>
> The original (and current) patch in this PR still introduces a regression. So
> it
Cydox wrote:
> I reverted my last commit. This leaves the original patch, which seems to
> work. @efriedma-quic, would you be okay with this patch while I work to
> improve the code in follow-up?
The original (and current) patch in this PR still introduces a regression. So
it should not be me
bwendling wrote:
I reverted my last commit. This leaves the original patch, which seems to work.
@efriedma-quic, would you be okay with this patch while I work to improve the
code in follow-up?
https://github.com/llvm/llvm-project/pull/110487
___
cfe
https://github.com/bwendling updated
https://github.com/llvm/llvm-project/pull/110487
>From 375a71d114fffb94c16455f476364a7de9e08191 Mon Sep 17 00:00:00 2001
From: Bill Wendling
Date: Mon, 30 Sep 2024 03:41:15 -0700
Subject: [PATCH 1/3] [Clang][CodeGen] Emit load of value
We were missing a loa
https://github.com/bwendling updated
https://github.com/llvm/llvm-project/pull/110487
>From 375a71d114fffb94c16455f476364a7de9e08191 Mon Sep 17 00:00:00 2001
From: Bill Wendling
Date: Mon, 30 Sep 2024 03:41:15 -0700
Subject: [PATCH 1/2] [Clang][CodeGen] Emit load of value
We were missing a loa
@@ -1160,23 +1162,10 @@ llvm::Value *CodeGenFunction::EmitLoadOfCountedByField(
if (!StructBase || StructBase->HasSideEffects(getContext()))
return nullptr;
- llvm::Value *Res = nullptr;
- if (const auto *DRE = dyn_cast(StructBase)) {
-Res = EmitDeclRefLValue(DRE).
Cydox wrote:
> I went ahead and used the `EmitPointerWithAlignment` for all (it worked
> without needing special casing). I'll look into doing this in Sema as a
> potential cleanup.
With that change now the compiler segfaults when compiling the example C file I
posted above:
> ```c
> #inclu
bwendling wrote:
> > If I return the LValueToRValue cast and run EmitLValue on it
>
> I'm surprised EmitLValue didn't error out on that. The result of an
> LValueToRValue cast is an rvalue. Calling EmitPointerWithAlignment on it
> should work, I think.
>
> > I understand, but there are ~30 di
https://github.com/bwendling updated
https://github.com/llvm/llvm-project/pull/110487
>From 375a71d114fffb94c16455f476364a7de9e08191 Mon Sep 17 00:00:00 2001
From: Bill Wendling
Date: Mon, 30 Sep 2024 03:41:15 -0700
Subject: [PATCH 1/2] [Clang][CodeGen] Emit load of value
We were missing a loa
bwendling wrote:
> This is sort of the same comment I've made on other related patches... but I
> think the fundamental issue here is that StructAccessBase is skipping over
> CK_LValueToRValue casts. Once you jump over such a cast, you're looking at
> expressions which are at a different level
https://github.com/efriedma-quic commented:
This is sort of the same comment I've made on other related patches... but I
think the fundamental issue here is that StructAccessBase is skipping over
CK_LValueToRValue casts. Once you jump over such a cast, you're looking at
expressions which are
Cydox wrote:
Reopened my fix as #110497 and also adjusted the test to also check for the
case of a nested struct without indirection.
https://github.com/llvm/llvm-project/pull/110487
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://list
Cydox wrote:
Wait, this introduces a regression when the inner struct is directly nested
without using a pointer like so:
Without this change the code below will return 64, with my fix it will also
return 64, with this fix it will SEGFAULT.
```C
#include
#include
#include
struct variable
Cydox wrote:
Fixes the kernel issue for me.
I closed #110437 in favor of this one
https://github.com/llvm/llvm-project/pull/110487
___
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/110487
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
20 matches
Mail list logo
