[PATCH] Fixing a corner-case bug in lib call optimization

[Gao, Yunzhong]

Hi Nick,

As Eli has pointed out, this involves implementation-defined behavior, meaning
the compiler should choose one particular behavior and stay with it.

The clang front end will generate the following LLVM IR for "(signed char)x":
%conv = trunc i32 %x to i8
I think my patch is at least consistent with the behavior chosen by clang. The trunc
instruction is described here: http://llvm.org/docs/LangRef.html#trunc-to-instruction

The standard does say that implemenation-defined behaviors should be
documented, but I did not see such documentation in the user manual. I found
an open bug instead: http://llvm.org/bugs/show_bug.cgi?id=11272 and I added a
comment there.

Thanks,
- Gao.

________________________________________
From: Nick Lewycky [nicholas at mxc.ca]
Sent: Tuesday, August 13, 2013 10:36 PM
To: Gao, Yunzhong
Cc: reviews+D1279+public+b2efa1ad64fbca2e at llvm-reviews.chandlerc.com; llvm-commits at cs.uiuc.edu
Subject: Re: [PATCH] Fixing a corner-case bug in lib call optimization

Actually, I was thinking about this some more and isn't the testcase you
posted undefined behaviour?

The C standard specifies that it gets converted from int to char. That
conversion will produce an implementation-defined result when the int is
not in range of a char. Now for the crazy part -- isn't it true that
there is no rule requiring a value in the abstract machine of C (or C++)
to actually fit in the number of bits allotted? Given the right setup,
you can have char x == 1000 evaluate to true (even assuming 8-bit char),
and no undefined behaviour, merely implementation-defined results.

Maybe I'm crazy?

Nick