Re: [google] Build libstdc++ exception throwing code with frame pointers (issue4348050)

[Diego Novillo]

On Mon, Apr 4, 2011 at 23:05, Paul Pluzhnikov  wrote:

> 2011-04-04  Paul Pluzhnikov  
>
>        * libstdc++-v3/src/Makefile.am  (revision 171950): Add
>        -fno-omit-frame-pointer to functexcept.
>        * libstdc++-v3/libsupc++/Makefile.am    (revision 171950): Add
>        -fno-omit-frame-pointer to eh_throw and eh_terminate.
>        * libstdc++-v3/src/Makefile.in  (revision 171950): Regenerate.
>        * libstdc++-v3/libsupc++/Makefile.in    (revision 171950): Regenerate.

Remove the '(revision 171950)' strings.


>
> Index: libstdc++-v3/src/Makefile.am
> ===
> --- libstdc++-v3/src/Makefile.am        (revision 171950)
> +++ libstdc++-v3/src/Makefile.am        (working copy)
> @@ -395,7 +395,8 @@
>        $(XTEMPLATE_FLAGS) \
>        $(WARN_CXXFLAGS) \
>        $(OPTIMIZE_CXXFLAGS) \
> -       $(CONFIG_CXXFLAGS)
> +       $(CONFIG_CXXFLAGS) \
> +       $($(@)_no_omit_frame_pointer)
>
>
>  # libstdc++ libtool notes
> @@ -469,3 +470,6 @@
>  install_debug:
>        (cd ${debugdir} && $(MAKE) \
>        toolexeclibdir=$(glibcxx_toolexeclibdir)/debug install)
> +
> +# Google-specific pessimization
> +functexcept.lo_no_omit_frame_pointer = -fno-omit-frame-pointer

Does this mean that this is not intended to go to trunk ever?  If so,
it may make more sense to put this in google/integration instead of
google/main.


Diego.

Re: [google] Enable lightweight debug checks (issue4344067)

[Diego Novillo]

On Tue, Apr 5, 2011 at 01:26, Paul Pluzhnikov  wrote:
> This patch adds lightweight debug checks (if enabled by macros).
>
> To be applied only to google/main branch.
>
> Tested by buildit --run-tests.
>
>
>
> 2011-04-04  Paul Pluzhnikov  
>
>        * libstdc++-v3/include/ext/vstring.h    (revision 171950): Enable
>        debug checks when __google_stl_debug_string is 1.
>        * libstdc++-v3/include/ext/sso_string_base.h    (revision 171950):
>        Scribble on logically-dangling storage when
>        __google_stl_debug_string_dangling is 1.
>        * libstdc++-v3/include/bits/stl_vector.h        (revision 171950):
>        Enable debug checks when __google_stl_debug_vector is 1.
>        * 
> libstdc++-v3/testsuite/23_containers/vector/requirements/dr438/assign_neg.cc  
> (revision 171950):
>        Adjust line number.
>        * 
> libstdc++-v3/testsuite/23_containers/vector/requirements/dr438/insert_neg.cc  
> (revision 171950):
>        Likewise.
>        * 
> libstdc++-v3/testsuite/23_containers/vector/requirements/dr438/constructor_1_neg.cc
>    (revision 171950):
>        Likewise.
>        * 
> libstdc++-v3/testsuite/23_containers/vector/requirements/dr438/constructor_2_neg.cc
>    (revision 171950):
>        Likewise.

Remove the '(revision 171950)' strings.  That's an mklog lameness :)

OK with those changes.


Diego.

Re: [patch ada]: Last fix for PR ada/47163 on windows native hosts

[Arnaud Charlet]

> as described in PR, there is a failure to copy adainclude/adalib
> libraries in MSYS.

The PR does not give any details as to what exact error message you are
getting, at which step, and what Makefile rule/line is causing this behavior.

I'm surprised by LN_S is used to link directories,this looks unexpected to
me at first sight, and first needs to be investigateed/clarified before
deciding on a proper fix.

Arno

Re: [PATCH, Fortran] Correct declaration of frexp and friends

[Duncan Sands]

Hi Tobias,


Pong. It helps to send Fortran patches also to fortran@ ...


indeed :)


On 30/03/11 16:43, Duncan Sands wrote:

While working on the dragonegg plugin I noticed that the Fortran front-end
declares frexp with the parameters the wrong way round. Instead of
double frexp(double x, int *exp);
it is declared as
double frexp(int *exp, double x);



OK to apply on mainline and the 4.5 and 4.6 branches?


OK and thanks for the patch. Do you have an GCC SVN account?


I do, so that's not a problem.  By the way I just noticed that the arguments to
the scalbn functions also seem to be the wrong way round:

  gfc_define_builtin ("__builtin_scalbnl", mfunc_longdouble[5],
  BUILT_IN_SCALBNL, "scalbnl", 
ATTR_CONST_NOTHROW_LEAF_LIST);
  gfc_define_builtin ("__builtin_scalbn", mfunc_double[5],
  BUILT_IN_SCALBN, "scalbn", ATTR_CONST_NOTHROW_LEAF_LIST);
  gfc_define_builtin ("__builtin_scalbnf", mfunc_float[5],
  BUILT_IN_SCALBNF, "scalbnf", 
ATTR_CONST_NOTHROW_LEAF_LIST);

but

  /* type (*) (int, type) */
  fntype[5] = build_function_type_list (type,
integer_type_node, type, NULL_TREE);

so it looks like you get scalbn(int, double) and not scalbn(double, int) etc.
If you agree that they are the wrong way round I will fix this too.

Ciao, Duncan.



Tobias


2011-03-30 Duncan Sands 

* f95-lang.c (build_builtin_fntypes): Swap frexp parameter types.

- /* type (*) (&int, type) */
- fntype[4] = build_function_type_list (type,
+ /* type (*) (type, &int) */
+ fntype[4] = build_function_type_list (type, type,
build_pointer_type (integer_type_node),
- type,
NULL_TREE);

Re: [patch ada]: Last fix for PR ada/47163 on windows native hosts

[Kai Tietz]

2011/4/5 Arnaud Charlet :
>> as described in PR, there is a failure to copy adainclude/adalib
>> libraries in MSYS.
>
> The PR does not give any details as to what exact error message you are
> getting, at which step, and what Makefile rule/line is causing this behavior.
>
> I'm surprised by LN_S is used to link directories,this looks unexpected to
> me at first sight, and first needs to be investigateed/clarified before
> deciding on a proper fix.
>
> Arno
>

Hmm, AFAICS is in Mafile.in the following line present:

# Copy target independent sources
$(foreach f,$(ADA_INCLUDE_SRCS) $(LIBGNAT_SRCS), \
  $(LN_S) $(fsrcpfx)ada/$(f) $(RTSDIR) ;) true

which seems to me the cause for this patch.

Kai

Re: [PATCH] Fix VTA updating in the combiner (PR debug/48343)

[Jakub Jelinek]

On Mon, Apr 04, 2011 at 09:55:12AM +0200, Jakub Jelinek wrote:
> So something like this?

Now bootstrapped/regtested on x86_64-linux and i686-linux, ok?

> 2011-04-04  Jakub Jelinek  
> 
>   PR debug/48343
>   * combine.c (combine_instructions): Add last_combined_insn,
>   update it if insn is after it, pass it to all try_combine
>   calls.
>   (try_combine): Add last_combined_insn parameter, pass it instead of
>   i3 to propagate_for_debug.
> 
>   * gcc.dg/torture/pr48343.c: New test.

Jakub

Re: [patch ada]: Last fix for PR ada/47163 on windows native hosts

[Arnaud Charlet]

> Hmm, AFAICS is in Mafile.in the following line present:
> 
> # Copy target independent sources
> $(foreach f,$(ADA_INCLUDE_SRCS) $(LIBGNAT_SRCS), \
>   $(LN_S) $(fsrcpfx)ada/$(f) $(RTSDIR) ;) true
> 
> which seems to me the cause for this patch.

The above loop will link/copy files only, not directories, so your patch
should have no effect and is incorrect.

Either there's a bug in cp -p in msys, or the problem is elsewhere, and
I'd like to understand where, since I cannot guess with the info in the PR,
nor with my knowledge of the GNAT Makefiles.

Arno

[lto, testsuite] Don't use visibility on targets that don't support it (PR lto/47334)

[Rainer Orth]

As described in the PR, it seems to make more sense to avoid to use the
visibility attribute on targets that don't support it rather than using
it unconditionally and later (and incompletely) prune the resulting
warning.

The following patch does exactly that.  It now needs to document the
explicit visibility requirement in gcc.dg/lto/20081222_0.c (the main
file of the testcase, rather than in 20081222_1.c that uses it) so the
whole testcase is skipped.

Bootstrapped on mainline without regressions on i386-pc-solaris2.8 with
Sun as which doesn't support the visibility attribute.

Ok for mainline and the 4.6 branch after testing?

Thanks.
Rainer


2011-03-27  Rainer Orth  

gcc/lto:
PR lto/47334)
* lto.c (promote_var): Only set VISIBILITY_HIDDEN if
HAVE_GAS_HIDDEN.
(promote_fn): Likewise.

gcc/testsuite:
PR lto/47334)
* lib/lto.exp (lto_prune_warns): Don't prune visibility warning.
* gcc.dg/lto/20081222_0.c: Add dg-require-visibility.

diff --git a/gcc/lto/lto.c b/gcc/lto/lto.c
--- a/gcc/lto/lto.c
+++ b/gcc/lto/lto.c
@@ -1,5 +1,5 @@
 /* Top-level LTO routines.
-   Copyright 2009, 2010 Free Software Foundation, Inc.
+   Copyright 2009, 2010, 2011 Free Software Foundation, Inc.
Contributed by CodeSourcery, Inc.
 
 This file is part of GCC.
@@ -1271,11 +1271,13 @@ promote_var (struct varpool_node *vnode)
 return false;
   gcc_assert (flag_wpa);
   TREE_PUBLIC (vnode->decl) = 1;
+#ifdef HAVE_GAS_HIDDEN
   DECL_VISIBILITY (vnode->decl) = VISIBILITY_HIDDEN;
   DECL_VISIBILITY_SPECIFIED (vnode->decl) = true;
   if (cgraph_dump_file)
 fprintf (cgraph_dump_file,
"Promoting var as hidden: %s\n", varpool_node_name (vnode));
+#endif
   return true;
 }
 
@@ -1288,8 +1290,10 @@ promote_fn (struct cgraph_node *node)
   if (TREE_PUBLIC (node->decl) || DECL_EXTERNAL (node->decl))
 return false;
   TREE_PUBLIC (node->decl) = 1;
+#ifdef HAVE_GAS_HIDDEN
   DECL_VISIBILITY (node->decl) = VISIBILITY_HIDDEN;
   DECL_VISIBILITY_SPECIFIED (node->decl) = true;
+#endif
   if (node->same_body)
 {
   struct cgraph_node *alias;
@@ -1297,14 +1301,18 @@ promote_fn (struct cgraph_node *node)
   alias; alias = alias->next)
{
  TREE_PUBLIC (alias->decl) = 1;
+#ifdef HAVE_GAS_HIDDEN
  DECL_VISIBILITY (alias->decl) = VISIBILITY_HIDDEN;
  DECL_VISIBILITY_SPECIFIED (alias->decl) = true;
+#endif
}
 }
+#ifdef HAVE_GAS_HIDDEN
   if (cgraph_dump_file)
 fprintf (cgraph_dump_file,
 "Promoting function as hidden: %s/%i\n",
 cgraph_node_name (node), node->uid);
+#endif
   return true;
 }
 
diff --git a/gcc/testsuite/gcc.dg/lto/20081222_0.c 
b/gcc/testsuite/gcc.dg/lto/20081222_0.c
--- a/gcc/testsuite/gcc.dg/lto/20081222_0.c
+++ b/gcc/testsuite/gcc.dg/lto/20081222_0.c
@@ -1,4 +1,6 @@
 /* { dg-require-alias "" } */
+/* { dg-require-visibility "" } */
+
 #include "20081222_0.h"
 
 extern void abort (void);
diff --git a/gcc/testsuite/lib/lto.exp b/gcc/testsuite/lib/lto.exp
--- a/gcc/testsuite/lib/lto.exp
+++ b/gcc/testsuite/lib/lto.exp
@@ -1,4 +1,4 @@
-# Copyright (C) 2009, 2010 Free Software Foundation, Inc.
+# Copyright (C) 2009, 2010, 2011 Free Software Foundation, Inc.
 
 # This program is free software; you can redistribute it and/or modify
 # it under the terms of the GNU General Public License as published by
@@ -22,14 +22,6 @@ proc lto_prune_warns { text } {
 
 verbose "lto_prune_warns: entry: $text" 2
 
-# Many tests that use visibility will still pass on platforms that don't 
support it.
-regsub -all "(^|\n)\[^\n\]*: warning: visibility attribute not supported 
in this configuration; ignored\[^\n\]*" $text "" text
-
-# And any stray location lines.
-regsub -all "(^|\n)\[^\n\]*: In function \[^\n\]*" $text "" text
-regsub -all "(^|\n)In file included from \[^\n\]*" $text "" text
-regsub -all "(^|\n)\[ \t\]*from \[^\n\]*" $text "" text
-
 # Sun ld warns about common symbols with differing sizes.  Unlike GNU ld
 # --warn-common (off by default), they cannot be disabled.
 regsub -all "(^|\n)ld: warning: symbol \[`'\]\[^\n\]*' has differing 
sizes:" $text "" text


-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: [Ping #2][Patch, testsuite]: Don't xfail sibcalls on AVR

[Georg-Johann Lay]

Georg-Johann Lay schrieb:
> Target avr now supports tail calls, so don't xfail on that.
> 
> testsuite/
> 
> 2011-03-29  Georg-Johann Lay  
> 
>   * gcc.dg/sibcall-3.c: Don't xfail on AVR.
>   * gcc.dg/sibcall-4.c: Don't xfail on AVR.
> 
> 

Re: [patch ada]: Last fix for PR ada/47163 on windows native hosts

[Kai Tietz]

2011/4/5 Arnaud Charlet :
>> Hmm, AFAICS is in Mafile.in the following line present:
>>
>> # Copy target independent sources
>>         $(foreach f,$(ADA_INCLUDE_SRCS) $(LIBGNAT_SRCS), \
>>           $(LN_S) $(fsrcpfx)ada/$(f) $(RTSDIR) ;) true
>>
>> which seems to me the cause for this patch.
>
> The above loop will link/copy files only, not directories, so your patch
> should have no effect and is incorrect.
>
> Either there's a bug in cp -p in msys, or the problem is elsewhere, and
> I'd like to understand where, since I cannot guess with the info in the PR,
> nor with my knowledge of the GNAT Makefiles.
>
> Arno
>

Well, there is a bug AFAICS. Issue is that 'ln -s file dir' fails, but
'ln -s file file1' works. See for this thread
http://lists.zerezo.com/mingw-users/msg03642.html, where this is
described. So it might be also a valid fix here to append to directory
the $f again.

Kai

Re: [patch ada]: Last fix for PR ada/47163 on windows native hosts

[Arnaud Charlet]

> Well, there is a bug AFAICS. Issue is that 'ln -s file dir' fails, but
> 'ln -s file file1' works. See for this thread
> http://lists.zerezo.com/mingw-users/msg03642.html, where this is
> described. So it might be also a valid fix here to append to directory
> the $f again.

OK, so it's indeed a bug in msys which should be fixed there IMO if it
does not support 'cp -p file dir'

Adding $f may cause command line limitations on some platforms, so I'd rather
avoid that.

Arno

Re: [PATCH, Fortran] Correct declaration of frexp and friends

[Duncan Sands]

Hi Tobias,


I do, so that's not a problem. By the way I just noticed that the arguments to
the scalbn functions also seem to be the wrong way round:


here's a gcc-4.5 patch which fixes: (1) the comment for fntype[2], (2) the
prototypes for the frexp family and (3) the prototypes for the scalbn family.
I checked all uses of all of the function types declared here and all the rest
seem to be correct.  I also took a look at an example using scalbn and it looks
like calls to scalbn pass arguments in the right order (i.e. consistent with the
fixed prototype).  I'm running the testsuite now.  OK to apply to the 4.5 branch
if it passes testing?

Index: f95-lang.c
===
--- f95-lang.c  (revision 171972)
+++ f95-lang.c  (working copy)
@@ -646,19 +646,20 @@
   /* type (*) (type, type) */
   tmp = tree_cons (NULL_TREE, type, tmp);
   fntype[1] = build_function_type (type, tmp);
-  /* type (*) (int, type) */
+  /* type (*) (type, int) */
   tmp = tree_cons (NULL_TREE, integer_type_node, void_list_node);
   tmp = tree_cons (NULL_TREE, type, tmp);
   fntype[2] = build_function_type (type, tmp);
   /* type (*) (void) */
   fntype[3] = build_function_type (type, void_list_node);
   /* type (*) (type, &int) */
-  tmp = tree_cons (NULL_TREE, type, void_list_node);
-  tmp = tree_cons (NULL_TREE, build_pointer_type (integer_type_node), tmp);
+  tmp = tree_cons (NULL_TREE, build_pointer_type (integer_type_node),
+   void_list_node);
+  tmp = tree_cons (NULL_TREE, type, tmp);
   fntype[4] = build_function_type (type, tmp);
   /* type (*) (type, int) */
-  tmp = tree_cons (NULL_TREE, type, void_list_node);
-  tmp = tree_cons (NULL_TREE, integer_type_node, tmp);
+  tmp = tree_cons (NULL_TREE, integer_type_node, void_list_node);
+  tmp = tree_cons (NULL_TREE, type, tmp);
   fntype[5] = build_function_type (type, tmp);
 }

Re: [patch ada]: Last fix for PR ada/47163 on windows native hosts

[Kai Tietz]

2011/4/5 Arnaud Charlet :
>> Well, there is a bug AFAICS. Issue is that 'ln -s file dir' fails, but
>> 'ln -s file file1' works. See for this thread
>> http://lists.zerezo.com/mingw-users/msg03642.html, where this is
>> described. So it might be also a valid fix here to append to directory
>> the $f again.
>
> OK, so it's indeed a bug in msys which should be fixed there IMO if it
> does not support 'cp -p file dir'

I agree, and I read the threads about that there on mingw.org.  I
don't see a good chance that it get fixed soon there.  Nevertheless is
the msys-environment the only way to do a full bootstrap of native gcc
toolchain, so I would simply love to have this work-a-rounded it in
gcc.  But well, I won't die if it isn't. ;)

> Adding $f may cause command line limitations on some platforms, so I'd rather
> avoid that.
Yes, understood. But some lines down in Makefile we use LN_S with same
pathes, but with filenames on all two arguments.  So I think this fear
might be without reason here. (see section "Copy new target dependent
sources").

Regards,
Kai

Re: [lto, testsuite] Don't use visibility on targets that don't support it (PR lto/47334)

[Richard Guenther]

On Tue, 5 Apr 2011, Rainer Orth wrote:

> As described in the PR, it seems to make more sense to avoid to use the
> visibility attribute on targets that don't support it rather than using
> it unconditionally and later (and incompletely) prune the resulting
> warning.
> 
> The following patch does exactly that.  It now needs to document the
> explicit visibility requirement in gcc.dg/lto/20081222_0.c (the main
> file of the testcase, rather than in 20081222_1.c that uses it) so the
> whole testcase is skipped.
> 
> Bootstrapped on mainline without regressions on i386-pc-solaris2.8 with
> Sun as which doesn't support the visibility attribute.
> 
> Ok for mainline and the 4.6 branch after testing?

The testsuite change is definitely ok.  I'm not sure about the
lto.c changes - as we make TU statics global but with hidden
visibility those symbols may clash with other global syms at
link time (a pre-existing problem it seems), now with your
change it also may clash with symbols from shared libs.

Honza, why is this promotion to global ok at all?  I can deliberately
break it by linking in a non-LTO object which clashes with the
mangled symbol.

Thanks,
Richard.

> Thanks.
>   Rainer
> 
> 
> 2011-03-27  Rainer Orth  
> 
>   gcc/lto:
>   PR lto/47334)
>   * lto.c (promote_var): Only set VISIBILITY_HIDDEN if
>   HAVE_GAS_HIDDEN.
>   (promote_fn): Likewise.
> 
>   gcc/testsuite:
>   PR lto/47334)
>   * lib/lto.exp (lto_prune_warns): Don't prune visibility warning.
>   * gcc.dg/lto/20081222_0.c: Add dg-require-visibility.
> 
> diff --git a/gcc/lto/lto.c b/gcc/lto/lto.c
> --- a/gcc/lto/lto.c
> +++ b/gcc/lto/lto.c
> @@ -1,5 +1,5 @@
>  /* Top-level LTO routines.
> -   Copyright 2009, 2010 Free Software Foundation, Inc.
> +   Copyright 2009, 2010, 2011 Free Software Foundation, Inc.
> Contributed by CodeSourcery, Inc.
>  
>  This file is part of GCC.
> @@ -1271,11 +1271,13 @@ promote_var (struct varpool_node *vnode)
>  return false;
>gcc_assert (flag_wpa);
>TREE_PUBLIC (vnode->decl) = 1;
> +#ifdef HAVE_GAS_HIDDEN
>DECL_VISIBILITY (vnode->decl) = VISIBILITY_HIDDEN;
>DECL_VISIBILITY_SPECIFIED (vnode->decl) = true;
>if (cgraph_dump_file)
>  fprintf (cgraph_dump_file,
>   "Promoting var as hidden: %s\n", varpool_node_name (vnode));
> +#endif
>return true;
>  }
>  
> @@ -1288,8 +1290,10 @@ promote_fn (struct cgraph_node *node)
>if (TREE_PUBLIC (node->decl) || DECL_EXTERNAL (node->decl))
>  return false;
>TREE_PUBLIC (node->decl) = 1;
> +#ifdef HAVE_GAS_HIDDEN
>DECL_VISIBILITY (node->decl) = VISIBILITY_HIDDEN;
>DECL_VISIBILITY_SPECIFIED (node->decl) = true;
> +#endif
>if (node->same_body)
>  {
>struct cgraph_node *alias;
> @@ -1297,14 +1301,18 @@ promote_fn (struct cgraph_node *node)
>  alias; alias = alias->next)
>   {
> TREE_PUBLIC (alias->decl) = 1;
> +#ifdef HAVE_GAS_HIDDEN
> DECL_VISIBILITY (alias->decl) = VISIBILITY_HIDDEN;
> DECL_VISIBILITY_SPECIFIED (alias->decl) = true;
> +#endif
>   }
>  }
> +#ifdef HAVE_GAS_HIDDEN
>if (cgraph_dump_file)
>  fprintf (cgraph_dump_file,
>"Promoting function as hidden: %s/%i\n",
>cgraph_node_name (node), node->uid);
> +#endif
>return true;
>  }
>  
> diff --git a/gcc/testsuite/gcc.dg/lto/20081222_0.c 
> b/gcc/testsuite/gcc.dg/lto/20081222_0.c
> --- a/gcc/testsuite/gcc.dg/lto/20081222_0.c
> +++ b/gcc/testsuite/gcc.dg/lto/20081222_0.c
> @@ -1,4 +1,6 @@
>  /* { dg-require-alias "" } */
> +/* { dg-require-visibility "" } */
> +
>  #include "20081222_0.h"
>  
>  extern void abort (void);
> diff --git a/gcc/testsuite/lib/lto.exp b/gcc/testsuite/lib/lto.exp
> --- a/gcc/testsuite/lib/lto.exp
> +++ b/gcc/testsuite/lib/lto.exp
> @@ -1,4 +1,4 @@
> -# Copyright (C) 2009, 2010 Free Software Foundation, Inc.
> +# Copyright (C) 2009, 2010, 2011 Free Software Foundation, Inc.
>  
>  # This program is free software; you can redistribute it and/or modify
>  # it under the terms of the GNU General Public License as published by
> @@ -22,14 +22,6 @@ proc lto_prune_warns { text } {
>  
>  verbose "lto_prune_warns: entry: $text" 2
>  
> -# Many tests that use visibility will still pass on platforms that don't 
> support it.
> -regsub -all "(^|\n)\[^\n\]*: warning: visibility attribute not supported 
> in this configuration; ignored\[^\n\]*" $text "" text
> -
> -# And any stray location lines.
> -regsub -all "(^|\n)\[^\n\]*: In function \[^\n\]*" $text "" text
> -regsub -all "(^|\n)In file included from \[^\n\]*" $text "" text
> -regsub -all "(^|\n)\[ \t\]*from \[^\n\]*" $text "" text
> -
>  # Sun ld warns about common symbols with differing sizes.  Unlike GNU ld
>  # --warn-common (off by default), they cannot be disabled.
>  regsub -all "(^|\n)ld: warning: symbol \[`'\]\[^\n\]*' has differing 
> sizes:" $text "" text
> 
> 
> 

-- 
Richard Guenther 
Novell / SUSE Labs
SUSE 

Re: [patch ada]: Last fix for PR ada/47163 on windows native hosts

[Arnaud Charlet]

> I agree, and I read the threads about that there on mingw.org.  I
> don't see a good chance that it get fixed soon there.  Nevertheless is
> the msys-environment the only way to do a full bootstrap of native gcc
> toolchain, so I would simply love to have this work-a-rounded it in
> gcc.  But well, I won't die if it isn't. ;)

