This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug target/79619] store via pointer obtained from alternate address space offset 0 dropped
- From: "rguenth at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Mon, 20 Feb 2017 10:21:33 +0000
- Subject: [Bug target/79619] store via pointer obtained from alternate address space offset 0 dropped
- Auto-submitted: auto-generated
- References: <bug-79619-4@http.gcc.gnu.org/bugzilla/>
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.