I didn't see those warning on my mac when I compiled but gcc does indeed
complain if -pedantic is specified without the -std=c99 option. So, in order to
use the initialization style we would need to specify -std=c99 option for gcc.
Not sure if there would be a problem specifying -std=c99?
-Nathan
On Thu, 20 Jan 2011, George Bosilca wrote:
Even before getting into the Oracle compiler, a fully compliant C99 compiler
such as gcc 4.2.1 complains a lot about the new code. Here is what I get:
../../../../../ompi/orte/mca/debugger/dummy/dummy_component.c:25: warning: ISO
C90 forbids specifying subobject to initialize
../../../../../ompi/orte/mca/debugger/dummy/dummy_component.c:28: warning: ISO
C90 forbids specifying subobject to initialize
../../../../../ompi/orte/mca/debugger/dummy/dummy_component.c:29: warning: ISO
C90 forbids specifying subobject to initialize
../../../../../ompi/orte/mca/debugger/dummy/dummy_component.c:30: warning: ISO
C90 forbids specifying subobject to initialize
../../../../../ompi/orte/mca/debugger/dummy/dummy_component.c:31: warning: ISO
C90 forbids specifying subobject to initialize
../../../../../ompi/orte/mca/debugger/dummy/dummy_component.c:33: warning: ISO
C90 forbids specifying subobject to initialize
../../../../../ompi/orte/mca/debugger/dummy/dummy_component.c:34: warning: ISO
C90 forbids specifying subobject to initialize
../../../../../ompi/orte/mca/debugger/dummy/dummy_component.c:35: warning: ISO
C90 forbids specifying subobject to initialize
../../../../../ompi/orte/mca/debugger/dummy/dummy_component.c:37: warning: ISO
C90 forbids specifying subobject to initialize
../../../../../ompi/orte/mca/debugger/dummy/dummy_component.c:39: warning: ISO
C90 forbids specifying subobject to initialize
../../../../../ompi/orte/mca/debugger/dummy/dummy_component.c: In function
'component_open':
../../../../../ompi/orte/mca/debugger/dummy/dummy_component.c:45: warning:
unused variable 'c'
../../../../../ompi/orte/mca/debugger/dummy/dummy.c:67: warning: ISO C90
forbids specifying subobject to initialize
../../../../../ompi/orte/mca/debugger/dummy/dummy.c:68: warning: ISO C90
forbids specifying subobject to initialize
../../../../../ompi/orte/mca/debugger/dummy/dummy.c:69: warning: ISO C90
forbids specifying subobject to initialize
../../../../../ompi/orte/mca/debugger/dummy/dummy.c:70: warning: ISO C90
forbids specifying subobject to initialize
george.
On Jan 19, 2011, at 20:36 , Terry Dontje wrote:
Hopefully we'll find out tomorrow but I think I vaguely remember an issue with
the Studio compilers and this type of initialization style.
--td
On 01/19/2011 05:22 PM, Nathan Hjelm wrote:
Done. I added the module orte/mca/debugger/dummy and I will remove it tomorrow.
-Nathan
HPC-3, LANL
On Wed, 19 Jan 2011, Jeff Squyres wrote:
+1 on Ralph and George's comments.
Want to make a dummy component somewhere that uses this kind of initialization
and see what happens? Put a test for the C99 initialization style in
configure.m4 to see if it works or not; MTT will then check this for
all the compilers that we care about.
On Jan 19, 2011, at 3:58 PM, Ralph Castain wrote:
I believe the majority of structs used in OMPI are actually declared to be opal
objects of some flavor, so I'm not sure how much this will actually
accomplish. Other than that, I have no real objection - either way works fine
for me.
On Jan 19, 2011, at 12:29 PM, George Bosilca wrote:
I'm with you on that. Let's create a fake module using the ISO C99 naming
scheme, and leave it to MTT to figure out where is breaks!
george.
On Jan 19, 2011, at 14:23 , Nathan Hjelm wrote:
I don't know if this has been discussed before or if this will break Windows
(or some obscure platform) support but I would like to start using the ISO C99
style for struct initialization (see section 6.7.8, example 10 in
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf). Using this style
would make mca code much easier to read. Any thoughts? Would this break
something?
Example:
struct module_foo {
char *bar;
int baz;
};
struct foo foobar = {
.bar = "foobar",
.baz = 1
};
-Nathan
HPC-3, LANL
_______________________________________________
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel
_______________________________________________
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel
_______________________________________________
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
_______________________________________________
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel
_______________________________________________
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel
--
<Mail Attachment.gif>
Terry D. Dontje | Principal Software Engineer
Developer Tools Engineering | +1.781.442.2631
Oracle - Performance Technologies
95 Network Drive, Burlington, MA 01803
Email terry.don...@oracle.com
_______________________________________________
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel
_______________________________________________
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel
