3.9 regression with legacy static assert macros (bad type resolution)

Project Infrastructure LLVM Dev List Archives
1

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.

--Jeremy

2

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).

Fred

3

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

4

Can we still check patches into 3.9.1?

5

It already shipped AFAIK: LLVM Download Page

6

+Tom : is there a plan for a 3.9.2?

7

+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

8

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

https://bugs.freedesktop.org/show_bug.cgi?id=99078

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

9

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?

10

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

99078 – Desktop icons oversaturated with red after December 11 2016 update
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.

Can you file a bug for this?

-Tom

11

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

12

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

99078 – Desktop icons oversaturated with red after December 11 2016 update
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.

Can you file a bug for this?

Done: https://llvm.org/bugs/show_bug.cgi?id=31722

Nicolai

13

+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