Bug 88467

This is because 4.4 doesn't support anonymous unions.  Adam Jackson is working on trying to get that backported to 4.4 at least for RHEL6.

So after some discussion on IRC, apparently OpenBSD is still using GCC 4.2, and there's no easy way to compile Mesa with a different compiler than the default. So it seems like we might have to remove the anonymous union usage after all.

Actually, it seems even GCC 4.2 supports anonymous unions with the -std=gnu99 flag, so it should just be a matter of passing the right flags.

-std=gnu99 with gcc 4.2.1 won't handle the initialisers however
and looks to only be supported in gcc 4.6 going by

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10676

../../src/glsl/nir/nir_from_ssa.c: In function 'isolate_phi_nodes_block':
../../src/glsl/nir/nir_from_ssa.c:387: error: unknown field 'ssa' specified in initializer
../../src/glsl/nir/nir_from_ssa.c:387: warning: missing braces around initializer
../../src/glsl/nir/nir_from_ssa.c:387: warning: (near initialization for 'entry_dest_src.<anonymous>')
../../src/glsl/nir/nir_from_ssa.c:387: warning: initialization from incompatible pointer type
../../src/glsl/nir/nir_from_ssa.c: In function 'emit_copy':
../../src/glsl/nir/nir_from_ssa.c:624: error: unknown field 'reg' specified in initializer
../../src/glsl/nir/nir_from_ssa.c:624: warning: missing braces around initializer
../../src/glsl/nir/nir_from_ssa.c:624: warning: (near initialization for 'dest.<anonymous>')
../../src/glsl/nir/nir_from_ssa.c:625: error: unknown field 'reg' specified in initializer
../../src/glsl/nir/nir_from_ssa.c:626: error: unknown field 'reg' specified in initializer
../../src/glsl/nir/nir_from_ssa.c:626: warning: excess elements in struct initializer
../../src/glsl/nir/nir_from_ssa.c:626: warning: (near initialization for 'dest')
../../src/glsl/nir/nir_from_ssa.c: In function 'resolve_parallel_copy':
../../src/glsl/nir/nir_from_ssa.c:724: error: unknown field 'reg' specified in initializer
../../src/glsl/nir/nir_from_ssa.c:724: warning: missing braces around initializer
../../src/glsl/nir/nir_from_ssa.c:724: warning: (near initialization for 'dest_src.<anonymous>')
../../src/glsl/nir/nir_from_ssa.c:725: error: unknown field 'reg' specified in initializer
../../src/glsl/nir/nir_from_ssa.c:726: error: unknown field 'reg' specified in initializer
../../src/glsl/nir/nir_from_ssa.c:726: warning: excess elements in struct initializer
../../src/glsl/nir/nir_from_ssa.c:726: warning: (near initialization for 'dest_src')

That's fixable and we'll need to fix it for MSVC2013 as well.

This is actually more annoying

with gcc 4.4

gcc -std=gnu99 supports anonymous structs, but doesn't support designated initialisers for anonymous structs.

I'm not really sure what we can do now, I've built with -std=gnu99 and now get less warnings but all the designated initalisers are fail.

I've filed a bug against the RHEL gcc to hopefully fix at least the designated initialiser vs anonymous struct/union issue.

https://bugzilla.redhat.com/show_bug.cgi?id=1184346

RHEL builds can use devtoolset for newer versions of GCC.

that doesn't help with our internal builds for inclusion in RHEL, they have to build with the system compiler.

