Patch for 2.95.3

Patch for 2.95.3

[Gunther Nikl]

Hello!

I would like to see the following patch installed in 2.95.3:

   http://gcc.gnu.org/ml/gcc-patches/2000-01/msg00000.html

This patch fixes the loss of a pending stack adjust (happens eg. on
m68k for m68060)

Gunther Nikl

Re: Patch for 2.95.3

[Bernd Schmidt]

On Thu, 7 Dec 2000, Gunther Nikl wrote:

> I would like to see the following patch installed in 2.95.3:
> 
>    http://gcc.gnu.org/ml/gcc-patches/2000-01/msg00000.html
> 
> This patch fixes the loss of a pending stack adjust (happens eg. on
> m68k for m68060)

It's already applied to the branch.


Bernd

Bit Fields

[Matt Minnis]

Is there a way to dynamically define bit fields in a integer?

I know how to define them in code, but how can it be done for purposes of 
reading in a file that would be easier to deal with if there was a way to 
do this.

Basically, read in a file describing internal registers of a micro 
controller of some sort, and have the bit fields to designate the different 
functions of some of the bits.

I know this can be done via a mask, but I would like to know if this is 
possible?

Thanks,

Matt Minnis

Bit fields

[Jean Christophe Beyler]

Dear all,

I am currently working on handling bit-fields on my port and am having
difficulties understanding why GCC is having problems with what I
wrote in.

Following what mips did:

(define_expand "extzv"
  [(set (match_operand 0 "register_operand")
    (zero_extract (match_operand 1 "nonimmediate_operand")
              (match_operand 2 "immediate_operand")
              (match_operand 3 "immediate_operand")))]
  "!TARGET_MIPS16"
{
  ...
})

(define_insn "extzv<mode>"
  [(set (match_operand:GPR 0 "register_operand" "=d")
    (zero_extract:GPR (match_operand:GPR 1 "register_operand" "d")
              (match_operand:SI 2 "immediate_operand" "I")
              (match_operand:SI 3 "immediate_operand" "I")))]
  "mips_use_ins_ext_p (operands[1], INTVAL (operands[2]),INTVAL (operands[3]))"
  "<d>ext\t%0,%1,%3,%2"
  [(set_attr "type" "arith")
   (set_attr "mode" "<MODE>")])

I did:

(define_insn "extzv"
   [(set (match_operand 0 "register_operand" "")
         (zero_extract (match_operand 1 "register_operand" "")
                       (match_operand 2 "const_int_operand" "")
                       (match_operand 3 "const_int_operand" "")))]
 ""
 "")

(define_insn "extzvdi2"
   [(set (match_operand:DI 0 "register_operand" "=r")
         (zero_extract:DI (match_operand:DI 1 "register_operand" "r")
                       (match_operand:DI 2 "const_int_operand" "L")
                       (match_operand:DI 3 "const_int_operand" "L")))]
 "check_extract (DImode, DImode, operands[2], operands[2])"
 "extr\\t%0,%1,%3,%2";
 [(set_attr "type"     "arith")
  (set_attr "mode"     "DI")
  (set_attr "length"   "1")])

For the moment, I haven't put anything in my expand because I don't
know if anything is necessary yet. I was first looking at if GCC was
generating the right code on simple examples.

But I get this message:
struct4.c: In function 'goo':
struct4.c:32: internal compiler error: in simplify_subreg, at
simplify-rtx.c:4923

Does anybody know how can I solve this issue ?
Thanks again for all your help,
Jean Christophe Beyler

Re: Bit fields

[Ian Lance Taylor]

Jean Christophe Beyler <jean.christophe.beyler@gmail.com> writes:

> But I get this message:
> struct4.c: In function 'goo':
> struct4.c:32: internal compiler error: in simplify_subreg, at
> simplify-rtx.c:4923
>
> Does anybody know how can I solve this issue ?

You need to start by looking at line 4923 of simplify-rtx.c to see what
the failure is.  We don't know, since we don't have your source and you
didn't mention which version of gcc you are using.

I don't see anything obviously wrong in your example, but there were
many omitted details which could have caused this problem.

Ian

Re: Bit fields

[Jean Christophe Beyler]

Sorry, you are correct. That line is the :
  gcc_assert (outermode != VOIDmode);
of the simplify_subreg function.

However, I've played around with it and saw that I made a mistake when
writing up this question, I simplified what I had put in my MD file,
and actually made a mistake. I apologize.

