Re: toplevel Makefile.tpl hacking

[François-Xavier Coudert]

> You can use "make check-target-libgfortran", which is what I thought you
> were using to test.

There's no testsuite for libgfortran (the command you mentionned does
not test anything). The only way I'm aware of to run the gfortran
testsuite is "make check-fortran" inside $builddir/gcc. I think I will
soon have a patch ready to fix that last problem.

FX

Build using --with-gmp and shared libraries

[François-Xavier Coudert]

Here is a patch to fix PR libfortran/21547: when building with
--with-gmp=/foo/bar and a shared libgmp in /foo/bar, the
$(RPATH_ENVVAR) variable (usually LD_LIBRARY_PATH) is not set
correctly when using the freshly built gfortran to build libgfortran.
The same thing happens for the gfortran testsuite, and the fix is also
included in this patch.

Basic testing done on i686-linux (built with --languages=c,fortran and
a shared libgmp in /foo/bar, and regtested). Extended testing (which
takes ages on my computer) in progress.

OK for mainline? OK for 4.0?

:ADDPATCH build:
Index: Makefile.tpl
===
--- Makefile.tpl	(revision 106019)
+++ Makefile.tpl	(working copy)
@@ -157,6 +157,7 @@
 	OBJDUMP="$(OBJDUMP)"; export OBJDUMP; \
 	TOPLEVEL_CONFIGURE_ARGUMENTS="$(TOPLEVEL_CONFIGURE_ARGUMENTS)"; export TOPLEVEL_CONFIGURE_ARGUMENTS; \
 	GMPLIBS="$(HOST_GMPLIBS)"; export GMPLIBS; \
+	GMPLIBSDIR="$(HOST_GMPLIBSDIR)"; export GMPLIBSDIR; \
 	GMPINC="$(HOST_GMPINC)"; export GMPINC; \
 @if gcc-bootstrap
 	$(RPATH_ENVVAR)=`echo "$(TARGET_LIB_PATH)$$$(RPATH_ENVVAR)" | sed 's,::*,:,g;s,^:*,,;s,:*$$,,'`; export $(RPATH_ENVVAR); \
@@ -216,6 +217,7 @@
 
 # Where to find GMP
 HOST_GMPLIBS = @gmplibs@
+HOST_GMPLIBSDIR = @gmplibsdir@
 HOST_GMPINC = @gmpinc@
 
 # --
@@ -615,7 +617,7 @@
 
 # Define HOST_LIB_PATH_gcc here, for the sake of TARGET_LIB_PATH, ouch
 @if gcc
-HOST_LIB_PATH_gcc = $$r/$(HOST_SUBDIR)/gcc:$$r/$(HOST_SUBDIR)/prev-gcc:
+HOST_LIB_PATH_gcc = $$r/$(HOST_SUBDIR)/gcc:$$r/$(HOST_SUBDIR)/prev-gcc:$(HOST_GMPLIBSDIR):
 @endif gcc
 
 [+ FOR host_modules +][+ IF lib_path +]
Index: configure.in
===
--- configure.in	(revision 106019)
+++ configure.in	(working copy)
@@ -1058,6 +1058,7 @@
 # Check for GMP and MPFR
 gmplibs=
 gmpinc=
+gmplibsdir=
 have_gmp=yes
 # Specify a location for mpfr
 # check for this first so it ends up on the link line before gmp.
@@ -1075,6 +1076,7 @@
 if test "x$with_mpfr" != x; then
   gmplibs="-L$with_mpfr/lib $gmplibs"
   gmpinc="-I$with_mpfr/include"
+  gmplibsdir="$with_mpfr/lib"
 fi
 
 # Specify a location for gmp
@@ -1097,6 +1099,11 @@
 if test "x$with_gmp" != x; then
   gmplibs="-L$with_gmp/lib $gmplibs"
   gmpinc="-I$with_gmp/include $gmpinc"
+  if test "x$gmplibsdir" != x; then
+gmplibsdir="$gmplibsdir:$with_gmp/lib"
+  else
+gmplibsdir="$with_gmp/lib"
+  fi
 fi
 
 saved_CFLAGS="$CFLAGS"
@@ -1125,6 +1132,7 @@
 # Flags needed for both GMP and/or MPFR
 AC_SUBST(gmplibs)
 AC_SUBST(gmpinc)
+AC_SUBST(gmplibsdir)
 
 # By default, C is the only stage 1 language.
 stage1_languages=c
Index: gcc/configure.ac
===
--- gcc/configure.ac	(revision 106019)
+++ gcc/configure.ac	(working copy)
@@ -3402,6 +3402,8 @@
 
 AC_ARG_VAR(GMPLIBS,[How to link GMP])
 AC_ARG_VAR(GMPINC,[How to find GMP include files])
+AC_ARG_VAR(GMPLIBSDIR,[Where to find the GMP library])
+AC_ARG_VAR(RPATH_ENVVAR,[How the systems locates libraries])
 
 # Configure the subdirectories
 # AC_CONFIG_SUBDIRS($subdirs)
Index: gcc/Makefile.in
===
--- gcc/Makefile.in	(revision 106019)
+++ gcc/Makefile.in	(working copy)
@@ -294,6 +294,8 @@
 # How to find GMP
 GMPLIBS = @GMPLIBS@
 GMPINC = @GMPINC@
+GMPLIBSDIR = @GMPLIBSDIR@
+RPATH_ENVVAR = @RPATH_ENVVAR@
 
 CPPLIB = ../libcpp/libcpp.a
 CPPINC = -I$(srcdir)/../libcpp/include
@@ -3906,6 +3908,7 @@
 	srcdir=`cd ${srcdir}; ${PWD_COMMAND}` ; export srcdir ; \
 	cd $(TESTSUITEDIR); \
 	EXPECT=${EXPECT} ; export EXPECT ; \
+	$(RPATH_ENVVAR)=`echo "$(GMPLIBSDIR):$$$(RPATH_ENVVAR)" | sed 's,::*,:,g;s,^:*,,;s,:*$$,,'` ; export $(RPATH_ENVVAR) ; \
 	if [ -f $${rootme}/../expect/expect ] ; then  \
 	   TCL_LIBRARY=`cd .. ; cd ${srcdir}/../tcl/library ; ${PWD_COMMAND}` ; \
 	export TCL_LIBRARY ; fi ; \



libgmp.ChangeLog
Description: Binary data

RE: diffing directories with merged-as-deleted files?

[Dave Korn]

Phil Edwards wrote:
> On Fri, Nov 04, 2005 at 12:58:11AM +0100, Giovanni Bajo wrote:
>> Joern RENNECKE <[EMAIL PROTECTED]> wrote:
>> 
>>> P.S.: When I use a diff-cmd with -N, I not only get a diff for the 44
>>> files that are different, but also a header for each of the 752 files
>>> that are identical, i.e. two lines for each file like: 
>>> 
>>> Index: gcc/tree-ssa-operands.c
>>> ===
>>> 
>>> cvs would never do such nonsense.


  Ever seen the output from "cvs diff -wBb"?  :)

 
>> Absolutely! It would just print all the directory names in the middle of
>> the diffs. I call that nonsense as well.
> 
> Somewhere I have a tiny awk script to remove all that garbage, ping me if
> I should hunt it up.

  You do know that stuff comes out on stderr and can be piped separately from
the rest of the output that comes on stdout, yeh?

  Or there's always "cvs -q ".

  Either way a script seems overkill - even a tiny one.

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

Re: GCC-generated code and i386 condition codes behavior

[Bryan Ford]

Hi Richard,

