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

[Richard Guenther]

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 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 thought of a try.  (No, the
patch in the audit trail doesn't fix anything...)

Richard.

-- 
Richard Guenther <[EMAIL PROTECTED]>
Novell / SUSE Labs
SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 - GF: Markus Rex

Re: paired register loads and stores

[Rask Ingemann Lambertsen]

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 to adjacent memory locations if the allocater
> happens to choose adjacent registers (is that correct?) or the
> variables are specified as living in hard registers with the help
> of an asm.
> 
> Several other architectures have paired loads: some ARM targets have ldrd
> which can be cheaper than a ldm, and ia64 has a pair load.
> 
> It seems like GCC does a good job of knowing how to modify register-
> sized subregs of two- or four-register larger modes.  So if I could
> tell GCC to turn:
> 
>[(set (reg:SI X) (mem:SI (addr)))
> (set (reg:SI Y) (mem:SI (addr+4)))]
> 
> (where addr is aligned to DI) into something like:
>[(set (reg:DI T) (mem:DI (addr)))
> (set (reg:SI X) (subreg:SI (reg:DI T) 0))
> (set (reg:SI Y) (subreg:SI (reg:DI T) 4))]
> 
> and I could do so early enough, GCC would know to access the subregs
> directly in instruction(s) using the loaded values, and I would end up 
> loading
> the register pair and using the individual elements.  But it has to
> be done early on; after register allocation even if I could get a
> DI temporary I'd probably have the two SI moves and that's probably
> not a win.

   You may have success using the combine pass to do this. The difficulty is
that combine only tries to combine instructions when the LOG_LINKS field is
set up. I think this only happens for plain SET insns when subregs are
involved, e.g.

(set (subreg:SI (reg:DI T) 0) (mem:SI addr))
(set (subreg:SI (reg:DI T) 4) (mem:SI addr+4))

   For example, I don't know how to make this work with adjecent structure
fields. You could try to extend the optimization that GCC already does for
loading adjecent structure fields smaller than a word; the one enabled by
SLOW_BYTE_ACCESS.

-- 
Rask Ingemann Lambertsen

Re: paired register loads and stores

[Rask Ingemann Lambertsen]

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 is targeted at a processor with 32-bit registers.

   Btw, this is no longer true unless you pass -fno-split-wide-types.

-- 
Rask Ingemann Lambertsen

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

[Christian Joensson]

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.la)
/bin/sh ./libtool --tag=GCJ --mode=link
/usr/local/src/trunk/objdir/gcc/gcj
-B/usr/local/src/trunk/objdir/i686-pc-cygwin/libjava/
-B/usr/local/src/trunk/objdir/gcc/
-L/usr/local/src/trunk/objdir/i686-pc-cygwin/libjava -ffloat-store
-fomit-frame-pointer -g -O2  -o jv-convert.exe
--main=gnu.gcj.convert.Convert -rpath
/usr/local/lib/gcc/i686-pc-cygwin/4.3.0 -shared-libgcc
-L/usr/local/src/trunk/objdir/i686-pc-cygwin/libjava/.libs libgcj.la
/usr/local/src/trunk/objdir/gcc/gcj
-B/usr/local/src/trunk/objdir/i686-pc-cygwin/libjava/
-B/usr/local/src/trunk/objdir/gcc/ -ffloat-store -fomit-frame-pointer
-g -O2 -o jv-convert.exe --main=gnu.gcj.convert.Convert -shared-libgcc
-L/usr/local/src/trunk/objdir/i686-pc-cygwin/libjava
-L/usr/local/src/trunk/objdir/i686-pc-cygwin/libjava/.libs
./.libs/libgcj.a
-L/usr/local/src/trunk/objdir/i686-pc-cygwin/libstdc++-v3/src
-L/usr/local/src/trunk/objdir/i686-pc-cygwin/libstdc++-v3/src/.libs
-ldl -lz -L/usr/local/src/trunk/objdir/./gcc -lgcc -lcygwin -luser32
-lkernel32 -ladvapi32 -lshell32 -lgcc
./.libs/libgcj.a(lt102-misc.o): In function `GC_init_inner':
/usr/local/src/trunk/objdir/i686-pc-cygwin/boehm-gc/../../../gcc/boehm-gc/misc.c:680:
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] Error 1
make[2]: Leaving directory `/usr/local/src/trunk/objdir/i686-pc-cygwin/libjava'
make[1]: *** [all-target-libjava] Error 2
make[1]: Leaving directory `/usr/local/src/trunk/objdir'
make: *** [bootstrap] Error 2

Any ideas of what can be done with this problem?

--
Cheers,

/ChJ

DR#314 update

[Joseph S. Myers]

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 
discussed the issue.

The conclusion at the London meeting was to leave the DR open and consider 
the matter for the C1x revision (to be discussed tomorrow) rather than 
resolving through the DR process.  There was sympathy for the notion that 
the standard *shouldn't* allow examples such as that of my question 3, 
even if there isn't currently wording with that effect.

(Reportedly papers N522 and N561 from 1995-6 - when the tag compatibility 
rules were worked out - may be relevant but aren't online; something may 
be done about scanning the older papers 1986-96 that were circulated only 
in paper form.)

I propose to send the following wording to Benito for the post-London 
mailing as a proposal for C1x - any comments before I send it?




My aim with DR314 is that it should be possible for an implementation
to combine the translation units of a program into a single internal
representation and optimize that, unifying structure and union types
across translation units where required to be compatible in the
process.

Normally, it is possible to create a single translation unit
equivalent to multiple translation units, after renaming static
variables and functions and structure and union tags.  DR314 question
3 is an example where such renaming is not possible.  My proposal is
to add a requirement that it is possible.

Proposed amendment for C1x:

6.2.7 after paragraph 2 insert: There shall exist a partition of
all the structure and union types in the program into disjoint
classes such that (a) if two types are in the same class, then
they are compatible and (b) whenever two structure or union types
are required to be compatible, including by (a), they are in the
same class.  If there does not exist such a partition, the
behavior is undefined.

This is intended to be consistent with all the analysis in N1226.

-- 
Joseph S. Myers
[EMAIL PROTECTED]

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

[Brian Dessent]

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 && ln -s ../libgcj-tools.la 
> libgcj-tools.la)
> /bin/sh ./libtool --tag=GCJ --mode=link
> /usr/local/src/trunk/objdir/gcc/gcj
> -B/usr/local/src/trunk/objdir/i686-pc-cygwin/libjava/
> -B/usr/local/src/trunk/objdir/gcc/
> -L/usr/local/src/trunk/objdir/i686-pc-cygwin/libjava -ffloat-store
> -fomit-frame-pointer -g -O2  -o jv-convert.exe
> --main=gnu.gcj.convert.Convert -rpath
> /usr/local/lib/gcc/i686-pc-cygwin/4.3.0 -shared-libgcc
> -L/usr/local/src/trunk/objdir/i686-pc-cygwin/libjava/.libs libgcj.la
> /usr/local/src/trunk/objdir/gcc/gcj
> -B/usr/local/src/trunk/objdir/i686-pc-cygwin/libjava/
> -B/usr/local/src/trunk/objdir/gcc/ -ffloat-store -fomit-frame-pointer
> -g -O2 -o jv-convert.exe --main=gnu.gcj.convert.Convert -shared-libgcc
>  -L/usr/local/src/trunk/objdir/i686-pc-cygwin/libjava
> -L/usr/local/src/trunk/objdir/i686-pc-cygwin/libjava/.libs
> ./.libs/libgcj.a
> -L/usr/local/src/trunk/objdir/i686-pc-cygwin/libstdc++-v3/src
> -L/usr/local/src/trunk/objdir/i686-pc-cygwin/libstdc++-v3/src/.libs
> -ldl -lz -L/usr/local/src/trunk/objdir/./gcc -lgcc -lcygwin -luser32
> -lkernel32 -ladvapi32 -lshell32 -lgcc
> ./.libs/libgcj.a(lt102-misc.o): In function `GC_init_inner':
> /usr/local/src/trunk/objdir/i686-pc-cygwin/boehm-gc/../../../gcc/boehm-gc/misc.c:680:
> 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] Error 1
> make[2]: Leaving directory 
> `/usr/local/src/trunk/objdir/i686-pc-cygwin/libjava'
> make[1]: *** [all-target-libjava] Error 2
> make[1]: Leaving directory `/usr/local/src/trunk/objdir'
> make: *** [bootstrap] Error 2

