Strange RTL problem

Strange RTL problem

[Chris Lattner]

I'm having a really wierd problem with a backend that I'm working on for
the following C code snippet:

int printf(const char *, ...);
int main() {
  signed char c0  = -1;
  unsigned char c1 = 255;
  printf("bs0  = %d %d\n", c0, c1);
  return 0;
}

I'd like to see output of -1, 255, but my target is generating "255 255".

Looking at the RTL, I see these two INSNs:

(insn 23 21 25 (set (mem/f:QI (plus:PDI (reg/f:PDI 14 %sp)
                (const_int 8 [0x8])) 0)
        (const_int -1 [0xffffffff])) 9 {*movqi} (nil)
    (nil))

(insn 25 23 26 (set (mem/f:QI (plus:PDI (reg/f:PDI 14 %sp)
                (const_int 12 [0xc])) 0)
        (const_int 255 [0xff])) 9 {*movqi} (nil)
    (nil))

which are immediately before the printf call.  Since both arguments are 8
bit quantities, they are stored onto the stack as QI mode, but doing
so they lose the integral promotion that would make them signed or
unsigned (this only happens with vararg functions).

This is really strange... does anyone have any idea what could be going
wrong here?  How are integral promotions different for vararg functions
than they are for other function calls?

Thanks,

-Chris

http://www.nondot.org/~sabre/os/
http://www.nondot.org/~sabre/Projects/

Re: Strange RTL problem

[Chris Lattner]

> This is really strange... does anyone have any idea what could be going
> wrong here?  How are integral promotions different for vararg functions
> than they are for other function calls?

One thing I should have mentioned before is that my target does not define
_any_ of the PROMOTE_* macros at all.  In particular, the description of
PROMOTE_PROTOTYPES sounds like it could be relevant:

"A C expression whose value is nonzero if an argument declared in a
 prototype as an integral type smaller than int should actually be passed
 as an int. In addition to avoiding errors in certain cases of mismatch,
 it also makes for better code on certain machines. If the macro is not
 defined in target header files, it defaults to 0."

Now I don't have any mismatch going on here, and I don't really want
values to be promoted that shouldn't be, so what is the best course of
action here?  Are all values passed through varargs considered to be a
mismatch of an argument (since there IS effectively no prototype for those
parameters?)

Thanks,

-Chris

http://www.nondot.org/~sabre/os/
http://www.nondot.org/~sabre/Projects/

Re: Strange RTL problem

[Daniel Jacobowitz]

On Wed, May 01, 2002 at 02:47:54PM -0500, Chris Lattner wrote:
> 
> I'm having a really wierd problem with a backend that I'm working on for
> the following C code snippet:
> 
> int printf(const char *, ...);
> int main() {
>   signed char c0  = -1;
>   unsigned char c1 = 255;
>   printf("bs0  = %d %d\n", c0, c1);
>   return 0;
> }
> 
> I'd like to see output of -1, 255, but my target is generating "255 255".
> 
> Looking at the RTL, I see these two INSNs:
> 
> (insn 23 21 25 (set (mem/f:QI (plus:PDI (reg/f:PDI 14 %sp)
>                 (const_int 8 [0x8])) 0)
>         (const_int -1 [0xffffffff])) 9 {*movqi} (nil)
>     (nil))
> 
> (insn 25 23 26 (set (mem/f:QI (plus:PDI (reg/f:PDI 14 %sp)
>                 (const_int 12 [0xc])) 0)
>         (const_int 255 [0xff])) 9 {*movqi} (nil)
>     (nil))
> 
> which are immediately before the printf call.  Since both arguments are 8
> bit quantities, they are stored onto the stack as QI mode, but doing
> so they lose the integral promotion that would make them signed or
> unsigned (this only happens with vararg functions).

It sounds like you're actually pushing them onto stack as QImode? 
That's wrong for at least C; they should be promoted to int (presumably
SImode) before they are pushed.


-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: Strange RTL problem (n/m)

[Chris Lattner]

> Now I don't have any mismatch going on here, and I don't really want
> values to be promoted that shouldn't be, so what is the best course of

Ok, I found my problem, which was due to some broken debugging code.
Sorry to bother everyone.  :)

-Chris

http://www.nondot.org/~sabre/os/
http://www.nondot.org/~sabre/Projects/