__builtin_va_list bug ir feature

__builtin_va_list bug ir feature

[Gisle Vanem]

gcc -v
Reading specs from e:/djgpp/lib/gcc-lib/djgpp/3.22/specs
Configured with: /dj204/gnu/gcc-3.22/configure i586-pc-msdosdjgpp 
  --prefix=/dev/env/DJDIR --disable-nls
Thread model: single
gcc version 3.2.2

I'm porting some code from Watcom to gcc and encountered tons 
of warnings on illegal use of va_arg(). So I cooked up a little test:

#include <stdarg.h>
char x;
void foo (va_list arg)
{
  x = va_arg (arg, char);
}

This gives a warning "`char' is promoted to `int' when passed through `...'"
Fair enough, but when I produce an asm-listing, here's what I get:
        .file   "test.c"
        .section .text
.globl _foo
_foo:
        pushl   %ebp
        movl    %esp, %ebp
        int     $5               # <<<<
.comm _x,16
        .ident  "GCC: (GNU) 3.2.2"

What's the "int $5" doing there?

Is this a gcc bug or feature? I found absolutely nothing in the
gcc online docs about this. If it's a feature, what's the rationale
behind it? IMHO if gcc should treat this as a fatal error instead
of emitting a bound trap (int $5). That is just too nasty. I spent
a full day tracking this down.

Using "va_arg (arg,int)" of-course produces the correct code.

--gv

Re: __builtin_va_list bug ir feature

[Joseph S. Myers]

On Fri, 25 Apr 2003, Gisle Vanem wrote:

> Is this a gcc bug or feature? I found absolutely nothing in the
> gcc online docs about this. If it's a feature, what's the rationale
> behind it? IMHO if gcc should treat this as a fatal error instead
> of emitting a bound trap (int $5). That is just too nasty. I spent
> a full day tracking this down.

The C standard permits this _in code that is never executed_ - it is
undefined behavior _at runtime_ if the wrong type is used in va_arg, and
an unpromoted type is necessarily wrong, but the function containing the
bad use of va_arg might never be executed, or that bad call might never be
executed, so it can't be a hard error, but instead is a mandatory warning,
with a trap generated in case the code is ever in fact executed.

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: __builtin_va_list bug or feature

[Gisle Vanem]

"Joseph S. Myers" <jsm28@cam.ac.uk> said:

> The C standard permits this _in code that is never executed_ - it is
> undefined behavior _at runtime_ if the wrong type is used in va_arg, and
> an unpromoted type is necessarily wrong, but the function containing the
> bad use of va_arg might never be executed, or that bad call might never be
> executed, so it can't be a hard error, but instead is a mandatory warning,
> with a trap generated in case the code is ever in fact executed.

Black talk and geek speech. The code is always executed when the format 
in question was used (%D in a custom va-function). 

So the unpromote type is wrong, so what! The djgpp va_arg() macro 
picks up the wrong type, but the stack isn't messed up. I'd rather prefer 
wrong output than a generated trap. Which neither MingW nor djgpp
have handlers for. Seems gcc is biased towards Linux in this case.

Gisle V.

# rm /bin/laden 
/bin/laden: Not found 

Re: __builtin_va_list bug or feature

[Joseph S. Myers]

On Fri, 25 Apr 2003, Gisle Vanem wrote:

> Black talk and geek speech. The code is always executed when the format 
> in question was used (%D in a custom va-function). 

The format needn't be used in a given execution of the program.  DR#109
<http://std.dkuug.dk/JTC1/SC22/WG14/www/docs/dr_109.html> is quite
explicit about what conforming implementations must do in such
circumstances:

   A conforming implementation must not fail to translate a strictly
   conforming program simply because _some_ possible execution of that
   program would result in undefined behavior.

> So the unpromote type is wrong, so what! The djgpp va_arg() macro 
> picks up the wrong type, but the stack isn't messed up. I'd rather prefer 
> wrong output than a generated trap. Which neither MingW nor djgpp
> have handlers for. Seems gcc is biased towards Linux in this case.

The ABI won't in general specify the interface for unpromoted types
because the C promotion rules mean they cannot arise as arguments to be
accessed by va_arg; complicated macros are liable to yield some quieter
form of undefined behavior at runtime (e.g. silent data corruption), but
with a built-in operator it is possible to do better; a generated trap
means the problem gets detected at runtime (hopefully in the course of
running a testsuite for the code if not before then), if somehow it wasn't
fixed after the warning was given.  This is much better than silent data
corruption, a likely other form of undefined behavior.  The natural
alternative to generating a trap would be for the compiler to reason that
undefined behavior means that the code in question cannot be reached and
optimize the rest of the program on that basis, which would be riskier
(and in this case unlikely to be a useful optimization).

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: __builtin_va_list bug or feature

[Richard Henderson]

On Fri, Apr 25, 2003 at 08:02:04PM +0200, Gisle Vanem wrote:
> I'd rather prefer wrong output than a generated trap. Which neither
> MingW nor djgpp have handlers for.  Seems gcc is biased towards Linux
> in this case.

I'm surprised there's no handler installed to generate 
some sort of signal in this case -- seems like a point
that could be improved for mingw and djgpp.

Anyway, if you'd rather we call abort instead, you can
comment out the following pattern in gcc/config/i386/i386.md:

	(define_insn "trap"
	  [(trap_if (const_int 1) (const_int 5))]
	  ""
	  "int\t$5")


r~