Re: [Tinycc-devel] [PATCH] When handling '.' operator, cope with VT_LLOCAL

[Edmund Grimley Evans]

Michael Matz <address@hidden>:

> Do you have a testcase?

I made the change after something in abitest failed with the arm64
back end, but with a newer version than the one I sent to the list.

> is: this patches only one place where lvalue_type is called (i.e.
> where something on the stack is lvalueized again).

The function lvalue_type isn't just used to "lvalueise" things, and
there may be places where the stack is lvaluised without calling
lvalue_type ...

> Why are the
> others trivially correct and don't need such handling?

I expect there are many bits of code that are wrong but which happen
never to receive the values that they can't handle.

How many parts of tccgen.c can correctly handle a VT_REF, do you
think? :-)

> Also,
> conceptually, I might have a problem with this: it fixes up things
> after they went wrong.  For instance, why isn't the problem in
> gen_op?  I mean, one invariant of gen_op (when called with
> non-optimizable args) is that it leaves a non-lvalue on the stack,
> so the code in unary() is correct as is, for those cases.  So,
> wouldn't it be better if the lvalue-to-rvalue conversion would
> happen also with gen_op(+,0)?

The advantage of making gen_op always convert to an rvalue is that
other code would have to worry about fewer cases.

The only disadvantage that I can think of is that certain expressions
which would cause GCC to warn that "value computed is not used" would
not get optimised.

So, if you're suggesting that gen_op should be modified to always
convert to an rvalue, then I think I agree. Shall we do that instead?

Since I probably still have a test case to hand, should I propose an
alternative patch that fixes my problem by modifying gen_op?

Edmund