search for: release_351

A change between r231216 and r231221 causes an assertion failure on the LLDB FreeBSD bot. The compiler is FreeBSD's in-tree one: FreeBSD clang version 3.5.1 (tags/RELEASE_351/final 225668) 20150115 First failing build: http://lab.llvm.org:8011/builders/lldb-x86_64-freebsd/builds/4668/steps/compile/logs/stdio Assertion: Assertion failed: ((!DD->isTrivial() || DD->hasAttr<DLLExportAttr>()) && "Should not emit dtor epilogue for non-exported trivi...

...ter type (and many others), but not a named structure pointer type. E.g. %x = type [1 x i32]* ; valid. %x = type {i32}* ; invalid. Is this the intended behaviour? Attaching a.ll, b.ll, c.ll and d.ll for reference. All files except d.ll compiles without error using clang version 3.5.1 (tags/RELEASE_351/final). > $ clang d.ll > d.ll:3:16: error: expected top-level entity > %x = type {i32}* > ^ > 1 error generated. Does it have anything to do with type equality? (just a hunch) * Item 2 - equality of named types A named integer type is equivalent to its literal...

...%x = type [1 x i32]* ; valid. >>> %x = type {i32}* ; invalid. >>> >>> Is this the intended behaviour? Attaching a.ll, b.ll, c.ll and d.ll for >>> reference. All files except d.ll compiles without error using clang >>> version >>> 3.5.1 (tags/RELEASE_351/final). >>> >>> $ clang d.ll >>>> d.ll:3:16: error: expected top-level entity >>>> %x = type {i32}* >>>> ^ >>>> 1 error generated. >>>> >>> >>> Does it have anything to do with type equa...

...ter type. E.g. >> >> %x = type [1 x i32]* ; valid. >> %x = type {i32}* ; invalid. >> >> Is this the intended behaviour? Attaching a.ll, b.ll, c.ll and d.ll for >> reference. All files except d.ll compiles without error using clang version >> 3.5.1 (tags/RELEASE_351/final). >> >>> $ clang d.ll >>> d.ll:3:16: error: expected top-level entity >>> %x = type {i32}* >>> ^ >>> 1 error generated. >> >> Does it have anything to do with type equality? (just a hunch) >> >> * Item...

I am trying to locate instructions in an LLVM Pass by line and column number (reported by an third-party tool) to instrument them. To achieve this, I am compiling my source files with `clang -g -O0 -emit-llvm` and looking for the information in the metadata using this code: const DebugLoc &location = instruction->getDebugLoc(); // location.getLine() // location.getCol()

...gt;>>>>> Is this the intended behaviour? Attaching a.ll, b.ll, c.ll and d.ll >>>>>>> for >>>>>>> reference. All files except d.ll compiles without error using clang >>>>>>> version >>>>>>> 3.5.1 (tags/RELEASE_351/final). >>>>>>> >>>>>>> $ clang d.ll >>>>>>> >>>>>>> d.ll:3:16: error: expected top-level entity >>>>>>>> %x = type {i32}* >>>>>>>> ^ >>&gt...