emit_group_store vs complex
Tue Aug 8 00:28:00 GMT 2000
Richard Henderson <firstname.lastname@example.org> writes:
> The problem is that emit_group_store forces /s set, no matter
> what the incoming memory says it's supposed to be. This is
> clearly a recipe for disaster. And there's a comment that
> says that the reason we make that change is because store_bit_field
> will abort otherwise. And as far as I can tell, there's no
> reason for store_bit_field to do that except to try to catch
> presumed bugs elsewhere in the compiler.
Hmmm. Can anyone say what MEM_IN_STRUCT_P is _for_?
I can't think of anything, other than alias analysis which is surely
much better handled by the frontend. What impact could
MEM_IN_STRUCT_P possibly have on the generated code?
- Geoffrey Keating <email@example.com>
More information about the Gcc-patches