date:20060120


Daniel Berlin wrote:

On Fri, 2006-01-20 at 10:53 +0530, Ranjit Mathew wrote:
  

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

  Mainline fails to bootstrap for me (revision 110017)
on i686-pc-linux-gnu.

Configured as:

$GCC_SRC_DIR/configure --prefix=$HOME/gcc --enable-languages=c,c++,java \
- --with-as=/home/ranmath/gnu/bin/as --with-gnu-as \
- --with-ld=/home/ranmath/gnu/bin/ld --with-gnu-ld \
- --with-arch=pentium4 --with-tune=pentium4 \
- --disable-nls --disable-checking --disable-libmudflap \
- --disable-debug --enable-threads=posix --enable-__cxa_atexit \
- --disable-static





Kenny thought it would be nice, rather than pass the actual bb info to free to 
the freeing function, to instead pass some random bitmap.


The attached fixes *that*, but this just causes a crash deeper in trying to 
free some chains.

However, it looks like that is either caused by a double free, or because
 we never null out pointers to things after we free the memory for what they 
are pointing to.

  



Index: df-core.c
===
--- df-core.c   (revision 110017)
+++ df-core.c   (working copy)
@@ -292,6 +292,7 @@ are write-only operations.  
 static struct df *ddf = NULL;

 struct df *shared_df = NULL;
 
+static void * df_get_bb_info (struct dataflow *, unsigned int);

 /*
   Functions to create, destroy and manipulate an instance of df.
 */
@@ -370,7 +371,7 @@ df_set_blocks (struct df *df, bitmap blo
  EXECUTE_IF_SET_IN_BITMAP (diff, 0, bb_index, bi)
{
  basic_block bb = BASIC_BLOCK (bb_index);
- (*dflow->problem->free_bb_fun) (dflow, bb, diff);
+ (*dflow->problem->free_bb_fun) (dflow, bb, df_get_bb_info 
(dflow, bb_index));
}
}
}
  
This is why c sucks.  In any language with a reasonable type system, 
this could have been written with a subtype and would not require using 
a void * arg.


Sorry for the problems and thanks for looking into them.

kenny

Re: RTL alias analysis

2006-01-20 Thread Richard Guenther

On 1/20/06, Steven Bosscher <[EMAIL PROTECTED]> wrote:
> On Tuesday 03 January 2006 17:27, Richard Henderson wrote:
> > On Mon, Jan 02, 2006 at 12:45:49AM -0500, Daniel Berlin wrote:
> > > ... the real
> > > solution is to transfer the information that the stack space sharing
> > > knows into some simple set form, and use *that directly* in alias.c, and
> > > check it *first*, so that if they have the same stack slot, we say there
> > > is a dependence, even if the memory expressions/types/etc look
> > > different.
> >
> > ... And that doesn't work for the test case, because we've
> > carefuly thrown away any information that might have given
> > us any information wrt the stack slots.
> >
> > I'll have to give this some thought.
>
> Hi rth,
>
> Is your "think this over"-process still runnig? ;-)
>
> We've tried to add some more food for thought in the audit trail
> of PR25654, which is tracking this issue.  Hope you'll add your
> thoughts so far, so that we can make some progress on getting a
> PR GCC 4.1 regression fixed...

A patch was also posted based on ideas in the audit trail.  It's third
incarnation at
http://gcc.gnu.org/ml/gcc-patches/2006-01/msg00967.html
would need a review.

Richard.

Re: Mainline bootstrap failure (revision 110017)

2006-01-20 Thread Andreas Jaeger


The tree is still broken for me.  Daniel, did you commit your patch?

Andreas
-- 
 Andreas Jaeger, [EMAIL PROTECTED], http://www.suse.de/~aj/
  SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126


pgprQ6b4mKkqS.pgp
Description: PGP signature

Re: Mainline bootstrap failure (revision 110017)

2006-01-20 Thread Andreas Jaeger

Kenneth Zadeck <[EMAIL PROTECTED]> writes:

> Daniel Berlin wrote:

>> The attached fixes *that*, but this just causes a crash deeper in trying to 
>> free some chains.
> [...]
> Sorry for the problems and thanks for looking into them.

Ken, please reread the email.  The issue is *not* fixed according to
Daniel, there's still another problem.  Could you look into it,
please?

Andreas
-- 
 Andreas Jaeger, [EMAIL PROTECTED], http://www.suse.de/~aj/
  SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126


pgpyrff9IvM6V.pgp
Description: PGP signature

Re: Mainline bootstrap failure (revision 110017)

2006-01-20 Thread Andreas Krebbel

(I've sent this first to gcc-patches accidently :(
> Kenny thought it would be nice, rather than pass the actual bb info to free 
> to the freeing function, to instead pass some random bitmap.
> 
> 
> The attached fixes *that*, but this just causes a crash deeper in trying to 
> free some chains.
> 
> However, it looks like that is either caused by a double free, or because
>  we never null out pointers to things after we free the memory for what they 
> are pointing to.
> 
Here is a reduced testcase failing with -O1:

__udivmodti4 ()
{
  unsigned long d0, a;

  for (a = 56; a > 0; a -= 8)
if ((d0 & 0xff) != 0)
  break;

  for (a = 57; a > 0; a -= 7)
if ((d0 & 0xff) != 0)
  break;
}

With your patch:

Program received signal SIGSEGV, Segmentation fault.
0x80188d16 in bitmap_obstack_free (map=0x808dea80) at 
/build/gcc-4.2/gcc/bitmap.c:272
272   map->first = (void *)map->obstack->heads;
(gdb) bt
#0  0x80188d16 in bitmap_obstack_free (map=0x808dea80) at 
/build/gcc-4.2/gcc/bitmap.c:272
#1  0x802319fc in df_rd_free (dflow=0x808c9eb0) at 
/build/gcc-4.2/gcc/df-problems.c:1191
#2  0x8022a2b6 in df_finish1 (df=0x808d7db0) at 
/build/gcc-4.2/gcc/df-core.c:406
#3  0x802914be in iv_analysis_done () at 
/build/gcc-4.2/gcc/loop-iv.c:1238
#4  0x803d4a42 in estimate_probability (loops_info=0x3cd9ce0)
at /build/gcc-4.2/gcc/predict.c:844
#5  0x803e699c in rest_of_handle_branch_prob () at 
/build/gcc-4.2/gcc/profile.c:1363

Without your patch:

Program received signal SIGSEGV, Segmentation fault.
0x80188d16 in bitmap_obstack_free (map=0x808ca708) at 
/build/gcc-4.2/gcc/bitmap.c:272
272   map->first = (void *)map->obstack->heads;
(gdb) bt
#0  0x80188d16 in bitmap_obstack_free (map=0x808ca708) at 
/build/gcc-4.2/gcc/bitmap.c:272
#1  0x802307b0 in df_rd_free_bb_info (dflow=0x808c9eb0, 
bb=0x201ad80, vbb_info=0x808ca660)
at /build/gcc-4.2/gcc/df-problems.c:853
#2  0x80229cd6 in df_set_blocks (df=0x808d7db0, blocks=0x808ca5a0)
at /build/gcc-4.2/gcc/df-core.c:373
#3  0x8028e2ac in iv_analysis_loop_init (loop=0x808d7ca0) at 
/build/gcc-4.2/gcc/loop-iv.c:267
#4  0x803d3efa in predict_loops (loops_info=0x3889ce0, 
rtlsimpleloops=1 '\001')
at /build/gcc-4.2/gcc/predict.c:618
#5  0x803d4a24 in estimate_probability (loops_info=0x3889ce0)
at /build/gcc-4.2/gcc/predict.c:842
#6  0x803e6984 in rest_of_handle_branch_prob () at 
/build/gcc-4.2/gcc/profile.c:1363

Bye,

-Andreas-

> Index: df-core.c
> ===
> --- df-core.c (revision 110017)
> +++ df-core.c (working copy)
> @@ -292,6 +292,7 @@ are write-only operations.  
>  static struct df *ddf = NULL;
>  struct df *shared_df = NULL;
>  
> +static void * df_get_bb_info (struct dataflow *, unsigned int);
>  
> /*
>Functions to create, destroy and manipulate an instance of df.
>  
> */
> @@ -370,7 +371,7 @@ df_set_blocks (struct df *df, bitmap blo
> EXECUTE_IF_SET_IN_BITMAP (diff, 0, bb_index, bi)
>   {
> basic_block bb = BASIC_BLOCK (bb_index);
> -   (*dflow->problem->free_bb_fun) (dflow, bb, diff);
> +   (*dflow->problem->free_bb_fun) (dflow, bb, df_get_bb_info 
> (dflow, bb_index));
>   }
>   }
>   }