You can use other environments (e.g. cygwin or interix) to build native
gcc under Windows, with a bit of tweaking.

> Yes, understood. But some lines down in Makefile we use LN_S with same
> pathes, but with filenames on all two arguments.  So I think this fear
> might be without reason here. (see section "Copy new target dependent
> sources").

The section you are referring to concerns a different and much smaller set
of files, so will not be affected by command line limitations, so this is not
comparable.

Arno

Re: [PATCH, Fortran] Correct declaration of frexp and friends

[Tobias Burnus]

Hi Ducan,

On 04/05/2011 11:41 AM, Duncan Sands wrote:

By the way I just noticed that the arguments to
the scalbn functions also seem to be the wrong way round:


here's a gcc-4.5 patch which fixes: (1) the comment for fntype[2], (2) 
the
prototypes for the frexp family and (3) the prototypes for the scalbn 
family.
I checked all uses of all of the function types declared here and all 
the rest
seem to be correct.  I also took a look at an example using scalbn and 
it looks
like calls to scalbn pass arguments in the right order (i.e. 
consistent with the
fixed prototype).  I'm running the testsuite now.  OK to apply to the 
4.5 branch

if it passes testing?


OK. (Contrary to the now fixed frexp, it seems to only affect < 4.6.)

Thanks for checking and fixing these bugs!

Tobias


Index: f95-lang.c
===
--- f95-lang.c(revision 171972)
+++ f95-lang.c(working copy)
@@ -646,19 +646,20 @@
   /* type (*) (type, type) */
   tmp = tree_cons (NULL_TREE, type, tmp);
   fntype[1] = build_function_type (type, tmp);
-  /* type (*) (int, type) */
+  /* type (*) (type, int) */
   tmp = tree_cons (NULL_TREE, integer_type_node, void_list_node);
   tmp = tree_cons (NULL_TREE, type, tmp);
   fntype[2] = build_function_type (type, tmp);
   /* type (*) (void) */
   fntype[3] = build_function_type (type, void_list_node);
   /* type (*) (type, &int) */
-  tmp = tree_cons (NULL_TREE, type, void_list_node);
-  tmp = tree_cons (NULL_TREE, build_pointer_type (integer_type_node), 
tmp);

+  tmp = tree_cons (NULL_TREE, build_pointer_type (integer_type_node),
+   void_list_node);
+  tmp = tree_cons (NULL_TREE, type, tmp);
   fntype[4] = build_function_type (type, tmp);
   /* type (*) (type, int) */
-  tmp = tree_cons (NULL_TREE, type, void_list_node);
-  tmp = tree_cons (NULL_TREE, integer_type_node, tmp);
+  tmp = tree_cons (NULL_TREE, integer_type_node, void_list_node);
+  tmp = tree_cons (NULL_TREE, type, tmp);
   fntype[5] = build_function_type (type, tmp);
 }

Re: [PATCH] allocate combine.c:LOG_LINKS in an alloc_pool

[Richard Guenther]

On Mon, Apr 4, 2011 at 9:25 PM, Nathan Froyd  wrote:
> On Mon, Apr 04, 2011 at 09:01:20PM +0200, Steven Bosscher wrote:
>> On Mon, Apr 4, 2011 at 8:49 PM, Nathan Froyd  
>> wrote:
>> > This patch does just what $SUBJECT suggests.  Benefits:
>> >
>> > - Smaller data structures in combine;
>> > - Freeing LOG_LINKS becomes much easier (don't have to transfer
>> >  everything to the INSN_LIST free list);
>> >
>> > Potential downsides:
>> >
>> > - Less sharing of INSN_LIST nodes might mean more cache thrashing.
>>
>> It looks like LOG_LINKs are allocated once. An alloc pool is
>> interesting if you allocate and free objects of the same size all the
>> time. In this case, I'd say an obstack would be a simpler and better
>> choice.
>
> FWIW, I went with alloc_pool because of the stats-for-free you get with
> appropriate configury.

I agree with Steven - alloc-pools have higher overhead because they
deal with memory re-use which you don't appearantly need.

Richard.

Re: [patch ada]: Last fix for PR ada/47163 on windows native hosts

[Kai Tietz]

2011/4/5 Arnaud Charlet :
>> I agree, and I read the threads about that there on mingw.org.  I
>> don't see a good chance that it get fixed soon there.  Nevertheless is
>> the msys-environment the only way to do a full bootstrap of native gcc
>> toolchain, so I would simply love to have this work-a-rounded it in
>> gcc.  But well, I won't die if it isn't. ;)
>
> You can use other environments (e.g. cygwin or interix) to build native
> gcc under Windows, with a bit of tweaking.

I know about that. And in fact I am use Wine for doing an native
compile. Nevertheless most users using msys for native windows.  Btw
that it would work on cygwin is more theory, as you need to replace
here system's make ... but well, I admit, if I tweak enough, its
possible. Interix is another nice approach, but for most people simply
unavailable due you need more then a windows-standard edition to use
it for free.

