Re: i386 define_asm_attributes question
On Tue, May 8, 2012 at 1:28 AM, Jan Hubicka wrote: > The idea here was originally to prevent LOOP instruction to get out of bounds. > ASM statement even if they are single line may be arbitrary long and thus can > run out of the limits. Arbitrary long, but interrupted by semi-colons? From the define_asm_attributes documentation (see http://gcc.gnu.org/onlinedocs/gccint/Tagging-Insns.html): "A specification for a length attribute is handled specially. The way to compute the length of an asm insn is to multiply the length specified in the expression define_asm_attributes by the number of machine instructions specified in the asm statement, determined by counting the number of semicolons and newlines in the string. Therefore, the value of the length attribute specified in a define_asm_attributes should be the maximum possible length of a single machine instruction. " Ciao! Steven
Re: Deprecate 32-bits HP-PA for GCC 4.8?
On 05/07/2012 07:33 PM, Steven Bosscher wrote: > I think it's reasonable to assume that most users of HP-UX10 on > machines with PA-RISC 2.0 support will have upgraded to HP-UX 11.11 or > later. While this may be true indeed, ... > 4. 32-bits HP-PA uses the SOM binary object format, i.e. it is a > non-ELF target (64-bits HP-PA is ELF). ... 32bit (SOM) still is the default output of HP-cc with HP-UX 11.31 on HP-PA. Actually, end of support for HP-UX 11.31 on HP 9000 is planned for end of 2020 now [1]. [1] http://www.hp.com/go/hpuxsupportmatrix /haubi/
Re: Deprecate 32-bits HP-PA for GCC 4.8?
Steven Bosscher wrote: > 2. HP-UX 10 is also the last target that only supports SJLJ exceptions. Hmm, SPU also supports only SJLJ exceptions ... Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE ulrich.weig...@de.ibm.com
Re: i386 define_asm_attributes question
> On Tue, May 8, 2012 at 1:28 AM, Jan Hubicka wrote: > > The idea here was originally to prevent LOOP instruction to get out of > > bounds. > > ASM statement even if they are single line may be arbitrary long and thus > > can > > run out of the limits. > > Arbitrary long, but interrupted by semi-colons? From the > define_asm_attributes documentation (see > http://gcc.gnu.org/onlinedocs/gccint/Tagging-Insns.html): > > "A specification for a length attribute is handled specially. The way > to compute the length of an asm insn is to multiply the length > specified in the expression define_asm_attributes by the number of > machine instructions specified in the asm statement, determined by > counting the number of semicolons and newlines in the string. > Therefore, the value of the length attribute specified in a > define_asm_attributes should be the maximum possible length of a > single machine instruction. " Yep, still it is possible to use gas's directive to put there more than 128 bytes without having single ; in it producing an error when using loop instruction. Back then it seemed to be better safe than sorry. But these days given that we do not output nops, I am happy with the 15 byte default Honza > > Ciao! > Steven
Re: Register constraints + and =
On 04/05/12 19:48, Ian Lance Taylor wrote:
The i386 rep_movqi insn is an example:
(define_insn "*rep_movqi"
[(set (match_operand:P 2 "register_operand" "=c") (const_int 0))
(set (match_operand:P 0 "register_operand" "=D")
(plus:P (match_operand:P 3 "register_operand" "0")
(match_operand:P 5 "register_operand" "2")))
(set (match_operand:P 1 "register_operand" "=S")
(plus:P (match_operand:P 4 "register_operand" "1") (match_dup 5)))
(set (mem:BLK (match_dup 3))
(mem:BLK (match_dup 4)))
(use (match_dup 5))]
"!(fixed_regs[CX_REG] || fixed_regs[SI_REG] || fixed_regs[DI_REG])"
"%^rep{%;} movsb"
[(set_attr "type" "str")
(set_attr "prefix_rep" "1")
(set_attr "memory" "both")
(set_attr "mode" "QI")])
Thanks for the discussion on this which was enlightening.
The rep_movqi rule seems scarily like our block copy instruction.
By looking at it, the question that arises is, why the (use (match_dup
5))? I thought this was used to tell gcc that an operand was going to be
used in a way not specified by the rtl but operand 5 is specified
elsewhere in the rtl so gcc doesn't seem to need that (use ...) rule. Is
this redundant or not?
--
PMatos
Re: Deprecate 32-bits HP-PA for GCC 4.8?
On Tue, May 8, 2012 at 4:56 AM, Ulrich Weigand wrote: > Steven Bosscher wrote: > >> 2. HP-UX 10 is also the last target that only supports SJLJ exceptions. > > Hmm, SPU also supports only SJLJ exceptions ... IIRC the main reason is because SJLJ exceptions produced smaller binary size. Though I wonder if this should not be looked at again to see if dwarf2 eh_frame produces smaller now. Thanks, Andrew Pinski
Re: Register constraints + and =
"Paulo J. Matos" writes:
> On 04/05/12 19:48, Ian Lance Taylor wrote:
>
>> The i386 rep_movqi insn is an example:
>>
>> (define_insn "*rep_movqi"
>>[(set (match_operand:P 2 "register_operand" "=c") (const_int 0))
>> (set (match_operand:P 0 "register_operand" "=D")
>> (plus:P (match_operand:P 3 "register_operand" "0")
>> (match_operand:P 5 "register_operand" "2")))
>> (set (match_operand:P 1 "register_operand" "=S")
>> (plus:P (match_operand:P 4 "register_operand" "1") (match_dup 5)))
>> (set (mem:BLK (match_dup 3))
>> (mem:BLK (match_dup 4)))
>> (use (match_dup 5))]
>>"!(fixed_regs[CX_REG] || fixed_regs[SI_REG] || fixed_regs[DI_REG])"
>>"%^rep{%;} movsb"
>>[(set_attr "type" "str")
>> (set_attr "prefix_rep" "1")
>> (set_attr "memory" "both")
>> (set_attr "mode" "QI")])
>>
>
> Thanks for the discussion on this which was enlightening.
> The rep_movqi rule seems scarily like our block copy instruction.
> By looking at it, the question that arises is, why the (use (match_dup
> 5))? I thought this was used to tell gcc that an operand was going to
> be used in a way not specified by the rtl but operand 5 is specified
> elsewhere in the rtl so gcc doesn't seem to need that (use ...)
> rule. Is this redundant or not?
I believe the (use (match_dup 5)) is redundant.
The insn used to look like this:
(define_insn "rep_movqi"
[(set (match_operand:SI 2 "register_operand" "=c") (const_int 0))
(use (match_operand:SI 5 "register_operand" "2"))
(set (match_operand:SI 0 "register_operand" "=D")
(plus:SI (match_operand:SI 3 "address_operand" "0") (match_dup 5)))
(set (match_operand:SI 1 "register_operand" "=S")
(plus:SI (match_operand:SI 4 "address_operand" "1") (match_dup 5)))
(set (mem:BLK (match_dup 3))
(mem:BLK (match_dup 4)))
(use (reg:SI 19))]
Here the (use (match_operand:SI 5) ...) appeared early to specify the
predicate and constraints for operand 5 and to make it clear that it was
just the input side of operand 2.
This change
http://gcc.gnu.org/ml/gcc-patches/2000-08/msg00877.html
Fri Sep 29 13:20:42 MET DST 2000 Jan Hubicka
* recog.c (recog_memoized): Rename to recog_memoized_1.
* recog.h (recog_memoized): Rename to recog_memoized_1.
(recog_memoized): New macro.
* rtl.h (single_set): Rename to single_set_1
(single_set): New macro.
* rtlanal.c (single_set): Rename to single_set_1; expect clobbers
to be last.
* i386.md (strmovsi_1, strmovhi_1 strmovqi_1):
Do not use match_dup of input operands at outputs.
Use register_operand for memory expression.
(rep_movsi): Put use last, canonicalize.
Use register_operand for memory expression.
(rep_movqi): Put use last.
Use register_operand for memory expression.
(strsetsi_1, strset_hi_1, strsetqi_1): Do not use match_dup
of input operands at outputs. Use register_operand for memory
expression.
(rep_stossi): Put use last; canonicalize; fix match_dup in
the address expression
(rep_stosqi): Likewise.
(memcmp expander): Update calls.
(cmpstrsi_nz_1, cmpstrsi_1, strlensi_1): Avoid match_dups in
the clobbers.
* i386.md (fp_jcc_3, fp_jcc_4, jp_fcc_5): if_then_else operand is
VOIDmode.
(fp_jcc_4, fp_jcc_3): Refuse unordered comparisons.
put the predicate and constraints on the first use of operand 5, and
added the (use (match_dup 5)) at the end of the insn. I think that that
change should have simply dropped the (use (match_dup 5)), as it was no
longer needed.
Ian
Re: Register constraints + and =
> "Paulo J. Matos" writes:
>
> > On 04/05/12 19:48, Ian Lance Taylor wrote:
> >
> >> The i386 rep_movqi insn is an example:
> >>
> >> (define_insn "*rep_movqi"
> >>[(set (match_operand:P 2 "register_operand" "=c") (const_int 0))
> >> (set (match_operand:P 0 "register_operand" "=D")
> >> (plus:P (match_operand:P 3 "register_operand" "0")
> >>(match_operand:P 5 "register_operand" "2")))
> >> (set (match_operand:P 1 "register_operand" "=S")
> >> (plus:P (match_operand:P 4 "register_operand" "1") (match_dup 5)))
> >> (set (mem:BLK (match_dup 3))
> >>(mem:BLK (match_dup 4)))
> >> (use (match_dup 5))]
> >>"!(fixed_regs[CX_REG] || fixed_regs[SI_REG] || fixed_regs[DI_REG])"
> >>"%^rep{%;} movsb"
> >>[(set_attr "type" "str")
> >> (set_attr "prefix_rep" "1")
> >> (set_attr "memory" "both")
> >> (set_attr "mode" "QI")])
> >>
> >
> > Thanks for the discussion on this which was enlightening.
> > The rep_movqi rule seems scarily like our block copy instruction.
> > By looking at it, the question that arises is, why the (use (match_dup
> > 5))? I thought this was used to tell gcc that an operand was going to
> > be used in a way not specified by the rtl but operand 5 is specified
> > elsewhere in the rtl so gcc doesn't seem to need that (use ...)
> > rule. Is this redundant or not?
>
> I believe the (use (match_dup 5)) is redundant.
>
> The insn used to look like this:
>
> (define_insn "rep_movqi"
>[(set (match_operand:SI 2 "register_operand" "=c") (const_int 0))
> (use (match_operand:SI 5 "register_operand" "2"))
> (set (match_operand:SI 0 "register_operand" "=D")
> (plus:SI (match_operand:SI 3 "address_operand" "0") (match_dup 5)))
> (set (match_operand:SI 1 "register_operand" "=S")
> (plus:SI (match_operand:SI 4 "address_operand" "1") (match_dup 5)))
> (set (mem:BLK (match_dup 3))
> (mem:BLK (match_dup 4)))
> (use (reg:SI 19))]
>
> Here the (use (match_operand:SI 5) ...) appeared early to specify the
> predicate and constraints for operand 5 and to make it clear that it was
> just the input side of operand 2.
>
> This change
>
>
> http://gcc.gnu.org/ml/gcc-patches/2000-08/msg00877.html
>
>
> Fri Sep 29 13:20:42 MET DST 2000 Jan Hubicka
>
> * recog.c (recog_memoized): Rename to recog_memoized_1.
> * recog.h (recog_memoized): Rename to recog_memoized_1.
> (recog_memoized): New macro.
> * rtl.h (single_set): Rename to single_set_1
> (single_set): New macro.
> * rtlanal.c (single_set): Rename to single_set_1; expect clobbers
> to be last.
>
> * i386.md (strmovsi_1, strmovhi_1 strmovqi_1):
> Do not use match_dup of input operands at outputs.
> Use register_operand for memory expression.
> (rep_movsi): Put use last, canonicalize.
> Use register_operand for memory expression.
> (rep_movqi): Put use last.
> Use register_operand for memory expression.
> (strsetsi_1, strset_hi_1, strsetqi_1): Do not use match_dup
> of input operands at outputs. Use register_operand for memory
> expression.
> (rep_stossi): Put use last; canonicalize; fix match_dup in
> the address expression
> (rep_stosqi): Likewise.
> (memcmp expander): Update calls.
> (cmpstrsi_nz_1, cmpstrsi_1, strlensi_1): Avoid match_dups in
> the clobbers.
>
> * i386.md (fp_jcc_3, fp_jcc_4, jp_fcc_5): if_then_else operand is
> VOIDmode.
> (fp_jcc_4, fp_jcc_3): Refuse unordered comparisons.
>
> put the predicate and constraints on the first use of operand 5, and
> added the (use (match_dup 5)) at the end of the insn. I think that that
> change should have simply dropped the (use (match_dup 5)), as it was no
> longer needed.
I believe I added use to make it clear that the insn does some other stuff with
operand 5
than just adding it to edx, i.e. that it specify the size of block copied.
Without this it would be theoretically possible to change value of ecx when we
need
to do something with edx (i.e. if another value is later added to ecx, the
optimizer
may add the value to ecx before the memcpy)
Honza
Re: Deprecate 32-bits HP-PA for GCC 4.8?
On Tue, May 8, 2012 at 1:56 PM, Ulrich Weigand wrote: > Steven Bosscher wrote: > >> 2. HP-UX 10 is also the last target that only supports SJLJ exceptions. > > Hmm, SPU also supports only SJLJ exceptions ... Then why is force_sjlj_exceptions not set for it? Ciao! Steven
Re: Register constraints + and =
Jan Hubicka writes:
>> "Paulo J. Matos" writes:
>>
>> > On 04/05/12 19:48, Ian Lance Taylor wrote:
>> >
>> >> The i386 rep_movqi insn is an example:
>> >>
>> >> (define_insn "*rep_movqi"
>> >>[(set (match_operand:P 2 "register_operand" "=c") (const_int 0))
>> >> (set (match_operand:P 0 "register_operand" "=D")
>> >> (plus:P (match_operand:P 3 "register_operand" "0")
>> >> (match_operand:P 5 "register_operand" "2")))
>> >> (set (match_operand:P 1 "register_operand" "=S")
>> >> (plus:P (match_operand:P 4 "register_operand" "1") (match_dup
>> >> 5)))
>> >> (set (mem:BLK (match_dup 3))
>> >> (mem:BLK (match_dup 4)))
>> >> (use (match_dup 5))]
>> >>"!(fixed_regs[CX_REG] || fixed_regs[SI_REG] || fixed_regs[DI_REG])"
>> >>"%^rep{%;} movsb"
>> >>[(set_attr "type" "str")
>> >> (set_attr "prefix_rep" "1")
>> >> (set_attr "memory" "both")
>> >> (set_attr "mode" "QI")])
>> >>
>> >
>> > Thanks for the discussion on this which was enlightening.
>> > The rep_movqi rule seems scarily like our block copy instruction.
>> > By looking at it, the question that arises is, why the (use (match_dup
>> > 5))? I thought this was used to tell gcc that an operand was going to
>> > be used in a way not specified by the rtl but operand 5 is specified
>> > elsewhere in the rtl so gcc doesn't seem to need that (use ...)
>> > rule. Is this redundant or not?
>>
>> I believe the (use (match_dup 5)) is redundant.
>>
>> The insn used to look like this:
>>
>> (define_insn "rep_movqi"
>>[(set (match_operand:SI 2 "register_operand" "=c") (const_int 0))
>> (use (match_operand:SI 5 "register_operand" "2"))
>> (set (match_operand:SI 0 "register_operand" "=D")
>> (plus:SI (match_operand:SI 3 "address_operand" "0") (match_dup 5)))
>> (set (match_operand:SI 1 "register_operand" "=S")
>> (plus:SI (match_operand:SI 4 "address_operand" "1") (match_dup 5)))
>> (set (mem:BLK (match_dup 3))
>> (mem:BLK (match_dup 4)))
>> (use (reg:SI 19))]
>>
>> Here the (use (match_operand:SI 5) ...) appeared early to specify the
>> predicate and constraints for operand 5 and to make it clear that it was
>> just the input side of operand 2.
>>
>> This change
>>
>>
>> http://gcc.gnu.org/ml/gcc-patches/2000-08/msg00877.html
>>
>>
>> Fri Sep 29 13:20:42 MET DST 2000 Jan Hubicka
>>
>> * recog.c (recog_memoized): Rename to recog_memoized_1.
>> * recog.h (recog_memoized): Rename to recog_memoized_1.
>> (recog_memoized): New macro.
>> * rtl.h (single_set): Rename to single_set_1
>> (single_set): New macro.
>> * rtlanal.c (single_set): Rename to single_set_1; expect clobbers
>> to be last.
>>
>> * i386.md (strmovsi_1, strmovhi_1 strmovqi_1):
>> Do not use match_dup of input operands at outputs.
>> Use register_operand for memory expression.
>> (rep_movsi): Put use last, canonicalize.
>> Use register_operand for memory expression.
>> (rep_movqi): Put use last.
>> Use register_operand for memory expression.
>> (strsetsi_1, strset_hi_1, strsetqi_1): Do not use match_dup
>> of input operands at outputs. Use register_operand for memory
>> expression.
>> (rep_stossi): Put use last; canonicalize; fix match_dup in
>> the address expression
>> (rep_stosqi): Likewise.
>> (memcmp expander): Update calls.
>> (cmpstrsi_nz_1, cmpstrsi_1, strlensi_1): Avoid match_dups in
>> the clobbers.
>>
>> * i386.md (fp_jcc_3, fp_jcc_4, jp_fcc_5): if_then_else operand is
>> VOIDmode.
>> (fp_jcc_4, fp_jcc_3): Refuse unordered comparisons.
>>
>> put the predicate and constraints on the first use of operand 5, and
>> added the (use (match_dup 5)) at the end of the insn. I think that that
>> change should have simply dropped the (use (match_dup 5)), as it was no
>> longer needed.
>
> I believe I added use to make it clear that the insn does some other stuff
> with operand 5
> than just adding it to edx, i.e. that it specify the size of block copied.
> Without this it would be theoretically possible to change value of ecx when
> we need
> to do something with edx (i.e. if another value is later added to ecx, the
> optimizer
> may add the value to ecx before the memcpy)
I can accept the issue as a matter of documentation, but I don't
understand the rest. Remember that all the patterns are executed in
parallel. I don't see how adding a USE in parallel could affect
anything about how the operand is used.
Ian
Re: Register constraints + and =
> > I can accept the issue as a matter of documentation, but I don't > understand the rest. Remember that all the patterns are executed in > parallel. I don't see how adding a USE in parallel could affect > anything about how the operand is used. > >> >> (define_insn "*rep_movqi" > >> >>[(set (match_operand:P 2 "register_operand" "=c") (const_int 0)) > >> >> (set (match_operand:P 0 "register_operand" "=D") > >> >> (plus:P (match_operand:P 3 "register_operand" "0") > >> >> (match_operand:P 5 "register_operand" "2"))) > >> >> (set (match_operand:P 1 "register_operand" "=S") > >> >> (plus:P (match_operand:P 4 "register_operand" "1") (match_dup > >> >> 5))) > >> >> (set (mem:BLK (match_dup 3)) > >> >> (mem:BLK (match_dup 4))) > >> >> (use (match_dup 5))] Without the extra use the patterns says that the only use of operand 5 (CX) is to add it to DX and SX. So seeing something like memcpy(DX,SX,10) DX+=10 SX+=10 is IMO foldable to memcpy(DX,SX,20) Not that current forwprop/combine would do that. But in theory I think it is valid transform. The extra use says that one can not change 10 to 20 because the value is used otherwise, not only as addent to DX and SX. At least that is what I was shooting for back then ;) Honza
Re: Register constraints + and =
Jan Hubicka writes: >> >> I can accept the issue as a matter of documentation, but I don't >> understand the rest. Remember that all the patterns are executed in >> parallel. I don't see how adding a USE in parallel could affect >> anything about how the operand is used. > >> >> >> (define_insn "*rep_movqi" >> >> >>[(set (match_operand:P 2 "register_operand" "=c") (const_int 0)) >> >> >> (set (match_operand:P 0 "register_operand" "=D") >> >> >> (plus:P (match_operand:P 3 "register_operand" "0") >> >> >>(match_operand:P 5 "register_operand" "2"))) >> >> >> (set (match_operand:P 1 "register_operand" "=S") >> >> >> (plus:P (match_operand:P 4 "register_operand" "1") (match_dup >> >> >> 5))) >> >> >> (set (mem:BLK (match_dup 3)) >> >> >>(mem:BLK (match_dup 4))) >> >> >> (use (match_dup 5))] > > Without the extra use the patterns says that the only use of operand 5 (CX) is > to add it to DX and SX. > > So seeing something like > > memcpy(DX,SX,10) > DX+=10 > SX+=10 > > is IMO foldable to > > memcpy(DX,SX,20) > > Not that current forwprop/combine would do that. But in theory I think it is > valid > transform. No, it's not. All the SETs are done in parallel--the define_insn has an implicit PARALLEL wrapped around the insns. You're trying to pull some of the outputs into the inputs, but that is not permitted by the rules of RTL. Ian
Re: Register constraints + and =
> Jan Hubicka writes: > > >> > >> I can accept the issue as a matter of documentation, but I don't > >> understand the rest. Remember that all the patterns are executed in > >> parallel. I don't see how adding a USE in parallel could affect > >> anything about how the operand is used. > > > >> >> >> (define_insn "*rep_movqi" > >> >> >>[(set (match_operand:P 2 "register_operand" "=c") (const_int 0)) > >> >> >> (set (match_operand:P 0 "register_operand" "=D") > >> >> >> (plus:P (match_operand:P 3 "register_operand" "0") > >> >> >> (match_operand:P 5 "register_operand" "2"))) > >> >> >> (set (match_operand:P 1 "register_operand" "=S") > >> >> >> (plus:P (match_operand:P 4 "register_operand" "1") > >> >> >> (match_dup 5))) > >> >> >> (set (mem:BLK (match_dup 3)) > >> >> >> (mem:BLK (match_dup 4))) > >> >> >> (use (match_dup 5))] > > > > Without the extra use the patterns says that the only use of operand 5 (CX) > > is > > to add it to DX and SX. > > > > So seeing something like > > > > memcpy(DX,SX,10) > > DX+=10 > > SX+=10 > > > > is IMO foldable to > > > > memcpy(DX,SX,20) > > > > Not that current forwprop/combine would do that. But in theory I think it > > is valid > > transform. > > No, it's not. All the SETs are done in parallel--the define_insn has an > implicit PARALLEL wrapped around the insns. You're trying to pull some > of the outputs into the inputs, but that is not permitted by the rules > of RTL. In expanded form it is (set (reg5) (const 10)) (parallel [(set (reg2) (const 0)) (set (reg0) (plus (reg3) (reg5))) (set (reg1) (plus (reg4) (reg5))) (set (mem (reg3)) (mem (reg4)))]) (set (reg0) (plus (reg0) (const 10))) (set (reg1) (plus (reg1) (const 10))) instructions separated by empty lines. transformed into: (set (reg5) (const 20)) (parallel [(set (reg2) (const 0)) (set (reg0) (plus (reg3) (reg5))) (set (reg1) (plus (reg4) (reg5))) (set (mem (reg3)) (mem (reg4)))]) I do not see puling inputs to outputs here. > > Ian
Re: Register constraints + and =
Jan Hubicka writes: >> Jan Hubicka writes: >> >> >> >> >> I can accept the issue as a matter of documentation, but I don't >> >> understand the rest. Remember that all the patterns are executed in >> >> parallel. I don't see how adding a USE in parallel could affect >> >> anything about how the operand is used. >> > >> >> >> >> (define_insn "*rep_movqi" >> >> >> >>[(set (match_operand:P 2 "register_operand" "=c") (const_int 0)) >> >> >> >> (set (match_operand:P 0 "register_operand" "=D") >> >> >> >> (plus:P (match_operand:P 3 "register_operand" "0") >> >> >> >> (match_operand:P 5 "register_operand" "2"))) >> >> >> >> (set (match_operand:P 1 "register_operand" "=S") >> >> >> >> (plus:P (match_operand:P 4 "register_operand" "1") >> >> >> >> (match_dup 5))) >> >> >> >> (set (mem:BLK (match_dup 3)) >> >> >> >> (mem:BLK (match_dup 4))) >> >> >> >> (use (match_dup 5))] >> > >> > Without the extra use the patterns says that the only use of operand 5 >> > (CX) is >> > to add it to DX and SX. >> > >> > So seeing something like >> > >> > memcpy(DX,SX,10) >> > DX+=10 >> > SX+=10 >> > >> > is IMO foldable to >> > >> > memcpy(DX,SX,20) >> > >> > Not that current forwprop/combine would do that. But in theory I think it >> > is valid >> > transform. >> >> No, it's not. All the SETs are done in parallel--the define_insn has an >> implicit PARALLEL wrapped around the insns. You're trying to pull some >> of the outputs into the inputs, but that is not permitted by the rules >> of RTL. > > In expanded form it is > > (set (reg5) (const 10)) > > (parallel [(set (reg2) (const 0)) >(set (reg0) (plus (reg3) (reg5))) >(set (reg1) (plus (reg4) (reg5))) >(set (mem (reg3)) (mem (reg4)))]) > > (set (reg0) (plus (reg0) (const 10))) > > (set (reg1) (plus (reg1) (const 10))) > > instructions separated by empty lines. > > transformed into: > (set (reg5) (const 20)) > > (parallel [(set (reg2) (const 0)) >(set (reg0) (plus (reg3) (reg5))) >(set (reg1) (plus (reg4) (reg5))) >(set (mem (reg3)) (mem (reg4)))]) > > I do not see puling inputs to outputs here. Ah, thanks. I finally see what you are getting at. Perhaps you are right. I'm not sure. Ian
h8300-elf build broken
I assume this is a size_t vs int type problem, but the diagnostic
points to the function declaration, not to an actual binary
expression, and I can't figure out what it's complaining about:
/greed/dj/m32c/gcc/h8300-elf/./gcc/xgcc -shared-libgcc
-B/greed/dj/m32c/gcc/h8300-elf/./gcc -nostdinc++
-L/greed/dj/m32c/gcc/h8300-elf/h8300-elf/h8300h/normal/int32/libstdc++-v3/src
-L/greed/dj/m32c/gcc/h8300-elf/h8300-elf/h8300h/normal/int32/libstdc++-v3/src/.libs
-B/greed/dj/m32c/install/h8300-elf/bin/
-B/greed/dj/m32c/install/h8300-elf/lib/ -isystem
/greed/dj/m32c/install/h8300-elf/include -isystem
/greed/dj/m32c/install/h8300-elf/sys-include -mh -mn -mint32 -x c++-header
-nostdinc++ -g -O2
-I/greed/dj/m32c/gcc/h8300-elf/h8300-elf/h8300h/normal/int32/libstdc++-v3/include/h8300-elf
-I/greed/dj/m32c/gcc/h8300-elf/h8300-elf/h8300h/normal/int32/libstdc++-v3/include
-I/greed/dj/m32c/gcc/gcc/libstdc++-v3/libsupc++ -O2 -g -std=gnu++0x
/greed/dj/m32c/gcc/gcc/libstdc++-v3/include/precompiled/stdc++.h \
-o h8300-elf/bits/stdc++.h.gch/O2ggnu++0x.gch
In file included from
/greed/dj/m32c/gcc/h8300-elf/h8300-elf/h8300h/normal/int32/libstdc++-v3/include/vector:70:0,
from
/greed/dj/m32c/gcc/h8300-elf/h8300-elf/h8300h/normal/int32/libstdc++-v3/include/bits/random.h:34,
from
/greed/dj/m32c/gcc/h8300-elf/h8300-elf/h8300h/normal/int32/libstdc++-v3/include/random:50,
from
/greed/dj/m32c/gcc/h8300-elf/h8300-elf/h8300h/normal/int32/libstdc++-v3/include/bits/stl_algo.h:67,
from
/greed/dj/m32c/gcc/h8300-elf/h8300-elf/h8300h/normal/int32/libstdc++-v3/include/algorithm:63,
from
/greed/dj/m32c/gcc/gcc/libstdc++-v3/include/precompiled/stdc++.h:65:
/greed/dj/m32c/gcc/h8300-elf/h8300-elf/h8300h/normal/int32/libstdc++-v3/include/bits/vector.tcc:
In member function 'void std::vector<_Tp, _Alloc>::_M_emplace_back_aux(_Args&&
...) [with _Args = {const int&}; _Tp = int; _Alloc = std::allocator]':
/greed/dj/m32c/gcc/h8300-elf/h8300-elf/h8300h/normal/int32/libstdc++-v3/include/bits/vector.tcc:397:7:
error: type mismatch in binary expression
vector<_Tp, _Alloc>::
^
/greed/dj/m32c/gcc/h8300-elf/h8300-elf/h8300h/normal/int32/libstdc++-v3/include/bits/vector.tcc:397:7:
internal compiler error: verify_gimple failed
vector<_Tp, _Alloc>::
^
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
make: *** [h8300-elf/bits/stdc++.h.gch/O2ggnu++0x.gch] Error 1
Note: my current patchset is:
Index: libstdc++-v3/include/std/bitset
===
--- libstdc++-v3/include/std/bitset (revision 186562)
+++ libstdc++-v3/include/std/bitset (working copy)
@@ -1374,13 +1374,13 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
void
bitset<_Nb>::
_M_copy_from_ptr(const _CharT* __s, size_t __len,
size_t __pos, size_t __n, _CharT __zero, _CharT __one)
{
reset();
- const size_t __nbits = std::min(_Nb, std::min(__n, __len - __pos));
+ const size_t __nbits = std::min(_Nb, std::min(__n, (size_t)(__len -
__pos)));
for (size_t __i = __nbits; __i > 0; --__i)
{
const _CharT __c = __s[__pos + __nbits - __i];
if (_Traits::eq(__c, __zero))
;
else if (_Traits::eq(__c, __one))
Index: libstdc++-v3/include/bits/random.tcc
===
--- libstdc++-v3/include/bits/random.tcc(revision 186562)
+++ libstdc++-v3/include/bits/random.tcc(working copy)
@@ -2786,13 +2786,13 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
: (__n >= 68) ? 7
: (__n >= 39) ? 5
: (__n >= 7) ? 3
: (__n - 1) / 2;
const size_t __p = (__n - __t) / 2;
const size_t __q = __p + __t;
- const size_t __m = std::max(__s + 1, __n);
+ const size_t __m = std::max((size_t)(__s + 1), __n);
for (size_t __k = 0; __k < __m; ++__k)
{
_Type __arg = (__begin[__k % __n]
^ __begin[(__k + __p) % __n]
^ __begin[(__k - 1) % __n]);
Index: gcc/config/h8300/h8300.h
===
--- gcc/config/h8300/h8300.h(revision 186534)
+++ gcc/config/h8300/h8300.h(working copy)
@@ -126,12 +126,13 @@ extern const char * const *h8_reg_names;
/* The return address is pushed on the stack. */
#define INCOMING_RETURN_ADDR_RTX gen_rtx_MEM (Pmode, gen_rtx_REG (Pmode,
STACK_POINTER_REGNUM))
#define INCOMING_FRAME_SP_OFFSET (POINTER_SIZE / 8)
#define DWARF_CIE_DATA_ALIGNMENT 2
+#define DWARF2_ADDR_SIZE 4
/* Define this if addresses of constant functions
shouldn't be put through pseudo regs where they can be cse'd.
D
Re: h8300-elf build broken
On Tue, May 8, 2012 at 5:14 PM, DJ Delorie wrote:
>
> I assume this is a size_t vs int type problem, but the diagnostic
> points to the function declaration, not to an actual binary
> expression, and I can't figure out what it's complaining about:
My mailer uses proportional fonts so I can't make sense of the
diagnostics with the carets :-/
>
> Note: my current patchset is:
>
> Index: libstdc++-v3/include/std/bitset
> ===
> --- libstdc++-v3/include/std/bitset (revision 186562)
> +++ libstdc++-v3/include/std/bitset (working copy)
> @@ -1374,13 +1374,13 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
> void
> bitset<_Nb>::
> _M_copy_from_ptr(const _CharT* __s, size_t __len,
> size_t __pos, size_t __n, _CharT __zero, _CharT __one)
> {
> reset();
> - const size_t __nbits = std::min(_Nb, std::min(__n, __len - __pos));
> + const size_t __nbits = std::min(_Nb, std::min(__n, (size_t)(__len -
> __pos)));
style nits: It should be size_t(__len - __pos), and not (size_t)(__len - __pos).
Same for the other hunk. Patch OK with those changes.
-- Gaby
