> Is the following patch a reasonable fix for this case?

The lines should be moved to within the first branch of the subsequent "if". 
They aren't needed if the second branch is taken because, in this case, we're 
back to the usual caller-copied scheme where we pass the address of the copy.

> I assume I should add similar code inside emit_library_call_value_1.

Yes, we need the same treatment for 'val' in the MEM_P (val) && !must_copy case 
as the one applied in emit_block_move_hints.


But these problems show that there is a slight discrepancy between what dse.c 
really needs (is the address of the variable taken?) and what may_be_aliased 
answers (might the variable be indirectly modified?).  Another viewpoint is to 
say that there is a slight discrepancy between Tree and RTL level when it comes 
to the address-taken property.  Not clear what to do about it so I think that 
we should try this kludgy way and see how it fares.

-- 
Eric Botcazou

Reply via email to