PGI Workstation x86_64 Interix/SUA - beginners questions

Accelerated Computing HPC Compilers Legacy PGI Compilers
#1

Greeetings all,
As an Interix user on x64 I was excited to hear about PGIs compiler. At the moment there is only one other compiler available AFAIK. I downloaded an evaluation version for x64 SUA and installed it. Unfortunatly the installer failed due to wrong permissions applied to the installed directories (it removed all permissions). After some tweaks and a couple of reinstallations, I managed to get it right (I think). It would be advisable to update the installer, it really needs to be fool-proof. The 2 weeks evaluation period is also far too short.

When I did my first test compile I run into a bug: The -largeaddressaware:no linker switch needs to be added to ldrc(121).

When compiling e.g. test compile of GNU make I get some strange warnings:

PGC-W-0114-More than one type specified (/opt/pgi/sua64/7.0-6/include/sys/types.h: 143)
PGC-W-0143-Useless typedef declaration (no declarators present) (/opt/pgi/sua64/7.0-6/include/sys/types.h: 143)
PGC-W-0115-Duplicate standard type (/opt/pgi/sua64/7.0-6/include/sys/types.h: 148)
PGC-W-0143-Useless typedef declaration (no declarators present) (/opt/pgi/sua64/7.0-6/include/sys/types.h: 148)
PGC-W-0114-More than one type specified (/opt/pgi/sua64/7.0-6/include/sys/types.h: 256)
PGC-W-0143-Useless typedef declaration (no declarators present) (/opt/pgi/sua64/7.0-6/include/sys/types.h: 256)

I can’t figure out why.

The compiler includes the Interix gcc.3.3 x86 headers and libs - are you sure this is right?

What about gcc shared libraries? Are they supported in x64 and if so, how to enable, create and use them? Since the linker ultimately is the MS x64 linker, it would be interesting to hear if you have found a solution of this.

Thanks
Jerker

#2

Seems like noone is monitoring … anyway

sys/types.h(143) => typedef u_int32_t uid_t;
which expands to
typedef unsigned int u_int32_t;
pgcc appears to choke on typedefs on typedefs? This behavior causes pgcc to fail some configure scripts resulting in wrong configuration. Is there any switches that need to be assigned?

I concluded that shared libraries are not supported in Interix by PGI.

#3

Hi Jerker,

Unfortunatly the installer failed due to wrong permissions applied to the installed directories (it removed all permissions).

I’ll pass this on.

The 2 weeks evaluation period is also far too short.

Please contact PGI Sales at sales@pgroup.com. They can usually extend this for you.

When I did my first test compile I run into a bug: The -largeaddressaware:no linker switch needs to be added to ldrc(121).

Can you please describe the bug?

When compiling e.g. test compile of GNU make I get some strange warnings:

It appears to me that for these messages that “uid_t” might be getting declared elsewhere. However, I’m unable to recreate the issue here so am not positive. What include files are you using? What command line arguments are you using?

The compiler includes the Interix gcc.3.3 x86 headers and libs - are you sure this is right?

Yes. A few of GNU header files are not interoperable with PGI compilers and needed to be rewritten. However, we do try to keep the header files as close to the original version as possible.

What about gcc shared libraries? Are they supported in x64 and if so, how to enable, create and use them? Since the linker ultimately is the MS x64 linker, it would be interesting to hear if you have found a solution of this.

We have been working closely with Microsoft on creating a linker which will be able to create shared libraries on 32-bit SFU. This linker will be available with the 7.0-7 release. Prior releases and 64-bit SUA do not support GNU style shared libraries.

  • Mat
#4

I appears to me that for these messages that “uid_t” might be getting declared elsewhere. However, I’m unable to recreate the issue here so am not positive. What include files are you using? What command line arguments are you using?

