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: combine/dce patch for PR36003, PR42575


On 06/24/2010 07:58 PM, Hans-Peter Nilsson wrote:
> On Tue, 22 Jun 2010, Bernd Schmidt wrote:
>> PR36003 is a problem where enabling pass_fast_rtl_byte_dce causes
>> crashes in a cris compiler when the host is 64 bit.  combine produces an
>> insn of the form
>>
>> (set (cc0)
>>         (zero_extract:DI (subreg:SI (reg/v:DI 38 [ high ]) 0)
>>             (const_int 1 [0x1])
>>             (const_int 0 [0x0]))) 16 {*btst} (nil))
>>
>> The cris backend accepts this
> 
> Look again!

Well, I was working with the revision mentioned in the PR so that I
could reproduce the problem.

> I find that reference in rtl.texi so IIUC is regarding valid
> RTX, not what a port has to assert or refuse.  In this respect,
> the port was consistent with the compare insns; there's no mode
> on the compare, just the operands of the compare.  I can't find
> whatever documentation specified this, maybe I found nothing at
> the time was just using the m68k-port as effective
> documentation, which had the same modeless zero_extract
> assigning to cc0 *at the time*.  Whatever, all this *has*
> changed.  Water under the bridges...

I'm not actually sure what you're trying to say here.  I wasn't
criticizing the cris backend, although I think it's good that it now has
a mode on the zero_extract since that'll avoid such problems in the future.


Bernd


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