Re: Recent VCG changes break gfortran's -std=f95 option

My first patch didn't even compile :( Here's a new one. Something is marking random_seed as noreturn. As far as I understand, symbols are marked as noreturn by use of TREE_THIS_VOLATILE, which is done on a few selected trees and is also done whenever a symbol has the noreturn attribute. T

Re: Recent VCG changes break gfortran's -std=f95 option

Something is marking random_seed as noreturn. As far as I understand, symbols are marked as noreturn by use of TREE_THIS_VOLATILE, which is done on a few selected trees and is also done whenever a symbol has the noreturn attribute. This noreturn attribute can be set to 1 by make_noreturn,

Re: Modifying ARM code generator for elimination of 8bit writes - need help

Rask, On Monday 05 June 2006 16:16, Rask Ingemann Lambertsen wrote: > On Mon, Jun 05, 2006 at 01:47:10PM +0200, Wolfgang Mües wrote: > Does GCC happen to accept "[%r, #0]" for swp? No. But no problem here to change that. > I think the comment in arm.h is wrong. The manual seems to agree with > t

Re: [MinGW] Set NATIVE_SYSTEM_HEADER_DIR relative to configured prefix

Ross Ridge wrote: >The GCC I get from my native MinGW build of the trunk is relocatable: Hmm... I should have sent that to gcc-patches, sorry. Ross Ridge

Re: [MinGW] Set NATIVE_SYSTEM_HEADER_DIR relative to configured prefix

Ranjit Mathew wrote: > Danny, I'm using the same configure flags that you have used for GCC >3.4.5 MinGW release (*except* for --prefix=/mingw, which is something >like --prefix=/j/mingw/mgw for me), but the GCC I get is not relocatable >at all, while I can put the MinGW GCC 3.4.5 release anywhere

Re: [wwwdocs] Complete revamp of our web site

On Jun 5, 2006, at 2:26 PM, DJ Delorie wrote: Feedback welcome! Right-side navigation bars are nonstandard. It should be moved to the left side. Don't accept the search engine excuse; that's easily fixable. Also, by fixing the search engine issue you punish Lynx users; the navigation men

Re: Where is the egg?

[Steven Bosscher] > But is it really necessary to remove the egg too? > Can we have it back? Pleaeaeaeaese? :-) [Gabriel Dos Reis] > yes, please let's have the egg back. If y'all need a differently sized egg, I can generate one. (I was the one who traced the old JPEG to make the clean PNG.) I've

Re: which cctool on Darwin?

Building cctools from source is like stabbing yourself in the kidney. You should use darwinbuild if you want to build the Apple-provided source only, or use odcctools if you want additional portability patches to build on multiple OSes and versions and have relocatable -- prefix support. I

Re: Recent VCG changes break gfortran's -std=f95 option

On Mon, Jun 05, 2006 at 10:33:40PM -0400, Andrew Pinski wrote: > > > > I have the simple program > > > > program a > > call random_seed() > > end program a > > Something is marking random_seed as noreturn. OK, so where do I start to look? AFAICT, this problem only occurs if -std=f95, a

Re: Recent VCG changes break gfortran's -std=f95 option

> > I have the simple program > > program a > call random_seed() > end program a Something is marking random_seed as noreturn. -- Pinski

Recent VCG changes break gfortran's -std=f95 option

I have the simple program program a call random_seed() end program a in the files a.f90 and b.f90. That is, a.f90 and b.f90 are identical. gfortran -o a -fdump-tree-all a.f90 gfortran -o b -fdump-tree-all -std=f95 b.f90 --- a.f90.003t.original Mon Jun 5 19:09:22 2006 +++ b.f90.003t.

Re: which cctool on Darwin?

On 05/06/2006, at 6:55 PM, Jack Howarth wrote: Geoff, Okay. I downloaded the cctools-590.42.1.tar.gz and attempted to build it using the same fink packaging script used for odcctools. However I get a build failure of... cc -O -g -I../../include -Wall -Wno-long-double -no-cpp-precomp -

Re: which cctool on Darwin?

Geoff, Okay. I downloaded the cctools-590.42.1.tar.gz and attempted to build it using the same fink packaging script used for odcctools. However I get a build failure of... cc -O -g -I../../include -Wall -Wno-long-double -no-cpp-precomp -fno-builtin-round -D_MACH_I386_THREAD_STATUS_FPSTATE_LEG

Re: which cctool on Darwin?

On 05/06/2006, at 6:09 PM, Jack Howarth wrote: Geoff, Could you update the cctools (particularly the source version) in infrastructure to the newer version? I see no reason to do this. You can get the last released version of cctools at

Re: which cctool on Darwin?

Geoff, Could you update the cctools (particularly the source version) in infrastructure to the newer version? Both Fink and OpenDarwin build odcctools packages to insure that a current cctools is available for their g95 and gcc packages regardless of what Xcode is installed. Currently fink is b

Re: GCC 4.2 Status Report (2006-06-04)

Joern RENNECKE wrote: > In http://gcc.gnu.org/ml/gcc/2006-06/msg00120.html, you wrote: > >> As fwprop is no longer on the table for 4.2, and as the vectorizer >> improvements seem to have stalled due to a combination of lack of review >> and Dorit's leave, I think it's time to declare 4.2 feature-

Re: which cctool on Darwin?

On 05/06/2006, at 2:58 PM, Jack Howarth wrote: Geoff, Would the ld64 in the cctools of Xcode 2.3 happen to resolve PR 27121? Jack 27121 was originally reported as a bug which can only be resolved by cctools, not ld64 which is not part of cctools. I see there was some additi

Re: which cctool on Darwin?

Geoff, Would the ld64 in the cctools of Xcode 2.3 happen to resolve PR 27121? Jack

Re: Where is the egg?

Steven Bosscher <[EMAIL PROTECTED]> writes: | But is it really necessary to remove the egg too? Can we have | it back? Pleaeaeaeaese? :-) yes, please let's have the egg back. -- Gaby

Re: [wwwdocs] Complete revamp of our web site

> "Gerald" == Gerald Pfeifer <[EMAIL PROTECTED]> writes: Gerald> The following patchset renovates our web presence, adopting Gerald> the current style from www.gnu.org and bringing the Java and Gerald> libstdc++ pages in sync so that we now have one common style. Looking better! I like it mu

Re: [wwwdocs] Complete revamp of our web site

> Feedback welcome! Right-side navigation bars are nonstandard. It should be moved to the left side. Don't accept the search engine excuse; that's easily fixable. Also, by fixing the search engine issue you punish Lynx users; the navigation menu is now near (but not at) the end of the text. S

Re: [wwwdocs] Complete revamp of our web site

* Gerald Pfeifer <[EMAIL PROTECTED]> [2006-06-05 22:51]: > GCC, the GNU Compiler Collection How about a dash here rather than a comma? Looks nicer imho: | GCC - the GNU Compiler Collection -- Martin Michlmayr [EMAIL PROTECTED]

Re: which cctool on Darwin?

On 05/06/2006, at 1:44 PM, Jack Howarth wrote: I noticed that Xcode 2.3 seems to have a cctools with a higher version that that in the infrastructure directory at the gcc ftp site. Should we be using the Xcode 2.3 version instead of that 20060413 copy for building gcc trunk? Yes. smime

[wwwdocs] Complete revamp of our web site

The following patchset renovates our web presence, adopting the current style from www.gnu.org and bringing the Java and libstdc++ pages in sync so that we now have one common style. Feedback welcome! (Steven, I've seen yours already and will respond. ;-) Compress the navigation bar vertically,

which cctool on Darwin?

I noticed that Xcode 2.3 seems to have a cctools with a higher version that that in the infrastructure directory at the gcc ftp site. Should we be using the Xcode 2.3 version instead of that 20060413 copy for building gcc trunk? Jack

Where is the egg?

Hi Gerald, Your updates to gcc.gnu.org are, ehm, not my taste, but I guess we have to follow www.gnu.org. But is it really necessary to remove the egg too? Can we have it back? Pleaeaeaeaese? :-) Gr. Steven

Re: GCC 4.2 Status Report (2006-06-04)

In http://gcc.gnu.org/ml/gcc/2006-06/msg00120.html, you wrote: As fwprop is no longer on the table for 4.2, and as the vectorizer improvements seem to have stalled due to a combination of lack of review and Dorit's leave, I think it's time to declare 4.2 feature-complete. I am still waiting fo

Re: Solaris 2.8 build failure for 4.1.1 (libtool/libjava)

Joe Buck wrote: It's GNU ld version 2.16.1. This is strange; I would have expected the linker to get just -rpath: -Wl should tell gcj to pass the following option to the linker. Known problem. See PR 21206. -- Jim Wilson, GNU Tools Support, http://www.specifix.com

Re: Objective C++ Bundling

Mike Stump wrote: On Jun 5, 2006, at 5:24 AM, Ranjit Mathew wrote: I found out recently that with just the gcc-core and gcc-g++ files, bootstrapping with --enable-languages=c,c++ fails since "gcc/objcp" was being processed without Objective C front-end and runtime files being there in the source

Re: Objective C++ Bundling

On Jun 5, 2006, at 5:24 AM, Ranjit Mathew wrote: I found out recently that with just the gcc-core and gcc-g++ files, bootstrapping with --enable-languages=c,c++ fails since "gcc/objcp" was being processed without Objective C front-end and runtime files being there in the source tree. I think th

Re: Why are we installing libtool files now?

> "Richard" == Richard Guenther <[EMAIL PROTECTED]> writes: >> On 6/4/06, Gerald Pfeifer <[EMAIL PROTECTED]> wrote: >> I noticed that with a full build (including all of GCJ and libgcj), >> we now install a bootload of libtool files into $PREFIX/share: Richard> PR27818 Thanks. I fixed this.

Re: Modifying ARM code generator for elimination of 8bit writes - need help

On Mon, Jun 05, 2006 at 01:47:10PM +0200, Wolfgang Mües wrote: > I don't know why the form "[%r, #0]" was coded before, because the > assembler understands "[%r]" very well for all instructions. The form > "[%r]" has a wider usage because it covers swp too. Does GCC happen to accept "[%r, #0]"

Objective C++ Bundling

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I found out recently that with just the gcc-core and gcc-g++ files, bootstrapping with --enable-languages=c,c++ fails since "gcc/objcp" was being processed without Objective C front-end and runtime files being there in the source tree. I think

Re: Modifying ARM code generator for elimination of 8bit writes - need help

> > Tightening the predicates isn't sufficient (and may not even be > > neccessary). You need to set the constraints so that the compiler > > knows *how* to fix invalid instructions. > > And if I have 4 different constraints in a single insn, and only one of > them is needing a temporary register,

Re: Modifying ARM code generator for elimination of 8bit writes - need help

On Mon, 2006-06-05 at 12:47, Wolfgang Mües wrote: > > /* Output the address of an operand. */ > > #define ARM_PRINT_OPERAND_ADDRESS(STREAM, X)\ > > { \ > > int is_minus = GET_CODE (X) == MINUS;

Re: Modifying ARM code generator for elimination of 8bit writes - need help

Hello, my first little success... in arm.h, I have changed > /* Output the address of an operand. */ > #define ARM_PRINT_OPERAND_ADDRESS(STREAM, X) \ > { \ > int is_minus = GET_CODE (X) == MINUS;

Re: Modifying ARM code generator for elimination of 8bit writes - need help

Richard, On Monday 05 June 2006 12:06, Richard Earnshaw wrote: > I'm confident right now that these will be too invasive to include in > mainline. As said before, this is OK for me. > The changes that tend to get incorporated into the compiler are to > work around bugs in the CPU, not bugs in s

Re: Modifying ARM code generator for elimination of 8bit writes - need help

Hello Dave ;-) On Monday 05 June 2006 02:12, Dave Murphy wrote: > I was just about to ask about this very thing since I'm quite sure > that there would be interest in adding this to devkitARM. You are following the process in dslinux, don't you? In fact, devkitARM is my current build environment

Re: A reload failure which I can't figure out

On Tue, May 30, 2006 at 08:23:34PM +0200, Rask Ingemann Lambertsen wrote: > Hi. > > I have problems figuring out why reload gives up on this: > > reload failure for reload 1 > ../../../cvssrc/gcc/gcc/libgcc2.c: In function '__moddi3': > ../../../cvssrc/gcc/gcc/libgcc2.c:1101: error: unable to fin

Re: Modifying ARM code generator for elimination of 8bit writes - need help

On Sun, 2006-06-04 at 22:01, Rask Ingemann Lambertsen wrote: > On Sun, Jun 04, 2006 at 12:24:53PM +0100, Paul Brook wrote: > > > For the record these hacks are unlikely to ever be acceptable in mainline > > gcc. > > They're relatively invasive changes who's only purpose is to support > > fundam

Re: Modifying ARM code generator for elimination of 8bit writes - need help

Paul, On Sunday 04 June 2006 17:57, Paul Brook wrote: > Because then you have several different patterns for the same > operation. The different variants of movsi should be part of the same > pattern so that the compiler can change its mind which variant it > wants to use. Together with the comme

apply for the relevant forms

Dear maintainer, Our Co. have a new 32b embedded processor, and we have ported the gcc backend for it(support c/c++), now we want add its backend code into gcc packages. i read the "Contributing to GCC " pages that we must sign some forms, can you kindly send the forms to me? Best Regards Liqi