OpenVMS x86 native compilers, cross compilers news and questions.
-
Topic author
mgdaniel
- Valued Contributor
- Posts: 64
- Joined: Mon Feb 28, 2022 5:16 pm
- Reputation: 0
- Location: Adelaide, South Australia
-
Status:
Offline
-
Contact:
Post
by mgdaniel » Sat Jan 13, 2024 2:01 am
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
- Master
- Posts: 385
- Joined: Fri Apr 17, 2020 7:31 pm
- Reputation: 0
- Location: Rhode Island, USA
-
Status:
Offline
-
Contact:
Post
by arne_v » Sat Jan 13, 2024 1:13 pm
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.
Last edited by
arne_v on Sat Jan 13, 2024 1:33 pm, edited 1 time in total.
-
mjvms27
- Contributor
- Posts: 23
- Joined: Wed May 17, 2023 2:11 pm
- Reputation: 0
-
Status:
Offline
Post
by mjvms27 » Sun Jan 14, 2024 12:30 pm
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];
}
Last edited by
mjvms27 on Sun Jan 14, 2024 12:37 pm, edited 1 time in total.
-
jonesd
- Valued Contributor
- Posts: 79
- Joined: Mon Aug 09, 2021 7:59 pm
- Reputation: 0
-
Status:
Offline
Post
by jonesd » Wed Jan 17, 2024 7:30 am
mjvms27 wrote: ↑Sun Jan 14, 2024 12:30 pm
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
- Contributor
- Posts: 23
- Joined: Wed May 17, 2023 2:11 pm
- Reputation: 0
-
Status:
Offline
Post
by mjvms27 » Wed Jan 17, 2024 8:04 am
jonesd wrote: ↑Wed Jan 17, 2024 7:30 am
mjvms27 wrote: ↑Sun Jan 14, 2024 12:30 pm
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".
-
Topic author
mgdaniel
- Valued Contributor
- Posts: 64
- Joined: Mon Feb 28, 2022 5:16 pm
- Reputation: 0
- Location: Adelaide, South Australia
-
Status:
Offline
-
Contact:
Post
by mgdaniel » Wed Jan 17, 2024 9:50 am
mjvms27 wrote: ↑Wed Jan 17, 2024 8:04 am
jonesd wrote: ↑Wed Jan 17, 2024 7:30 am
mjvms27 wrote: ↑Sun Jan 14, 2024 12:30 pm
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
- VSI Expert
-
Master
- Posts: 148
- Joined: Tue Dec 01, 2020 8:40 am
- Reputation: 0
-
Status:
Offline
Post
by jreagan » Thu Jan 18, 2024 8:09 am
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.
-
Topic author
mgdaniel
- Valued Contributor
- Posts: 64
- Joined: Mon Feb 28, 2022 5:16 pm
- Reputation: 0
- Location: Adelaide, South Australia
-
Status:
Offline
-
Contact:
Post
by mgdaniel » Thu Jan 18, 2024 12:45 pm
jreagan wrote: ↑Thu Jan 18, 2024 8:09 am
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
- VSI Expert
-
Master
- Posts: 148
- Joined: Tue Dec 01, 2020 8:40 am
- Reputation: 0
-
Status:
Offline
Post
by jreagan » Sat Jan 20, 2024 12:07 pm
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).