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

Nicolai Hähnle via llvm-dev llvm-dev at lists.llvm.org
Mon Jan 23 07:42:23 PST 2017


There's a regression in AMDGPU which would be nice to get resolved, see:

https://bugs.freedesktop.org/show_bug.cgi?id=99078
https://bugs.launchpad.net/ubuntu/+source/llvm-toolchain-3.9/+bug/1656620?comments=all

I think it's reasonably low-risk to back-port

AMDGPU: Reduce the duration of whole-quad-mode
AMDGPU: Do not clobber SCC in SIWholeQuadMode

since they've been in trunk and hence the Padoka PPA for Ubuntu for 
several months and I'm not aware of any bugs reported since then. 
Alternatively, we could revert

AMDGPU: Fix an interaction between WQM and polygon stippling

to go back to how things were in 3.9 -- this re-introduces a low-impact 
bug, but would fix the high-impact bug linked above.

Nicolai

On 23.01.2017 15:58, Tom Stellard via llvm-dev 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> 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
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>


More information about the llvm-dev mailing list