This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Is the check performed on the return value from force_const_mem in the plus_constant function correct?
- From: Andrew Bennett <Andrew dot Bennett at imgtec dot com>
- To: "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Tue, 2 Jun 2015 11:22:16 +0000
- Subject: Is the check performed on the return value from force_const_mem in the plus_constant function correct?
- Authentication-results: sourceware.org; auth=none
Hi,
I am debugging a segmentation fault when compiling some code for MIPS. The
segmentation fault occurs in the plus_constant function in explow.c when it
tries to update a constant pool value. The offending code is below:
case MEM:
/* If this is a reference to the constant pool, try replacing it with
a reference to a new constant. If the resulting address isn't
valid, don't return it because we have no way to validize it. */
if (GET_CODE (XEXP (x, 0)) == SYMBOL_REF
&& CONSTANT_POOL_ADDRESS_P (XEXP (x, 0)))
{
tem = plus_constant (mode, get_pool_constant (XEXP (x, 0)), c);
tem = force_const_mem (GET_MODE (x), tem);
if (memory_address_p (GET_MODE (tem), XEXP (tem, 0)))
return tem;
}
The code fails for MIPS because its cannot_force_const_mem target function does
not allow constants (so that the move expanders can deal with them later on),
this then causes the force_const_mem function to return a NULL_RTX.
What I can't understand is why the memory_address_p function is used to check
the result from force_const_mem? From looking at the return values from
force_const_mem the only possibilies are what looks like a valid memory rtx,
or a NULL_RTX. Also there is no other instances in the code where this happens.
I was therefore wondering is anyone knew why the check is done in this manner?
I think the fix should be to just check that the tem variable is not a NULL_RTX.
I was also wondering if anyone had any issues/objections to checking the result
in this manner?
Many thanks,
Andrew