similar to: [LLVMdev] [cfe-dev] Unexpected results from _Bool cast

He wants to be able to resume execution from the debugger after assertion failure. Reid On Tue, Jul 26, 2011 at 8:07 PM, Alistair Lynn <arplynn at gmail.com> wrote: > Hi- > >> Yep, but tripping the debugger is highly non-portable. > > You're suggesting that inline asm is more portable than calling abort? > > Alistair > >

wrapping the macro's body in: do { ... } while (false) would make the the macro a proper statement so that: if (cond) ASSERT(some_other_cond); else do_something_cool (); compiles as expected. IMO, it would work as such #define ASSERT_STM(cond,expr) On Tue, Jul 26, 2011 at 6:36 PM, Reid Kleckner <reid.kleckner at gmail.com>wrote: > He wants to be able to resume execution

sorry, my previous message got sent too early I think the macro should look something like this: #define ASSERT_STRM(cond,expr) \ do { if (cond) { std::cerr << expr << std::end; assertion_trap (); } } while (false) On Tue, Jul 26, 2011 at 7:57 PM, Nathan Jeffords <blunted2night at gmail.com>wrote: > wrapping the macro's body in: > > do { ... } while

Great suggestion - what should the !NDEBUG version look like? On Tue, Jul 26, 2011 at 8:01 PM, Nathan Jeffords <blunted2night at gmail.com>wrote: > sorry, my previous message got sent too early > > I think the macro should look something like this: > > #define ASSERT_STRM(cond,expr) \ > do { > if (cond) { > std::cerr << expr << std::end; >

Hi- > Yep, but tripping the debugger is highly non-portable. You're suggesting that inline asm is more portable than calling abort? Alistair

"The fact that the loop is unrolled explains why the XORs, SHLs, and ORs are not folded into 1." I dont see why the unrolling explains it. "I think he is trying to say this expression generated by unrolling by a factor of 4 can indeed be folded into a single XOR, SHL and OR. " Precisely. The code generated by unrolling can be folded into a single XOR and SHL. And even if it

Hi- > I haven't seen a machine in which OR is faster than ADD nor more energy-efficient. They're all done by the same ALU circuitry which delays the pipeline by its worstcase path timing. So, for modern processor hardware purposes, OR is exactly equal ADD. Transforming ADD to OR isn't strenght reduction at all. Maybe this is benefical only if you have a backend generating circuitry

Here's an example of how this would be used: In the constructor for ConstantVector, there's an assert: assert(C->getType() == T->getElementType() && "Initializer for vector element doesn't match vector element type!"); I would change this to: ASSERT_STRM(C->getType() == T->getElementType(), "Initializer for vector element "

I didn't see swapcontext in the list in gcc's special_function_p function... -bw On May 26, 2010, at 2:20 PM, Alistair Lynn wrote: > Hello- > > Shouldn't this catch swapcontext as well? > > Alistair > > On 26 May 2010, at 22:14, Dale Johannesen wrote: > >> >> On May 26, 2010, at 2:05 PMPDT, Dan Gohman wrote: >> >>> vfork and

Yeah I had a think about it, and I think intrinsics are the wrong way to do it. So I'd say you are likely right. Bill. On 13 June 2010 04:33, Alistair Lynn <arplynn at gmail.com> wrote: > Hi Bill- > > I think, ideally, the backend would be able to match arbitrary-precision arithmetic to add-with-carry or subtract-with-borrow through i65/i33. That would remove the need for the

I'm trying to: Resample with replacement pairs of distinct rows from a 120 x 65,000 matrix H of 0's and 1's. For each resampled pair sum the resulting 2 x 65,000 matrix by column: 0 1 0 1 ... + 0 0 1 1 ... _______ = 0 1 1 2 ... For each column accumulate the number of 0's, 1's and 2's over the resamples to obtain a 3 x 65,000 matrix G. For those

On Jul 1, 2011, at 2:43 PM, Alistair Lynn wrote: > Hi Andrew- > >> fatal error: error in backend: SSE2 register return with SSE2 disabled > > Is this for 32-bit or 64-bit x86? 64-bit x86. > If it's the latter, the ABI demands > that the return value in this case is in xmm0 - SSE is required. > Well -no-sse -mno-mmx works for EFI as it is pre-boot firmware and

Hello- Shouldn't this catch swapcontext as well? Alistair On 26 May 2010, at 22:14, Dale Johannesen wrote: > > On May 26, 2010, at 2:05 PMPDT, Dan Gohman wrote: > >> vfork and getcontext have wildly platform-dependent semantics. >> Handling >> them conservatively is reasonable, even if some platforms don't need >> it. >> >> Dan >

Hi David- On 26 Apr 2010, at 21:05, David Greene wrote: > What's a "trap" and "trap value?" Is it some C++0X or Java thing? > It needs to be defined. See LangRef.html Alistair

On Apr 26, 2010, at 1:15 PM, Alistair Lynn wrote: > Hi David- > > On 26 Apr 2010, at 21:05, David Greene wrote: > >> What's a "trap" and "trap value?" Is it some C++0X or Java thing? >> It needs to be defined. > > See LangRef.html Yes; it was just added 4 days ago, for an unrelated purpose. It's an interesting concept which on the

Hello R-users: I am using "yags" for fitting GEE which is giving me the same result as "Proc GENMOD". Now I have couple of questions related to yags output. (By the way, someone told me to run the geeglm for the same analysis and I did run but did not get the same result as of genmod and don't know how to correct the geeglm codes so that all three will be same!)

It's past 3 AM here, so maybe I really shouldn't be answering in this state of awakeness. However, what I understand from your example is that loops with counters must be entered from another block in order to use the phi instruction correctly, not that it should be invalid to branch to the entry block. It seems to me that it makes sense to go back to the entry point if looping is not

Hi Andrew- > fatal error: error in backend: SSE2 register return with SSE2 disabled Is this for 32-bit or 64-bit x86? If it's the latter, the ABI demands that the return value in this case is in xmm0 - SSE is required. Alistair

Hi Andrew- > Well -no-sse -mno-mmx works for EFI as it is pre-boot firmware and does not have any floating point C code. We use -no-sse and -mno-mmx code to prevent optimized code gen using these registers for optimizations. Whether it's optimised or not doesn't particularly matter, the x86_64 ABI says that floating-point return values go into SSE registers, so that is where LLVM is

Hi Bill- I think, ideally, the backend would be able to match arbitrary-precision arithmetic to add-with-carry or subtract-with-borrow through i65/i33. That would remove the need for the overflow intrinsics entirely. Alistair On 13 Jun 2010, at 02:27, Bill Hart wrote: > I was able to get the loop to increment from -999 to 0 using IR > directly. That got rid of the cmpq. > > The