[llvm-dev] 3.9 regression with legacy static assert macros (bad type resolution)
Jeremy Huddleston Sequoia via llvm-dev
llvm-dev at lists.llvm.org
Mon Jan 23 13:21:08 PST 2017
> On Jan 23, 2017, at 06:58, Tom Stellard <tom at stellard.net> wrote:
>
> On Tue, Dec 27, 2016 at 10:30:56AM -0800, Mehdi Amini via llvm-dev wrote:
>> +Tom : is there a plan for a 3.9.2?
>>
>
> I don't have a plan for 3.9.2, but I'm not opposed to doing one if there
> is enough interest.
>
> Jeremy can you file a bug for this against version 3.9 for this issue?
Done: https://llvm.org/bugs/show_bug.cgi?id=31725
>
> -Tom
>
>> —
>> Mehdi
>>
>>> On Dec 27, 2016, at 10:30 AM, Mehdi Amini <mehdi.amini at apple.com> wrote:
>>>
>>> It already shipped AFAIK: http://releases.llvm.org/download.html
>>>
>>> —
>>> Mehdi
>>>
>>>> On Dec 27, 2016, at 9:55 AM, Akira Hatanaka via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>>>>
>>>> Can we still check patches into 3.9.1?
>>>>
>>>>> On Dec 24, 2016, at 1:47 AM, Jeremy Huddleston Sequoia <jeremyhu at apple.com> wrote:
>>>>>
>>>>>
>>>>>> On Dec 23, 2016, at 11:17, Frédéric Riss <friss at apple.com> wrote:
>>>>>>
>>>>>>
>>>>>>> On Dec 22, 2016, at 9:36 PM, Jeremy Huddleston Sequoia via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>>>>>>>
>>>>>>> 3.9.0 and current release_39 (r90413) have issues with older static assertion macros like this one from an older libunwind:
>>>>>>>
>>>>>>> #define COMPILE_TIME_ASSERT( expr ) \
>>>>>>> extern int compile_time_assert_failed[ ( expr ) ? 1 : -1 ] __attribute__( ( unused ) );
>>>>>>>
>>>>>>> I notice that the issue is fixed on current trunk. Does anyone know what revision introduced the fix? Can we get it cherry-picked into release_39? I know 3.9.1 final was just tagged, but having it on the branch will make it easier for distributions to find since this is a fairly common pattern, and of course it would be good to fix this regression in 3.9.2 if there is one
>>>>>>
>>>>>> I think this was fixed in r280330 (in clang).
>>>>>
>>>>> Thanks. That indeed looks like it. I'll pull that into our patchset, but could we get that cherry-picked onto release_39 to benefit others as well?
>>>>>
>>>>> Thanks,
>>>>> Jeremy
>>>>>
>>>>>
>>>>>>
>>>>>> Fred
>>>>>>
>>>>>>>
>>>>>>> --Jeremy
>>>>>>>
>>>>>>>
>>>>>>> ---
>>>>>>>
>>>>>>> ~ $ clang++-mp-3.9 -Wno-invalid-offsetof -c macho_relocatable_file.cpp
>>>>>>> In file included from src/ld/parsers/macho_relocatable_file.cpp:37:
>>>>>>> src/ld/parsers/libunwind/DwarfInstructions.hpp:920:13: error: redeclaration of 'compile_time_assert_failed' with a different type: 'int [((int)CFI_Parser<A>::kMaxRegisterNumber > (int)DW_X86_64_RET_ADDR) ? 1 : -1]' vs
>>>>>>> 'int [1]'
>>>>>>> extern int compile_time_assert_failed[ ( (int)CFI_Parser<A>::kMaxRegisterNumber > (int)DW_X86_64_RET_ADDR ) ? 1 : -1 ] __attribute__( ( unused ) );;
>>>>>>> ^
>>>>>>> src/ld/parsers/libunwind/Registers.hpp:548:13: note: previous declaration is here
>>>>>>> extern int compile_time_assert_failed[ ( sizeof(Registers_ppc) < sizeof(unw_context_t) ) ? 1 : -1 ] __attribute__( ( unused ) );;
>>>>>>> ^
>>>>>>> In file included from src/ld/parsers/macho_relocatable_file.cpp:37:
>>>>>>> src/ld/parsers/libunwind/DwarfInstructions.hpp:1311:13: error: redeclaration of 'compile_time_assert_failed' with a different type: 'int [((int)CFI_Parser<A>::kMaxRegisterNumber > (int)DW_X86_RET_ADDR) ? 1 : -1]' vs
>>>>>>> 'int [1]'
>>>>>>> extern int compile_time_assert_failed[ ( (int)CFI_Parser<A>::kMaxRegisterNumber > (int)DW_X86_RET_ADDR ) ? 1 : -1 ] __attribute__( ( unused ) );;
>>>>>>> ^
>>>>>>> src/ld/parsers/libunwind/Registers.hpp:548:13: note: previous declaration is here
>>>>>>> extern int compile_time_assert_failed[ ( sizeof(Registers_ppc) < sizeof(unw_context_t) ) ? 1 : -1 ] __attribute__( ( unused ) );;
>>>>>>> ^
>>>>>>> In file included from src/ld/parsers/macho_relocatable_file.cpp:37:
>>>>>>> src/ld/parsers/libunwind/DwarfInstructions.hpp:1677:13: error: redeclaration of 'compile_time_assert_failed' with a different type: 'int [((int)CFI_Parser<A>::kMaxRegisterNumber > (int)UNW_PPC_SPEFSCR) ? 1 : -1]' vs
>>>>>>> 'int [1]'
>>>>>>> extern int compile_time_assert_failed[ ( (int)CFI_Parser<A>::kMaxRegisterNumber > (int)UNW_PPC_SPEFSCR ) ? 1 : -1 ] __attribute__( ( unused ) );;
>>>>>>> ^
>>>>>>> src/ld/parsers/libunwind/Registers.hpp:548:13: note: previous declaration is here
>>>>>>> extern int compile_time_assert_failed[ ( sizeof(Registers_ppc) < sizeof(unw_context_t) ) ? 1 : -1 ] __attribute__( ( unused ) );;
>>>>>>> ^
>>>>>>> 3 errors generated.
>>>>>>>
>>>>>>> ~ $ clang++-mp-3.8 -Wno-invalid-offsetof -c macho_relocatable_file.cpp
>>>>>>>
>>>>>>> ~ $ clang++-mp-devel -Wno-invalid-offsetof -c macho_relocatable_file.cpp
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> LLVM Developers mailing list
>>>>>>> llvm-dev at lists.llvm.org
>>>>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> LLVM Developers mailing list
>>>> llvm-dev at lists.llvm.org
>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4465 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170123/3e123971/attachment.bin>
More information about the llvm-dev
mailing list