Re: [fortran] Different FUNC_DECLS with the same DECL_NAME - MAIN__ and named PROGRAM main functions [was Re: gcc-4.5-20090528 is now available]
Jerry DeLisle wrote: > I tested the above on x86-64 Linux. OK to commit. Thanks for the review. Committed: Sendinggcc/fortran/ChangeLog Sendinggcc/fortran/trans-decl.c Transmitting file data .. Committed revision 148035. Tobias
Re: [fortran] Different FUNC_DECLS with the same DECL_NAME - MAIN__ and named PROGRAM main functions [was Re: gcc-4.5-20090528 is now available]
Tobias Burnus wrote: > Jerry DeLisle wrote: >> I tested the above on x86-64 Linux. OK to commit. > Thanks for the review. Committed: > > Sendinggcc/fortran/ChangeLog > Sendinggcc/fortran/trans-decl.c > Transmitting file data .. > Committed revision 148035. > > Tobias Thank you both :) cheers, DaveK
Bootstrap broken on darwin / fink
Hi, I'm seeing this error: /Users/tobi/src/hggcc/build/./prev-gcc/xgcc -B/Users/tobi/src/hggcc/build/./prev-gcc/ -B/usr/local/i386-apple-darwin8.11.1/bin/ -B/usr/local/i386-apple-darwin8.11.1/bin/ -B/usr/local/i386-apple-darwin8.11.1/lib/ -isystem /usr/local/i386-apple-darwin8.11.1/include -isystem /usr/local/i386-apple-darwin8.11.1/sys-include-c -g -O2 -fomit-frame-pointer -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototype -Wmissing-prototypes -Wcast-qual -Wold-style-definition -Wc++-compat -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -I. -I. -I../../gcc -I../../gcc/. -I../.. gcc/../include -I./../intl -I../../gcc/../libcpp/include -I/sw/include -I../../gcc/../libdecnumber -I../../gcc/../libdecnumber/dpd -I../libdecnumber../../gcc/ retty-print.c -o pretty-print.o cc1: warnings being treated as errors ../../gcc/pretty-print.c: In function 'identifier_to_locale': ../../gcc/pretty-print.c:1016: error: passing argument 2 of 'libiconv' from incompatible pointer type /sw/include/iconv.h:83: note: expected 'char **' but argument is of type 'const char **' make[3]: *** [pretty-print.o] Error 1 make[3]: *** Waiting for unfinished jobs make[2]: *** [all-stage2-gcc] Error 2 make[1]: *** [stage2-bubble] Error 2 make: *** [all] Error 2 My libiconv identifies itself as #define _LIBICONV_VERSION 0x010B/* version number: (major<<8) + minor */ The complaint is about: ICONV_CONST char *inbuf = CONST_CAST (char *, ident); [...snip...] iconv_ret = iconv (cd, &inbuf, &inbytesleft, &outbuf, &outbytesleft); Cheers, - Tobi
Re: Bootstrap broken on darwin / fink
On Mon, 1 Jun 2009, Tobias Schlüter wrote: > The complaint is about: > ICONV_CONST char *inbuf = CONST_CAST (char *, ident); > [...snip...] > iconv_ret = iconv (cd, &inbuf, &inbytesleft, >&outbuf, &outbytesleft); The types are exactly the same as in the corresponding code in libcpp/charset.c. ICONV_CONST char *inbuf; iconv (cd, &inbuf, &inbytesleft, &outbuf, &outbytesleft); You'll need to work out what's different on your system between gcc and libcpp to make it work in one place only. Note that iconv.m4 comes from gettext; it's possible the configure support has since been refined upstream and should be updated. -- Joseph S. Myers jos...@codesourcery.com
Re: Bootstrap broken on darwin / fink
Tobias Schlüter wrote: > cc1: warnings being treated as errors > ../../gcc/pretty-print.c: In function 'identifier_to_locale': > ../../gcc/pretty-print.c:1016: error: passing argument 2 of 'libiconv' > from incompatible pointer type > /sw/include/iconv.h:83: note: expected 'char **' but argument is of type > 'const char **' This would probably have been more appropriate on a fink related mailing list. As Joseph pointed out, configure is finding a different iconv.h than the compiler, and they provide different prototypes for iconv(). I suggest looking at Jack Howarth's gcc package in fink to see what he's doing with this. Peter -- Peter O'Gorman http://pogma.com
Re: Bootstrap broken on darwin / fink
Joseph S. Myers wrote: On Mon, 1 Jun 2009, Tobias Schlüter wrote: The complaint is about: ICONV_CONST char *inbuf = CONST_CAST (char *, ident); [...snip...] iconv_ret = iconv (cd, &inbuf, &inbytesleft, &outbuf, &outbytesleft); The types are exactly the same as in the corresponding code in libcpp/charset.c. ICONV_CONST char *inbuf; iconv (cd, &inbuf, &inbytesleft, &outbuf, &outbytesleft); You'll need to work out what's different on your system between gcc and libcpp to make it work in one place only. Note that iconv.m4 comes from gettext; it's possible the configure support has since been refined upstream and should be updated. In gcc/auto-host.h I have #define HAVE_ICONV_H, whereas in libcpp/ I haven't. From PR31932, I presume that HAVE_ICONV_H should never be defined. The check is explicitly made in AC_CHECK_HEADERS in gcc/configure.ac. I can't see what happens if I remove the check as fink symlinks autoconf-2.59 to autoconf which in turn is a symlink to autoconf-2.63. Cheers, - Tobi
Re: Problems with sibling calls
Ulrich Weigand schrieb: Georg-Johann Lay wrote: I'd like to support sibling calls for a target where function args can be passed in call-saved registers, namely AVR. The s390 back-end already has the very same issue. You may want to have a look at config/s390/s390.c:s390_call_saved_register_used and how it is used by s390_function_ok_for_sibcall. Hi Ulrich, thank's much for this hint. It's the missing link I was after. Georg-Johann
Re: Bootstrap broken on darwin / fink
On Mon, Jun 01, 2009 at 12:07:56PM +0200, Tobias Schlüter wrote: > > Hi, > > I'm seeing this error: > > /Users/tobi/src/hggcc/build/./prev-gcc/xgcc > -B/Users/tobi/src/hggcc/build/./prev-gcc/ > -B/usr/local/i386-apple-darwin8.11.1/bin/ > -B/usr/local/i386-apple-darwin8.11.1/bin/ > -B/usr/local/i386-apple-darwin8.11.1/lib/ -isystem > /usr/local/i386-apple-darwin8.11.1/include -isystem > /usr/local/i386-apple-darwin8.11.1/sys-include-c -g -O2 > -fomit-frame-pointer -DIN_GCC -W -Wall -Wwrite-strings > -Wstrict-prototype > -Wmissing-prototypes -Wcast-qual -Wold-style-definition -Wc++-compat > -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros > -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -I. -I. > -I../../gcc -I../../gcc/. -I../.. > gcc/../include -I./../intl -I../../gcc/../libcpp/include -I/sw/include > -I../../gcc/../libdecnumber -I../../gcc/../libdecnumber/dpd > -I../libdecnumber../../gcc/ > retty-print.c -o pretty-print.o > cc1: warnings being treated as errors > ../../gcc/pretty-print.c: In function 'identifier_to_locale': > ../../gcc/pretty-print.c:1016: error: passing argument 2 of 'libiconv' > from incompatible pointer type > /sw/include/iconv.h:83: note: expected 'char **' but argument is of type > 'const char **' > make[3]: *** [pretty-print.o] Error 1 > make[3]: *** Waiting for unfinished jobs > make[2]: *** [all-stage2-gcc] Error 2 > make[1]: *** [stage2-bubble] Error 2 > make: *** [all] Error 2 > > > My libiconv identifies itself as > #define _LIBICONV_VERSION 0x010B/* version number: (major<<8) + minor */ > > The complaint is about: > ICONV_CONST char *inbuf = CONST_CAST (char *, ident); > [...snip...] > iconv_ret = iconv (cd, &inbuf, &inbytesleft, >&outbuf, &outbytesleft); > > > Cheers, > - Tobi > Tobi, You didn't show the configure options you used to build gcc trunk against the fink libraries. You need at least... --with-gmp=/sw --with-libiconv-prefix=/sw --with-system-zlib --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib Note that we don't set CPPFLAGS or LDFLAGS to have -I/sw/include or -L/sw/lib in the fink gcc packaging so that only those libraries that we explicitly set are picked up from fink. All other cases should be picked up from the system libraries. Jack
Re: Bootstrap broken on darwin / fink
Hi Jack, Jack Howarth wrote: You didn't show the configure options you used to build gcc trunk against the fink libraries. You need at least... --with-gmp=/sw --with-libiconv-prefix=/sw --with-system-zlib --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib Note that we don't set CPPFLAGS or LDFLAGS to have -I/sw/include or -L/sw/lib in the fink gcc packaging so that only those libraries that we explicitly set are picked up from fink. All other cases should be picked up from the system libraries. I wasn't aware of this. So far, I've only used --with-gmp=/sw and it worked like a charm, but I've not tried buildig gcc in a while, maybe I updated my fink tree in the meantime. My guess is, that as libcpp doesn't use gmp it doesn't get the -I/sw/include, whereas gcc/ gets it from --with-gmp. There are libiconvs in both /usr and /sw. Both with --with-libiconv-prefix=/sw and --with-libiconv-prefix=/usr, the build still fails in the same place, i.e. the libiconv from /usr is not picked up even if explicitly requested. Cheers, - Tobi
Re: Measuring FSF gcc from 4.1.2 to today on various benchmarks.
I would conclude from the statistics that, right now, the cost of including -fforward-propagate in -O1 overrides any performance benefit that may result. I'm still working on a patch to eliminate reaching definitions from fwprop. Paolo
The Linux binutils 2.19.51.0.7 is released.
This is the beta release of binutils 2.19.51.0.7 for Linux, which is
based on binutils 2009 0601 in CVS on sourceware.org plus various
changes. It is purely for Linux.
All relevant patches in patches have been applied to the source tree.
You can take a look at patches/README to see what have been applied and
in what order they have been applied.
Starting from the 2.18.50.0.4 release, the x86 assembler no longer
accepts
fnstsw %eax
fnstsw stores 16bit into %ax and the upper 16bit of %eax is unchanged.
Please use
fnstsw %ax
Starting from the 2.17.50.0.4 release, the default output section LMA
(load memory address) has changed for allocatable sections from being
equal to VMA (virtual memory address), to keeping the difference between
LMA and VMA the same as the previous output section in the same region.
For
.data.init_task : { *(.data.init_task) }
LMA of .data.init_task section is equal to its VMA with the old linker.
With the new linker, it depends on the previous output section. You
can use
.data.init_task : AT (ADDR(.data.init_task)) { *(.data.init_task) }
to ensure that LMA of .data.init_task section is always equal to its
VMA. The linker script in the older 2.6 x86-64 kernel depends on the
old behavior. You can add AT (ADDR(section)) to force LMA of
.data.init_task section equal to its VMA. It will work with both old
and new linkers. The x86-64 kernel linker script in kernel 2.6.13 and
above is OK.
The new x86_64 assembler no longer accepts
monitor %eax,%ecx,%edx
You should use
monitor %rax,%ecx,%edx
or
monitor
which works with both old and new x86_64 assemblers. They should
generate the same opcode.
The new i386/x86_64 assemblers no longer accept instructions for moving
between a segment register and a 32bit memory location, i.e.,
movl (%eax),%ds
movl %ds,(%eax)
To generate instructions for moving between a segment register and a
16bit memory location without the 16bit operand size prefix, 0x66,
mov (%eax),%ds
mov %ds,(%eax)
should be used. It will work with both new and old assemblers. The
assembler starting from 2.16.90.0.1 will also support
movw (%eax),%ds
movw %ds,(%eax)
without the 0x66 prefix. Patches for 2.4 and 2.6 Linux kernels are
available at
http://www.kernel.org/pub/linux/devel/binutils/linux-2.4-seg-4.patch
http://www.kernel.org/pub/linux/devel/binutils/linux-2.6-seg-5.patch
The ia64 assembler is now defaulted to tune for Itanium 2 processors.
To build a kernel for Itanium 1 processors, you will need to add
ifeq ($(CONFIG_ITANIUM),y)
CFLAGS += -Wa,-mtune=itanium1
AFLAGS += -Wa,-mtune=itanium1
endif
to arch/ia64/Makefile in your kernel source tree.
Please report any bugs related to binutils 2.19.51.0.7 to
hjl.to...@gmail.com
and
http://www.sourceware.org/bugzilla/
Changes from binutils 2.19.51.0.6:
1. Update from binutils 2009 0601.
2. Update STT_GNU_IFUNC support. PR 10205.
3. Fix x86 asssembler Intel syntax regression with '$'. PR 10198.
Changes from binutils 2.19.51.0.5:
1. Update from binutils 2009 0529.
2. Rewrite STT_GNU_IFUNC, R_386_IRELATIVE and R_X86_64_IRELATIVE linker
support for STT_GNU_IFUNC symbols in shared library, dynamic executable
and static executable.
3. Add plugin support.
4. Improve spu support.
Changes from binutils 2.19.51.0.4:
1. Update from binutils 2009 0525.
2. Add STT_GNU_IFUNC, R_386_IRELATIVE and R_X86_64_IRELATIVE support to
assembler and linker.
3. Add LD_AS_NEEDED support to linker.
4. Remove AMD SSE5 support.
5. A new Intel syntax parser in x86 assembler.
6. Add DWARF discriminator support.
7. Add --64 support for x86 PE/COFF assembler.
8. Support common symbol with alignment for PE/COFF.
9. Improve gold support.
10. Improve arm support.
11. Improve mep support.
12. Improve mips support.
13. Improve ppc support.
14. Improve spu support.
Changes from binutils 2.19.51.0.3:
1. Update from binutils 2009 0418.
2. Remove EFI targets and use PEI targets for EFI. Add --file-alignment,
--heap, --image-base, --section-alignment, --stack and --subsystem command
line options for objcopy. PR 10074.
3. Update linker to warn alternate ELF machine code.
4. Fix x86 linker TLS transition. PR 9938.
5. Improve DWARF dumper to check relocations against STT_SECTION
symbol.
6. Guard DWARF dumper on bad DWARF input.
7. Add EM_ETPU and EM_SLE9X. Reserve 3 ELF machine types for Intel.
8. Adding a linker missing entry symbol warning for -pie. PR 9970.
9. Make the -e option for linker to imply -u. PR 6766.
10. Properly handle paging for PEI targets.
11. Fix assembler listing with input from stdin.
12. Update objcopy/string to generate symbol table if there is any
relocation in output. PR 9945.
13. Require texinfo 4.7 for build. PR 10039.
14. Add moxie support.
15. Improve gold support.
16. Improve AIX support.
17. Improve arm support.
18. Improve cris support.
19. Improve crx support.
20. Improve mips support.
21. Improve ppc support.
Fortran-related libgomp failures in case of -fno-openmp
On i386-unknown-freebsd7.1 we see the following tests fail:
FAIL: libgomp.fortran/condinc2.f -O (test for excess errors)
WARNING: libgomp.fortran/condinc2.f -O compilation failed to produce
executable
FAIL: libgomp.fortran/condinc4.f90 -O (test for excess errors)
WARNING: libgomp.fortran/condinc4.f90 -O compilation failed to produce
executable
FAIL: libgomp.fortran/omp_cond2.f -O (test for excess errors)
WARNING: libgomp.fortran/omp_cond2.f -O compilation failed to produce
executable
FAIL: libgomp.fortran/omp_cond4.F90 -O (test for excess errors)
WARNING: libgomp.fortran/omp_cond4.F90 -O compilation failed to produce
executable
Looking into the log files, the pattern is the same in all cases:
Excess errors:
/pfeifer/OBJ-0531-2252/i386-unknown-freebsd7.1/./libgomp/.libs/libgomp.so:
undefined reference to `pthread_create'
And what all of these three testcases have in common is
{ dg-options "-fno-openmp" }
So, it seems -fno-openmp in combination with an attempt to still link
libgomp.so leads to this failure.
Is it possible this is an issue with the testsuite rather than with
the code on FreeBSD?
Gerald
Re: Fortran-related libgomp failures in case of -fno-openmp
On Mon, Jun 01, 2009 at 07:59:15PM +0200, Gerald Pfeifer wrote:
> Excess errors:
> /pfeifer/OBJ-0531-2252/i386-unknown-freebsd7.1/./libgomp/.libs/libgomp.so:
> undefined reference to `pthread_create'
>
> And what all of these three testcases have in common is
>
> { dg-options "-fno-openmp" }
>
> So, it seems -fno-openmp in combination with an attempt to still link
> libgomp.so leads to this failure.
>
>
> Is it possible this is an issue with the testsuite rather than with
> the code on FreeBSD?
>
The code is fine. The problem is with the testsuite. When
-fopenmp is used on FreeBSD, the additional option -pthread
is added to the list of options.
REMOVE:kargl[28] gfortran -v -fopenmp -c d.f90
Using built-in specs.
Target: i386-portbld-freebsd8.0
Configured with: ./..//gcc-4.3-20081120/configure --disable-nls
--with-system-zlib --with-libiconv-prefix=/usr/local --with-gmp=/usr/local
--program-suffix=43 --libdir=/usr/local/lib/gcc-4.3.3
--with-gxx-include-dir=/usr/local/lib/gcc-4.3.3/include/c++/ --disable-rpath
--prefix=/usr/local --mandir=/usr/local/man --infodir=/usr/local/info/gcc43
--build=i386-portbld-freebsd8.0
Thread model: posix
gcc version 4.3.3 20081120 (prerelease) (GCC)
COLLECT_GCC_OPTIONS='-v' '-fopenmp' '-c' '-mtune=i386' '-pthread'
If someone uses -fno-openmp and still tries to link to libgomp,
then the -pthread option is missing and hence the test fail
because -lpthread is not included. On FreeBSD, libgomp.so.1
does not show a dependency on libpthread, so the dynamic linker
can't automagically work.
REMOVE:kargl[30] ldd /usr/home/kargl/work/lib/libgomp.so.1
/usr/home/kargl/work/lib/libgomp.so.1:
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x481a8000)
libc.so.7 => /lib/libc.so.7 (0x4808c000)
--
Steve
Re: Fortran-related libgomp failures in case of -fno-openmp
On Mon, 2009-06-01 at 11:14 -0700, Steve Kargl wrote:
> On Mon, Jun 01, 2009 at 07:59:15PM +0200, Gerald Pfeifer wrote:
> > Excess errors:
> > /pfeifer/OBJ-0531-2252/i386-unknown-freebsd7.1/./libgomp/.libs/libgomp.so:
> > undefined reference to `pthread_create'
> >
> > And what all of these three testcases have in common is
> >
> > { dg-options "-fno-openmp" }
> >
> > So, it seems -fno-openmp in combination with an attempt to still link
> > libgomp.so leads to this failure.
> >
> >
> > Is it possible this is an issue with the testsuite rather than with
> > the code on FreeBSD?
> >
>
> The code is fine. The problem is with the testsuite. When
> -fopenmp is used on FreeBSD, the additional option -pthread
> is added to the list of options.
>
> REMOVE:kargl[28] gfortran -v -fopenmp -c d.f90
> Using built-in specs.
> Target: i386-portbld-freebsd8.0
> Configured with: ./..//gcc-4.3-20081120/configure --disable-nls
> --with-system-zlib --with-libiconv-prefix=/usr/local --with-gmp=/usr/local
> --program-suffix=43 --libdir=/usr/local/lib/gcc-4.3.3
> --with-gxx-include-dir=/usr/local/lib/gcc-4.3.3/include/c++/ --disable-rpath
> --prefix=/usr/local --mandir=/usr/local/man --infodir=/usr/local/info/gcc43
> --build=i386-portbld-freebsd8.0
> Thread model: posix
> gcc version 4.3.3 20081120 (prerelease) (GCC)
> COLLECT_GCC_OPTIONS='-v' '-fopenmp' '-c' '-mtune=i386' '-pthread'
>
> If someone uses -fno-openmp and still tries to link to libgomp,
> then the -pthread option is missing and hence the test fail
> because -lpthread is not included. On FreeBSD, libgomp.so.1
> does not show a dependency on libpthread, so the dynamic linker
> can't automagically work.
Why doesn't libgomp.so.1 show a depedency on libpthread, isn't
that the bug?
> REMOVE:kargl[30] ldd /usr/home/kargl/work/lib/libgomp.so.1
> /usr/home/kargl/work/lib/libgomp.so.1:
> libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x481a8000)
Janis
Re: Fortran-related libgomp failures in case of -fno-openmp
On Mon, Jun 01, 2009 at 12:49:42PM -0700, Janis Johnson wrote: > On Mon, 2009-06-01 at 11:14 -0700, Steve Kargl wrote: > > > > If someone uses -fno-openmp and still tries to link to libgomp, > > then the -pthread option is missing and hence the test fail > > because -lpthread is not included. On FreeBSD, libgomp.so.1 > > does not show a dependency on libpthread, so the dynamic linker > > can't automagically work. > > Why doesn't libgomp.so.1 show a depedency on libpthread, isn't > that the bug? > I've never looked at how the authors of libgomp wrote the build glue nor have I tried to decipher why one would specifically suppress OpenMP with the -fno-openmp option yet still try to link to its runtime library. It does appear that libgomp/configure looks to see if -pthread (or -lpthread) is required, but then it may not use that result in actually building libgomp.so.1 -- Steve
gcc --help for options which are not warnings or optimizations
Nick, how is gcc --help supposed to work for options which are neither warnings nor optimizations? For example, -fstack-protector. Is there a --help option which will display it? Ian
Link error ....redefinition of......
I download source code for book> from:http://users.cs.fiu.edu/~weiss/dsaa_c++/code/,try to compiler it,but got many errors,most of them say: .. previously declared here ...: redefinition of . I think template causes these errors,but how to fix it. --- My configuration: Ubuntu 9.04 GCC version 4.3.3 (Ubuntu 4.3.3-5ubuntu4) Eclipse 3.4 CDT:.5.0.2 - Files and error message are following: StackAr.h - #ifndef STACKAR_H #define STACKAR_H #include "../vector.h" #include "../dsexceptions.h" template class Stack { public: explicit Stack( int capacity = 10 ); bool isEmpty( ) const; . #include "StackAr.cpp" #endif -- StackAr.cpp #include "StackAr.h" template Stack::Stack( int capacity ) : theArray( capacity ) { topOfStack = -1; } template bool Stack::isEmpty( ) const { return topOfStack == -1; } ... Test.cpp #include #include "StackAr.h" using namespace std; int main() { Stack s; for (int i = 0; i < 10; i++) s.push(i); while (!s.isEmpty()) cout << s.topAndPop() << endl; return 0; } - error message: Build of configuration Debug for project DACPP make all Building file: ../src/stack/StackAr.cpp Invoking: GCC C++ Compiler g++ -O0 -g3 -Wall -c -fmessage-length=0 -MMD -MP -MF"src/stack/StackAr.d" -MT"src/stack/StackAr.d" -o"src/stack/StackAr.o" "../src/stack/StackAr.cpp" ../src/stack/StackAr.cpp:7: erreur: redefinition of ‘Stack::Stack(int)’ ../src/stack/StackAr.cpp:7: erreur: ‘Stack::Stack(int)’ previously declared here ../src/stack/StackAr.cpp:17: erreur: redefinition of ‘bool Stack::isEmpty() const’ ../src/stack/StackAr.cpp:17: erreur: ‘bool Stack::isEmpty() const’ previously declared here ...
Re: Link error ....redefinition of......
On Tuesday 02 June 2009 08:16:35 Alex Luya wrote:
> I download source code for book < Analysis in C++ (Second Edition), /by Mark Allen Weiss>>
> from:http://users.cs.fiu.edu/~weiss/dsaa_c++/code/,try to compiler
> it,but got many errors,most of them say:
> .. previously declared here
> ...: redefinition of .
>
> I think template causes these errors,but how to fix it.
This is not the correct mailing list for such questions! Nevertheless, the
reason for your compile errors is a simple one. Just drop the line
#include "StackAr.cpp"
from your header file. Why are you trying to include the implementation in the
header? The other way round is how things work! (And you do have the header
include in your implementation - why both directions?)
> ---
> My configuration:
> Ubuntu 9.04
> GCC version 4.3.3 (Ubuntu 4.3.3-5ubuntu4)
> Eclipse 3.4
> CDT:.5.0.2
> -
>
> Files and error message are following:
>
> StackAr.h
> -
> #ifndef STACKAR_H
> #define STACKAR_H
>
> #include "../vector.h"
> #include "../dsexceptions.h"
>
> template
> class Stack
> {
> public:
> explicit Stack( int capacity = 10 );
> bool isEmpty( ) const;
> .
> #include "StackAr.cpp"
> #endif
>
> --
>
> StackAr.cpp
>
> #include "StackAr.h"
> template
> Stack::Stack( int capacity ) : theArray( capacity )
> {
> topOfStack = -1;
> }
>
> template
> bool Stack::isEmpty( ) const
> {
> return topOfStack == -1;
> }
> ...
>
> Test.cpp
> #include
> #include "StackAr.h"
> using namespace std;
>
> int main()
> {
> Stack s;
>
> for (int i = 0; i < 10; i++)
> s.push(i);
>
> while (!s.isEmpty())
> cout << s.topAndPop() << endl;
> return 0;
> }
>
>
> -
> error message:
>
> Build of configuration Debug for project DACPP
>
> make all
> Building file: ../src/stack/StackAr.cpp
> Invoking: GCC C++ Compiler
> g++ -O0 -g3 -Wall -c -fmessage-length=0 -MMD -MP
> -MF"src/stack/StackAr.d" -MT"src/stack/StackAr.d"
> -o"src/stack/StackAr.o" "../src/stack/StackAr.cpp"
> ../src/stack/StackAr.cpp:7: erreur: redefinition of
> ‘Stack::Stack(int)’
> ../src/stack/StackAr.cpp:7: erreur: ‘Stack::Stack(int)’
> previously declared here
> ../src/stack/StackAr.cpp:17: erreur: redefinition of ‘bool
> Stack::isEmpty() const’
> ../src/stack/StackAr.cpp:17: erreur: ‘bool Stack::isEmpty()
> const’ previously declared here
> ...
--
<><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
<> <>
<> Tim München, M.Sc.muenc...@physik.uni-wuppertal.de <>
<> Bergische Universitaet <>
<> FB C - Physik Tel.: +49 (0)202 439-3521 <>
<> Gaussstr. 20 Fax : +49 (0)202 439-2811 <>
<> 42097 Wuppertal <>
<> <>
<><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
