similar to: [LLVMdev] finding integer undefined behaviors using clang

On Apr 8, 2011, at 8:27 AM, John Regehr wrote: > Patch and documentation can be found here: > > http://embed.cs.utah.edu/ubc/ It seems that this could be merged into -fcatch-undefined-behavior while separating mechanism from policy: 1) Adding checks for more undefined behavior. 2) Allowing different choices of trap mechanism when undefined behavior is encountered. Cameron

Hi Cameron, I agree, it would be nice to integrate this. My quick analysis of the situation, however, was that there's probably some difference of opinion about how heavyweight the trap handler should be. Ours is very heavy, in order to produce informative messages. People using traps in production code -- for example to simulate infinitely-ranged integers -- aren't going to like

John Regehr wrote: > Hi Cameron, > > I agree, it would be nice to integrate this. My quick analysis of the > situation, however, was that there's probably some difference of opinion > about how heavyweight the trap handler should be. Ours is very heavy, in > order to produce informative messages. People using traps in production > code -- for example to simulate

http://blog.regehr.org/archives/761 Thanks, John

On Jul 26, 2012, at 9:58 AM, John Regehr wrote: > http://blog.regehr.org/archives/761 It's an interesting post, but I'd like to point out that it is a non-goal for the project to be actively hostile to users of the compiler. :) It is useful to have debugging tools for people who really care, but "exploiting" undefined behavior just for the sake of breaking code is a

> Indeed, but can't an analysis find at least one value for each variable > where the behavior is not undefined? > Such a value must exist, or the entire function is useless if it always > has undefined behavior. Good point :). > Sure, testing on 1 such value (or a random) value won't prove that the > result is correct, but may help finding trivial > miscompilations

Richard, I think adding the runtime undefined behavior checking and unifying the diagnostic output format is a great idea. This would probably be of interest to the LLVM Dev list as well. Anna. On Aug 10, 2012, at 7:48 PM, Richard Smith wrote: > Hi, > > There are three different (and mostly orthogonal, design-wise) areas where I would like to make improvements to Clang's

On Mar 16, 2011, at 9:31 AM, Cameron Zwarich wrote: > Promoting the return value is unsafe for bool returns on x86-64, which in the latest revision of the ABI only guarantees that the top 7 bits of the 8-bit register are 0. My comment is a bit off, because the question of what type to make the return value is somewhat orthogonal to the question of which zext assert we should add. Cameron

On Feb 16, 2013, at 1:31 PM, Cameron Zwarich <zwarich at apple.com> wrote: > That's exactly the right place. Really? You don't want the expansion to be optimized? You want to specify a machine model for the pseudo's as if they're real instructions? You don't want to schedule or register allocate the real instructions? -Andy > On Feb 16, 2013, at 1:08 PM, Reed

On Feb 8, 2013, at 4:37 PM, Cameron Zwarich <zwarich at apple.com> wrote: > On Feb 8, 2013, at 4:20 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: > >> On Feb 8, 2013, at 4:03 PM, Cameron Zwarich <zwarich at apple.com> wrote: >> >>> How much of the work is done here? I'd be happy to do the phi elimination part, since I basically did that

On Mon, Nov 21, 2011 at 1:03 PM, Michael Smith <Michael.Smith at synopsys.com> wrote: > Sorry, Dead Store Elimination. Hmm... does tweaking the value of BlockScanLimit in MemoryDependenceAnalysis.cpp help? -Eli > > > > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On > Behalf Of Michael Smith > Sent: Monday, November 21, 2011 12:20 PM

It looks like this problem only exists on nested loops, ideas? On Thu, Jan 12, 2012 at 11:44 AM, Ryan Taylor <ryta1203 at gmail.com> wrote: > Is it not a good idea to try and extract loops that have multiple exits? > > > On Thu, Jan 12, 2012 at 10:44 AM, Ryan Taylor <ryta1203 at gmail.com> wrote: > >> I am trying to use ExtractLoop() but I am getting segFaults:

As you all have undoubtedly noticed, I recently did Yet Another Merge to Apple's GCC top-of-tree. This merge was prompted by several important fixes in the "blocks" implementation. There are still many testcases that need to be moved over, but those can come at our leisure. I compiled both the "Apple way" and the "FSF way". It also passed the tests in

The allocator you are building, is it the Hack's and Goos's polynomial time algorithm? On Tue, Oct 5, 2010 at 7:14 PM, Cameron Zwarich <zwarich at apple.com> wrote: > There is nothing that currently handles this properly, as far as I know. If you have a phi > > c = phi(a, b) > > where a, b and c are all assigned distinct stack slots, then copies must be inserted in

Aye, between all current register allocators the 'AU.addRequiredID(PHIEliminationID);' will cause phi's to be eliminated to copies, but this misses the point of my question. What I am asking, is how does stack know that the value of the variable which the resulting value of the phi is currently allocated at. For instance take the instruction: Machine Basic Block (mbb) 12 reg16666 =

I'm getting the error below on Ubuntu Hardy on ia32 on r55688. John make[3]: Entering directory `/home/regehr/llvm-gcc/build/gcc' gcc -c -g -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wmissing-format-attribute -DHAVE_CONFIG_H -I. -I. -I../../gcc

On Feb 8, 2013, at 4:45 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote: > On Feb 8, 2013, at 4:37 PM, Cameron Zwarich <zwarich at apple.com> wrote: > >> I'll try doing that. Did you ever add a way to update LiveIntervals quickly after splitting an edge or will that have to finally be added? I can skip the critical edge splitting for now. > > That

On Jun 12, 2011, at 1:25 AM, Duncan Sands wrote: > Hi Sohail, > >> Is LLVM expressive enough to represent asynchronous exceptions? > > not currently. The first step in this direction is to get rid of the invoke > instruction and attach exception handling information to basic blocks. See > http://nondot.org/sabre/LLVMNotes/ExceptionHandlingChanges.txt > for a

Hello Cameron, thanks a lot for your fast answer, which just makes me curious if making ARM tailcalls on par with x86 in the future is on some of the development plans already? If not, then what do you think is the complexity of such work? Thanks! Karel On 06/17/11 10:41 PM, Cameron Zwarich wrote: > They work pretty well now, at least on Thumb2 / Darwin. It is still fairly conservative

Sorry, forgot to add group to CC. On Sun, Nov 20, 2011 at 6:14 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > Cameron, > > To make it less vague, I would ideally like to traverse top down. I > believe what you suggested is what I want, I will have a look at it. > > Currently, I am iterating over the BBs in a Function, so > Function::iterator BBitr=F->begin(),