Alexander Potapenko | 27 Aug 16:10 2014

Verifying unwind info/debugging a crash in _Unwind_Backtrace() on OSX

Hi all,

I'm debugging a crash in the guts of libunwind that started occuring
when I changed the ASan runtime to use _Unwind_Backtrace() on OSX to
report errors.
The crash happens for every test case that has an ASan report in it,
so I'm suspecting something's wrong with the unwind info generated by
the Xcode Clang, which I'm using to build my Clang and the ASan
runtime library (with either -funwind-tables or
GDB is also unable to unwind past a certain frame in the runtime library.

$ gdb ./p
==23138==ERROR: AddressSanitizer: stack-buffer-overflow on address
0x7fff5fbffad5 at pc 0x000100000e25 bp 0x7fff5fbffa30 sp
WRITE of size 1 at 0x7fff5fbffad5 thread T0
==26613==got pc: 0x00010004a17c
==26613==got pc: 0x00010003b199
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: 13 at address: 0x0000000000000000
0x00007fff8d734a81 in
(gdb) bt
#0  0x00007fff8d734a81 in
(Continue reading)

Rafael Espíndola | 27 Aug 16:00 2014

Debug info BOF


Has anyone proposed a BOF on debug info for the next dev meeting? The
one last year was quiet informative.

This year the date might coincide with me trying to figure out how to
make debug info processing lazier during LTO, so it would be an
awesome opportunity to discuss it with developers that are more
familiar with it :-)

Carsten Mattner | 27 Aug 15:40 2014

migrating from autoconf to cmake+ninja

I want to start using cmake+ninja instead of autoconf for configuring
and building llvm from svn, but I have no idea how to map my existing
list of autoconf flags to cmake.

Here's how I run ./configure right now in the top directory:
PREFIX=_some_prefix_dir_ \
    ../llvm/configure \
    --prefix=$PREFIX \
    --libdir=$PREFIX/lib/llvm \
    --sysconfdir=$PREFIX/etc \
    --enable-shared \
    --enable-targets=all \
    --disable-expensive-checks \
    --disable-debug-runtime \
    --disable-assertions \
    --with-binutils-include=/usr/include \

Is it possible to map this to cmake flags and if yes how?

Platform is linux-x86_64 and revision is release_35 branch.

If there's superfluous flags please do tell and I'll remove them.

Also is there a flag to skip tests?

Is building lld on linux supported? I tried including lld in the build
and it failed:
llvm[4]: Linking Release unit test CoreTest (without symbols)
/tmp/llvm/build/Release/lib/libgtest_main.a(TestMain.o): In function `main':
(Continue reading)

George King | 27 Aug 07:22 2014

Meaning of llvm-cov 'taken at least once'

Hi list,
Today I played around with the llvm-cov from the 3.5rc3 release; here
is an example of output:

Function 'main'
Lines executed:91.67% of 24
Branches executed:100.00% of 11
Taken at least once:81.82% of 11
No calls

What is the meaning of 'branches executed' versus 'taken at least
once'? I would imagine that the first implied the second, so I'm
clearly missing something.

Also, what is the alternative to 'no calls'? I see that in every
function in my single-file example; does it mean calls across
compilation units?

Pete Cooper | 27 Aug 02:33 2014

Re: [RFC] Removing static initializers for command line options

On Aug 26, 2014, at 5:31 PM, Chandler Carruth <chandlerc <at>> wrote:

On Tue, Aug 26, 2014 at 5:09 PM, Pete Cooper <peter_cooper <at>> wrote:
>> - I'd like to avoid a separate "option store". My current suggestion is to
>> use the LLVMContext, and to add a context to the layers which don't have an
>> LLVMContext and where these kinds of options make sense.
> I agree. There are few places in LLVM without a LLVMContext. For
> example, there is one cl::opt in lib/MC and Joerg already has a patch
> to turn it into a proper API.
I disagree with this point.  The majority of the fields of the context are IR.  An MC only tool should not be required to link the LLVM IR just because they want to use a command line option.

Sorry, this is my fault, I phrased something poorly.

When I said "add a context to the layers ..." I didn't mean to add an LLVMContext to them. I agree, that's crazy. =] I meant add some context object *for* that layer. Maybe an MCContext. This would *only* traffic in the shared context and state needed by that layer, not any other layer. If the layer needs these debug options, they can expose a generic interface from that context and the option management code will happily use it.

The reason I mention this is that I don't want us to develop N different objects which are essentially "side cars" to carry additional state around a layer of abstraction. We've been using LLVMContext to do that successfully at the IR layer. At other layers where we need to do the same, I'd like to add a single context *type* to represent that layer, and use objects of that type to pass around both options and any other common structures needed at that layer.
Sounds good.  Thanks for clarifying that.



LLVM Developers mailing list
LLVMdev <at>
Pete Cooper | 27 Aug 02:09 2014

Re: [RFC] Removing static initializers for command line options

> On Aug 26, 2014, at 11:52 AM, Rafael Espíndola <rafael.espindola <at>> wrote:
>> These "debugging knobs" or library level options which *aren't* exposed in
>> the library's APIs are very risky to expose in a side-channel API: they are
>> often completely unsupported or unsupportable options that were never
>> intended for "production" usage. Once we expose these options via some API
>> to library users, we run a very serious risk of getting locked into
>> supporting behaviors or debugging misbehavior that were never expected or
>> planned for...
> Agreed. This is my only real concern in here.
>> However, the debugging use case is real and important. So I want to propose
>> that we guard many of the paths to setting these options with NDEBUG so that
>> in non-asserts builds, library users can't override these options. This
>> would mean the C++ API for setting this in LLVMContext (and the C API if we
>> ever expose it there) would only support setting these in asserts builds. We
>> could even sink the checking into the registry. The name should probably
>> have "debug" in it somewhere. It would then have some
>> InternalUnsupportedScaryBad API which is not actually in the header files
>> but is used in LLVM's tools to maintain their current behavior without
>> documenting a public API. It's not bulletproof, but it seemed that it would
>> be sufficient for the debugging use cases and is a strong statement of
>> "unsupported" IMO.
> Just to be clear, the idea is that in a release build the only way of
> setting options is via the command line? That they can still be passed
> to opt or llc, but they would not be considered part of the API.
>> - I really like the idea of using a 'void*' derived from some static tag as
>> a way to identify uniquely each option. I also think we can use some minimal
>> "reflection" techniques to significantly simplify this.
> I like it too. The reason I do is that it is one more layer in a
> defense in depth against making our internal options part of the API.
> The key is not just a well known value (like a string).
>> - I'd like to avoid a separate "option store". My current suggestion is to
>> use the LLVMContext, and to add a context to the layers which don't have an
>> LLVMContext and where these kinds of options make sense.
> I agree. There are few places in LLVM without a LLVMContext. For
> example, there is one cl::opt in lib/MC and Joerg already has a patch
> to turn it into a proper API.
I disagree with this point.  The majority of the fields of the context are IR.  An MC only tool should not be
required to link the LLVM IR just because they want to use a command line option.

Chris’ suggestion is to make an OptionStore class and pass it throughout the APIs where we want to handle
options.  At first the store should be a global singleton.  Users of options don’t need to know about the
LLVMContext or any other unrelated data structure.  If the options are stored as a field of the context then
that can easily be done too.

If we later decide that the OptionStore should live in the LLVMContext or any other location then thats
fine, but moving it to that point would be a minimal change as no APIs have to be rewritten.  Also, if we decide
that we want the LLVMContext to have an option store, but MC level tools to be allowed to define their own,
then that would also be possible.

> Cheers,
> Rafael
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev <at>

LLVM Developers mailing list
LLVMdev <at>
Robin Morisset | 26 Aug 21:59 2014

PSA: changes to AtomicExpandLoadLinkedPass


Just in case anyone out-of-tree depends on AtomicExpandLoadLinkedPass (unlikely as it was rather ARM-specific), I feel I should warn that it has recently been renamed into AtomicExpandPass, and the interface with the target is changing. In particular shouldExpandAtomicInIR will soon be split into shouldExpandAtomicLoadInIR, shouldExpandAtomicStoreInIR,... (; and two new hooks emitLeadingFence and emitTrailingFence are being added (

Please tell me if you would like to keep being informed of changes to this interface as I may modify it again later.

Best regards,
Robin Morisset
LLVM Developers mailing list
LLVMdev <at>
Ramkumar Ramachandra | 26 Aug 21:37 2014

[BUG] Varargs example in LangRef segfaults


So the Variable Argument Handling Intrinsics section of the LangRef
lists an example that segfaults. Try the following on x86_64:

-- 8< --
define i32  <at> test(i32 %X, ...) {
  ; Initialize variable argument processing
  %ap = alloca i8*
  %ap2 = bitcast i8** %ap to i8*
  call void  <at> llvm.va_start(i8* %ap2)

  ; Read a single integer argument
  %tmp = va_arg i8** %ap, i32

  ; Demonstrate usage of llvm.va_copy and llvm.va_end
  %aq = alloca i8*
  %aq2 = bitcast i8** %aq to i8*
  call void  <at> llvm.va_copy(i8* %aq2, i8* %ap2)
  call void  <at> llvm.va_end(i8* %aq2)

  ; Stop processing of arguments.
  call void  <at> llvm.va_end(i8* %ap2)
  ret i32 %tmp

define i32  <at> main() {
  %call = call i32 (i32, ...)*  <at> test(i32 1, i32 3)
  ret i32 %call

declare void  <at> llvm.va_start(i8*)
declare void  <at> llvm.va_copy(i8*, i8*)
declare void  <at> llvm.va_end(i8*)
-- 8< --

It happens because va_arg is apparently not implemented properly on
X86 (I saw tests/Codegen/X86/vaargs.ll). What should be done about the
1. Update the LangRef.
2. Fix va_arg for x86.

If (2) is the way to go, I'll take a stab at it.


Steve King | 26 Aug 18:52 2014


I would like to improve llvm-objdump.  However, many unit tests depend
precisely on the current output, making the picture a little tricky.
My experience is limited to ELF format objects, so experts in other
formats please sanity check.

Suggested changes:
1) Symbolize conditional branch targets.  Currently, llvm-objdump
prints branch targets numerically regardless of -symbolize.

2) Make -symbolize the default behavior for human friendliness.

3) Add new -bare option to suppress symbolizing.  Many unit tests will
use -bare to preserve expected output in today's format.

4) When multiple symbols exist for a given address, print all of them.
Today, llvm-objdump only prints the last symbol found, but symbolizes
references with the first symbol found.  So, it's a bit of a mess.

5) When symbolizing code references, prefer matching symbols with type
FUNC, but fall back to matches with type NOTYPE.  This matches GNU
objdump behavior and many hand written assembly files don't specify
.type directives anyway.

How does this sound?

Oleg Ranevskyy | 26 Aug 21:20 2014

Bug 16257 - fmul of undef ConstantExpr not folded to undef

Hi Duncan,

Thank you for your comment to the bug 16257.

I am new to LLVM, so not all the aspects of LLVM's "undef" seem clear to me yet.
I read and understood the examples from the LLVM documentation:

However, those examples do not cover all of the possible contexts where "undef" can appear.
E.g., I can't realize why "fmul undef, undef" may not result in "undef" whereas "mul undef, undef" is always folded to "undef". Seems I am missing something important about floats here.

The same applies to "fdiv".
"fdiv undef, undef" is not folded but "div %X, undef" and "div undef, %X" are folded to "undef" (SimplifyFDivInst function in lib/Analysis/InstructionSimplify.cpp). Moreover, SimplifyFDivInst does not take into account whether signalling of SNaNs can be switched off or not - it always folds if one of the operands is "undef".

Another mysterious thing for me is folding of "mul %X, undef".
The result depends on whether %X is odd or even:
  • "undef" if %X is odd or equal to "undef";
  • 0 otherwise.
There is a similar bug 16258 about folding of "fadd undef, undef". "Add" gets folded to "undef" if one or both its operands are "undef".
Should "fadd" behave differently than integer "add" too?

I've tried to google these questions, scanned StackOverflow, but didn't find any good articles / posts answering them. LLVM's "undef" is covered quite poorly.

Duncan, do you know of any web resources explaining this in more detail?

Thank you in advance for any help.

Kind regards,
LLVM Developers mailing list
LLVMdev <at>
Kevin K O'Brien | 26 Aug 17:16 2014

Re: Multiply-add combining

Hi Olivier,
      I think we discussed this last Thursday? My feeling is that each use of the multiply can be considered separately. If it can be combined, then we should do so. The multiply should be left in place and removed by a dead code elimination pass sometime later. This is what TOBEY does. If you want me to explain the XL method in more detail, come talk to me.

Kevin O'Brien
Manager, Advanced Compiler Technology
IBM T.J Watson Research Center, Yorktown Heights, NY

Olivier H Sallenave---08/26/2014 11:12:04 AM---Hi, I tried to compile the following using -ffp-contract=fast:


Olivier H Sallenave/Watson/IBM


llvmdev <at>,


Samuel F Antao/Watson/IBM <at> IBMUS, Kevin K O'Brien/Watson/IBM <at> IBMUS


08/26/2014 11:12 AM


Multiply-add combining


I tried to compile the following using -ffp-contract=fast:

  %mul = fmul double %sub5, %x
  %add = fadd double %add6, %mul
  %sub = fsub double %sub5, %mul

I expected fadd and fsub to be contracted with fmul, which didn't happen.

When looking in DAGCombiner.cpp, it appears the result of the fmul needs to be used only once, which isn't the case here as it is used by both the fadd and the fsub:

    // fold (fadd (fmul x, y), z) -> (fma x, y, z)
    if (N0.getOpcode() == ISD::FMUL && N0.hasOneUse())
      return DAG.getNode(ISD::FMA, SDLoc(N), VT, N0.getOperand(0),
          N0.getOperand(1), N1);

This heuristic looks a little conservative, could we instead check that every instruction using the result of the fmul are combinable (i.e., they are either fadd or fsub)?

Thanks in advance,

LLVM Developers mailing list
LLVMdev <at>