Bug 88467

Summary: nir.c:140: error: ‘nir_src’ has no member named ‘ssa’
Product: Mesa Reporter: Vinson Lee <vlee>
Component: Mesa coreAssignee: Adam Jackson <ajax>
Status: RESOLVED FIXED QA Contact: mesa-dev
Severity: blocker    
Priority: medium CC: airlied, jason
Version: gitKeywords: regression
Hardware: x86-64 (AMD64)   
OS: All   
Whiteboard:
i915 platform: i915 features:

Description Vinson Lee 2015-01-15 17:02:06 UTC
mesa: 0d05d1226e0f51f703e0dcbf736375ee4f252473 (master 10.5.0-devel)

Build error with GCC 4.4.

  CC     nir.lo
In file included from ../../src/glsl/nir/nir.c:28:
../../src/glsl/nir/nir.h:471: warning: declaration does not declare anything
../../src/glsl/nir/nir.h:480: warning: declaration does not declare anything
In file included from ../../src/glsl/nir/nir.c:28:
../../src/glsl/nir/nir.h:955: warning: declaration does not declare anything
../../src/glsl/nir/nir.c: In function ‘nir_src_copy’:
../../src/glsl/nir/nir.c:140: error: ‘nir_src’ has no member named ‘ssa’
Comment 1 Jason Ekstrand 2015-01-15 17:49:18 UTC
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.
Comment 2 Connor Abbott 2015-01-15 18:53:33 UTC
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.
Comment 3 Connor Abbott 2015-01-15 18:58:59 UTC
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.
Comment 4 Jonathan Gray 2015-01-16 12:01:14 UTC
-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')
Comment 5 Jason Ekstrand 2015-01-16 15:08:13 UTC
That's fixable and we'll need to fix it for MSVC2013 as well.
Comment 6 Dave Airlie 2015-01-21 07:01:33 UTC
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.
Comment 7 Dave Airlie 2015-01-21 07:11:13 UTC
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
Comment 8 Vinson Lee 2015-01-21 07:43:36 UTC
RHEL builds can use devtoolset for newer versions of GCC.
Comment 9 Dave Airlie 2015-01-21 08:21:52 UTC
that doesn't help with our internal builds for inclusion in RHEL, they have to build with the system compiler.
Comment 10 Jason Ekstrand 2015-01-21 15:09:48 UTC
(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.
Comment 11 Jason Ekstrand 2015-01-21 19:15:38 UTC
(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
Comment 12 Emil Velikov 2015-01-22 19:09:30 UTC
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) :)
Comment 13 Jason Ekstrand 2015-01-22 19:12:10 UTC
(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.
Comment 14 Connor Abbott 2015-01-22 19:50:02 UTC
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.
Comment 15 Jason Ekstrand 2015-01-22 19:52:09 UTC
(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.
Comment 16 Connor Abbott 2015-01-22 19:54:28 UTC
(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.
Comment 17 Jason Ekstrand 2015-01-22 19:58:34 UTC
(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.
Comment 18 Emil Velikov 2015-01-22 21:14:47 UTC
(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.
Comment 19 Jason Ekstrand 2015-01-27 01:31:23 UTC
This should be fixed in master now.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.