Re: Patches for coldfire v4e

[EMAIL PROTECTED] wrote: > Attached are the patches for coldfire v4e. These > changes are originally contributed by Peter Barada. I > have migrated and tested these changes from gcc 3.04 > to gcc 3.4 and now to mainline. Thank you for submitting this patch. I've not yet had the time to perfor

Re: GCC 4.0 RC2

Ian Lance Taylor writes: > Richard Sandiford <[EMAIL PROTECTED]> writes: >> Huh. For the record: it can't. get_attr_length() returns 0 >> for ADDR_VECs regardless of JUMP_IN_TEXT_SECTION. I'll update >> the comment when applying the bug-fix patch to mainline. > > shorten_branches handles JUMP_T

Re: Patches for coldfire v4e

[EMAIL PROTECTED] wrote: > Hi, > Sorry, I missed ChangeLog patches. There seems to be a bogus hunk in this patch. The long lines need to be wrapped to 80 characters. Also, one line is indented with spaces instead of TABs. -- // Bernardo Innocenti - Develer S.r.l., R&D dept. \X/ http://www.d

Re: GCC 4.0 RC1 Available

> Exception in thread "main" java.lang.RuntimeException: test failed:5 > <> > FAIL: Array_3 -O3 execution - bytecode->native test This one is expected I think, though not XFAILed (it fails only at -O3). BTW, you keep getting "<>" everywhere - is addr2line from binutils not present somewhere i

Re: About the number of DOM's iterations.

On Tue, 2005-04-12 at 14:36 -0400, Kazu Hirata wrote: > Hi, > > Note that with -O1, we limit the number of iterations of DOM to 1 so > that we can get resonable compile time performance. I was wondering > what happens if we do the same with -O2 now that we have passes like > copy-prop, VRP, and i

Re: GCC 4.0 RC1 Available

Per Bothner wrote: Mark Wielaard wrote: Hi Per, On Tue, 2005-04-12 at 20:45 +0200, Mark Wielaard wrote: I am looking for a real solution. Does the following work for you? 2005-04-02 Mark Wielaard <[EMAIL PROTECTED]> * java/lang/natRuntime.cc (insertSystemProperties): Set java.cla

Re: RFC:Updated VEC API

Nathan Sidwell wrote: option1) Require the allocation mechanism to be mentioned in *all* vector API calls. So you'd have 'VEC_append (tree,gc,v,t)', but you'd also have 'VEC_length (tree,gc,v)', which is kind of annoying. I think that's more than annoying: it's dangerous. We'll get it wrong on

Re: GCC 4.0 RC1 Available

Mark Mitchell <[EMAIL PROTECTED]> writes: > If you are willing to help, please download the release candidate, > build it on appropriate platforms, and post testresults by using > contrib/test_summary. Please use the release candidate itself, *not* > the CVS 4.0 release branch, as part of the goa

Re: GCC 4.0 RC2

Richard Sandiford <[EMAIL PROTECTED]> writes: > Huh. For the record: it can't. get_attr_length() returns 0 > for ADDR_VECs regardless of JUMP_IN_TEXT_SECTION. I'll update > the comment when applying the bug-fix patch to mainline. shorten_branches handles JUMP_TABLES_IN_TEXT_SECTION correctly.

Re: GCC 4.0 RC1 Available

Per Bothner wrote: However, the Kawa testsuite fails, raising a ClassNotFoundException. I'm looking into it. Hm. This fails, with or without the patch: clas = Class.forName(cname); This works: clas = Class.forName(cname, true, getClass().getClassLoader()); This is with make all && make install

Re: GCC 4.0 RC1 Available

On Mon, 11 Apr 2005, Julian Brown wrote: > Quite a few of the 4.0 RC1 tests FAIL, though I'm not sure how many of > these are regressions, and how many are just new tests which fail. And a new test which fails may or may not be a regression - finding out whether it is requires either testing the

Re: RTL code

Rajkishore Barik wrote: Can someone tell me if there is a way to generate RTL code which does not include use and def of the same pseudo in the same insn? That depends on how you are generating RTL, but it should be pretty obvious that you can use gen_reg_rtx to generate a temp reg for use as a d

Re: gcc cache misses [was: Re: OT: How is memory latency important on AMD64 box while compiling large C/C++ sources]

On Apr 12, 2005, at 12:59 PM, Karel Gardas wrote: Either cachegrind is wrong, or gcc gets much better from that time? Or do I interpret cachegrind provided data in the wrong way? What do you think about it? Or you're comparing x86 to power, and noticing that the x86 has to execute way more da

Re: gcc cache misses [was: Re: OT: How is memory latency important on AMD64 box while compiling large C/C++ sources]

On Tue, 12 Apr 2005, Karel Gardas wrote: cachegrind can also be used to estimate the number (though, not sure how accurate it is, possibly not very). I use Shark to actually get the real number. Perhaps it's possible that cachegrind is wrong or cache misses differ from platform to platform, but I

Re: HEAD regression: All java tests are failing with an ICE when optimized

Andrew Haley wrote: Oh, right. I wonder why this happens only with Java? Because Java defaults to -fnon-call-exceptions. Add -fno-non-call-exceptions and it will work. It looks to me like the REG_EH_REGION check in postreload-gcse.c is bogus. We can have these notes here with -fnon-call-exce

Re: RFC:Updated VEC API

On Tue, 2005-04-12 at 19:42 +0100, Nathan Sidwell wrote: > Hi, > I promised to fix up the vector api, and there's a design decision > which needs to be made (incidentally, if we were in C++ land, we wouldn't > have to chose, as the right thing just happens). > Option1 is more easy to implement. Op

Re: GCC 4.0 RC1 Available

Per Bothner wrote: 2005-04-02 Mark Wielaard <[EMAIL PROTECTED]> * java/lang/natRuntime.cc (insertSystemProperties): Set java.class.path to CLASSPATH if not already set. Yes, Kawa builds with this patch. Thanks! However, the Kawa testsuite fails, raising a ClassNotFoundException.

Re: GCC 4.0 RC1 Available

Mark Wielaard wrote: Hi Per, On Tue, 2005-04-12 at 20:45 +0200, Mark Wielaard wrote: I am looking for a real solution. Does the following work for you? 2005-04-02 Mark Wielaard <[EMAIL PROTECTED]> * java/lang/natRuntime.cc (insertSystemProperties): Set java.class.path to CLASSPAT

Re: GCC 4.0 RC1 Available

On Tue, 2005-04-12 at 17:51 -0400, Bryce McKinlay wrote: > Mark Wielaard wrote: > > >On Tue, 2005-04-12 at 11:23 -0700, Per Bothner wrote: > > > > > >>Try compiling to native: > >> > >>$ gcj -o CL CL.java --main=CL > >>$ CLASSPATH=.:/:/usr:/random ./CL > >>gnu.gcj.runtime.SystemClassLoader{urls=

Basic block reordering algorithm

I stumbled across the following and was interested in others thoughts before I proceed any further. The algorithm described in the comments of bb-reorder.c (and the paper cited) talk about two parameters for controlling which blocks will be added to traces. "Branch threshhold" refers to the b

Re: GCC 4.0 RC1 Available

Hi Per, On Tue, 2005-04-12 at 20:45 +0200, Mark Wielaard wrote: > I am looking for a real solution. Does the following work for you? 2005-04-02 Mark Wielaard <[EMAIL PROTECTED]> * java/lang/natRuntime.cc (insertSystemProperties): Set java.class.path to CLASSPATH if not already

Re: GCC 4.0 RC1 Available

Mark Wielaard wrote: On Tue, 2005-04-12 at 11:23 -0700, Per Bothner wrote: Try compiling to native: $ gcj -o CL CL.java --main=CL $ CLASSPATH=.:/:/usr:/random ./CL gnu.gcj.runtime.SystemClassLoader{urls=[file:./], parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}} Aha. Than

Re: PowerPC sections ?

Charles J Gillan wrote: Is the GOT not sufficient to do this though ? I can’t see why it is necessary to define two new sections ? What goes into those sections ? The GOT is sufficient if you have a shared library loader that knows how to read ELF files and apply the relocations embedded within

Re: GCC 4.0 RC2

Richard Sandiford <[EMAIL PROTECTED]> writes: > PS. mips.c has the following > > > /* Return the length of instruction INSN. > >??? MIPS16 switch tables go in .text, but we don't define >JUMP_TABLES_IN_TEXT_SECTION

Re: GCC 4.0 RC2

Mark Mitchell wrote: Sadly, it's become clear there's going to have to be a second release candidate. In particular, there are some wrong-code bugs that are popping up on real packages on primary platforms. I think there is a case for considering the bug discussed in this thread release-critical

Re: GCC 4.0 RC2

Mark, I tried running some MIPS16 tests against RC1 and found a regression from 3.4. The problem is the following hack in mips.h: /* When generating mips16 code we want to put the jump table in the .text section. In

Re: ada build failure?

Ada does not build on mainline right now, though it dies much later than what you're seeing, see: http://gcc.gnu.org/ml/gcc/2005-04/msg00527.html Laurent On Tue, 2005-04-12 at 13:11 -0700, Richard Henderson wrote: > Is anyone else seeing this? I see the same with either 3.3 or 3.4 > as the buil

Re: New optimisation idea ?

On Apr 12, 2005, at 4:38 PM, Christophe Jaillet wrote: Reading point 3. of "Removal of duplicate effort at http://gcc.gnu.org/wiki/Speedup%20areas, I got the following idea : First of all, I don't think that it is actually done by gcc. If I'm wrong or if this idea doesn't worse the effort, just fo

New optimisation idea ?

Reading point 3. of "Removal of duplicate effort at http://gcc.gnu.org/wiki/Speedup%20areas, I got the following idea : First of all, I don't think that it is actually done by gcc. If I'm wrong or if this idea doesn't worse the effort, just forget about it. +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+= Man

Re: ada build failure?

Richard, No but I haven't been able to bootstrap with Ada since Friday I'm currently getting stage1/xgcc -Bstage1/ -B/usr/local/NETGCC/i686-pc-linux-gnu/bin/ -c -O2 -g -fomit-frame-pointer -gnatpg -gnata -I- -I. -Iada -I/src/gcc4.0/gcc/gcc/ada /src/gcc4.0/gcc/gcc/ada/ada.ads -o ada/ada.o raised

ada build failure?

Is anyone else seeing this? I see the same with either 3.3 or 3.4 as the build compiler. gcc -c -g -gnatpg -gnata -I- -I. -Iada -I../../src-gcc/gcc/ada \ ../../src-gcc/gcc/ada/exp_ch11.adb -o ada/exp_ch11.o exp_ch11.adb:926:34: expected type "Char_Code_Base" defined at types.ads:531 exp_ch

gcc cache misses [was: Re: OT: How is memory latency important on AMD64 box while compiling large C/C++ sources]

On Tue, 12 Apr 2005, Mike Stump wrote: > On Tuesday, April 12, 2005, at 06:38 AM, Karel Gardas wrote: > > Especially: ``Currently gcc takes a cache miss every 20 instructions, > > or > > some ungodly number, and that really saps performance.'' > > > > but I don't know if this is just an 1st April

RE: gcc for syntax check only (C): need to read source from stdin

Original Message >From: Dave Korn >Sent: 12 April 2005 18:45 > No write perms mate! However I'll check out HEAD and do a > before-and-after testsuite run overnight, and get back to you in the > morning with the results (UK time). I spoke too soon. [EMAIL PROTECTED] /gnu/testing/ob

Re: GCC 4.0 RC2

I know I asked late in the process but this fix for a m68k/coldfire failure just showed up: [Bug target/18421] ICE in reload_cse_simplify_operands, at postreload.c:391 Any chance at it getting considered? Thanks. --joel Mark Mitchell wrote: Sadly, it's become clear there's going to have to be a s

Re: GCC 4.0 RC2

On Tuesday 12 April 2005 19:59, Mark Mitchell wrote: > Therefore, I'm going to allow some of the queued patches into 4.0 at > this time. If your patch isn't on this list, but is here: > > http://gcc.gnu.org/wiki/Last-Minute%20Requests%20for%204.0.0 > > I'm still considering it. I'll let you know

Re: GCC 4.0 RC1 Available

On Tue, 2005-04-12 at 11:23 -0700, Per Bothner wrote: > Try compiling to native: > > $ gcj -o CL CL.java --main=CL > $ CLASSPATH=.:/:/usr:/random ./CL > gnu.gcj.runtime.SystemClassLoader{urls=[file:./], > parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}} Aha. Thanks. As a workar

RFC:Updated VEC API

Hi, I promised to fix up the vector api, and there's a design decision which needs to be made (incidentally, if we were in C++ land, we wouldn't have to chose, as the right thing just happens). The old API keyed the allocation strategy off the type name. This led to the lovely typedef tree

Re: Getting rid of -fno-unit-at-a-time [Was Re: RFC: Preserving order of functions and top-level asms via cgraph]

Daniel Jacobowitz wrote: BTW, I hope -fno-unit-at-a-time doesn't go away until at least gcc-4.1.1 or so... I still lean on that crutch. A user! Can you explain why? The x86-64 2.4 linux kernel uses it too, because some code relies on the ordering between asm and several functions. Other Linux por

About the number of DOM's iterations.

Hi, Note that with -O1, we limit the number of iterations of DOM to 1 so that we can get resonable compile time performance. I was wondering what happens if we do the same with -O2 now that we have passes like copy-prop, VRP, and improved FRE as well as good and old CCP. Numbers go first. All o

Re: Getting rid of -fno-unit-at-a-time [Was Re: RFC: Preserving order of functions and top-level asms via cgraph]

On Tue, Apr 12, 2005 at 06:34:29PM +0200, Andi Kleen wrote: > Daniel Jacobowitz <[EMAIL PROTECTED]> writes: > > > On Mon, Apr 11, 2005 at 10:02:06AM -0700, Daniel Kegel wrote: > >> BTW, I hope -fno-unit-at-a-time doesn't go away until at least gcc-4.1.1 > >> or so... I still lean on that crutch. >

Re: about the parse tree

On Monday, April 11, 2005, at 07:47 PM, zouq wrote: i want very much to learn more about the parse tree in gcc. tree.def is fairly dense and contains many of the details about trees. Have you read that? can some one show me some way to learn it a little easier, i have tried to debug it, but the

Re: GCC 4.0 RC1 Available

Mark Wielaard wrote: I tried to replicate this issue with some simple example, ... $ gcj -C CL.java $ CLASSPATH=.:/:/usr:/random gij CL gnu.gcj.runtime.SystemClassLoader{urls=[file:./,file:/,file:/usr/], parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}} Try compiling to native: $ g

Re: GCC 4.0 RC1 Available

Hi, On Mon, 2005-04-11 at 15:33 -0700, Per Bothner wrote: > Printing getClass().getClassLoader() yields: > gnu.gcj.runtime.SystemClassLoader{urls=[file:./], >parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}} > > Note the urls=[file:./]. Looks like it's ignoring the CLASSPATH

Re: gcc for syntax check only (C): need to read source from stdin

"Dave Korn" <[EMAIL PROTECTED]> writes: > No write perms mate! However I'll check out HEAD and do a > before-and-after testsuite run overnight, and get back to you in the morning > with the results (UK time). Will "--enable-languages=c,c++" be enough, or > do you want me to test against all de

GCC 4.0 RC2

Sadly, it's become clear there's going to have to be a second release candidate. In particular, there are some wrong-code bugs that are popping up on real packages on primary platforms. Jason Merill is looking into some of the C++ issues, but he's in Lillehammer this week for the ISO meeting.

Re: OT: How is memory latency important on AMD64 box while compiling large C/C++ sources

On Tuesday, April 12, 2005, at 06:38 AM, Karel Gardas wrote: Especially: ``Currently gcc takes a cache miss every 20 instructions, or some ungodly number, and that really saps performance.'' but I don't know if this is just an 1st April fool joke Nope, no joke. The exact number will vary from m

RE: gcc for syntax check only (C): need to read source from stdin

Original Message >From: Zack Weinberg >Sent: 12 April 2005 18:31 > Yes, I think this is the right thing. Please test against mainline > and apply it there if successful. I don't think it is important > enough to put into 4.0.0, but you should put it on the 4.0 branch > after the release,

Re: gcc for syntax check only (C): need to read source from stdin

"Dave Korn" <[EMAIL PROTECTED]> writes: > Then the error message *really* ought to say > > gcc: -E or -x required when input is from standard input > > since it is thoroughly obtuse and non-explanatory as it stands. The > attached is against 4.0 RC1, but I imagine it'll apply cleanly to HEAD wi

Re: gcc for syntax check only (C): need to read source from stdin

Zack, Now this works. Thanks a lot. And with -pipe, no temporary files at all (checked -v output). Could this be possibly placed in some FAQ? I tried to google for this first but did not get such a definitive (and simple) answer. On 4/12/05, Zack Weinberg <[EMAIL PROTECTED]> wrote: > In order

RE: gcc for syntax check only (C): need to read source from stdin

Original Message >From: Dave Korn >Sent: 12 April 2005 18:19 > > > 2005-12-04 Dave Korn <[EMAIL PROTECTED]> Oops. Please forgive mixed-endian date! It is of course the 12th of April and not the 4th of December today! 2005-04-12 Dave Korn <[EMAIL PROTECTED]> * gcc.c (

RE: gcc for syntax check only (C): need to read source from stdin

Original Message >From: Zack Weinberg >Sent: 12 April 2005 18:02 > Dimitry Golubovsky <[EMAIL PROTECTED]> writes: > >> Devang, >> >> Thanks for your relpy. >> >> This addresses only compiler's action problem (no output produced), >> but does not address the stdin problem. >> >> When I

Re: gcc for syntax check only (C): need to read source from stdin

Dimitry Golubovsky <[EMAIL PROTECTED]> writes: > Devang, > > Thanks for your relpy. > > This addresses only compiler's action problem (no output produced), > but does not address the stdin problem. > > When I try > > % cat a.c | gcc -fsyntax-only - > > I get > > gcc: -E required when input is fro

Re: Getting rid of -fno-unit-at-a-time [Was Re: RFC: Preserving order of functions and top-level asms via cgraph]

Andi Kleen wrote: Daniel Jacobowitz <[EMAIL PROTECTED]> writes: On Mon, Apr 11, 2005 at 10:02:06AM -0700, Daniel Kegel wrote: BTW, I hope -fno-unit-at-a-time doesn't go away until at least gcc-4.1.1 or so... I still lean on that crutch. A user! Can you explain why? The x86-64 2.4 linux kernel us

Re: RFC: Plan for cleaning up the "Addressing Modes" macros

Bernd Schmidt <[EMAIL PROTECTED]> writes: > Zack Weinberg wrote: >> The target macros described in the "Addressing Modes" section of the >> internals manual are rather badly in need of cleaning up. > > What's your status on this - would you mind very much if I made > changes to those macros now?

Re: Semi-Latent Bug in tree vectorizer

On Sat, 2005-04-09 at 23:23 -0400, Diego Novillo wrote: > On Fri, Apr 08, 2005 at 10:52:02AM -0600, Jeffrey A Law wrote: > > > When we vectorize the store we copy the virtual operands from the > > original statement to the new vectorized statement via this code: > > > > /* Copy the V_MAY_DEFS r

Re: gcc for syntax check only (C): need to read source from stdin

Devang, Thanks for your relpy. This addresses only compiler's action problem (no output produced), but does not address the stdin problem. When I try % cat a.c | gcc -fsyntax-only - I get gcc: -E required when input is from standard input again and when I use -E it only runs the preprocess

Re: Getting rid of -fno-unit-at-a-time [Was Re: RFC: Preserving order of functions and top-level asms via cgraph]

Daniel Jacobowitz <[EMAIL PROTECTED]> writes: > On Mon, Apr 11, 2005 at 10:02:06AM -0700, Daniel Kegel wrote: >> BTW, I hope -fno-unit-at-a-time doesn't go away until at least gcc-4.1.1 >> or so... I still lean on that crutch. > > A user! Can you explain why? The x86-64 2.4 linux kernel uses it

Re: gcc for syntax check only (C): need to read source from stdin

To read source from stdin use "-". preprocessor man page says, Either infile or outfile may be -, which as infile means to read from standard input and as outfile means to write to standard output. On Apr 12, 2005, at 7:10 AM, Dimitry Golubovsky wrote: Hi, A program I am working on

Re: gcc for syntax check only (C): need to read source from stdin

Try -fsyntax-only On Apr 12, 2005, at 7:10 AM, Dimitry Golubovsky wrote: Hi, A program I am working on generates some C code on the fly, and I would like to check its syntax right after generation. I might save this code fragment in a temporary file and gun gcc -c over it, watching for exit code (0

Pinapa: A SystemC front-end based on GCC

Pinapa is a SystemC front-end based on GCC that I've developed during my Ph. D. You can download and/or read more about Pinapa here: http://greensocs.sourceforge.net/pinapa/ Many thanks to the GCC team: I didn't have to write a complete C++ parser thanks to GCC ;-). -- Matthieu

Re: Mainline has been broken for more than 3 days now

The patch for this has already been submitted to gcc-patches: http://gcc.gnu.org/ml/gcc-patches/2005-04/msg01240.html -- Caroline Tice [EMAIL PROTECTED] On Apr 12, 2005, at 6:04 AM, Diego Novillo wrote: I have been using this crutch for the last couple of days to be able to get mainline to bootstra

Packaging error in 4.0RC1 docs? [was RE: Problem compiling GCC 4.0 RC1 on powerpc-ibm-aix5.2.0.0 ]

Original Message >From: Kate Minola >Sent: 12 April 2005 16:15 > When I look in gcc-4.0.0-20050410/INSTALL at specific.html Oh, BTW, it seems the internal links in that page are b0rked in the usual sort of way, owing to the mangling of 'special' characters. A link like: *-ibm-aix* do

RE: GCC 3.4.3

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

Re: Problem compiling GCC 4.0 RC1 on powerpc-ibm-aix5.2.0.0

> Kate Minola writes: Kate> Err ... what target-specific installation notes for AIX? Kate> Where are you looking? *-ibm-aix* David

Re: Problem compiling GCC 4.0 RC1 on powerpc-ibm-aix5.2.0.0

David, > > Kate Minola writes: > > Kate> Any thoughts on what is different between our two machines? > Kate> Any suggestions for things to compare? > > Do you have all of the updates listed in the Target-specific > installation notes for AIX installed? Err ... what target-specific ins

RE: GCC 3.4.3

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

Re: GCC 4.0 RC1 Available

> On 11/04/2005, at 11:23 PM, Ranjit Mathew wrote: > > > Geoffrey Keating wrote: > > [...] > >> which I see you've already committed a patch for, and a large number > >> of Java failures. > >> > >> You can see full test results at > > [...] > >> > >>

RE: GCC 3.4.3

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

proposal: explicit context pointers in addition to trampolines in C frontend

Hi, I've been thinking about trampolines and nested functions in C the other day. I really like using trampolines for callback functions, such as in http://svn.clifford.at/spl/trunk/spl_modules/mod_xml.c see: static struct spl_node *handler_xml2tree(struct spl_task *task, void *data)

gcc for syntax check only (C): need to read source from stdin

Hi, A program I am working on generates some C code on the fly, and I would like to check its syntax right after generation. I might save this code fragment in a temporary file and gun gcc -c over it, watching for exit code (0: syntax OK, 1: incorrect). This is fine with the one exception that I h

RE: GCC 3.4.3

On Tue, 12 Apr 2005, Dave Korn wrote: 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 direc

Re: Problem compiling GCC 4.0 RC1 on powerpc-ibm-aix5.2.0.0

> Kate Minola writes: Kate> Any thoughts on what is different between our two machines? Kate> Any suggestions for things to compare? Do you have all of the updates listed in the Target-specific installation notes for AIX installed? David

Re: GCC 4.0 RC1 Available

On 11/04/2005, at 11:23 PM, Ranjit Mathew wrote: Geoffrey Keating wrote: [...] which I see you've already committed a patch for, and a large number of Java failures. You can see full test results at [...] for 4.0.0-20050410. It might be

Re: GCC 4.0 RC1 Available

On 12/04/2005, at 6:47 AM, Andrew Haley wrote: Geoff Keating writes: On 12/04/2005, at 6:31 AM, Andrew Haley wrote: Eric Botcazou writes: which I see you've already committed a patch for, and a large number of Java failures. for 4.0.0-

Re: Problem compiling GCC 4.0 RC1 on powerpc-ibm-aix5.2.0.0

David, > This probably says more about GCC 3.4.2 on AIX than about > GCC 4.0 RC1. See the messages to the gcc-testresults > mailinglist about successful AIX 5.2 bootstrap of GCC 4. Thanks. I should have looked at gcc-testresults. But even using xlc % xlc -qversion @(#) IBM XL C/C++ Enterpris

Re: GCC 4.0 RC1 Available

Geoff Keating writes: > > On 12/04/2005, at 6:31 AM, Andrew Haley wrote: > > > Eric Botcazou writes: > >>> which I see you've already committed a patch for, and a large number > >>> of Java failures. > >>> > >>> > >>> > >>> f

Re: GCC 4.0 RC1 Available

On 12/04/2005, at 6:31 AM, Andrew Haley wrote: Eric Botcazou writes: which I see you've already committed a patch for, and a large number of Java failures. for 4.0.0-20050410. Same failure as on Solaris. Andrew, do you have a Darwin mach

Re: OT: How is memory latency important on AMD64 box while compiling large C/C++ sources

On Tue, 12 Apr 2005, Karel Gardas wrote: > using cache and how much cache it needs (I'm cosidering 512KB cache CPU > here either Winchester or Venice core) and that's the reason why I ask > here, since I've not been able so far to search by google for sufficient > answer for this question. Also t

Re: GCC 4.0 RC1 Available

Eric Botcazou writes: > > which I see you've already committed a patch for, and a large number > > of Java failures. > > > > > > > > for 4.0.0-20050410. > > Same failure as on Solaris. > > Andrew, do you have a Darwin machine

RE: GCC 3.4.3

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

Mainline has been broken for more than 3 days now

I have been using this crutch for the last couple of days to be able to get mainline to bootstrap with java enabled. Index: varasm.c === RCS file: /cvs/gcc/gcc/gcc/varasm.c,v retrieving revision 1.495 diff -u -3 -p -r1.495 varasm.c --

Re: GCC 3.4.3

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

internal compiler error at dwarf2out.c:8362

ze unit size align 8 symtab 0 alias set -1 precision 16 min max >> The GCC core is gcc version 4.1.0 20050412 (experimental). The bug only happens, if the base type of the second typedef is an array. As I have not found the use of a port specific type attribute in GCC, I don&

Re: 3.4.3 on Solaris9, boehm-gc probs.

On Thu, 7 Apr 2005, Hugh Sasse Staff Elec Eng wrote: On Thu, 7 Apr 2005, Eric Botcazou wrote: But to get the definitions we are after it should be looking in sys, No, is not directly included, only . Oh, I see. And I think I now understand what the --with-local-prefix does, so I'll let you know

Re: Mainline build failure on i686-pc-linux-gnu

On Tue, Apr 12, 2005 at 07:30:56AM +0200, Gabriel Dos Reis wrote: > This might be due to the bootstrapping compiler -- I was using a > compiler built from yesterday tree to bootstrap > Oh, PR 20933. Yes, the fix you see there should allow you to use 4.1 as a stage0 compiler again. We were misco

Re: GCC 3.4.3

On Fri, 8 Apr 2005, 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 install.sh in and that made the top leve

Re: Patches for coldfire v4e

[EMAIL PROTECTED] wrote: Hi, Attached are the patches for coldfire v4e. These changes are originally contributed by Peter Barada. I have migrated and tested these changes from gcc 3.04 to gcc 3.4 and now to mainline. Since coldfire v4e has MMU we need to support m68k-linux target for coldfire

Re: GCC 4.0 RC1 Available

Laurent GUERBY wrote: FYI, on SuSE 9.2, on x86 and x86_64 starting with the system Ada compiler (3.3.3 based) I get no such issue in configure: /bin/bash triggers the message, /bin/sh doesn't. Debian/bash 2.05b; SuSE 9.2/bash 3.00.0(1), if true; then break; fi I had run % bash ../src/gcc-4.0.0-200

Re: GCC 4.0 RC1 Available

Mark Mitchell wrote: Marcus Meissner wrote: Btw, We still see some critical 4.0 problems, ordered by my view of importance: PR/20126 triggers a miscompilation of python (i386 and x86_64 at least). PR/20917 triggers a miscompilation of glibc (on s390). PR/20739 triggers a --enable-checking problem

Re: Patches for coldfire v4e

Hi, Sorry, I missed ChangeLog patches. Regards, C Jaiprakash --- [EMAIL PROTECTED] wrote: > Hi, > Attached are the patches for coldfire v4e. These > changes are originally contributed by Peter Barada. > I > have migrated and tested these changes from gcc 3.04 > to gcc 3.4 and now to mainline.

Re: GCC 4.0 RC1 Available

FYI, on SuSE 9.2, on x86 and x86_64 starting with the system Ada compiler (3.3.3 based) I get no such issue in configure: checking whether we are using GNU C... yes checking whether gcc accepts -g... yes checking for gnatbind... gnatbind checking whether compiler driver understands Ada... yes che

Re: GCC 4.0 RC1 Available

c,ada show no unexpected failure on x86 and x86_64 (SuSE 9.2), great! A minor thing: I configured with c,ada only (no C++) on x86 and x86_64-linux and got http://gcc.gnu.org/ml/gcc-testresults/2005-04/msg00791.html http://gcc.gnu.org/ml/gcc-testresults/2005-04/msg00790.html [...]

OT: How is memory latency important on AMD64 box while compiling large C/C++ sources

Hello, first of all, I'm sorry for off-topic, the question from subject might look silly to you, since natural answer might be "it is very important", but in the light of deciding what and how much memory will I need in AMD64 box, I've got into deciding troubles caused by the fact that I can not

Re: Bootstrap failure on i686-pc-linux-gnu since 2005-04-09 20:41UTC

> The patch has just been submitted to gcc-patches for > approval (the tests are nearly done and appear to > be passing so far). I'm travelling today, so I won't be able to test until tomorrow. Thanks, Dave -- J. David Anglin [EMAIL PROTECTED] National Research C

Re: GCC 4.0 RC1 Available

Andrew Haley <[EMAIL PROTECTED]> wrote: > There was. We are now, for the first time ever, in a position where > we can run a large number of big Java applications using entirely free > software. This is a really great news! So great that I wonder why changes.html does not mention it (and news.

Re: Mainline build failure on i686-pc-linux-gnu

Andrew Pinski <[EMAIL PROTECTED]> writes: | And what version of the compiler were you starting with? | If it was 4.1.0 between the following patches: | 2005-04-08 Diego Novillo <[EMAIL PROTECTED]> | | Merge from tree-cleanup-branch: VRP, store CCP, store | copy-prop, incre

Re: RFC: Plan for cleaning up the "Addressing Modes" macros

Zack Weinberg wrote: The target macros described in the "Addressing Modes" section of the internals manual are rather badly in need of cleaning up. What's your status on this - would you mind very much if I made changes to those macros now? Bernd

Re: Getting rid of -fno-unit-at-a-time

On Apr 12, 2005, at 3:14 AM, Thorsten Glaser wrote: Daniel Jacobowitz dixit: On Mon, Apr 11, 2005 at 10:02:06AM -0700, Daniel Kegel wrote: BTW, I hope -fno-unit-at-a-time doesn't go away until at least gcc-4.1.1 or so... I still lean on that crutch. A user! Can you explain why? If you're "just" l

Re: Mainline build failure on i686-pc-linux-gnu

On Apr 12, 2005, at 12:53 AM, Gabriel Dos Reis wrote: Diego Novillo <[EMAIL PROTECTED]> writes: | On Mon, Apr 11, 2005 at 10:59:46PM -0500, Gabriel Dos Reis wrote: | | >-c /home/gdr/redhat/egcs/gcc/crtstuff.c -DCRT_BEGIN \ | > -o crtbegin.o | > make[1]: *** [crtbegin.o] Aborted | > make[1]: L

Re: Getting rid of -fno-unit-at-a-time

Daniel Jacobowitz dixit: >On Mon, Apr 11, 2005 at 10:02:06AM -0700, Daniel Kegel wrote: >> BTW, I hope -fno-unit-at-a-time doesn't go away until at least gcc-4.1.1 >> or so... I still lean on that crutch. > >A user! Can you explain why? If you're "just" looking for users: I need -fno-unit-at-a-

  1   2   >