On Wednesday 26 October 2005 00:30, Richard Henderson wrote:
> On Mon, Oct 24, 2005 at 03:39:53PM -0500, Bryan Ford wrote:
> > My question: does GCC-generated code ever actually depend on this aspect
> > of the x86 architecture - i.e., on instructions that architecturally
> > change some but not all condition codes _not_ changing those bits that
> > they're not supposed to change?
>
> No.

Excellent - thanks very much for responding!

Bryan

ref_contains_indirect_ref always false?

[Richard Guenther]

Hi!

it seems that

static inline bool
ref_contains_indirect_ref (tree ref)
{
  while (handled_component_p (ref))
{
  if (TREE_CODE (ref) == INDIRECT_REF)
return true;
  ref = TREE_OPERAND (ref, 0);
}
  return false;
}

always returns false, because handled_component_p (ref) returns
false for INDIRECT_REF:

int
handled_component_p (tree t)
{
  switch (TREE_CODE (t))
{
case BIT_FIELD_REF:
case COMPONENT_REF:
case ARRAY_REF:
case ARRAY_RANGE_REF:
case VIEW_CONVERT_EXPR:
case REALPART_EXPR:
case IMAGPART_EXPR:
  return 1;

default:
  return 0;
}
}

am I missing something?

Richard.

Re: Build using --with-gmp and shared libraries

[Albert Chin]

On Fri, Nov 04, 2005 at 10:10:14AM +0100, FranXois-Xavier_Coudert wrote:
> Here is a patch to fix PR libfortran/21547: when building with
> --with-gmp=/foo/bar and a shared libgmp in /foo/bar, the
> $(RPATH_ENVVAR) variable (usually LD_LIBRARY_PATH) is not set
> correctly when using the freshly built gfortran to build libgfortran.
> The same thing happens for the gfortran testsuite, and the fix is also
> included in this patch.

Why wouldn't mpfr have the same problem?

-- 
albert chin ([EMAIL PROTECTED])

Re: Build using --with-gmp and shared libraries

[François-Xavier Coudert]

>> Here is a patch to fix PR libfortran/21547: when building with
>> --with-gmp=/foo/bar and a shared libgmp in /foo/bar, the
>> $(RPATH_ENVVAR) variable (usually LD_LIBRARY_PATH) is not set
>> correctly when using the freshly built gfortran to build libgfortran.
>> The same thing happens for the gfortran testsuite, and the fix is also
>> included in this patch.
>
> Why wouldn't mpfr have the same problem?

Sorry not to mention that. It can (although it usually doesn't,
because the default for libmpfr is to build only a static library),
and this is fix by the same patch. In fact, in the gcc configury, all
occurences of GMPLIBS, GMPINCS always take care of both gmp and mpfr.
I followed this lead, and GMPLIBSDIR points to the directories where
gmp and mpfr are installed, if different. All this is done in the
toplevel configure.

FX

Re: timezone of svn server for -r?

[Vincent Lefevre]

On 2005-11-03 22:58:17 +0100, Andreas Schwab wrote:
> Joern RENNECKE <[EMAIL PROTECTED]> writes:
> 
> > What timezone does the svn server use when I specify time & date with -r?

The date is relative to your local timezone (the one of the client).
The server doesn't use a particular timezone.

> From the subversion book:
> 
> Here are examples of the date formats that Subversion accepts.
> Remember to use quotes around any date that contains spaces.
> $ svn checkout --revision {2002-02-17}
> $ svn checkout --revision {15:30}
> $ svn checkout --revision {15:30:00.20}
> $ svn checkout --revision {"2002-02-17 15:30"}
> $ svn checkout --revision {"2002-02-17 15:30 +0230"}
> $ svn checkout --revision {2002-02-17T15:30}
> $ svn checkout --revision {2002-02-17T15:30Z}
> $ svn checkout --revision {2002-02-17T15:30-04:00}
> $ svn checkout --revision {20020217T1530}
> $ svn checkout --revision {20020217T1530Z}
> $ svn checkout --revision {20020217T1530-0500}
> 
> Use Z or + for the timezone.

Or if you want to always use UTC, you can set the TZ environment
variable to UTC, possibly via a shell alias if you do not want
that globally.

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

Re: svn url shortcuts

[Vincent Lefevre]

On 2005-11-03 18:43:56 -0500, DJ Delorie wrote:
> This is crude, but it lets you use "tag:foo/bar/grill"
> as a repository, and it replaces the "tag:foo" with a matching
> entry in ~/.svnrc like this:
> 
> tag foo svn://gcc.gnu.org/svn/gcc/trunk/whatever
> 
> So, with a .svnrc like this:
> 
> tag trunk svn://gcc.gnu.org/svn/gcc/trunk
> tag 4.0 svn://gcc.gnu.org/svn/gcc/branches/gcc-4_0-branch
> 
> You could just "svn co tag:4.0/gcc/config/i386"
> 
> It probably screams for lots more prettying up, but at least I did
> something about it ;-)
> 
> If you want it shorter, I could rewrite this so that the tag name goes
> before the colon, like "4.0:gcc/config/i386"

This would be better, but then, you should say "prefix" instead of
"tag" (which could be mixed up with tags), and the colon should be
part of the prefix, e.g. in your ~/.subversion/config file:

prefix 4.0: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_0-branch/

(note the trailing slash). So, users could use other prefixes if
they wish, not necessarily with a colon.

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

[PATCH] Re: ref_contains_indirect_ref always false?

[Richard Guenther]

On Fri, 4 Nov 2005, Richard Guenther wrote:

> Hi!
> 
> it seems that
> 
> static inline bool
> ref_contains_indirect_ref (tree ref)
> {
>   while (handled_component_p (ref))
> {
>   if (TREE_CODE (ref) == INDIRECT_REF)
> return true;
>   ref = TREE_OPERAND (ref, 0);
> }
>   return false;
> }
> 
> always returns false, because handled_component_p (ref) returns
> false for INDIRECT_REF.

The following patch "fixes" this by imitating ref_contains_array_ref
semantics.  Bootstrapped on x86_64-unknonw-linux-gnu, regtest in 
progress, ok for mainline if it succeeds?

Thanks,
Richard.


2005-11-04  Richard Guenther  <[EMAIL PROTECTED]>

* tree-flow-inline.h (ref_contains_indirect_ref): Deal
with INDIRECT_REF not in handled_component_p.

Index: tree-flow-inline.h
===
--- tree-flow-inline.h  (revision 106485)
+++ tree-flow-inline.h  (working copy)
@@ -1413,11 +1413,13 @@
 static inline bool
 ref_contains_indirect_ref (tree ref)
 {
+  if (TREE_CODE (ref) == INDIRECT_REF)
+return true;
   while (handled_component_p (ref))
 {
+  ref = TREE_OPERAND (ref, 0);
   if (TREE_CODE (ref) == INDIRECT_REF)
return true;
-  ref = TREE_OPERAND (ref, 0);
 }
   return false;
 }

Re: [PATCH] Re: ref_contains_indirect_ref always false?

[Richard Kenner]

The following patch "fixes" this by imitating ref_contains_array_ref
semantics.  Bootstrapped on x86_64-unknonw-linux-gnu, regtest in 
progress, ok for mainline if it succeeds?

Wouldn't this be simpler:

static inline bool
ref_contains_indirect_ref (tree ref)
{
   while (handled_component_p (ref))
 ref = TREE_OPERAND (ref, 0);

   return TREE_CODE (ref) == INDIRECT_REF;
}

??

Re: [PATCH] Re: ref_contains_indirect_ref always false?

[Diego Novillo]

On Friday 04 November 2005 08:34, Richard Guenther wrote:

