This is the mail archive of the gcc-bugs@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]

[Bug target/79619] store via pointer obtained from alternate address space offset 0 dropped


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79619

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
Note that this fix doesn't properly ensure that ADDR_SPACE_CONVERT of 0 from
generic to non-generic address space "magically changes" from nothing_id to
nonlocal_id, thus if you hide the constant:

void bug(void)
{
  unsigned long ptr = 0;
  *(*(char*__seg_fs*)ptr) = 1;                                                  
} 

you get, with -O -fno-tree-ccp -fno-tree-forwprop

  <bb 2> [0.00%]:
  # PT = null
  _2 = MEM[(char * <address-space-1> *)0B];
  *_2 = 1;

again (-fno-tree-ccp -fno-tree-forwprop avoid propagating the literal zero
before points-to analysis runs, CSE later does this but it's too late).

After points-to we see

  <bb 2> [0.00%]:
  ptr_3 = 0;
  # PT = null
  _1 = (char * <address-space-1> *) ptr_3;
  # PT = null
  _2 = *_1;
  *_2 = 1;

note this isn't an ADDR_SPACE_CONVERT_EXPR but a NOP_EXPR (integer to pointer
conversion).  points-to tracks pointers through integers (not treating
integers as general escape points) which then means that when using
non-generic address-spaces you have to treat integer zero as pointing to
any global...  that's quite pessimizing for example for a memset (.., 0, ...).

IMHO it's advisable to not use objects at address zero even in non-generic
address-spaces.

As a workaround for the above we could simply treat non-generic address-spaces
as always pointing to anything (disabling PTA for non-generic address-space
pointers).  Or only do this at such conversion sites.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]