>> Yes, understood. But some lines down in Makefile we use LN_S with same
>> pathes, but with filenames on all two arguments.  So I think this fear
>> might be without reason here. (see section "Copy new target dependent
>> sources").
>
> The section you are referring to concerns a different and much smaller set
> of files, so will not be affected by command line limitations, so this is not
> comparable.

Sorry, here I am a bit curious. Maybe I am just unaware, but what have
the arguments of the LN_S call to do with the amount of entries in the
list, which are getting enumerated by foreach? The $f variable anyway
will contain just one filename, isn't it? Is such an foreach loop
unrolled before execution so that I have 'elements-in-foreach' *
'size-of-executed-command'?

Kai

Re: [patch ada]: Last fix for PR ada/47163 on windows native hosts

[Arnaud Charlet]

> I know about that. And in fact I am use Wine for doing an native
> compile. Nevertheless most users using msys for native windows.  Btw
> that it would work on cygwin is more theory,

It's not theory, it's what e.g. we do at AdaCore so it's very much
reality rather than theory.

> Sorry, here I am a bit curious. Maybe I am just unaware, but what have
> the arguments of the LN_S call to do with the amount of entries in the
> list, which are getting enumerated by foreach? The $f variable anyway
> will contain just one filename, isn't it? Is such an foreach loop
> unrolled before execution so that I have 'elements-in-foreach' *
> 'size-of-executed-command'?

Yes, GNU make 'foreach' will expand all the commands and concatenate them
into a single command line. In other words, foreach is simply a text
substition, unlike sh 'for' command.

Arno

Re: [patch][cprop.c] Simplify find_used_regs, iterate cprop_insn

[Richard Guenther]

On Mon, Apr 4, 2011 at 9:57 PM, Steven Bosscher  wrote:
> Hi,
>
> This patch has one significant change: cprop_insn would not iterate
> after a successful copy propagation, assuming the uses found with
> find_used_regs remain the same. This is not true in two cases:
>
> * find_used_regs found multiple uses of the same register, but that
> register was replaced by try_replace_reg.
>
> * find_used_regs found regs that have been folded after substitution
> in try_replace_reg (which ultimately tries simplify_replace_rtx if all
> else fails)
>
> After this patch, cprop_insn starts over after one successful copy
> propagation replacement.
>
>
> The rest of the patch just cleans up a single-member struct reg_use {
> rtx reg }. An array of rtx is simpler, although it probably makes no
> difference for the generated code for cprop.c.
>
> Bootstrapped & tested on x86_64-unknown-linux-gnu. OK?

Ok.

Thanks,
Richard.

> Ciao!
> Steven
>

Re: [patch ada]: Last fix for PR ada/47163 on windows native hosts

[Kai Tietz]

2011/4/5 Arnaud Charlet :
>> I know about that. And in fact I am use Wine for doing an native
>> compile. Nevertheless most users using msys for native windows.  Btw
>> that it would work on cygwin is more theory,
>
> It's not theory, it's what e.g. we do at AdaCore so it's very much
> reality rather than theory.
Interesting

>> Sorry, here I am a bit curious. Maybe I am just unaware, but what have
>> the arguments of the LN_S call to do with the amount of entries in the
>> list, which are getting enumerated by foreach? The $f variable anyway
>> will contain just one filename, isn't it? Is such an foreach loop
>> unrolled before execution so that I have 'elements-in-foreach' *
>> 'size-of-executed-command'?
>
> Yes, GNU make 'foreach' will expand all the commands and concatenate them
> into a single command line. In other words, foreach is simply a text
> substition, unlike sh 'for' command.

Thanks for the explaining. I wasn't aware.

Kai

Re: PATCH: PR middle-end/48440: [4.7 Regression] FAIL: gcc.c-torture/compile/labels-3.c

[Richard Guenther]

On Tue, Apr 5, 2011 at 8:44 AM, Paolo Bonzini  wrote:
 Index: cgraphbuild.c
 ===
 --- cgraphbuild.c.orig  2011-04-03 11:28:45.0 +0200
 +++ cgraphbuild.c       2011-04-03 11:31:21.0 +0200
 @@ -53,6 +53,12 @@ record_reference (tree *tp, int *walk_su
   tree decl;
   struct record_reference_ctx *ctx = (struct record_reference_ctx *)data;

 +  t = canonicalize_constructor_val (t);
 +  if (!t)
 +    t = *tp;
 +  else if (t != *tp)
 +    *tp = t;
 +
   switch (TREE_CODE (t))
     {
     case VAR_DECL:
>>>
>>> This change caused:
>>>
>>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48440
>>>
>>
>> This avoids  canonicalizing constructor values for address conversion
>> if Pmode != ptr_mode.  OK for trunk?
>
> Certainly the right place to fix it is in canonicalize_constructor_val itself.

There should never be any Pmode pointer types in the gimple IL.  The
proper place to fix it if any is in useless_type_conversion_p.

Richard.

> Paolo
>

Re: [PATCH, PR43920, 2/9] ARM specific part - test case

[Tom de Vries]

Hi Richard,

On 04/01/2011 06:10 PM, Tom de Vries wrote:
> On 04/01/2011 05:34 PM, Richard Earnshaw wrote:
>> On Fri, 2011-04-01 at 16:47 +0200, Tom de Vries wrote:
>>> Reposting, with ChangeLog.
>>
>> +/* { dg-options "-march=armv7-a -mthumb -Os" } */
>>
>> No, use dg-require-effective-target.  The above doesn't work properly
>> with multilib testing.
>>
> 
> Changed it into:
> 
> +/* { dg-options "-mthumb -Os" }  */
> +/* { dg-require-effective-target arm_thumb2_ok } */
> 

Is this updated version (
http://gcc.gnu.org/ml/gcc-patches/2011-04/msg00058.html ) ok for trunk?

Thanks,
- Tom

Re: [PATCH, Fortran] Correct declaration of frexp and friends

[Duncan Sands]

Hi Tobias,


here's a gcc-4.5 patch which fixes: (1) the comment for fntype[2], (2) the
prototypes for the frexp family and (3) the prototypes for the scalbn family.
I checked all uses of all of the function types declared here and all the rest
seem to be correct. I also took a look at an example using scalbn and it looks
like calls to scalbn pass arguments in the right order (i.e. consistent with the
fixed prototype). I'm running the testsuite now. OK to apply to the 4.5 branch
if it passes testing?


OK. (Contrary to the now fixed frexp, it seems to only affect < 4.6.)


yes, scalbn was already fixed in gcc-4.6 and later.


Thanks for checking and fixing these bugs!


No problem, thanks for approving!  Committed as revision 171979.

Ciao, Duncan.

Re: Avoid global state in rx_handle_option

[Nick Clifton]

Hi Joseph,


Tested building cc1 and xgcc for cross to rx-elf.  Will commit to
trunk in the absence of target maintainer objections.

2011-04-04  Joseph Myers

* config/rx/rx-opts.h: New.
* config/rx/rx.c (rx_cpu_type): Remove.
(rx_handle_option): Don't assert that global structures are in
use.  Access variables via opts pointer.  Defer most handling of
OPT_mint_register_.  Use error_at.
(rx_option_override): Handle deferred OPT_mint_register_ here.
* config/rx/rx.h (enum rx_cpu_types): Move to rx-opts.h.
* config/rx/rx.opt (config/rx/rx-opts.h: New HeaderInclude.
(mcpu=): Use Enum and specifiy rx_cpu_type with Var.
(rx_cpu_types): New Enum and EnumValue entries.
(mint-register=): Use Defer and use Var accordingly.


No objections - please apply.

Cheers
  Nick

[PATCH] don't use TYPE_ARG_TYPES in type_generic or sentinel attribute handling

[Nathan Froyd]

The type_generic and sentinel attribute handlers for c-family, LTO, and
Ada grovel through TYPE_ARG_TYPES; this patch changes them to use the
standard functions prototype_p and stdarg_p instead.  Less
TYPE_ARG_TYPES usage is a good thing.

The prototype_p check in the type_generic handlers is gross, but it's
necessary with the current system, because we have functions like:

DEF_GCC_BUILTIN(BUILT_IN_ISFINITE, "isfinite", BT_FN_INT_VAR, 
ATTR_CONST_NOTHROW_TYPEGENERIC_LEAF)

i.e. a zero-argument, "varargs" function.  Better would be to have a
flag in FUNCTION_TYPE denoting vararg-ness, rather than the
void_list_node vs. NULL scheme we have now, but that's further down the
line.

Tested on x86_64-unknown-linux-gnu.  OK to commit?

-Nathan

gcc/ada/
* gcc-interface/utils.c (handle_sentinel_attribute): Don't use
TYPE_ARG_TYPES
(handle_type_generic_attribute): Likewise.

gcc/c-family/
* c-common.c (handle_sentinel_attribute): Don't use TYPE_ARG_TYPES.
(handle_type_generic_attribute): Likewise.

gcc/lto/
* lto-lang.c (handle_sentinel_attribute): Don't use TYPE_ARG_TYPES.
(handle_type_generic_attribute): Likewise.

diff --git a/gcc/ada/gcc-interface/utils.c b/gcc/ada/gcc-interface/utils.c
index dc74374..8a78789 100644
--- a/gcc/ada/gcc-interface/utils.c
+++ b/gcc/ada/gcc-interface/utils.c
@@ -5266,8 +5266,6 @@ static tree
 handle_sentinel_attribute (tree *node, tree name, tree args,
   int ARG_UNUSED (flags), bool *no_add_attrs)
 {
-  tree params = TYPE_ARG_TYPES (*node);
-
   if (!prototype_p (*node))
 {
   warning (OPT_Wattributes,
@@ -5277,10 +5275,7 @@ handle_sentinel_attribute (tree *node, tree name, tree 
args,
 }
   else
 {
-  while (TREE_CHAIN (params))
-   params = TREE_CHAIN (params);
-
-  if (VOID_TYPE_P (TREE_VALUE (params)))
+  if (!stdarg_p (*node))
 {
  warning (OPT_Wattributes,
   "%qs attribute only applies to variadic functions",
@@ -5400,17 +5395,11 @@ handle_type_generic_attribute (tree *node, tree 
ARG_UNUSED (name),
   tree ARG_UNUSED (args), int ARG_UNUSED (flags),
   bool * ARG_UNUSED (no_add_attrs))
 {
-  tree params;
-
   /* Ensure we have a function type.  */
   gcc_assert (TREE_CODE (*node) == FUNCTION_TYPE);
 
-  params = TYPE_ARG_TYPES (*node);
-  while (params && ! VOID_TYPE_P (TREE_VALUE (params)))
-params = TREE_CHAIN (params);
-
   /* Ensure we have a variadic function.  */
-  gcc_assert (!params);
+  gcc_assert (!prototype_p (*node) || stdarg_p (*node));
 
   return NULL_TREE;
 }
diff --git a/gcc/c-family/c-common.c b/gcc/c-family/c-common.c
index cab9e7e..1d40292 100644
--- a/gcc/c-family/c-common.c
+++ b/gcc/c-family/c-common.c
@@ -7653,8 +7653,6 @@ static tree
 handle_sentinel_attribute (tree *node, tree name, tree args,
   int ARG_UNUSED (flags), bool *no_add_attrs)
 {
-  tree params = TYPE_ARG_TYPES (*node);
-
   if (!prototype_p (*node))
 {
   warning (OPT_Wattributes,
@@ -7663,10 +7661,7 @@ handle_sentinel_attribute (tree *node, tree name, tree 
args,
 }
   else
 {
-  while (TREE_CHAIN (params))
-   params = TREE_CHAIN (params);
-
-  if (VOID_TYPE_P (TREE_VALUE (params)))
+  if (!stdarg_p (*node))
{
  warning (OPT_Wattributes,
   "%qE attribute only applies to variadic functions", name);
@@ -7705,17 +7700,11 @@ handle_type_generic_attribute (tree *node, tree 
ARG_UNUSED (name),
   tree ARG_UNUSED (args), int ARG_UNUSED (flags),
   bool * ARG_UNUSED (no_add_attrs))
 {
-  tree params;
-
   /* Ensure we have a function type.  */
   gcc_assert (TREE_CODE (*node) == FUNCTION_TYPE);
 
-  params = TYPE_ARG_TYPES (*node);
-  while (params && ! VOID_TYPE_P (TREE_VALUE (params)))
-params = TREE_CHAIN (params);
-
   /* Ensure we have a variadic function.  */
-  gcc_assert (!params);
+  gcc_assert (!prototype_p (*node) || stdarg_p (*node));
 
   return NULL_TREE;
 }
diff --git a/gcc/lto/lto-lang.c b/gcc/lto/lto-lang.c
index 535fc58..c65d916 100644
--- a/gcc/lto/lto-lang.c
+++ b/gcc/lto/lto-lang.c
@@ -373,13 +373,7 @@ handle_sentinel_attribute (tree *node, tree ARG_UNUSED 
(name), tree args,
   int ARG_UNUSED (flags),
   bool * ARG_UNUSED (no_add_attrs))
 {
-  tree params = TYPE_ARG_TYPES (*node);
-  gcc_assert (params);
-
-  while (TREE_CHAIN (params))
-params = TREE_CHAIN (params);
-
-  gcc_assert (!VOID_TYPE_P (TREE_VALUE (params)));
+  gcc_assert (stdarg_p (*node));
 
   if (args)
 {
@@ -399,17 +393,11 @@ handle_type_generic_attribute (tree *node, tree 
ARG_UNUSED (name),
   tree ARG_UNUSED (args), int ARG_UNUSED (flags),
   bool * ARG_UNUSED (no_add_attrs))
 {
-  tree params;
-  
   /* Ensure we have a function type.

[PATCH] move some debug routines from final.c to dbxout.c

[Nathan Froyd]

I was looking at debug_flush_symbol_queue and thought "gosh, it's
inefficient if we're calling this all the time, but it only does work
when we want DBX_DEBUGGING_INFO."  So I looked around and saw that
debug_flush_symbol_queue and friends are only called from dbxout.c.  So
this patch moves them there; any inefficiency can be cleaned up at a
later point in time. ;)

Tested on x86_64-unknown-linux-gnu; verified that DBX_DEBUGGING_INFO is
defined and therefore dbxout.c gets compile-checked.  OK to commit?

-Nathan

* debug.h (debug_flush_symbol_queue, debug_queue_symbol): Delete.
(debug_free_queue, debug_nesting, symbol_queue_index): Delete.
* final.c (debug_flush_symbol_queue, debug_queue_symbol):
Move these...
(debug_free_queue, debug_nesting, symbol_queue_index):
...and these...
* dbxout.c: ...to here.  Make static.

diff --git a/gcc/dbxout.c b/gcc/dbxout.c
index 89d52a1..5ed9b69 100644
--- a/gcc/dbxout.c
+++ b/gcc/dbxout.c
@@ -96,6 +96,20 @@ along with GCC; see the file COPYING3.  If not see
 #include "xcoffout.h"
 #endif
 
+/* When -gused is used, emit debug info for only used symbols. But in
+   addition to the standard intercepted debug_hooks there are some
+   direct calls into this file, i.e., dbxout_symbol, dbxout_parms, and
+   dbxout_reg_params.  Those routines may also be called from a higher
+   level intercepted routine. So to prevent recording data for an inner
+   call to one of these for an intercept, we maintain an intercept
+   nesting counter (debug_nesting). We only save the intercepted
+   arguments if the nesting is 1.  */
+static int debug_nesting = 0;
+
+static tree *symbol_queue;
+static int symbol_queue_index = 0;
+static int symbol_queue_size = 0;
+
 #define DBXOUT_DECR_NESTING \
   if (--debug_nesting == 0 && symbol_queue_index > 0) \
 { emit_pending_bincls_if_required (); debug_flush_symbol_queue (); }
@@ -333,6 +347,7 @@ static const char *dbxout_common_check (tree, int *);
 static void dbxout_global_decl (tree);
 static void dbxout_type_decl (tree, int);
 static void dbxout_handle_pch (unsigned);
+static void debug_free_queue (void);
 
 /* The debug hooks structure.  */
 #if defined (DBX_DEBUGGING_INFO)
@@ -1403,7 +1418,73 @@ dbxout_type_index (tree type)
 }
 
 
+/* Generate the symbols for any queued up type symbols we encountered
+   while generating the type info for some originally used symbol.
+   This might generate additional entries in the queue.  Only when
+   the nesting depth goes to 0 is this routine called.  */
+
+static void
+debug_flush_symbol_queue (void)
+{
+  int i;
+
+  /* Make sure that additionally queued items are not flushed
+ prematurely.  */
+
+  ++debug_nesting;
+
+  for (i = 0; i < symbol_queue_index; ++i)
+{
+  /* If we pushed queued symbols then such symbols must be
+ output no matter what anyone else says.  Specifically,
+ we need to make sure dbxout_symbol() thinks the symbol was
+ used and also we need to override TYPE_DECL_SUPPRESS_DEBUG
+ which may be set for outside reasons.  */
+  int saved_tree_used = TREE_USED (symbol_queue[i]);
+  int saved_suppress_debug = TYPE_DECL_SUPPRESS_DEBUG (symbol_queue[i]);
+  TREE_USED (symbol_queue[i]) = 1;
+  TYPE_DECL_SUPPRESS_DEBUG (symbol_queue[i]) = 0;
+
+#ifdef DBX_DEBUGGING_INFO
+  dbxout_symbol (symbol_queue[i], 0);
+#endif
+
+  TREE_USED (symbol_queue[i]) = saved_tree_used;
+  TYPE_DECL_SUPPRESS_DEBUG (symbol_queue[i]) = saved_suppress_debug;
+}
+
+  symbol_queue_index = 0;
+  --debug_nesting;
+}
 
+/* Queue a type symbol needed as part of the definition of a decl
+   symbol.  These symbols are generated when debug_flush_symbol_queue()
+   is called.  */
+
+static void
+debug_queue_symbol (tree decl)
+{
+  if (symbol_queue_index >= symbol_queue_size)
+{
+  symbol_queue_size += 10;
+  symbol_queue = XRESIZEVEC (tree, symbol_queue, symbol_queue_size);
+}
+
+  symbol_queue[symbol_queue_index++] = decl;
+}
+
+/* Free symbol queue.  */
+static void
+debug_free_queue (void)
+{
+  if (symbol_queue)
+{
+  free (symbol_queue);
+  symbol_queue = NULL;
+  symbol_queue_size = 0;
+}
+}
+
 /* Used in several places: evaluates to '0' for a private decl,
'1' for a protected decl, '2' for a public decl.  */
 #define DECL_ACCESSIBILITY_CHAR(DECL) \
diff --git a/gcc/debug.h b/gcc/debug.h
index ffdca54..efdffe1 100644
--- a/gcc/debug.h
+++ b/gcc/debug.h
@@ -186,12 +186,6 @@ extern int dwarf2out_do_frame (void);
 extern int dwarf2out_do_cfi_asm (void);
 extern void dwarf2out_switch_text_section (void);
 
-extern void debug_flush_symbol_queue (void);
-extern void debug_queue_symbol (tree);
-extern void debug_free_queue (void);
-extern int debug_nesting;
-extern int symbol_queue_index;
-
 const char *remap_debug_filename (const char *);
 void add_debug_prefix_map (const char *);
 
diff --git a/gcc/final.c b/gcc/final.c
index cc7234c..3d97397 10064

Re: [PATCH, PR43920, 7/9] Cross-jumping - Extend search scope.

[Tom de Vries]

Hi Jeff,

On 03/31/2011 08:56 PM, Jeff Law wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On 03/31/11 12:43, Tom de Vries wrote:
>> Allows crossjump over fallthru paths.
> OK.
> jeff

You ok'ed patches 7/9 (
http://gcc.gnu.org/ml/gcc-patches/2011-03/msg02258.html ) and 9/9 (
http://gcc.gnu.org/ml/gcc-patches/2011-03/msg02260.html ).

Unfortunately I did not include the ChangeLog entries at that time. I
resubmitted these patches with ChangeLog:
- http://gcc.gnu.org/ml/gcc-patches/2011-04/msg00039.html
- http://gcc.gnu.org/ml/gcc-patches/2011-04/msg00041.html

Are the ChangeLog entries ok as well?

Thanks,
- Tom

Re: [PATCH] cleanup gcse.c:canon_modify_mem_list

[Nathan Froyd]

On Mon, Apr 04, 2011 at 12:01:09PM -0600, Jeff Law wrote:
> > +  canon_modify_mem_list = GCNEWVEC (VEC(modify_pair,heap) *,
> > +   last_basic_block);
> nit; You're missing some whitespace here (after the VEC).

This doesn't seem to be a hard-and-fast policy; all of the VEC code I
remember writing or looking at recently has no spaces, and I checked the
patch in on that basis.  However, running grep indicates that we have a
profusion of styles...

-Nathan

[wwwdocs][patch] Document NEON default vector size change

[Ira Rosen]

Hi,

As pointed out here
http://gcc.gnu.org/ml/gcc-patches/2011-03/msg02183.html the change of
the default vector size has to be documented in changes.html:

 * htdocs/gcc-4.7/changes.html (targets): Document ARM NEON default
 vector size change.

Index: htdocs/gcc-4.7/changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.7/changes.html,v
retrieving revision 1.6
diff -r1.6 changes.html
82a83,89
> ARM
> 
> The default vector size in auto-vectorization for NEON is now 128 
> bits.
>   If for some reason vectorization fails, the vectorizer tries again with
>   64 bit vectors.
>   
>

OK (once the change itself is committed)?

Thanks,
Ira

Re: [PATCH] move some debug routines from final.c to dbxout.c

[Richard Guenther]

On Tue, Apr 5, 2011 at 1:36 PM, Nathan Froyd  wrote:
> I was looking at debug_flush_symbol_queue and thought "gosh, it's
> inefficient if we're calling this all the time, but it only does work
> when we want DBX_DEBUGGING_INFO."  So I looked around and saw that
> debug_flush_symbol_queue and friends are only called from dbxout.c.  So
> this patch moves them there; any inefficiency can be cleaned up at a
> later point in time. ;)
>
> Tested on x86_64-unknown-linux-gnu; verified that DBX_DEBUGGING_INFO is
> defined and therefore dbxout.c gets compile-checked.  OK to commit?

Ok if you built any target with DBX support enabled.

Richard.

> -Nathan
>
>        * debug.h (debug_flush_symbol_queue, debug_queue_symbol): Delete.
>        (debug_free_queue, debug_nesting, symbol_queue_index): Delete.
>        * final.c (debug_flush_symbol_queue, debug_queue_symbol):
>        Move these...
>        (debug_free_queue, debug_nesting, symbol_queue_index):
>        ...and these...
>        * dbxout.c: ...to here.  Make static.
>
> diff --git a/gcc/dbxout.c b/gcc/dbxout.c
> index 89d52a1..5ed9b69 100644
> --- a/gcc/dbxout.c
> +++ b/gcc/dbxout.c
> @@ -96,6 +96,20 @@ along with GCC; see the file COPYING3.  If not see
>  #include "xcoffout.h"
>  #endif
>
> +/* When -gused is used, emit debug info for only used symbols. But in
> +   addition to the standard intercepted debug_hooks there are some
> +   direct calls into this file, i.e., dbxout_symbol, dbxout_parms, and
> +   dbxout_reg_params.  Those routines may also be called from a higher
> +   level intercepted routine. So to prevent recording data for an inner
> +   call to one of these for an intercept, we maintain an intercept
> +   nesting counter (debug_nesting). We only save the intercepted
> +   arguments if the nesting is 1.  */
> +static int debug_nesting = 0;
> +
> +static tree *symbol_queue;
> +static int symbol_queue_index = 0;
> +static int symbol_queue_size = 0;
> +
>  #define DBXOUT_DECR_NESTING \
>   if (--debug_nesting == 0 && symbol_queue_index > 0) \
>     { emit_pending_bincls_if_required (); debug_flush_symbol_queue (); }
> @@ -333,6 +347,7 @@ static const char *dbxout_common_check (tree, int *);
>  static void dbxout_global_decl (tree);
>  static void dbxout_type_decl (tree, int);
>  static void dbxout_handle_pch (unsigned);
> +static void debug_free_queue (void);
>
>  /* The debug hooks structure.  */
>  #if defined (DBX_DEBUGGING_INFO)
> @@ -1403,7 +1418,73 @@ dbxout_type_index (tree type)
>  }
>
>
> +/* Generate the symbols for any queued up type symbols we encountered
> +   while generating the type info for some originally used symbol.
> +   This might generate additional entries in the queue.  Only when
> +   the nesting depth goes to 0 is this routine called.  */
> +
> +static void
> +debug_flush_symbol_queue (void)
> +{
> +  int i;
> +
> +  /* Make sure that additionally queued items are not flushed
> +     prematurely.  */
> +
> +  ++debug_nesting;
> +
> +  for (i = 0; i < symbol_queue_index; ++i)
> +    {
> +      /* If we pushed queued symbols then such symbols must be
> +         output no matter what anyone else says.  Specifically,
> +         we need to make sure dbxout_symbol() thinks the symbol was
> +         used and also we need to override TYPE_DECL_SUPPRESS_DEBUG
> +         which may be set for outside reasons.  */
> +      int saved_tree_used = TREE_USED (symbol_queue[i]);
> +      int saved_suppress_debug = TYPE_DECL_SUPPRESS_DEBUG (symbol_queue[i]);
> +      TREE_USED (symbol_queue[i]) = 1;
> +      TYPE_DECL_SUPPRESS_DEBUG (symbol_queue[i]) = 0;
> +
> +#ifdef DBX_DEBUGGING_INFO
> +      dbxout_symbol (symbol_queue[i], 0);
> +#endif
> +
> +      TREE_USED (symbol_queue[i]) = saved_tree_used;
> +      TYPE_DECL_SUPPRESS_DEBUG (symbol_queue[i]) = saved_suppress_debug;
> +    }
> +
> +  symbol_queue_index = 0;
> +  --debug_nesting;
> +}
>
> +/* Queue a type symbol needed as part of the definition of a decl
> +   symbol.  These symbols are generated when debug_flush_symbol_queue()
> +   is called.  */
> +
> +static void
> +debug_queue_symbol (tree decl)
> +{
> +  if (symbol_queue_index >= symbol_queue_size)
> +    {
> +      symbol_queue_size += 10;
> +      symbol_queue = XRESIZEVEC (tree, symbol_queue, symbol_queue_size);
> +    }
> +
> +  symbol_queue[symbol_queue_index++] = decl;
> +}
> +
> +/* Free symbol queue.  */
> +static void
> +debug_free_queue (void)
> +{
> +  if (symbol_queue)
> +    {
> +      free (symbol_queue);
> +      symbol_queue = NULL;
> +      symbol_queue_size = 0;
> +    }
> +}
> +
>  /* Used in several places: evaluates to '0' for a private decl,
>    '1' for a protected decl, '2' for a public decl.  */
>  #define DECL_ACCESSIBILITY_CHAR(DECL) \
> diff --git a/gcc/debug.h b/gcc/debug.h
> index ffdca54..efdffe1 100644
> --- a/gcc/debug.h
> +++ b/gcc/debug.h
> @@ -186,12 +186,6 @@ extern int dwarf2out_do_frame (void);
>  extern int dwarf2out_do_cfi_asm (void);
>  extern void dwarf2out_switch_text_section 

Re: [wwwdocs][patch] Document NEON default vector size change

[Gerald Pfeifer]

On Tue, 5 Apr 2011, Ira Rosen wrote:
>> The default vector size in auto-vectorization for NEON is now 128 
>> bits.
>>   If for some reason vectorization fails, the vectorizer tries again with
>>   64 bit vectors.

64-bit according to http://gcc.gnu.org/codingconventions.html.

And perhaps omit "for some reason" and add "thusly", as in "If 
vectorization fails thusly"?

> OK (once the change itself is committed)?

Sure thing!

Gerald

Re: [PATCH PING] c++-specific bits of tree-slimming patches

[Nathan Froyd]

On Thu, Mar 24, 2011 at 06:15:18AM -0700, Nathan Froyd wrote:
> The C++-specific bits of these patches:
> 
>   [PATCH 02/18] enforce TREE_CHAIN and TREE_TYPE accesses
>   http://gcc.gnu.org/ml/gcc-patches/2011-03/msg00557.html
> 
>   [PATCH 07/18] generalize build_case_label to the rest of the compiler
>   http://gcc.gnu.org/ml/gcc-patches/2011-03/msg00557.html
> 
>   [PATCH 08/18] convert cp *FOR_STMTs to use private scope fields
>   http://gcc.gnu.org/ml/gcc-patches/2011-03/msg00553.html
> 
>   [PATCH 09/18] convert cp IF_STMTs to use private scope fields
>   http://gcc.gnu.org/ml/gcc-patches/2011-03/msg00562.html
> 
>   [PATCH 10/18] convert cp SWITCH_STMTs to use private scope fields
>   http://gcc.gnu.org/ml/gcc-patches/2011-03/msg00552.html
> 
>   [PATCH 11/18] mark EXPR_PACK_EXPANSION as typed only
>   http://gcc.gnu.org/ml/gcc-patches/2011-03/msg00563.html
> 
>   [PATCH 17/18] introduce block_chainon and use BLOCK_CHAIN more
>   http://gcc.gnu.org/ml/gcc-patches/2011-03/msg00566.html
> 
> are still pending review.

Ping^2.

Alternatively, could we have a GWP or similar rule on Tom's suggestion:

http://gcc.gnu.org/ml/gcc-patches/2011-03/msg00620.html

that patches propagating middle-end changes to front-ends are
obvious/preapproved, perhaps after a 24-48 hour waiting period for
comments?  That would cover 02 and 07 above (possibly 17 as well); 02 is
blocking some of the already-approved middle-end changes later in the
series.

I think Tom's suggestion makes a lot of sense, but I'm not exactly a
disinterested observer... :)

-Nathan

[PATCH] Fix PR48431

[Richard Guenther]

Committed.

Richard.

2011-04-05  Richard Guenther  

PR bootstrap/48431
* lto-plugin.c (claim_file_handler): Do not declare vars in code.

Index: lto-plugin/lto-plugin.c
===
*** lto-plugin/lto-plugin.c (revision 171978)
--- lto-plugin/lto-plugin.c (working copy)
*** claim_file_handler (const struct ld_plug
*** 851,861 
/* We pass the offset of the actual file, not the archive header.
   Can't use PRIx64, because that's C99, so we have to print the
 64-bit hex int as two 32-bit ones. */
!   int lo, hi;
lo = file->offset & 0x;
hi = ((int64_t)file->offset >> 32) & 0x;
!   int t = hi ? asprintf (&objname, "%s@0x%x%08x", file->name, lo, hi)
!   : asprintf (&objname, "%s@0x%x", file->name, lo);
check (t >= 0, LDPL_FATAL, "asprintf failed");
lto_file.name = objname;
  }
--- 851,861 
/* We pass the offset of the actual file, not the archive header.
   Can't use PRIx64, because that's C99, so we have to print the
 64-bit hex int as two 32-bit ones. */
!   int lo, hi, t;
lo = file->offset & 0x;
hi = ((int64_t)file->offset >> 32) & 0x;
!   t = hi ? asprintf (&objname, "%s@0x%x%08x", file->name, lo, hi)
!: asprintf (&objname, "%s@0x%x", file->name, lo);
check (t >= 0, LDPL_FATAL, "asprintf failed");
lto_file.name = objname;
  }

Re: [PATCH, PR43920, 2/9] ARM specific part - test case

[Richard Earnshaw]

On Tue, 2011-04-05 at 12:42 +0200, Tom de Vries wrote:
> Hi Richard,
> 
> On 04/01/2011 06:10 PM, Tom de Vries wrote:
> > On 04/01/2011 05:34 PM, Richard Earnshaw wrote:
> >> On Fri, 2011-04-01 at 16:47 +0200, Tom de Vries wrote:
> >>> Reposting, with ChangeLog.
> >>
> >> +/* { dg-options "-march=armv7-a -mthumb -Os" } */
> >>
> >> No, use dg-require-effective-target.  The above doesn't work properly
> >> with multilib testing.
> >>
> > 
> > Changed it into:
> > 
> > +/* { dg-options "-mthumb -Os" }  */
> > +/* { dg-require-effective-target arm_thumb2_ok } */
> > 
> 
> Is this updated version (
> http://gcc.gnu.org/ml/gcc-patches/2011-04/msg00058.html ) ok for trunk?
> 

Yes, thanks.

R.

Re: [PATCH] don't use TYPE_ARG_TYPES in type_generic or sentinel attribute handling

[Joseph S. Myers]

On Tue, 5 Apr 2011, Nathan Froyd wrote:

> gcc/c-family/
>   * c-common.c (handle_sentinel_attribute): Don't use TYPE_ARG_TYPES.
>   (handle_type_generic_attribute): Likewise.

The C-family changes are OK.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [PATCH] cleanup gcse.c:canon_modify_mem_list

[Richard Earnshaw]

On Tue, 2011-04-05 at 04:44 -0700, Nathan Froyd wrote:
> On Mon, Apr 04, 2011 at 12:01:09PM -0600, Jeff Law wrote:
> > > +  canon_modify_mem_list = GCNEWVEC (VEC(modify_pair,heap) *,
> > > + last_basic_block);
> > nit; You're missing some whitespace here (after the VEC).
> 
> This doesn't seem to be a hard-and-fast policy; all of the VEC code I
> remember writing or looking at recently has no spaces, and I checked the
> patch in on that basis.  However, running grep indicates that we have a
> profusion of styles...

I think the style guide is quite clear on this: there should be a space
there as Jeff says.  The fact that some code has crept in with other
styles doesn't make them right, or give justification for ignoring the
style guide.

R.

Re: [PATCH] cleanup gcse.c:canon_modify_mem_list

[Nathan Froyd]

On Tue, Apr 05, 2011 at 01:22:39PM +0100, Richard Earnshaw wrote:
> On Tue, 2011-04-05 at 04:44 -0700, Nathan Froyd wrote:
> > > nit; You're missing some whitespace here (after the VEC).
> > 
> > This doesn't seem to be a hard-and-fast policy; all of the VEC code I
> > remember writing or looking at recently has no spaces, and I checked the
> > patch in on that basis.  However, running grep indicates that we have a
> > profusion of styles...
> 
> I think the style guide is quite clear on this: there should be a space
> there as Jeff says.  The fact that some code has crept in with other
> styles doesn't make them right, or give justification for ignoring the
> style guide.

Would you like a patch for the hundreds of instances without spaces?

Certainly vec.h never uses spaces; I thought this was simply The Way
Things Were.

-Nathan

Re: [cxx-mem-model] C++ atomic tests (synchronized and relaxed)

[Aldy Hernandez]

Notice the store of  *after* the store to . I consider
this a bug and have put this on my laundry list.


Seems plausible, though I don't know the details of the x86_64 memory
model well enough to be sure that it would be possible to observe this
reordering. But then, if your test fails I guess it is. :)


I have not looked into why it happens, just that it does so incorrectly. 
 So I'm just as stumped :).



for (int i=0; i < SIZE; ++i)
x[i].store(666, memory_order_relaxed);

This is the test in the attached atomics-3.C.


I don't think that's testing what you want to test; those stores are to
the same array, but not to the same memory location.


Ahh, poop, yeah.  I had a simpler test, but it's pretty hard to trick 
GCC to not eliminate the first store if they're both to the same 
location.  I've removed this test, and only committed the first one.


Thanks for looking into this.
Aldy

[patch] PR48441 ICE in mark_oprs_set

[Steven Bosscher]

Hi,

My recent patch to cprop.c to use DF_INSN_INFO caches exposed a latent
bug in CPROP. The bug triggered on hppa-linux, but the problem is
generic.

The ICE looks like this:

Breakpoint 3, mark_oprs_set (insn=0x76edc140) at
../../trunk/gcc/cprop.c:538
538   struct df_insn_info *insn_info = DF_INSN_INFO_GET (insn);
(gdb) p debug_rtx(insn)
(jump_insn 171 170 248 31 (set (pc)
(if_then_else (eq (reg/v:SI 158 [ rval ])
(const_int 7 [0x7]))
(label_ref:SI 248)
(pc))) ../../gcc/libcpp/charset.c:481 25 {*pa.md:1330}
 (expr_list:REG_BR_PROB (const_int 9550 [0x254e])
(nil))
 -> 248)
$12 = void
(gdb) p insn_info
$14 = (struct df_insn_info *) 0x14ca078
(gdb) call df_insn_debug(insn,false,stderr)
insn 171 luid 0 defs { } uses { u226(158)} eq uses { } mws
(gdb) cont
Continuing.

Breakpoint 3, mark_oprs_set (insn=0x76edc140) at
../../trunk/gcc/cprop.c:538
538   struct df_insn_info *insn_info = DF_INSN_INFO_GET (insn);
(gdb) p debug_rtx(insn)
(jump_insn/v 171 170 257 29 (set (pc)
(if_then_else (eq (reg/v:SI 158 [ rval ])
(const_int 7 [0x7]))
(label_ref:SI 257)
(pc))) ../../gcc/libcpp/charset.c:481 25 {*pa.md:1330}
 (expr_list:REG_BR_PROB (const_int 9550 [0x254e])
(nil))
 -> 257)
$13 = void
(gdb) p insn_info
$15 = (struct df_insn_info *) 0x0
(gdb) # So the insn is not even known anymore in DF
(gdb) call df_insn_debug(insn,false,stderr)

Program received signal SIGSEGV, Segmentation fault.
0x0063d9cb in df_insn_uid_debug (uid=171, follow_chain=0 '\0',
file=0x77bd8860) at ../../trunk/gcc/df-core.c:2113
2113  fprintf (file, "insn %d luid %d",


What happens, is that cprop_insn makes the insn deleted, in the second
CPROP pass:

Breakpoint 3, one_cprop_pass () at ../../trunk/gcc/cprop.c:1799
1799changed |= cprop_insn (insn);
(gdb) p debug_rtx(insn)
(jump_insn 214 213 303 29 (set (pc)
(if_then_else (eq (reg/v:SI 202 [ rval ])
(const_int 7 [0x7]))
(label_ref:SI 303)
(pc))) charset.i:106 25 {*pa.md:1330}
 (expr_list:REG_BR_PROB (const_int 9550 [0x254e])
(nil))
 -> 303)
$12 = void
(gdb) next
1805if (! NOTE_P (insn))
(gdb) p debug_rtx(insn)
(jump_insn/v 214 213 303 29 (set (pc)
(if_then_else (eq (reg/v:SI 202 [ rval ])
(const_int 7 [0x7]))
(label_ref:SI 303)
(pc))) charset.i:106 25 {*pa.md:1330}
 (expr_list:REG_BR_PROB (const_int 9550 [0x254e])
(nil))
 -> 303)
$13 = void
(gdb)

CPROP finds that rval==22 and folds away the comparsion "(eq (rval==22) (7))"
in cprop_jump, and then goes on to:

  /* If this is now a no-op delete it, otherwise this must be a valid insn.  */
  if (new_rtx == pc_rtx)
delete_insn (jump);

I also verified that the same occurred before my patch, i.e. we were
doing mark_oprs_set on dead/deleted insns.

Patch is simple. Bootstrapped&tested on x86_64-unknown-linux-gnu. The
bug never triggered there, so I'll wait for confirmation that the
hppa-linux problem is fixed with this patch, and commit the patch
under the "obvious" rule.

Ciao!
Steven

PR middle-end/48441
* cprop.c (one_cprop_pass): Do not mark_oprs_set of deleted insns.

Index: cprop.c
===
--- cprop.c(revision 171948)
+++ cprop.c(working copy)
@@ -1797,8 +1797,8 @@ one_cprop_pass (void)
 /* Keep track of everything modified by this insn.  */
 /* ??? Need to be careful w.r.t. mods done to INSN.
Don't call mark_oprs_set if we turned the
-   insn into a NOTE.  */
-if (! NOTE_P (insn))
+   insn into a NOTE, or deleted the insn.  */
+if (! NOTE_P (insn) && ! INSN_DELETED_P (insn))
   mark_oprs_set (insn);
   }
 }

Re: [patch ada]: Last fix for PR ada/47163 on windows native hosts

[Charles Wilson]

On 4/5/2011 6:22 AM, Kai Tietz wrote:
> 2011/4/5 Arnaud Charlet :
>>> I know about that. And in fact I am use Wine for doing an native
>>> compile. Nevertheless most users using msys for native windows.  Btw
>>> that it would work on cygwin is more theory,
>>
>> It's not theory, it's what e.g. we do at AdaCore so it's very much
>> reality rather than theory.
> Interesting

I'm one of the MSys "devs" (if you want to call the sporadic process of
updating MSys "development").  I'll take a look at implementing
ln -s file dir
as synonymous with
ln -s file dir/basename-of-file
in the next few days.

--
Chuck

Re: [PATCH] cleanup gcse.c:canon_modify_mem_list

[Richard Earnshaw]

On Tue, 2011-04-05 at 05:30 -0700, Nathan Froyd wrote:
> On Tue, Apr 05, 2011 at 01:22:39PM +0100, Richard Earnshaw wrote:
> > On Tue, 2011-04-05 at 04:44 -0700, Nathan Froyd wrote:
> > > > nit; You're missing some whitespace here (after the VEC).
> > > 
> > > This doesn't seem to be a hard-and-fast policy; all of the VEC code I
> > > remember writing or looking at recently has no spaces, and I checked the
> > > patch in on that basis.  However, running grep indicates that we have a
> > > profusion of styles...
> > 
> > I think the style guide is quite clear on this: there should be a space
> > there as Jeff says.  The fact that some code has crept in with other
> > styles doesn't make them right, or give justification for ignoring the
> > style guide.
> 
> Would you like a patch for the hundreds of instances without spaces?
> 
> Certainly vec.h never uses spaces; I thought this was simply The Way
> Things Were.
> 
> -Nathan
> 

IMO, rototils are generally pointless.  If you are fixing code nearby
then yes, fix the formatting issues.  Otherwise, just don't exacerbate
the problem, or we'll reach the point where a rototil really does become
necessary.

R.

Re: [PATCH] cleanup gcse.c:canon_modify_mem_list

[Jeff Law]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 04/05/11 06:55, Richard Earnshaw wrote:
> 
> On Tue, 2011-04-05 at 05:30 -0700, Nathan Froyd wrote:
>> On Tue, Apr 05, 2011 at 01:22:39PM +0100, Richard Earnshaw wrote:
>>> On Tue, 2011-04-05 at 04:44 -0700, Nathan Froyd wrote:
> nit; You're missing some whitespace here (after the VEC).

 This doesn't seem to be a hard-and-fast policy; all of the VEC code I
 remember writing or looking at recently has no spaces, and I checked the
 patch in on that basis.  However, running grep indicates that we have a
 profusion of styles...
>>>
>>> I think the style guide is quite clear on this: there should be a space
>>> there as Jeff says.  The fact that some code has crept in with other
>>> styles doesn't make them right, or give justification for ignoring the
>>> style guide.
>>
>> Would you like a patch for the hundreds of instances without spaces?
>>
>> Certainly vec.h never uses spaces; I thought this was simply The Way
>> Things Were.
>>
>> -Nathan
>>
> 
> IMO, rototils are generally pointless.  If you are fixing code nearby
> then yes, fix the formatting issues.  Otherwise, just don't exacerbate
> the problem, or we'll reach the point where a rototil really does become
> necessary.
Well, the other approach is to have a commit hook which automatically
deals with formatting crap by running indent, or whatever tool we want.

That would take the decision out of the hands of the developer and free
the reviewer from having to catch such things and ensures there is a
canonical form for our sources.

jeff
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJNmxQQAAoJEBRtltQi2kC7f7sH/RtTsEdYZKbgD1IdDTHnAW2R
OW3ie04GuUdFC1ZAekvOcVhbIeouLZ/HyyaWiZZ3uNajF6cRDMIDe7MEygqKAWKg
WUVtJeQlrhnERcvjJFe3pYzxf2wBwSYI/A+6Ql5mXfigx2Za7WoSdzq1zQXvd+Pe
ihR35DClH2lX3YAqGi6h47J+lk0kRuN1kvnSWwOzo/ACYBkdJrbZDCRVtkV+UQnt
zgn/NkUwNbnJmyApLlr5jVYRIbe8saVrjnrO39siOVz26eqnuV8IehY7ePnidr3f
8wZ06mTJaN/PgMpCltHvQZ3Vos/+BxTtCMTAFaxRKAJd25HNcd955GHBNG7qIYE=
=UkkH
-END PGP SIGNATURE-

[PATCH] use build_function_type_list for float128 functions

[Nathan Froyd]

When the real16/float128 bits were added to the Fortran FE, some uses of
build_function_type snuck in.  This patch changes them to use
build_function_type_list.

The patch also corrects a small bug: the types for frexp and scalbn had
their argument types in the wrong order.

Tested on x86_64-unknown-linux-gnu.  OK to commit?

-Nathan

* trans-intrinsic.c (gfc_build_intrinsic_lib_fndecls): Use
build_function_type_list instead of build_function_type.  Correct
argument order for func_frexp and func_scalbn.

diff --git a/gcc/fortran/trans-intrinsic.c b/gcc/fortran/trans-intrinsic.c
index a3c2ecd..9a69632 100644
--- a/gcc/fortran/trans-intrinsic.c
+++ b/gcc/fortran/trans-intrinsic.c
@@ -621,35 +621,38 @@ gfc_build_intrinsic_lib_fndecls (void)
C99-like library functions.  For now, we only handle __float128
q-suffixed functions.  */
 
-tree tmp, func_1, func_2, func_cabs, func_frexp;
+tree type, complex_type, func_1, func_2, func_cabs, func_frexp;
 tree func_lround, func_llround, func_scalbn, func_cpow;
 
 memset (quad_decls, 0, sizeof(tree) * (END_BUILTINS + 1));
 
+type = float128_type_node;
+complex_type = complex_float128_type_node;
 /* type (*) (type) */
-tmp = tree_cons (NULL_TREE, float128_type_node, void_list_node);
-func_1 = build_function_type (float128_type_node, tmp);
+func_1 = build_function_type_list (type, type, NULL_TREE);
 /* long (*) (type) */
-func_lround = build_function_type (long_integer_type_node, tmp);
+func_lround = build_function_type_list (long_integer_type_node,
+   type, NULL_TREE);
 /* long long (*) (type) */
-func_llround = build_function_type (long_long_integer_type_node, tmp);
+func_llround = build_function_type_list (long_long_integer_type_node,
+type, NULL_TREE);
 /* type (*) (type, type) */
-tmp = tree_cons (NULL_TREE, float128_type_node, tmp);
-func_2 = build_function_type (float128_type_node, tmp);
+func_2 = build_function_type_list (type, type, type, NULL_TREE);
 /* type (*) (type, &int) */
-tmp = tree_cons (NULL_TREE, float128_type_node, void_list_node);
-tmp = tree_cons (NULL_TREE, build_pointer_type (integer_type_node), tmp);
-func_frexp = build_function_type (float128_type_node, tmp);
+func_frexp
+  = build_function_type_list (type,
+ type,
+ build_pointer_type (integer_type_node),
+ NULL_TREE);
 /* type (*) (type, int) */
-tmp = tree_cons (NULL_TREE, float128_type_node, void_list_node);
-tmp = tree_cons (NULL_TREE, integer_type_node, tmp);
-func_scalbn = build_function_type (float128_type_node, tmp);
+func_scalbn = build_function_type_list (type,
+   type, integer_type_node, NULL_TREE);
 /* type (*) (complex type) */
-tmp = tree_cons (NULL_TREE, complex_float128_type_node, void_list_node);
-func_cabs = build_function_type (float128_type_node, tmp);
+func_cabs = build_function_type_list (type, complex_type, NULL_TREE);
 /* complex type (*) (complex type, complex type) */
-tmp = tree_cons (NULL_TREE, complex_float128_type_node, tmp);
-func_cpow = build_function_type (complex_float128_type_node, tmp);
+func_cpow
+  = build_function_type_list (complex_type,
+ complex_type, complex_type, NULL_TREE);
 
 #define DEFINE_MATH_BUILTIN(ID, NAME, ARGTYPE)
 #define DEFINE_MATH_BUILTIN_C(ID, NAME, ARGTYPE)

[PATCH] make gcse.c:modify_mem_list hold VECs instead of INSN_LISTs

[Nathan Froyd]

As promised, this patch turns modify_mem_list into an array of VECs,
similar to the changes done to canon_modify_mem_list.  Since I'm in the
area, I took the liberty of tweaking the VEC declarations related to
canon_modify_mem_list to have spaces before parens, as folks seem to
think that's the right way to write them.

Tested on x86_64-unknown-linux-gnu.  OK to commit?

-Nathan

* gcse.c (modify_mem_list): Convert to an array of VECs.
(canon_modify_mem_list, compute_transp): Tweak formatting.
(alloc_gcse_mem): Likewise.  Adjust for modify_mem_list change.
(load_killed_in_block_p): Likewise.
(record_last_mem_set_info): Likewise.
(clear_modify_mem_tables): Likewise.

diff --git a/gcc/gcse.c b/gcc/gcse.c
index d6a4db4..41fff7a 100644
--- a/gcc/gcse.c
+++ b/gcc/gcse.c
@@ -382,7 +382,7 @@ static regset reg_set_bitmap;
 
 /* Array, indexed by basic block number for a list of insns which modify
memory within that block.  */
-static rtx * modify_mem_list;
+static VEC (rtx,heap) **modify_mem_list;
 static bitmap modify_mem_list_set;
 
 typedef struct modify_pair_s
@@ -396,7 +396,7 @@ DEF_VEC_ALLOC_O(modify_pair,heap);
 
 /* This array parallels modify_mem_list, except that it stores MEMs
being set and their canonicalized memory addresses.  */
-static VEC(modify_pair,heap) **canon_modify_mem_list;
+static VEC (modify_pair,heap) **canon_modify_mem_list;
 
 /* Bitmap indexed by block numbers to record which blocks contain
function calls.  */
@@ -595,8 +595,8 @@ alloc_gcse_mem (void)
 
   /* Allocate array to keep a list of insns which modify memory in each
  basic block.  */
-  modify_mem_list = GCNEWVEC (rtx, last_basic_block);
-  canon_modify_mem_list = GCNEWVEC (VEC(modify_pair,heap) *,
+  modify_mem_list = GCNEWVEC (VEC (rtx,heap) *, last_basic_block);
+  canon_modify_mem_list = GCNEWVEC (VEC (modify_pair,heap) *,
last_basic_block);
   modify_mem_list_set = BITMAP_ALLOC (NULL);
   blocks_with_calls = BITMAP_ALLOC (NULL);
@@ -991,26 +991,22 @@ mems_conflict_for_gcse_p (rtx dest, const_rtx setter 
ATTRIBUTE_UNUSED,
 static int
 load_killed_in_block_p (const_basic_block bb, int uid_limit, const_rtx x, int 
avail_p)
 {
-  rtx list_entry = modify_mem_list[bb->index];
+  VEC (rtx,heap) *list = modify_mem_list[bb->index];
+  rtx setter;
+  unsigned ix;
 
   /* If this is a readonly then we aren't going to be changing it.  */
   if (MEM_READONLY_P (x))
 return 0;
 
-  while (list_entry)
+  FOR_EACH_VEC_ELT_REVERSE (rtx, list, ix, setter)
 {
-  rtx setter;
   /* Ignore entries in the list that do not apply.  */
   if ((avail_p
-  && DF_INSN_LUID (XEXP (list_entry, 0)) < uid_limit)
+  && DF_INSN_LUID (setter) < uid_limit)
  || (! avail_p
- && DF_INSN_LUID (XEXP (list_entry, 0)) > uid_limit))
-   {
- list_entry = XEXP (list_entry, 1);
- continue;
-   }
-
-  setter = XEXP (list_entry, 0);
+ && DF_INSN_LUID (setter) > uid_limit))
+   continue;
 
   /* If SETTER is a call everything is clobbered.  Note that calls
 to pure functions are never put on the list, so we need not
@@ -1028,7 +1024,6 @@ load_killed_in_block_p (const_basic_block bb, int 
uid_limit, const_rtx x, int av
   note_stores (PATTERN (setter), mems_conflict_for_gcse_p, NULL);
   if (gcse_mems_conflict_p)
return 1;
-  list_entry = XEXP (list_entry, 1);
 }
   return 0;
 }
@@ -1480,7 +1475,7 @@ record_last_mem_set_info (rtx insn)
 
   /* load_killed_in_block_p will handle the case of calls clobbering
  everything.  */
-  modify_mem_list[bb] = alloc_INSN_LIST (insn, modify_mem_list[bb]);
+  VEC_safe_push (rtx, heap, modify_mem_list[bb], insn);
   bitmap_set_bit (modify_mem_list_set, bb);
 
   if (CALL_P (insn))
@@ -1621,7 +1616,7 @@ clear_modify_mem_tables (void)
 
   EXECUTE_IF_SET_IN_BITMAP (modify_mem_list_set, 0, i, bi)
 {
-  free_INSN_LIST_list (modify_mem_list + i);
+  VEC_free (rtx, heap, modify_mem_list[i]);
   VEC_free (modify_pair, heap, canon_modify_mem_list[i]);
 }
   bitmap_clear (modify_mem_list_set);
@@ -1693,7 +1688,7 @@ compute_transp (const_rtx x, int indx, sbitmap *bmap)
blocks_with_calls,
0, bb_index, bi)
  {
-   VEC(modify_pair,heap) *list
+   VEC (modify_pair,heap) *list
  = canon_modify_mem_list[bb_index];
modify_pair *pair;
unsigned ix;

Re: [patch ada]: Last fix for PR ada/47163 on windows native hosts

[Arnaud Charlet]

> I'm one of the MSys "devs" (if you want to call the sporadic process of
> updating MSys "development").  I'll take a look at implementing
>   ln -s file dir
> as synonymous with
>   ln -s file dir/basename-of-file
> in the next few days.

Thanks, although the case we're really interested in here is:

   cp -p file dir
as equivalent to
   cp -p file dir/basename-of-file

Arno

Re: [patch libjava]: Do some fixes for windows native targets

[Tom Tromey]

> "Kai" == Kai Tietz  writes:

Kai> this patch fixes some issues in libjava for windows targets.  It
Kai> addresses for now only 32-bit target, but for JNICALL definition I
Kai> introduced already logic for 64-bit windows target too as preparation.

Most of this seems ok to me.

Kai>* java/lang/reflect/Field.h (_Jv_JNI_ToReflectedField):
Kai>Likewise.
Kai>* java/lang/reflect/Constructor.h (_Jv_JNI_ToReflectedMethod):
Kai>Likewise.

These headers are generated.  You have to edit headers.txt and then
rebuild them.

Tom

Re: [patch, ARM] Make 128 bits the default vector size for NEON

[Ramana Radhakrishnan]

On 31/03/11 12:39, Ira Rosen wrote:

Hi,

This patch changes NEON's default vector size from 64 to 128 bits.

The patch doesn't touch mvectorize-with-neon-quad, but removes the
uses of TARGET_NEON_VECTORIZE_QUAD.
Following Julian's suggestion I added a param preferred-vector-size
for testing and debugging purposes.


IIUC, this patch makes mvectorize-with-neon-quad effectively a no-op 
which is ok with me.


If this is now the default, what is the behaviour of 
-mno-vectorize-with-neon-quad now ? Should that set the value of the 
parameter to 64 or should we be rejecting the negative of that option ?


If not, we should then consider adding a RejectNegative to that option.


cheers
Ramana


--
Ramana Radhakrishnan

Re: [PATCH, ARM] PR47855 Compute attr "length" for some thumb2 insns

[Ramana Radhakrishnan]

The patch was tested on arm qemu without regression, OK for install?


Ok if no regressions.

cheers
Ramana



thanks
Carrot


ChangeLog:
2011-04-01  Wei Guozhi

 PR target/47855
 * config/arm/arm.md (arm_cmpsi_insn): Compute attr "length".
 (arm_cond_branch): Likewise.
 (arm_cond_branch_reversed): Likewise.
 (arm_jump): Likewise.
 (push_multi): Likewise.
 * config/arm/constraints.md (Py): New constraint.


Index: constraints.md
===
--- constraints.md  (revision 171337)
+++ constraints.md  (working copy)
@@ -31,7 +31,7 @@
  ;; The following multi-letter normal constraints have been used:
  ;; in ARM/Thumb-2 state: Da, Db, Dc, Dn, Dl, DL, Dv, Dy, Di, Dz
  ;; in Thumb-1 state: Pa, Pb, Pc, Pd
-;; in Thumb-2 state: Ps, Pt, Pu, Pv, Pw, Px
+;; in Thumb-2 state: Ps, Pt, Pu, Pv, Pw, Px, Py

  ;; The following memory constraints have been used:
  ;; in ARM/Thumb-2 state: Q, Ut, Uv, Uy, Un, Um, Us
@@ -189,6 +189,11 @@
(and (match_code "const_int")
 (match_test "TARGET_THUMB2&&  ival>= -7&&  ival<= -1")))

+(define_constraint "Py"
+  "@internal In Thumb-2 state a constant in the range 0 to 255"
+  (and (match_code "const_int")
+   (match_test "TARGET_THUMB2&&  ival>= 0&&  ival<= 255")))
+
  (define_constraint "G"
   "In ARM/Thumb-2 state a valid FPA immediate constant."
   (and (match_code "const_double")
Index: arm.md
===
--- arm.md  (revision 171337)
+++ arm.md  (working copy)
@@ -7109,13 +7109,17 @@

  (define_insn "*arm_cmpsi_insn"
[(set (reg:CC CC_REGNUM)
-   (compare:CC (match_operand:SI 0 "s_register_operand" "r,r")
-   (match_operand:SI 1 "arm_add_operand""rI,L")))]
+   (compare:CC (match_operand:SI 0 "s_register_operand" "l,r,r,r")
+   (match_operand:SI 1 "arm_add_operand""Py,r,rI,L")))]
"TARGET_32BIT"
"@
 cmp%?\\t%0, %1
+   cmp%?\\t%0, %1
+   cmp%?\\t%0, %1
 cmn%?\\t%0, #%n1"
-  [(set_attr "conds" "set")]
+  [(set_attr "conds" "set")
+   (set_attr "arch" "t2,t2,any,any")
+   (set_attr "length" "2,2,4,4")]
  )

  (define_insn "*cmpsi_shiftsi"
@@ -7286,7 +7290,14 @@
return \"b%d1\\t%l0\";
"
[(set_attr "conds" "use")
-   (set_attr "type" "branch")]
+   (set_attr "type" "branch")
+   (set (attr "length")
+   (if_then_else
+  (and (ne (symbol_ref "TARGET_THUMB2") (const_int 0))
+   (and (ge (minus (match_dup 0) (pc)) (const_int -250))
+(le (minus (match_dup 0) (pc)) (const_int 256
+  (const_int 2)
+  (const_int 4)))]
  )

  (define_insn "*arm_cond_branch_reversed"
@@ -7305,7 +7316,14 @@
return \"b%D1\\t%l0\";
"
[(set_attr "conds" "use")
-   (set_attr "type" "branch")]
+   (set_attr "type" "branch")
+   (set (attr "length")
+   (if_then_else
+  (and (ne (symbol_ref "TARGET_THUMB2") (const_int 0))
+   (and (ge (minus (match_dup 0) (pc)) (const_int -250))
+(le (minus (match_dup 0) (pc)) (const_int 256
+  (const_int 2)
+  (const_int 4)))]
  )



@@ -7757,7 +7775,14 @@
  return \"b%?\\t%l0\";
}
"
-  [(set_attr "predicable" "yes")]
+  [(set_attr "predicable" "yes")
+   (set (attr "length")
+   (if_then_else
+  (and (ne (symbol_ref "TARGET_THUMB2") (const_int 0))
+   (and (ge (minus (match_dup 0) (pc)) (const_int -2044))
+(le (minus (match_dup 0) (pc)) (const_int 2048
+  (const_int 2)
+  (const_int 4)))]
  )

  (define_insn "*thumb_jump"
@@ -10256,7 +10281,29 @@

  return \"\";
}"
-  [(set_attr "type" "store4")]
+  [(set_attr "type" "store4")
+   (set (attr "length")
+   (if_then_else
+  (and (ne (symbol_ref "TARGET_THUMB2") (const_int 0))
+   (ne (symbol_ref "{
+   /* Check if there are any high register (except lr)
+  references in the list. KEEP the following iteration
+  in sync with the template above.  */
+   int i, regno, hi_reg;
+   int num_saves = XVECLEN (operands[2], 0);
+   regno = REGNO (operands[1]);
+   hi_reg = (REGNO_REG_CLASS (regno) == HI_REGS)
+   &&  (regno != LR_REGNUM);
+   for (i = 1; i<  num_saves&&  !hi_reg; i++)
+ {
+   regno = REGNO (XEXP (XVECEXP (operands[2], 0, i), 0));
+   hi_reg |= (REGNO_REG_CLASS (regno) == HI_REGS)
+   &&  (regno != LR_REGNUM);
+ }
+   !hi_reg;}")
+ (const_int 0)))
+  (const_int 2)
+  (const_int 4)))]
  )

  (define_insn "stack_tie"

Re: [PATCH, PR43920, 1/9] ARM specific part.

[Tom de Vries]

On 04/04/2011 02:22 PM, Rainer Orth wrote:
> Richard Guenther  writes:
> 
>> On Sun, Apr 3, 2011 at 9:34 PM, Sergey Ostanevich  
>> wrote:
>>> I would recommend to use 'nm -S a.out' that gives
>>>
>>> [...]
>>> 004004a4 0054 T main
>>> [...]
>>>
>>> then you can provide a name for the routine you want to test for the size.
>>
>> That also sounds reasonable.  Is nm -S more portable than size?
> 
> Neither Solaris nor IRIX nm have it.  size isn't particularly portable,
> either: there are many variations in output format.
> 
>   Rainer
> 

In case we ever need it, here's a patch to access nm -S.

Thanks,
- Tom
2011-04-05  Tom de Vries  

	* lib/scanasm.exp (object-symbol-size): New proc.
Index: gcc/testsuite/lib/scanasm.exp
===
--- gcc/testsuite/lib/scanasm.exp (revision 170556)
+++ gcc/testsuite/lib/scanasm.exp (working copy)
@@ -315,6 +315,90 @@ proc scan-assembler-dem-not { args } {
 }
 }
 
+# Call pass if symbol size is ok, otherwise fail.
+# example: /* { dg-final { object-symbol-size main <= 54 } } */
+proc object-symbol-size { args } {
+global nm
+global base_dir
+
+if { [llength $args] < 3 } {
+	error "object-symbol-size: too few arguments"
+return
+}
+if { [llength $args] > 4 } {
+	error "object-symbol-size: too many arguments"
+	return
+}
+if { [llength $args] >= 4 } {
+	switch [dg-process-target [lindex $args 1]] {
+	"S" { }
+	"N" { return }
+	"F" { setup_xfail "*-*-*" }
+	"P" { }
+	}
+}
+
+# Find nm like we find g++ in g++.exp.
+if ![info exists nm]  {
+	set nm [findfile $base_dir/../../../binutils/nm \
+		$base_dir/../../../binutils/nm \
+		[findfile $base_dir/../../nm $base_dir/../../nm \
+		 [findfile $base_dir/nm $base_dir/nm \
+		  [transform nm
+	verbose -log "nm is $nm"
+}
+
+upvar 2 name testcase
+set testcase [lindex $testcase 0]
+set output_file "[file rootname [file tail $testcase]].o"
+set output [remote_exec host "$nm" "-S $output_file"]
+set status [lindex $output 0]
+if { $status != 0 } {
+error "object-symbol-size: $nm failed"
+return
+}
+set text [lindex $output 1]
+
+set symbol [lindex $args 0]
+set match [lsearch -all $text $symbol]
+if { [llength $match] != 1 } {
+error "object-symbol-size: number of matches for $symbol: [llength $match]"
+return
+}
+
+set type [lindex $text [expr $match - 1]]
+if ![regexp {^[a-zA-Z\-\?]$} $type] {
+error "object-symbol-size: type field for $symbol not as expected: $type"
+return
+}
+
+set hex [lindex $text [expr $match - 2]]
+set actual [expr "0x$hex"]
+if ![string is integer $actual ] {
+error "object-symbol-size: size field for $symbol not as expected: $hex"
+return
+}
+verbose -log "$symbol size is $actual"
+
+set cmp [lindex $args 1]
+if { [lsearch { < > <= >= == != } $cmp] == -1 } {
+error "object-symbol-size: illegal argument: $cmp"
+return
+}
+
+set with [lindex $args 2]
+if ![string is integer $with ] {
+error "object-symbol-size: illegal argument: $with"
+return
+}
+
+if [expr $actual $cmp $with] {
+	pass "$testcase object-symbol-size $symbol $cmp $with"
+} else {
+	fail "$testcase object-symbol-size $symbol $cmp $with"
+}
+}
+
 # Utility for testing that a function is defined on the current line.
 # Call pass if so, otherwise fail.  Invoked directly; the file must
 # have been compiled with -g -dA.

[wwwdocs] Move formatting for to CSS (and add some color)

[Gerald Pfeifer]

Isn't CSS nice?  So much easier than doing things the classic way,
even when the latter used macros. :-)

Applied, and gcc.gnu.org regenerated.

Gerald

Index: gcc.css
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc.css,v
retrieving revision 1.9
diff -u -r1.9 gcc.css
--- gcc.css 4 Apr 2011 23:27:39 -   1.9
+++ gcc.css 5 Apr 2011 13:53:24 -
@@ -9,6 +9,8 @@
 a:visited { color: #bb; text-decoration: none; }
 a:hover   { color: orange;  text-decoration: none; }
 
+h1{ color: #FF8C00; text-align:center;" }
+
 dl.news dt { font-weight:bold; }
 dl.news dd { margin-left:3ex; }
 
Index: style.mhtml
===
RCS file: /cvs/gcc/wwwdocs/htdocs/style.mhtml,v
retrieving revision 1.111
diff -u -r1.111 style.mhtml
--- style.mhtml 4 Apr 2011 23:58:25 -   1.111
+++ style.mhtml 5 Apr 2011 13:53:24 -
@@ -91,14 +91,6 @@
 - GNU Project - Free Software Foundation (FSF)
 
 
-;;; Redefine the  tag to add our own style.
-
-
-
-%body
-
-
-
 ;;; Redefine the  tag introducing our own color scheme and adding an
 ;;; "about" link and a "last modified" at the bottom.
 

Re: [PATCH] allocate combine.c:LOG_LINKS in an obstack

[Nathan Froyd]

On Mon, Apr 04, 2011 at 02:49:54PM -0400, Nathan Froyd wrote:
> This patch does just what $SUBJECT suggests.

v2, now with obstacks!

Tested on x86_64-unknown-linux-gnu.  OK to commit?

-Nathan

* combine.c: Include obstack.h
(struct insn_link): Define.
(uid_log_links): Adjust type.
(FOR_EACH_LOG_LINK): New macro.
(insn_link_obstack): Declare.
(alloc_insn_link): Define.
(create_log_links): Call it.  Use FOR_EACH_LOG_LINK and adjust
type of link variables.
(find_single_use, insn_a_feeds_b, combine_instructions): Likewise.
(try_combine, record_promoted_values, distribute_notes): Likewise.
(distribute_links): Likewise.  Tweak prototype.
(clear_log_links): Delete.
(adjust_for_new_dest): Call alloc_insn_link.
* Makefile.in (combine.o): Depend on $(OBSTACK_H).

diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index 16779bd..d47a69e 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -3247,7 +3247,8 @@ combine.o : combine.c $(CONFIG_H) $(SYSTEM_H) coretypes.h 
$(TM_H) $(RTL_H) \
$(FLAGS_H) $(FUNCTION_H) insn-config.h $(INSN_ATTR_H) $(REGS_H) $(EXPR_H) \
rtlhooks-def.h $(BASIC_BLOCK_H) $(RECOG_H) hard-reg-set.h \
$(DIAGNOSTIC_CORE_H) $(TM_P_H) $(TREE_H) $(TARGET_H) output.h $(PARAMS_H) 
$(OPTABS_H) \
-   insn-codes.h $(TIMEVAR_H) $(TREE_PASS_H) $(DF_H) vecprim.h $(CGRAPH_H)
+   insn-codes.h $(TIMEVAR_H) $(TREE_PASS_H) $(DF_H) vecprim.h $(CGRAPH_H) \
+   $(OBSTACK_H)
 reginfo.o : reginfo.c $(CONFIG_H) $(SYSTEM_H) coretypes.h $(TM_H) $(RTL_H) \
hard-reg-set.h $(FLAGS_H) $(BASIC_BLOCK_H) addresses.h $(REGS_H) \
insn-config.h $(RECOG_H) reload.h $(DIAGNOSTIC_CORE_H) \
diff --git a/gcc/combine.c b/gcc/combine.c
index 37236cc..30b7fdd 100644
--- a/gcc/combine.c
+++ b/gcc/combine.c
@@ -104,6 +104,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "tree-pass.h"
 #include "df.h"
 #include "cgraph.h"
+#include "obstack.h"
 
 /* Number of attempts to combine instructions in this function.  */
 
@@ -309,13 +310,38 @@ static int max_uid_known;
 static int *uid_insn_cost;
 
 /* The following array records the LOG_LINKS for every insn in the
-   instruction stream as an INSN_LIST rtx.  */
+   instruction stream as struct insn_link pointers.  */
 
-static rtx *uid_log_links;
+struct insn_link {
+  rtx insn;
+  struct insn_link *next;
+};
+
+static struct insn_link **uid_log_links;
 
 #define INSN_COST(INSN)(uid_insn_cost[INSN_UID (INSN)])
 #define LOG_LINKS(INSN)(uid_log_links[INSN_UID (INSN)])
 
+#define FOR_EACH_LOG_LINK(L, INSN) \
+  for ((L) = LOG_LINKS (INSN); (L); (L) = (L)->next)
+
+/* Links for LOG_LINKS are allocated from this obstack.  */
+
+static struct obstack insn_link_obstack;
+
+/* Allocate a link.  */
+
+static inline struct insn_link *
+alloc_insn_link (rtx insn, struct insn_link *next)
+{
+  struct insn_link *l
+= (struct insn_link *) obstack_alloc (&insn_link_obstack,
+ sizeof (struct insn_link));
+  l->insn = insn;
+  l->next = next;
+  return l;
+}
+
 /* Incremented for each basic block.  */
 
 static int label_tick;
@@ -438,7 +464,7 @@ static int reg_dead_at_p (rtx, rtx);
 static void move_deaths (rtx, rtx, int, rtx, rtx *);
 static int reg_bitfield_target_p (rtx, rtx);
 static void distribute_notes (rtx, rtx, rtx, rtx, rtx, rtx, rtx);
-static void distribute_links (rtx);
+static void distribute_links (struct insn_link *);
 static void mark_used_regs_combine (rtx);
 static void record_promoted_value (rtx, rtx);
 static int unmentioned_reg_p_1 (rtx *, void *);
@@ -609,7 +635,7 @@ find_single_use (rtx dest, rtx insn, rtx *ploc)
   basic_block bb;
   rtx next;
   rtx *result;
-  rtx link;
+  struct insn_link *link;
 
 #ifdef HAVE_cc0
   if (dest == cc0_rtx)
@@ -635,8 +661,8 @@ find_single_use (rtx dest, rtx insn, rtx *ploc)
next = NEXT_INSN (next))
 if (INSN_P (next) && dead_or_set_p (next, dest))
   {
-   for (link = LOG_LINKS (next); link; link = XEXP (link, 1))
- if (XEXP (link, 0) == insn)
+   FOR_EACH_LOG_LINK (link, next)
+ if (link->insn == insn)
break;
 
if (link)
@@ -985,15 +1011,14 @@ create_log_links (void)
   || asm_noperands (PATTERN (use_insn)) < 0)
{
  /* Don't add duplicate links between instructions.  */
- rtx links;
- for (links = LOG_LINKS (use_insn); links;
-  links = XEXP (links, 1))
-   if (insn == XEXP (links, 0))
+ struct insn_link *links;
+ FOR_EACH_LOG_LINK (links, use_insn)
+   if (insn == links->insn)
  break;
 
  if (!links)
-   LOG_LINKS (use_insn) =
- alloc_INSN_LIST (insn, LOG_LINKS (use

[wwwdocs] Google's Summer of Code

[Gerald Pfeifer]

Ian made the very good point that we should highlight this a bit,
and suggested some wording and link.  Here we go!

Gerald

Index: index.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/index.html,v
retrieving revision 1.784
diff -u -r1.784 index.html
--- index.html  3 Apr 2011 17:18:17 -   1.784
+++ index.html  5 Apr 2011 13:58:10 -
@@ -50,6 +50,12 @@
 News
 
 
+
+GCC has been accepted to
+http://socghop.appspot.com/gsoc/org/google/gsoc2011/gcc";>Google's
+Summer of Code 2011.
+We are currently accepting student applications.
+
 March 25, 2011
 GCC 4.6.0 has been released.
 
Index: gcc.css
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc.css,v
retrieving revision 1.10
diff -u -r1.10 gcc.css
--- gcc.css 5 Apr 2011 13:55:12 -   1.10
+++ gcc.css 5 Apr 2011 13:58:10 -
@@ -11,6 +11,8 @@
 
 h1{ color: #FF8C00; text-align:center;" }
 
+.highlight{ color: #FF8C00; }
+
 dl.news dt { font-weight:bold; }
 dl.news dd { margin-left:3ex; }
 

Re: [PATCH] allocate combine.c:LOG_LINKS in an obstack

[Richard Guenther]

On Tue, Apr 5, 2011 at 3:59 PM, Nathan Froyd  wrote:
> On Mon, Apr 04, 2011 at 02:49:54PM -0400, Nathan Froyd wrote:
>> This patch does just what $SUBJECT suggests.
>
> v2, now with obstacks!
>
> Tested on x86_64-unknown-linux-gnu.  OK to commit?

Ok.

Thanks,
Richard.

> -Nathan
>
>        * combine.c: Include obstack.h
>        (struct insn_link): Define.
>        (uid_log_links): Adjust type.
>        (FOR_EACH_LOG_LINK): New macro.
>        (insn_link_obstack): Declare.
>        (alloc_insn_link): Define.
>        (create_log_links): Call it.  Use FOR_EACH_LOG_LINK and adjust
>        type of link variables.
>        (find_single_use, insn_a_feeds_b, combine_instructions): Likewise.
>        (try_combine, record_promoted_values, distribute_notes): Likewise.
>        (distribute_links): Likewise.  Tweak prototype.
>        (clear_log_links): Delete.
>        (adjust_for_new_dest): Call alloc_insn_link.
>        * Makefile.in (combine.o): Depend on $(OBSTACK_H).
>
> diff --git a/gcc/Makefile.in b/gcc/Makefile.in
> index 16779bd..d47a69e 100644
> --- a/gcc/Makefile.in
> +++ b/gcc/Makefile.in
> @@ -3247,7 +3247,8 @@ combine.o : combine.c $(CONFIG_H) $(SYSTEM_H) 
> coretypes.h $(TM_H) $(RTL_H) \
>    $(FLAGS_H) $(FUNCTION_H) insn-config.h $(INSN_ATTR_H) $(REGS_H) $(EXPR_H) \
>    rtlhooks-def.h $(BASIC_BLOCK_H) $(RECOG_H) hard-reg-set.h \
>    $(DIAGNOSTIC_CORE_H) $(TM_P_H) $(TREE_H) $(TARGET_H) output.h $(PARAMS_H) 
> $(OPTABS_H) \
> -   insn-codes.h $(TIMEVAR_H) $(TREE_PASS_H) $(DF_H) vecprim.h $(CGRAPH_H)
> +   insn-codes.h $(TIMEVAR_H) $(TREE_PASS_H) $(DF_H) vecprim.h $(CGRAPH_H) \
> +   $(OBSTACK_H)
>  reginfo.o : reginfo.c $(CONFIG_H) $(SYSTEM_H) coretypes.h $(TM_H) $(RTL_H) \
>    hard-reg-set.h $(FLAGS_H) $(BASIC_BLOCK_H) addresses.h $(REGS_H) \
>    insn-config.h $(RECOG_H) reload.h $(DIAGNOSTIC_CORE_H) \
> diff --git a/gcc/combine.c b/gcc/combine.c
> index 37236cc..30b7fdd 100644
> --- a/gcc/combine.c
> +++ b/gcc/combine.c
> @@ -104,6 +104,7 @@ along with GCC; see the file COPYING3.  If not see
>  #include "tree-pass.h"
>  #include "df.h"
>  #include "cgraph.h"
> +#include "obstack.h"
>
>  /* Number of attempts to combine instructions in this function.  */
>
> @@ -309,13 +310,38 @@ static int max_uid_known;
>  static int *uid_insn_cost;
>
>  /* The following array records the LOG_LINKS for every insn in the
> -   instruction stream as an INSN_LIST rtx.  */
> +   instruction stream as struct insn_link pointers.  */
>
> -static rtx *uid_log_links;
> +struct insn_link {
> +  rtx insn;
> +  struct insn_link *next;
> +};
> +
> +static struct insn_link **uid_log_links;
>
>  #define INSN_COST(INSN)                (uid_insn_cost[INSN_UID (INSN)])
>  #define LOG_LINKS(INSN)                (uid_log_links[INSN_UID (INSN)])
>
> +#define FOR_EACH_LOG_LINK(L, INSN)                             \
> +  for ((L) = LOG_LINKS (INSN); (L); (L) = (L)->next)
> +
> +/* Links for LOG_LINKS are allocated from this obstack.  */
> +
> +static struct obstack insn_link_obstack;
> +
> +/* Allocate a link.  */
> +
> +static inline struct insn_link *
> +alloc_insn_link (rtx insn, struct insn_link *next)
> +{
> +  struct insn_link *l
> +    = (struct insn_link *) obstack_alloc (&insn_link_obstack,
> +                                         sizeof (struct insn_link));
> +  l->insn = insn;
> +  l->next = next;
> +  return l;
> +}
> +
>  /* Incremented for each basic block.  */
>
>  static int label_tick;
> @@ -438,7 +464,7 @@ static int reg_dead_at_p (rtx, rtx);
>  static void move_deaths (rtx, rtx, int, rtx, rtx *);
>  static int reg_bitfield_target_p (rtx, rtx);
>  static void distribute_notes (rtx, rtx, rtx, rtx, rtx, rtx, rtx);
> -static void distribute_links (rtx);
> +static void distribute_links (struct insn_link *);
>  static void mark_used_regs_combine (rtx);
>  static void record_promoted_value (rtx, rtx);
>  static int unmentioned_reg_p_1 (rtx *, void *);
> @@ -609,7 +635,7 @@ find_single_use (rtx dest, rtx insn, rtx *ploc)
>   basic_block bb;
>   rtx next;
>   rtx *result;
> -  rtx link;
> +  struct insn_link *link;
>
>  #ifdef HAVE_cc0
>   if (dest == cc0_rtx)
> @@ -635,8 +661,8 @@ find_single_use (rtx dest, rtx insn, rtx *ploc)
>        next = NEXT_INSN (next))
>     if (INSN_P (next) && dead_or_set_p (next, dest))
>       {
> -       for (link = LOG_LINKS (next); link; link = XEXP (link, 1))
> -         if (XEXP (link, 0) == insn)
> +       FOR_EACH_LOG_LINK (link, next)
> +         if (link->insn == insn)
>            break;
>
>        if (link)
> @@ -985,15 +1011,14 @@ create_log_links (void)
>                       || asm_noperands (PATTERN (use_insn)) < 0)
>                    {
>                      /* Don't add duplicate links between instructions.  */
> -                     rtx links;
> -                     for (links = LOG_LINKS (use_insn); links;
> -                          links = XEXP (links, 1))
> -                       if (insn == XEXP (links, 0))
> +                     struct insn_link *links;
> + 

Re: [patch ada]: Last fix for PR ada/47163 on windows native hosts

[Charles Wilson]

On 4/5/2011 9:21 AM, Arnaud Charlet wrote:
>> I'm one of the MSys "devs" (if you want to call the sporadic process of
>> updating MSys "development").  I'll take a look at implementing
>>  ln -s file dir
>> as synonymous with
>>  ln -s file dir/basename-of-file
>> in the next few days.
> 
> Thanks, although the case we're really interested in here is:
> 
>cp -p file dir
> as equivalent to
>cp -p file dir/basename-of-file

Well, THAT already works on MSYS:

$ echo "test data" > foo
$ mkdir bar
$ cp -p foo bar
$ ls bar
foo

The problem with ln -s is this:

CYGWIN:

$ echo "test data" > foo
$ mkdir bar
$ ln -s foo bar
$ ls -l bar
total 1.0K
lrwxrwxrwx 1 owner group 3 Apr  5 09:57 foo -> foo

Note that this link, on cygwin, is broken anyway (and circular) but it
DOES succeed.  You get the same behavior on linux.

MSYS:
$ echo "test data" > foo
$ mkdir bar
$ ln -s foo bar
ln: creating symbolic link `bar/foo' to `foo': No such file or directory

This happens because MSYS's 'ln -s' (i.e. symlink(2)) can't resolve the
relative path "foo" from within the "bar" directory, so it can't figure
out how to 'fake' the symlink (MSYS always does fake symlinks, using
copy). Basically, this is a symptom of a larger issue: because MSYS
fakes symlinks using copy, there is no such thing as a "dangling
symlink" on MSYS -- and any attempt to create one will fail.

What I'm talking about is special casing this particular usage, so that
on MSYS:
$ ln -s file dir
acts like
$ cp -p file dir

Note that even on linux, if you wanted a non-dangling symlink, you'd
need to express the ln -s command as
$ ln -s ../file dir
because the path-to-target, if relative, needs to be relative from the
location of the symlink, not from the cwd.

So...is this still an issue with MSYS, or is it a bug in Ada's build
procedure that it deliberately tries to create a dangling symlink?

--
Chuck

[PATCH] Fix LTO bootstrap on i686-linux (problem with two Ldebug_info0 labels; PR bootstrap/48148)

[Jakub Jelinek]

Hi!

i686-linux LTO bootstrap currently fails, because in one partition
we emit .Ldebug_info0 label twice.  The problem is that
resolve_addr for call_site support attempts to force_decl_die external
function decls, and at least with LTO that in turn can attempt
to create new type DIEs, in this case an enumeration with context_die
being NULL.  Unfortunately the code to add proper parents to limbo nodes
is done right before resolve_addr (and should be done there, so that
resolve_addr reaches all the needed DIEs).

This patch fixes it by running over limbo_die_list nodes again if
resolve_addr created any.

LTO bootstrapped/regtested on i686-linux, ok for trunk?

2011-04-05  Jakub Jelinek  

PR bootstrap/48148
* dwarf2out.c (add_parents_for_limbo_dies): New function.
(dwarf2out_finish): Call it, and call it again if any new
limbo_die_list nodes appeared after resolve_addr.

--- gcc/dwarf2out.c.jj  2011-04-05 12:34:11.0 +0200
+++ gcc/dwarf2out.c 2011-04-05 13:34:04.628420737 +0200
@@ -23495,47 +23495,17 @@ optimize_location_lists (dw_die_ref die)
   htab_delete (htab);
 }
 
-/* Output stuff that dwarf requires at the end of every file,
-   and generate the DWARF-2 debugging info.  */
+/* Traverse the limbo die list, and add parent/child links.  The only
+   dies without parents that should be here are concrete instances of
+   inline functions, and the comp_unit_die.  We can ignore the comp_unit_die.
+   For concrete instances, we can get the parent die from the abstract
+   instance.  */
 
 static void
-dwarf2out_finish (const char *filename)
+add_parents_for_limbo_dies (void)
 {
   limbo_die_node *node, *next_node;
-  comdat_type_node *ctnode;
-  htab_t comdat_type_table;
-  unsigned int i;
-
-  gen_scheduled_generic_parms_dies ();
-  gen_remaining_tmpl_value_param_die_attribute ();
 
-  /* Add the name for the main input file now.  We delayed this from
- dwarf2out_init to avoid complications with PCH.  */
-  add_name_attribute (comp_unit_die (), remap_debug_filename (filename));
-  if (!IS_ABSOLUTE_PATH (filename))
-add_comp_dir_attribute (comp_unit_die ());
-  else if (get_AT (comp_unit_die (), DW_AT_comp_dir) == NULL)
-{
-  bool p = false;
-  htab_traverse (file_table, file_table_relative_p, &p);
-  if (p)
-   add_comp_dir_attribute (comp_unit_die ());
-}
-
-  for (i = 0; i < VEC_length (deferred_locations, deferred_locations_list); 
i++)
-{
-  add_location_or_const_value_attribute (
-VEC_index (deferred_locations, deferred_locations_list, i)->die,
-VEC_index (deferred_locations, deferred_locations_list, i)->variable,
-   false,
-   DW_AT_location);
-}
-
-  /* Traverse the limbo die list, and add parent/child links.  The only
- dies without parents that should be here are concrete instances of
- inline functions, and the comp_unit_die.  We can ignore the comp_unit_die.
- For concrete instances, we can get the parent die from the abstract
- instance.  */
   for (node = limbo_die_list; node; node = next_node)
 {
   dw_die_ref die = node->die;
@@ -23587,9 +23557,52 @@ dwarf2out_finish (const char *filename)
 }
 
   limbo_die_list = NULL;
+}
+
+/* Output stuff that dwarf requires at the end of every file,
+   and generate the DWARF-2 debugging info.  */
+
+static void
+dwarf2out_finish (const char *filename)
+{
+  limbo_die_node *node;
+  comdat_type_node *ctnode;
+  htab_t comdat_type_table;
+  unsigned int i;
+
+  gen_scheduled_generic_parms_dies ();
+  gen_remaining_tmpl_value_param_die_attribute ();
+
+  /* Add the name for the main input file now.  We delayed this from
+ dwarf2out_init to avoid complications with PCH.  */
+  add_name_attribute (comp_unit_die (), remap_debug_filename (filename));
+  if (!IS_ABSOLUTE_PATH (filename))
+add_comp_dir_attribute (comp_unit_die ());
+  else if (get_AT (comp_unit_die (), DW_AT_comp_dir) == NULL)
+{
+  bool p = false;
+  htab_traverse (file_table, file_table_relative_p, &p);
+  if (p)
+   add_comp_dir_attribute (comp_unit_die ());
+}
+
+  for (i = 0; i < VEC_length (deferred_locations, deferred_locations_list); 
i++)
+{
+  add_location_or_const_value_attribute (
+   VEC_index (deferred_locations, deferred_locations_list, i)->die,
+   VEC_index (deferred_locations, deferred_locations_list, i)->variable,
+   false,
+   DW_AT_location);
+}
+
+  add_parents_for_limbo_dies ();
 
   resolve_addr (comp_unit_die ());
 
+  /* resolve_addr might have created new DIEs.  */
+  if (limbo_die_list)
+add_parents_for_limbo_dies ();
+
   for (node = deferred_asm_name; node; node = node->next)
 {
   tree decl = node->created_for;

Jakub

Re: [PATCH] use build_function_type_list for float128 functions

[Tobias Burnus]

On 04/05/2011 03:12 PM, Nathan Froyd wrote:

When the real16/float128 bits were added to the Fortran FE, some uses of
build_function_type snuck in.  This patch changes them to use
build_function_type_list.


Thanks!


The patch also corrects a small bug: the types for frexp and scalbn had
their argument types in the wrong order.


Well spotted!


Tested on x86_64-unknown-linux-gnu.  OK to commit?


OK. Thanks for the patch!

Tobias


* trans-intrinsic.c (gfc_build_intrinsic_lib_fndecls): Use
build_function_type_list instead of build_function_type.  Correct
argument order for func_frexp and func_scalbn.

Re: [patch ada]: Last fix for PR ada/47163 on windows native hosts

[Ralf Wildenhues]

* Charles Wilson wrote on Tue, Apr 05, 2011 at 04:15:02PM CEST:
> On 4/5/2011 9:21 AM, Arnaud Charlet wrote:
> >> I'm one of the MSys "devs" (if you want to call the sporadic process of
> >> updating MSys "development").  I'll take a look at implementing
> >>ln -s file dir
> >> as synonymous with
> >>ln -s file dir/basename-of-file
> >> in the next few days.

Please use LN_S *only* in the way that it is documented.  Let me quote 'info 
Autoconf --index LN_S':

 -- Macro: AC_PROG_LN_S
 If `ln -s' works on the current file system (the operating system
 and file system support symbolic links), set the output variable
 `LN_S' to `ln -s'; otherwise, if `ln' works, set `LN_S' to `ln',
 and otherwise set it to `cp -p'.

 If you make a link in a directory other than the current
 directory, its meaning depends on whether `ln' or `ln -s' is used.
 To safely create links using `$(LN_S)', either find out which form
 is used and adjust the arguments, or always invoke `ln' in the
 directory where the link is to be created.

 In other words, it does not work to do:
  $(LN_S) foo /x/bar

 Instead, do:

  (cd /x && $(LN_S) foo bar)

Thanks,
Ralf

[libgo, build] Avoid echo -n in gotest

[Rainer Orth]

Inspecting the Solaris 8 libgo.sum file, I was reminded that echo -n
isn't portable.  The autoconf manual agrees and suggests printf as a
replacement.  The following patch implements this.

Bootstrapped on i386-pc-solaris2.8 with gas.

Rainer


2011-04-05  Rainer Orth  

* testsuite/gotest: Use printf instead of echo -n.

diff --git a/libgo/testsuite/gotest b/libgo/testsuite/gotest
--- a/libgo/testsuite/gotest
+++ b/libgo/testsuite/gotest
@@ -231,7 +231,7 @@ mkdir _test
 
 case "x$gofiles" in
 x)
-   gofiles=$(echo -n $(ls *_test.go 2>/dev/null))
+   gofiles=$(printf "%s" "$(ls *_test.go 2>/dev/null)")
 esac
 
 case "x$gofiles" in
@@ -250,7 +250,7 @@ GC="$holdGC"
 
 case "x$pkgfiles" in
 x)
-   pkgbasefiles=$(echo -n $(ls *.go | grep -v _test.go 2>/dev/null))
+   pkgbasefiles=$(printf "%s" "$(ls *.go | grep -v _test.go 2>/dev/null)")
;;
 *)
for f in $pkgfiles; do


-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: Scheduler cleanups, 5/5

[Eric Botcazou]

> The patch below fixes the testcase in the PR. I'll test
> tonight/tomorrow, probably on mips64-elf. Ok if that passes?

I get back the comparison failure with it on IA-64/Linux:

Comparing stages 2 and 3
warning: gcc/cc1-checksum.o differs
warning: gcc/cc1plus-checksum.o differs
Bootstrap comparison failure!
gcc/ada/a-elchha.o differs
gcc/ada/butil.o differs
gcc/ada/elists.o differs
gcc/ada/fmap.o differs
gcc/ada/ali.o differs
gcc/ada/fname.o differs
gcc/ada/fname-uf.o differs
gcc/ada/g-speche.o differs
gcc/ada/g-u3spch.o differs
gcc/ada/lib-util.o differs
gcc/ada/osint-c.o differs
gcc/ada/namet.o differs
gcc/ada/output.o differs
gcc/ada/osint.o differs
gcc/ada/s-os_lib.o differs
gcc/build/genhooks.o differs
gcc/build/genchecksum.o differs
libcpp/directives.o differs
libcpp/expr.o differs
libcpp/files.o differs
libcpp/lex.o differs
libcpp/mkdeps.o differs
libcpp/traditional.o differs
libdecnumber/decimal32.o differs
libdecnumber/decNumber.o differs
libiberty/pic/simple-object-coff.o differs
libiberty/pic/simple-object-elf.o differs
libiberty/pic/simple-object-mach-o.o differs
libiberty/pic/cplus-dem.o differs
libiberty/pic/cp-demangle.o differs
libiberty/pic/pex-common.o differs
libiberty/simple-object-coff.o differs
libiberty/simple-object-elf.o differs
libiberty/simple-object-mach-o.o differs
libiberty/cplus-dem.o differs
libiberty/md5.o differs
libiberty/sha1.o differs
libiberty/cp-demangle.o differs
libiberty/pex-common.o differs
lto-plugin/.libs/lto-plugin.o differs
zlib/libz_a-compress.o differs
zlib/libz_a-uncompr.o differs

This is an --enable-checking build.  For libiberty/pex-common.o:

@@ -1,5 +1,5 @@

-stage2-libiberty/pex-common.o: file format elf64-ia64-little
+stage3-libiberty/pex-common.o: file format elf64-ia64-little


 Disassembly of section .text:
@@ -1097,15 +1097,15 @@
 167c:  08 00 84 00 br.ret.sptk.many b0;;

 1680 :
-1680:  18 40 35 14 80 05   [MMB]   alloc r40=ar.pfs,13,10,0
-1686:  c0 80 33 7e 46 00   adds r12=-16,r12
-168c:  00 00 00 20 nop.b 0x0
-1690:  01 70 c0 40 00 21   [MII]   adds r14=48,r32
-1696:  70 02 00 62 00 20   mov r39=b0
-169c:  05 08 00 84 mov r41=r1;;
-16a0:  09 70 00 1c 10 10   [MMI]   ld4 r14=[r14]
-16a6:  00 00 00 02 00 60   nop.m 0x0
-16ac:  84 01 01 84 adds r35=24,r32;;
+1680:  08 40 35 14 80 05   [MMI]   alloc r40=ar.pfs,13,10,0
+1686:  c0 80 33 7e 46 e0   adds r12=-16,r12
+168c:  04 00 c4 00 mov r39=b0
+1690:  09 70 c0 40 00 21   [MMI]   adds r14=48,r32
+1696:  90 02 04 00 42 60   mov r41=r1
+169c:  84 01 01 84 adds r35=24,r32;;
+16a0:  09 00 00 00 01 00   [MMI]   nop.m 0x0
+16a6:  e0 00 38 20 20 00   ld4 r14=[r14]
+16ac:  00 00 04 00 nop.i 0x0;;
 16b0:  11 30 00 1c 87 31   [MIB]   cmp4.lt p6,p7=0,r14
 16b6:  00 00 00 02 00 03   nop.i 0x0
 16bc:  70 00 00 43   (p06) br.cond.dpnt.few 1720 
;;
@@ -1427,15 +1427,15 @@
 1d3c:  00 00 04 00 nop.i 0x0

 1d40 :
-1d40:  18 30 31 10 80 05   [MMB]   alloc r38=ar.pfs,12,8,0
-1d46:  c0 80 33 7e 46 00   adds r12=-16,r12
-1d4c:  00 00 00 20 nop.b 0x0
+1d40:  08 30 31 10 80 05   [MMI]   alloc r38=ar.pfs,12,8,0
+1d46:  c0 80 33 7e 46 a0   adds r12=-16,r12
+1d4c:  04 00 c4 00 mov r37=b0
 1d50:  09 18 01 41 00 21   [MMI]   adds r35=64,r32
-1d56:  40 82 81 00 42 a0   adds r36=48,r32
-1d5c:  04 00 c4 00 mov r37=b0;;
-1d60:  09 70 00 46 18 10   [MMI]   ld8 r14=[r35]
-1d66:  00 00 00 02 00 e0   nop.m 0x0
-1d6c:  04 08 00 84 mov r39=r1;;
+1d56:  40 82 81 00 42 e0   adds r36=48,r32
+1d5c:  04 08 00 84 mov r39=r1;;
+1d60:  09 00 00 00 01 00   [MMI]   nop.m 0x0
+1d66:  e0 00 8c 30 20 00   ld8 r14=[r35]
+1d6c:  00 00 04 00 nop.i 0x0;;
 1d70:  11 38 00 1c 06 39   [MIB]   cmp.eq p7,p6=0,r14
 1d76:  00 00 00 02 80 03   nop.i 0x0
 1d7c:  00 01 00 43   (p07) br.cond.dpnt.few 1e70 
;;


-- 
Eric Botcazou

Fix accidental reversion

[Eric Botcazou]

In June of last year I installed the change:

2010-06-06  Eric Botcazou  

* stor-layout.c (self_referential_size): Set UNKNOWN_LOCATION on the
newly built CALL_EXPR.

but it was accidentally reverted by:

2010-07-13  Nathan Froyd  

[...]
(expand_parallel_call): Call build_call_expr_loc_vec instead of
build_function_call_expr.
* stor-layout.c (self_referential_size): Likewise.


So installed again on mainline and 4.6 branch after testing on i586-suse-linux.

This helps coverage info, for example on:

   procedure To_Upper (Item : in out String) is
   begin
  Item := Ada.Characters.Handling.To_Upper (Item);
   end To_Upper;

and only affects the Ada compiler.


2011-04-05  Eric Botcazou  

* stor-layout.c (self_referential_size): Fix 2010-07-13 commit.


-- 
Eric Botcazou
Index: stor-layout.c
===
--- stor-layout.c	(revision 171942)
+++ stor-layout.c	(working copy)
@@ -367,7 +367,7 @@ self_referential_size (tree size)
   VEC_safe_push (tree, gc, size_functions, fndecl);
 
   /* Replace the original expression with a call to the size function.  */
-  return build_call_expr_loc_vec (input_location, fndecl, args);
+  return build_call_expr_loc_vec (UNKNOWN_LOCATION, fndecl, args);
 }
 
 /* Take, queue and compile all the size functions.  It is essential that

Re: [libgo, build] Avoid echo -n in gotest

[Andreas Schwab]

Rainer Orth  writes:

> diff --git a/libgo/testsuite/gotest b/libgo/testsuite/gotest
> --- a/libgo/testsuite/gotest
> +++ b/libgo/testsuite/gotest
> @@ -231,7 +231,7 @@ mkdir _test
>  
>  case "x$gofiles" in
>  x)
> - gofiles=$(echo -n $(ls *_test.go 2>/dev/null))
> + gofiles=$(printf "%s" "$(ls *_test.go 2>/dev/null)")

There is no reason to use "echo -n" in the first place, since command
substitution strips trailing newlines.  But the printf replacement keeps
internal newlines, unlike the original line.  If that is ok then this is
a useless use of printf, since you can just assign the output of the
nested command directly.

Andreas.

-- 
Andreas Schwab, sch...@redhat.com
GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84  5EC7 45C6 250E 6F00 984E
"And now for something completely different."

Re: [PATCH] cleanup gcse.c:canon_modify_mem_list

[Richard Earnshaw]

On Tue, 2011-04-05 at 07:07 -0600, Jeff Law wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On 04/05/11 06:55, Richard Earnshaw wrote:
> > 
> > On Tue, 2011-04-05 at 05:30 -0700, Nathan Froyd wrote:
> >> On Tue, Apr 05, 2011 at 01:22:39PM +0100, Richard Earnshaw wrote:
> >>> On Tue, 2011-04-05 at 04:44 -0700, Nathan Froyd wrote:
> > nit; You're missing some whitespace here (after the VEC).
> 
>  This doesn't seem to be a hard-and-fast policy; all of the VEC code I
>  remember writing or looking at recently has no spaces, and I checked the
>  patch in on that basis.  However, running grep indicates that we have a
>  profusion of styles...
> >>>
> >>> I think the style guide is quite clear on this: there should be a space
> >>> there as Jeff says.  The fact that some code has crept in with other
> >>> styles doesn't make them right, or give justification for ignoring the
> >>> style guide.
> >>
> >> Would you like a patch for the hundreds of instances without spaces?
> >>
> >> Certainly vec.h never uses spaces; I thought this was simply The Way
> >> Things Were.
> >>
> >> -Nathan
> >>
> > 
> > IMO, rototils are generally pointless.  If you are fixing code nearby
> > then yes, fix the formatting issues.  Otherwise, just don't exacerbate
> > the problem, or we'll reach the point where a rototil really does become
> > necessary.
> Well, the other approach is to have a commit hook which automatically
> deals with formatting crap by running indent, or whatever tool we want.
> 
> That would take the decision out of the hands of the developer and free
> the reviewer from having to catch such things and ensures there is a
> canonical form for our sources.

Only if a tool either

1) Has a way to over-ride it when it's being stupid, or...
2) is never stupid...

Most indent tools don't handle comments very well, IMO.  For example:

  /* Some commentary text...

Some Code Fragment

 some more commentary text.  */

if you auto-indent that, you'll often end up with the code fragment,
which was deliberately given extra indentation being moved to the same
indentation as the surrounding text.  In some cases that can lose
important information.

R.

Re: [PATCH] allocate combine.c:LOG_LINKS in an obstack

[Steven Bosscher]

On Tue, Apr 5, 2011 at 3:59 PM, Nathan Froyd  wrote:
> On Mon, Apr 04, 2011 at 02:49:54PM -0400, Nathan Froyd wrote:
>> This patch does just what $SUBJECT suggests.
>
> v2, now with obstacks!

Still one TODO in doc/rtl.texi:

@findex LOG_LINKS
@item LOG_LINKS (@var{i})
A list (chain of @code{insn_list} expressions) giving information about
dependencies between instructions within a basic block.  Neither a jump
nor a label may come between the related insns.  These are only used by
the schedulers and by combine.  This is a deprecated data structure.
Def-use and use-def chains are now preferred.

Ciao!
Steven

Re: [PATCH] allocate combine.c:LOG_LINKS in an obstack

[Nathan Froyd]

On Tue, Apr 05, 2011 at 04:42:27PM +0200, Steven Bosscher wrote:
> On Tue, Apr 5, 2011 at 3:59 PM, Nathan Froyd  wrote:
> > v2, now with obstacks!
> 
> @findex LOG_LINKS
> @item LOG_LINKS (@var{i})
> A list (chain of @code{insn_list} expressions) giving information about
> dependencies between instructions within a basic block.  Neither a jump
> nor a label may come between the related insns.  These are only used by
> the schedulers and by combine.  This is a deprecated data structure.
> Def-use and use-def chains are now preferred.

So, being somewhat RTL-ignorant, is this patch going in the wrong
direction?  Should combine be using DF instead of constructing
LOG_LINKS?

-Nathan

Re: [PATCH] Fix VTA updating in the combiner (PR debug/48343)

[Eric Botcazou]

> Alternatively, perhaps all we care about is either i3, or NEXT_INSN of the
> last debug_insn propagate_for_debug changed in an interesting way.  Thus
> propagate_for_debug could return the last DEBUG_INSN it changed, and caller
> decide either that no updating of last_modified_debug_insn is needed (that
> is the case of the pair of propagate_for_debug calls from first to last
> which just make it a lowpart subreg), or it would update it.

Maybe.  I was more or less waiting for Alexandre's take on all this. :-)

> 2011-04-04  Jakub Jelinek  
>
>   PR debug/48343
>   * combine.c (combine_instructions): Add last_combined_insn,
>   update it if insn is after it, pass it to all try_combine
>   calls.
>   (try_combine): Add last_combined_insn parameter, pass it instead of
>   i3 to propagate_for_debug.
>
>   * gcc.dg/torture/pr48343.c: New test.

This version is fine by me at least, thanks.

-- 
Eric Botcazou

[wwwdocs] Fix two blunders of mine

[Gerald Pfeifer]

That'll teach me sneaking in some wwwdocs work around lunch break.

Fixed thusly.

Gerald

Index: index.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/index.html,v
retrieving revision 1.785
retrieving revision 1.787
diff -u -r1.785 -r1.787
--- index.html  5 Apr 2011 14:00:14 -   1.785
+++ index.html  5 Apr 2011 14:18:50 -   1.786
@@ -51,6 +51,7 @@
 
 
 
+April 4, 2011
 GCC has been accepted to
 http://socghop.appspot.com/gsoc/org/google/gsoc2011/gcc";>Google's
 Summer of Code 2011.
Index: gcc.css
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc.css,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- gcc.css 5 Apr 2011 14:00:14 -   1.11
+++ gcc.css 5 Apr 2011 14:17:45 -   1.12
@@ -9,7 +9,7 @@
 a:visited { color: #bb; text-decoration: none; }
 a:hover   { color: orange;  text-decoration: none; }
 
-h1{ color: #FF8C00; text-align:center;" }
+h1{ color: #FF8C00; text-align:center; }
 
 .highlight{ color: #FF8C00; }
 

Re: [PATCH] allocate combine.c:LOG_LINKS in an obstack

[Steven Bosscher]

On Tue, Apr 5, 2011 at 4:51 PM, Nathan Froyd  wrote:
> On Tue, Apr 05, 2011 at 04:42:27PM +0200, Steven Bosscher wrote:
>> On Tue, Apr 5, 2011 at 3:59 PM, Nathan Froyd  
>> wrote:
>> > v2, now with obstacks!
>>
>> @findex LOG_LINKS
>> @item LOG_LINKS (@var{i})
>> A list (chain of @code{insn_list} expressions) giving information about
>> dependencies between instructions within a basic block.  Neither a jump
>> nor a label may come between the related insns.  These are only used by
>> the schedulers and by combine.  This is a deprecated data structure.
>> Def-use and use-def chains are now preferred.
>
> So, being somewhat RTL-ignorant, is this patch going in the wrong
> direction?

Oh, not at all. Just documentation that needs updating! :)

Ciao!
Steven

Re: [PATCH, ARM] Avoid element-order-dependent operations for quad-word vectors in big-endian mode for NEON

[Julian Brown]

On Wed, 9 Feb 2011 12:11:35 +
Julian Brown  wrote:

> On Wed, 12 Jan 2011 17:38:22 +
> Julian Brown  wrote:
> 
> > This version of the patch tweaks target-supports.exp to say that
> > various operations are not available in big-endian mode (removing
> > some of the FAILs from the previous version -- though in big-endian
> > mode without -mvectorize-with-neon-quad, some tests have
> > transitioned from PASS to XPASS. I'm not sure that's worth worrying
> > about).
> > 
> > The main part of the patch remains unchanged.
> 
> Ping?

Ping?

(Patch: http://gcc.gnu.org/ml/gcc-patches/2011-01/msg00768.html)

Thanks,

Julian

[PATCH, PR48461] define emit_use_return_register_into_block only if HAVE_return.

[Tom de Vries]

Hi,

I introduced the function emit_use_return_register_into_block for
PR43920, but should have guarded it with HAVE_return.
The patch fixes this.

Tested by doing x86_64 non-bootstrap c/fortran build.

OK for trunk?

Thanks,
- Tom
2011-04-05  Tom de Vries  

	PR middle-end/48461
	* function.c (emit_use_return_register_into_block): Only define if
	HAVE_return.
Index: gcc/function.c
===
--- gcc/function.c	(revision 171977)
+++ gcc/function.c	(working copy)
@@ -5262,6 +5262,7 @@ prologue_epilogue_contains (const_rtx in
   return 0;
 }
 
+#ifdef HAVE_return
 /* Insert use of return register before the end of BB.  */
 
 static void
@@ -5275,7 +5276,6 @@ emit_use_return_register_into_block (bas
   emit_insn_before (seq, BB_END (bb));
 }
 
-#ifdef HAVE_return
 /* Insert gen_return at the end of block BB.  This also means updating
block_for_insn appropriately.  */
 

Re: [PATCH, PR48461] define emit_use_return_register_into_block only if HAVE_return.

[Richard Guenther]

On Tue, Apr 5, 2011 at 5:50 PM, Tom de Vries  wrote:
> Hi,
>
> I introduced the function emit_use_return_register_into_block for
> PR43920, but should have guarded it with HAVE_return.
> The patch fixes this.
>
> Tested by doing x86_64 non-bootstrap c/fortran build.
>
> OK for trunk?

Ok.

Thanks,
Richard.

> Thanks,
> - Tom
>

Re: Scheduler cleanups, 5/5

[Bernd Schmidt]

On 04/05/2011 04:32 PM, Eric Botcazou wrote:
>> The patch below fixes the testcase in the PR. I'll test
>> tonight/tomorrow, probably on mips64-elf. Ok if that passes?
> 
> I get back the comparison failure with it on IA-64/Linux:

Looking into it. I ran into PR48441, I assume you were using the patch
from that as well?


Bernd

Re: [PATCH] make LABEL_DECL has its own rtx field for its associated CODE_LABEL

[Michael Matz]

Hi,

On Mon, 4 Apr 2011, Nathan Froyd wrote:

> On Mon, Apr 04, 2011 at 05:52:00PM +0200, Steven Bosscher wrote:
> > Have you looked into maybe putting the CODE_LABEL for a LABEL_DECL in
> > an on-the-side structure (hash table, whatever)? It looks like it is
> > only used during expansion of SWITCH statements.
> 
> I haven't, though it'd be easy enough once all accesses go through
> label_rtx.  I'd be equally happy doing that instead of pushing DECL_RTX
> down.

I have a preference in having just one DECL_RTL field for conceptual 
reasons:

Most DECLs are actually objects (there are some prominent exceptions, but 
those always would be better described with something like NAMED_ENTITY, 
if we had something like that, namespaces and translation_unit would 
qualify).  All these have a RTL representation, so one field for them 
seems appropriate.  That some of those don't have a size (either because 
size makes no sense or is always available via type size) hints towards a 
problem in the inheritance.  I would think it should look like so:

decl_common {}  # no size, no rtl, no align, no pt_uid
decl_with_rtl : decl_common {
  # add rtl, align, pt_uid
}
decl_with_size : decl_with_rtl {
  # add size, size_unit
}

Then decl_common can still be used for 
imported_decl/namespace/translation_unit; objects 
are at least decl_with_rtl, and some objects will be decl_with_size.


Ciao,
Michael.
5B

Re: [patch ada]: Last fix for PR ada/47163 on windows native hosts

[Charles Wilson]

On 4/5/2011 10:21 AM, Ralf Wildenhues wrote:
> * Charles Wilson wrote on Tue, Apr 05, 2011 at 04:15:02PM CEST:
>> On 4/5/2011 9:21 AM, Arnaud Charlet wrote:
 I'm one of the MSys "devs" (if you want to call the sporadic process of
 updating MSys "development").  I'll take a look at implementing
ln -s file dir
 as synonymous with
ln -s file dir/basename-of-file
 in the next few days.
> 
> Please use LN_S *only* in the way that it is documented.  Let me quote 'info 
> Autoconf --index LN_S':
> 
>  -- Macro: AC_PROG_LN_S
>  If `ln -s' works on the current file system (the operating system
>  and file system support symbolic links), set the output variable
>  `LN_S' to `ln -s'; otherwise, if `ln' works, set `LN_S' to `ln',
>  and otherwise set it to `cp -p'.
> 
>  If you make a link in a directory other than the current
>  directory, its meaning depends on whether `ln' or `ln -s' is used.
>  To safely create links using `$(LN_S)', either find out which form
>  is used and adjust the arguments, or always invoke `ln' in the
>  directory where the link is to be created.
> 
>  In other words, it does not work to do:
>   $(LN_S) foo /x/bar
> 
>  Instead, do:
> 
>   (cd /x && $(LN_S) foo bar)

OK, so you're saying "don't 'fix' MSys's ln -s behavior since doing so
would contravene normal expectations"

However, as Arno pointed out, right now for MSys LN_S is defined as "cp
-p" so it appears that "ln -s" behavior is a red herring.

This confuses me, because as I demonstrated earlier:

$ cp -p file dir

*works* on MSys.  So, I think we need more information from Kai about
WHAT exactly is failing here.  He claims that
cp -p file dir
fails for him (and, wants to 'fix' it by adding -r, which implies that
some element of the foreach statement resolves to a *dir*, not a *file*
-- but Arno says that is not the case. /me = confused...)

What version of coreutils, and msys, are you using, Kai?  I tested with
msys-1.0.16 and coreutils-5.97-3.  Contact me offlist if you want help
running these details down.


As a side issue, it ALSO seems to me that Ada's Mafile.in is doing it
wrong, given Ralf's statements above:

# Copy target independent sources
$(foreach f,$(ADA_INCLUDE_SRCS) $(LIBGNAT_SRCS), \
  $(LN_S) $(fsrcpfx)ada/$(f) $(RTSDIR) ;) true

But as this isn't shell code (some sort of Ada buildfile? I'm not
familiar with building Ada), I'm not sure exactly how to "fix" it in the
event LN_S is ACTUALLY defined as "ln -s" or "ln" (which, recall, is NOT
the case on MSYS, which apparently uses cp -p).

--
Chuck

Re: Scheduler cleanups, 5/5

[Jeff Law]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 04/05/11 09:54, Bernd Schmidt wrote:
> On 04/05/2011 04:32 PM, Eric Botcazou wrote:
>>> The patch below fixes the testcase in the PR. I'll test
>>> tonight/tomorrow, probably on mips64-elf. Ok if that passes?
>>
>> I get back the comparison failure with it on IA-64/Linux:
> 
> Looking into it. I ran into PR48441, I assume you were using the patch
> from that as well?
Bernd,

Any comparison failures with --disable-checking or
- --enable-checking=release configured trees should be sent my way.
There's a bug in a change of mine from last week which will cause these
kinds of problems.  No sense in you duplicating the work I've already
done to track those problems down.

jeff
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJNmz5lAAoJEBRtltQi2kC7drwH/RnGeuX9h35n6N0tn9J0tWsy
iIM83r1Okh/1+YfT4MIpYAStY/tPMgvKoppiqXrqgB8lBHoEcY0I4E58GWjt2fI6
+rbhwPR3Fpc3Fn9/FM0K+ulHhFjPhgdvag/OI6PBXQzfXCdnS4gLUd2c5dEXDOFz
FnSjp6yPYP7GtTfaVJOj7vKvzYsvECI5FB+VJgSTDB1PNlhjTIDSU9VxDTWxvdXj
ywrwZiNr3fXrVMb9rJVrOk0nXVjkPaKq7GEmDxHeIaXxNZqOXc1il014/zObVDHe
aIaRLewui/19MX3OtJFPYeFCM9MqsAaip4JwgF/peSp9pjD+IzNct6k4k9riWwI=
=IBZn
-END PGP SIGNATURE-

Re: Scheduler cleanups, 5/5

[Bernd Schmidt]

On 04/05/2011 06:08 PM, Jeff Law wrote:
> On 04/05/11 09:54, Bernd Schmidt wrote:
>> On 04/05/2011 04:32 PM, Eric Botcazou wrote:
 The patch below fixes the testcase in the PR. I'll test
 tonight/tomorrow, probably on mips64-elf. Ok if that passes?
>>>
>>> I get back the comparison failure with it on IA-64/Linux:
> 
>> Looking into it. I ran into PR48441, I assume you were using the patch
>> from that as well?
> Bernd,
> 
> Any comparison failures with --disable-checking or
> --enable-checking=release configured trees should be sent my way.
> There's a bug in a change of mine from last week which will cause these
> kinds of problems.  No sense in you duplicating the work I've already
> done to track those problems down.

Well, I need to test the scheduler patch posted three messages or so
previously, on either mips64 or ia64, so might as well try to bootstrap
on gcc60.


Bernd

Re: [patch ada]: Last fix for PR ada/47163 on windows native hosts

[Arnaud Charlet]

> As a side issue, it ALSO seems to me that Ada's Mafile.in is doing it
> wrong, given Ralf's statements above:
> 
>   # Copy target independent sources
> $(foreach f,$(ADA_INCLUDE_SRCS) $(LIBGNAT_SRCS), \
>   $(LN_S) $(fsrcpfx)ada/$(f) $(RTSDIR) ;) true
> 
> But as this isn't shell code (some sort of Ada buildfile? I'm not
> familiar with building Ada),

This is standard GNU make code.

> I'm not sure exactly how to "fix" it in the
> event LN_S is ACTUALLY defined as "ln -s" or "ln" (which, recall, is NOT
> the case on MSYS, which apparently uses cp -p).

There is nothing broken here as far as I can tell, so nothing to "fix" here.

Arno

Re: [PATCH] allocate combine.c:LOG_LINKS in an obstack

[Jeff Law]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 04/05/11 08:51, Nathan Froyd wrote:
> On Tue, Apr 05, 2011 at 04:42:27PM +0200, Steven Bosscher wrote:
>> On Tue, Apr 5, 2011 at 3:59 PM, Nathan Froyd  
>> wrote:
>>> v2, now with obstacks!
>>
>> @findex LOG_LINKS
>> @item LOG_LINKS (@var{i})
>> A list (chain of @code{insn_list} expressions) giving information about
>> dependencies between instructions within a basic block.  Neither a jump
>> nor a label may come between the related insns.  These are only used by
>> the schedulers and by combine.  This is a deprecated data structure.
>> Def-use and use-def chains are now preferred.
> 
> So, being somewhat RTL-ignorant, is this patch going in the wrong
> direction?  Should combine be using DF instead of constructing
> LOG_LINKS?
Ideally, we'd like to get rid of LOG_LINKS in favor of DF; however, I
don't think anyone has looked at what would be needed to make that
happen for combine.c or at what the memory & compile-time implications
might be for such a change.

I still think your patch is a step forward as it should reduce the load
on the garbage collector.

Jeff
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJNmz+iAAoJEBRtltQi2kC7NQAH/0GKXSsi3aOoZ/TCYYa2FIpI
CfFPLaE9lXfXkFLNIXrVKcWC+NkqbLcFxEQFLusyfQAU4Aqcc0sxFEg69hSCJLPG
EWCUBhLqd3YbHpv3pLkykV0nOrd8wBqt24NCbLKaALsNkyvWUGx/hsM3O2lUUbAJ
YnUmuyAzx2e5fSQ1WZvfNVb2/GXe7/p0QEDCq/yWf1l/6Pide4EtjWy4NPCbx1C9
AI+P+sqHWwmd6wPzTZTLamOlFCg0QNXwhSJ5eYL0WBkLjuxE9M4EHPiVuyta1Y8c
xkCOspGxsq6UdNycM6aGprlHS8uX8O5s4i//lTx/xq5U4n5USKLe3SbLn3Qk9MM=
=h8QI
-END PGP SIGNATURE-

Re: Scheduler cleanups, 5/5

[Jeff Law]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 04/05/11 10:10, Bernd Schmidt wrote:
> On 04/05/2011 06:08 PM, Jeff Law wrote:
>> On 04/05/11 09:54, Bernd Schmidt wrote:
>>> On 04/05/2011 04:32 PM, Eric Botcazou wrote:
> The patch below fixes the testcase in the PR. I'll test
> tonight/tomorrow, probably on mips64-elf. Ok if that passes?

 I get back the comparison failure with it on IA-64/Linux:
>>
>>> Looking into it. I ran into PR48441, I assume you were using the patch
>>> from that as well?
>> Bernd,
>>
>> Any comparison failures with --disable-checking or
>> --enable-checking=release configured trees should be sent my way.
>> There's a bug in a change of mine from last week which will cause these
>> kinds of problems.  No sense in you duplicating the work I've already
>> done to track those problems down.
> 
> Well, I need to test the scheduler patch posted three messages or so
> previously, on either mips64 or ia64, so might as well try to bootstrap
> on gcc60.
In which case, if you're not using checking, you'll want the attached
patch to avoid comparison failures with --disable-checking.  I felt like
a bloody idiot when I finally saw what I'd done...




-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJNm0AgAAoJEBRtltQi2kC7UloH/1Z+zEV26u9m6FZ++57nXJbE
TedMoL+C/Kvefd2HBpIdN+Jgz+bsEgauOIyCbAuodhHbqkODDuIbdHmx6f5xn+V1
SjMWzCaxNiJdCinPYFqe/Mb1+hHz3s7iEsPjhj4EQ91Tx7/Xv/qPbU8qimSL6zhy
51l2RH+jNMgapHw+7QhMwVfY6oCI0hvbHMY6+Ly2oG16yxPt9RKJyp8o+q2zlFB1
WVD7EvkoaMg+wQAlXnV8scslKeoUE/aJOnGfOXnuaiEWPterE7Ku4JE8xz0P+PWA
k4JoBeII+vR89ofpXjeG1Ei0vzXQjFHKgPUxkfmNiWMhM6uioQ+PK/GVYW0YPkw=
=tiZC
-END PGP SIGNATURE-
Index: tree-ssa-threadupdate.c
===
*** tree-ssa-threadupdate.c (revision 171989)
--- tree-ssa-threadupdate.c (working copy)
*** determine_bb_domination_status (struct l
*** 665,671 
edge_iterator ei;
edge e;
  
- #ifdef ENABLE_CHECKING
/* This function assumes BB is a successor of LOOP->header.
   If that is not the case return DOMST_NONDOMINATING which
   is always safe.  */
--- 665,670 
*** determine_bb_domination_status (struct l
*** 684,690 
if (!ok)
return DOMST_NONDOMINATING;
  }
- #endif
  
if (bb == loop->latch)
  return DOMST_DOMINATING;
--- 683,688 

Re: [PATCH] cleanup gcse.c:canon_modify_mem_list

[Jeff Law]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 04/05/11 05:44, Nathan Froyd wrote:
> On Mon, Apr 04, 2011 at 12:01:09PM -0600, Jeff Law wrote:
>>> +  canon_modify_mem_list = GCNEWVEC (VEC(modify_pair,heap) *,
>>> +   last_basic_block);
>> nit; You're missing some whitespace here (after the VEC).
> 
> This doesn't seem to be a hard-and-fast policy; all of the VEC code I
> remember writing or looking at recently has no spaces, and I checked the
> patch in on that basis.  However, running grep indicates that we have a
> profusion of styles...
In a codebase as big as GCC, violations tends to slip in.If/when you
see stuff, we'd love to see patches which fix such problems.

jeff
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJNm0EOAAoJEBRtltQi2kC72/gH+gO3bpEldTzuEblKU5XGyhRw
h92X43nPb7qZ/9SaH9RI+zc0XGRAclwqja7X360kFmC/b06AMTbakmsBkcIZDFUj
MhXnt5jsOtQGAA4UlA1rPaUTA8IPN+QzIfIe8puN8Yf/W5Q0nxxKzJPbujXLkK0o
+5dB8CXUOYQ0rAfkzleEUSdPi0iKm8wvg13HY83Q52EZvUQ3aWcxFPmXA0oIaz+v
FQVhjjzr4YvHd2MaomofWC/t246bLVB+L6ofZnjh0jkhAikC0/z+FLG8en0VfGhr
0it6/hRIchlZfRV6jh/dN6vLR+NwP8FHwG25O/G+jnPRbut3fw3BaaQr4n3dnTQ=
=vAx7
-END PGP SIGNATURE-

Re: [PATCH] make LABEL_DECL has its own rtx field for its associated CODE_LABEL

[Nathan Froyd]

On Tue, Apr 05, 2011 at 05:55:33PM +0200, Michael Matz wrote:
> I have a preference in having just one DECL_RTL field for conceptual 
> reasons:
> 
> Most DECLs are actually objects (there are some prominent exceptions, but 
> those always would be better described with something like NAMED_ENTITY, 
> if we had something like that, namespaces and translation_unit would 
> qualify).  All these have a RTL representation, so one field for them 
> seems appropriate.  That some of those don't have a size (either because 
> size makes no sense or is always available via type size) hints towards a 
> problem in the inheritance.  I would think it should look like so:
> 
> decl_common {}  # no size, no rtl, no align, no pt_uid
> decl_with_rtl : decl_common {
>   # add rtl, align, pt_uid
> }
> decl_with_size : decl_with_rtl {
>   # add size, size_unit
> }
> 
> Then decl_common can still be used for 
> imported_decl/namespace/translation_unit; objects 
> are at least decl_with_rtl, and some objects will be decl_with_size.

This is what I was heading for, but I hadn't fully worked out how to
switch around the inheritance structure.  Thanks!

Consider this patch dropped, then; I'll work towards something like the
above instead.

-Nathan

Re: [PATCH] make gcse.c:modify_mem_list hold VECs instead of INSN_LISTs

[Jeff Law]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 04/05/11 07:20, Nathan Froyd wrote:
> As promised, this patch turns modify_mem_list into an array of VECs,
> similar to the changes done to canon_modify_mem_list.  Since I'm in the
> area, I took the liberty of tweaking the VEC declarations related to
> canon_modify_mem_list to have spaces before parens, as folks seem to
> think that's the right way to write them.
> 
> Tested on x86_64-unknown-linux-gnu.  OK to commit?
> 
> -Nathan
> 
>   * gcse.c (modify_mem_list): Convert to an array of VECs.
>   (canon_modify_mem_list, compute_transp): Tweak formatting.
>   (alloc_gcse_mem): Likewise.  Adjust for modify_mem_list change.
>   (load_killed_in_block_p): Likewise.
>   (record_last_mem_set_info): Likewise.
>   (clear_modify_mem_tables): Likewise.
OK.
jeff
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJNm0K4AAoJEBRtltQi2kC74eMH/1MKEULO+359JWwgaUem37o/
0LLmKqpxzE+FIYcUjvR0zWdI6kFI+sXBPCPv5RZqEKDq5Pdyh0StcIAoxGmPfahI
dwsypKr8zrtE28ItcsqDdMNT2j9/Ec3iJ3mB12m5b68S6y2u7l+LDCcD2Zb+L4g6
t0Btxks4PuypOTJppLSrbJ3ke6IcaXekS0VgVsEatqHIHVx/Goo6dYcAMs/3azBm
8Z0VVlSpneQ/mpTy8ltJ4e0PGUEE2qJ7HTPIkqdccWhj97KxpDARFKR3VSPw4jio
9FYJSr83+1ti1wzFBbr/x4lbT4gYc+HKF77uIM1dGXbNse+gVKjehR9VEX66WNI=
=7T4j
-END PGP SIGNATURE-

Re: Scheduler cleanups, 5/5

[Steve Ellcey]

On Tue, 2011-04-05 at 17:54 +0200, Bernd Schmidt wrote:
> On 04/05/2011 04:32 PM, Eric Botcazou wrote:
> >> The patch below fixes the testcase in the PR. I'll test
> >> tonight/tomorrow, probably on mips64-elf. Ok if that passes?
> > 
> > I get back the comparison failure with it on IA-64/Linux:
> 
> Looking into it. I ran into PR48441, I assume you were using the patch
> from that as well?
> 
> 
> Bernd

Hm, I just tried a bootstrap build on IA64 HP-UX using the haifa-sched.c
patch and r171988 and I got this error during stage 2:


/proj/opensrc_nobackup/sje/reg/src/trunk/gcc/genautomata.c: In function 'create_
automata':
/proj/opensrc_nobackup/sje/reg/src/trunk/gcc/genautomata.c:6678:1: internal comp
iler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[3]: *** [build/genautomata.o] Error 1
make[3]: Leaving directory `/proj/opensrc_nobackup/sje/reg/build-ia64-hp-hpux11.
23-trunk/obj_gcc/gcc'
make[2]: *** [all-stage2-gcc] Error 2

I added Jeff Law's patch to tree-ssa-threadupdate.c but that didn't change this
error.

I don't seem to be able to reproduce this on IA64 Linux.

Steve Ellcey
s...@cup.hp.com

Re: [patch ada]: Last fix for PR ada/47163 on windows native hosts

[Charles Wilson]

On 4/5/2011 12:11 PM, Arnaud Charlet wrote:
>> As a side issue, it ALSO seems to me that Ada's Mafile.in is doing it
>> wrong, given Ralf's statements above:
>>
>>  # Copy target independent sources
>> $(foreach f,$(ADA_INCLUDE_SRCS) $(LIBGNAT_SRCS), \
>>   $(LN_S) $(fsrcpfx)ada/$(f) $(RTSDIR) ;) true
>>
>> But as this isn't shell code (some sort of Ada buildfile? I'm not
>> familiar with building Ada),
> 
> This is standard GNU make code.

Sorry, I always have to check the manual for the more unusual features
of make...like everything in Functions:: node.

>> I'm not sure exactly how to "fix" it in the
>> event LN_S is ACTUALLY defined as "ln -s" or "ln" (which, recall, is NOT
>> the case on MSYS, which apparently uses cp -p).
> 
> There is nothing broken here as far as I can tell, so nothing to "fix" here.

According to 'info Autoconf --index LN_S' as quoted by Ralf, it is not
*portable* to do
$(LN_S) a_file a_dir
because it behaves differently depending on whether LN_S is "ln -s",
"ln" (or, as in this case, "cp -p"). This:
$(LN_S) $(fsrcpfx)ada/$(f) $(RTSDIR)
fits that non-portable pattern -- assuming $(f) is always a file, and
$(RTSDIR) is actually a directory.  Ralf recommends that, for
portability, it should be changed to something like

(cd $(RTSDIR) && $(LN_S) ??? $(basename $(f)) )

The only problem is how to express $(fsrcpfx)ada/$(f) as a relative path
from RTSDIR, or as an absolute path (maybe that's not a problem; I'm
unsure how fsrcpfx is defined).

--
Chuck

Re: [patch ada]: Last fix for PR ada/47163 on windows native hosts

[Arnaud Charlet]

> According to 'info Autoconf --index LN_S' as quoted by Ralf, it is not
> *portable* to do
>   $(LN_S) a_file a_dir
> because it behaves differently depending on whether LN_S is "ln -s",
> "ln" (or, as in this case, "cp -p").

That is certainly true.

> This:
>   $(LN_S) $(fsrcpfx)ada/$(f) $(RTSDIR)
> fits that non-portable pattern

That's wrong. The above is

$(LN_S) /full/path/to/a_file a_dir

which is quite different from

$(LN_S) a_file a_dir

and will work equally well with ln or ln -s or cp -p.

> Ralf recommends that, for
> portability, it should be changed to something like

And I recommend that we do nothing here because there's nothing broken.

Arno

Re: [patch ada]: Last fix for PR ada/47163 on windows native hosts

[Charles Wilson]

On 4/5/2011 12:50 PM, Arnaud Charlet wrote:
>> This:
>>  $(LN_S) $(fsrcpfx)ada/$(f) $(RTSDIR)
>> fits that non-portable pattern
> 
> That's wrong. The above is
> 
> $(LN_S) /full/path/to/a_file a_dir
> 
> which is quite different from
> 
> $(LN_S) a_file a_dir
> 
> and will work equally well with ln or ln -s or cp -p.

A-HA! That's what I was missing; $a_file was an absolute path.
But...that works on MSYS too, with LN_S equal to all of those possibilities:

$ echo "test data" > /tmp/foo
$ ls -li /tmp/foo
3625195 -rw-r--r-- 1 owner group 10 Apr  5 12:53 /tmp/foo

$ mkdir bar
$ ln -s /tmp/foo bar
$ ls -li bar
total 1
2969862 -rw-r--r-- 1 owner group 10 Apr  5 12:53 foo

(Note that foo is NOT actually a symlink here, because of MSys's fake
behavior. It's a copy)

$ rm -rf bar
$ mkdir bar
$ ln /tmp/foo bar
$ ls -li bar
3625195 -rw-r--r-- 2 owner group 10 Apr  5 12:53 bar

(Note: in this case it is actually a hardlink -- and the link count has
increased. MSys supports hardlinks on NTFS file systems, with all the
usual caveats -- same device, etc)

$ rm -rf bar
$ mkdir bar
$ cp -p /tmp/foo bar
$ ls -li bar
total 1
1397010 -rw-r--r-- 1 owner group 10 Apr  5 12:53 foo


So, we really really need more info from Kai about WHAT exactly is
failing here.


>> Ralf recommends that, for
>> portability, it should be changed to something like
> 
> And I recommend that we do nothing here because there's nothing broken.

Ack.

--
Chuck

Re: Scheduler cleanups, 5/5

[Steve Ellcey]

On Tue, 2011-04-05 at 09:41 -0700, Steve Ellcey wrote:

> Hm, I just tried a bootstrap build on IA64 HP-UX using the haifa-sched.c
> patch and r171988 and I got this error during stage 2:
> 
> 
> /proj/opensrc_nobackup/sje/reg/src/trunk/gcc/genautomata.c: In function 
> 'create_
> automata':
> /proj/opensrc_nobackup/sje/reg/src/trunk/gcc/genautomata.c:6678:1: internal 
> comp
> iler error: Segmentation fault
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See  for instructions.
> make[3]: *** [build/genautomata.o] Error 1
> make[3]: Leaving directory 
> `/proj/opensrc_nobackup/sje/reg/build-ia64-hp-hpux11.
> 23-trunk/obj_gcc/gcc'
> make[2]: *** [all-stage2-gcc] Error 2
> 
> I added Jeff Law's patch to tree-ssa-threadupdate.c but that didn't change 
> this
> error.
> 
> I don't seem to be able to reproduce this on IA64 Linux.

I was able to reproduce it on my Linux system.  I thought my build had
already gotten past the point where this was happening but it hadn't.  I
get this on IA64 HP-UX and Linux with the proposed haifa-sched.c change.

Steve Ellcey
s...@cup.hp.com

Re: [PATCH] Fix VTA updating in the combiner (PR debug/48343)

[Alexandre Oliva]

On Apr  4, 2011, Jakub Jelinek  wrote:

> Alternatively, perhaps all we care about is either i3, or NEXT_INSN of
> the last debug_insn propagate_for_debug changed in an interesting way.

Ideally, we'd like to identify all debug users of i2dest (or whatever
DEF we're removing) and propagate into them, even if they are e.g. in
different blocks or after i3.

IIRC stopping at i3 is a trade-off that avoids making the analysis more
complex, just because we know i2dest, if removed, isn't used after i3
any more, although it might still be used in debug insns.  I don't
recall how/when(/whether) we adjust those afterwards.

Anyhow, I don't quite understand what makes the retry case special.
Each try_combine call (and its debug propagations) are supposed to be
self-contained.  If we dropped a SET, we should adjust all debug uses of
its SET_DEST; if we didn't drop it, no adjustment is needed.  It seems
to me that extending the range might even cause us to modify
e.g. unrelated uses of the same pseudo, no?  Isn't the problem perhaps
that we are failing to adjust some debug insns at an earlier call?

-- 
Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/   FSF Latin America board member
Free Software Evangelist  Red Hat Brazil Compiler Engineer

Re: [lto, testsuite] Don't use visibility on targets that don't support it (PR lto/47334)

[Mike Stump]

On Apr 5, 2011, at 1:56 AM, Rainer Orth wrote:
>  * lto.c (promote_var): Only set VISIBILITY_HIDDEN if
>   HAVE_GAS_HIDDEN.

This looks wrong, there are more things that have visibility than those things 
that use GAS and have .hidden.  Darwin I think is one of them.  ?  cygming.h 
seems to be another.

Re: [lto, testsuite] Don't use visibility on targets that don't support it (PR lto/47334)

[Mike Stump]

On Apr 5, 2011, at 1:56 AM, Rainer Orth wrote:
>   * lto.c (promote_var): Only set VISIBILITY_HIDDEN if
>   HAVE_GAS_HIDDEN.

Oh, at a minimum, if TARGET_ASM_ASSEMBLE_VISIBILITY is set, doing this stuff I 
think is useful?

[Patch, Fortran] PR 18918 - Fix/Add multi-image support to UCOBOUND

[Tobias Burnus]

This patch adds multi-image support to UCOBOUND. In the -fcoarray=single 
case, the last dimension is just "LCOARRAY (coarray, dim=corank)". 
However, if there are multiple images, one has for corank-1 coarrays: 
"lcobound(coarray) + num_images() -1" and for multi-rank coarrays for 
the last dimension "lcobound(coarray, dim=corank) + ceiling (real 
(num_images ()) / real (size)) - 1", where size is the product of the 
extends in all but the last codimension.


Well, that's actually all the patch does. (Except that "ceiling(N/S)-1" 
is replaced by "(N+S-1)/S-1" = "(N-1)/S".)


Build an regtested on x86-64-linux.
OK for the trunk?

(Sorry, no test case. I think one should soon start to create a 
-fcoarray=lib version of the test suite, where one passes the link (e.g. 
"$DIR/mpi.o $MPI_LIB" or "$DIR/single.o") and run command (e.g. "mpiexec 
-n 3" or "") via environment variables.)


Tobias

PS: We should soon work again on the regressions. Currently there are 10 
regressions of which 6 are GCC 4.6/4.7 regressions - and 1 is 4.7 only. 
We should fix all of the 4.6/4.7 regressions before the GCC 4.6.1 release!


PPS: Maybe someone understands why UCOBOUND(corank_1_coarray) for which 
one has the pseudo code:

   D = [codim=1].lbound + num_image - 1
gets translated as:
   D.1571 = (integer(kind=4)) (((character(kind=4)) 
parm.2.dim[NON_LVALUE_EXPR  + 1].lbound + (character(kind=4)) 
_gfortran_caf_num_images.4) + 4294967295);


Namely: Why are there all those casts to "character(kind=4)" and why is 
"+ (-1)" converted into 4294967295? The result surely works, but the 
dump looks odd.
2011-04-05  Tobias Burnus  

	PR fortran/18918
	* simplify.c (simplify_bound_dim): Exit for
	ucobound's last dimension unless -fcoarray=single.
	* trans-array (gfc_conv_descriptor_size_1): Renamed from
	gfc_conv_descriptor_size, made static, has now from_dim and
	to_dim arguments.
	(gfc_conv_descriptor_size): Call gfc_conv_descriptor_size.
	(gfc_conv_descriptor_cosize): New function.
	* trans-array.h (gfc_conv_descriptor_cosize): New prototype.
	* trans-intrinsic.c (conv_intrinsic_cobound): Add input_location
	and handle last codim of ucobound for when -fcoarray is not "single".

diff --git a/gcc/fortran/simplify.c b/gcc/fortran/simplify.c
index 2a99445..abc3383 100644
--- a/gcc/fortran/simplify.c
+++ b/gcc/fortran/simplify.c
@@ -3298,7 +3298,8 @@ simplify_bound_dim (gfc_expr *array, gfc_expr *kind, int d, int upper,
 
   /* The last dimension of an assumed-size array is special.  */
   if ((!coarray && d == as->rank && as->type == AS_ASSUMED_SIZE && !upper)
-  || (coarray && d == as->rank + as->corank))
+  || (coarray && d == as->rank + as->corank
+	  && (!upper || gfc_option.coarray == GFC_FCOARRAY_SINGLE)))
 {
   if (as->lower[d-1]->expr_type == EXPR_CONSTANT)
 	{
diff --git a/gcc/fortran/trans-array.c b/gcc/fortran/trans-array.c
index 0046d0a..f8e26b0 100644
--- a/gcc/fortran/trans-array.c
+++ b/gcc/fortran/trans-array.c
@@ -4055,17 +4055,17 @@ gfc_conv_array_extent_dim (tree lbound, tree ubound, tree* or_expr)
 
 
 /* For an array descriptor, get the total number of elements.  This is just
-   the product of the extents along all dimensions.  */
+   the product of the extents along from_dim to to_dim.  */
 
-tree
-gfc_conv_descriptor_size (tree desc, int rank)
+static tree
+gfc_conv_descriptor_size_1 (tree desc, int from_dim, int to_dim)
 {
   tree res;
   int dim;
 
   res = gfc_index_one_node;
 
-  for (dim = 0; dim < rank; ++dim)
+  for (dim = from_dim; dim < to_dim; ++dim)
 {
   tree lbound;
   tree ubound;
@@ -4083,6 +4083,24 @@ gfc_conv_descriptor_size (tree desc, int rank)
 }
 
 
+/* Full size of an array.  */
+
+tree
+gfc_conv_descriptor_size (tree desc, int rank)
+{
+  return gfc_conv_descriptor_size_1 (desc, 0, rank);
+}
+
+
+/* Size of a coarray for all dimensions but the last.  */
+
+tree
+gfc_conv_descriptor_cosize (tree desc, int rank, int corank)
+{
+  return gfc_conv_descriptor_size_1 (desc, rank, rank + corank - 1);
+}
+
+
 /* Helper function for marking a boolean expression tree as unlikely.  */
 
 static tree
diff --git a/gcc/fortran/trans-array.h b/gcc/fortran/trans-array.h
index 1b35759..fef56ae 100644
--- a/gcc/fortran/trans-array.h
+++ b/gcc/fortran/trans-array.h
@@ -164,3 +164,4 @@ void gfc_trans_string_copy (stmtblock_t *, tree, tree, int, tree, tree, int);
 /* Calculate extent / size of an array.  */
 tree gfc_conv_array_extent_dim (tree, tree, tree*);
 tree gfc_conv_descriptor_size (tree, int);
+tree gfc_conv_descriptor_cosize (tree, int, int);
diff --git a/gcc/fortran/trans-intrinsic.c b/gcc/fortran/trans-intrinsic.c
index 9a69632..0c2ce51 100644
--- a/gcc/fortran/trans-intrinsic.c
+++ b/gcc/fortran/trans-intrinsic.c
@@ -1170,10 +1170,10 @@ conv_intrinsic_cobound (gfc_se * se, gfc_expr * expr)
   tree_rank = gfc_conv_mpz_to_tree (mpz_rank, gfc_index_integer_kind);
 
   bound = se->loop->loopvar[0];
-  bound = fold_build2 (PLUS_EXPR, gfc_array_index_type, bound,

Re: [PATCH] Fix VTA updating in the combiner (PR debug/48343)

[Jakub Jelinek]

On Tue, Apr 05, 2011 at 02:24:55PM -0300, Alexandre Oliva wrote:
> On Apr  4, 2011, Jakub Jelinek  wrote:
> 
> > Alternatively, perhaps all we care about is either i3, or NEXT_INSN of
> > the last debug_insn propagate_for_debug changed in an interesting way.
> 
> Ideally, we'd like to identify all debug users of i2dest (or whatever
> DEF we're removing) and propagate into them, even if they are e.g. in
> different blocks or after i3.

If they are in different blocks, then either there must be some other
use of the pseudo in real code after that (but then combine won't do such
replacements), or DF would have resetted those debug_insns referencing it
(or replaced the pseudos in there with a debug temporary set before the last
real use), otherwise debug insns would change the liveness of the pseudo.

> IIRC stopping at i3 is a trade-off that avoids making the analysis more
> complex, just because we know i2dest, if removed, isn't used after i3
> any more, although it might still be used in debug insns.  I don't
> recall how/when(/whether) we adjust those afterwards.

The change mode of pseudos propagation can't be a best effort, we really
must change all the pseudos (or reset debug_insns containing them),
otherwise the RTL in the insns might be invalid.
The other changes we propagate are best effort, if we don't change all,
and some pseudo remains referenced only in debug insns and not really set
in real code or used anywhere, next DF recomputation will just reset them.
Of course the less often that happens, the better.

> Anyhow, I don't quite understand what makes the retry case special.
> Each try_combine call (and its debug propagations) are supposed to be
> self-contained.  If we dropped a SET, we should adjust all debug uses of
> its SET_DEST; if we didn't drop it, no adjustment is needed.  It seems
> to me that extending the range might even cause us to modify
> e.g. unrelated uses of the same pseudo, no?  Isn't the problem perhaps
> that we are failing to adjust some debug insns at an earlier call?

The reason why retry case is special is that without any previous
propagate_for_debug calls we know that e.g. in the change mode case,
the pseudo can't be referenced before i2 and after i3 where i2 is
the single setter of the pseudo and i3 is the single (non-debug) user.
Otherwise RTL would not be valid before combiner.  But with some previous
propagate_for_debug calls in the same bb that guarantee (as the testcase
shows) is no longer true.  We might have propagate_for_debug, replacing
some i2dest with i2src in between i2 and i3, then goto retry with new
i3' being somewhere before previous i3.  We change mode of the pseudo
that was present in old i2src, but if we stop looking for debug insns
at i3', there might be some debug insn in between i3' and i3 that
references that pseudo.

Jakub

Re: Scheduler cleanups, 5/5

[Eric Botcazou]

> Looking into it. I ran into PR48441, I assume you were using the patch
> from that as well?

It's yesterday's tree + your 2 patches to haifa-sched.c, so without Steven's 
patch... at least it was supposed to be, but I screwed up, sorry about that.

After having done another round of testing, let me recap:
  1. yesterday's pristine tree yields the bootstrap comparison failure on the 
IA-64/Linux machine,
  2. yesterday's pristine tree + your 2 patches to haifa-sched.c successfully 
bootstraps on the IA-64/Linux machine.

-- 
Eric Botcazou

[PATCH] use use_reg in several backends

[Nathan Froyd]

Several places in the compiler could be usefully modified to use use_reg
instead of hand-building EXPR_LISTs.  This patch makes such changes.

Since this patch implements equivalent functionality with an existing
function call, I believe it counts as obvious.

Tested by building cc1 for appropriate targets.  Will commit in a day or
two after giving maintainers a chance for comments.

-Nathan

* config/alpha/alpha.c (alpha_emit_xfloating_libcall): Call use_reg.
* config/xtensa/xtensa.c (xtensa_call_tls_desc): Likewise.
* config/sparc/sparc.c (sparc_legitimize_tls_address): Likewise.

diff --git a/gcc/config/alpha/alpha.c b/gcc/config/alpha/alpha.c
index 8aabeb2..d34042e 100644
--- a/gcc/config/alpha/alpha.c
+++ b/gcc/config/alpha/alpha.c
@@ -2999,7 +2999,7 @@ alpha_emit_xfloating_libcall (rtx func, rtx target, rtx 
operands[],
}
 
   emit_move_insn (reg, operands[i]);
-  usage = alloc_EXPR_LIST (0, gen_rtx_USE (VOIDmode, reg), usage);
+  use_reg (&usage, reg);
 }
 
   switch (GET_MODE (target))
diff --git a/gcc/config/xtensa/xtensa.c b/gcc/config/xtensa/xtensa.c
index 5623cc1..fe70270 100644
--- a/gcc/config/xtensa/xtensa.c
+++ b/gcc/config/xtensa/xtensa.c
@@ -1872,9 +1872,7 @@ xtensa_call_tls_desc (rtx sym, rtx *retp)
   emit_insn (gen_tls_arg (arg, sym));
   emit_move_insn (a10, arg);
   call_insn = emit_call_insn (gen_tls_call (a10, fn, sym, const1_rtx));
-  CALL_INSN_FUNCTION_USAGE (call_insn)
-= gen_rtx_EXPR_LIST (VOIDmode, gen_rtx_USE (VOIDmode, a10),
-CALL_INSN_FUNCTION_USAGE (call_insn));
+  use_reg (&CALL_INSN_FUNCTION_USAGE (call_insn), a10);
   insns = get_insns ();
   end_sequence ();

diff --git a/gcc/config/sparc/sparc.c b/gcc/config/sparc/sparc.c
index 1e7ce53..ecb4d25 100644
--- a/gcc/config/sparc/sparc.c
+++ b/gcc/config/sparc/sparc.c
@@ -3308,9 +3308,7 @@ sparc_legitimize_tls_address (rtx addr)
insn = emit_call_insn (gen_tgd_call64 (o0, sparc_tls_get_addr (),
   addr, const1_rtx));
  }
-CALL_INSN_FUNCTION_USAGE (insn)
- = gen_rtx_EXPR_LIST (VOIDmode, gen_rtx_USE (VOIDmode, o0),
-  CALL_INSN_FUNCTION_USAGE (insn));
+   use_reg (&CALL_INSN_FUNCTION_USAGE (insn), o0);
insn = get_insns ();
end_sequence ();
emit_libcall_block (insn, ret, o0, addr);
@@ -3338,9 +3336,7 @@ sparc_legitimize_tls_address (rtx addr)
insn = emit_call_insn (gen_tldm_call64 (o0, sparc_tls_get_addr (),
const1_rtx));
  }
-CALL_INSN_FUNCTION_USAGE (insn)
- = gen_rtx_EXPR_LIST (VOIDmode, gen_rtx_USE (VOIDmode, o0),
-  CALL_INSN_FUNCTION_USAGE (insn));
+   use_reg (&CALL_INSN_FUNCTION_USAGE (insn), o0);
insn = get_insns ();
end_sequence ();
emit_libcall_block (insn, temp3, o0,

Re: [PATCH] don't use TYPE_ARG_TYPES in type_generic or sentinel attribute handling

[Eric Botcazou]

> gcc/ada/
>   * gcc-interface/utils.c (handle_sentinel_attribute): Don't use
>   TYPE_ARG_TYPES
>   (handle_type_generic_attribute): Likewise.

This code is very likely a duplicate of the one in c-common.c so Joseph's 
approval counts for it as well.

-- 
Eric Botcazou

Re: Scheduler cleanups, 5/5

[Steve Ellcey]

On Tue, 2011-04-05 at 19:48 +0200, Eric Botcazou wrote:
> > Looking into it. I ran into PR48441, I assume you were using the patch
> > from that as well?
> 
> It's yesterday's tree + your 2 patches to haifa-sched.c, so without Steven's 
> patch... at least it was supposed to be, but I screwed up, sorry about that.
> 
> After having done another round of testing, let me recap:
>   1. yesterday's pristine tree yields the bootstrap comparison failure on the 
> IA-64/Linux machine,
>   2. yesterday's pristine tree + your 2 patches to haifa-sched.c successfully 
> bootstraps on the IA-64/Linux machine.

What are the two patches to haifa-sched.c?  I have one patch to
schedule_block from
http://gcc.gnu.org/ml/gcc-patches/2011-04/msg00271.html
but that patch (alone or with the Jeff Law patch) isn't working for me
on IA64 Linux.  Is there a second haifa-sched.c patch I should also
have?

Steve Ellcey
s...@cup.hp.com

Re: [PATCH] use use_reg in several backends

[Eric Botcazou]

>   * config/sparc/sparc.c (sparc_legitimize_tls_address): Likewise.

Fine with me, thanks.

-- 
Eric Botcazou

Re: [PATCH] cleanup gcse.c:canon_modify_mem_list

[Mike Stump]

On Apr 5, 2011, at 5:55 AM, Richard Earnshaw wrote:
> IMO, rototils are generally pointless.

As a counter point, I like polish and style, in addition to beauty and 
flexibility.  I'd rather see more style cleanups, more polish cleanups and more 
beautiful cleanups.  I'd like to see more, not less people doing that work.  
I'd like to see more maintainership status give out on that basis.  I like 
rototils.  This is the mechanism by which we give a uniformity to the code, 
make it predictable, easier to work, easier to copy from.

Re: [lto, testsuite] Don't use visibility on targets that don't support it (PR lto/47334)

[Rainer Orth]

Mike Stump  writes:

> On Apr 5, 2011, at 1:56 AM, Rainer Orth wrote:
>>  * lto.c (promote_var): Only set VISIBILITY_HIDDEN if
>>  HAVE_GAS_HIDDEN.
>
> This looks wrong, there are more things that have visibility than those 
> things that use GAS and have .hidden.  Darwin I think is one of them.  ?  
> cygming.h seems to be another.

As for many of the HAVE_GAS_* macros, this one is a misnomer: it simply
describes if the target assembler has visibility support (at least for
many targets).

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: Scheduler cleanups, 5/5

[Eric Botcazou]

> What are the two patches to haifa-sched.c?  I have one patch to
> schedule_block from
> http://gcc.gnu.org/ml/gcc-patches/2011-04/msg00271.html
> but that patch (alone or with the Jeff Law patch) isn't working for me
> on IA64 Linux.  Is there a second haifa-sched.c patch I should also
> have?

No, the important point is that I'm using yesterday's tree, so the first patch 
is Bernd's patch from yesterday (r171942).

-- 
Eric Botcazou