Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Development mailing list

Subject: Re: [OMPI devel] dummy component warnings
From: Nathan Hjelm (hjelmn_at_[hidden])
Date: 2011-01-25 18:01:15


Damn! I will remove the offending code now.

-Nathan
HPC-3, LANL

On Tue, 25 Jan 2011, Jeff Squyres wrote:

> FWIW, we might have a deal breaker back here at Cisco...
>
> The OMPI code base is being used in an embedded environment with a toolchain that (we think) was derived from gcc 3.x. It seems to totally hate the -std=gnu99 flag. :-(
>
> Further, it is extremely unlikely that the toolchain will be upgraded (this is something beyond our control).
>
> Cisco must therefore vote "thumbs down" on the C99 stuff.
>
> Sorry guys! :-(
>
>
>
> On Jan 25, 2011, at 5:51 PM, Paul H. Hargrove wrote:
>
>> I found a root cause and a simpler/better simple fix:
>>
>> From manpage for gcc on Linux:
>>> file.s
>>> Assembler code.
>>
>> And from Darwin:
>>
>>> file.s
>>> Assembler code. Apple's version of GCC runs the preprocessor on these files as well as
>>> those ending in .S.
>>
>> So the problem/difference is that Apple insists on passing the .s through the preprocessor by default when FSF's gcc does not.
>> The fix appears to be an explict "-xassembler":
>>
>> $ cat foo.s
>> .text
>> # _gsym_test_func
>> .globl _gsym_test_func
>> _gsym_test_func:
>> # _gsym_test_func
>>
>> $ gcc -std=c99 -c foo.s
>> foo.s:2:3: error: invalid preprocessing directive #_gsym_test_func
>> foo.s:5:3: error: invalid preprocessing directive #_gsym_test_func
>>
>> $ gcc -std=c99 -c -xassembler foo.s
>> [no output]
>>
>> -Paul
>>
>>
>> On 1/25/2011 2:48 PM, Nathan Hjelm wrote:
>>> Ok, then there are two possible simple fixes:
>>> - Strip -std from CCASFLAGS if Apple's gcc 4.0 is encountered, or
>>> - Always strip -std from CCASFLAGS. The flag shouln't have any effect when compiling assembly.
>>>
>>> -Nathan
>>> HPC-3, LANL
>>>
>>> On Tue, 25 Jan 2011, Paul H. Hargrove wrote:
>>>
>>>> I can confirm that the problem appears specific to Apple's compiler.
>>>>
>>>> Since the failure was reported to be configure-time, that took less time to check up on that I'd expected.
>>>> What I find is that gcc-4.0.0 on Linux/x86 *does* fail the "#_gsym_test_func" test, but for the RIGHT reason, and then goes on to
>>>> pass the next test case with the proper form of global symbol. The relevent portion of config.log appears below.
>>>>
>>>> -Paul
>>>>
>>>> configure:27399: checking prefix for global symbol labels
>>>> configure: trying _
>>>> configure:27439: gcc -std=gnu99 -O3 -DNDEBUG -finline-functions -fno-strict-aliasing -c conftest.s >conftest.out 2>&1
>>>> configure:27442: $? = 0
>>>> configure:27447: gcc -std=gnu99 -O3 -DNDEBUG -finline-functions -fno-strict-aliasing -I. conftest_c.c -c > conftest.cmpl 2>&1
>>>> configure:27450: $? = 0
>>>> configure:27455: gcc -std=gnu99 -O3 -DNDEBUG -finline-functions -fno-strict-aliasing conftest_c.o conftest.o -o conftest >
>>>> conftest.link 2>&1
>>>> configure:27458: $? = 1
>>>> conftest_c.o: In function `main':
>>>> conftest_c.o(.text+0xd): undefined reference to `gsym_test_func'
>>>> collect2: ld returned 1 exit status
>>>> configure: failed C program was:
>>>> #ifdef __cplusplus
>>>> extern "C" {
>>>> #endif
>>>> void gsym_test_func(void);
>>>> #ifdef __cplusplus
>>>> }
>>>> #endif
>>>> int
>>>> main()
>>>> {
>>>> gsym_test_func();
>>>> return 0;
>>>> }
>>>> configure: failed ASM program was:
>>>>
>>>> .text
>>>> # _gsym_test_func
>>>> .globl _gsym_test_func
>>>> _gsym_test_func:
>>>> # _gsym_test_func
>>>>
>>>> configure: trying
>>>> configure:27439: gcc -std=gnu99 -O3 -DNDEBUG -finline-functions -fno-strict-aliasing -c conftest.s >conftest.out 2>&1
>>>> configure:27442: $? = 0
>>>> configure:27447: gcc -std=gnu99 -O3 -DNDEBUG -finline-functions -fno-strict-aliasing -I. conftest_c.c -c > conftest.cmpl 2>&1
>>>> configure:27450: $? = 0
>>>> configure:27455: gcc -std=gnu99 -O3 -DNDEBUG -finline-functions -fno-strict-aliasing conftest_c.o conftest.o -o conftest >
>>>> conftest.link 2>&1
>>>> configure:27458: $? = 0
>>>> configure:27496: result:
>>>>
>>>>
>>>>
>>>>
>>>> On 1/25/2011 2:19 PM, Paul H. Hargrove wrote:
>>>> I have gcc-4.0.0 on Linux built from unmodified FSF sources.
>>>> I will try to reproduce.
>>>>
>>>> -Paul
>>>>
>>>> On 1/25/2011 1:47 PM, Nathan Hjelm wrote:
>>>> Looks like a bug in Apple's gcc 4.0. I tried the source with gcc 3.4.6 and gcc 4.1.2 on Linux and did not
>>>> see that error.
>>>>
>>>> I will take a look and see if there is a simple fix to get around this apparent compiler bug.
>>>>
>>>> -Nathan
>>>>
>>>> On Tue, 25 Jan 2011, Jeff Squyres wrote:
>>>>
>>>> Short version
>>>> =============
>>>>
>>>> MTT turned up a problem with -std=gnu99 on OS X Leopard, which ships with the gcc 4.0
>>>> compiler (OS X Snow Leopard ships with gcc 4.2, and doesn't have a problem). Does anyone
>>>> have gcc 4.0 on Linux? I'm wondering if the same problem would occur.
>>>>
>>>> More details:
>>>> =============
>>>>
>>>> From our friends at Absoft:
>>>>
>>>>
>>>> -----
>>>> The -std=gnu99 is causing the problem when used with gcc-4.0 ( the default on Leopard with
>>>> Apple's XCode 3.1 development tools ):
>>>>
>>>> BigMac:ompi cag$ gcc --version -std=gnu99 -c conftest.s
>>>> conftest.s:2:3: error: invalid preprocessing directive #_gsym_test_func
>>>> conftest.s:5:3: error: invalid preprocessing directive #_gsym_test_func
>>>> BigMac:ompi cag$ gcc-4.0 -std=gnu99 -c conftest.s
>>>> conftest.s:2:3: error: invalid preprocessing directive #_gsym_test_func
>>>> conftest.s:5:3: error: invalid preprocessing directive #_gsym_test_func
>>>> BigMac:ompi cag$ gcc-4.2 -std=gnu99 -c conftest.s
>>>> BigMac:ompi cag$
>>>>
>>>> On Snow Leopard with Apple's XCode 3.2 development tools, the default compiler is 4.2.
>>>> -----
>>>>
>>>> The compile line he's talking about in particular is from a configure test in
>>>> opal/config/opal_config_asm.m4, where we're looking for assembly global symbols. The source
>>>> that we're trying to compile is:
>>>>
>>>> -----
>>>> .text
>>>> # _gsym_test_func
>>>> .globl _gsym_test_func
>>>> _gsym_test_func:
>>>> # _gsym_test_func
>>>> -----
>>>>
>>>> (configure tries a few prefixes)
>>>>
>>>> But the "#" token with the -std=gnu99 option is causing failures where it shouldn't (i.e., it
>>>> causes configure to abort because all the assembly tests looking for the global symbols error
>>>> out due to the # token.
>>>>
>>>> So I think we either need to find a workaround for this assembly test or whack the idea of
>>>> the C99 stuff. :-(
>>>>
>>>>
>>>>
>>>> On Jan 24, 2011, at 10:29 AM, Nathan Hjelm wrote:
>>>>
>>>> No, they didn't get added (adding them now). I didn't get a chance to add them
>>>> over the weekend.
>>>>
>>>> -Nathan
>>>>
>>>> On Mon, 24 Jan 2011, Jeff Squyres wrote:
>>>>
>>>> I'm getting these:
>>>>
>>>> CC dummy_component.lo
>>>> dummy_component.c:25: warning: ISO C90 forbids specifying subobject
>>>> to initialize
>>>> dummy_component.c:28: warning: ISO C90 forbids specifying subobject
>>>> to initialize
>>>> dummy_component.c:29: warning: ISO C90 forbids specifying subobject
>>>> to initialize
>>>> dummy_component.c:30: warning: ISO C90 forbids specifying subobject
>>>> to initialize
>>>> dummy_component.c:31: warning: ISO C90 forbids specifying subobject
>>>> to initialize
>>>> dummy_component.c:33: warning: ISO C90 forbids specifying subobject
>>>> to initialize
>>>> dummy_component.c:34: warning: ISO C90 forbids specifying subobject
>>>> to initialize
>>>> dummy_component.c:35: warning: ISO C90 forbids specifying subobject
>>>> to initialize
>>>> dummy_component.c:37: warning: ISO C90 forbids specifying subobject
>>>> to initialize
>>>> dummy_component.c:39: warning: ISO C90 forbids specifying subobject
>>>> to initialize
>>>> dummy_component.c: In function ‘component_open’:
>>>> dummy_component.c:45: warning: unused variable ‘c’
>>>> dummy.c:67: warning: ISO C90 forbids specifying subobject to
>>>> initialize
>>>> dummy.c:68: warning: ISO C90 forbids specifying subobject to
>>>> initialize
>>>> dummy.c:69: warning: ISO C90 forbids specifying subobject to
>>>> initialize
>>>> dummy.c:70: warning: ISO C90 forbids specifying subobject to
>>>> initialize
>>>> CCLD mca_debugger_dummy.la
>>>>
>>>> Did the autoconf tests not get added?
>>>>
>>>> --
>>>> Jeff Squyres
>>>> jsquyres_at_[hidden]
>>>> For corporate legal information go to:
>>>> http://www.cisco.com/web/about/doing_business/legal/cri/
>>>>
>>>>
>>>> _______________________________________________
>>>> devel mailing list
>>>> devel_at_[hidden]
>>>> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>>>>
>>>> _______________________________________________
>>>> devel mailing list
>>>> devel_at_[hidden]
>>>> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>>>>
>>>>
>>>>
>>>> --
>>>> Jeff Squyres
>>>> jsquyres_at_[hidden]
>>>> For corporate legal information go to:
>>>> http://www.cisco.com/web/about/doing_business/legal/cri/
>>>>
>>>>
>>>> _______________________________________________
>>>> devel mailing list
>>>> devel_at_[hidden]
>>>> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>>>>
>>>> _______________________________________________
>>>> devel mailing list
>>>> devel_at_[hidden]
>>>> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>>>>
>>>>
>>>> --
>>>> Paul H. Hargrove PHHargrove_at_[hidden]
>>>> Future Technologies Group
>>>> HPC Research Department Tel: +1-510-495-2352
>>>> Lawrence Berkeley National Laboratory Fax: +1-510-486-6900
>>>>
>>>>
>>>> _______________________________________________
>>>> devel mailing list
>>>> devel_at_[hidden]
>>>> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>>>>
>>>>
>>>> --
>>>> Paul H. Hargrove PHHargrove_at_[hidden]
>>>> Future Technologies Group
>>>> HPC Research Department Tel: +1-510-495-2352
>>>> Lawrence Berkeley National Laboratory Fax: +1-510-486-6900
>>>>
>>>>
>>>
>>> _______________________________________________
>>> devel mailing list
>>>
>>> devel_at_[hidden]
>>> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>>
>> --
>> Paul H. Hargrove
>> PHHargrove_at_[hidden]
>>
>> Future Technologies Group
>> HPC Research Department Tel: +1-510-495-2352
>> Lawrence Berkeley National Laboratory Fax: +1-510-486-6900
>>
>> _______________________________________________
>> devel mailing list
>> devel_at_[hidden]
>> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>
>
> --
> Jeff Squyres
> jsquyres_at_[hidden]
> For corporate legal information go to:
> http://www.cisco.com/web/about/doing_business/legal/cri/
>
>
> _______________________________________________
> devel mailing list
> devel_at_[hidden]
> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>