>   * tree-flow-inline.h (ref_contains_indirect_ref): Deal
>   with INDIRECT_REF not in handled_component_p.
>
If you handle INDIRECT_REF directly, then you are seemingly changing the 
semantics of the predicate.  The predicate says that it's expecting an 
ARRAY_REF as input.

Point me to the bug you are trying to fix?  There wasn't enough context in 
your message.

Re: [PATCH] Re: ref_contains_indirect_ref always false?

[Richard Kenner]

If you handle INDIRECT_REF directly, then you are seemingly changing the 
semantics of the predicate.  The predicate says that it's expecting an 
ARRAY_REF as input.

The way it's documented, the input *must* be an ARRAY_REF.  If that's
not what's meant, the comment should be changed.  But if the comment is right,
then the behavior is undefined if the input is *not* an ARRAY_REF, so there's
no change to its documented semantics.

Point me to the bug you are trying to fix?  

The bug I see is that the code doesn't agree with its comment ...

Re: [PATCH] Re: ref_contains_indirect_ref always false?

[Richard Guenther]

On Fri, 4 Nov 2005, Richard Kenner wrote:

> The following patch "fixes" this by imitating ref_contains_array_ref
> semantics.  Bootstrapped on x86_64-unknonw-linux-gnu, regtest in 
> progress, ok for mainline if it succeeds?
> 
> Wouldn't this be simpler:
> 
> static inline bool
> ref_contains_indirect_ref (tree ref)
> {
>while (handled_component_p (ref))
>  ref = TREE_OPERAND (ref, 0);
> 
>return TREE_CODE (ref) == INDIRECT_REF;
> }

Yes, this would work, if INDIRECT_REF can be only innermost, i.e. we are
applying the predicate to GIMPLE trees only.

Richard.

Re: [PATCH] Re: ref_contains_indirect_ref always false?

[Richard Guenther]

On Fri, 4 Nov 2005, Diego Novillo wrote:

> On Friday 04 November 2005 08:34, Richard Guenther wrote:
> 
> > * tree-flow-inline.h (ref_contains_indirect_ref): Deal
> > with INDIRECT_REF not in handled_component_p.
> >
> If you handle INDIRECT_REF directly, then you are seemingly changing the 
> semantics of the predicate.  The predicate says that it's expecting an 
> ARRAY_REF as input.
> 
> Point me to the bug you are trying to fix?  There wasn't enough context in 
> your message.

The bug is that as present, ref_contains_indirect_ref returns always 
false, regardless of input.  Because handled_component_p returns false
for TREE_CODE (arg) == INDIRECT_REF.

Richard.

Re: [PATCH] Re: ref_contains_indirect_ref always false?

[Daniel Berlin]

On Fri, 2005-11-04 at 15:45 +0100, Richard Guenther wrote:
> On Fri, 4 Nov 2005, Diego Novillo wrote:
> 
> > On Friday 04 November 2005 08:34, Richard Guenther wrote:
> > 
> > >   * tree-flow-inline.h (ref_contains_indirect_ref): Deal
> > >   with INDIRECT_REF not in handled_component_p.
> > >
> > If you handle INDIRECT_REF directly, then you are seemingly changing the 
> > semantics of the predicate.  The predicate says that it's expecting an 
> > ARRAY_REF as input.
> > 
> > Point me to the bug you are trying to fix?  There wasn't enough context in 
> > your message.
> 
> The bug is that as present, ref_contains_indirect_ref returns always 
> false, regardless of input.  Because handled_component_p returns false
> for TREE_CODE (arg) == INDIRECT_REF.
> 

Can you remove the tree-ssa-structalias use of this predicate at the
same time please?
It's not actually not necessary there (the loop-niter uses are still
needed).

--Dan
> Richard.

Re: [PATCH] Re: ref_contains_indirect_ref always false?

[Diego Novillo]

On Friday 04 November 2005 09:45, Richard Guenther wrote:
> On Fri, 4 Nov 2005, Diego Novillo wrote:
> > On Friday 04 November 2005 08:34, Richard Guenther wrote:
> > >   * tree-flow-inline.h (ref_contains_indirect_ref): Deal
> > >   with INDIRECT_REF not in handled_component_p.
> >
> > If you handle INDIRECT_REF directly, then you are seemingly changing
> > the semantics of the predicate.  The predicate says that it's
> > expecting an ARRAY_REF as input.
> >
> > Point me to the bug you are trying to fix?  There wasn't enough
> > context in your message.
>
> The bug is that as present, ref_contains_indirect_ref returns always
> false, regardless of input.  Because handled_component_p returns false
> for TREE_CODE (arg) == INDIRECT_REF.
>
OK.  In that case, let's use Kenner's version and add

#if defined ENABLE_CHECKING
gcc_assert (handled_component_p (ref))
#endif

at the start of both ref_contains_indirect_ref and ref_contains_array_ref.  
The comment will need fixing, too.  Both predicates are supposed to handle 
aggregates in general.


Thanks.

Re: [PATCH] Re: ref_contains_indirect_ref always false?

[Richard Kenner]

#if defined ENABLE_CHECKING
gcc_assert (handled_component_p (ref))
#endif

If the comment says it has to be an ARRAY_REF, why not just check for that?

Re: diffing directories with merged-as-deleted files?

[Joern RENNECKE]

Daniel Berlin wrote:

 


I did

svn co svn+ssh://gcc.gnu.org/svn/gcc/branches/sh-elf-4_1-branch
cd sh-elf-4_1-branch
svn merge -r106276:106279 svn+ssh://gcc.gnu.org/svn/gcc/trunk .
(rev 106276:106279 contains the change that will remove .cvsignore)

[EMAIL PROTECTED]:/mnt/gccstuff/sh-elf-4_1-branch> svn diff -N
 

It's not the diff against the pristine copy that's the problem, but the 
diff against mainline.


I've renamed the toplevel dir to gcc (for compatibility with my 
symlink-building scripts),

then changed current directory to it.  Then I did:

svn diff --old svn+ssh://[EMAIL PROTECTED]/svn/gcc/trunk/gcc --new gcc 
|less

Re: Build using --with-gmp and shared libraries

[Steve Kargl]

On Fri, Nov 04, 2005 at 01:32:06PM +0100, Fran?ois-Xavier Coudert wrote:
> >> Here is a patch to fix PR libfortran/21547: when building with
> >> --with-gmp=/foo/bar and a shared libgmp in /foo/bar, the
> >> $(RPATH_ENVVAR) variable (usually LD_LIBRARY_PATH) is not set
> >> correctly when using the freshly built gfortran to build libgfortran.
> >> The same thing happens for the gfortran testsuite, and the fix is also
> >> included in this patch.
> >
> > Why wouldn't mpfr have the same problem?
> 
> Sorry not to mention that. It can (although it usually doesn't,
> because the default for libmpfr is to build only a static library),
> and this is fix by the same patch. In fact, in the gcc configury, all
> occurences of GMPLIBS, GMPINCS always take care of both gmp and mpfr.
> I followed this lead, and GMPLIBSDIR points to the directories where
> gmp and mpfr are installed, if different. All this is done in the
> toplevel configure.
> 

The newest version of mpfr will build a shared library.
In fact, we should move to using the newest version,
but I think some/many people would object to having two 
external library dependencies.

-- 
Steve

RE: [PATCH] Re: ref_contains_indirect_ref always false?

[Dave Korn]

Richard Kenner wrote:
> #if defined ENABLE_CHECKING
>   gcc_assert (handled_component_p (ref))
> #endif
> 
> If the comment says it has to be an ARRAY_REF, why not just check for
> that? 


  Given that we're supposed to be passing in an ARRAY_REF and we don't want it
