Re: [patch] Store motion rewrite

Hello,

> > !   /* Do not consider MEMs that mention stack pointer; in the following
> > !      we rely on that constant functions do not read memory, which of course
> > !      does not include their arguments if passed on stack.  */
> > !   if (reg_mentioned_p (stack_pointer_rtx, dest))
> >       return;
> 
> Really this needs to be any value whose *base* is the stack
> pointer.  Consider passing a large structure on the stack,
> large enough that we overflow the architecture's immediate
> offset from the sp, so we've generated
> 
> 	(set (reg temp) (plus (reg sp) (const_int high_part))
> 	(set (mem (plus (reg temp) (const_int low_part))) (foo))
> 
> For a target like SH that has very limited immediate offsets,
> this might be a real problem.  You should be able to test this
> using a function of about 20 arguments, I think.

here is the new version.  I was unable to find a simple way how to
check for this -- building du chains or something like that just for
this purpose is overkill.  So I have just altered it the way we expect
even constant functions to read any mem whose base contains any
register.

Zdenek

Index: gcse.c
===================================================================

Re: [PATCH]: HC11 regression, don't rely on REG_WAS_0 notes

On Mon, 31 Mar 2003, Stephane Carrez wrote:

> Hi!
> 
> I was too optimistic in thinking the REG_WAS_0 notes could be used.
> They can in some cases.  But they are not removed in other cases and
> this results in wrong value to be set (reg is incremented/decremented instead
> of loading +1/-1 in it, but since the previous reg value is *not* 0, we get a wrong value).
> 
> I committed this patch on 3_3 and mainline to disable their use.
> 
> 	Stephane
> 
> 2003-03-31  Stephane Carrez  <stcarrez <at> nerim.fr>
> 
> 	* config/m68hc11/m68hc11.c (m68hc11_gen_movhi): Don't rely on REG_WAS_0
> 	notes as they are boggus.
> 	(m68hc11_gen_movqi): Likewise.
> 

That should be "bogus" not "boggus"...

Also, shouldn't we fix the REG_WAS_0 notes instead of avoiding using them?

Toshi

Re: ppc and ia64 bootstrap compare fix, resend

On Mar 31, 2003, Richard Henderson <rth <at> redhat.com> wrote:

>         * real.c (real_identical): Reorg so as to not compare
>         signalling for normals.

My spell checker says it's signaling, not signalling.  Is it wrong?
If not, mind if I fix the typo here and in the code?

--

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva <at> {redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva <at> {lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: irix6.5 bootstrap failure in libstdc++-v3/src/locale-inst.cc

Here is a patch that should fix this the right way:

2003-03-31  Andrew Pinski  <pinskia <at> physics.uc.edu>

	* config-lang.in (gtfiles): add \$(srcdir)/cp/name-lookup.c after 
\$(srcdir)/cp/name-lookup.h
	* name-lookup.c: include gt-cp-name-lookup.h at the end of the file

Thanks,
Andrew Pinski

Index: config-lang.in
===================================================================
RCS file: /cvs/gcc/gcc/gcc/cp/config-lang.in,v
retrieving revision 1.17
diff -u -d -b -w -u -r1.17 config-lang.in
--- config-lang.in	30 Mar 2003 13:18:17 -0000	1.17
+++ config-lang.in	1 Apr 2003 00:19:10 -0000
 <at>  <at>  -34,4 +34,4  <at>  <at> 

  target_libs="target-libstdc++-v3 target-gperf"

-gtfiles="\$(srcdir)/cp/name-lookup.h \$(srcdir)/cp/cp-tree.h  
\$(srcdir)/cp/decl.h \$(srcdir)/cp/lex.h \$(srcdir)/cp/call.c  
\$(srcdir)/cp/decl.c \$(srcdir)/cp/decl2.c \$(srcdir)/cp/pt.c  
\$(srcdir)/cp/repo.c \$(srcdir)/cp/semantics.c \$(srcdir)/cp/tree.c  

Re: irix6.5 bootstrap failure in libstdc++-v3/src/locale-inst.cc

I forgot to do the Makefile part of it sorry.

all in cp/
2003-03-31  Andrew Pinski  <pinskia <at> physics.uc.edu>

	* config-lang.in (gtfiles): add \$(srcdir)/cp/name-lookup.c after 
\$(srcdir)/cp/name-lookup.h
	* name-lookup.c: include gt-cp-name-lookup.h at the end of the file
	* Makefile: (gt-cp-name-lookup.h): is generated by the gtype
	(cp/name-lookup.o): depends on gt-cp-name-lookup.h

Thanks,
Andrew Pinski

On Monday, Mar 31, 2003, at 19:23 US/Eastern, Andrew Pinski wrote:

> Here is a patch that should fix this the right way:
>
> 2003-03-31  Andrew Pinski  <pinskia <at> physics.uc.edu>
>
> 	* config-lang.in (gtfiles): add \$(srcdir)/cp/name-lookup.c after  
> \$(srcdir)/cp/name-lookup.h
> 	* name-lookup.c: include gt-cp-name-lookup.h at the end of the file
>
> Thanks,
> Andrew Pinski

Re: ppc and ia64 bootstrap compare fix, resend

On Mon, 2003-03-31 at 16:20, Alexandre Oliva wrote:
> On Mar 31, 2003, Richard Henderson <rth <at> redhat.com> wrote:
> 
> >         * real.c (real_identical): Reorg so as to not compare
> >         signalling for normals.
> 
> My spell checker says it's signaling, not signalling.  Is it wrong?

According to www.m-w.com both are correct.

-eric

--

-- 
o/~ got caught stealing fire from the sky o/~

Re: irix6.5 bootstrap failure in libstdc++-v3/src/locale-inst.cc

Wrote the ChangeLog wrong a little:

On Monday, Mar 31, 2003, at 19:35 US/Eastern, Andrew Pinski wrote:
> 	* Makefile: (gt-cp-name-lookup.h): is generated by the gtype
> 	(cp/name-lookup.o): depends on gt-cp-name-lookup.h
>

`Makefile' should be `Make-lang.in'

Thanks,
Andrew Pinski

[PATH] Fix c++ bootstrap problem really.

I forgot to one thing, sorry.

all in cp/
2003-03-31  Andrew Pinski  <pinskia <at> physics.uc.edu>

	* config-lang.in (gtfiles): add \$(srcdir)/cp/name-lookup.c after 
\$(srcdir)/cp/name-lookup.h
	* name-lookup.c: (cxx_binding_make): Use ggc_alloc_cleared instead of 
ggc_alloc.
	Include gt-cp-name-lookup.h at the end of the file
	* Make-lang.in: (gt-cp-name-lookup.h): is generated by the gtype
	(cp/name-lookup.o): depends on gt-cp-name-lookup.h

Thanks,
Andrew Pinski

[tree-ssa] flowgraph linearization [patch]

Adds one more pass to flowgraph cleanup to linearize useless
control structures.  It handles 'if (1)' and 'if (0)'.  It could
be made to handle 'switch (constant)' but checking that a switch
body is not accessible from the outside is not as quick as an
if().

This reduces the amount of RTL emitted when converting trees to
RTL.  Not by a whole lot in the case of GCC's core files, but
there are some gains.  The total compile time also decreased by a
negligible amount (despite the additional work we do).

The patch also removes -Wtraditional from Makefile.in so that we
can start using C89 in the branch.

Bootstrapped and tested x86, ppc and x86-64.

Diego.

	* Makefile.in (STRICT_WARN, STRICT2_WARN): Remove -Wtraditional.
	* timevar.def (TV_TREE_CLEANUP_CFG): Define.
	* tree-cfg.c (set_parent_stmt): Add documentation.
	(replace_stmt): New function.
	(merge_tree_blocks): New function.
	(remap_stmts): New function.
	(linearize_cond_expr): New function.
	(linearize_control_structures): New function.
	(cleanup_tree_cfg): Call it.
	Use new timevar TV_TREE_CLEANUP_CFG.
	(remove_bb): Update debugging message.
	Make sure that bb->head_tree_p and bb->end_tree_p exist before

[RFC] C++ vs forced unwinding

To refresh your memory, forced unwinding is a not-an-exception 
that runs only cleanups, but can't be caught.  It's intended to
be used by e.g. longjmp_unwind and pthread cancellation.

The code for this was never completed, as is clear from the todo
comments left about in except.c.  Now that glibc *really* wants
to use this, I've been prompted to finish the job.

There are a couple of points that I didn't expect:

First, some Standard C functions suddenly can throw exceptions,
of a kind.  Posix specifies a list of entry points that are
primary and secondary thread cancellation points.

Second, functions declared throw() will still propagate forced
unwind exceptions.  If we don't represent this, the cleanups get
deleted as unreachable.

Both of these points mean extra overhead for applications that
don't need forced unwinding, so I've conditionalized everything
under a new flag -fforced-unwind-exceptions.  I was thinking that
we could have -pthread imply this, since in theory folks are
supposed to use that for their threaded applications.

Third, presumably we need a way to indicate that a function
does not transitively call a function which is a cancellation
point.  Presumably this would be a new attribute.  Something
else to think about here is that forced unwinding does not only
apply to thread cancellation -- a user could use longjmp_unwind
for whatever purpose they wanted.  This last has prompted me to