If I replace this :
(define_insn "extzv"
  [(set (match_operand 0 "register_operand" "")
        (zero_extract (match_operand 1 "register_operand" "")
                      (match_operand 2 "const_int_operand" "")
                      (match_operand 3 "const_int_operand" "")))]
 ""
 "")

into :
(define_expand "extzv"
  [(set (match_operand 0 "register_operand" "")
        (zero_extract (match_operand 1 "register_operand" "")
                      (match_operand 2 "const_int_operand" "")
                      (match_operand 3 "const_int_operand" "")))]
 ""
 "")

I do not get any errors. I don't know if it's handled but it seems to
no longer have issues anymore.

However, if I consider this code:
typedef struct stest {
    uint64_t a:1;
    uint64_t b:1;
}STest;

void
goo (STest *t, uint64_t *a, uint64_t *b)
{
    *a = t->a;
}

At the expand phase, I see:

(insn 9 8 10 3 struct4.c:24 (set (subreg:DI (reg:QI 76) 0)
        (zero_extract:DI (reg:DI 75)
            (const_int 1 [0x1])
            (const_int 0 [0x0]))) -1 (nil))

(insn 10 9 11 3 struct4.c:24 (set (reg:DI 77)
        (zero_extend:DI (reg:QI 76))) -1 (nil))

Is there anything I can do to remove that zero_extend?

Thanks,
Jc

Re: Bit fields

[Richard Henderson]

On 08/31/2009 01:07 PM, Jean Christophe Beyler wrote:
> If I replace this :
> (define_insn "extzv"
>    [(set (match_operand 0 "register_operand" "")
>          (zero_extract (match_operand 1 "register_operand" "")
>                        (match_operand 2 "const_int_operand" "")
>                        (match_operand 3 "const_int_operand" "")))]
>   ""
>   "")

Well, I can tell you that an insn pattern with no modes
on the non-immediate operands will definitely cause problems.

> (insn 9 8 10 3 struct4.c:24 (set (subreg:DI (reg:QI 76) 0)
>          (zero_extract:DI (reg:DI 75)
>              (const_int 1 [0x1])
>              (const_int 0 [0x0]))) -1 (nil))
>
> (insn 10 9 11 3 struct4.c:24 (set (reg:DI 77)
>          (zero_extend:DI (reg:QI 76))) -1 (nil))
>
> Is there anything I can do to remove that zero_extend?

You could try either using a predicate that disallows
a subreg, or by having your expander rewrite things into

   (set (reg:DI new-scratch))
        (zero_extract:DI ...))
   (set (reg:QI 76 (subreg:QI (reg:DI new scratch)))

and relying on subsequent passes to clean that up.


r~

Re: Bit fields

[Jean Christophe Beyler]

On Mon, Aug 31, 2009 at 5:27 PM, Richard Henderson<rth@redhat.com> wrote:
> On 08/31/2009 02:07 PM, Jean Christophe Beyler wrote:
>>
>> I am going to try this but shouldn't it be :
>>
>> (set (reg:QI new-scratch))
>>       (zero_extract:DI ...))
>
> No.

Ok, I think I understand why not:

>> (insn 9 8 10 3 struct4.c:24 (set (subreg:DI (reg:QI 76) 0)
>>         (zero_extract:DI (reg:DI 75)
>>             (const_int 1 [0x1])
>>             (const_int 0 [0x0]))) -1 (nil))

Is basically saying :

(set (reg:DI new-scratch)
        (zero_extract:DI (reg:DI 75)
            (const_int 1 [0x1])
            (const_int 0 [0x0]))) -1 (nil))

and then apply the subreg:

(set (reg:QI 76) (subreg:QI (reg:DI new-scratch)))

which is what you were saying. I was reading the subreg the other way around.

>
>> Any ideas?
>
> Nope.  You'll have to debug it.
>

Ok, is it normal to see a ashift with a negative value though or is
this already sign of a (potentially) different problem?

Thanks again and sorry about the random questions,
Jc

Re: Bit fields

[Richard Henderson]

On 08/31/2009 07:20 PM, Jean Christophe Beyler wrote:
> Ok, is it normal to see a ashift with a negative value though or is
> this already sign of a (potentially) different problem?

I seem to recall that it's normal.  Combine was originally
written in the days of VAX, where negative shifts were allowed.
You'll just want to reject them in your patterns.


r~