Michael Matz <[email protected]>: > 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 _______________________________________________ Tinycc-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/tinycc-devel
