[cfe-dev] -ftrapv

[David Chisnall]

On 1 Apr 2009, at 19:32, Mike Stump wrote:

> On Apr 1, 2009, at 8:54 AM, David Chisnall wrote:
>> I've attached a diff which adds -ftrapv to clang-cc
>
> Delicious!  Added in r68221.

Thanks

>> (not to clang; the driver code scares me)
>
> Check out the code I added to add the option to clang, turns out is  
> is magically easy (for clang_f_options anyway).

Wow, that is magically easy.  I had it almost right, but the errors I  
was getting were just confusing me more.

>> When an overflow is detected, it calls a function in a supporting  
>> library to handle it.  I've provided a default implementation in  
>> overflowlib.c.
>
> Hum, I don't know quite what to do with runtime code yet.  Logically  
> we need a runtime library.  I kinda like the idea of bundling in a  
> reference to the required runtime into the output file, and then  
> having the linker use that knowledge to ensure that the proper  
> runtime is linked in.  Conceptually, it would be the same as  
> actually putting the runtime into the output, with link-once style  
> linkage, but cheaper, as one wouldn't need to generate or move all  
> the bits, essentially just the name.  gcc would have done this 15  
> years ago if the linkers supported it, but they didn't.  Modern  
> linkers probably could be encouraged to support this for us, if we  
> try.

I was wondering if we could make the __overflow_hander link-once and  
set it to abort by default, but allow a linked runtime library to  
provide another default version of it.  Then I realised I actually had  
no idea about nontrivial linker options and decided to leave this bit  
for someone who actually knew what they were talking about...

In a future version, I'd quite like to be able to specify the handler  
function on a per-module basis, so we can have different, statically- 
defined, overflow behaviour for different modules and allow LLVM to  
inline the handlers where appropriate.

> Absent that, either we need a libclang.{so,dylib,a} or some other  
> suitably advanced technology.  Do we have such yet?
>
>> This can be replaced in compiled code by some other function if  
>> required.  For 100% GCC compatibility just add:
>>
>> __overflow_handler = abort;
>
> I put this in without considering the finer point of exactly how we  
> want this to be.  I think it is an excellent start.  I do encourage  
> people to weigh in on how they think this should work, if they want  
> to see something else.  My quick first impression is I like it  
> exactly how you did it.


I really just wanted something to play with for prototyping the (not- 
yet-finalised) C1x extensions for overflow checking.  My aim was to  
provide a hook that is sufficiently general to allow experimentation  
and eventually provide an implementation in libc.so (or libclang.bc)  
that implements the C1x semantics when they are properly defined.

The other use I have for this is in the Étoilé Smalltalk compiler,  
which implements messages sent to SmallInt objects in C, and compiles  
them to bitcode with clang, then links them with the bitcode from  
Smalltalk classes so that they can be inlined where appropriate.  This  
will let me remove a load of inefficient overflow checking code from  
that file.

David