to return true if passed in an INDIRECT_REF, why not just reverse the order of
the two statements in the body of the original while loop?

  Before:
> static inline bool
> ref_contains_indirect_ref (tree ref)
> {
>   while (handled_component_p (ref))
> {
>   if (TREE_CODE (ref) == INDIRECT_REF)
> return true;
>   ref = TREE_OPERAND (ref, 0);
> }
>   return false;
> }

  After:
> static inline bool
> ref_contains_indirect_ref (tree ref)
> {
>   while (handled_component_p (ref))
> {
>   ref = TREE_OPERAND (ref, 0);
>   if (TREE_CODE (ref) == INDIRECT_REF)
> return true;
> }
>   return false;
> }


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

Re: [PATCH] Re: ref_contains_indirect_ref always false?

[Richard Guenther]

On Fri, 4 Nov 2005, Diego Novillo wrote:

> On Friday 04 November 2005 09:45, Richard Guenther wrote:
> > On Fri, 4 Nov 2005, Diego Novillo wrote:
> > > On Friday 04 November 2005 08:34, Richard Guenther wrote:
> > > > * tree-flow-inline.h (ref_contains_indirect_ref): Deal
> > > > with INDIRECT_REF not in handled_component_p.
> > >
> > > If you handle INDIRECT_REF directly, then you are seemingly changing
> > > the semantics of the predicate.  The predicate says that it's
> > > expecting an ARRAY_REF as input.
> > >
> > > Point me to the bug you are trying to fix?  There wasn't enough
> > > context in your message.
> >
> > The bug is that as present, ref_contains_indirect_ref returns always
> > false, regardless of input.  Because handled_component_p returns false
> > for TREE_CODE (arg) == INDIRECT_REF.
> >
> OK.  In that case, let's use Kenner's version and add
> 
> #if defined ENABLE_CHECKING
>   gcc_assert (handled_component_p (ref))
> #endif
> 
> at the start of both ref_contains_indirect_ref and ref_contains_array_ref.  
> The comment will need fixing, too.  Both predicates are supposed to handle 
> aggregates in general.

This is what I'm currently re-checking.

Richard.


2005-11-04  Richard Guenther  <[EMAIL PROTECTED]>

* tree-flow-inline.h (ref_contains_indirect_ref): Make comment
match the code and vice-versa.
(ref_contains_array_ref): Likewise.
* tree-ssa-structalias.c (find_func_aliases): Remove call to
ref_contains_indirect_ref.

Index: tree-flow-inline.h
===
--- tree-flow-inline.h  (revision 106485)
+++ tree-flow-inline.h  (working copy)
@@ -1407,32 +1407,35 @@
   return TREE_READONLY (var) && (TREE_STATIC (var) || DECL_EXTERNAL (var));
 }
 
-/* Return true if REF, an ARRAY_REF, has an INDIRECT_REF somewhere in
-   it.  */
+/* Return true if REF, a handled component reference, has an INDIRECT_REF
+   somewhere in it.  */
 
 static inline bool
 ref_contains_indirect_ref (tree ref)
 {
-  while (handled_component_p (ref))
-{
-  if (TREE_CODE (ref) == INDIRECT_REF)
-   return true;
-  ref = TREE_OPERAND (ref, 0);
-}
-  return false;
+  gcc_assert (handled_component_p (ref));
+
+  do {
+ref = TREE_OPERAND (ref, 0);
+  } while (handled_component_p (ref));
+
+  return TREE_CODE (ref) == INDIRECT_REF;
 }
 
-/* Return true if REF, a COMPONENT_REF, has an ARRAY_REF somewhere in it.  */
+/* Return true if REF, a handled component reference, has an ARRAY_REF
+   somewhere in it.  */
 
 static inline bool
 ref_contains_array_ref (tree ref)
 {
-  while (handled_component_p (ref))
-{
-  if (TREE_CODE (ref) == ARRAY_REF)
-   return true;
-  ref = TREE_OPERAND (ref, 0);
-}
+  gcc_assert (handled_component_p (ref));
+
+  do {
+if (TREE_CODE (ref) == ARRAY_REF)
+  return true;
+ref = TREE_OPERAND (ref, 0);
+  } while (handled_component_p (ref));
+
   return false;
 }
 
Index: tree-ssa-structalias.c
===
--- tree-ssa-structalias.c  (revision 106485)
+++ tree-ssa-structalias.c  (working copy)
@@ -2865,7 +2865,6 @@
 containing pointers, dereferences, and call expressions.  */
  if (POINTER_TYPE_P (TREE_TYPE (lhsop))
  || AGGREGATE_TYPE_P (TREE_TYPE (lhsop))
- || ref_contains_indirect_ref (lhsop)
  || TREE_CODE (rhsop) == CALL_EXPR)
{
  lhs = get_constraint_for (lhsop, NULL);

Re: [PATCH] Re: ref_contains_indirect_ref always false?

[Diego Novillo]

On Friday 04 November 2005 10:07, Richard Kenner wrote:
> #if defined ENABLE_CHECKING
>   gcc_assert (handled_component_p (ref))
> #endif
>
> If the comment says it has to be an ARRAY_REF, why not just check for
> that?

The comment is out of sync with the code.  It's used in code that may be 
sending an arbitrary aggregate.

Given that Dan asked to remove the call from tree-ssa-structalias.c, then 
we can take advantage and tighten the two predicates more.

In ref_contains_indirect_ref:
Rename to array_ref_contains_indirect_ref
Add gcc_assert (TREE_CODE (ref) == ARRAY_REF) at the start.

In ref_contains_array_ref:
Leave the gcc_assert I proposed.  That predicate is used for more than 
COMPONENT_REFs.
The comment needs to be updated.

Re: Build using --with-gmp and shared libraries

[François-Xavier Coudert]

> The newest version of mpfr will build a shared library.
> In fact, we should move to using the newest version,
> but I think some/many people would object to having two
> external library dependencies.

What advantages have the newest version? And (sorry for the obvious
question) why isn't it kept in sync with gmp?

FX

F77 code under gcc

[Alex Tzanov]

Dear developers,


I have recently upgraded my PC to Suse Linux 10 (from 9.3). The
distribution
comes with gcc 4.0.2. The problem that arrised after the upgrade is that
I
cannot compile f77 codes anymore. More precisely when I try to compile a

Fortran file (*.f) I am getting the error:

"gcc: installation problem, cannot exec 'f951': No such file or
directory


This is rather confusing since Novell claims that the provided rpm

has been created with support of F77. Assuming the problem could come from

formated input I tried

-ffree-form

-x f77

but nothing works. Do you have any clue about that? How I can compile F77 code 
or should I

downgrade to gcc 2.95 or 3.0.x?

Thank you

Alexander

--
Alexander Tzanov
Scientific Computing and Visualization
New York University, WWH
251 Mercer Street
phone: 212 998 3159
fax:   212 995 4120
e-mail: [EMAIL PROTECTED]

Re: F77 code under gcc

[Richard Guenther]

On 11/4/05, Alex Tzanov <[EMAIL PROTECTED]> wrote:
> Dear developers,
>
>
> I have recently upgraded my PC to Suse Linux 10 (from 9.3). The
> distribution
> comes with gcc 4.0.2. The problem that arrised after the upgrade is that
> I
> cannot compile f77 codes anymore. More precisely when I try to compile a
>
> Fortran file (*.f) I am getting the error:
>
> "gcc: installation problem, cannot exec 'f951': No such file or
> directory

First of all, you should report installation problems of vendor packages
to the vendor, i.e. SUSE or NOVELL in this case.  Second, this list
is for development _of_ gcc, not with, for such kind of questions please
refer to [EMAIL PROTECTED]

You are probably missing an installed rpm, like gcc-fortran or whatever
it is called.

Thanks,
Richard.

>
>
> This is rather confusing since Novell claims that the provided rpm
>
> has been created with support of F77. Assuming the problem could come from
>
> formated input I tried
>
> -ffree-form
>
> -x f77
>
> but nothing works. Do you have any clue about that? How I can compile F77 
> code or should I
>
> downgrade to gcc 2.95 or 3.0.x?
>
> Thank you
>
> Alexander
>
> --
> Alexander Tzanov
> Scientific Computing and Visualization
> New York University, WWH
> 251 Mercer Street
> phone: 212 998 3159
> fax:   212 995 4120
> e-mail: [EMAIL PROTECTED]
>
>
>
>

Re: diffing directories with merged-as-deleted files?

[Daniel Berlin]

On Fri, 2005-11-04 at 15:05 +, Joern RENNECKE wrote:
> Daniel Berlin wrote:
> 
> >  
> >
> >I did
> >
> >svn co svn+ssh://gcc.gnu.org/svn/gcc/branches/sh-elf-4_1-branch
> >cd sh-elf-4_1-branch
> >svn merge -r106276:106279 svn+ssh://gcc.gnu.org/svn/gcc/trunk .
> >(rev 106276:106279 contains the change that will remove .cvsignore)
> >
> >[EMAIL PROTECTED]:/mnt/gccstuff/sh-elf-4_1-branch> svn diff -N
> >  
> >
> It's not the diff against the pristine copy that's the problem, but the 
> diff against mainline.

Uh, but a diff against the pristine copy is the same as a diff against
mainline at that point, since your only differences come from merging
the mainline.

> I've renamed the toplevel dir to gcc (for compatibility with my 
> symlink-building scripts),
> then changed current directory to it.

