Hi, Dave,
Thanks a lot for your help.
Best Regards
Jian-ping
-"Dave Korn" <[EMAIL PROTECTED]> wrote: -
To: <[EMAIL PROTECTED]>,
From: "Dave Korn" <[EMAIL PROTECTED]>
Date: 01/17/2006 07:04PM
cc: <[EMAIL PROTECTED]>
Subject: RE: Forwa
Jian-ping.Hui wrote:
> Now my question is: Why there are such difference between the two version
> gcc?
This is a VFAQ. See http://gcc.gnu.org/gcc-3.4/changes.html#cplusplus
> Could I compile b.cpp by simply changing some compiler options?
No, you will have to fix the invalid code to be f
Sorry for the previous wrong format mail. Please ignore it.
I encountered an issue when building our program. The compilation will fail
when using gcc 3.4.3. However, the same program can be compiled
successfully with gcc 3.2.3.
I used the following example to reproduce the issue:
=
a.h
Hi,
I encountered an issue when building our program. The compilation will fail
when using gcc 3.4.3. However,
the same program can be compiled successfully with gcc 3.2.3.
I used the following example to reproduce the issue:
=
a.h
=
#ifndef A_H_
#define A_H_
class A
{
public
On Tue, 2005-11-08 at 17:22, Albert Chin wrote:
> A .depot file is a tar file so just untar it.
Yeah, I knew that, it just took me a while to remember. I added
comments to PR 24718 explaining what the underlying problem is, and
confirming the bug. I probably can't do much more as I don't have an
On Tue, Nov 08, 2005 at 04:00:42PM -0800, Jim Wilson wrote:
> The only part I don't understand is where these specs came from, as
> this doesn't match anything in the FSF tree. I'm guessing that HP
> is distributing a modified gcc with patches added to it, and these
> patches are buggy. I went to
Steve Ellcey wrote:
I am not convinced there is a bug here.
There is an extremely obvious bug here. Please look at the specs that
Albert Chin included in his email message. There is no way that
-static-libgcc should require -shared-libgcc, which is what happens in
his specs.
The only par
> > As mentioned before, there is a brace missing after the gcc_s_hpux64.
> > This brace is needed to close off the shared-libgcc rule before the
> > static-libgcc rule starts. You then must delete a brace from the end of
> > the !static rule which has one too many.
>
> Yes, doing so gives the
On Mon, Nov 07, 2005 at 06:27:40PM -0800, Jim Wilson wrote:
> Albert Chin wrote:
> >I set ':set showmatch' in vim and all the braces match up.
>
> Yes, the braces match up. You wouldn't have been able to build gcc if
> they didn't.
>
> However, they are still wrong. One of the braces is in the
on problem, but that seems
rather unlikely.
The above is from gcc-3.4.3 + some patches. However, the HP 3.4.4
binary has the same "*libgcc" line. Do you have a GCC 3.4.x binary on
HP/IA-64 which works correctly with -shared?
I do not have an ia64-hpux machine. I have an HP loaner,
problem in the FSF gcc tree. I'm guessing this is
> a mistake in the HP gcc sources that you are using.
The above is from gcc-3.4.3 + some patches. However, the HP 3.4.4
binary has the same "*libgcc" line. Do you have a GCC 3.4.x binary on
HP/IA-64 which works correctly with -shared?
--
albert chin ([EMAIL PROTECTED])
Albert Chin wrote:
The "*libgcc" line from the 3.4.3/3.4.4 specs file:
*libgcc:
%{shared-libgcc:%{!mlp64:-lgcc_s}%{mlp64:-lgcc_s_hpux64}
%{static|static-libgcc:-lgcc -lgcc_eh
-lunwind}%{!static:%{!static-libgcc:%{!shared:%{!shared-libgcc:-lgcc -lgcc_eh
-lunwind}%{shared-libgcc:-lgcc_s%M -l
I've built gcc-3.4.3 for HP-UX 11.23/IA-64 and used the pre-compiled
gcc-3.4.4 binary from the http://www.hp.com/go/gcc site. Both exhibit
the same problem. While trying to build Perl 5.8.6:
$ gmake
...
gcc -v -o libperl.so -shared -fPIC perl.o gv.o toke.o perly.o op.o
pad.o regc
Hello
I have taken the opensoruce from
http://www-personal.engin.umich.edu/~wagnerr/ConfigFile.html for reading
configuration file. It perfectly works fine with gcc 3.2.3 and it fail
to compile with gcc 3.4.3 on RHEL 4
I am getting following error
g++ -Wno-trigraphs -Wno-unused -Wno
celeron_obj-gcc-3.4.3> /export/users/jordan/compile/gcc/gcc-3.4.3/config.guess
i386-pc-solaris2.8
celeron_obj-gcc-3.4.3> which gcc
/usr/local/bin/gcc
celeron_obj-gcc-3.4.3> gcc -v
Reading specs from /usr/local/lib/gcc/i386-pc-solaris2.8/3.4.3/specs
Configured with: /export/users/jordan/co
Kenneth P.. Massey wrote:
> The code below runs significantly slower when compiled in 64 bit with
> 3.4.3 than
> it does in 3.3.4, and both are significantly slower than a 32 bit
> compile.
Thanks for the report. Would you please open a bugreport in Bugzilla?
--
Giovanni Bajo
The code below runs significantly slower when compiled in 64 bit with 3.4.3 than
it does in 3.3.4, and both are significantly slower than a 32 bit compile.
Can anyone tell what's going on:
1) between 32 and 64 bits
2) between 3.3.4 and 3.4.3
Thanks.
amd64 3200, 1024k cache
with gcc
Gary Funck wrote:
(call_insn 84 66 141 (call_placeholder 77 67 0 0 (call_insn 83 82 0 (parallel [
call_placeholder is a special kind of RTL. It contains 3 instruction
sequences for the 3 different possible kinds of calls: a normal call, a
tail call, and a sibling call. These aren't printed in t
Hello, using the 3.4.3 baseline on SGI MIPS3 Irix6.5,
I'm running into a problem where bad code is generated on a relatively
trivial program when both -funit-at-a-time and -foptimize-sibling-calls
is asserted. The nature of the failure is that the RTL optimizer
seems to get confused about what va
bash-3.00$ ../gcc-3.4.3/config.guess
i586-pc-interix3
bash-3.00$ gcc/xgcc -v
Using built-in specs.
Configured with: ../gcc-3.4.3/configure --verbose --disable-shared
--with-stabs --enable-nls --with-gnu-as --with-gnu-ld
--enable-targets=i586-pc-interix3 --enable-threads=posix
--enable-languages=c
Original Message
>From: Hugh Sasse Staff Elec Eng
>Sent: 12 April 2005 15:40
>> "Yes, since the fix was in the top level. I have already closed at
>> least two binutils PRs about this as FIXED - searching for product ==
>> binutils, subject containing install, state containing RESOLVED wo
On Tue, 12 Apr 2005, Dave Korn wrote:
Original Message
From: Hugh Sasse Staff Elec Eng
Sent: 12 April 2005 14:49
Wouldn't it be an awful lot easier to just
A) apply the previously-mentioned fix to toplevel?
If I knew where it was mentioned, probably.
Earlier in this very thread, Daniel
Original Message
>From: Hugh Sasse Staff Elec Eng
>Sent: 12 April 2005 14:49
>> Wouldn't it be an awful lot easier to just
>>
>> A) apply the previously-mentioned fix to toplevel?
>
> If I knew where it was mentioned, probably.
Earlier in this very thread, Daniel Jacobowitz said (i
obably.
B) use a full path to configure, since this only crops up when using a
relative path to the configure script?
This seems to be what happened in practice, but my :
cp gcc-3.4.3/install-sh gcc-3.4.3/boehm-gc
cp gcc-3.4.3/install-sh gcc-3.4.3/config
cp gcc-3.4.3/install-sh gcc-3.4.3/contr
Original Message
>From: Ray Holme
>Sent: 12 April 2005 13:42
> the install-sh is always referenced in the parent directory.
> (../install-sh)
>
> so for all the first level directories in the install directory - one copy
> at the top will do.
>
> now for sub-sub directories - you must co
the install-sh is always referenced in the parent directory.
(../install-sh)
so for all the first level directories in the install directory - one copy
at the top will do.
now for sub-sub directories - you must copy (or link) one into the parent
sub-directory.
I don't think there are any three
e top level installs work, but the sub-sub directories
were still looking for ../install-sh - so I copied it down another level
Thanks again.
Ray Holme
So I am right in thinking one must copy gcc-3.4.3/install.sh into
all of these, or is there a subset that will do?
gcc-3.4.3/boehm-gc
gcc-3.4.3/boe
On Fri, Apr 08, 2005 at 10:13:38AM -0700, Joe Buck wrote:
> On Fri, Apr 08, 2005 at 09:20:47AM -0400, Daniel Jacobowitz wrote:
> > On Fri, Apr 08, 2005 at 09:05:17AM -0400, Ray Holme wrote:
> > > Many thanks to all for the lessons on how NOT to make things you don't
> > > want.
> > >
> > > After 5
On Fri, Apr 08, 2005 at 09:20:47AM -0400, Daniel Jacobowitz wrote:
> On Fri, Apr 08, 2005 at 09:05:17AM -0400, Ray Holme wrote:
> > Many thanks to all for the lessons on how NOT to make things you don't
> > want.
> >
> > After 56 hours teh full make bootstrap finished - make install failed
> > mis
On Fri, Apr 08, 2005 at 09:05:17AM -0400, Ray Holme wrote:
> Many thanks to all for the lessons on how NOT to make things you don't
> want.
>
> After 56 hours teh full make bootstrap finished - make install failed
> miserable as
> install.sh was not where it belonged - so I copied the SRCDIR insta
Many thanks to all for the lessons on how NOT to make things you don't
want.
After 56 hours teh full make bootstrap finished - make install failed
miserable as
install.sh was not where it belonged - so I copied the SRCDIR install.sh
in and that made the top level installs work, but the sub-sub dir
Hi,
Here are build and test results for gcc-3.4.3 on standard (just slightly
upgraded) Red Hat Linux 8.0 system. Everything worked fine.
Regards,
Anna Aret
==
config.guess
i686-pc-linux-gnu
gcc -v
Reading specs from /usr/local/lib
On Saturday 19 March 2005 07:51, Carl van_Schaik wrote:
> I'm running into a bug with gcc 3.4.3:
>
> I've got syscall code for user-land to our kernel that trashes r14/lr.
> The code is inlined, and works find in ARM mode. When compiling in thumb,
> gcc does not prese
I'm running into a bug with gcc 3.4.3:
I've got syscall code for user-land to our kernel that trashes r14/lr.
The code is inlined, and works find in ARM mode. When compiling in thumb,
gcc does not preserve lr. With an older gcc 3.3.3, the code was not inlined,
but generated correctly.
Reporting a smooth and successful build of gcc-3.4.3
on Red Hat Linux release 8.0 (Psyche) with kernel
2.6.11.2
[EMAIL PROTECTED] gcc-3.4.3]# ./config.guess
i686-pc-linux-gnu
[EMAIL PROTECTED] gcc-3.4.3]# gcc -v
Reading specs from
/usr/local/lib/gcc/i686-pc-linux-gnu/3.4.3/specs
Configured with
> From: James E Wilson
> Sent: Tuesday, March 08, 2005 6:59 PM
[...]
>
> Try re-reading the docs. -fkeep-static-consts is the default. The
> purpose of this is that we don't perform this optimization at -O0
> normally, but if you use -fno-keep-static-consts, then we do. So this
> option can
Gary Funck wrote:
When compiled with GCC 3.4.3, at -O2, the ident string above will _not_
appear in the executable. This is apparently expected behavior.
See the docs for __attribute__ ((used)). Contrary to the docs, it works
for more than functions.
However, interestingly,
gcc -fkeep-static
Given the following,
static char const rcsid[] =
"$Id: f.c,v 5.4 1993/11/09 17:40:15 eggert Exp $";
int main() {}
When compiled with GCC 3.4.3, at -O2, the ident string above will _not_
appear in the executable. This is apparently expected behavior.
However, interestingly,
gcc -fk
Syed Shabir Zakiullah <[EMAIL PROTECTED]> writes:
> While building gcc-3.4.3 I am getting following error during make stage.
>
> ../../../libiberty/cplus-dem.c:55: error: conflicting types for 'malloc'
> ../../../libiberty/cplus-dem.c:55: error: c
While building gcc-3.4.3 I am getting following error during make stage.
../../../libiberty/cplus-dem.c:55: error: conflicting types for 'malloc'
../../../libiberty/cplus-dem.c:55: error: conflicting types for 'malloc'
../../../libiberty/cplus-dem.c: In function
I have now tested the -ieee flag. So this is a documentation error,
because the vital option is not mentioned in the host specific note.
I have added a suggested documentation change to PR16787. It would be
good if someone could fix the documentation.
Bill Northcott
On 10/02/2005, at 12:56 PM
41 matches
Mail list logo
