Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#1397 cc1plus fails to emit symbol names

OTHER
closed
nobody
gcc (462)
Bug
out-of-date
Unknown
False
2013-02-07
2010-02-16
No

Description:
When compiling with cc1plus, symbol names are not emitted for assembling. This results in the assembler reporting numerous redefinition errors for symbol '_' (since each identifier is usually prefixed with an underscore). If compiled with cc1, there is no problem (besides needing the code to be pure C).

The previous installation of MinGW (with GCC 3.4.5) does not have this problem. Tests with the current installation (see below) on other systems do not exhibit this behavior, leading me to believe this may be a compatibility issue.

Host system:
AMD Athlon (K7) 900MHz; 512 MB RAM; Windows 98SE

GCC Version (gcc -v):
Using built-in specs.
Target: mingw32
Configured with: ../gcc-4.4.0/configure --enable-languages=c,ada,c++,fortran,java,objc,obj-c++ --disable-sjlj-exceptions --enable-shared --enable-libgcj --enable-libgomp --with-dwarf2 --disable-win32-registry --enable-libstdcxx-debug --enable-version-specific-runtime-libs --prefix=/mingw --with-gmp=/mingw/src/gmp/root --with-mpfr=/mingw/src/mpfr/root --build=mingw32
Thread model: win32
gcc version 4.4.0 (GCC)

Binutils Version (ld -v):
GNU ld (GNU Binutils) 2.20

Build Environments Tested:
command.com and MSYS (with and without RXVT)

MSYS Version (uname -a):
MINGW32_98-4.10 hostname 1.0.10(0.46/3/2) 2004-03-15 07:17 i686 unknown

MinGW Installed from Packages:
binutils-2.20-1-mingw32-bin.tar.gz
mingwrt-3.17-mingw32-dev.tar.gz
mingwrt-3.17-mingw32-dll.tar.gz
mingw-utils-0.4-1-mingw32-bin.tar
mingw-utils-0.4-1-mingw32-doc.tar
w32api-3.14-mingw32-dev.tar.gz
make-3.81-20090914-mingw32-bin.tar.gz
gdb-7.0.50.20100202-mingw32-bin.tar.gz
libiconv-1.13.1-1-mingw32-dll-2.tar
gmp-4.2.4-mingw32-dll.tar.gz
mpfr-2.4.1-mingw32-dll.tar.gz
pthreads-w32-2.8.0-mingw32-dll.tar.gz
gcc-core-4.4.0-mingw32-bin.tar.gz
gcc-core-4.4.0-mingw32-dll.tar.gz
gcc-c++-4.4.0-mingw32-bin.tar.gz
gcc-c++-4.4.0-mingw32-dll.tar.gz

Test case (test.cpp):
void DoNothing (void) { }

int main (int argc, char * argv []) {
DoNothing ();
return (0);
}

Compile, Assemble, and Link Commands:
g++ -o test.exe test.cpp
gcc -o test.exe test.cpp

Results (messages):
L:\TEMP\cc5RT5r4.s: Assembler messages:
L:\TEMP\cc5RT5r4.s:17: Error: symbol `_' is already defined

Compile (only) Commands:
g++ -S test.cpp
gcc -S test.cpp

Compile (backend) Commands:
cc1plus test.cpp -o test.s
cc1 test.cpp -o test.s

Results (cc1plus messages):
void DoNothing() int main(int, char**)
Analyzing compilation unit
Performing interprocedural optimizations
<visibility> <early_local_cleanups> <summary generate> <inline>Assembling functions:
void DoNothing() int main(int, char**)
Execution times (seconds)
parser : 0.05 ( 8%) usr 278 kB (27%) ggc
name lookup : 0.55 (83%) usr 53 kB ( 5%) ggc
TOTAL : 0.66 1045 kB

Results (cc1 messages):
DoNothing main
Analyzing compilation unit
Performing interprocedural optimizations
<visibility> <early_local_cleanups> <summary generate> <inline>Assembling functions:
DoNothing main
Execution times (seconds)
parser : 0.05 (45%) usr 43 kB ( 7%) ggc
integrated RA : 0.06 (55%) usr 1 kB ( 0%) ggc
TOTAL : 0.11 632 kB

Results (test.s from cc1plus):
.file "test.cpp"
.text
.globl _
.def _; .scl 2; .type 32; .endef
_:
LFB0:
pushl %ebp
LCFI0:
movl %esp, %ebp
LCFI1:
leave
ret
LFE0:
.def _; .scl 2; .type 32; .endef
.globl _
.def _; .scl 2; .type 32; .endef
_:
LFB1:
pushl %ebp
LCFI2:
movl %esp, %ebp
LCFI3:
andl $-16, %esp
LCFI4:
call _
call _
movl $0, %eax
leave
ret
LFE1:

Results (test.s from cc1):
.file "test.cpp"
.text
.globl _DoNothing
.def _DoNothing; .scl 2; .type 32; .endef
_DoNothing:
pushl %ebp
movl %esp, %ebp
popl %ebp
ret
.def ___main; .scl 2; .type 32; .endef
.globl _main
.def _main; .scl 2; .type 32; .endef
_main:
pushl %ebp
movl %esp, %ebp
andl $-16, %esp
call ___main
call _DoNothing
movl $0, %eax
movl %ebp, %esp
popl %ebp
ret

Additional Notes:
1. TDM GCC produces the same results.
2. The following switches (through g++) were used to examine additional information about compilation: -Q, -ftime-report -fmem-report, -fdump-rtl-all, -fdump-tree-all
The results were still the same (even though the dumps all had the correct symbol names). Since the names in the dumps were not mangled, it is possible that the problem relates to mangled names.

I realize this may not be easy to reproduce, so if there are any further tests I can perform (or results I can post), please let me know.

Thank you for your help.
- Christopher

Discussion

  • Earnie Boyd
    Earnie Boyd
    2013-02-07

    • labels: MinGW --> gcc
    • status: open --> closed
    • milestone: --> OTHER
    • type: --> Bug
    • resolution: --> out-of-date
    • category: --> Unknown
    • patch_attached: --> False