>  Then I did:
> 
> svn diff --old svn+ssh://[EMAIL PROTECTED]/svn/gcc/trunk/gcc --new gcc 
> |less
>  

This i can reproduce.
I imagine nobody noticed because, as i've pointed out above, this is a
very roundabout way of doing the same thing regular svn diff will tell
you at that point.
I'm committing a fix now and nominating it for 1.3.x
Thanks!

Re: [PATCH] Re: ref_contains_indirect_ref always false?

[Daniel Berlin]

On Fri, 2005-11-04 at 10:17 -0500, Diego Novillo wrote:
> On Friday 04 November 2005 10:07, Richard Kenner wrote:
> > #if defined ENABLE_CHECKING
> > gcc_assert (handled_component_p (ref))
> > #endif
> >
> > If the comment says it has to be an ARRAY_REF, why not just check for
> > that?
> 
> The comment is out of sync with the code.  It's used in code that may be 
> sending an arbitrary aggregate.
> 
> Given that Dan asked to remove the call from tree-ssa-structalias.c, then 
> we can take advantage and tighten the two predicates more.
> 
> In ref_contains_indirect_ref:
>   Rename to array_ref_contains_indirect_ref
>   Add gcc_assert (TREE_CODE (ref) == ARRAY_REF) at the start.

This would be fine.
The use in tree-ssa-loop-niter.c is really trying to skip out on
inferring loop bounds from pointer to structure accesses in the case of
things like:


struct a
{
  char foo[1];
};


struct a *b = malloc (sizeof (struct a) + 100);
b->foo = "I like candy!"


Since we have to keep this working:)

Thus, it should *always* be handed an ARRAY_REF.

Re: diffing directories with merged-as-deleted files?

[Joern RENNECKE]

Daniel Berlin wrote:

 


Uh, but a diff against the pristine copy is the same as a diff against
mainline at that point, since your only differences come from merging
the mainline.
 


No, the pristine copy is the pristine copy of the branch.  I want to diff
my working copy of the branch against the head of trunk.

 


This i can reproduce.
I imagine nobody noticed because, as i've pointed out above, this is a
very roundabout way of doing the same thing regular svn diff will tell
you at that point.
I'm committing a fix now and nominating it for 1.3.x
 


Thanks!

RE: [PATCH] Re: ref_contains_indirect_ref always false?

[Dave Korn]

Daniel Berlin wrote:

> The use in tree-ssa-loop-niter.c is really trying to skip out on
> inferring loop bounds from pointer to structure accesses in the case of
> things like:
> 
> 
> struct a
> {
>   char foo[1];
> };
> 
> 
> struct a *b = malloc (sizeof (struct a) + 100);
> b->foo = "I like candy!"
> 
> 
> Since we have to keep this working:)


  We do?!  Storing a pointer value to a char variable has never worked very
well so far!

;)


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

RE: [PATCH] Re: ref_contains_indirect_ref always false?

[Daniel Berlin]

On Fri, 2005-11-04 at 16:23 +, Dave Korn wrote:
> Daniel Berlin wrote:
> 
> > The use in tree-ssa-loop-niter.c is really trying to skip out on
> > inferring loop bounds from pointer to structure accesses in the case of
> > things like:
> > 
> > 
> > struct a
> > {
> >   char foo[1];
> > };
> > 
> > 
> > struct a *b = malloc (sizeof (struct a) + 100);
> > b->foo = "I like candy!"
> > 
> > 
> > Since we have to keep this working:)
> 
> 
>   We do?!  Storing a pointer value to a char variable has never worked very
> well so far!

I was shorthanding it, you know what i meant :)

Re: [PATCH] Re: ref_contains_indirect_ref always false?

[Richard Guenther]

On Fri, 4 Nov 2005, Diego Novillo wrote:

> On Friday 04 November 2005 10:07, Richard Kenner wrote:
> > #if defined ENABLE_CHECKING
> > gcc_assert (handled_component_p (ref))
> > #endif
> >
> > If the comment says it has to be an ARRAY_REF, why not just check for
> > that?
> 
> The comment is out of sync with the code.  It's used in code that may be 
> sending an arbitrary aggregate.
> 
> Given that Dan asked to remove the call from tree-ssa-structalias.c, then 
> we can take advantage and tighten the two predicates more.
> 
> In ref_contains_indirect_ref:
>   Rename to array_ref_contains_indirect_ref
>   Add gcc_assert (TREE_CODE (ref) == ARRAY_REF) at the start.
> 
> In ref_contains_array_ref:
>   Leave the gcc_assert I proposed.  That predicate is used for more than 
> COMPONENT_REFs.
>   The comment needs to be updated.

I bootstrapped and regtested the following on x86_64-unknown-linux-gnu.

Ok for mainline?

Thanks,
Richard.


2005-11-04  Richard Guenther  <[EMAIL PROTECTED]>

* tree-flow.h (ref_contains_indirect_ref): Rename to
array_ref_contains_indirect_ref.
* tree-flow-inline.h (ref_contains_indirect_ref): Likewise.
(array_ref_contains_indirect_ref): Make comment match the code
and vice-versa.
(ref_contains_array_ref): Likewise.
* tree-ssa-structalias.c (find_func_aliases): Remove call to
ref_contains_indirect_ref.
* tree-ssa-loop-niter.c (infer_loop_bounds_from_undefined):
Rename calls to ref_contains_indirect_ref.

Index: tree-flow-inline.h
===
--- tree-flow-inline.h  (revision 106485)
+++ tree-flow-inline.h  (working copy)
@@ -1407,32 +1407,34 @@
   return TREE_READONLY (var) && (TREE_STATIC (var) || DECL_EXTERNAL (var));
 }
 
-/* Return true if REF, an ARRAY_REF, has an INDIRECT_REF somewhere in
-   it.  */
+/* Return true if REF, an ARRAY_REF, has an INDIRECT_REF somewhere in it.  */
 
 static inline bool