(In reply to Dave Airlie from comment #6)
> This is actually more annoying
> 
> with gcc 4.4
> 
> gcc -std=gnu99 supports anonymous structs, but doesn't support designated
> initialisers for anonymous structs.
> 
> I'm not really sure what we can do now, I've built with -std=gnu99 and now
> get less warnings but all the designated initalisers are fail.

I've been meaning to get rid of those.  They don't work properly on msvc either.  I'll kick out a patch later today and note it on the bug.

(In reply to Jason Ekstrand from comment #10)
> (In reply to Dave Airlie from comment #6)
> > This is actually more annoying
> > 
> > with gcc 4.4
> > 
> > gcc -std=gnu99 supports anonymous structs, but doesn't support designated
> > initialisers for anonymous structs.
> > 
> > I'm not really sure what we can do now, I've built with -std=gnu99 and now
> > get less warnings but all the designated initalisers are fail.
> 
> I've been meaning to get rid of those.  They don't work properly on msvc
> either.  I'll kick out a patch later today and note it on the bug.

I just dropped the patches on the list.  If a branch is better, it can be found here:

http://cgit.freedesktop.org/~jekstrand/mesa/log/?h=review/src-constructors

Jason,

MSVC 2013 supports designated initialisers yet the VMWare guys cannot migrate to it yet iirc.

On the anonymous unions - perhaps we can nuke them by naming them ? There have been similar problems in the past, and this was the most comfortable/flexible fix.

Just my 2c (in case anyone is interested) :)

(In reply to Emil Velikov from comment #12)
> Jason,
> 
> MSVC 2013 supports designated initialisers yet the VMWare guys cannot
> migrate to it yet iirc.
> 
> On the anonymous unions - perhaps we can nuke them by naming them ? There
> have been similar problems in the past, and this was the most
> comfortable/flexible fix.
> 
> Just my 2c (in case anyone is interested) :)

It does... sort-of.  Unfortunately, the fact that they don't work with unions is a well-documented bug in MSVC 2013.

I definitely don't want to remove the anonymous union from nir_src. We use it all over the place, and it really helps with readability and writeability. Without it, we would have to say "src[n].src.src.ssa" or "src[n].src.src.reg" for ALU sources, which just seems silly.

(In reply to Connor Abbott from comment #14)
> I definitely don't want to remove the anonymous union from nir_src. We use
> it all over the place, and it really helps with readability and
> writeability. Without it, we would have to say "src[n].src.src.ssa" or
> "src[n].src.src.reg" for ALU sources, which just seems silly.

The anonymous union isn't the problem.  That's fine with --std=gnu99.  The problem is that they don't work with designated initializers.  Now that those are gone, NIR builds just fine with --std=gnu99.  We're just waiting for patch review to finish on the configure.ac patch and we'll be building on GCC 4.4 again.

(In reply to Jason Ekstrand from comment #15)
> (In reply to Connor Abbott from comment #14)
> > I definitely don't want to remove the anonymous union from nir_src. We use
> > it all over the place, and it really helps with readability and
> > writeability. Without it, we would have to say "src[n].src.src.ssa" or
> > "src[n].src.src.reg" for ALU sources, which just seems silly.
> 
> The anonymous union isn't the problem.  That's fine with --std=gnu99.  The
> problem is that they don't work with designated initializers.  Now that
> those are gone, NIR builds just fine with --std=gnu99.  We're just waiting
> for patch review to finish on the configure.ac patch and we'll be building
> on GCC 4.4 again.

Sure, I was just replying to Emil's suggestion.

(In reply to Connor Abbott from comment #16)
> (In reply to Jason Ekstrand from comment #15)
> > (In reply to Connor Abbott from comment #14)
> > > I definitely don't want to remove the anonymous union from nir_src. We use
> > > it all over the place, and it really helps with readability and
> > > writeability. Without it, we would have to say "src[n].src.src.ssa" or
> > > "src[n].src.src.reg" for ALU sources, which just seems silly.
> > 
> > The anonymous union isn't the problem.  That's fine with --std=gnu99.  The
> > problem is that they don't work with designated initializers.  Now that
> > those are gone, NIR builds just fine with --std=gnu99.  We're just waiting
> > for patch review to finish on the configure.ac patch and we'll be building
> > on GCC 4.4 again.
> 
> Sure, I was just replying to Emil's suggestion.

Sure.  I guess I wasn't reading carefully enough.

(In reply to Jason Ekstrand from comment #13)
> (In reply to Emil Velikov from comment #12)
> > Jason,
> > 
> > MSVC 2013 supports designated initialisers yet the VMWare guys cannot
> > migrate to it yet iirc.
> > 
> It does... sort-of.  Unfortunately, the fact that they don't work with
> unions is a well-documented bug in MSVC 2013.
>
/me was thinking that he tried such a scenario, but most likely he was confused.

(In reply to Connor Abbott from comment #14)
> I definitely don't want to remove the anonymous union from nir_src. We use
> it all over the place,
Indeed. There is also nir_dest and nir_const_value. So that suggestion goes down in flames.

> and it really helps with readability and
> writeability. Without it, we would have to say "src[n].src.src.ssa" or
> "src[n].src.src.reg" for ALU sources, which just seems silly.
There are a handful of other silly things around :)

Thanks for the help/input guys.

This should be fixed in master now.