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]

Re: PATCH: PR middle-end/49721: convert_memory_address_addr_space may generate invalid new insns


On Thu, Jul 28, 2011 at 8:32 PM, H.J. Lu <hjl.tools@gmail.com> wrote:

>>>>>>> > ?convert_memory_address_addr_space has a special PLUS/MULT case for
>>>>>>> > ?POINTERS_EXTEND_UNSIGNED< ?0. ?It turns out that it is also needed
>>>>>>> > ?for all Pmode != ptr_mode cases. ?OK for trunk?
>>>>>>> > ?2011-06-11 ?H.J. Lu ?<hongjiu.lu@intel.com>
>>>>>>> >
>>>>>>> > ?? ? ? ?PR middle-end/47727
>>>>>>> > ?? ? ? ?* explow.c (convert_memory_address_addr_space): Permute the
>>>>>>> > ?? ? ? ?conversion and addition if one operand is a constant.
>>>>>>>
>>>>>>> Do we still need this patch? With recent target changes the testcase
>>>>>>> from PR can be compiled without problems with a gcc from an unpatched
>>>>>>> trunk.
>>>>>>
>>>>>> Given the communication difficulties, I hope not...
>>>>>>
>>>>>> Paolo
>>>>>>
>>>>>
>>>>> Here is the updated patch. ?OK for trunk?
>>>>
>>>> Did you see the question two levels up the thread you are replying to?
>>>>
>>>
>>> The patch is for
>>>
>>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49721
>>>
>>> I changed the thread subject.
>>
>> Please add testcase to see the patch in action.
>>
>
> I haven't found a testcase yet. ?The problem was discovered in
> this thread:
>
> http://gcc.gnu.org/ml/gcc-patches/2011-07/msg01065.html

This was before x32 could handle SImode addresses. With recent x86
target work, this is no more true, and SImode and DImode addresses are
first-class citizens as far as x32 backend is concerned. Please note
that original testcase (that this whole patch is all about) now
compiles without problems. Also, middle end is shared with at least
two ptr_mode != Pmode targets, and they all work well. So, to see what
makes x32 special, we need a testcase that breaks _WITHOUT_ your
proposed patch. Without testcase, nobody can analyze your approach and
tell if the approach is the right one, if this is in fact target
problem, or indeed a middle-end problem.

And there is no point to flood the mainling-list with patches.

Uros.


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