It did that to me to as well, so I checked the Interix SDK headers. Some defines are guarded with GNUC and _MSC_VER - quite unnecessary actually - so I unified them and removed the compiler conditionals. That is: First part of types.h, inttypes.h where int64_t and friends are defined. There is no duplicate uid_t define, but there are exact duplicates of other defines in the headers, of size_t for example. My stdint.h is edited to pass the autoconf C99 test (carefully done!). There could be some detail inflicted by me somewhere causing the problem, one never know. However, gcc, icl and the MS compiler have no problem.

It seems to me that pgcc have problems with typedefs like this:
typedef unsigned long long int uint64_t;

I was thinking there could be a switch like “enable ANSI C”-whatever missing.

Typical commandline : pgcc -O1 -D_ALL_SOURCE -o testapp testapp.c

Can you please describe the bug?

I don’t remember exactly what the message was, but the linker complains about “ADDR32” conversion without this switch in the PGI libraries and refuse to link. I’m using the MS x64 linker 8.00.50727.762 (VS2005 SP1).

7.0-7 release for SUA

Something to look forward to, I think! So, will this release have a GNU-style ld or a MS linker interface?

#5

Hi Jerker,

While it does sound like you know what you’re doing, modifying system include files is generally not a good idea. Unfortunately, I don’t have any good advice for you except to try it with the original headers. Note that these are just warnings so may be ignored. However, I leave this up to you.

It seems to me that pgcc have problems with typedefs like this:
typedef unsigned long long int uint64_t;

Can you please give an example of the problem you see? The following toy program is able to handle this typedef without any issue.

%cat myt.c
typedef unsigned long long int uint64_t;
typedef uint64_t myi64_t;
void main () {
   myi64_t i;
   i = 123123123;
   printf("%ld\n", i);
}
%pgcc myt.c
%./a.out
123123123



I was thinking there could be a switch like “enable ANSI C”-whatever missing.

Can you please clarify?

I don’t remember exactly what the message was, but the linker complains about “ADDR32” conversion without this switch in the PGI libraries and refuse to link.

Where you trying to use the generated objects in a DLL? If so, then this is not yet supported for 64-bit SUA. You may consider using the PGI Windows compilers which do support DLL creation.

Something to look forward to, I think! So, will this release have a GNU-style ld or a MS linker interface?

The 32-bit SUA/SFU compilers will use a GNU-style linker while the 64-bit SUA compilers will use MS link.

  • Mat
#6

Hi Mat

modifying system include files is generally not a good idea

No, but with Interix headers there are some issues, especially with the MS compiler and LP64. You cannot use the original headers in x64 without a compiler with LP64 support. cc and l2ll - OK, but not in VS. There are a few bugs, discovered in SUA 5.2, still appears in the Longhorn beta.

$ ./a.out
123123123

You’re right, there must be a conflict somewhere in the headers. I look into that again. pgcc have ANSI C as standard, right? I was thinking if a switch like -c89/-c99 was needed.

Where you trying to use the generated objects in a DLL? If so, then this is not yet supported for 64-bit SUA. You may consider using the PGI Windows compilers which do support DLL creation.

No, just a first simple testprogram. You must be able to recreate it with a fresh pgcc installation. The only thing I changed was the PSDK directory to my VS installation (which contains newer versions of the tools). It all depends on how the PGI libraries was linked. I only tested the x64 version, I doubt there is a problem in 32bit.

The 32-bit SUA/SFU compilers will use a GNU-style linker while the 64-bit SUA compilers will use MS link.

That sounds great and very interesting if you manage to get shared library support.

#7

Hi Jerker,

pgcc have ANSI C as standard, right? I was thinking if a switch like -c89/-c99 was needed.

By default the PGI C compilers use C99. To use C89 use “-c89”.

Would it be possible for you to write-up a report and sample code about the ADDR32 error you’re seeing and send it to PGI customer support at trs@pgroup.com? I’d like to have an engineer look at it.

Thanks,
Mat

#8

write-up a report and sample code about the ADDR32 error you’re seeing

OK, I post it here as well.

// test_longtype.c
extern int __cdecl printf (const char *, ...);

