Location for gcc402.zip
Please let me know the location of the gcc402.zip Thanks Amrith
Re: Location for gcc402.zip
> Please let me know the location of the gcc402.zip If you are looking for GCC releases, please see: http://gcc.gnu.org/releases.html Ben
Forward declaration issue on gcc 3.4.3
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:
A() { }
~A() { }
void FuncA();
};
#endif
==
a.cpp
==
#include "a.h"
==
b.h
==
#ifndef B_H_
#define B_H_
class A;
template class B
{
public:
B() { }
~B() { }
void FuncB()
{
A* pa;
pa->FuncA();
}
};
#endif
==
b.cpp
==
#include "b.h"
#include "a.h"
I used the following commands to compile b.cpp:
/usr/bin/g++ -c -g b.cpp
I got different result when using different version gcc.
===
gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-42)
===
Success.
===
gcc version 3.4.3 20041212 (Red Hat 3.4.3-9.EL4)
===
Fail with errors as below:
In file included from b.cpp:1:
b.h: In member function `void B::FunB()':
b.h:16: error: invalid use of undefined type `struct A'
b.h:4: error: forward declaration of `struct A'
If I change the order of head files in b.cpp to:
#include "a.h"
#include "b.h"
The compilation will pass.
Now my question is: Why there are such difference between the two version
gcc? Could I compile b.cpp
by simply changing some compiler options? Hopeful for your quick reply. I
'm very appeaciate for your
help.
Thanks.
Best Regards
Jianping
2006-01-16
Problem with Trampolines initialization
Hello everyone, I have a doubt reagarding these trampolines, When i was going through the details in an atricle named GCC-INTERNALS, It said that we have a macro with the following name TRAMPOLINE_ADJUST_ADDRESS (addr). The explaination to it said that this is used mainly to perform any machine-specific adjustment in the address of the trampoline. addr holds the address that was passed to INITIALIZE_TRAMPOLINE. In case the address to be used for a function call should be different from the address in which the template was stored, the different address should be assigned to addr. If this macro is not defined, addr will be used for function calls. If this macro is not defined, by default the trampoline is allocated as a stack slot. This default is right for most machines. The exceptions are machines where it is impossible to execute instructions in the stack area. On such machines, you may have to implement a separate stack, using this macro in conjunction with TARGET_ASM_FUNCTION_PROLOGUE and TARGET_ASM_FUNCTION_EPILOGUE. Now, the problem is with the lines in bold , that when TRAMPOLINE_INITIALIZE is used then at that time, where is the trampoline allocated. From whatever i understood, i> First the initialisation macro is used ii> then the tramp..._adjust_addr... is used. What if we dont define ii> then in that case during initialisation where would it be by default ? Also, these trampolines are doing two jobs, loading of the static chain regs jump to real addr of nested funcs This code is present on the stack by default. Can I have the pleasure to have a look at that piece of code at run time, ya this code is generated by gcc, any suggestions for getting to the code which is responsible for generating the code for these trampolines. -- Regards, Sandeep A candle loses nothing if it is used to light another one!
Forward declaration issue on gcc 3.4.3(New)
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
=
#ifndef A_H_
#define A_H_
class A
{
public:
A() { }
~A() { }
void FuncA();
};
#endif
==
a.cpp
==
#include "a.h"
==
b.h
==
#ifndef B_H_
#define B_H_
class A;
template class B
{
public:
B() { }
~B() { }
void FuncB()
{
A* pa;
pa->FuncA();
}
};
#endif
==
b.cpp
==
#include "b.h"
#include "a.h"
I used the following commands to compile b.cpp:
/usr/bin/g++ -c -g b.cpp
I got different result when using different version gcc.
===
gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-42)
===
Success.
===
gcc version 3.4.3 20041212 (Red Hat 3.4.3-9.EL4)
===
Fail with errors as below:
In file included from b.cpp:1:
b.h: In member function `void B::FunB()':
b.h:16: error: invalid use of undefined type `struct A'
b.h:4: error: forward declaration of `struct A'
If I change the order of head files in b.cpp to:
#include "a.h"
#include "b.h"
The compilation will pass.
Now my question is: Why there are such difference between the two version
gcc? Could I compile b.cpp by simply changing some compiler options?
Hopeful for your quick reply. I 'm very appeaciate for your help.
Thanks.
Best Regards
Jianping Hui
2006-01-16
RE: Forward declaration issue on gcc 3.4.3(New)
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 fully compliant with the C++ language standard. cheers, DaveK -- Can't think of a witty .sigline today
Re: -msep-data without -fPIC ?
On Sat, Jan 14, 2006 at 02:21:20AM +0100, Philippe De Muyter wrote: > For an embedded mmu-less m68k target, I would like to generate code > that will always run at a fixed place in memory, thus not needing to be PIC, > but that would access a data+bss segment that could be anywhere in memory, > thus needing accesses to the data segment via %a5 and an offset table. > > 1. Does that possibility already exist in gcc (I did not find it) ? > -msep-data currently does PI-text + PI-data. AFAICT, this doesn't exist within mainline GCC. The AmigaOS port (which isn't part of the official sources) implements this scheme, either with 16bit or 32bit displacements. The latter requires a 68020 or better. Note, you need binutils support as well. > 2. If it does not exist, I plan to integrate it. > - From which release or branch should I start ? > I'd like to work on something that is stable except for my changes. You have to use current mainlines sources. > - How is it currently possible in the gcc internals to know if a > SYMBOL_REF points to the .text or .rodata segments ? The AmigaOS port uses SYMBOL_REF_FLAG to record this information. I believe SYMBOL_REF_FLAG is deprecated and there is a newer functionality to achieve the same. Gunther
Re: -msep-data without -fPIC ?
Gunther Nikl wrote : > On Sat, Jan 14, 2006 at 02:21:20AM +0100, Philippe De Muyter wrote: > > For an embedded mmu-less m68k target, I would like to generate code > > that will always run at a fixed place in memory, thus not needing to be PIC, > > but that would access a data+bss segment that could be anywhere in memory, > > thus needing accesses to the data segment via %a5 and an offset table. > > > > 1. Does that possibility already exist in gcc (I did not find it) ? > > -msep-data currently does PI-text + PI-data. > > AFAICT, this doesn't exist within mainline GCC. The AmigaOS port (which > isn't part of the official sources) implements this scheme, either with > 16bit or 32bit displacements. The latter requires a 68020 or better. > Note, you need binutils support as well. Where is that AmigaOS port availaible ? That seems to be an easier solution. > > > 2. If it does not exist, I plan to integrate it. > > - From which release or branch should I start ? > > I'd like to work on something that is stable except for my changes. > > You have to use current mainlines sources. > > > - How is it currently possible in the gcc internals to know if a > > SYMBOL_REF points to the .text or .rodata segments ? > > The AmigaOS port uses SYMBOL_REF_FLAG to record this information. I believe > SYMBOL_REF_FLAG is deprecated and there is a newer functionality to achieve > the same. > > Gunther > Thanks for your answer Philippe
Re: -msep-data without -fPIC ?
On Tue, Jan 17, 2006 at 01:35:59PM +0100, Philippe De Muyter wrote: > Gunther Nikl wrote : > > On Sat, Jan 14, 2006 at 02:21:20AM +0100, Philippe De Muyter wrote: > > > For an embedded mmu-less m68k target, I would like to generate code > > > that will always run at a fixed place in memory, thus not needing to be > > > PIC, > > > but that would access a data+bss segment that could be anywhere in memory, > > > thus needing accesses to the data segment via %a5 and an offset table. > > > > > > 1. Does that possibility already exist in gcc (I did not find it) ? > > > -msep-data currently does PI-text + PI-data. > > > > AFAICT, this doesn't exist within mainline GCC. The AmigaOS port (which > > isn't part of the official sources) implements this scheme, either with > > 16bit or 32bit displacements. The latter requires a 68020 or better. > > Note, you need binutils support as well. > > Where is that AmigaOS port availaible ? > That seems to be an easier solution. GCC diffs upto 3.4.0 are available here: ftp://ftp.back2roots.org/pub/geekgadgets/amiga/m68k/alpha/gcc/ There is a sourceforge project called "adtools" which is intended to have the AmigaOS/68k GCC port. Currently those patches are not integrated yet. However, the binutils support is available there. http://www.sourceforge.net/projects/adtools/ Its probably impossible to integrate anything from there into official sources because its imposible to tell who participated in developing these features. Gunther
Re: What should -fdump-tree-...-details include? (was Re: Patch ping)
Hello, > > another point to consider is that perhaps there might be some common > > way how to specify "detail level"; we already have -fsched-verbose=num > > and -ftree-vectorizer-verbose=num, perhaps we should avoid having a > > separate flag for each pass. > > > Good point. Would you be willing to work on implementing this? Or perhaps > put it in the TODO list on the Wiki so someone else can work on it? I will try to come up with something. Zdenek
successfully built and installed GCC
Classification: UNCLASSIFIED i686-pc-linux-gnu Using built-in specs. Target: i686-pc-linux-gnu Configured with: /home/joshuang/joshuang/gcc-4.0.2/configure --prefix=/home/joshuang/joshuang/local Thread model: posix gcc version 4.0.2 Red Hat Linux release 7.3 (Valhalla) Kernel \r on an \m Linux 2.4.18-3bigmem+lsf #4 SMP i686 unknown glibc-2.2.5-34
How to submit suggestions?
While doing my RS/6000 work last week, I bumped into two bugs and two other items which I would more consider suggestions. The bugs I will submit via the prescribed method. But how to the maintainers want to see the suggestions? Thanks, Perry Smith
Re: How to submit suggestions?
> Perry Smith writes: Perry> While doing my RS/6000 work last week, I bumped into two bugs and two Perry> other items which I would more consider suggestions. The bugs I will Perry> submit via the prescribed method. But how to the maintainers want to Perry> see the suggestions? GCC Bugzilla enhancement request? David
Note about 1.3 server large commit issue
Just so you guys know, a change in 1.3 will make large commits take a longer than they used to. We background the task that sends out the mail, and in 1.2, this used to cause the post-commit hook that runs to return immediately. However, 1.3, in order to catch output from the post-commit hooks, now waits for the entire script to finish, including it's children. Thus, commits will sit there till the mailer finishes creating the mail messages (not until it's done sending them). I'm working on this, while there is a discussion on svn-dev about what to do here. It's obviously a tricky problem. If it lasts much longer, i'll probably just hack up our local 1.3 version to not catch the output, since we log it separately anyway. Just letting you guys know what is up. --Dan
Re: [Ada] GCC 4.1 Status Report (2006-01-15)
> http://gcc.gnu.org/ml/gcc-testresults/2006-01/msg00833.html > hppa2.0w-hp-hpux11.11 has some cxg problems, but I don't > know if 4.0 worked at all there. A testsuite run with ada for 4.0.3 is here: http://gcc.gnu.org/ml/gcc-testresults/2006-01/msg00893.html. The run terminated before completing. I've added the test that caused the failure to my norun list. A PR is here: http://gcc.gnu.org/ml/gcc-bugs/2006-01/msg01655.html. Dave -- J. David Anglin [EMAIL PROTECTED] National Research Council of Canada (613) 990-0752 (FAX: 952-6602)
Re: GCC can't stop using GNU libiconv if it's in /usr/local
> IMHO, the fact that GCC includes /usr/local/include by default in it's > system header search path is brain damaged, but it's probably way too > entrenched to revisit that. :-( > > --Kaveh > -- > Kaveh R. Ghazi[EMAIL PROTECTED] You can stop this by specifying --with-local-prefix=/not-usr-local when configuring GCC. I have built a GCC into a location like /be by specifying both --prefix=/be and --with-local-prefix=/be This GCC does not look in /usr/local/include (but does search /be/include). Steve Ellcey [EMAIL PROTECTED]
Importing GNU Classpath 0.20
Hi, GNU Classpath 0.20 was released last weekend. It contains a lot of new standard library classes and bug fixes. See http://www.gnu.org/software/classpath/announce/20060113.html And the list of fixed bugs: http://gcc.gnu.org/bugzilla/buglist.cgi?product=classpath&target_milestone=0.20 We will import this now into the libjava directory on the trunk. Please let us know ([EMAIL PROTECTED]) if there are any issues with the new import. Cheers, Mark -- Escape the Java Trap with GNU Classpath! http://www.gnu.org/philosophy/java-trap.html Join the community at http://planet.classpath.org/ signature.asc Description: This is a digitally signed message part
Re: Status of -fstack-usage?
On Sun, 15 Jan 2006, Olivier Hainque wrote: > Bernd Trog wrote: > > Will it output the real or worst case stack usage? > > The latter in any case, although I'm not sure what you mean by "real" > stack usage. Could you please enligthen ? By "real" I ment the actual stack usage (which is -Ox dependent) and by "worst case" I ment by looking simply at the code before any optimization. The actual stack usage would be most interesting, of course. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
-Wpointer-sign for GCC 4.1
Someone's informed Richard Stallman that this (annoying) warning will not be enabled by default in GCC 4.1. But, it currently seems to be. Should it be turned off before the release? If not, who told RMS it was? :-) -- Daniel Jacobowitz CodeSourcery
Re: PATCH[m68k] : ColdFire : Allow addq/subq to memory
"Philippe De Muyter" <[EMAIL PROTECTED]> writes: > * config/m68k/m68k.md (*addsi3_5200): Allow addq/subq to memory > operands. This is ok, but please send the patch to [EMAIL PROTECTED] Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: PATCH[m68k] : ColdFire : Allow addq/subq to memory
Andreas Schwab wrote : > "Philippe De Muyter" <[EMAIL PROTECTED]> writes: > > > * config/m68k/m68k.md (*addsi3_5200): Allow addq/subq to memory > > operands. > > This is ok, but please send the patch to [EMAIL PROTECTED] > > Andreas. It is already there :) http://gcc.gnu.org/ml/gcc-patches/2005-08/msg01551.html Do you need a resend ? Philippe
Libmudflap and MIPS, does it work?
I am running make -k check on a 4.1 mipsel-linux cross compiler. It seems that many of the libmudflap tests enter some sort of endless loop. Strace shows no system calls, but they take 100% of the cpu. Has anyone ever gotten mudflap working on mips? If not would it be a good idea to disable mudflap by default on mips? David Daney
Successful build and install of gcc 3.4.5
config.guess output: i686-pc-linux-gnu gcc -v output: Reading specs from /usr/local/lib/gcc/i686-pc-linux-gnu/3.4.5/specs Configured with: ../gcc-3.4.5/configure Thread model: posix gcc version 3.4.5 Distribution: SUSE LINUX 10.0 (i586) uname -srv output:Linux 2.6.13-15.7-default #1 Tue Nov 29 14:32:29 UTC 2005 rpm -q glibc: glibc-2.3.5-40 Other comments: Installed alongside gcc 4.0.2 which is standard for this distribution. Accepting the default prefix of /usr/local was not necessarily a good idea as some applications require a later version of the libraries (fixed by inserting /usr/lib before /usr/local/lib in /etc/ld.so.conf). -- Stephen pgpBbWPCU6Yvg.pgp Description: PGP signature
Successful build and install of gcc-3.4.5
> ./config.guess x86_64-unknown-linux-gnu > gcc -v Reading specs from /usr/local/lib/gcc/x86_64-unknown-linux-gnu/3.4.5/specs Configured with: ../gcc-3.4.5/configure Thread model: posix gcc version 3.4.5 Distribution: SUSE LINUX 10.0 (X86-64) > uname -srv Linux 2.6.13-15.7-default #1 Tue Nov 29 14:32:29 UTC 2005 > rpm -q glibc glibc-2.3.5-40 -- Stephen pgpr7AwuZkKUt.pgp Description: PGP signature
gcc-3.4-20060117 is now available
Snapshot gcc-3.4-20060117 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/3.4-20060117/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 3.4 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-3_4-branch revision 109841 You'll find: gcc-3.4-20060117.tar.bz2 Complete GCC (includes all of below) gcc-core-3.4-20060117.tar.bz2 C front end and core compiler gcc-ada-3.4-20060117.tar.bz2 Ada front end and runtime gcc-g++-3.4-20060117.tar.bz2 C++ front end and runtime gcc-g77-3.4-20060117.tar.bz2 Fortran 77 front end and runtime gcc-java-3.4-20060117.tar.bz2 Java front end and runtime gcc-objc-3.4-20060117.tar.bz2 Objective-C front end and runtime gcc-testsuite-3.4-20060117.tar.bz2The GCC testsuite Diffs from 3.4-20060110 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-3.4 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: Libmudflap and MIPS, does it work?
On Jan 17, 2006, at 1:54 PM, David Daney wrote: I am running make -k check on a 4.1 mipsel-linux cross compiler. It seems that many of the libmudflap tests enter some sort of endless loop. Strace shows no system calls, but they take 100% of the cpu. Has anyone ever gotten mudflap working on mips? I've never tried, but I think that mudflap isn't guaranteed to work for cross compilers. Frank? If not would it be a good idea to disable mudflap by default on mips? Tried native? If that also doesn't work I'd be up for disabling. -eric
Re: PATCH[m68k] : ColdFire : Allow addq/subq to memory
"Philippe De Muyter" <[EMAIL PROTECTED]> writes: > Andreas Schwab wrote : >> "Philippe De Muyter" <[EMAIL PROTECTED]> writes: >> >> >* config/m68k/m68k.md (*addsi3_5200): Allow addq/subq to memory >> >operands. >> >> This is ok, but please send the patch to [EMAIL PROTECTED] >> >> Andreas. > > It is already there :) > > http://gcc.gnu.org/ml/gcc-patches/2005-08/msg01551.html Sorry, it's too long ago to remember. > Do you need a resend ? No, it's ok. Please check in. Thanks, Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: Libmudflap and MIPS, does it work?
Hi - > >Has anyone ever gotten mudflap working on mips? > I've never tried, but I think that mudflap isn't guaranteed to work > for cross compilers. Frank? The compiler portion (tree-mudflap.c) should work about as well for crosses as for native builds. The part that poses porting problems is the libmudflap runtime. > >If not would it be a good idea to disable mudflap by default on mips? > Tried native? If that also doesn't work I'd be up for disabling. I was under the impression that libmudflap was disabled by default almost everywhere. Unless libmudflap is ported for the libc in question, it should not be built. - FChE
Re: -msep-data without -fPIC ?
Gunther Nikl wrote : > On Tue, Jan 17, 2006 at 01:35:59PM +0100, Philippe De Muyter wrote: > > Where is that AmigaOS port availaible ? > > That seems to be an easier solution. > > GCC diffs upto 3.4.0 are available here: > >ftp://ftp.back2roots.org/pub/geekgadgets/amiga/m68k/alpha/gcc/ I have downloaded them, and found the -baserel(32) and -resident(32) options. That seems to be a good starting point, but is not precisely what I meant. What I meant is : .text segment is not pic and is linked for a well known address, .rodata segment is linked for a fixed address. Initialized data containing references to the text or rodata are kept in rodata, as they need no relocation. data, bss, and initialized data containing references to data or bss are accessed via a5 Is that available ? I would like to compile busybox that way, and execute it in place from my flash, without duplicating in ram for each process what should be read-only datas. Philippe > > There is a sourceforge project called "adtools" which is intended to have > the AmigaOS/68k GCC port. Currently those patches are not integrated yet. > However, the binutils support is available there. > >http://www.sourceforge.net/projects/adtools/ > > Its probably impossible to integrate anything from there into official > sources because its imposible to tell who participated in developing > these features. > > Gunther >
Re: Libmudflap and MIPS, does it work?
On Jan 17, 2006, at 5:57 PM, Frank Ch. Eigler wrote: If not would it be a good idea to disable mudflap by default on mips? Tried native? If that also doesn't work I'd be up for disabling. I was under the impression that libmudflap was disabled by default almost everywhere. Unless libmudflap is ported for the libc in question, it should not be built. Since this mips-linux-gnu, I would not doubt this is just the case of an older glibc which is causing the problem. David, what version of glibc are you using? -- Pinski
Re: [PATCH] Re: conversion warnings in c++
The overall patch is OK. Please could add testcases that test -Wno-conversion? Thanks for doing this. Thanks. I've committed the patch and a testcase that makes sure we don't emit a warning if Wconversion is turned off. -eric
Re: Libmudflap and MIPS, does it work?
Andrew Pinski wrote: On Jan 17, 2006, at 5:57 PM, Frank Ch. Eigler wrote: If not would it be a good idea to disable mudflap by default on mips? Tried native? If that also doesn't work I'd be up for disabling. I was under the impression that libmudflap was disabled by default almost everywhere. Unless libmudflap is ported for the libc in question, it should not be built. Since this mips-linux-gnu, I would not doubt this is just the case of an older glibc which is causing the problem. David, what version of glibc are you using? 2.3.3/linux-threads + some patches (mostly to make it build with gcc-3.4) David Daney
RE: Forward declaration issue on gcc 3.4.3(New)
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: Forward declaration issue on gcc 3.4.3(New) 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 fully compliant with the C++ language standard. cheers, DaveK -- Can't think of a witty .sigline today
Re: [HELP] GCC 4.1 branch Ada status on powerpc-darwin?
On Jan 16, 2006, at 11:48 PM, Laurent GUERBY wrote: Hi, you've provided me with ACATS testing results on powerpc-darwin in the past, we currently don't know the state of Ada on the GCC 4.1 branch for powerpc-darwin as of 20060117: http://gcc.gnu.org/ml/gcc/2006-01/msg00578.html http://gcc.gnu.org/ml/gcc/2006-01/msg00581.html So if you have some time to try a bootstrap cycle with Ada on the 4.1 branch and report problems or results to our mailing lists we would be grateful. A 4.1 release is planned for the coming weeks. Thanks in advance for your help, Laurent Bootstrap fails for me on powerpc-darwin8 (Mac OS X 10.4.4) with a linking error in the rts. It doesn't seem to be picking up the correct libgcc_s.dylib (or libgcceh.a?). I have the latest Xcode 2.2 tools installed, but the bootstrap compiler is a FSF gcc 4.0.0 with Ada enabled. I used this as the configuration: ../gcc-4_1-branch/configure --prefix=/opt/test --enable-shared -- with-mpfr=/opt/local --with-gmp=/opt/local --enable-languages=c,ada ===make bootstrap=== touch ../stamp-gnatlib rm -f rts/libgnat.dylib rts/libgnarl.dylib cd rts; ../../xgcc -B../../ -dynamiclib -Wa,-force_cpusubtype_ALL - pipe \ -o libgnat-4.1.dylib \ a-caldel.o a-calend.o a-cdlili.o a-cgaaso.o a-cgarso.o a-cgcaso.o a- chacon.o a-chahan.o a-charac.o a-chlat1.o a-chlat9.o a-chtgke.o a- chtgop.o a-chzla1.o a-chzla9.o a-cidlli.o a-cihama.o a-cihase.o a- ciorma.o a-ciormu.o a-ciorse.o a-cohama.o a-cohase.o a-cohata.o a- coinve.o a-colien.o a-colire.o a-comlin.o a-contai.o a-convec.o a- coorma.o a-coormu.o a-coorse.o a-coprnu.o a-crbltr.o a-crbtgk.o a- crbtgo.o a-cwila1.o a-cwila9.o a-decima.o a-diocst.o a-direct.o a- direio.o a-dirval.o a-einuoc.o a-elchha.o a-except.o a-exctra.o a- filico.o a-finali.o a-flteio.o a-fwteio.o a-inteio.o a-ioexce.o a- iwteio.o a-lfteio.o a-lfwtio.o a-lfztio.o a-liteio.o a-liwtio.o a- liztio.o a-llftio.o a-llfwti.o a-llfzti.o a-llitio.o a-lliwti.o a- llizti.o a-ncelfu.o a-ngcefu.o a-ngcoty.o a-ngelfu.o a-nlcefu.o a- nlcoty.o a-nlelfu.o a-nllcef.o a-nllcty.o a-nllefu.o a-nscefu.o a- nscoty.o a-nselfu.o a-nucoty.o a-nudira.o a-nuelfu.o a-nuflra.o a- numaux.o a-numeri.o a-rbtgso.o a-secain.o a-sequio.o a-sfteio.o a- sfwtio.o a-sfztio.o a-shcain.o a-siocst.o a-siteio.o a-siwtio.o a- siztio.o a-slcain.o a-ssicst.o a-ssitio.o a-ssiwti.o a-ssizti.o a- stmaco.o a-storio.o a-strbou.o a-stream.o a-strfix.o a-strhas.o a- string.o a-strmap.o a-strsea.o a-strsup.o a-strunb.o a-ststio.o a- stunau.o a-stunha.o a-stwibo.o a-stwifi.o a-stwiha.o a-stwima.o a- stwise.o a-stwisu.o a-stwiun.o a-stzbou.o a-stzfix.o a-stzhas.o a- stzmap.o a-stzsea.o a-stzsup.o a-stzunb.o a-suteio.o a-swmwco.o a- swunau.o a-swuwha.o a-swuwti.o a-szmzco.o a-szunau.o a-szuzha.o a- szuzti.o a-tags.o a-tgdico.o a-teioed.o a-textio.o a-ticoau.o a- ticoio.o a-tideau.o a-tideio.o a-tienau.o a-tienio.o a-tifiio.o a- tiflau.o a-tiflio.o a-tigeau.o a-tiinau.o a-tiinio.o a-timoau.o a- timoio.o a-tiocst.o a-titest.o a-tiunio.o a-unccon.o a-uncdea.o a- wichun.o a-widcha.o a-witeio.o a-wtcoau.o a-wtcoio.o a-wtcstr.o a- wtdeau.o a-wtdeio.o a-wtedit.o a-wtenau.o a-wtenio.o a-wtfiio.o a- wtflau.o a-wtflio.o a-wtgeau.o a-wtinau.o a-wtinio.o a-wtmoau.o a- wtmoio.o a-wttest.o a-wwunio.o a-zchara.o a-zchuni.o a-ztcoau.o a- ztcoio.o a-ztcstr.o a-ztdeau.o a-ztdeio.o a-ztedit.o a-ztenau.o a- ztenio.o a-ztexio.o a-ztfiio.o a-ztflau.o a-ztflio.o a-ztgeau.o a- ztinau.o a-ztinio.o a-ztmoau.o a-ztmoio.o a-zttest.o a-zzunio.o ada.o calendar.o g-arrspl.o g-awk.o g-bubsor.o g-busora.o g-busorg.o g- calend.o g-casuti.o g-catiio.o g-cgi.o g-cgicoo.o g-cgideb.o g- comlin.o g-comver.o g-crc32.o g-ctrl_c.o g-curexc.o g-debuti.o g- debpoo.o g-diopit.o g-dirope.o g-dyntab.o g-dynhta.o g-except.o g- excact.o g-exctra.o g-expect.o g-flocon.o g-heasor.o g-hesora.o g- hesorg.o g-htable.o g-io.o g-io_aux.o g-locfil.o g-md5.o g-memdum.o g- moreex.o g-os_lib.o g-pehage.o g-regexp.o g-regpat.o g-sestin.o g- soccon.o g-socket.o g-socthi.o g-soliop.o g-souinf.o g-speche.o g- spipat.o g-spitbo.o g-sptabo.o g-sptain.o g-sptavs.o g-string.o g- strspl.o g-table.o g-tasloc.o g-traceb.o g-utf_32.o g-wistsp.o g- zstspl.o gnat.o i-c.o i-cexten.o i-cobol.o i-cpoint.o i-cpp.o i- cstrea.o i-cstrin.o i-fortra.o i-pacdec.o interfac.o ioexcept.o machcode.o s-addima.o s-addope.o s-arit64.o s-assert.o s-atacco.o s- auxdec.o s-bitops.o s-boarop.o s-carsi8.o s-carun8.o s-casi16.o s- casi32.o s-casi64.o s-casuti.o s-caun16.o s-caun32.o s-caun64.o s- chepoo.o s-crtl.o s-crc32.o s-direio.o s-errrep.o s-exctab.o s- exnint.o s-exnllf.o s-exnlli.o s-expint.o s-explli.o s-expllu.o s- expmod.o s-expuns.o s-fatflt.o s-fatgen.o s-fatlfl.o s-fatllf.o s- fatsfl.o s-ficobl.o s-fileio.o s-filofl.o s-fishfl.o s-finimp.o s- finroo.o s-fore.o s-fvadfl.o s-fvaffl.o s-fvagfl.o s-geveop.o s- htable.o s-imgbiu.o s-imgboo.o s-imgcha.o s-imgdec.o s-imgenu.o s- imgint
The testsuite is way broken right now
The testsuite is way broken and does not run all the tests: http://gcc.gnu.org/ml/gcc-testresults/2006-01/msg00878.html http://gcc.gnu.org/ml/gcc-testresults/2006-01/msg00876.html http://gcc.gnu.org/ml/gcc-testresults/2006-01/msg00886.html http://gcc.gnu.org/ml/gcc-testresults/2006-01/msg00898.html http://gcc.gnu.org/ml/gcc-testresults/2006-01/msg00900.html http://gcc.gnu.org/ml/gcc-testresults/2006-01/msg00907.html msg00898 says: ERROR: tcl error sourcing /cvs/gcc-svn/trunk/gcc/testsuite/gcc.dg/torture/dg-torture.exp. ERROR: unmatched open brace in list There might be more problems because the rest of them are just empty. Can someone figure out what is going on? I am running a bootstrap/test right now on powerpc-darwin to see if I can reproduce it. -- Pinski
Re: The testsuite is way broken right now
On Jan 17, 2006, at 8:45 PM, Andrew Pinski wrote:
The testsuite is way broken and does not run all the tests:
http://gcc.gnu.org/ml/gcc-testresults/2006-01/msg00878.html
http://gcc.gnu.org/ml/gcc-testresults/2006-01/msg00876.html
http://gcc.gnu.org/ml/gcc-testresults/2006-01/msg00886.html
http://gcc.gnu.org/ml/gcc-testresults/2006-01/msg00900.html
http://gcc.gnu.org/ml/gcc-testresults/2006-01/msg00907.html
The empty testsuite problem was fixed by:
2006-01-17 Shantonu Sen <[EMAIL PROTECTED]>
* Makefile.in (check-%, check-consistency): Use $${srcdir}
instead of $(srcdir) and ${srcdir}.
http://gcc.gnu.org/ml/gcc-testresults/2006-01/msg00898.html
msg00898 says:
ERROR: tcl error sourcing
/cvs/gcc-svn/trunk/gcc/testsuite/gcc.dg/torture/dg-torture.exp.
ERROR: unmatched open brace in list
This is caused by another missing close brace in a testcase like my
previous patch.
Committed as obvious.
Thanks,
Andrew Pinski
* gcc.dg/torture/fp-int-convert-float128.c: Fix dg-do line,
add a closing brace.
Index: testsuite/gcc.dg/torture/fp-int-convert-float128.c
===
--- testsuite/gcc.dg/torture/fp-int-convert-float128.c (revision 109856)
+++ testsuite/gcc.dg/torture/fp-int-convert-float128.c (working copy)
@@ -1,6 +1,6 @@
/* Test floating-point conversions. __float128 type. */
/* Origin: Joseph Myers <[EMAIL PROTECTED]> */
-/* { dg-do run { target { ia64-*-* || { { i?86-*-* x86_64-*-*} && lp64 } } } */
+/* { dg-do run { target { ia64-*-* || { { i?86-*-* x86_64-*-*} && lp64 } } } }
*/
/* { dg-xfail-if "" { i?86-*-* x86_64-*-* } { "*" } { "" } } */
/* { dg-options "" } */
Re: Microchip Pic-18F port on GNU/Gcc
On Jan 8, 2006, at 3:11 PM, [EMAIL PROTECTED] wrote: So can you tell me more about your experience with the Microchip 18F, if somebody is currently working on this device, Nope, don't think so. or if the memory model of the PIC18 is definitively a problem to gcc porting ? Weird chips make porting harder. :-)
Re: Static coverage analysis with 'gcov'.
On Jan 9, 2006, at 7:41 AM, [EMAIL PROTECTED] wrote: I actually want to do coverage analysis on bootloader code from YAMON (used mostly on MIPS board). Obviously, I cannot invoke 'gcov' on bootloader code and thus the conundrum. Don't see why not, just arrange to save it out to memory someplace, and then run the memory to disk later during boot. You just need to do up some code to save the data out to the memory buffer at the end of boot up.
Re: Microchip Pic-18F port on GNU/Gcc
> > or if the memory model of the PIC18 is definitively a problem to > > gcc porting ? > > Weird chips make porting harder. :-) Hey, if I can get the m32c series supported... But yeah, gcc *really* wants to see a standard RISC chip these days.
Re: Example of debugging GCC with toplevel bootstrap
On Jan 13, 2006, at 5:01 PM, Richard Kenner wrote: Steven Bosscher wrote: ... you can use --disable-bootstrap and do a regular make, or is there some reason why you can't do that? I thought the point was that that option is temporary and will go away. Over my dead body. We will always have a nice simple easy way to do development so that it is quick fast and easy.
Re: Example of debugging GCC with toplevel bootstrap
On Jan 17, 2006, at 10:30 PM, Mike Stump wrote: On Jan 13, 2006, at 5:01 PM, Richard Kenner wrote: Steven Bosscher wrote: ... you can use --disable-bootstrap and do a regular make, or is there some reason why you can't do that? I thought the point was that that option is temporary and will go away. Over my dead body. We will always have a nice simple easy way to do development so that it is quick fast and easy. "When they prey out of my cold dead hands..." :-)
Re: Command line options and pragmas
On Jan 9, 2006, at 10:46 AM, David Taylor wrote: For a variety of reasons, we would like to be able to specify individual compilation switches *within* individual files. Dale added this to our gcc compiler, see the apple/trunk branch for example, near APPLE LOCAL .* optimization pragmas lines. We do optimization setting from pragmas with it.
Re: Example of debugging GCC with toplevel bootstrap
Mike Stump wrote: On Jan 13, 2006, at 5:01 PM, Richard Kenner wrote: Steven Bosscher wrote: ... you can use --disable-bootstrap and do a regular make, or is there some reason why you can't do that? I thought the point was that that option is temporary and will go away. Over my dead body. We will always have a nice simple easy way to do development so that it is quick fast and easy. As I said multiple times, *of course* bootstrapping will *never* be mandatory. On the other hand, GCC-only bootstrapping (i.e. configuring with disabled bootstrap, and then typing "make bootstrap") will be deleted. Paolo