-ref_contains_indirect_ref (tree ref)
+array_ref_contains_indirect_ref (tree ref)
 {
-  while (handled_component_p (ref))
-{
-  if (TREE_CODE (ref) == INDIRECT_REF)
-   return true;
-  ref = TREE_OPERAND (ref, 0);
-}
-  return false;
+  gcc_assert (TREE_CODE (ref) == ARRAY_REF);
+
+  do {
+ref = TREE_OPERAND (ref, 0);
+  } while (handled_component_p (ref));
+
+  return TREE_CODE (ref) == INDIRECT_REF;
 }
 
-/* Return true if REF, a COMPONENT_REF, has an ARRAY_REF somewhere in it.  */
+/* Return true if REF, a handled component reference, has an ARRAY_REF
+   somewhere in it.  */
 
 static inline bool
 ref_contains_array_ref (tree ref)
 {
-  while (handled_component_p (ref))
-{
-  if (TREE_CODE (ref) == ARRAY_REF)
-   return true;
-  ref = TREE_OPERAND (ref, 0);
-}
+  gcc_assert (handled_component_p (ref));
+
+  do {
+if (TREE_CODE (ref) == ARRAY_REF)
+  return true;
+ref = TREE_OPERAND (ref, 0);
+  } while (handled_component_p (ref));
+
   return false;
 }
 
Index: tree-flow.h
===
--- tree-flow.h (revision 106485)
+++ tree-flow.h (working copy)
@@ -614,7 +614,7 @@
 static inline subvar_t get_subvars_for_var (tree);
 static inline tree get_subvar_at (tree, unsigned HOST_WIDE_INT);
 static inline bool ref_contains_array_ref (tree);
-static inline bool ref_contains_indirect_ref (tree);
+static inline bool array_ref_contains_indirect_ref (tree);
 extern tree okay_component_ref_for_subvars (tree, unsigned HOST_WIDE_INT *,
unsigned HOST_WIDE_INT *);
 static inline bool var_can_have_subvars (tree);
Index: tree-ssa-structalias.c
===
--- tree-ssa-structalias.c  (revision 106485)
+++ tree-ssa-structalias.c  (working copy)
@@ -2865,7 +2865,6 @@
 containing pointers, dereferences, and call expressions.  */
  if (POINTER_TYPE_P (TREE_TYPE (lhsop))
  || AGGREGATE_TYPE_P (TREE_TYPE (lhsop))
- || ref_contains_indirect_ref (lhsop)
  || TREE_CODE (rhsop) == CALL_EXPR)
{
  lhs = get_constraint_for (lhsop, NULL);
Index: tree-ssa-loop-niter.c
===
--- tree-ssa-loop-niter.c   (revision 106485)
+++ tree-ssa-loop-niter.c   (working copy)
@@ -1438,11 +1438,11 @@
/* For each array access, analyze its access function
   and record a bound on the loop iteration domain.  */
if (TREE_CODE (op1) == ARRAY_REF 
-   && !ref_contains_indirect_ref (op1))
+   && !array_ref_contains_indirect_ref (op1))
  estimate_iters_using_array (stmt, op1);
 
if (TREE_CODE (op0) == ARRAY_REF 
-   && !ref_contains_indirect_ref (op0))
+   && !arr

RE: [PATCH] Re: ref_contains_indirect_ref always false?

[Dave Korn]

Daniel Berlin wrote:

[cc list trimmed because it's just one of those silly friday afternoon things]

> On Fri, 2005-11-04 at 16:23 +, Dave Korn wrote:
>> Daniel Berlin wrote:
>> 
>>> The use in tree-ssa-loop-niter.c is really trying to skip out on
>>> inferring loop bounds from pointer to structure accesses in the case of
>>> things like: 
>>> 
>>> 
>>> struct a
>>> {
>>>   char foo[1];
>>> };
>>> 
>>> 
>>> struct a *b = malloc (sizeof (struct a) + 100);
>>> b->foo = "I like candy!"
>>> 
>>> 
>>> Since we have to keep this working:)
>> 
>> 
>>   We do?!  Storing a pointer value to a char variable has never worked
>> very well so far!
> 
> I was shorthanding it, you know what i meant :)


  heh, yeh, I knew.


  But I see so many lines like that in C programs written by people who
_think_ they're writing in C++ [*] 


cheers,
  DaveK

[*] Or BASIC, even more likely!
-- 
Can't think of a witty .sigline today

*-rtems status on head was Re: cross newlib builds on svn head

[Joel Sherrill <[EMAIL PROTECTED]>]

Thanks to Paolo Bonzini's patch, I can get much further and now have 
more to report. :)


The Good

h8300-rtems4.7 - C, C++ build OK (Ada not tried)
i386-rtems4.7 - C, C++, Ada build OK
m68k-rtems4.7 - C, C++, Ada build OK
sh-rtems4.7 - C, C++ build OK (Ada not tried)
sparc-rtems4.7 - C, C++, Ada build OK.

The Bad
===
avr-rtems4.7 - ICE on C
arm-rtems4.7 - ada/rts/raise.c does not compile
mips-rtems4.7 - GNAT bug box at a-calend.adb:480:24
mips64-rtems4.7 - GNAT bug box at a-calend.adb:480:24
powerpc-rtems4.7 - GNAT bug box at a-calend.adb:480:24

The Details
===
arm-rtems4.7 - C, C++ OK.  Ada fails with this:

../../xgcc -B../../  -c -DCROSS_COMPILE -DIN_GCC   `echo -g -O2 
-Dinhibit_libc -fno-inline -fexceptions -DIN_RTS |sed -e 
's/-pedantic//g' -e 's/-Wtraditional//g'`   \
-I. -I.. -I../.. 
-I/home/joel/gcc-work/head/gcc-head-test/gcc/ada 
-I/home/joel/gcc-work/head/gcc-head-test/gcc/ada/../config 
-I/home/joel/gcc-work/head/gcc-head-test/gcc/ada/../../include 
-I/home/joel/gcc-work/head/gcc-head-test/gcc/ada/.. -I./../.. raise.c -o 
raise.o

raise.c: In function 'db':
raise.c:233: error: 'va_list' undeclared (first use in this function)
raise.c:233: error: (Each undeclared identifier is reported only once
raise.c:233: error: for each function it appears in.)
raise.c:233: error: expected ';' before 'msg_args'
raise.c:237: error: 'msg_args' undeclared (first use in this function)
raise.c: In function 'get_region_description_for':
raise.c:595: warning: pointer targets in assignment differ in signedness

I haven't had a chance to investigate why this doesn't compile.

avr-rtems4.7 - C dies with an ICE

./../../../../../gcc-head-test/newlib/libc/misc/init.c: In function 
'__libc_fini_array':
../../../../../../gcc-head-test/newlib/libc/misc/init.c:59: error: 
unable to find a register to spill in class 'BASE_POINTER_REGS'
../../../../../../gcc-head-test/newlib/libc/misc/init.c:59: error: this 
is the insn:
(insn 65 32 33 2 
../../../../../../gcc-head-test/newlib/libc/misc/init.c:56 (set 
(mem/c:HI (plus:HI (reg/f:HI 28 r28)

(const_int 1 [0x1])) [5 S2 A8])
(reg:HI 24 r24)) 12 {*movhi} (nil)
(nil))
../../../../../../gcc-head-test/newlib/libc/misc/init.c:59: internal 
compiler error: in spill_failure, at reload1.c:1890


mips64-rtems4.7, mips-rtems4.7, and powerpc-rtems4.7 all die in Ada at 
the same spot.


