VSI C V7.6-001 for OpenVMS x86-64

VSI C Reference Manual

VSI C User Manual

VSI C Run-Time Library Reference Manual for OpenVMS Systems

Enter the command HELP CC at the $ prompt.

Support for "#pragma __inline" was added.

Support for "#pragma optimize level=0" was added.

Tail-call optimization was disabled to conform to the Calling Standard.

Set correct $STATUS on /SHOW=FULLPATH.

Fixed debug info for bitfields.

Fixed optimization breaking setjmp/longjmp/vfork.

Fixed optimization for equations in non-default rounding mode.

The /IEEE_MODE qualifier is not fully functional. The default is for /IEEE_MODE=DENORM, but options like FAST, UNDERFLOW_TO_ZERO, and so on may not function correctly.

The C compiler contains partial support for the /OPTIMIZE qualifier. It does not fully support all of the sub-options from the /OPTIMIZE qualifier. The degree of optimization will increase in future updates.

The debug support from the compiler may not correctly describe every possible data type. We expect to improve the debug support in future releases of the compiler and OpenVMS debugger.

The /MACHINE_CODE qualifier is currently ignored. As a temporary workaround, you can use the ANALYZE/OBJECT/DISASSEMBLE command.

The #dictionary pragma is not currently supported.

long double

The long double data type is not yet fully supported. Known issues include compile-time initialization of global/static variables (including structures/unions with long double data types) and calls to math intrinsic functions.

varargs.h vs stdarg.h

Due to how the AMD64 ABI Calling Standard is defined, varargs.h is difficult to support. Most Linux platforms do not support it at all. We have tried to retain as much as possible, but strongly suggest that you convert to using <stdarg.h> instead. It will require source modifications, but they will work on Alpha and IA-64 so you can keep common code going forward.

Variable initializers that contain math exceptions do not properly get signaled by the compiler.

The /CHECK=UNINITIALIZED_VARIABLES qualifier is not supported and may cause a run-time error.

If the /FIRST_INCLUDE qualifier is used to specify more than one header-file, and the first logical source line of the primary source file spans physical lines (i.e. it either begins a C-style delimited comment that is not completed on that line, or the last character before the end-of-line is a backslash line-continuation character), then the compiler will give an internal error. Workarounds are either to make sure that the first logical line of the primary source file does not span physical lines (e.g. make it a blank line), or to avoid specifying more than one header in the /FIRST_INCLUDE qualifier (e.g. use a single /FIRST_INCLUDE header that #includes all of the headers you want to precede the first line of the primary source file).

When used without optimization the x86-64 compiler processes unused static functions, which results in linker warnings.

For example, the following program will get link warnings:

#include <stdio.h>

extern int bar(void);

void main(void)
{
    puts("Success");
}

static int foo()
{
    return bar(); /* Should not get undefined for bar() */
}

With the x86-64 compiler:

$ cc/nooptimize test.c
$ link test
%ILINK-W-NUDFSYMS, 1 undefined symbol:
%ILINK-I-UDFSYM,        BAR
%ILINK-W-USEUNDEF, undefined symbol BAR referenced
    section: $CODE$
    offset: %X0000000000000029
    module: TEST
    file: DKA200:[MYDIR]TEST.OBJ;1
$

No warnings are issued during linking on IA-64 for this same test.

No warnings are issued on case sensitive variables.

Definitions of variables which differ only by case are not reported. For example, the following program gets warnings from the IA-64 compiler, but the x86-64 compiler does not issue any warning:

int xxxx = 1;
int XXXX = 2;
int XxXx = 3;

With the IA-64 compiler:

$ cc test.c

int XXXX = 2;
....^
%CC-W-DUPEXTERN, The declaration of "XXXX" will map to the same
external name as the declaration of "xxxx" at line number 1 in
file DKA200:[MYDIR]TEST.C;1.
at line number 2 in file DKA200:[MYDIR]TEST.C;1

int XxXx = 3;
....^
%CC-W-DUPEXTERN, The declaration of "XxXx" will map to the same
external name as the declaration of "xxxx" at line number 1 in
file DKA200:[MYDIR]TEST.C;1.
at line number 3 in file DKA200:[MYDIR]TEST.C;1
$

The compiler does not issue warnings for uninitialized variables.

References to an uninitialized variable will get a warning with the IA-64 compiler, but not with the x86-64 compiler.

Some compiler errors are printed only to SYS$OUTPUT, not to SYS$ERROR.

For example:

 $ TYPE TEST.C
// Dummy test to make sure we generate diagnostic
z;
$
$ DEFINE SYS$ERROR E.DOC
$ CC TEST.C 

z;
.^
%CC-W-NOTYPES, Declaration has no type or storage class.
at line number 2 in file TEST.C;1
$ DEASSIGN SYS$ERROR
$ TY E.DOC
$

The compiler does not report invalid references to restricted pointers.

For the following example test:

#include <stdio>
int * __restrict a;
int * __restrict b;
int c = 5;

void main(void) {
    a = &c;
    b = a;
    *b = 1;
    printf("%d\n", *a);
}

No warning is issued by the x86-64 compiler, whereas the IA-64 compiler does issue a warning:

$ cc test.c
$ cc dev1053.c

    *b = 1;
    ....^
%CC-W-BADALIAS, Reference through restricted pointer b uses a
pointer value based on different restricted pointer, a at line
number 9 in file DISK1:[TEST]TEST.C;1
$