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

[Evan Cheng]

Rats. Is it possible to find a previous revision (with r61122 patch  
applied) when it bootstrapped?

Thanks,

Evan

On Dec 17, 2008, at 12:50 AM, Bill Wendling wrote:

> It's still failing with the same error (that the .o files differ).
>
> -bw
>
> On Dec 16, 2008, at 11:39 PM, Evan Cheng wrote:
>
>> You may want to check if r61122 fixed all the bootstrapping issues?
>> It's likely r61030 is not the real cause.
>>
>> Evan
>>
>> On Dec 16, 2008, at 8:25 PM, Nick Lewycky wrote:
>>
>>> Bill Wendling wrote:
>>>> On Tue, Dec 16, 2008 at 10:53 AM, Bill Wendling
>>>> <isanbard at gmail.com> wrote:
>>>>> 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.
>>>>>
>>>> Now it's failing on X86 in release mode. I'm going to go ahead and
>>>> revert those patches.
>>>
>>> Thanks Bill! I'll try to reproduce this locally and if I can't, I'll
>>> give you a buzz.
>>>
>>> Nick
>>>
>>>>
>>>> -bw
>>>> _______________________________________________
>>>> llvm-commits mailing list
>>>> llvm-commits at cs.uiuc.edu
>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>>>>
>>>
>>> _______________________________________________
>>> llvm-commits mailing list
>>> llvm-commits at cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>>
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits