Re: GCC 4.2.0 Status Report (2007-04-24)

On Tue, 24 Apr 2007, Mark Mitchell wrote: > 3. PR 30567: Wrong code with -O3 due to aliasing problems > > Richard G. has analyzed this and proposed a patch. Richard, is this > ready to go? If not, do you need help? I guess I can only produce a workaround, as I'm not too deeply into the aliasin

Re: paired register loads and stores

On Fri, Sep 29, 2006 at 05:27:10AM +, Erich Plondke wrote: > rs6000 and Sparc ports seem to use a peephole2 to get the ldd or lfq > instructions (respectively), but it looks like there's no reason for > the register allocater to allocate registers together. The peephole2 > just picks up loads

Re: paired register loads and stores

On Fri, Sep 29, 2006 at 09:52:58AM -0400, David Edelsohn wrote: > > The GCC register allocator allocates objects that span multiple > registers in adjacent registers. For instance, a 64-bit doubleword > integer (long long int) will be allocated in two adjacent hardware > registers when GCC

gcc/boehm-gc/misc.c:680: undefined reference to `_GC_get_thread_stack_base'

on cygwin, with current gcc trunk, revision Tue Apr 24 20:47:06 UTC 2007 (revision 124119M) (with Dave Korn's suggested patch to libjava), I get a failure liike this: ranlib .libs/libgcj-tools.a creating libgcj-tools.la (cd .libs && rm -f libgcj-tools.la && ln -s ../libgcj-tools.la libgcj-tools.

DR#314 update

Recall that C99 DR#314 deals with cross-translation unit type compatibility issues raised on this list with optimizing multiple translation units together. N1226 further di

Re: gcc/boehm-gc/misc.c:680: undefined reference to `_GC_get_thread_stack_base'

