* 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
[parent not found: <20020725102412.GV26054@bubble.sa.bigpond.net.au>]
* 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).