../../xgcc -B../../  -c -g -O2  -W -Wall -gnatpg  a-calend.adb -o 
a-calend.o

+===GNAT BUG DETECTED===+
| 4.1.0 20051102 (experimental) (mips-unknown-rtems4.7) GCC error: |
| tree check: expected class   |
| Error detected at a-calend.adb:480:24


Advice, patches always appreciated.

--
Joel Sherrill, Ph.D. Director of Research & Development
[EMAIL PROTECTED] On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available (256) 722-9985

arm-rtems4.7 Ada update

[Joel Sherrill <[EMAIL PROTECTED]>]

I added an include of  to gcc/ada/raise.c and now the 
arm-rtems4.7 target compiles Ada enough to get to the same GNAT bug box 
as powerpc, mips, and mips64 do.  So whatever I tripped appears to

be a cross-CPU Ada issue.

Long term, where should the include of stdarg.h be for raise.c?
I just added it above the function db() around line 230.

--
Joel Sherrill, Ph.D. Director of Research & Development
[EMAIL PROTECTED] On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available (256) 722-9985

Re: [PATCH] Re: ref_contains_indirect_ref always false?

[Diego Novillo]

On Friday 04 November 2005 11:34, Richard Guenther wrote:

>   * tree-flow.h (ref_contains_indirect_ref): Rename to
>   array_ref_contains_indirect_ref.
>   * tree-flow-inline.h (ref_contains_indirect_ref): Likewise.
>   (array_ref_contains_indirect_ref): Make comment match the code
>   and vice-versa.
>   (ref_contains_array_ref): Likewise.
>   * tree-ssa-structalias.c (find_func_aliases): Remove call to
>   ref_contains_indirect_ref.
>   * tree-ssa-loop-niter.c (infer_loop_bounds_from_undefined):
>   Rename calls to ref_contains_indirect_ref.
>
OK.  Thanks.

Re: *-rtems status on head was Re: cross newlib builds on svn head

[Andreas Schwab]

"Joel Sherrill <[EMAIL PROTECTED]>" <[EMAIL PROTECTED]> writes:

> mips64-rtems4.7, mips-rtems4.7, and powerpc-rtems4.7 all die in Ada at 
> the same spot.
>
> ../../xgcc -B../../  -c -g -O2  -W -Wall -gnatpg  a-calend.adb -o 
> a-calend.o
> +===GNAT BUG DETECTED===+
> | 4.1.0 20051102 (experimental) (mips-unknown-rtems4.7) GCC error: |
> | tree check: expected class   |
> | Error detected at a-calend.adb:480:24

This is probably PR22533, workaround:

Index: ipa-utils.c
===
--- ipa-utils.c (revision 106486)
+++ ipa-utils.c (working copy)
@@ -217,6 +217,7 @@ get_base_var (tree t)
 
   while (!SSA_VAR_P (t) 
 && (!CONSTANT_CLASS_P (t))
+&& TREE_CODE (t) != CONSTRUCTOR
 && TREE_CODE (t) != LABEL_DECL
 && TREE_CODE (t) != FUNCTION_DECL
 && TREE_CODE (t) != CONST_DECL)

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Build using --with-gmp and shared libraries

[Steve Kargl]

On Fri, Nov 04, 2005 at 04:21:29PM +0100, Fran?ois-Xavier Coudert wrote:
> > The newest version of mpfr will build a shared library.
> > In fact, we should move to using the newest version,
> > but I think some/many people would object to having two
> > external library dependencies.
> 
> What advantages have the newest version? And (sorry for the obvious
> question) why isn't it kept in sync with gmp?
> 

I don't know the history/reason for the split.  GMP 4.x 
includes essentially mpfr 2.0.1, which was released in
May 2002.  There have been 6 newer releases of mpfr 
since that time.  There are literally hundreds of bug
fixes, new features, and speed improvements.  For 
gfortran, there is a new mpfr_subnormalize function.
This would allow me to replace a homegrown hack that
Tobi and I developed for dealing with subnormal numbers.

For more info on mpfr versions, check
http://www.mpfr.org/download.html

-- 
Steve

Re: Build using --with-gmp and shared libraries

[Janne Blomqvist]

On Fri, Nov 04, 2005 at 09:22:11AM -0800, Steve Kargl wrote:
> On Fri, Nov 04, 2005 at 04:21:29PM +0100, Fran?ois-Xavier Coudert wrote:
> > > The newest version of mpfr will build a shared library.
> > > In fact, we should move to using the newest version,
> > > but I think some/many people would object to having two
> > > external library dependencies.
> > 
> > What advantages have the newest version? And (sorry for the obvious
> > question) why isn't it kept in sync with gmp?
> > 
> 
> I don't know the history/reason for the split.  GMP 4.x 
> includes essentially mpfr 2.0.1, which was released in
> May 2002.  There have been 6 newer releases of mpfr 
> since that time.  There are literally hundreds of bug
> fixes, new features, and speed improvements.  For 
> gfortran, there is a new mpfr_subnormalize function.
> This would allow me to replace a homegrown hack that
> Tobi and I developed for dealing with subnormal numbers.
> 
> For more info on mpfr versions, check
> http://www.mpfr.org/download.html

Would it be possible to replace gmp with mpfr entirely? Or do we use
gmp functionality that isn't found in mpfr?

-- 
Janne Blomqvist

Re: GCC-generated code and i386 condition codes behavior

[Robert Dewar]

My question: does GCC-generated code ever actually depend on this aspect
of the x86 architecture - i.e., on instructions that architecturally
change some but not all condition codes _not_ changing those bits that
they're not supposed to change?


No.


An interesting anecdote from decades ago. When we were working on
the Realia COBOL compiler, and distributing it for the PC, we got
a mysterious message from IBM saying that they had a problem but
could not tell us what it was unless we signed a NDA. We signed,
and it turned out that the CMOS chip (from Harris?) 80C88 used
in the ancient IBM convertible machine had a bug, CVD destroyed
the carry flag, and Realia COBOL was the ONLY software that
was affected. We made a change to the compiler, told no one
(a requirement of the NDA), and everyone was happy :-) although
the generated code was (and probably still is) less efficient :-)

I must say I am a bit surprised that gcc never takes advantage
of the fact that inc and dec do not destroy the carry flag, this
is quite significant for some loops.

Re: Build using --with-gmp and shared libraries

[Vincent Lefevre]

On 2005-11-04 16:21:29 +0100, François-Xavier Coudert wrote:
> > The newest version of mpfr will build a shared library.
> > In fact, we should move to using the newest version,
> > but I think some/many people would object to having two
> > external library dependencies.
> 
> What advantages have the newest version?

http://www.mpfr.org/mpfr-2.2.0/#changes

In any case, don't use the version that comes with GMP.
It is old and *many* bugs have been fixed since. And the
API has changed (it has been stable since version 2.0.2,
AFAIK).

> And (sorry for the obvious question) why isn't it kept in sync
> with gmp?

For several reasons. Mainly because MPFR is still in its early days
(well, perhaps not as of 2.2.0), and thus we have more often bug
fixes and various improvements.

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

Re: Build using --with-gmp and shared libraries

[Tobias . Schlueter]

Quoting Janne Blomqvist <[EMAIL PROTECTED]>:
> Would it be possible to replace gmp with mpfr entirely? Or do we use
> gmp functionality that isn't found in mpfr?

We use mpz_* for our integer handling, so that's not an option, unfortunately.

- Tobi

Re: Build using --with-gmp and shared libraries

[Vincent Lefevre]

On 2005-11-04 19:26:14 +0200, Janne Blomqvist wrote:
> Would it be possible to replace gmp with mpfr entirely?

