This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
Richard Henderson <rth@redhat.com> writes: > On Wed, May 29, 2002 at 04:24:43PM -0700, Dan Nicolaescu wrote: > > Another failing test, global pointer vars that point to objects that > > have "char" fields are put in alias set 0 (this might be OK though). > > I wouldn't expect alias sets to have anything to do with this. > In fact, all these tests should be run at -O1 so that we don't > use alias sets. > > We're trying to test alias resolution based on location within > a larger object, not whether types of the accessed objects differ. OK, I think I know what's going on. Here is a new set of testcases, in C this time, no reason to be in C++.
Attachment:
alias-global.c
Description: alias-global.c
When compiling fail_c and fail_i nonoverlapping_memrefs_p (x, y) returns false for x = (mem/s/j:QI (plus:SI (reg/v/f:SI 107) (const_int 8 [0x8])) [0 <variable>.f1+0 S1 A64]) ^^^^^^^^^^^^ this is probably a problem y = (mem/f:SI (lo_sum:SI (reg/f:SI 110) (symbol_ref:SI ("fs1"))) [0 fs1+0 S4 A32]) because decl_for_component_ref (exprx) is NULL. so true_dependence returns 1. If fail_i is compiled with -fstrict-aliasing true_dependence for the above mems returns false because of the DIFFERENT_ALIAS_SETS_P test. If fail_c is compiled with -fstrict-aliasing true_dependence for the above mems returns true because fs1.f1 is in alias set zero, so DIFFERENT_ALIAS_SETS_P can't return true as in fail_i.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |