From Nihal Jere to ~mcf/cproc
--- This patch should handle most cases, but there is a catch: In the function g in test/typeof-vm.c, notice I had to initialize p. If it is uninitialized, and since the argument of typeof is evaluated, p is loaded without being stored to. cc.h | 3 ++- decl.c | 8 +++++--- expr.c | 21 ++++++++++++--------- qbe.c | 6 ++++++ test/typeof-vm.c | 17 +++++++++++++++++ 5 files changed, 42 insertions(+), 13 deletions(-) diff --git a/cc.h b/cc.h [message trimmed]
From Nihal Jere to ~mpu/qbe
This is an attempt to implement volatile load/store. Currently they are unimplemented for arm64 and rv64, but right now I just want to make sure people more familiar with qbe think the approach is reasonable. Essentially I took all of the existing load/store instructions, and made duplicates which don't go through any of the optimization passes. --- all.h | 2 ++ amd64/isel.c | 12 ++++++++++++ ops.h | 15 +++++++++++++++ parse.c | 16 ++++++++++++++-- ssa.c | 2 ++ tools/lexh.c | 11 +++++++---- [message trimmed]
From Nihal Jere to ~mcf/cproc
On Thu, Apr 11, 2024 at 06:33:38PM -0700, Michael Forney wrote: > Hey Nihal, > > I pushed a few more commits to the VLA branch. Mostly fixing some > edge cases, tests, and some simplification. > > Here's a few outstanding issues. > - Write a test for compatibility of VLA types. This can be done > with static_assert and __builtin_types_compatible_p. > - Implement typeof with expression that has VM type used in > cast/__builtin_va_arg/compound literal. We can worry about this > later, but for now I think we should just make typename() error > out if it receives a typeofexpr from declarator(). > - I'm still worried about the possibility of VLAs used in a loop
From Nihal Jere to ~mcf/cproc
Actually I think this is still wrong, since u.array.length is set whether the type is variably-modified or not. Would it make sense to replace u.array.length with the evaluated expression in `declarator` in decl.c, and then check if this is a constant in typecompatible? On Wed, Apr 10, 2024 at 08:10:29PM -0500, Nihal Jere wrote: > Two arrays are type compatible when they have compatible base types and > either one is a VLA, or they both have the same constant expression > length. > --- > type.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/type.c b/type.c
From Nihal Jere to ~mcf/cproc
calcvla was adjusted to handle with any types with PROPVM set. typeof is still not handled in casts. --- cc.h | 1 + decl.c | 11 ++++++++--- qbe.c | 27 ++++++++++++++++----------- 3 files changed, 25 insertions(+), 14 deletions(-) diff --git a/cc.h b/cc.h index e73c850..6a1b485 100644 --- a/cc.h +++ b/cc.h @@ -278,6 +278,7 @@ struct decl { [message trimmed]
From Nihal Jere to ~mcf/cproc
Two arrays are type compatible when they have compatible base types and either one is a VLA, or they both have the same constant expression length. --- type.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/type.c b/type.c index 0347881..b609bfc 100644 --- a/type.c +++ b/type.c @@ -131,7 +131,8 @@ typecompatible(struct type *t1, struct type *t2) case TYPEPOINTER: goto derived; [message trimmed]
From Nihal Jere to ~mcf/cproc
On Tue, Apr 09, 2024 at 07:25:36PM -0700, Michael Forney wrote: > Here's what I believe to be a gcc bug: > > int a[(0, 1)]; typeof(puts("variably-modified"), &a) p; > > This doesn't print "variably-modified" (but does in clang). While > > int (*p)[(0, 1)] = 0; typeof(puts("variably-modified"), p) q; > > does print "variably-modified" in both gcc and clang. This is weird > because &a and p both have the exact same type; Interesting. To make sure I understand correctly, in the first line, the fact that `(0, 1)` is not a constant expression (even though its
From Nihal Jere to ~mcf/cproc
On Mon, Apr 08, 2024 at 11:55:51PM -0700, Michael Forney wrote: > Do you have any ideas on how to implement this? > I am working on a patch which adds a `struct expr *` field to `struct decl`, and only sets it when either typeof or typeof_unqual is used. Then we generate the code for the expression if it has PROPVM set on its type. Would this work, or is there something I'm missing?
From Nihal Jere to ~mcf/cproc
--- type.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/type.c b/type.c index 0347881..5095d3d 100644 --- a/type.c +++ b/type.c @@ -131,7 +131,7 @@ typecompatible(struct type *t1, struct type *t2) case TYPEPOINTER: goto derived; case TYPEARRAY: if (!t1->incomplete && !t2->incomplete && t1->size != t2->size) if (!t1->incomplete && !t2->incomplete && t1->size && t2->size && t1->size != t2->size) [message trimmed]
From Nihal Jere to ~mcf/cproc
--- qbe.c | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/qbe.c b/qbe.c index b0134cc..af7a050 100644 --- a/qbe.c +++ b/qbe.c @@ -276,11 +276,10 @@ funcalloc(struct func *f, struct decl *d) assert(!d->type->incomplete); struct value *dynsize; /* VLA, so output the size */ [message trimmed]