Nothing has changed since the last time you asked this exact question:
.  It'd be better to
post this to the java list, BTW.

Brian

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

[Dave Korn]

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] Error 1 
>> make[2]: Leaving directory
>> `/usr/local/src/trunk/objdir/i686-pc-cygwin/libjava' make[1]: ***
>> [all-target-libjava] Error 2 
>> make[1]: Leaving directory `/usr/local/src/trunk/objdir'
>> make: *** [bootstrap] Error 2
> 
> Nothing has changed since the last time you asked this exact question:
> .  It'd be better to
> post this to the java list, BTW.


  Sorry guys, work pressure of day job at the moment, can't help for a couple
of days, but see Tom's comment at

http://gcc.gnu.org/ml/java/2007-04/msg00131.html

cheers,
  DaveK
-- 
Can't think of a witty .sigline today

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

[Diego Novillo]

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 thought of a try.  (No, the
> patch in the audit trail doesn't fix anything...)

I'll take a look today.

general_operand() not accepting CONCAT?

[Rask Ingemann Lambertsen]

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

(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"
  [(set (mem:GT16 (pre_dec:HI (reg:HI SP_REG)))
(match_operand:GT16 0 "general_operand" "RmIpu"))]
  "TARGET_PUSH_IMM || !CONSTANT_P (operands[0])"
  "#"
  "reload_completed"
  ...

but looking at recog.c, sure enough: general_operand() doesn't accept the
(concat ...) construct. Is that intentional?

-- 
Rask Ingemann Lambertsen

Re: GIMPLE tuples document uploaded to wiki

[Aldy Hernandez]

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?

[Ian Lance Taylor]

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)
> (reg:SF 37))) -1 (nil)
> (nil))
> 
> which I thought I'd covered with
> 
> (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"
>   [(set (mem:GT16 (pre_dec:HI (reg:HI SP_REG)))
> (match_operand:GT16 0 "general_operand" "RmIpu"))]
>   "TARGET_PUSH_IMM || !CONSTANT_P (operands[0])"
>   "#"
>   "reload_completed"
>   ...
> 
> but looking at recog.c, sure enough: general_operand() doesn't accept the
> (concat ...) construct. Is that intentional?

I would expect that most existing backends are not going to handle a
CONCAT correctly.  If you want to change general_operand to accept
CONCAT, you will need to audit existing uses.

Ian

Re: GIMPLE tuples document uploaded to wiki

[Geert Bosch]

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

[Diego Novillo]

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 rephrase, thanks.

Re: general_operand() not accepting CONCAT?

[Richard Henderson]

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 expr.c.


r~

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

[Kaveh R. GHAZI]

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 = identifier_global_value(sg); /* Question 1 */
  if (sg)
  {
if (TREE_TYPE (sg) == TYPE_DECL
&& DECL_ORIGINAL_TYPE (sg) == integer_type_node)
  return sg; /* Use this to set signgam. */
else
  /* Question 2 */ ;
  }
  else
  {
/* Question 3 */ ;
  }
else
{
  /* Question 4 */
}


I've marked above where I have questions about how to proceed.

1.  Only the C-family functions have identifier_global_value.  I need to
access this from the middle-end.  Should I use a langhook?  What should
the non-C languages default to returning?  NULL?  Should I punt in non-C
or just set the return value of lgamma without setting signgam?  I could
also declare signgam myself.

2.  I assume that if signgam is defined at global scope with something
other than int type then I punt, or should I proceed without setting
signgam?

3.  If signgam is declared somehow but not at global scope, then should I
declare it myself with type int and proceed to set it?  Or should I ignore
signgam but still generate the lgamma value?  Or do nothing?

4.  Likewise, if signgam is not declared at all, which of the three
choices from #3 should I do?

My guesses are:
1.  Do nothing for non-C.
2.  Punt.
3.  Declare signgam and proceed.
4.  Ditto.

Thanks,
--Kaveh
--
Kaveh R. Ghazi  [EMAIL PROTECTED]

Re: GIMPLE tuples document uploaded to wiki

[Daniel Berlin]

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/wiki/tuples

Aldy

Re: GIMPLE tuples document uploaded to wiki

[Diego Novillo]

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

[Steve Ellcey]

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 with version r124042 it fails.  The difference between the two is
your checkin:

2007-04-22  Richard Guenther  <[EMAIL PROTECTED]>

PR tree-optimization/29789
* tree-ssa-loop-im.c (stmt_cost): Adjust cost of shifts.
(rewrite_reciprocal): New helper split out from
determine_invariantness_stmt.
(rewrite_bittest): Likewise.
(determine_invariantness_stmt): Rewrite (A >> B) & 1 to
A & (1 << B) if (1 << B) is loop invariant but (A >> B)
is not.

To make things harder, the problem only seems to happen if I build
bootstrap.  If I build a non-bootstrap compiler then the applu test
compiles and runs fine.  If I build a bootstrap compiler, I can compile
applu but the program core dumps when run.  Do you have any ideas about
what might be happening or what I might try in order to understand what
is going wrong.

Steve Ellcey
[EMAIL PROTECTED]

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

[H. J. Lu]

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
> version r124041 of the GCC gfortran compiler it works but if I compile
> it with version r124042 it fails.  The difference between the two is
> your checkin:
> 

See

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31703


H.J.

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

[Joerg Wunsch]

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_value ("max-inline-insns-auto", 5);
>   flag_inline_functions = 1;

> Inlining has changed considerably since then, and it is possible
> that these parameter values are no longer appropriate.  The reports
> at the time indicate space savings.

Thanks for telling me where to look for it, Ian!  It's really
appreciated.

I made a first attempt on lowering max-inline-insns-auto from 5 to 3.
I did some initial testing (using the C program and shell script in
the attachment), on a recent GCC tree built for both, the AVR target
as well as my host's native i386 target.  This appears to be at a
break-even to me:

Conditions  -Os -Os -fno-inline
target=avr, N=1, GETX= CONST_ARG:   22  26
target=i386, N=1, GETX= CONST_ARG:  38  54
target=avr, N=1, GETX=  function:   40  42
target=i386, N=1, GETX=  function:  53  69
target=avr, N=2, GETX= CONST_ARG:   30  30
target=i386, N=2, GETX= CONST_ARG:  64  64
target=avr, N=2, GETX=  function:   50  48
target=i386, N=2, GETX=  function:  79  80
target=avr, N=3, GETX= CONST_ARG:   34  34
target=i386, N=3, GETX= CONST_ARG:  74  74
target=avr, N=3, GETX=  function:   54  52
target=i386, N=3, GETX=  function:  86  87
target=avr, N=4, GETX= CONST_ARG:   38  38
target=i386, N=4, GETX= CONST_ARG:  84  84
target=avr, N=4, GETX=  function:   58  56
target=i386, N=4, GETX=  function:  93  94
target=avr, N=5, GETX= CONST_ARG:   42  42
target=i386, N=5, GETX= CONST_ARG:  94  94
target=avr, N=5, GETX=  function:   62  60
target=i386, N=5, GETX=  function:  100 101

For only a single invocation, obviously, running with -fno-inline will
always yield larger code (albeit the difference is much less on the
AVR than on the i386).

For multiple invocations, both architectures are neutral to the
-fno-inline option when invocation the function to be inlined with a
constant argument.  If instead the argument is another function
(possibly to be inlined), both architectures behave differently: the
AVR wins one instruction (two bytes) when not inlining, the i386 wins
one instruction when inlining.

The "getx()" function was a silly attempt to mimic the typical C++
access methods mentioned without really using C++.

This indicates using 3 instead of 5 might be a much more sane default.

What's that test suite that has been mentioned here, and how to run
it?

-- 
cheers, J"org   .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)
#define UCSRA (*(volatile unsigned char *)0x2B)
#define UDRE 5
#define UDR   (*(volatile unsigned char *)0x2C)

static void putch(char ch);

void putch(char ch)
{
  while (!(UCSRA & (1< 1
  putch(GETX()); 
# if N > 2
  putch(GETX()); 
#  if N > 3
  putch(GETX());
#   if N > 4
  putch(GETX()); 
#   endif
#  endif
# endif
#endif

  return 0;
}



run.sh
Description: Bourne shell script

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

[Ian Lance Taylor]

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)

[Zdenek Dvorak]

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 will send a patch once it passes regtesting.

Zdenek

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

[Mark Mitchell]

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 here?
> 
> I found the problem, I will send a patch once it passes regtesting.

Thanks!

-- 
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713

Successfull Build of gcc on Cygwin WinXp SP2

[James Tebneff]

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 23/04/2007)


$ ./g++ -v
Using built-in specs.
Target: i686-pc-cygwin
Configured with: ../configure --prefix=/cygdrive/c/beta
--enable-languages=c,c++
Thread model: single
gcc version 4.3.0 20070424 (experimental)


JT

Re: paired register loads and stores

[Andrew Pinski]

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 split anyways if the
target supports loading adjacent registers (note adjacent is defined
by the target headers really, that is reg 0 is adjacent to reg1, what
they are up to the target).

-- Pinski

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

[Fu, Chao-Ying]

> -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 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
> > version r124041 of the GCC gfortran compiler it works but 
> if I compile
> > it with version r124042 it fails.  The difference between the two is
> > your checkin:
> > 
> 
> See
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31703
> 
> 
> H.J.
> 

I got a test that fails for mips32r2-elf.  Is this fail from the same issue?

(bug74.c)
void test (long long mod, long long temp)
{
  while (1)
{
  int leftmost = (mod >> 1) & 1;
  mod = mod << 1;
  if (leftmost)
mod = temp;
}
}

# mipsisa32r2-elf-gcc -S bug74.c -O -fdump-tree-all
bug74.c: In function â?~testâ?T:
bug74.c:5: internal compiler error: in simplify_subreg, at simplify-rtx.c:4677
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.

(bug74.c.119t.blocks)

;; Function test (test)

test (mod, temp)
{
  long long int mod.25;
  int leftmost;

:;

:;
  mod.25 = mod;

:;
  leftmost = mod.25 & 2;
  mod.25 = mod.25 << 1;
  mod = temp;
  if (leftmost != 0) goto ; else goto ;

}

NOTE that there should be a type cast to int for this statement
"leftmost = mod.25 & 2;".

Regards,
Chao-ying

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

[Andrew Pinski]

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 extern
decls.
You can reproduce this with:

../src/configure -v --enable-languages=c,c++ 
--enable-targets=powerpc-linux,powerpc64-linux powerpc-linux-gnu


This works for me on powerpc64-linux-gnu configured as such:
--prefix=${HOME}/gcc-mainline --with-mpfr=/usr/local --with-cpu=default32

The only thing I can think of which is causing the issue is that the
check for pthread_setaffinity_np is defining _GNU_SOURCE but
config/linux/affinity.c is not but I just looked into the source and
it does:
#ifndef _GNU_SOURCE
#define _GNU_SOURCE 1
#endif


So I don't think that is the issue.  Can you look into config.log and
make sure that the test is not emitting warnings.  It is a link time
test too.  The other problem might be that you have an older
pthreads.h header file installed and a newer libpthreads.so so the
versions are mismatching.

Thanks,
Andrew Pinski

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

[H. J. Lu]

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: 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
> > > version r124041 of the GCC gfortran compiler it works but 
> > if I compile
> > > it with version r124042 it fails.  The difference between the two is
> > > your checkin:
> > > 
> > 
> > See
> > 
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31703
> > 
> > 
> > H.J.
> > 
> 
> I got a test that fails for mips32r2-elf.  Is this fail from the same issue?

I think it is the same issue.


H.J.
---
> 
> (bug74.c)
> void test (long long mod, long long temp)
> {
>   while (1)
> {
>   int leftmost = (mod >> 1) & 1;
>   mod = mod << 1;
>   if (leftmost)
> mod = temp;
> }
> }
> 
> # mipsisa32r2-elf-gcc -S bug74.c -O -fdump-tree-all
> bug74.c: In function â?~testâ?T:
> bug74.c:5: internal compiler error: in simplify_subreg, at simplify-rtx.c:4677
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See http://gcc.gnu.org/bugs.html> for instructions.
> 
> (bug74.c.119t.blocks)
> 
> ;; Function test (test)
> 
> test (mod, temp)
> {
>   long long int mod.25;
>   int leftmost;
> 
> :;
> 
> :;
>   mod.25 = mod;
> 
> :;
>   leftmost = mod.25 & 2;
>   mod.25 = mod.25 << 1;
>   mod = temp;
>   if (leftmost != 0) goto ; else goto ;
> 
> }
> 
> NOTE that there should be a type cast to int for this statement
> "leftmost = mod.25 & 2;".
>