Re: Mainline bootstrap failure (revision 110017)


Andreas Jaeger wrote:

Kenneth Zadeck <[EMAIL PROTECTED]> writes:

  

Daniel Berlin wrote:



  

The attached fixes *that*, but this just causes a crash deeper in trying to 
free some chains.
  

[...]
Sorry for the problems and thanks for looking into them.



Ken, please reread the email.  The issue is *not* fixed according to
Daniel, there's still another problem.  Could you look into it,
please?

Andreas
  

I will update and start looking.

sorry

kenny

Re: Mainline bootstrap failure (revision 110017)


Andreas Jaeger wrote:

Kenneth Zadeck <[EMAIL PROTECTED]> writes:

  

Daniel Berlin wrote:



  

The attached fixes *that*, but this just causes a crash deeper in trying to 
free some chains.
  

[...]
Sorry for the problems and thanks for looking into them.



Ken, please reread the email.  The issue is *not* fixed according to
Daniel, there's still another problem.  Could you look into it,
please?

Andreas
  
I would like permission to revert zdenek's patch for a few days.  There 
is nothing wrong with zdenek's patch, pe se, but it excercises a part of 
df that should work but does not.


We could revert my storage patch, but the problem is much deeper than 
that.  The storage patch only causes this problem to happen when 
bootstrapping.  The problem will still be there and may cause random 
ices when running zdeneks code.


The problem is that when ever you delete any basic blocks, you need to 
get rid of the def use and use def chains that either start or end in 
the deleted block, furthermore,  this has to be done before the 
instructions are deleted for those blocks.  This will take me a day to 
get correct.
Zdenek's patch is the only code that manipulates the blocks after 
use-def or def-use chains are built.


Kenny

Re: Status of -fstack-usage?

2006-01-20 Thread Olivier Hainque

Hello Ioannis;

Ioannis E. Venetis wrote:

> > Would __builtin_stack_size (F) retrieve information about F's stack frame
> > only, or would it also recursively account for every other function that
> > F may call ?
> >
> > Implementing the former is probably possible, though I'm not sure
> > exactly how useful it would be. 

> I agree that the former is probably not very useful. If a function is
> set to run as a thread and it calls other functions, the stack required
> for those functions should be accounted for. Probably the second option
> is much more useful.

 Sure. It's unfortunately not really an option for complexity reasons.

> I had a look here:
> 
> http://gcc.gnu.org/onlinedocs/gnat_ugn_unw/Static-Stack-Usage-Analysis.html
> 
> I think that the best would be __builtin_stack_size(F) to return what is
> described as "dynamic" and "bounded" in the above link.

 I'm afraid there is a misunderstanding here. What -fstack-usage outputs
 for each function is information about the stack used only by the function
 itself. There is no relationship with what the functions it calls do.

 The "dynamic" qualifier states whether the function itself allocates
 dynamic amounts of stack, like with an "alloca (n)" and "n" a variable.

 The extra "bounded" qualifier states whether we know a bound for such
 dynamic allocations.

> Except from recursive functions, what are the other cases where the
> above size cannot be computed statically?

 Functions often call functions in other compilation units, so this
 almost always is a non-straightforward inter-unit computation issue
 to start with. This is what the accompaning -fcallgraph-info is
 about, together with some tool to merge the per-unit graphs and
 perform computations on the outcome.

 Then, any form of indirect call is a potentially hard source of difficulty
 and there are several variants of those across the languages supported in
 GCC.

 Third, functions we don't compile often come into play.

 And I'm probably forgetting a couple :)

Help - Crash gcc 3.4.2 64 bits Shared Library

2006-01-20 Thread Frederico Faria

Hi,

Sometimes I have got a bus error at libstdc++ with gcc
3.4.2
in SUN.

I have used a multithread 64 bits application that
loads dynamicly ( as a application's plugin ) a couple
of dinamic libraries. That application and all your
dynamic libraries have a strong use of C++ Standard
Librarie.

Sometimes, when the application is running over high
load
It has received a bus error. The error is got in the
push_back() method call to a vector object.
I have a limited stack trace got using "mdb" ( see
below ), because I was not able to reproduce the
error in development.

I would like know if the error could is or due some
libstdc++ bug either some missing compilation flag (
i have used -fPIC -shared -m64 in shared libraries
generation ), either some application bug.

Could somebody gives me any hint/tip ? Below is the
stack trace.

Thank you,

Frederico Faria

Information about the environment

The application is compiled with:
SunOS 5.8 Generic_117350-04 sun4u sparc
SUNW,Sun-Fire-V210
GCC 3.4.2

The application runs another SUN:
SunOS 5.9 Generic_118558-04 sun4u sparc
SUNW,Sun-Fire-880

Stack Trace:

668fcfb1
libstdc++.so.6`_ZN9__gnu_cxx18__exchange_and_addEPVli(1314eb710,
1314eb710, 1314eb718, 1314eb710, 0, 668fd918)
668fd091 0x6fd786d8(12ad55738, 3,
6e591a38, 668fdaa0, 668ff250,
668fd9d8)
668fd151
CacheRelatedPlugins.so`_ZN25CurrentTransactionStorage12addAccountIdEjm+0x40(12ad55738,
275946, 275946, 0, 81010100,
668fdaa0)
668fd211
CacheRelatedPlugins.so`_ZN12PackageCache17registerAccountIdER13ParserContextm+0x4b4(12ad54d00,
668ff250, 275946,
117eda898, 81010100, ff00)

___
Yahoo! doce lar. Faça do Yahoo! sua homepage.
http://br.yahoo.com/homepageset.html

Re: Mainline bootstrap failure (revision 110017)

2006-01-20 Thread Daniel Berlin

On Fri, 2006-01-20 at 12:34 +0100, Andreas Jaeger wrote:
> The tree is still broken for me.  Daniel, did you commit your patch?

No, because i realized last night that you will just hit the rest of the
problem during bootstrap, without fail.

> 
> Andreas

Re: Mainline bootstrap failure (revision 110017)

Hello,

> >>>The attached fixes *that*, but this just causes a crash deeper in trying 
> >>>to free some chains.
> >>>  
> >>[...]
> >>Sorry for the problems and thanks for looking into them.
> >>
> >
> >Ken, please reread the email.  The issue is *not* fixed according to
> >Daniel, there's still another problem.  Could you look into it,
> >please?
> >
> I would like permission to revert zdenek's patch for a few days.  There 
> is nothing wrong with zdenek's patch, pe se, but it excercises a part of 
> df that should work but does not.

I don't quite like this idea; as you yourself say, the problem is not in
that patch (in fact, mainline bootstraps and passes regtesting with it
without your patch); so I think that if we indeed want to go into
reverting patches, it should be the one causing the problem (and I have
a followup patch that I would like to be able to test).

Btw.: of course it may happen that some patch sometimes breaks
bootstrap, it happened to everyone of us.  But, with your patch, not
even libgcc builds.  This means that you did not even try to build gcc
before commiting your patch.  Please do that next time.  In fact,
running at least a partial bootstrap till gengtype is run helped me
avoid introducing bootstrap failures (caused by unexpected interaction
with patches commited since I tested the patch fully the last time)
several times, so it is a good idea even if you are quite sure that no
such problem may occur.

> We could revert my storage patch, but the problem is much deeper than 
> that.  The storage patch only causes this problem to happen when 
> bootstrapping.  The problem will still be there and may cause random 
> ices when running zdeneks code.
> 
> The problem is that when ever you delete any basic blocks, you need to 
> get rid of the def use and use def chains that either start or end in 
> the deleted block, furthermore,  this has to be done before the 
> instructions are deleted for those blocks.  This will take me a day to 
> get correct.
> Zdenek's patch is the only code that manipulates the blocks after 
> use-def or def-use chains are built.

This analysis seems wrong to me -- the crash occurs when called from
estimate_probability, and we do not change CFG in branch prediction.

Zdenek

Re: libgomp and OMP_NUM_THREADS

2006-01-20 Thread David Edelsohn

> Jakub Jelinek writes:

Jakub> Not sure why sched allows that, because insn 42 clearly operates on 
volatile
Jakub> memory.  Do you think that's a bug in sched that it should be honoring
Jakub> /v and not moving insns accross it, or that something is broken with the
Jakub> ppc* patterns?

I think it more likely is a latent bug in the scheduler, not a
problem with the patterns.  Admittedly the volatile load-locked insn does
not appear until the post-reload splitter after sched1, but it still seems
that the scheduler should not move volatile mem.

What happens on Alpha?  I would expect that it would show similar
symptoms. 

David

Re: Mainline bootstrap failure (revision 110017)


Zdenek Dvorak wrote:

Hello,

  
The attached fixes *that*, but this just causes a crash deeper in trying 
to free some chains.
 
  

[...]
Sorry for the problems and thanks for looking into them.
   


Ken, please reread the email.  The issue is *not* fixed according to
Daniel, there's still another problem.  Could you look into it,
please?

  
I would like permission to revert zdenek's patch for a few days.  There 
is nothing wrong with zdenek's patch, pe se, but it excercises a part of 
df that should work but does not.



I don't quite like this idea; as you yourself say, the problem is not in
that patch (in fact, mainline bootstraps and passes regtesting with it
without your patch); so I think that if we indeed want to go into
reverting patches, it should be the one causing the problem (and I have
a followup patch that I would like to be able to test).

Btw.: of course it may happen that some patch sometimes breaks
bootstrap, it happened to everyone of us.  But, with your patch, not
even libgcc builds.  This means that you did not even try to build gcc
before commiting your patch.  Please do that next time.  In fact,
running at least a partial bootstrap till gengtype is run helped me
avoid introducing bootstrap failures (caused by unexpected interaction
with patches commited since I tested the patch fully the last time)
several times, so it is a good idea even if you are quite sure that no
such problem may occur.

  

Zdenek,
There are several problems here.  If I fix the immediate problem, you 
only hit the next one.


The underlying problem is that when you change the blocks in the program 
and you have def-use or use-def chains built, these have to be cleaned 
out in a way that was not being done.
If I revert my patch, it will fix the immediate problem that 
df_set_blocks crashes but will most likely happen in other places.  It 
is because of the other places that it is not sufficient to just revert 
my patch.


Yours is currently the only place that plays with blocks when the 
use-def chain problem has been built.  This is something that I 
advertised could be done and I blew it.  But removing my last patch is 
not going to fix that, it will still be broken, it will just fail less 
often.


Kenny
We could revert my storage patch, but the problem is much deeper than 
that.  The storage patch only causes this problem to happen when 
bootstrapping.  The problem will still be there and may cause random 
ices when running zdeneks code.


The problem is that when ever you delete any basic blocks, you need to 
get rid of the def use and use def chains that either start or end in 
the deleted block, furthermore,  this has to be done before the 
instructions are deleted for those blocks.  This will take me a day to 
get correct.
Zdenek's patch is the only code that manipulates the blocks after 
use-def or def-use chains are built.



This analysis seems wrong to me -- the crash occurs when called from
estimate_probability, and we do not change CFG in branch prediction.

Zdenek

Re: [HELP] GCC 4.1 branch Ada status on powerpc-darwin?

2006-01-20 Thread Peter O'Gorman


Geoff Keating wrote:


On 19/01/2006, at 9:08 AM, Peter O'Gorman wrote:

Eric Botcazou wrote:
|>Yes the workaround is to add -fexceptions or -shared-libgcc to the
|>command line when linking libgnat but I don't know if that is the  
correct

|>fix or some hacking to config/darwin.h is needed.
|
|
| Thanks.  However, that's not sufficient because the tools fail to  
build too:


I'm adding Geoff Keating to the CC, hoping that he'll both shout at  
me while
explaining why this change to darwin.h is broken, and suggest a  real 
fix.



If ADA is going to use exceptions, then it needs to do what G++ does,  
which is pass -shared-libgcc in its driver.


This change allows gcc to build on powerpc-apple-darwin8.4 with ada.


It's not OK because for forwards binary compatibility the shared  libgcc 
must be used for exception handling.


Okay.

The following patch allows the 4.1 branch to build ada on 
powerpc-apple-darwin8.4, okay? If so please apply as I do not have write access.


??-??-2006  Peter O'Gorman  <[EMAIL PROTECTED]>

* Makefile.in: Pass -static-libgcc when building tools,
and -shared-libgcc when building library on darwin.

Peter


Index: gcc/ada/Makefile.in
===
--- gcc/ada/Makefile.in (revision 110022)
+++ gcc/ada/Makefile.in (working copy)
@@ -1308,7 +1308,7 @@
 
   EH_MECHANISM=-gcc
   GNATLIB_SHARED = gnatlib-shared-darwin
-  SO_OPTS = -Wl,-flat_namespace
+  SO_OPTS = -Wl,-flat_namespace -shared-libgcc
   RANLIB = ranlib -c
   GMEM_LIB = gmemlib
   PREFIX_OBJS=$(PREFIX_REAL_OBJS)
@@ -1365,6 +1365,7 @@
 
 LIBGNAT=../rts/libgnat.a 
 GCC_LINK="$(CC) -static-libgcc $(ADA_INCLUDES)"
+TOOL_CC=$(CC) -static-libgcc
 
 # when compiling the tools, the runtime has to be first on the path so that
 # it hides the runtime files lying with the rest of the sources
@@ -1472,15 +1473,15 @@
 
 # Likewise for the tools
 ../../gnatmake$(exeext): $(P) b_gnatm.o link.o $(GNATMAKE_OBJS)
-   $(CC) $(ALL_CFLAGS) $(LDFLAGS) -o $@ b_gnatm.o $(GNATMAKE_OBJS) \
+   $(TOOL_CC) $(ALL_CFLAGS) $(LDFLAGS) -o $@ b_gnatm.o $(GNATMAKE_OBJS) \
  $(TOOLS_LIBS)
 
 ../../gnatlink$(exeext): $(P) b_gnatl.o link.o $(GNATLINK_OBJS)
-   $(CC) $(ALL_CFLAGS) $(LDFLAGS) -o $@ b_gnatl.o $(GNATLINK_OBJS) \
+   $(TOOL_CC) $(ALL_CFLAGS) $(LDFLAGS) -o $@ b_gnatl.o $(GNATLINK_OBJS) \
  $(TOOLS_LIBS)
 
 ../../gnatbl$(exeext): gnatbl.o
-   $(CC) -o $@ $(ALL_CFLAGS) $(LDFLAGS) gnatbl.o $(TOOLS_LIBS)
+   $(TOOL_CC) -o $@ $(ALL_CFLAGS) $(LDFLAGS) gnatbl.o $(TOOLS_LIBS)
 
 gnatbl.o: gnatbl.c adaint.h
$(CC) $(ALL_CFLAGS) $(INCLUDES) -c $< $(OUTPUT_OPTION)

Re: [HELP] GCC 4.1 branch Ada status on powerpc-darwin?

2006-01-20 Thread Arnaud Charlet

>  LIBGNAT=../rts/libgnat.a 
>  GCC_LINK="$(CC) -static-libgcc $(ADA_INCLUDES)"
> +TOOL_CC=$(CC) -static-libgcc

I'd rather avoid code duplication and reuse GCC_LINK if possible, or
split GCC_LINK in two if needed.

Otherwise the tools part is generally fine with me (passing -static-libgcc
to build gnatmake, gnatbind and gnatbl, although gnatbl is a small
C program which does not use exceptions)

Arno

Re: Mainline bootstrap failure (revision 110017)

2006-01-20 Thread Daniel Berlin

On Fri, 2006-01-20 at 16:06 +0100, Zdenek Dvorak wrote:
> Hello,
> 
> > >>>The attached fixes *that*, but this just causes a crash deeper in trying 
> > >>>to free some chains.
> > >>>  
> > >>[...]
> > >>Sorry for the problems and thanks for looking into them.
> > >>
> > >
> > >Ken, please reread the email.  The issue is *not* fixed according to
> > >Daniel, there's still another problem.  Could you look into it,
> > >please?
> > >
> > I would like permission to revert zdenek's patch for a few days.  There 
> > is nothing wrong with zdenek's patch, pe se, but it excercises a part of 
> > df that should work but does not.
> 
> I don't quite like this idea; as you yourself say, the problem is not in
> that patch (in fact, mainline bootstraps and passes regtesting with it
> without your patch); so I think that if we indeed want to go into
> reverting patches, it should be the one causing the problem (and I have
> a followup patch that I would like to be able to test).
> 
> Btw.: of course it may happen that some patch sometimes breaks
> bootstrap, it happened to everyone of us.  But, with your patch, not
> even libgcc builds.  This means that you did not even try to build gcc
> before commiting your patch.

This is simply not true.
I in fact, watched him bootstrap and regtest it multiple times.
It simply happened that 10 minutes before he committed his patch, you
committed yours.
Please don't go accusing people of not bootstrapping, etc.

> > We could revert my storage patch, but the problem is much deeper than 
> > that.  The storage patch only causes this problem to happen when 
> > bootstrapping.  The problem will still be there and may cause random 
> > ices when running zdeneks code.
> > 
> > The problem is that when ever you delete any basic blocks, you need to 
> > get rid of the def use and use def chains that either start or end in 
> > the deleted block, furthermore,  this has to be done before the 
> > instructions are deleted for those blocks.  This will take me a day to 
> > get correct.
> > Zdenek's patch is the only code that manipulates the blocks after 
> > use-def or def-use chains are built.
> 
> This analysis seems wrong to me -- the crash occurs when called from
> estimate_probability, and we do not change CFG in branch prediction.

The crash occurs from df_set_blocks called from iv_analysis.
Not sure what you are referring to.

His analysis of what is going on is completely correct.

Re: libgomp and OMP_NUM_THREADS

2006-01-20 Thread Jakub Jelinek

On Fri, Jan 20, 2006 at 10:10:23AM -0500, David Edelsohn wrote:
> > Jakub Jelinek writes:
> 
> Jakub> Not sure why sched allows that, because insn 42 clearly operates on 
> volatile
> Jakub> memory.  Do you think that's a bug in sched that it should be honoring
> Jakub> /v and not moving insns accross it, or that something is broken with 
> the
> Jakub> ppc* patterns?
> 
>   I think it more likely is a latent bug in the scheduler, not a
> problem with the patterns.  Admittedly the volatile load-locked insn does
> not appear until the post-reload splitter after sched1, but it still seems
> that the scheduler should not move volatile mem.

That's quite questionable, depends on what is a volatile memory reference
supposed to mean (and what is UNSPEC_VOLATILE supposed to mean, and __asm
__volatile).
My understanding is that UNSPEC_VOLATILE and __asm __volatile are an
optimization barrier, but a mere volatile memory reference doesn't have
to be.  Other memory references obviously cannot be moved over the volatile
memory read or write if GCC can't prove they don't overlap or if they
are both volatile.  But a memory read or write that provably doesn't
overlap the volatile memory location, is not volatile (thus has no
side-effects) IMNSHO can be moved across it, hoisted out of loops etc.
__sync_* builtins are supposed to be optimization barriers, so I'd say
UNSPEC_VOLATILE or some other optimization barrier for them is highly
desirable.

>   What happens on Alpha?  I would expect that it would show similar
> symptoms. 

It is likely Alpha and IA-64 have similar problems (in fact, the number
ofunreproduceable failures I'm getting in libgomp testsuite on ia64 is quite
high, while i386, x86_64, s390{,x}, sparc* (and ppc* with the patch I
posted) are fine).  But I don't have an Alpha box to check that myself.

Jakub

Re: Mainline bootstrap failure (revision 110017)

2006-01-20 Thread Roger Sayle

On Fri, 20 Jan 2006, Kenneth Zadeck wrote:
> I would like permission to revert Zdenek's patch for a few days.  There
> is nothing wrong with zdenek's patch, pe se, but it excercises a part of
> df that should work but does not.

I'm going to make an executive decision on this one, to restore bootstrap
immediately.  I agree that Zdenek's patch be reverted for a few days
without prejudice.  Both patch submitters followed the rules of bootstrap
and regression test, but a bad (unforetestable) interaction occurred
between the two.  It turns out that it was the Kenny's DF changes at
fault, that contain paths that weren't fully tested with his changes
alone.  Zdenek's patch is innocent, but reliant on this problematic
functionality.

Normally, we'd allow 48 hours of shouting before fixing the tree.
But I think we agree that in the case "the mid-air collision" needs
to be resolved by Kenny, and his request for a short-term work around
carries some weight.  With no shame on the killloop merge, I suspect we
should back it out, as it is mostly new functionality, whilst Kenny's
patch also contained bug-fixes, and is therefore probably the more stable
of the two bits when applied independently.

I hope this is satisfactory to anyone.  The judge's decision is final
modulo an over-ruling by Mark or the SC.  This gets the tree back to
bootstrap land, and allows the rest of GOMP to be merged etc... at a
busy point in the GCC lifecycle.

The clock is ticking for Kenny.  I propose a reverse 48 hour rule
where we reinstate Zdenek's patch on Monday, either by fixing DF
by then or by reverting the DF changes.  i.e. swap one of the clashing
patches for the other.

My apologies to everyone for any inconvenience.  Many thanks to Dan
and H-P for investigating the problem on IRC.

Roger
--
Roger Sayle, E-mail: [EMAIL PROTECTED]
OpenEye Scientific Software, WWW: http://www.eyesopen.com/
Suite 1107, 3600 Cerrillos Road, Tel: (+1) 505-473-7385
Santa Fe, New Mexico, 87507. Fax: (+1) 505-473-0833

Re: Mainline bootstrap failure (revision 110017)

Hello,

> > > >>>The attached fixes *that*, but this just causes a crash deeper in 
> > > >>>trying 
> > > >>>to free some chains.
> > > >>>  
> > > >>[...]
> > > >>Sorry for the problems and thanks for looking into them.
> > > >>
> > > >
> > > >Ken, please reread the email.  The issue is *not* fixed according to
> > > >Daniel, there's still another problem.  Could you look into it,
> > > >please?
> > > >
> > > I would like permission to revert zdenek's patch for a few days.  There 
> > > is nothing wrong with zdenek's patch, pe se, but it excercises a part of 
> > > df that should work but does not.
> > 
> > I don't quite like this idea; as you yourself say, the problem is not in
> > that patch (in fact, mainline bootstraps and passes regtesting with it
> > without your patch); so I think that if we indeed want to go into
> > reverting patches, it should be the one causing the problem (and I have
> > a followup patch that I would like to be able to test).
> > 
> > Btw.: of course it may happen that some patch sometimes breaks
> > bootstrap, it happened to everyone of us.  But, with your patch, not
> > even libgcc builds.  This means that you did not even try to build gcc
> > before commiting your patch.
> 
> This is simply not true.
> I in fact, watched him bootstrap and regtest it multiple times.
> It simply happened that 10 minutes before he committed his patch, you
> committed yours.
> Please don't go accusing people of not bootstrapping, etc.

I do not accuse him of not testing it; of course that he tested it
properly.  I just say that he should have at least build the branch in
the state in that he wanted to commit it.  It takes just a few minutes,
and if someone makes change during that time, rebuilding to verify that
these did not break something takes just a few seconds.

> > > We could revert my storage patch, but the problem is much deeper than 
> > > that.  The storage patch only causes this problem to happen when 
> > > bootstrapping.  The problem will still be there and may cause random 
> > > ices when running zdeneks code.
> > > 
> > > The problem is that when ever you delete any basic blocks, you need to 
> > > get rid of the def use and use def chains that either start or end in 
> > > the deleted block, furthermore,  this has to be done before the 
> > > instructions are deleted for those blocks.  This will take me a day to 
> > > get correct.
> > > Zdenek's patch is the only code that manipulates the blocks after 
> > > use-def or def-use chains are built.
> > 
> > This analysis seems wrong to me -- the crash occurs when called from
> > estimate_probability, and we do not change CFG in branch prediction.
> 
> The crash occurs from df_set_blocks called from iv_analysis.
> Not sure what you are referring to.
> 
> His analysis of what is going on is completely correct.

"that manipulates the blocks after use-def or def-use chains are built":
the place from that the function is called does not manipulate blocks in
any way, the only thing it does is setting probabilities of edges.

Zdenek

Re: Mainline bootstrap failure (revision 110017)

Hello,

> On Fri, 20 Jan 2006, Kenneth Zadeck wrote:
> > I would like permission to revert Zdenek's patch for a few days.  There
> > is nothing wrong with zdenek's patch, pe se, but it excercises a part of
> > df that should work but does not.
> 
> 
> I'm going to make an executive decision on this one, to restore bootstrap
> immediately.  I agree that Zdenek's patch be reverted for a few days
> without prejudice.  Both patch submitters followed the rules of bootstrap
> and regression test, but a bad (unforetestable) interaction occurred
> between the two.  It turns out that it was the Kenny's DF changes at
> fault, that contain paths that weren't fully tested with his changes
> alone.  Zdenek's patch is innocent, but reliant on this problematic
> functionality.

I propose the following workaround instead, that also restores bootstrap.  It
changes the way loop-iv uses df to more conservative one, that does not
seem to cause problems.

Zdenek

Index: loop-iv.c
===
*** loop-iv.c   (revision 110028)
--- loop-iv.c   (working copy)
*** iv_analysis_loop_init (struct loop *loop
*** 250,263 
current_loop = loop;
  
/* Clear the information from the analysis of the previous loop.  */
!   if (first_time)
! {
!   df = df_init (DF_HARD_REGS | DF_EQUIV_NOTES);
!   df_chain_add_problem (df, DF_UD_CHAIN);
!   bivs = htab_create (10, biv_hash, biv_eq, free);
! }
!   else
! clear_iv_info ();
  
for (i = 0; i < loop->num_nodes; i++)
  {
--- 250,260 
current_loop = loop;
  
/* Clear the information from the analysis of the previous loop.  */
!   if (!first_time)
! iv_analysis_done ();
!   df = df_init (DF_HARD_REGS | DF_EQUIV_NOTES);
!   df_chain_add_problem (df, DF_UD_CHAIN);
!   bivs = htab_create (10, biv_hash, biv_eq, free);
  
for (i = 0; i < loop->num_nodes; i++)
  {

Re: Mainline bootstrap failure (revision 110017)

2006-01-20 Thread Gabriel Dos Reis


[...]

| > > Btw.: of course it may happen that some patch sometimes breaks
| > > bootstrap, it happened to everyone of us.  But, with your patch, not
| > > even libgcc builds.  This means that you did not even try to build gcc
| > > before commiting your patch.
| > 
| > This is simply not true.
| > I in fact, watched him bootstrap and regtest it multiple times.
| > It simply happened that 10 minutes before he committed his patch, you
| > committed yours.

So he updated his tree, saw changes in the middle-end and committed
his without testing.  That completely matches Zdenek's statement.

-- Gaby

Re: Mainline bootstrap failure (revision 110017)

2006-01-20 Thread Eric Botcazou

> So he updated his tree, saw changes in the middle-end and committed
> his without testing.

So Kenny would have had to lauch a new bootstrap, wait for a couple of hours 
only to discover that something again changed in-between, and so on?

-- 
Eric Botcazou

Re: Mainline bootstrap failure (revision 110017)

2006-01-20 Thread Gabriel Dos Reis

Eric Botcazou <[EMAIL PROTECTED]> writes:

| > So he updated his tree, saw changes in the middle-end and committed
| > his without testing.
| 
| So Kenny would have had to lauch a new bootstrap, wait for a couple of hours 
| only to discover that something again changed in-between, and so on?

I don't know whether it would take him hours, since the tree does not
even bootstrap, but most certainly Zdenek's statement was accurate and
our commit procedure wasn't observed.  Now, if you want to change our
commit procedure, that is a different matter.

-- Gaby

Re: Mainline bootstrap failure (revision 110017)

Hello,

> > So he updated his tree, saw changes in the middle-end and committed
> > his without testing.
> 
> So Kenny would have had to lauch a new bootstrap, wait for a couple of hours 
> only to discover that something again changed in-between, and so on?

while the testing procedures for gcc recommend to do full testing before
commiting, especially in case you have reason to believe that something
related has changed, it is not mandatory.

But, it is a good idea to spend a few seconds by checking that gcc at
least builds (or in this particular case, does not).  While this also is
not mandatory, it is a common sense, I guess.

Zdenek

Re: Mainline bootstrap failure (revision 110017)


Eric Botcazou wrote:

So he updated his tree, saw changes in the middle-end and committed
his without testing.



So Kenny would have had to lauch a new bootstrap, wait for a couple of hours 
only to discover that something again changed in-between, and so on?


  
This is exactly what I did, when I got the approval, I did an update, 
launched a bootstrap and regression test, when that passed, I did 
another update and committed.


I am sure that zdenek has access to 1000 teraflop machine to make this 
process almost instantanious.  The rest of us have to make due with 
machies that only run at a few gigahertz.


kenny

Re: Mainline bootstrap failure (revision 110017)

2006-01-20 Thread Eric Botcazou

> I don't know whether it would take him hours, since the tree does not
> even bootstrap, but most certainly Zdenek's statement was accurate and
> our commit procedure wasn't observed.

I'm not sure the commit procedure requires you to retest in that case.

-- 
Eric Botcazou

Re: Mainline bootstrap failure (revision 110017)

2006-01-20 Thread Roger Sayle

On Fri, 20 Jan 2006, Zdenek Dvorak wrote:
> I propose the following workaround instead, that also restores
> bootstrap.  It changes the way loop-iv uses df to more conservative one,
> that does not seem to cause problems.

That's what I like to see... options.  Yes, this is OK for mainline,
please hold off on the reversion (or if necessary reapply with this
change).

Many thanks,

Roger
--

Re: Mainline bootstrap failure (revision 110017)

Hello,

> Eric Botcazou wrote:
> >>So he updated his tree, saw changes in the middle-end and committed
> >>his without testing.
> >>
> >
> >So Kenny would have had to lauch a new bootstrap, wait for a couple of 
> >hours only to discover that something again changed in-between, and so on?
> >
> >  
> This is exactly what I did, when I got the approval, I did an update, 
> launched a bootstrap and regression test, when that passed, I did 
> another update and committed.
> 
> I am sure that zdenek has access to 1000 teraflop machine to make this 
> process almost instantanious.

unfortunately not.  However, I try to at least read the original message
(that said absolutely nothing about doing full bootstrap) before writing
replies that some of the recipients might find insulting.

Zdenek

>The rest of us have to make due with 
> machies that only run at a few gigahertz.

Re: RTL alias analysis

Richard Guenther wrote:

> A patch was also posted based on ideas in the audit trail.  It's third
> incarnation at
> http://gcc.gnu.org/ml/gcc-patches/2006-01/msg00967.html
> would need a review.

This patch uses "type_i == type_j" which is usually a mistake; are we
sure we don't need the usual type-equality predicate functions?

Also, why doesn't:

   union U { char c; int i; };
   struct S { union U u; };
   struct T { union U u; };

present the same problem between S and T?  S and T will fail the type_i
== type_j test, but does that keep us safe?  In general, I think the
patch needs a paragraph-long comment explaining what the problem is and
how this approach solves it.

Thanks,

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

Re: RTL alias analysis

2006-01-20 Thread Steven Bosscher

On Friday 20 January 2006 18:21, Mark Mitchell wrote:
> Richard Guenther wrote:
> > A patch was also posted based on ideas in the audit trail.  It's third
> > incarnation at
> > http://gcc.gnu.org/ml/gcc-patches/2006-01/msg00967.html
> > would need a review.
>
> This patch uses "type_i == type_j" which is usually a mistake; are we
> sure we don't need the usual type-equality predicate functions?

Ah, you noticed that.  So you answered your own question:

> Also, why doesn't:
>
>union U { char c; int i; };
>struct S { union U u; };
>struct T { union U u; };
>
> present the same problem between S and T?

Because type_i != type_j.

Maybe it fails if we use the types_compatible_p langhook, someone
would have to try.

Gr.
Steven

Re: RTL alias analysis

2006-01-20 Thread Richard Guenther

On 1/20/06, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> Richard Guenther wrote:
>
> > A patch was also posted based on ideas in the audit trail.  It's third
> > incarnation at
> > http://gcc.gnu.org/ml/gcc-patches/2006-01/msg00967.html
> > would need a review.
>
> This patch uses "type_i == type_j" which is usually a mistake; are we
> sure we don't need the usual type-equality predicate functions?
>
> Also, why doesn't:
>
>union U { char c; int i; };
>struct S { union U u; };
>struct T { union U u; };
>
> present the same problem between S and T?  S and T will fail the type_i
> == type_j test, but does that keep us safe?  In general, I think the

objects_must_conflict_p (type_i, type_j) doesn't say they must conflict now
and so we put it in a separate partition.  I.e. get_alias_set will
return a different
alias set for S and T.

> patch needs a paragraph-long comment explaining what the problem is and
> how this approach solves it.

Ok, I'll try to come up with an explanation.

Richard.

Re: RTL alias analysis

Steven Bosscher wrote:
> On Friday 20 January 2006 18:21, Mark Mitchell wrote:
> 
>>Richard Guenther wrote:
>>
>>>A patch was also posted based on ideas in the audit trail.  It's third
>>>incarnation at
>>>http://gcc.gnu.org/ml/gcc-patches/2006-01/msg00967.html
>>>would need a review.
>>
>>This patch uses "type_i == type_j" which is usually a mistake; are we
>>sure we don't need the usual type-equality predicate functions?
>  
> Ah, you noticed that.  So you answered your own question:

If so, I'm not smart enough to understand the answer.  Clearly, the
comments on the patch are insufficient for me to understand what it's
doing.  May we please have a version of the patch which a paragraph
explaining what the tests are accomplishing?

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

Re: RTL alias analysis

2006-01-20 Thread Steven Bosscher

On Friday 20 January 2006 18:34, Steven Bosscher wrote:
> On Friday 20 January 2006 18:21, Mark Mitchell wrote:
> > Richard Guenther wrote:
> > > A patch was also posted based on ideas in the audit trail.  It's third
> > > incarnation at
> > > http://gcc.gnu.org/ml/gcc-patches/2006-01/msg00967.html
> > > would need a review.

FWIW, I don't believe this is a "fix", but rather a solid work-around
for the problem.  I'm still trusting rth's superior compiler brain and
GCC knowledge to ultimately be ingredients in a real fix ;-)

Gr.
Steven

Re: RTL alias analysis

Richard Guenther wrote:

>>patch needs a paragraph-long comment explaining what the problem is and
>>how this approach solves it.
> 
> Ok, I'll try to come up with an explanation.

Thanks!

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

Re: RTL alias analysis

2006-01-20 Thread Steven Bosscher

On Friday 20 January 2006 18:38, Mark Mitchell wrote:
> Steven Bosscher wrote:
> > On Friday 20 January 2006 18:21, Mark Mitchell wrote:
> >>Richard Guenther wrote:
> >>>A patch was also posted based on ideas in the audit trail.  It's third
> >>>incarnation at
> >>>http://gcc.gnu.org/ml/gcc-patches/2006-01/msg00967.html
> >>>would need a review.
> >>
> >>This patch uses "type_i == type_j" which is usually a mistake; are we
> >>sure we don't need the usual type-equality predicate functions?
> >
> > Ah, you noticed that.  So you answered your own question:
>
> If so, I'm not smart enough to understand the answer.

The patch just lacks a proper explanation.  Richi left that in the
PR audit trail, but it should be in cfgexpand.c.  Actually the whole
algorithm for the stack slot sharing is poorly explained.  I already
complained about that when rth commited it, but it was never fixed.

> Clearly, the 
> comments on the patch are insufficient for me to understand what it's
> doing.  May we please have a version of the patch which a paragraph
> explaining what the tests are accomplishing?

That code in cfgexpand partitions variables that have to go onto the
stack.  It constructs a conflict graph for these variables.  If two
variables (or rather, the partitions they are in) do not conflict,
they can be allocated in the same stack space.

Initially, all variables are in their own partition, and the stack
slot sharing algorithm uses a union-find algorithm to union partitions
of variables that can live in the same stack space.  If two partitions
conflict, they can't be merged.

Returning to the test case of the PR, we have two variables of the
same union type:

union setconflict
{
  short a[20];
  int b[10];
};

int
foo (void)
{
  int sum = 0;
  {
struct A { union setconflict u; } a;
short *c;
c = a.u.a;
asm ("": "=r" (c):"0" (c));
*c = 2;
asm ("": "=r" (c):"0" (c));
sum += *c;
  }
  {
struct B { union setconflict u; } a;
int *c;
c = a.u.b;
asm ("": "=r" (c):"0" (c));
*c = 1;  // This store is moved before the first "sum += *c;"
asm ("": "=r" (c):"0" (c));
sum += *c;
  }

  return sum;
}

Initially both the variables "a" are in their own partition, but we
unify their partitions so that the two variables are allocated in the
same stack space.  This confuses RTL alias analysis, which only sees
two indirect memory references with different alias sets.  It applies
the strict aliasing rules and decides that it is OK for the scheduler
to move around loads and stores to and from those two variables.

A proper fix would somehow teach RTL alias analysis about this kind
of situation, but that is beyond my hacking skills, and, I'm sure he
would admit, beyond Richi's hacking stills too.  I only went looking
for work-arounds because the few people who understand how RTL alias
analysis works decided to ignore this bug (and pretty much all other
GCC 4.1 regressions...).

The proposed work-around is to avoid confusing RTL alias analysis by
simply not presenting it with situations where two references to the
same memory can have different alias sets.

The next question was: When can we cause this situation, that two
variables are allocated on the stack, and we can access that memory
through indirect references with different (non-conflicting) alias
sets.  Honza, Richi, and I have given this a lot of thought, and we
believe this can _only_ happen for aggregate types if they contain
a union.  If that assumption is wrong, you can stop reading here ;-)

If you look at cfgexpand.c, you'll find add_alias_set_conflicts:

static void
add_alias_set_conflicts (void)
{
  size_t i, j, n = stack_vars_num;

  for (i = 0; i < n; ++i)
{
  tree type_i = TREE_TYPE (stack_vars[i].decl);
  bool aggr_i = AGGREGATE_TYPE_P (type_i);

  for (j = 0; j < i; ++j)
{
  tree type_j = TREE_TYPE (stack_vars[j].decl);
  bool aggr_j = AGGREGATE_TYPE_P (type_j);
  if (aggr_i != aggr_j || !objects_must_conflict_p (type_i, type_j))
add_stack_var_conflict (i, j);
}
}
}

This is _exactly_ supposed to avoid allocating two variables in the
same stack space when we can access that memory through indirect
references with non-conflicting alias sets.  objects_must_conflict_p
is supposed to guard that.  objects_must_conflict_p returns true if
type_i and type_j have conflicting alias sets.  If it returns false,
we have to assume that relying on RTL AA is unsafe, so a conflict is
added to avoid stuffing the variables of type_i and type_j into the
same stack space.
(At least, that's my understanding, but rth should know for sure.)

But if you have two stack variables of the same union type, you get
type_i == type_j.  For equal types, objects_must_conflict_p returns
true.  Therefore, we never add a conflict for variables of the same
type, ever.

Note that this is entirely based on the type of the variable, _not_
on the types of the fields of an aggregate

Re: Contributing to GCC (for avr target).

2006-01-20 Thread Denis Chertykov

"Anatoly Sokolov" <[EMAIL PROTECTED]> writes:

> Hello.
> 
> I am the member of the project 'avr-libc' (AVR C Runtime Library). As
> a result of this work there were patches with additions of support of
> new Atmel devices in gcc the toolchain. I have a desire to add them in
> official GCC sources, unfortunately at avr target at the moment would
> be not present the active maintainer who could make it. I also work
> above other additions and bug fixes for gcc for avr terget.

I'm the maintainer of AVR port and I can review all your patches.

> If for incorporate contributions in gcc it is required to sign
> copyright assignment, I would like them to sign.

Yes, you must sign copyright assignment first.

Denis.

Re: RTL alias analysis

On Fri, Jan 20, 2006 at 06:39:21PM +0100, Steven Bosscher wrote:
> FWIW, I don't believe this is a "fix", but rather a solid work-around
> for the problem.  I'm still trusting rth's superior compiler brain and
> GCC knowledge to ultimately be ingredients in a real fix ;-)

I don't think it's quite solid for a workaround.

And, unfortunately, I can't think of any "good" solution to 
the problem.  The only only way to prevent some of the 
potential problems is to prevent moving memory operations
across block boundaries, which would be a real joy for our
optimizers.

In some cases I'm sure we could see no ill effects by adding
memory barriers strategically, and in others I'm sure we'd
kill performance.

r~

Re: libgomp & solaris

2006-01-20 Thread Andreas Tobler


Richard Henderson wrote:

On Thu, Jan 19, 2006 at 10:45:39PM +0100, Andreas Tobler wrote:
In team.c solaris fails due to the fact that alloca is defined in 
alloca.h iso stdlib.h ...


Er, *not* defined did you mean?  This should probably be fixed
with a #define to __builtin_alloca in libgomp.h or so.


Not clear to me.



config/posix/proc.c fails in a similar manner due 
to the fact that getloadavg is defined in sys/loadavg.h


Easy, more configury near getloadavg detection.


Like this?

#ifdef HAVE_SYS_LOADAVG_H
# include sys/loadavg.h
#endif

or with double guard:

#ifdef HAVE_GETLOADAVG
#ifdef HAVE_SYS_LOADAVG_H
# include sys/loadavg.h
#endif
#endif

The next issue is the -pthread in the config stuff. Solaris does not 
like it :)  -pthreads instead.


Sounds like a typo in the specs for the platform.


Hm, in gcc.c I find a hardcoded -pthread gcc.c:844
Changing it to -pthreads on solaris makes the libgomp test pass except 
the wrong multilib detection etc. Another topic.


/* Adding -fopenmp should imply pthreads.  This is particularly important
   for targets that use different start files and suchlike.  */
#ifndef GOMP_SELF_SPECS
#define GOMP_SELF_SPECS "%{fopenmp: -pthread}"
#endif

Here I do not know how to address this.

I think I submit piece by piece then.

Thanks,
Andreas

Re: RTL alias analysis

2006-01-20 Thread Richard Guenther

On 1/20/06, Richard Henderson <[EMAIL PROTECTED]> wrote:
> On Fri, Jan 20, 2006 at 06:39:21PM +0100, Steven Bosscher wrote:
> > FWIW, I don't believe this is a "fix", but rather a solid work-around
> > for the problem.  I'm still trusting rth's superior compiler brain and
> > GCC knowledge to ultimately be ingredients in a real fix ;-)
>
> I don't think it's quite solid for a workaround.

Can you base this thought on a testcase?  Not that I'm confident
of the workaround - I'm just sure it's a progression from what we have now.

Richard.

Re: RTL alias analysis

Richard Henderson wrote:
> On Fri, Jan 20, 2006 at 06:39:21PM +0100, Steven Bosscher wrote:
> 
>>FWIW, I don't believe this is a "fix", but rather a solid work-around
>>for the problem.  I'm still trusting rth's superior compiler brain and
>>GCC knowledge to ultimately be ingredients in a real fix ;-)
> 
> 
> I don't think it's quite solid for a workaround.

Would you elaborate?  I found myself reasonably convinced by Steven's
explanation.

I guess a secondary question is: is the workaround sufficiently useful
in many of the problematic cases and sufficiently non-harmful in other
cases as to merit inclusion, given that we don't have a better solution?

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

Re: libgomp & solaris

2006-01-20 Thread Andreas Tobler


Andreas Tobler wrote:

Richard Henderson wrote:

On Thu, Jan 19, 2006 at 10:45:39PM +0100, Andreas Tobler wrote:
In team.c solaris fails due to the fact that alloca is defined in 
alloca.h iso stdlib.h ...


Er, *not* defined did you mean?  This should probably be fixed
with a #define to __builtin_alloca in libgomp.h or so.


Not clear to me.


Ok now :)

Andreas

Re: insv vs one-bit fields

On Thu, Jan 19, 2006 at 09:56:54PM -0500, DJ Delorie wrote:
> Nobody has said anything about this for the last two weeks.  Can we
> remove this restriction now?

Have you done any testing on common platforms to see what
happens when you change this?


r~

Re: insv vs one-bit fields

2006-01-20 Thread DJ Delorie


> Have you done any testing on common platforms to see what happens
> when you change this?

It's been in my x86-64 builds for the last few months.  That's the
"gcc" that gets used for everything else.  Are there other platforms
that are likely to have one-bit insv patterns?  (of course, that's the
question nobody answered last time).

Re: libgomp & solaris

On Fri, Jan 20, 2006 at 10:18:18PM +0100, Andreas Tobler wrote:
> or with double guard:
> 
> #ifdef HAVE_GETLOADAVG
> #ifdef HAVE_SYS_LOADAVG_H
> # include sys/loadavg.h
> #endif
> #endif

This, I guess.

> >Sounds like a typo in the specs for the platform.
> 
> Hm, in gcc.c I find a hardcoded -pthread gcc.c:844

I mean in the solaris specs.  We shouldn't have -pthread for
some platforms and -pthreads for others.


r~

Re: insv vs one-bit fields

On Fri, Jan 20, 2006 at 04:44:04PM -0500, DJ Delorie wrote:
> It's been in my x86-64 builds for the last few months.  That's the
> "gcc" that gets used for everything else.  Are there other platforms
> that are likely to have one-bit insv patterns?  (of course, that's the
> question nobody answered last time).

m68k and ia64 spring to mind.  Both have set-one-bit-in-register
type instructions.  But the point isn't that x86-64 continues to
build, but that it's still using the right patterns.

r~

Re: libgomp & solaris

2006-01-20 Thread Andreas Tobler


Richard Henderson wrote:

On Fri, Jan 20, 2006 at 10:18:18PM +0100, Andreas Tobler wrote:

or with double guard:

#ifdef HAVE_GETLOADAVG
#ifdef HAVE_SYS_LOADAVG_H
# include sys/loadavg.h
#endif
#endif


This, I guess.


Ok. Thanks.



Sounds like a typo in the specs for the platform.

Hm, in gcc.c I find a hardcoded -pthread gcc.c:844


I mean in the solaris specs.  We shouldn't have -pthread for
some platforms and -pthreads for others.


Hm, then sol2.h and sol26.h build the minority where we have pthread_s_.
Don't know the history yet.

Andreas

Re: libgomp and OMP_NUM_THREADS

On Fri, Jan 20, 2006 at 03:42:57AM -0500, Jakub Jelinek wrote:
> The mem in the sync insn has alias set 0 and no attributes
> except MEM_VOLATLE_P.  The reason why sched1 decided to move it anyway
> is that it proved that the MEMs are different:

Ah yes.  I'd meant to go back and add a bit or tag to MEM_ATTRS
that forces alias.c to ensure that the mem conflicts with all
other memories.  Similar to how we currently treat MEM with the
address being a SCRATCH.

I guess I forgot about it...

r~

Re: insv vs one-bit fields

2006-01-20 Thread DJ Delorie


> m68k and ia64 spring to mind.  Both have set-one-bit-in-register
> type instructions.  But the point isn't that x86-64 continues to
> build, but that it's still using the right patterns.

If you could suggest a proper testing strategy, I'm willing to test
it.

Re: RTL alias analysis

On Fri, Jan 20, 2006 at 01:26:51PM -0800, Mark Mitchell wrote:
> I guess a secondary question is: is the workaround sufficiently useful
> in many of the problematic cases and sufficiently non-harmful in other
> cases as to merit inclusion, given that we don't have a better solution?

I replied with my suggestion for a workaround in the thread
with the actual patch.


r~

Re: RTL alias analysis

Richard Henderson wrote:
> On Fri, Jan 20, 2006 at 01:26:51PM -0800, Mark Mitchell wrote:
> 
>>I guess a secondary question is: is the workaround sufficiently useful
>>in many of the problematic cases and sufficiently non-harmful in other
>>cases as to merit inclusion, given that we don't have a better solution?
> 
> 
> I replied with my suggestion for a workaround in the thread
> with the actual patch.

Sorry, I missed that.  Do you have a URL?  I'd like to get that in the
PR audit trail.

Thanks,

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

Re: libgomp & solaris

2006-01-20 Thread Eric Botcazou

> Hm, then sol2.h and sol26.h build the minority where we have pthread_s_.
> Don't know the history yet.

That doesn't seem to be a Sun-ism.

-- 
Eric Botcazou

Re: insv vs one-bit fields

On Fri, Jan 20, 2006 at 04:56:38PM -0500, DJ Delorie wrote:
> If you could suggest a proper testing strategy, I'm willing to test it.

Write a small test that is supposed to use one of the set-bit
insns.  Verify that it does before and after the patch.



r~

gcc-4.1-20060120 is now available

2006-01-20 Thread gccadmin

Snapshot gcc-4.1-20060120 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20060120/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 4.1 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_1-branch 
revision 110046

You'll find:

gcc-4.1-20060120.tar.bz2  Complete GCC (includes all of below)

gcc-core-4.1-20060120.tar.bz2 C front end and core compiler

gcc-ada-4.1-20060120.tar.bz2  Ada front end and runtime

gcc-fortran-4.1-20060120.tar.bz2  Fortran front end and runtime

gcc-g++-4.1-20060120.tar.bz2  C++ front end and runtime

gcc-java-4.1-20060120.tar.bz2 Java front end and runtime

gcc-objc-4.1-20060120.tar.bz2 Objective-C front end and runtime

gcc-testsuite-4.1-20060120.tar.bz2The GCC testsuite

Diffs from 4.1-20060113 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.1
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: [HELP] GCC 4.1 branch Ada status on powerpc-darwin?

2006-01-20 Thread Peter O'Gorman


Arnaud Charlet wrote:
LIBGNAT=../rts/libgnat.a 
GCC_LINK="$(CC) -static-libgcc $(ADA_INCLUDES)"

+TOOL_CC=$(CC) -static-libgcc



I'd rather avoid code duplication and reuse GCC_LINK if possible, or
split GCC_LINK in two if needed.


I thought so too, and indeed tried it this way at first, but got:
"../../xgcc -B../../ -static-libgcc -I- -I../rts -I. 
-I/Users/peter/cvsco.build/gcc-4.1/gcc-4_1-branch/gcc/ada" -DIN_GCC


/bin/sh: line 1: ../../xgcc -B../../ -static-libgcc -I- -I../rts -I. 
-I/Users/peter/cvsco.build/gcc-4.1/gcc-4_1-branch/gcc/ada: No such file or 
directory


The quotes around GCC_LINK could be removed here and instead put in the the 
-GCC=$(GCC_LINK) bits, but it seemed easier to have a new var.


Peter

error found in get_ivts_expr() function.

2006-01-20 Thread Uttam Pawar

Hi All,

I found following code snippet in file, trunk/gcc/loop-unroll.c

   1814 /* Locate in EXPR the expression corresponding to the location recorded
   1815in IVTS, and return a pointer to the RTX for this location.  */
   1816
   1817 static rtx *
   1818 get_ivts_expr (rtx expr, struct iv_to_split *ivts)
   1819 {
   1820   unsigned i;
   1821   rtx *ret = &expr;
   1822
   1823   for (i = 0; i < ivts->n_loc; i++)
   1824 ret = &XEXP (*ret, ivts->loc[i]);
   1825
   1826   return ret;
   1827 }

at line 1821, what is the point of taking address of a stack variable? and 
returning it, if the 
'condition' in for loop fails. Is this done intentionally or is it an error?

Thanks,

Uttam

Request for 48 hours of just regression/bug fixes

2006-01-20 Thread Andrew Pinski

I noticed today that there were three projects which were merged into
the mainline within a 24 hour period yesterday.

Date: Thu, 19 Jan 2006 01:42:49 -  IAB  - Daniel Berlin
Date: Thu, 19 Jan 2006 10:24:04 -  Vect - Dorit
Date: Thu, 19 Jan 2006 16:55:54 -  GOMP - Diego Novillo

So I am requesting that we go through a 48 hour period starting Monday
(as the weekends are usually quiet for patch committing) for a stage 3
type regression only/bug fixes.

Right now we have some build regressions on some primary targets and 
there
are about 25 regressions 4.2 (from 4.1) which have been reported 
already.

Two being wrong code and 6 being ICEs on valid code.

Thoughts?

Thanks,
Andrew Pinski

Re: -Wpointer-sign for GCC 4.1

2006-01-20 Thread Joe Buck

On Thu, Jan 19, 2006 at 06:44:28PM -0800, Mark Mitchell wrote:
> Joe Buck wrote:
> 
> > So the answer is that, after consulting with some of the affected people
> > (which is why you got mail, Mike) the SC told RMS that it would be
> > changed.  If it hasn't been done yet, then it's a release blocker,
> > because it was a promise the SC made.
> 
> Since you seem to have a handle on the outcome of the discussion, would
> you please create a Bugzilla entry for this, targeted at 4.1, explaining
> what it is the SC agreed to do?  Otherwise, I'm certain to forget about
> this issue...

It is PR 25892.

Re: Mainline bootstrap failure (revision 110017)


This fixes the problems that became apparent from zdeneks patch.

Bootstrapped and regression tested against the version with zdenek's 
original code (since this directly tickled the failure and bootstrapped 
(and in the process of regression testing) against the current mainline. 
Both on i686-pc-linux-gnu.


Kenny


2005-01-20  Kenneth Zadeck <[EMAIL PROTECTED]>

   * df-scan.c (problem_SCAN): Added NULL reset function.
   (df_scan_reset_blocks): Added code to call reset block function
   (df_bb_refs_delete) Fixed comment.
   (df_insn_refs_delete): Made tolerant of deleting non existent info
   for dataflow problems that need to be reset.
   * df-core.c (df_set_blocks): Ditto.
   * df.h (struct df_problem): Added reset_fun.
   * df-problems.c (problem_RU, problem_RD, problem_LR, problem_UR,
   problem_UREC, problem_CHAIN, problem_RI): Initialized reset_fun field.
   (df_chain_insn_reset, df_chain_bb_reset, df_chain_reset): New
   functions to clear out all references to def-use or use-def chains.


Zdenek Dvorak wrote:

Hello,

  
The attached fixes *that*, but this just causes a crash deeper in trying 
to free some chains.
 
  

[...]
Sorry for the problems and thanks for looking into them.
   


Ken, please reread the email.  The issue is *not* fixed according to
Daniel, there's still another problem.  Could you look into it,
please?

  
I would like permission to revert zdenek's patch for a few days.  There 
is nothing wrong with zdenek's patch, pe se, but it excercises a part of 
df that should work but does not.



I don't quite like this idea; as you yourself say, the problem is not in
that patch (in fact, mainline bootstraps and passes regtesting with it
without your patch); so I think that if we indeed want to go into
reverting patches, it should be the one causing the problem (and I have
a followup patch that I would like to be able to test).

Btw.: of course it may happen that some patch sometimes breaks
bootstrap, it happened to everyone of us.  But, with your patch, not
even libgcc builds.  This means that you did not even try to build gcc
before commiting your patch.  Please do that next time.  In fact,
running at least a partial bootstrap till gengtype is run helped me
avoid introducing bootstrap failures (caused by unexpected interaction
with patches commited since I tested the patch fully the last time)
several times, so it is a good idea even if you are quite sure that no
such problem may occur.

  
We could revert my storage patch, but the problem is much deeper than 
that.  The storage patch only causes this problem to happen when 
bootstrapping.  The problem will still be there and may cause random 
ices when running zdeneks code.


The problem is that when ever you delete any basic blocks, you need to 
get rid of the def use and use def chains that either start or end in 
the deleted block, furthermore,  this has to be done before the 
instructions are deleted for those blocks.  This will take me a day to 
get correct.
Zdenek's patch is the only code that manipulates the blocks after 
use-def or def-use chains are built.



This analysis seems wrong to me -- the crash occurs when called from
estimate_probability, and we do not change CFG in branch prediction.

Zdenek
  


Index: df-scan.c
===
--- df-scan.c	(revision 110059)
+++ df-scan.c	(working copy)
@@ -304,6 +304,7 @@ static struct df_problem problem_SCAN =
   DF_SCAN,/* Problem id.  */
   DF_NONE,/* Direction.  */
   df_scan_alloc,  /* Allocate the problem specific data.  */
+  NULL,   /* Reset global information.  */
   df_scan_free_bb_info,   /* Free basic block info.  */
   NULL,   /* Local compute function.  */
   NULL,   /* Init the solution specific data.  */
@@ -426,6 +427,8 @@ df_rescan_blocks (struct df *df, bitmap 
 
   if (blocks)
 {
+  int i;
+
   /* Need to assure that there are space in all of the tables.  */
   unsigned int insn_num = get_max_uid () + 1;
   insn_num += insn_num / 4;
@@ -443,6 +446,24 @@ df_rescan_blocks (struct df *df, bitmap 
   df->def_info.add_refs_inline = true;
   df->use_info.add_refs_inline = true;
 
+  for (i = df->num_problems_defined; i; i--)
+	{
+	  bitmap blocks_to_reset = NULL;
+	  if (*dflow->problem->reset_fun)
+	{
+	  if (!blocks_to_reset)
+		{
+		  blocks_to_reset = BITMAP_ALLOC (NULL);
+		  bitmap_copy (blocks_to_reset, local_blocks_to_scan);
+		  if (df->blocks_to_scan)
+		bitmap_ior_into (blocks_to_reset, df->blocks_to_scan);
+		}
+	  (*dflow->problem->reset_fun) (dflow, blocks_to_reset);
+	}
+	  if (blocks_to_reset)
+	BITMAP_FREE (blocks_to_reset);
+	}
+
   df_refs_delete (dflow, local_blocks_to_scan);
 
   /* This may be a mistake, but if an explicit blocks is passed in
@@ -727,11 +748,14 @@ df_insn_refs

Re: GCC Error Codes

2006-01-20 Thread Philipp Thomas

On Sun, 15 Jan 2006 10:40:19 -0600, Perry Smith wrote:

> From Andreas's reply, it may not.  In AIX, they want the message to  
>come out in the user's native language so they print out the  
>translated message (that comes from a separate file).

It's the same with gettext. You have a file containing key and value
(i.e. original text and it's translation) for each language, normally
residing under /usr/share/locale//LC_MESSAGE/.mo
. Now in order to retrieve the localized message, the library will
search for a translation matching the message in the program by
searching the relevant message catalog for the current locale.

Philipp

Re: -Wpointer-sign for GCC 4.1