MPFR is based on GMP. It mainly uses the MPN and MPZ layers.
However the MPF layer isn't used at all. So, you still need
GMP somewhere anyway.

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

Re: GCC-generated code and i386 condition codes behavior

[Andi Kleen]

Robert Dewar <[EMAIL PROTECTED]> writes:
> 
> I must say I am a bit surprised that gcc never takes advantage
> of the fact that inc and dec do not destroy the carry flag, this
> is quite significant for some loops.

A lot of this old wisdom is no longer true.

inc and dec are to be generally avoided these days, because the
partial changing of EFLAGS causes too strict dependencies on Intel P4
cores and threefore slower execution. It's better to use add/sub
$1,... instead, except if you're optimizing for code size.

-Andi

Re: GCC-generated code and i386 condition codes behavior

[Paolo Bonzini]

I must say I am a bit surprised that gcc never takes advantage
of the fact that inc and dec do not destroy the carry flag, this
is quite significant for some loops.


And which is extremely bad on Pentium II and newer.

Paolo, who made the first paid computer work on Realia COBOL

Re: GCC-generated code and i386 condition codes behavior

[Robert Dewar]

Andi Kleen wrote:

Robert Dewar <[EMAIL PROTECTED]> writes:


I must say I am a bit surprised that gcc never takes advantage
of the fact that inc and dec do not destroy the carry flag, this
is quite significant for some loops.



A lot of this old wisdom is no longer true.

inc and dec are to be generally avoided these days, because the
partial changing of EFLAGS causes too strict dependencies on Intel P4
cores and threefore slower execution. It's better to use add/sub
$1,... instead, except if you're optimizing for code size.


actually as Geert points out, probably LEA is the right choice
when you don't want to affect the flags, though in this case
I guess you need some otherway to test for loop termination.
Not clear how you do that without destroying the carry flag.
I will do some benchmarks in this area to see how the old
wisdom holds :-)


-Andi

Unwinding through signal handlers on IA-64/Linux

[Eric Botcazou]

Hi,

It works if the unwind library is HP's libunwind (aka system libunwind) but 
doesn't if the unwind library is the bundled one (config/ia64/unwind-ia64.c).
That's with a 3.4.5pre-based compiler on SLES 9, but the problem is very 
likely present on all branches.

The bottom line is that the CFM register is incorrectly restored: it is loaded 
with the value of the AR.PFS register when the signal is raised.

Breakpoint 3, 0x40003300 in _ada_p ()
(gdb) info reg cfm
cfm0x287647
(gdb) info reg pfs
pfs0xc388   -4611686018427387000
(gdb) continue
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0x40003300 in _ada_p ()
(gdb)
Continuing.

Breakpoint 1, 0x400033f2 in _ada_p ()
(gdb) info reg cfm
cfm0x388904


Debug session with the same executable using HP's libunwind:

Breakpoint 3, 0x40003300 in _ada_p ()
(gdb) info reg cfm
cfm0x287647
(gdb) info reg pfs
pfs0xc388   -4611686018427387000
(gdb) continue
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0x40003300 in _ada_p ()
(gdb)
Continuing.

Breakpoint 1, 0x400033f2 in _ada_p ()
(gdb) info reg cfm
cfm0x287647


Now the unwinder gets it almost right, that is fs->curr.reg[UNW_REG_PFS] holds 
the right values (val = 224, where = UNW_WHERE_SPREL, when = -1).  But there 
are these lines in ia64_handle_unwabi:

  /* pfs_loc already set above.  Without this pfs_loc would point
 incorrectly to sc_cfm instead of sc_ar_pfs.  */
  fs->curr.reg[UNW_REG_PFS].where = UNW_WHERE_NONE;

The problem is that we want pfs_loc to essentially[1] point to sc_cfm, which 
is the saved CFM in the signal context, because we use the target AR.PFS to 
restore the CFM with the help of br.ret; we certainly don't want it to point 
to the saved AR.PFS in the signal context, which is a dead value if a 
register frame has been allocated[2].

These lines look very questionable to me; if they are removed, all works fine 
for the attached testcase (compile with -gnatp).  Maybe some confusion comes 
from

  context->pfs_loc = &(sc->sc_ar_pfs);

a few lines above, which is a dead statement if considered alone.

Can anyone shed some light on this?  Thanks in advance.


[1] essentially because we probably would want pfs_loc to point to a CFM+EC 
value.  But I skimmed through HP's libunwind and I didn't find any attempt to 
put together a full AR.PFS value from saved CFM and EC.

[2] if a register frame has not been allocated then AR.PFS is live in the 
procedure and would need to be restored too.  Incidentally, the current code 
probably works in that case, but I think it cannot happen in practice.

-- 
Eric Botcazou
with Ada.Text_IO;

procedure P is
   type Int_Ptr is access all Integer;
   Data : Int_Ptr := null;
begin
   Data.all := 0;
exception
   when others =>
  Ada.Text_IO.Put_Line ("Exception handled");
end P;

The new gcc_release script hasn't been pushed to production

[Kelley Cook]

Snapshots haven't been created since 10/29.

Looks like the version of gcc_release running on gcc.gnu.org is still 
the old CVS based one.


> gcc_release: Tagging sources as gcc-ss-4_0-20051103
> cvs [export aborted]: no such tag gcc-ss-4_0-20051103
> cvs [rtag aborted]: could not open lock file 
`/cvs/gcc/gcc/,.cvsignore,': Permission denied

> gcc_release: error: Could not tag sources

Re: The new gcc_release script hasn't been pushed to production

[Daniel Berlin]

On Fri, 4 Nov 2005, Kelley Cook wrote:


Snapshots haven't been created since 10/29.


I updated the one gccadmin uses yesterday.
look in /home/gccadmin/scripts



Looks like the version of gcc_release running on gcc.gnu.org is still the old 
CVS based one.



gcc_release: Tagging sources as gcc-ss-4_0-20051103
cvs [export aborted]: no such tag gcc-ss-4_0-20051103
cvs [rtag aborted]: could not open lock file `/cvs/gcc/gcc/,.cvsignore,': 

Permission denied

gcc_release: error: Could not tag sources



Yes, this was a few hours before i updated the script.
I didn't want to rerun it and screw up the dates.

Re: The new gcc_release script hasn't been pushed to production

[Joseph S. Myers]

On Fri, 4 Nov 2005, Daniel Berlin wrote:

> 
> 
> On Fri, 4 Nov 2005, Kelley Cook wrote:
> 
> > Snapshots haven't been created since 10/29.
> 
> I updated the one gccadmin uses yesterday.
> look in /home/gccadmin/scripts

I haven't seen the changes on gcc-patches yet.

-- 
Joseph S. Myers   http://www.srcf.ucam.org/~jsm28/gcc/
[EMAIL PROTECTED] (personal mail)
[EMAIL PROTECTED] (CodeSourcery mail)
[EMAIL PROTECTED] (Bugzilla assignments and CCs)

Re: The new gcc_release script hasn't been pushed to production

[Daniel Berlin]

On Sat, 2005-11-05 at 01:07 +, Joseph S. Myers wrote:
> On Fri, 4 Nov 2005, Daniel Berlin wrote:
> 
> > 
> > 
> > On Fri, 4 Nov 2005, Kelley Cook wrote:
> > 
> > > Snapshots haven't been created since 10/29.
> > 
> > I updated the one gccadmin uses yesterday.
> > look in /home/gccadmin/scripts
> 
> I haven't seen the changes on gcc-patches yet.
> 
They were posted sometime yesterday, and committed in rev 106476 and
106478.

I only tested them for snapshot creation, without the announcement part
running.

I'm sure there is still work they need.