[Bug c/48274] New: C frontend emit invalid promotions

["matz at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48274

           Summary: C frontend emit invalid promotions
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: matz@gcc.gnu.org


This came up in the context of a stricter consistency checker for types in
our middle end.  I believe the C frontend emits invalid promotions for calls
to prototyped functions:

% cat x.c
unsigned passchar (char c);
unsigned passflt (float f);
unsigned passva (int i, ...);
char blachar (char c, float f)
{
  return passchar (c) + passflt (f) + passva(1, f);
}
% ./cc1 x.c -fdump-tree-original
% cat x.c.003t.original
;; Function blachar (null)
;; enabled by -tree-original
{
  return (char) (((unsigned char) passchar ((int) c) + (unsigned char) passflt
(f)) + (unsigned char) passva (1, (double) f));
}

The emitted code doesn't depend on the -std=xxx setting.  What I believe
is invalid here is the call to passchar().  First, it's a prototyped
function, hence 6.5.2.2 #7 is invoked:

#7: ... the arguments are implicitly converted, as if by assignment, to the
    types of the corresponding parameters, taking the type of each parameter
    to be the unqualiïed version of its declared type. The ellipsis notation
    ...

Hence, as if by assignment.  types of assignment expressions is that of the
left operand after lvalue conversions.  In this case the left operand is
the corresponding parameter (char c), hence I don't think there's much
leeway to read this as actually passing an 'int'.

This sort of looks as if the argument passer applies either default argument
promotions (6.5.2.2 #6, but that would mean it also had to promote the
float in passflt() call to double), or integer promotions (which would be
completely off) to arguments for calls to prototyped functions.