VSI C x86-64 V7.5-009 (GEM 50XBR) buglet? G2L-E-ASSERT, GEM ENTRY

[mgdaniel]

Different in behaviour between Alpha and X86 compilers.
Alpha allows internally scoped storage to share a name with the containing function. X86 does not.

Code: Select all

# DEMO_G2L_E_ASSERT.C
#include <stdlib.h>
#include <stdio.h>
#include <string.h>

void test1 ();

main ()
{
   test1 ();
}

void test1 ()
{
   static char  test1 [32];
}

Code: Select all

$ cc/version
VSI C V7.4-002 on OpenVMS Alpha V8.4-2L2
$ cc /names=as_is DEMO_G2L_E_ASSERT
$ link DEMO_G2L_E_ASSERT

Code: Select all

$ cc/version
VSI C x86-64 V7.5-009 (GEM 50XBR) on OpenVMS x86_64 V9.2-1
$ cc /names=as_is DEMO_G2L_E_ASSERT
G2L-E-ASSERT, GEM ENTRY test1 already defined as GEM VARIABLE
$ link DEMO_G2L_E_ASSERT
%ILINK-F-NOMODS, no input modules specified (or found)

[arne_v]

Well V7.5 is doing better than X7.4.

Code: Select all

$ cc/ver
VSI C X7.4-785 (GEM 50X65) on OpenVMS x86_64 V9.2-1
$ type zz.c
#include <stdlib.h>
#include <stdio.h>
#include <string.h>

void test1 ();

main ()
{
   test1 ();
}

void test1 ()
{
   static char  test1 [32];
}
$ cc/name=as_is zz
assert error: expression = isa<X>(Val) && "cast<Ty>() argument of incompatible type!", in file /llvm$root/include/llvm-project-10/ll
vm/include/llvm/Support/Casting.h at line 264
%SYSTEM-F-OPCCUS, opcode reserved to customer fault at PC=FFFF830009F367DF, PS=0000001B
%TRACE-F-TRACEBACK, symbolic stack dump follows
image     module    routine               line      rel PC           abs PC
DECC$SHR  SIGNAL.C;1                    #20739 00000000801C97DF FFFF830009F367DF
DECC$SHR  ABORT.C;1                      #2967 000000008009643B FFFF830009E0343B
DECC$SHR                                     0 000000008039B779 FFFF83000A108779
DECC$COMPILER  [.src]g2l_entrysymbol.cxx  cast<llvm::Function, llvm::Value>
                                          #175 0000000001A1E2C1 0000000001A1E2C1
DECC$COMPILER  [.src]g2l_entrysymbol.cxx  dwarf
                                          #394 0000000000AD057B 0000000000AD057B
DECC$COMPILER  [.src]g2l_symbol.cxx  convertSymbol
                                          #828 0000000000A4993A 0000000000A4993A
DECC$COMPILER  [.src]g2l_module.cxx  convertDeclarations
                                         #1554 0000000000A473B7 0000000000A473B7
DECC$COMPILER  [.src]g2l_module.cxx  convertModule
                                         #1165 0000000000A44603 0000000000A44603
DECC$COMPILER  [.src]g2l_module.cxx  G2L_COMPILE_MODULE
                                          #619 0000000000A43181 0000000000A43181
DECC$COMPILER  GEM_CO.BLI;1  GEM_CO_COMPILE_MODULE
                                         #3223 0000000000000A54 00000000006D8844
DECC$COMPILER  COMPILE.C;1  gemc_be_master
                                       #103704 00000000004238BE 00000000004238BE
DECC$COMPILER  COMPILE.C;1  gem_xx_compile
                                       #102915 0000000000422597 0000000000422597
DECC$COMPILER  GEM_CP_VMS.BLI;1  GEM_CP_MAIN
                                         #2447 000000000000384E 00000000006CC23E
DECC$COMPILER                                0 0000000000AD36A4 0000000000AD36A4
DECC$COMPILER                                0 00000000021887AD 00000000021887AD
PTHREAD$RTL                                  0 000000008004122C FFFF830009D0922C
PTHREAD$RTL                                  0 0000000080002316 FFFF830009CCA316
                                             0 FFFF8300081BDEA6 FFFF8300081BDEA6
DCL                                          0 000000008006778B 000000007ADFF78B
%TRACE-I-LINENUMBER, Leading '#' specifies a source file record number.
%TRACE-I-END, end of TRACE stack dump

Added in 21 minutes 31 seconds:
After updating to V7.5, then I of course get the same error as you.

[mjvms27]

The code presented (with the following minor C99 corrections shown below, unrelated to the test1 issue), is legal code and should compile successfully, so I concur that this seems to be a compiler bug/regression.

minor C99 corrections:

Code: Select all

#include <stdlib.h>
#include <stdio.h>
#include <string.h>

void test1 (void);

int main (void)
{
   test1 ();
}

void test1 (void)
{
   static char  test1 [32];
}

[jonesd]

The code presented (with the following minor C99 corrections shown below, unrelated to the test1 issue), is legal code and should compile successfully, so I concur that this seems to be a compiler bug/regression.

Strange that it only happens if the array is declared as static.

[mjvms27]

The code presented (with the following minor C99 corrections shown below, unrelated to the test1 issue), is legal code and should compile successfully, so I concur that this seems to be a compiler bug/regression.

Strange that it only happens if the array is declared as static.

It also only happens with "/names=as_is".

[mgdaniel]

The code presented (with the following minor C99 corrections shown below, unrelated to the test1 issue), is legal code and should compile successfully, so I concur that this seems to be a compiler bug/regression.

Strange that it only happens if the array is declared as static.

It also only happens with "/names=as_is".

Without the "as_is" the default would be to upper-case all names.

Code: Select all

#include <stdlib.h>
#include <stdio.h>
#include <string.h>

void test1 ();
void TEST2 ();

main ()
{
   test1 ();
   TEST2 ();
}

void test1 ()
{
   static char  test1 [32];
}

void TEST2 ()
{
   static char  TEST2 [32];
}

Code: Select all

X86VMS$ cc DEMO_G2L_E_ASSERT.C
G2L-E-ASSERT, GEM ENTRY TEST2 already defined as GEM VARIABLE
X86VMS$ cc /name=as_is DEMO_G2L_E_ASSERT.C
G2L-E-ASSERT, GEM ENTRY test1 already defined as GEM VARIABLE

Seems to be some (globally scoped) symbol confusion in the GEM-to-llvm post-processing.

[jreagan]

LLVM has the silly rule about unique names that really isn't a problem. It also thinks that an ELF symbol and an ELF section cannot have the same name. [GEM on Itanium doesn't care, ELF doesn't care, the linker doesn't care.] We've had to try to workaround much of that. Here's another place that we need more work. I'll add a ticket.

[mgdaniel]

I'll add a ticket.

Early in the Service Portal I submitted a number of "issues". More recently just been posting this level of feedback via the "forum". Is there a clear preference?

[jreagan]

I prefer using the service portal. Those automatically get tracked into our bug tracking software. Reports here rely on me to do that for you (and I can be busy and not visit for a while).