[llvm-dev] 3.9 regression with legacy static assert macros (bad type resolution)

Mehdi Amini via llvm-dev llvm-dev at lists.llvm.org
Mon Jan 23 08:39:27 PST 2017


Oh Nicolai reported it this morning, sorry for the noise!

> On Jan 23, 2017, at 8:32 AM, Mehdi Amini via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> There is a bug with Mesa and AMDGPU that folks would be very happy to see resolved I believe, do you know about it or do you need a reference?
> 
>> Mehdi
> 
>> On Jan 23, 2017, at 6:58 AM, Tom Stellard <tom at stellard.net <mailto: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?
>> 
>> -Tom
>> 
>>>>>> Mehdi
>>> 
>>>> On Dec 27, 2016, at 10:30 AM, Mehdi Amini <mehdi.amini at apple.com <mailto:mehdi.amini at apple.com>> wrote:
>>>> 
>>>> It already shipped AFAIK: http://releases.llvm.org/download.html <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 <mailto: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 <mailto:jeremyhu at apple.com>> wrote:
>>>>>> 
>>>>>> 
>>>>>>> On Dec 23, 2016, at 11:17, Frédéric Riss <friss at apple.com <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto:llvm-dev at lists.llvm.org>
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <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 --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170123/642f481e/attachment.html>


More information about the llvm-dev mailing list