Christian Joensson wrote: > on cygwin, with current gcc trunk, revision Tue Apr 24 20:47:06 UTC > 2007 (revision 124119M) (with Dave Korn's suggested patch to > libjava), I get a failure liike this: > > ranlib .libs/libgcj-tools.a > creating libgcj-tools.la > (cd .libs && rm -f libgcj-tools.la &

RE: gcc/boehm-gc/misc.c:680: undefined reference to `_GC_get_thread_stack_base'

On 25 April 2007 11:39, Brian Dessent wrote: >> undefined reference to `_GC_get_thread_stack_base' >> collect2: ld returned 1 exit status >> make[3]: *** [jv-convert.exe] Error 1 >> make[3]: Leaving directory >> `/usr/local/src/trunk/objdir/i686-pc-cygwin/libjava' make[2]: *** >> [all-recursive]

Re: GCC 4.2.0 Status Report (2007-04-24)

Richard Guenther wrote on 04/25/07 03:54: > I guess I can only produce a workaround, as I'm not too deeply into > the aliasing stuff. So I'd prefer if Danny or Diego could have a look > (Danny apperantly doesn't have time to do so, my bets for Diego are > similar), but I'll give the workaround I

general_operand() not accepting CONCAT?

I just got /home/rask/cvssrc/gcc/gcc/testsuite/gcc.c-torture/compile/complex-3.c:17: error: unrecognizable insn: (insn 69 67 70 5 (set (mem:SC (pre_dec:HI (reg/f:HI 12 sp)) [0 S8 A8]) (concat:SC (reg:SF 36) (reg:SF 37))) -1 (nil) (nil)) which I thought I'd covered with (d

Re: GIMPLE tuples document uploaded to wiki

I have uploaded a new version of the tuples document, with the latest discussions. http://gcc.gnu.org/wiki/tuples Aldy

Re: general_operand() not accepting CONCAT?

Rask Ingemann Lambertsen <[EMAIL PROTECTED]> writes: > I just got > > /home/rask/cvssrc/gcc/gcc/testsuite/gcc.c-torture/compile/complex-3.c:17: > error: unrecognizable insn: > (insn 69 67 70 5 (set (mem:SC (pre_dec:HI (reg/f:HI 12 sp)) [0 S8 A8]) > (concat:SC (reg:SF 36) > (re

Re: GIMPLE tuples document uploaded to wiki

In 3.1, you write: The statistics gathered over the programs mentioned in the previous section show that about 43% of all statements contain 0 or more register operands I'd assume 100% contain 0 or more register operands. Did you mean 43% contain 1 or more? -Geert

Re: GIMPLE tuples document uploaded to wiki

Geert Bosch wrote on 04/25/07 11:49: > I'd assume 100% contain 0 or more register operands. > Did you mean 43% contain 1 or more? Well, no. I meant 0 or more, but it's badly worded. It means that 43% of the statements either have no operands or they contain only register operands. I'll rephras

Re: general_operand() not accepting CONCAT?

On Wed, Apr 25, 2007 at 01:51:34PM +0200, Rask Ingemann Lambertsen wrote: > (define_mode_macro GT16 [SI DI TI SF DF XF SC DC XC SD DD TD CHI CSI CDI > CTI]) > > (define_insn_and_split "*push1" You almost certainly do not want to handle complex yourself, and instead rely on the fallback code in ex

Q: Accessing signgam from the middle-end for builtin lgamma

I'd like to work on using MPFR to handle builtin lgamma. The lgamma function requires setting the global int variable "signgam" in addition to calculating the return value of lgamma. I think I see how to do grab a handle on signgam like so: sg = maybe_get_identifier("signgam"); if (sg) { sg =

Re: GIMPLE tuples document uploaded to wiki

It still has the addresses_taken bitmap, remove it :) Also, I assume for a call with no return, it will be a GS_CALL with lhs == NULL? On 4/25/07, Aldy Hernandez <[EMAIL PROTECTED]> wrote: I have uploaded a new version of the tuples document, with the latest discussions. http://gcc.gnu.org/wi

Re: GIMPLE tuples document uploaded to wiki

Daniel Berlin wrote on 04/25/07 14:40: > It still has the addresses_taken bitmap, remove it :) Oh, right. Is it gone already? > Also, I assume for a call with no return, it will be a GS_CALL with lhs == > NULL? Yes. I clarified it. Thanks.

Problem with patch for PR tree-optimization/29789

Richard, Has anyone reported any problems with your tree-ssa-loop-im.c patch that fixes PR tree-optimization/29789? I have been looking at a failure with the SPECfp2000 173.applu test. I found that if I compile it with version r124041 of the GCC gfortran compiler it works but if I compile it wit

Re: Problem with patch for PR tree-optimization/29789

On Wed, Apr 25, 2007 at 01:55:14PM -0700, Steve Ellcey wrote: > Richard, > > Has anyone reported any problems with your tree-ssa-loop-im.c patch that > fixes PR tree-optimization/29789? I have been looking at a failure with > the SPECfp2000 173.applu test. I found that if I compile it with > ver

Re: GCC -On optimization passes: flag and doc issues

As Ian Lance Taylor wrote: > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31528 > The relevant code is in opts.c: > if (optimize_size) > { > /* Inlining of very small functions usually reduces total size. */ > set_param_value ("max-inline-insns-single", 5); > set_param_

Re: GCC -On optimization passes: flag and doc issues

Joerg Wunsch <[EMAIL PROTECTED]> writes: > What's that test suite that has been mentioned here, and how to run > it? http://www.inf.u-szeged.hu/csibe/ Ian

Re: GCC 4.2.0 Status Report (2007-04-24)

Hello, > 4. PR 31360: Missed optimization > > I don't generally mark missed optimization bugs as P1, but not hoisting > loads of zero out of a 4-instruction loop is bad. Zdenek has fixed this > on mainline. Andrew says that patch has a bug. So, what's the story here? I found the problem, I wi

Re: GCC 4.2.0 Status Report (2007-04-24)

Zdenek Dvorak wrote: > Hello, > >> 4. PR 31360: Missed optimization >> >> I don't generally mark missed optimization bugs as P1, but not hoisting >> loads of zero out of a 4-instruction loop is bad. Zdenek has fixed this >> on mainline. Andrew says that patch has a bug. So, what's the story her

Successfull Build of gcc on Cygwin WinXp SP2

Successfully built latest gcc on Win XP SP2 with cvs built cygwin. $ ./config.guess i686-pc-cygwin $ cygcheck -V cygcheck version 1.94 System Checker for Cygwin Copyright 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006 Red Hat, Inc. Compiled on Apr 17 2007 (It was actually compiled on 2

Re: paired register loads and stores

On 4/25/07, Rask Ingemann Lambertsen <[EMAIL PROTECTED]> wrote: Btw, this is no longer true unless you pass -fno-split-wide-types. No, it is still true in most cases as some targets still have not split their own patterns for this feature. In fact in some cases you still want it not to be sp

RE: Problem with patch for PR tree-optimization/29789

> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of > H. J. Lu > Sent: Wednesday, April 25, 2007 2:02 PM > To: Steve Ellcey > Cc: [EMAIL PROTECTED]; gcc@gcc.gnu.org > Subject: Re: Problem with patch for PR tree-optimization/29789 > > > On Wed, Apr 25, 2007 a

Re: bootstrap broken on powerpc: implicit declaration of function 'pthread_getaffinity_np'

On 4/23/07, Martin Michlmayr <[EMAIL PROTECTED]> wrote: Since the change listed below, bootstrap on powerpc is broken when you configure for both powerpc-linux and powerpc64-linux: 2007-04-04 Jakub Jelinek <[EMAIL PROTECTED]> * libgomp.h (gomp_cpu_affinity, gomp_cpu_affinity_len): New

Re: Problem with patch for PR tree-optimization/29789

On Wed, Apr 25, 2007 at 06:08:47PM -0700, Fu, Chao-Ying wrote: > > -Original Message- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of > > H. J. Lu > > Sent: Wednesday, April 25, 2007 2:02 PM > > To: Steve Ellcey > > Cc: [EMAIL PROTECTED]; gcc@gcc.gnu.org > > Subject: Re: Pro