Richard Sandiford schrieb:
> Georg-Johann Lay writes:
>> Richard Henderson schrieb:
>>> On 03/25/2011 05:41 AM, Georg-Johann Lay wrote:
> On 03/22/2011 06:48 PM, Richard Henderson wrote:
>
>> Ok. Watch out for other target problems this week.
libgcc fails to build for avr (SVN 17
Georg-Johann Lay writes:
> Richard Henderson schrieb:
>> On 03/25/2011 05:41 AM, Georg-Johann Lay wrote:
On 03/22/2011 06:48 PM, Richard Henderson wrote:
> Ok. Watch out for other target problems this week.
>>> libgcc fails to build for avr (SVN 171446)
>>>
>>> ../../../../../gcc.gn
Richard Henderson schrieb:
> On 03/25/2011 05:41 AM, Georg-Johann Lay wrote:
>>> On 03/22/2011 06:48 PM, Richard Henderson wrote:
>>>
Ok. Watch out for other target problems this week.
>> libgcc fails to build for avr (SVN 171446)
>>
>> ../../../../../gcc.gnu.org/trunk/libgcc/../gcc/libgcc2.c
On 03/30/2011 01:53 AM, Richard Sandiford wrote:
> This comes back to the point that we really should know up-front what
> modes op0 and op1 actually have. (The thing I left as a future clean-up.)
> Until then, the process implemented by yesterday's patch was supposed to be:
>
>- work out wha
Richard Henderson writes:
> On 03/29/2011 06:21 AM, Richard Sandiford wrote:
>> - enum machine_mode mode0 = insn_data[(int) icode].operand[1].mode;
>> - enum machine_mode mode1 = insn_data[(int) icode].operand[2].mode;
>> - enum machine_mode tmp_mode;
>> + enum machine_mode xmode0 = insn_data[
On 03/29/2011 06:21 AM, Richard Sandiford wrote:
> - enum machine_mode mode0 = insn_data[(int) icode].operand[1].mode;
> - enum machine_mode mode1 = insn_data[(int) icode].operand[2].mode;
> - enum machine_mode tmp_mode;
> + enum machine_mode xmode0 = insn_data[(int) icode].operand[1].mode;
> +
Mikael Pettersson writes:
> > gcc/
> >PR rtl-optimization/48332
> >* optabs.c (expand_binop_directly): Set xmodeN to the target-mandated
> >mode of input operand N and modeN to its actual mode.
>
> Thanks, this allowed me to build gcc-4.7 as a cross to m68k-linux again.
Good to he
Richard Sandiford writes:
> Mikael Pettersson writes:
> > Richard Sandiford writes:
> > > Andreas Krebbel writes:
> > > > On 03/22/2011 06:48 PM, Richard Henderson wrote:
> > > >
> > > >> Ok. Watch out for other target problems this week.
> > > >
> > > > This unfortunately broke bo
Mikael Pettersson writes:
> Richard Sandiford writes:
> > Andreas Krebbel writes:
> > > On 03/22/2011 06:48 PM, Richard Henderson wrote:
> > >
> > >> Ok. Watch out for other target problems this week.
> > >
> > > This unfortunately broke bootstrap on s390.
> >
> > This is PR 48263. Sin
Richard Sandiford writes:
> Andreas Krebbel writes:
> > On 03/22/2011 06:48 PM, Richard Henderson wrote:
> >
> >> Ok. Watch out for other target problems this week.
> >
> > This unfortunately broke bootstrap on s390.
>
> This is PR 48263. Since it seems to be affecting several targets,
On 03/25/2011 11:49 AM, Richard Henderson wrote:
> On 03/25/2011 10:51 AM, Richard Sandiford wrote:
>> Thanks. I think it needs to be s/!= 4/>= 6/ though, so that
>> match_scratches still work when 6 operands really are passed in.
>
> For the record, I audited all setmem and movmem patterns.
>
>
On 03/25/2011 10:51 AM, Richard Sandiford wrote:
> Thanks. I think it needs to be s/!= 4/>= 6/ though, so that
> match_scratches still work when 6 operands really are passed in.
For the record, I audited all setmem and movmem patterns.
There are is only one that uses 6 operands: i386.
There are
Richard Sandiford writes:
> Er, >= 4 even...
Or not, *sigh*. Time I went home...
Richard
Richard Sandiford writes:
> Richard Henderson writes:
>> This is due to a miscommunication between the middle-end and the backend
>> about how many arguments the setmemhi pattern takes.
>>
>> (define_expand "setmemhi"
>> [(parallel [(set (match_operand:BLK 0 "memory_operand" "")
>>
Richard Henderson writes:
> This is due to a miscommunication between the middle-end and the backend
> about how many arguments the setmemhi pattern takes.
>
> (define_expand "setmemhi"
> [(parallel [(set (match_operand:BLK 0 "memory_operand" "")
>(match_operand 2 "const_int_
On 03/25/2011 05:41 AM, Georg-Johann Lay wrote:
>> On 03/22/2011 06:48 PM, Richard Henderson wrote:
>>
>>> Ok. Watch out for other target problems this week.
>
> libgcc fails to build for avr (SVN 171446)
>
> ../../../../../gcc.gnu.org/trunk/libgcc/../gcc/libgcc2.c: In function
> '__negdi2':
> .
Georg-Johann Lay schrieb:
> Andreas Krebbel schrieb:
>> On 03/22/2011 06:48 PM, Richard Henderson wrote:
>>
>>> Ok. Watch out for other target problems this week.
>
> libgcc fails to build for avr (SVN 171446)
>
> ../../../../../gcc.gnu.org/trunk/libgcc/../gcc/libgcc2.c: In function
> '__negdi2'
Andreas Krebbel schrieb:
> On 03/22/2011 06:48 PM, Richard Henderson wrote:
>
>> Ok. Watch out for other target problems this week.
libgcc fails to build for avr (SVN 171446)
../../../../../gcc.gnu.org/trunk/libgcc/../gcc/libgcc2.c: In function
'__negdi2':
../../../../../gcc.gnu.org/trunk/libgc
On 03/24/2011 05:13 AM, Richard Sandiford wrote:
> gcc/
> PR rtl-optimization/48263
> * optabs.c (expand_binop_directly): Reinstate convert_modes code
> and original commutative_p handling. Use maybe_gen_insn.
Ok.
r~
This showed up as a warning during the h8300 build I did this morning.
I've no idea why it wasn't caught during the x86_64, ARM and MIPS testing.
Bootstrapped & regression-tested on x86_64-linux-gnu. Installed as obvious.
Richard
gcc/
* builtins.c (expand_movstr): Fix endp == 1 adjustm
Richard Sandiford writes:
> Andreas Krebbel writes:
>> On 03/22/2011 06:48 PM, Richard Henderson wrote:
>>
>>> Ok. Watch out for other target problems this week.
>>
>> This unfortunately broke bootstrap on s390.
>
> This is PR 48263. Since it seems to be affecting several targets,
> and since m
Andreas Krebbel writes:
> On 03/22/2011 06:48 PM, Richard Henderson wrote:
>
>> Ok. Watch out for other target problems this week.
>
> This unfortunately broke bootstrap on s390.
This is PR 48263. Since it seems to be affecting several targets,
and since my bootstrap seems to be taking a looong
On 03/22/2011 06:48 PM, Richard Henderson wrote:
> Ok. Watch out for other target problems this week.
This unfortunately broke bootstrap on s390.
An unrecognizable insns is generated:
(insn 22 21 23 4 (set (reg/v:DI 44 [ end])
(mult:DI (sign_extend:DI (mem/s/j:SI (plus:SI (reg/v/f:SI 47 [ f
"Anatoly Sokolov" writes:
> This patch casue ICE on H8300 target:
This is due to jump_address_operand checking the wrong mode.
The predicate is:
(define_predicate "jump_address_operand"
(match_code "reg,mem")
{
if (GET_CODE (op) == REG)
return mode == Pmode;
[...]
}
but "mode" is the
Hi.
From: "Richard Henderson"
Sent: Tuesday, March 22, 2011 8:48 PM
Ok. Watch out for other target problems this week.
This patch casue ICE on H8300 target:
make[4]: Entering directory
`/home/aesok/h83001/build/h8300-elf/h8300h/libgcc'
# If this is the top-level multilib, build all t
On 03/22/2011 08:08 AM, Richard Sandiford wrote:
>>> + for (i = 0; i + 1 < nops; i++)
>>> +if (ops[i].commutative < MAX_EXPAND_OPERANDS
>>> + && swap_commutative_operands_with_target
>>> (ops[ops[i].commutative].value,
>>> + ops[i].value,
Richard Henderson writes:
>> * reload.c (find_reloads_address_1): Use insn_operand_matches.
>> * reload1.c (gen_reload): Likewise.
>
> All the bits that just use insn_operand_matches are approved.
> You can commit those first if you like to reduce the patch size.
OK, thanks, here's what
On 03/19/2011 12:52 PM, Richard Sandiford wrote:
> Given the mode stuff above, I've tried to be quite draconian as far
> as caller-provided modes go. I think the caller really should know
> what mode they're dealing with. The one case where I had to hold
> back a bit was create_convert_operand_fr
On 03/17/2011 09:32 AM, Richard Sandiford wrote:
> This patch adds a few helper functions for dealing with optabs:
>
> - insn_operand_matches (ICODE, OPNO, X)
> - (maybe_)legitimize_insn_target (ICODE, OPNO, TARGET, MODE)
> - (maybe_)legitimize_insn_source (ICODE, OPNO, SOURCE, MODE)
Cool.
Why p
29 matches
Mail list logo