int __cdecl main(void)
{
    int size = sizeof(int);
    printf("size of int is %u\n", size);
    size = sizeof(long);
    printf("size of long is %u\n", size);

    return 0;
}




$ pgcc -O1 -o test_longtype test_longtype.c
libpgc.a(stkchk.o) : error LNK2017: 'ADDR32' relocation to '.data' invalid without /LARGEADDRESSAWARE:NO
...
libpgc.a(trace_interix.o) : error LNK2017: 'ADDR32' relocation to '.data' invalid without /LARGEADDRESSAWARE:NO
LINK : fatal error LNK1165: link failed because of fixup errors

My fix:
ldrc(121) /subsystem:$SUBSYS … /largeaddressaware:no /machine:$MACHINE[/quote]

#9

Here is autoconf(2.61) test for uid_t taken from GNU make 3.81
config.log

configure:8296: checking for uid_t in sys/types.h
pgcc-Fatal-/opt/pgi/sua64/7.0-6/bin/pgc TERMINATED by signal 13
Arguments to /opt/pgi/sua64/7.0-6/bin/pgc
/opt/pgi/sua64/7.0-6/bin/pgc conftest.c -opt 1 -terse 1 -inform warn -x 59 4 -x 19 0x400000 -x 119 0x40E10400 -x 59 4 -x 70 0x8000 -x 122 1 -x 122 0x40 -x 123 0x1000 -x 127 20 -tp p7-64 -y 80 0x4000000 -x 119 0x8000000 -astype 0 -stdinc /opt/pgi/sua64/7.0-6/include:/usr/local/include:/include:/usr/include -def lp64 -def unix -def __unix -def __unix__ -def __INTERIX -def _POSIX_ -def _ALL_SOURCE -def _REENTRANT -def MT -def __inline__= -def __x86_64__ -def _M_AMD64 -def __NO_MATH_INLINES -def __amd64__ -def __extension__= -def __SSE__ -def __MMX__ -def __SSE2__ -def __SSE3__ -predicate '#machine(x86_64) #lint(off) #system(unix) #system(posix) #cpu(x86_64)' -def _CTYPE_DISABLE_MACROS -cmdline '+pgcc conftest.c -E -O1 -D_CTYPE_DISABLE_MACROS' -x 123 4 -x 123 0x80000000 -alwaysinline /opt/pgi/sua64/7.0-6/lib/libintrinsics.il 4 -es -pp
configure:8319: result: no

The warnings occur when there are duplicate typedefs. This will generate them:

#include <sys/types.h>
#include <inttypes.h>
int __cdecl main(void)
{
    return 0;
}




typedef int a;
typedef int a;
int __cdecl main(void)
{
    return 0;
}

It seems there are 2 separate problems. pgcc choke on uid_t for some reason and appear to hate when a typedef occur twice.

#10

autoconf tests that terminate with “TERMINATED by signal 13” I discovered so far. As I understand the tests are aborted before completed resulting in wrong configuration.

  • AC_AIX - checking for AIX
    AC_HEADER_STDC - checking for ANSI C header files
    AC_TYPE_UID_T - checking for uid_t in sys/types.h
    AC_FUNC_GETLOADAVG
    AC_CACHE_VAL
    AC_EGREP_CPP

exactly why is beyond me. Some of these may fail due to other macros.

#11

Hi Jerker,

I’ll try to look at autoconf to determine the issue. Unfortunately it may not be until late next week before I’ll get a chance to look at it.

  • Mat
#12

I have not got any useful response from my report about the import libraries. The major problem are the signal errors though.

I take it these are bugs in the current version then.

#13

I got the same error pgc TERMINATED by signal 13 then uses GNU configure
to fix that error I defines export CPP=pgprepro in /etc/profile.lcl
PS:
$ uname -a
Interix droopy 5.2 SP-9.0.3790.4125 authenticamd AMD64_Family_15_Model_47_Stepping_2

PPS: I found better solution ;)
export CPP="pgcpp -U__cplusplus -E"