[ghogenso@u.washington.edu: Problems with .cpp extension: minor annoyances]

[ghogenso@u.washington.edu: Problems with .cpp extension: minor annoyances]

[DJ Delorie]

Is this the desired behavior?  gcc *does* support a lot of file
extensions for each language.

Return-Path: <ghogenso@u.washington.edu>
X-Sender: ghogenso@stein2.u.washington.edu
Date: Tue, 27 Sep 1994 10:25:42 -0700 (PDT)
From: Gordon Hogenson <ghogenso@u.washington.edu>
Sender: Gordon Hogenson <ghogenso@u.washington.edu>
Reply-To: Gordon Hogenson <ghogenso@u.washington.edu>
Subject: Problems with .cpp extension: minor annoyances
To: djgpp@sun.soe.clarkson.edu
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
DJ-Mail-Sort: djgpp@, djgpp


There are a few problems with the .cpp filename extension under
DJGPP.  It seems that the various utility programs don't
deal well with it.  ld reports errors with the wrong filename
extension -- always 'foo.cc' even if the file is really 'foo.cpp'.

It doesn't seem to be a serious problem with errors and warnings
from ld, since I can easily tell what is meant [although I suppose
editors that rely on this to locate a position in a source file will not
work], but I find that GDB can't find the source files.
It looks for 'foo.cc' when it should be looking for 'foo.cpp'.

Gordon

Re: [ghogenso@u.washington.edu: Problems with .cpp extension: minor annoyances]

[Ian Lance Taylor]

   Date: Wed, 28 Sep 94 07:41:21 -0400
   From: dj@stealth.ctron.com (DJ Delorie)

   Is this the desired behavior?  gcc *does* support a lot of file
   extensions for each language.

   Date: Tue, 27 Sep 1994 10:25:42 -0700 (PDT)
   From: Gordon Hogenson <ghogenso@u.washington.edu>

   There are a few problems with the .cpp filename extension under
   DJGPP.  It seems that the various utility programs don't
   deal well with it.  ld reports errors with the wrong filename
   extension -- always 'foo.cc' even if the file is really 'foo.cpp'.

   It doesn't seem to be a serious problem with errors and warnings
   from ld, since I can easily tell what is meant [although I suppose
   editors that rely on this to locate a position in a source file will not
   work], but I find that GDB can't find the source files.
   It looks for 'foo.cc' when it should be looking for 'foo.cpp'.

There is nothing about file extensions in either ld or gdb.  Both
programs get the filenames out of the debugging information.  I
suspect that if you examine the debugging information in your .o file,
you will find that it refers to foo.cc, not foo.cpp.  I suspect
further that your foo.cpp file includes # directives naming the file
foo.cc.

If not, then there is a bug.  Please provide a testcase showing the
problem.

Ian

Re: [ghogenso@u.washington.edu: Problems with .cpp extension]

[Gordon Hogenson]

Under DJGPP 1.12 with G++ 2.6.0, I experience the following problem
when using filename extension .cpp instead of .cc.  The assembler
output contains the incorrect ".file" heading.  Included here is an
intentional link-time error to illustrate that ld then
reports the wrong filename.

--------------------- main.cpp ------------------------------

int main()
{

  int i;
  for (i = 0; i < 55; i++)
    my_function(i); 

}

------------------- output of 'gcc main.cpp -o main -g -v' --------

Reading specs from d:/gcc/lib/specs
gcc version 2.6.0
 d:/gcc/bin/cpp.exe -lang-c++ -v -undef -D__GNUC__=2 -D__GNUG__=2 
-D__cplusplus -D__GNUC_MINOR__=6 -Dunix -Di386 -DGO32 -DMSDOS -D__unix__ 
-D__i386__ -D__GO32__ -D__MSDOS__ -D__unix -D__i386 -D__GO32 -D__MSDOS -g 
main.cpp f:/cc000073
GNU CPP version 2.6.0 (80386, BSD syntax)
#include "..." search starts here:
#include <...> search starts here:
 d:/gcc/cplusinc
 d:/gcc/include
 /usr/local/lib/g++-include
 /usr/local/include
 /usr/local/go32/include
 /usr/local/lib/gcc-lib/go32/2.6.0/include
 /usr/include
End of search list.
 d:/gcc/bin/cc1plus.exe f:/cc000073 -quiet -dumpbase main.cc -g -version 
-o f:/cca00073
GNU C++ version 2.6.0 (80386, BSD syntax) compiled by GNU C version 2.6.0.
main.cpp: In function `int main()':
main.cpp:7: warning: implicit declaration of function `int my_function(...)'
 d:/gcc/bin/as.exe -o f:/ccb00073 f:/cca00073
 d:/gcc/bin/ld.exe -o main d:/gcc/lib/crt0.o -Ld:/gcc/lib f:/ccb00073 
-lgcc -lg -lc -lgcc
main.cc:7: main: undefined reference to `my_function'
     ^^^^^
     This is incorrect!

--------------------------------------------------------------------------

Running 'gcc main.cpp -g -v -S -o main.s', we get the file main.s:

-------------------------------------------------------------------------

	.file	"main.cc"
gcc2_compiled.:
___gnu_compiled_cplusplus:
.text
	.align 2
	.def	_main;	.val	_main;	.scl	2;	.type	044;	.endef
.globl _main
_main:
	pushl %ebp
	movl %esp,%ebp
	subl $4,%esp
	.def	.bf;	.val	.;	.scl	101;	.line	3;	.endef
	call ___main
	.def	_i;	.val	-4;	.scl	1;	.type	04;	.endef
	.ln	4
	movl $0,-4(%ebp)
L2:
	.def	.bb;	.val	.;	.scl	100;	.line	4;	.endef
	cmpl $54,-4(%ebp)
	jle L5
	jmp L3
	.align 2,0x90
L5:
	.ln	5
	pushl -4(%ebp)
	call _my_function
	addl $4,%esp
	.def	.eb;	.val	.;	.scl	100;	.line	5;	.endef
L4:
	incl -4(%ebp)
	jmp L2
	.align 2,0x90
L3:
	xorl %eax,%eax
	jmp L1
	.align 2,0x90
	jmp L1
	.align 2,0x90
	.ln	7
L1:
	.def	.ef;	.val	.;	.scl	101;	.line	7;	.endef
	leave
	ret
	.def	_main;	.val	.;	.scl	-1;	.endef
----------------------------------------------------------------------------
Thus the '.file' is incorrect in the assembler output.
----------------------------------------------------------------------------

Thanks,
Gordon Hogenson