* Undefined behavior in 950605-1.c
@ 2002-07-25 7:08 Momchil Velikov
2002-07-25 8:54 ` Andreas Schwab
0 siblings, 1 reply; 8+ messages in thread
From: Momchil Velikov @ 2002-07-25 7:08 UTC (permalink / raw)
To: gcc
IMHO, gcc.c-torture/execute/950605-1.c (pasted below) provokes
undefined behavior according to ISO 9899:1999 6.5.2.2 [#6]
... If the function is defined with a type that does not
include a prototype, and the types of the arguments after
promotion are not compatible with those of the parameters after
promotion, the behavior is undefined, except for the following
cases:
-- one promoted type is a signed integer type, the other
promoted type is the corresponding unsigned integer type,
and the value is representable in both types;
f (c)
unsigned char c;
{
if (c != 0xFF)
abort ();
}
main ()
{
f (-1);
exit (0);
}
IOW, the value -1 is not representable in the promoted type of the
formal parameter of ``f''.
Comments?
~velco
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Undefined behavior in 950605-1.c
2002-07-25 7:08 Undefined behavior in 950605-1.c Momchil Velikov
@ 2002-07-25 8:54 ` Andreas Schwab
2002-07-25 9:04 ` Momchil Velikov
0 siblings, 1 reply; 8+ messages in thread
From: Andreas Schwab @ 2002-07-25 8:54 UTC (permalink / raw)
To: Momchil Velikov; +Cc: gcc
Momchil Velikov <velco@fadata.bg> writes:
|> IMHO, gcc.c-torture/execute/950605-1.c (pasted below) provokes
|> undefined behavior according to ISO 9899:1999 6.5.2.2 [#6]
|>
|> ... If the function is defined with a type that does not
|> include a prototype, and the types of the arguments after
|> promotion are not compatible with those of the parameters after
|> promotion, the behavior is undefined, except for the following
|> cases:
|>
|> -- one promoted type is a signed integer type, the other
|> promoted type is the corresponding unsigned integer type,
|> and the value is representable in both types;
|>
|> f (c)
|> unsigned char c;
|> {
|> if (c != 0xFF)
|> abort ();
|> }
|>
|> main ()
|> {
|> f (-1);
|> exit (0);
|> }
|>
|> IOW, the value -1 is not representable in the promoted type of the
|> formal parameter of ``f''.
The promoted type of the formal parameter of f is either int or unsigned
int, and -1 is representable in both types.
Andreas.
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Undefined behavior in 950605-1.c
2002-07-25 8:54 ` Andreas Schwab
@ 2002-07-25 9:04 ` Momchil Velikov
[not found] ` <20020725102412.GV26054@bubble.sa.bigpond.net.au>
0 siblings, 1 reply; 8+ messages in thread
From: Momchil Velikov @ 2002-07-25 9:04 UTC (permalink / raw)
To: Andreas Schwab; +Cc: gcc
>>>>> "Andreas" == Andreas Schwab <schwab@suse.de> writes:
Andreas> |>
Andreas> |> f (c)
Andreas> |> unsigned char c;
Andreas> |> {
Andreas> |> if (c != 0xFF)
Andreas> |> abort ();
Andreas> |> }
Andreas> |>
Andreas> |> main ()
Andreas> |> {
Andreas> |> f (-1);
Andreas> |> exit (0);
Andreas> |> }
Andreas> |>
Andreas> |> IOW, the value -1 is not representable in the promoted type of the
Andreas> |> formal parameter of ``f''.
Andreas> The promoted type of the formal parameter of f is either int
Andreas> or unsigned int, and -1 is representable in both types.
Hmm, what does "representable" means ? I'd think (on 32-bit two's
complement machine) [-2^31, 2^31) is representable by ``int'' and [0,
2^32) is representable by ``unsigned int'', thus -1 is not
representable if the promoted type of the parametar is unsigned.
~velco
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Undefined behavior in 950605-1.c
[not found] ` <20020725102412.GV26054@bubble.sa.bigpond.net.au>
@ 2002-07-25 10:56 ` Momchil Velikov
2002-07-25 11:24 ` Andreas Schwab
2002-07-25 13:25 ` Richard Henderson
0 siblings, 2 replies; 8+ messages in thread
From: Momchil Velikov @ 2002-07-25 10:56 UTC (permalink / raw)
To: Alan Modra; +Cc: gcc
>>>>> "Alan" == Alan Modra <amodra@bigpond.net.au> writes:
Alan> On Thu, Jul 25, 2002 at 12:53:59PM +0300, Momchil Velikov wrote:
>> representable if the promoted type of the parametar is unsigned.
Alan> Ah, but what is the promoted type of "unsigned char"? int!
ISO/IEC 9899:1999 6.5.2.2 [#6]
" ... the other promoted type is the corresponding unsigned integer
type, ..."
IMHO, that means that it is legal for the promoted type of ``unsigned
char'' to be ``unsigned int''. Isn't that the case with architectures
with a definition of PROMOTE_MODE, which does not change UNSIGNEDP or
sets it to 1, e.g, ARM, PPC, V850 ?
Indeed it contradicts with 6.3.1.1 [#2]:
"If an int can represent all values of the original type, the value
is converted to an int; otherwise, it is converted to an unsigned
int. These are called the integer promotions."
~velco
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Undefined behavior in 950605-1.c
2002-07-25 10:56 ` Momchil Velikov
@ 2002-07-25 11:24 ` Andreas Schwab
2002-07-25 13:25 ` Richard Henderson
1 sibling, 0 replies; 8+ messages in thread
From: Andreas Schwab @ 2002-07-25 11:24 UTC (permalink / raw)
To: Momchil Velikov; +Cc: Alan Modra, gcc
Momchil Velikov <velco@fadata.bg> writes:
|> >>>>> "Alan" == Alan Modra <amodra@bigpond.net.au> writes:
|>
|> Alan> On Thu, Jul 25, 2002 at 12:53:59PM +0300, Momchil Velikov wrote:
|> >> representable if the promoted type of the parametar is unsigned.
|>
|> Alan> Ah, but what is the promoted type of "unsigned char"? int!
|>
|> ISO/IEC 9899:1999 6.5.2.2 [#6]
|>
|> " ... the other promoted type is the corresponding unsigned integer
|> type, ..."
|>
|> IMHO, that means that it is legal for the promoted type of ``unsigned
|> char'' to be ``unsigned int''.
Only if UCHAR_MAX == UINT_MAX. Otherwise int can represent all values of
unsigned char, thus unsigned char is promoted to int.
Andreas.
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Undefined behavior in 950605-1.c
2002-07-25 10:56 ` Momchil Velikov
2002-07-25 11:24 ` Andreas Schwab
@ 2002-07-25 13:25 ` Richard Henderson
2002-07-26 14:47 ` Richard Earnshaw
1 sibling, 1 reply; 8+ messages in thread
From: Richard Henderson @ 2002-07-25 13:25 UTC (permalink / raw)
To: Momchil Velikov; +Cc: Alan Modra, gcc
On Thu, Jul 25, 2002 at 03:22:46PM +0300, Momchil Velikov wrote:
> Alan> Ah, but what is the promoted type of "unsigned char"? int!
Except if sizeof(char) == sizeof(int).
> Isn't that the case with architectures
> with a definition of PROMOTE_MODE, which does not change UNSIGNEDP or
> sets it to 1, e.g, ARM, PPC, V850 ?
PROMOTE_MODE has nothing to do with C types. It's for efficiency
in the generated rtl *only*. If a strictly conforming program can
notice the existance of PROMOTE_MODE, there is a bug.
r~
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Undefined behavior in 950605-1.c
2002-07-25 13:25 ` Richard Henderson
@ 2002-07-26 14:47 ` Richard Earnshaw
2002-07-28 0:08 ` Richard Henderson
0 siblings, 1 reply; 8+ messages in thread
From: Richard Earnshaw @ 2002-07-26 14:47 UTC (permalink / raw)
To: Richard Henderson; +Cc: Momchil Velikov, Alan Modra, gcc, Richard.Earnshaw
> PROMOTE_MODE has nothing to do with C types. It's for efficiency
> in the generated rtl *only*.
I believe it can also be part of the ABI specification, so someone writing
assembler would be able to tell the difference, and a compiler can assume
that a caller has done the promotion (so saving a repeat promotion).
> If a strictly conforming program can
> notice the existance of PROMOTE_MODE, there is a bug.
Agreed.
R.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Undefined behavior in 950605-1.c
2002-07-26 14:47 ` Richard Earnshaw
@ 2002-07-28 0:08 ` Richard Henderson
0 siblings, 0 replies; 8+ messages in thread
From: Richard Henderson @ 2002-07-28 0:08 UTC (permalink / raw)
To: Richard.Earnshaw; +Cc: Momchil Velikov, Alan Modra, gcc
On Fri, Jul 26, 2002 at 09:54:52AM +0100, Richard Earnshaw wrote:
> > PROMOTE_MODE has nothing to do with C types. It's for efficiency
> > in the generated rtl *only*.
>
> I believe it can also be part of the ABI specification...
This is true. I was sort of glossing over that to avoid confusion.
r~
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2002-07-27 22:03 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-07-25 7:08 Undefined behavior in 950605-1.c Momchil Velikov
2002-07-25 8:54 ` Andreas Schwab
2002-07-25 9:04 ` Momchil Velikov
[not found] ` <20020725102412.GV26054@bubble.sa.bigpond.net.au>
2002-07-25 10:56 ` Momchil Velikov
2002-07-25 11:24 ` Andreas Schwab
2002-07-25 13:25 ` Richard Henderson
2002-07-26 14:47 ` Richard Earnshaw
2002-07-28 0:08 ` Richard Henderson
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).