Bug 93189 - "./util/u_inlines.h", line 83: operands have incompatible types: void ":" int
Summary: "./util/u_inlines.h", line 83: operands have incompatible types: void ":" int
Status: RESOLVED WONTFIX
Alias: None
Product: Mesa
Classification: Unclassified
Component: Mesa core (show other bugs)
Version: git
Hardware: x86 (IA32) Solaris
: medium normal
Assignee: mesa-dev
QA Contact: mesa-dev
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-12-01 08:23 UTC by Vinson Lee
Modified: 2015-12-02 07:55 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Vinson Lee 2015-12-01 08:23:05 UTC
mesa: 750393ff7d6162372f368f5ed726b23f4cae49a0 (11.2.0-devel)

Oracle Solaris Studio build error

  CC     cso_cache/cso_context.lo
"./util/u_inlines.h", line 83: operands have incompatible types:
         void ":" int
Comment 1 Alan Coopersmith 2015-12-01 08:26:20 UTC
Mesa cannot be built with non-gcc compilers, no matter how many bugs you cc me on.
Comment 2 Jose Fonseca 2015-12-01 15:46:26 UTC
Vinson, Alan,


If Oracle itself has no interest on building Mesa with Solaris Sudio component, let's save everybody's time by making that dependency crystal clear.


That is, let's just modify configure.ac to abort if Mesa is not built with a supported compiler (ie, GCC, Clang, or MSVC).


Or maybe, instead of a whitelist, do a blacklist (ie, detect Solaris CC and abort.)  As that might be more future proof (e.g., if another GCC look-alike compiler appears in the future.)


Anybody knows a reliable way to detect Solaris CC on configure.ac?
Comment 3 Alan Coopersmith 2015-12-01 16:04:55 UTC
There was interest in the past, but trying to keep up is too hard and the
benefit too small, so we've just given up and build Mesa with gcc now.
Comment 4 Alan Coopersmith 2015-12-01 16:09:55 UTC
(In reply to Jose Fonseca from comment #2)
> Anybody knows a reliable way to detect Solaris CC on configure.ac?

Whoops, missed this part.   It's easy - autoconf will set $GCC to "no".
A more definitive way involves checking if the C compiler defines
__SUNPRO_C or the C++ compiler defines __SUNPRO_CC - for instance, in
the xorg-macros.m4 for autoconf, see the XORG_COMPILER_BRAND macro:

http://cgit.freedesktop.org/xorg/util/macros/tree/xorg-macros.m4.in?id=util-macros-1.19.0#n1500
Comment 5 Ian Romanick 2015-12-01 19:39:49 UTC
(In reply to Jose Fonseca from comment #2)
> Vinson, Alan,
> 
> 
> If Oracle itself has no interest on building Mesa with Solaris Sudio
> component, let's save everybody's time by making that dependency crystal
> clear.

I would tend to agree, but I looked at the code in question:

define p_atomic_inc(v) (void) (\
   sizeof(*v) == sizeof(uint8_t)  ? atomic_inc_8 ((uint8_t  *)(v)) : \
   sizeof(*v) == sizeof(uint16_t) ? atomic_inc_16((uint16_t *)(v)) : \
   sizeof(*v) == sizeof(uint32_t) ? atomic_inc_32((uint32_t *)(v)) : \
   sizeof(*v) == sizeof(uint64_t) ? atomic_inc_64((uint64_t *)(v)) : \
                                    (assert(!"should not get here"), 0))

I don't think that would build on any compiler... and it doesn't seem that hard to fix.

static inline _p_atomic_inc(void *v, size_t s)
{
    assert(s == sizeof(uint8_t) ||
           s == sizeof(uint16_t) ||
           s == sizeof(uint32_t) ||
           s == sizeof(uint64_t));

    switch (s) {
    case sizeof(uint8_t):  atomic_inc_8 ((uint8_t  *)(v)); break;
    case sizeof(uint16_t): atomic_inc_16((uint16_t *)(v)); break;
    case sizeof(uint32_t): atomic_inc_32((uint32_t *)(v)); break;
    case sizeof(uint64_t): atomic_inc_64((uint64_t *)(v)); break;
    default: unreachable("Bad size");
    }
}

#define p_atomic_inc(v) _p_atomic_inc(v, sizeof(*v))

One could probably create a macro or two to generate the other functions.
Comment 6 Matt Turner 2015-12-01 20:15:02 UTC
The point of the ternary magic is to make the macros typeless, like gcc's atomic ops built-ins (https://gcc.gnu.org/onlinedocs/gcc-4.4.5/gcc/Atomic-Builtins.html)

The problem is that a bunch of them have to return a value and you can't do that without statement-expressions which is unsupported by MSVC.


In this particular case, the problem seems to be that we're doing the (assert(...), 0) trick on a place where the atomic doesn't have to return a value. Wouldn't it be fine to just change 0 -> (void)0?

But I think I've already spent way too long on this. Vinson, please do not file bugs about Oracle Solaris Studio compile errors. Patches are of course welcome.
Comment 7 Jose Fonseca 2015-12-01 23:12:25 UTC
It doesn't make sense to spend time on supporting platforms for which there are no active developers.

Keeping Mesa compiling across GCC and MSVC is already quite time consuming.

I posted a couple of patches to mesa-dev for review that explicitly refuse to build with Sun CC and remove special code we had for it.
Comment 8 Jose Fonseca 2015-12-02 07:55:41 UTC
So as of commit 51564f04b77e6d29a888a4fbd83d96de062ac634 we officially require GCC on Solaris.

Thanks.


bug/show.html.tmpl processed on Mar 30, 2017 at 04:50:37.
(provided by the Example extension).