Feature (or change?) request: "j1" and "j11"

[ereisch]

It appears as though with some of the newer compilers (I recently jumped from 12.0.4 to 15.0.2), "j1" and "j11" are now reserved symbols.  I'm getting very obscure errors from the linker about dwarf version 3, though the true error is just above this in that "j1" is defined in real/j1.c (which is also a function name in my program).  If this is an internal Fortran function that is not designed to be called externally, maybe it would be best to do some name mangling on it or put one of the usual "for__" prefixes on it?  I can also see people using such short names as global variables when linking with C programs, which could create the same error.

Thanks!

[Steven_L_Intel1]

There are no reserved words in Fortran and no intrinsics by those names. Please provide a test case that shows the error.

[ereisch]

My apologies for not including that earlier.  I created a simple program with those names and it didn't error out during the link.  Turns out, there need to be a couple conditions present to cause the offending library file to be pulled in.  First, the program must have the "DATAND" intrinsic used somewhere.  Additionally, the "-assume nounderscore", "-fimf-arch-consistency=true", and "-O0" flags must be set during compile.  Here is my compile line:

ifort -assume nounderscore -fimf-arch-consistency=true -O0 -m32 -o j1_test j1_test.for

Please excuse any typos in the attached routine.

According to the link map, the offending routine is pulled in by libimf.a(bitwisereproducible.o), which is pulled in by __bwr_atand().

Thanks again

[Steven_L_Intel1]

Thanks. libimf is part of the Intel math library, it is not Fortran specific.  We'll take a closer look.

[Steven_L_Intel1]

I can reproduce the duplicate symbol error for j1, though not any errors about Dwarf nor j11. Even so, it's a problem and I escalated it to development as issue DPD200372589. Thanks for the nice example. 

A fundamental problem is that there is no established convention on Linux (nor Windows) for keeping user and system/tool namespaces separate. I was once a developer on VMS and from the start there was a documented naming convention that would not have allowed this conflict to happen. Even so, "j1" is an inappropriate choice for an internal library routine or global.

[ereisch]

Thanks Steve.  I can't speak for Windows, but I do know a number of internal library calls at the system level on Linux usually will start with double-underscores.  I personally like the "for__" convention you guys seem to have at least partially adopted -- it makes it easy to differentiate Intel/Fortran functions from system functions in profiling reports and the like.

For reference, the specific error I'm getting is:

/opt/intel/composerxe-2015.2.164/bin/ia32/../../compiler/lib/ia32/libimf.a(j1.o): In function 'j1':

real/j1.c:(.text+0x420): multiple definition of 'j1'

ld: Dwarf Error: found dwarf version '3', this reader only handles version 2 information.

j1_test.o:/j1_test.for:(.text+0x0): first defined here

Note: using GNU ld (GNU binutils for Debian) 2.18.0.20080103.  I do not get the Dwarf error when using a newer version of binutils.  I get a slightly different message when using an older version:

/opt/intel/composerxe-2015.2.164/bin/ia32/../../compiler/lib/ia32/libimf.a(j1.o): In function 'j1':

real/j1.c:(.text+0x420): multiple definition of 'j1'

ld: Dwarf Error: found dwarf version '3', this reader only handles version 2 information.

j1_test.o:/j1_test.for:(.text+0x0): first defined here

ld: Warning: size of symbol 'j1' changed from 540 in j1_test.o to 1376 in /opt/intel/composerxe-2015.2.164/bin/ia32/../../compiler/lib/ia32/libimf.a(j1.o)

The above was using GNU ld version 2.17.50.0.6-26.el5 20061020.

I can't seem to reproduce the j11 error.  I suspect the Dwarf errors are red herrings caused by the symbol conflict and don't represent a true incompatibility in the code.  But that's just speculation.

Thanks again.

[Steven_L_Intel1]

Right - we use for__ for Fortran run-time routines, but math library routines also called from C don't have that liberty. Still, it seems that this j1 is an internal routine and they could do better.

[Lorri_M_Intel]

Related to the DWARF issue; the default version of dwarf debugging information we output is at DWARF-3.

If you want to use a lower version, please try adding -gdwarf-2 to your command line.  I'm not sure what was improved in the dwarf-3 interface, but at least by using dwarf-2 you can debug something.

Finally, the compiler *tries* to differentiate the external names created for user routines by postfixing an underscore.

I'm not trying to create any excuses for my colleagues in libimf (I agree with Steve that "j1" is not unique enough), but could we try and resolve your problem by looking at why you need the "assume nounderscore" switch?

Are you calling C routines?   Are you creating routines to be called from C routines?  Are you calling system routines?

          Thanks -

                               --Lorri

[ereisch]

Sorry for not clarifying this earlier -- I already implemented a workaround by renaming my local function to something else (it was fortunately only referenced in one other file).  I just wanted to report the issue in case anyone else was encountering it.

We include the nounderscore directive because we have heavy intermixing of C and Fortran (and one or two other languages) in our Fortran source.

Thanks again

[Steven_L_Intel1]

Our math library developers note that, while they agree the choice of "j1" as a library function name is unfortunate, it is the generally accepted name for this Bessel function and is present by that name in glibc. There isn't anything we can do about this. 

[Matt_Thompson]

Steve Lionel (Intel) wrote:

Our math library developers note that, while they agree the choice of "j1" as a library function name is unfortunate, it is the generally accepted name for this Bessel function and is present by that name in glibc. There isn't anything we can do about this. 

I am glad the Standards Committee decided on BESSEL_J1/BESSEL_JN for the Bessel function in Fortran. I never knew that math.h just coded it as j1, etc.