[llvm-commits] [llvm] r61030 - in /llvm/trunk: include/llvm/Attributes.h lib/AsmParser/llvmAsmParser.y lib/Bitcode/Writer/BitcodeWriter.cpp lib/VMCore/Attributes.cpp

[Bill Wendling]

On Tue, Dec 16, 2008 at 12:57 AM, Nick Lewycky <nicholas at mxc.ca> wrote:
> Bill Wendling wrote:
>> Nick,
>>
>> You patch r61019 is causing a bootstrap failure on PPC. Here's the
>> minimal testcase and the error:
>>
>> $ cat testcase.i
>> struct S {
>>    unsigned long long f1;
>>    unsigned long long f2;
>> };
>> static void func2(struct S);
>> void func1() {
>>    struct S a;
>>    func2(a);
>> }
>>
>> $ Volumes/SandBox/NightlyTest/test/llvm-gcc.obj/./prev-gcc/xgcc -B/
>> Volumes/SandBox/NightlyTest/test/llvm\
>> -gcc.obj/./prev-gcc/ -B/Volumes/SandBox/NightlyTest/test/llvm-
>> gcc.install/powerpc-apple-darwin9.5.0/bin\
>> / -c testcase.i
>> bash-3.2$ bash-3.2$ Assertion failed: (isPowerOf2_32(i) && "Alignment
>> must be a power of two."), functi\
>> on constructAlignmentFromInt, file /Volumes/SandBox/NightlyTest/test/
>> llvm.src/include/llvm/Attributes.h\
>> , line 81.
>> testcase.i: In function 'func1':
>> testcase.i:6: internal compiler error: Abort trap
>> Please submit a full bug report,
>> with preprocessed source if appropriate.
>> See <URL:http://developer.apple.com/bugreporter> for instructions.
>>
>> Unfortunately, this occurs in the front-end, so I can't create a .bc
>> file. Here is the backtrace:
>>
>> (gdb) bt
>> #0  0x95bfd278 in abort ()
>> #1  0x95bec904 in __assert_rtn ()
>> #2  0x0093396c in llvm::Attribute::constructAlignmentFromInt ()
>> #3  0x00862a6c in DefaultABI<(anonymous
>> namespace)::FunctionTypeConversion>::HandleArgument ()
>> #4  0x0084b4ec in TypeConverter::ConvertFunctionType ()
>> #5  0x007cf6fc in make_decl_llvm ()
>> #6  0x007e3790 in llvm_get_decl ()
>> #7  0x007e6fe0 in TreeToLLVM::EmitLV_DECL ()
>> #8  0x00816dcc in TreeToLLVM::EmitLV ()
>> #9  0x0081e7fc in TreeToLLVM::EmitADDR_EXPR ()
>> #10 0x00802734 in TreeToLLVM::Emit ()
>> #11 0x00801988 in TreeToLLVM::EmitCALL_EXPR ()
>> #12 0x00802750 in TreeToLLVM::Emit ()
>> #13 0x0081f558 in TreeToLLVM::EmitFunction ()
>> #14 0x007d22a4 in llvm_emit_code_for_current_function ()
>> #15 0x0018c3a8 in tree_rest_of_compilation ()
>> #16 0x0002d9bc in c_expand_body ()
>> #17 0x008df4dc in cgraph_expand_function ()
>> #18 0x008dba94 in cgraph_assemble_pending_functions ()
>> #19 0x008dc01c in cgraph_finalize_function ()
>> #20 0x0002d854 in finish_function ()
>> #21 0x000d88a0 in c_parser_declaration_or_fndef ()
>> #22 0x000d7afc in c_parser_external_declaration ()
>> #23 0x000d7968 in c_parser_translation_unit ()
>> #24 0x000eb214 in c_parse_file ()
>> #25 0x000c35dc in c_common_parse_file ()
>> #26 0x0070688c in compile_file ()
>> #27 0x007095e0 in do_compile ()
>> #28 0x00709680 in toplev_main ()
>> #29 0x0010b308 in main ()
>>
>> Could you back-out your changes and investigate?
>
> I'll do that if we can't resolve this quickly, but it's complicated by
> the fact that other patches have already gone in which depend on this
> one. I think it's just r61019 r61030 r61040 so far.
>
> The crash you pasted should only happen if there's a mismatch between
> LLVM and llvm-gcc versions. To be exact, it looks like llvm-gcc was
> picking up the newer Attribute.h from LLVM, while still linking against
> an older version of the LLVM libraries (perhaps installed in the system?).
>
> Could you please check to make sure that's not the case? If you're sure,
> I'll be happy to go ahead and back this change out (or you can do it if
> you like), but I want to be sure firts.
>
Hi Nick,

It failed again last night, which was r61086. It was using the correct
header files.

-bw