Your June 7 change to expand_expr

Richard Kenner kenner@vlsi1.ultra.nyu.edu
Wed Jul 1 05:54:00 GMT 1998


    I disagree that setting MEM_IN_STRUCT_P is less likely to generate bad
    code.

    MEM_IN_STRUCT_P only comes into play when memory references have
    *different* values for MEM_IN_STRUCT_P *and* when the reference
    with MEM_IN_STRUCT_P is a varying address and the reference w/o
    MEM_IN_STRUCT_P is a non-varying address.

    And since most references to do not have MEM_IN_STRUCT_P set, you've
    *increased* the number of memory references that you do not conflict
    with -- which seems less safe to me.

But the question is not the total number of references that can
potentially conflict but instead the number that actually conflict.

I agree this is very empirical and I was relating my empirical
evidence, which is that I've seen more bugs caused by it *not* being
set then from it *being* set.  Indeed, this is the first in the latter
category I can recall, though we've always known they are theoretically
possible.

    But is the integer these things point to part of an aggregate?  That
    is the key question you have to answer before setting MEM_IN_STRUCT_P.

Right, but you can't possibly know.

    Right.  Presumably setting MEM_IN_STRUCT_P is OK and correct for your
    test, but I'm not sure it's always the right thing to do.  I think you
    need to look more closely at the underlying types (which I would think
    should still be available in expr.c).

I don't see how the types help.  I don't know C++, but consider the
following in Ada (should be clear enough to understand):

	i, j: integer;
	arr: array (1..5) of integer;
	foo: integer renames arr(i);
	bar: integer renames j;

foo and bar have exactly the same type and are used in exactly the
same way, but one points into an aggregate and the other to a scalar.
How could expr.c tell them apart?

    MEM_IN_STRUCT_P only applies if one reference has it and the other
    does not *and* the reference with MEM_IN_STRUCT_P is a varying address
    and the other is at a constant address.

It's not hard to make up a case where that will occur.



More information about the Gcc-bugs mailing list