[PATCH, RFC] Start on making rs6000 target support create builtins on the fly

[Michael Meissner]

This patch is the beginning stages of my revamp of the builtin function
handling in the rs6000 port.  When I added target attribute support in GCC 4.6,
I ran out of time in tackling enabling builtin functions if the user says a
function is to be compiled for a different target machine.  These patches are
not yet ready for checkin, but I was wondering if the general concept is ok
before I start converting all of the builtins.

At this point, I'm just trying to move all of information in the various bdesc
arrays and *_init_builtin functions into rs6000-builtins.def.  I have created a
new macro RS6000_BUILTIN_ARGS that takes all of the information I think we will
need to create the new builtin.  While it would be nice to have a grand new
machine independent way of doing this, but I figure that can come in time.  I
would prefer not to miss the 4.7 window.

At the moment, I just have __builtin_altivec_vadd{ubm,uhm,fp} converted to the
new style.  So any comments on just these pieces before I start creating all of
the builtins.

One thing that irrates me about the current setup is the fact that we are out
of target_flags bits, and paired/spe builtins have special handling.  I haven't
gone through the rs6000.opts to see if we can squeeze 2 more bits in the masks,
but I provided an alternate solution here that does not need them to be
re-integrated.

2011-08-12  Michael Meissner  

* config/rs6000/rs6000-builtin.def (RS6000_BUILTIN_ARGS): New
macros to encode types within the macros, so that we can process
the builtins as a single table, instead of being spread out over
several different functions.  Start converting the Altivec add
functions to the new scheme.
(RS6000_BUILTIN_ARG0): Ditto.
(RS6000_BUILTIN_ARG1): Ditto.
(RS6000_BUILTIN_ARG2): Ditto.
(RS6000_BUILTIN_ARG2): Ditto.
(RS6000_BUILTIN_ARG3): Ditto.

* config/rs6000/rs6000.c (rs6000_builtin_decls_init): New static
array to record the builtin functions that have been created, even
if the current machine does not support the function.
(builtin_info): New array to hold all of the information for
creating builtin functions.
(builtin_classify): Delete, merge into builtin_info.
(def_builtin): Use builtin_info instead of builtin_classify.
(bdesc_2arg): Remove Altivec add functions moved over to the new
format.
(rs6000_expand_builtin): Add support for generating builtin
functions from a table.
(rs6000_create_builtin): New function, create a builtin function
from the table of builtins.
(rs6000_table_init_builtins): New function to create the builtins
that are in the builtin table.

* config/rs6000/rs6000.h (enum rs6000_btmask): Masks of the
various conditions for creating builtins.
(enum rs6000_btc): Add typedef.
(enum rs6000_builtin_type_index): Ditto.
(enum rs6000_builtins): Define RS6000_BUILTIN_ARGS for new builtin
handling.
(RS6000_BTI_NONE): New name for no type provided.
(RS6000_BTI_NOT_OPAQUE): Map into RS6000_BTI_NONE.


-- 
Michael Meissner, IBM
5 Technology Place Drive, M/S 2757, Westford, MA 01886-3141, USA
meiss...@linux.vnet.ibm.com fax +1 (978) 399-6899
Index: gcc/config/rs6000/rs6000-builtin.def
===
--- gcc/config/rs6000/rs6000-builtin.def(revision 177676)
+++ gcc/config/rs6000/rs6000-builtin.def(working copy)
@@ -26,7 +26,74 @@
 
 /* Before including this file, two macros must be defined:
RS6000_BUILTIN   -- 2 arguments, the enum name, and classification
-   RS6000_BUILTIN_EQUATE -- 2 arguments, enum name and value */
+   RS6000_BUILTIN_EQUATE -- 2 arguments, enum name and value
+
+   RS6000_BUILTIN_ARGS  -- 9 arguments:
+   argument 1, the string name of the builtin function
+   argument 2, the enum name
+   argument 3, the insn code for the function that implments this
+   argument 4, the classification
+   argument 5, the mask for whether the builtin should be used
+   argument 6, RS6000_BTI index for return value
+   arguments 7-9, RS6000_BTI index for 1-3 arguments.  */
+
+#ifndef RS6000_BUILTIN_ARG0
+#define RS6000_BUILTIN_ARG0(STR, NAME, ICODE, CLASS, MASK, RET)
\
+  RS6000_BUILTIN_ARGS(STR, \
+ NAME, \
+ ICODE,\
+ CLASS,\
+ MASK, \
+ RET,  \
+ RS6000_BTI_NONE,  \
+ RS6000_BTI_NONE,  \
+   

Re: [PATCH] Make VRP optimize useless conversions

[H.J. Lu]

On Mon, Jul 11, 2011 at 5:12 AM, Richard Guenther  wrote:
> On Fri, 8 Jul 2011, Richard Guenther wrote:
>
>> On Fri, 8 Jul 2011, Michael Matz wrote:
>>
>> > Hi,
>> >
>> > On Fri, 8 Jul 2011, Richard Guenther wrote:
>> >
>> > > It should be indeed safe with the current handling of conversions, but
>> > > better be safe.  So, like the following?
>> >
>> > No.  The point is that you can't compare the bounds that VRP computes with
>> > each other when the outcome affects correctness.  Think about a very
>> > trivial and stupid VRP, that assigns the range [WIDEST_INT_MIN ..
>> > WIDEST_UINT_MAX] to each and every SSA name without looking at types and
>> > operations at all (assuming that this reflects the largest int type on the
>> > target).  It's useless but correct.  Of course we wouldn't implement such
>> > useless range discovery, but similar situations can arise when some VRP
>> > algorithms give up for certain reasons, or computation of tight bounds
>> > merely isn't implemented for some operations.
>> >
>> > Your routines need to work also in the presence of such imprecise ranges.
>> >
>> > Hence, the check that the intermediate conversion is useless needs to take
>> > into account the input value range (that's conservatively correct), and
>> > the precision and signedness of the target type (if it can represent all
>> > value of the input range the conversion was useless).  It must not look at
>> > the suspected value range of the destination, precisely because it is
>> > conservative only.
>>
>> Ok, indeed conservative is different for what VRP does and for what
>> a transformation must assess.  So the following patch makes
>> a conservative attempt at checking the transformation (which of
>> course non-surprisingly matches what the VRP part does).
>>
>> So, more like the following?
>
> The following actually works.
>
> Bootstrapped and tested on x86_64-unknown-linux-gnu.
>
> Can you double-check it?
>
> Thanks,
> Richard.
>
> 2011-07-11  Richard Guenther  
>
>        * tree-vrp.c (simplify_conversion_using_ranges): Manually
>        translate the source value-range through the conversion chain.
>

This may have caused:

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

-- 
H.J.

Re: [cxx-mem-model] alternate fetch operations

[Andrew MacLeod]

On 08/12/2011 07:05 PM, Richard Henderson wrote:

On 08/11/2011 02:42 PM, Andrew MacLeod wrote:

The names for the previous set implies the fetch is done before the
operation, so the new ones simply drop the fetch and simply use the
operation name. I found sync_mem_op_fetch slightly less clear.

Really?  I guess I'm pretty used to that, and it also makes it
abundantly clear what the difference between s_m_fetch_add and
s_m_add really is.

On balance I think we're better off sticking closer to the
original __sync_{fetch_op,op_fetch} names.

Does anyone else have an opinion on this naming?


Otherwise the patch looks ok.


Actually, I think I will change the names.  I discovered as i was 
delving deeper that the rtl sync_ patterns are set up differently as 
well. the actually builtins are more explicit, and they specify it more 
clearly...  To match them, I will change them to :


__sync_mem_fetch_and_add
__sync_mem_add_and_fetch


At some point in the future when everything is working and there are 
less pressing issues, I will attempt to consolidate everything in some 
consistent fashion.


Andrew

[PATCH] update my email address

[Sebastian Pop]

Hi,
as I am not working anymore at AMD, I will commit the following patch.

Sebastian

---
 MAINTAINERS |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 3c7e8a9..ec0579d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -225,9 +225,9 @@ tree-ssaAndrew MacLeod  
amacl...@redhat.com
 PREDaniel Berlin   dber...@dberlin.org
 code sinking   Daniel Berlin   dber...@dberlin.org
 mudflapFrank Ch. Eiglerf...@redhat.com
-tree browser/unparser  Sebastian Pop   sebastian@amd.com
+tree browser/unparser  Sebastian Pop   seb...@gmail.com
 scev, data dependence  Daniel Berlin   dber...@dberlin.org
-scev, data dependence  Sebastian Pop   sebastian@amd.com
+scev, data dependence  Sebastian Pop   seb...@gmail.com
 profile feedback   Jan Hubicka j...@suse.cz
 type-safe vectors  Nathan Sidwell  nat...@codesourcery.com
 alias analysis Daniel Berlin   dber...@dberlin.org
@@ -279,7 +279,7 @@ Fortran Janus Weil  
ja...@gcc.gnu.org
 gengtype/GTY   Laurynas Biveinis   laurynas.bivei...@gmail.com
 Graphite   Daniel Berlin   dber...@dberlin.org
 Graphite   Tobias Grosser  gros...@fim.uni-passau.de
-Graphite   Sebastian Pop   sebastian@amd.com
+Graphite   Sebastian Pop   seb...@gmail.com
 libcpp Tom Tromey  tro...@redhat.com
 loop optimizer Zdenek Dvorak   o...@ucw.cz
 Plugin Diego Novillo   dnovi...@google.com
-- 
1.7.4.1

Re: [cxx-mem-model] alternate fetch operations

[Richard Henderson]

On 08/11/2011 02:42 PM, Andrew MacLeod wrote:
> The names for the previous set implies the fetch is done before the
> operation, so the new ones simply drop the fetch and simply use the
> operation name. I found sync_mem_op_fetch slightly less clear.

Really?  I guess I'm pretty used to that, and it also makes it 
abundantly clear what the difference between s_m_fetch_add and
s_m_add really is.

On balance I think we're better off sticking closer to the
original __sync_{fetch_op,op_fetch} names.

Does anyone else have an opinion on this naming?


Otherwise the patch looks ok.


r~

Re: [Patch,AVR]: Fix PR49903

[Hans-Peter Nilsson]

On Thu, 11 Aug 2011, Georg-Johann Lay wrote:

> This is an optimization in machine dependent reorg to
> remove redundant comparisons like in
>
>cc0 = compare (Reg, Num)
>if (cc0 == 0)
>  goto L1
>
>cc0 = compare (Reg, Num)
>if (cc0 > 0)
>  goto L2
>
> The second comparison is redundant an can be removed.
> Code like this can be seen in binary decision switch/case
> expansion.

A glance at AVR makes me think this should already be handled by
the NOTICE_UPDATE_CC machinery.  Any analysis why this doesn't
happen?  With the same test-case (at -Os) I don't see redundant
compares for cris-elf, for example.

brgds, H-P

Re: [PATCH] PR ada/50048: "cc1: note: obsolete option -I- used, please use -iquote instead" during bootstrap

[Ludovic Brenta]

Andrew Pinski writes:
> This is wrong as -iquote takes an operand.  So it is eating up -I. for
> the -iquote.  You have to replace all of the -I after -I- with
> -iquote.

OK, here is an amended patch.  I don't dare call it "trivial" anymore :)
(Note that even the "wrong" patch solved the problem reported on Debian,
though).

2011-08-11  Ludovic Brenta  

PR ada/50048
* gcc-interface/Makefile.in (INCLUDES): replace -I- with
-iquote.

Index: b/src/gcc/ada/gcc-interface/Makefile.in
===
--- a/src/gcc/ada/gcc-interface/Makefile.in
+++ b/src/gcc/ada/gcc-interface/Makefile.in
@@ -247,8 +247,8 @@
 # Both . and srcdir are used, in that order,
 # so that tm.h and config.h will be found in the compilation
 # subdirectory rather than in the source directory.
-INCLUDES = -I- -I. -I.. -I$(srcdir)/ada -I$(srcdir) -I$(srcdir)/config \
-   -I$(srcdir)/../include
+INCLUDES = -iquote . -iquote .. -iquote $(srcdir)/ada -iquote$(srcdir) \
+   -iquote $(srcdir)/config -iquote $(srcdir)/../include
 
 ADA_INCLUDES = -I- -I. -I$(srcdir)/ada
 

C++ PATCH for c++/50034 (wrong error on passing to ... in unevaluated context)

[Jason Merrill]

G++ was complaining about performing the lvalue-rvalue conversion on an 
lvalue of abstract type, which is correct when the conversion is 
potentially evaluated, but as it turns out, not in unevaluated context.


Tested x86_64-pc-linux-gnu, applying to trunk.
commit 28e405968ae794fcb73d2946a6c83bde167cc2ae
Author: Jason Merrill 
Date:   Fri Aug 12 00:37:14 2011 -0400

	PR c++/50034
	* call.c (convert_arg_to_ellipsis): force_rvalue only in
	potentially evaluated context.

diff --git a/gcc/cp/call.c b/gcc/cp/call.c
index a3b0f8a..e8fb68d 100644
--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -6097,7 +6097,7 @@ convert_arg_to_ellipsis (tree arg)
 {
   /* Build up a real lvalue-to-rvalue conversion in case the
 	 copy constructor is trivial but not callable.  */
-  if (CLASS_TYPE_P (arg_type))
+  if (!cp_unevaluated_operand && CLASS_TYPE_P (arg_type))
 	force_rvalue (arg, tf_warning_or_error);
 
   /* [expr.call] 5.2.2/7:
diff --git a/gcc/testsuite/g++.dg/cpp0x/defaulted28.C b/gcc/testsuite/g++.dg/cpp0x/defaulted28.C
index 15caef6..bcbf763 100644
--- a/gcc/testsuite/g++.dg/cpp0x/defaulted28.C
+++ b/gcc/testsuite/g++.dg/cpp0x/defaulted28.C
@@ -1,4 +1,5 @@
 // PR c++/49102
+// PR c++/50034
 // { dg-options -std=c++0x }
 
 struct A {
@@ -8,8 +9,9 @@ private:
   A(A const&) = default;	// { dg-error "private" }
 };
 
-void f(...) { }
+int f(...) { }
 int main() {
   A a;
   f(a); 			// { dg-error "this context" }
+  sizeof(f(a));			// OK because unevaluated
 }

Re: Commit: RX: Add support for conditional register moves

[Richard Henderson]

On 08/11/2011 05:19 AM, Nick Clifton wrote:
> Hi Guys,
> 
>   I am applying the patch below on behalf of Renesas.  It adds support
>   to the RX backend for conditional register moves.
> 
>   Tested without any regressions on an rx-elf toolchain.
> 
> Cheers
>   Nick
> 
> gcc/ChangeLog
> 2011-08-11   Kazuhiro Inaoka  
> 
>   * config/rx/rx.md (movsicc): Allow register to register
>   transfers.
>   (*movsicc): Likewise.
>   (*stcc): Restrict this pattern to EQ and NE compares.
>   (*stcc_reg): New pattern.  Works for any comparison but only for
>   register transfers.
> 
> Index: gcc/config/rx/rx.md
> ===
> --- gcc/config/rx/rx.md   (revision 177584)
> +++ gcc/config/rx/rx.md   (working copy)
> @@ -1598,7 +1598,7 @@
>  (memex_commutative:SI (match_dup 0)
>(match_dup 2)))
> (clobber (reg:CC CC_REG))])]
> -  "peep2_regno_dead_p (2, REGNO (operands[0]))"
> +  "peep2_regno_dead_p (2, REGNO (operands[0])) && (optimize < 3 || 
> optimize_size)"

The patch doesn't match the changelog.  And this looks very wrong...

r~

Fix rtl-opt/49994 -- sched_ebb vs unwind info

[Richard Henderson]

Extra dependencies are needed to avoid creating incorrect unwind info.
See the patch and the PR for more details.

Tested on x86_64-linux.  Committed.


r~
diff --git a/gcc/sched-deps.c b/gcc/sched-deps.c
index 2961cca..ed592c8 100644
--- a/gcc/sched-deps.c
+++ b/gcc/sched-deps.c
@@ -2696,6 +2696,18 @@ sched_analyze_insn (struct deps_desc *deps, rtx x, rtx 
insn)
 add_dependence_list (insn, deps->last_function_call_may_noreturn,
 1, REG_DEP_ANTI);
 
+  /* We must avoid creating a situation in which two successors of the
+ current block have different unwind info after scheduling.  If at any
+ point the two paths re-join this leads to incorrect unwind info.  */
+  /* ??? There are certain situations involving a forced frame pointer in
+ which, with extra effort, we could fix up the unwind info at a later
+ CFG join.  However, it seems better to notice these cases earlier
+ during prologue generation and avoid marking the frame pointer setup
+ as frame-related at all.  */
+  if (RTX_FRAME_RELATED_P (insn))
+deps->sched_before_next_jump
+  = alloc_INSN_LIST (insn, deps->sched_before_next_jump);
+
   if (code == COND_EXEC)
 {
   sched_analyze_2 (deps, COND_EXEC_TEST (x), insn);
@@ -3302,12 +3314,11 @@ deps_analyze_insn (struct deps_desc *deps, rtx insn)
   if (NONDEBUG_INSN_P (insn))
 sched_get_condition_with_rev (insn, NULL);
 
-  if (NONJUMP_INSN_P (insn) || DEBUG_INSN_P (insn) || JUMP_P (insn))
+  if (JUMP_P (insn))
 {
   /* Make each JUMP_INSN (but not a speculative check)
  a scheduling barrier for memory references.  */
   if (!deps->readonly
-  && JUMP_P (insn)
   && !(sel_sched_p ()
&& sel_insn_is_speculation_check (insn)))
 {
@@ -3326,6 +3337,15 @@ deps_analyze_insn (struct deps_desc *deps, rtx insn)
}
 }
 
+  /* For each insn which shouldn't cross a jump, add a dependence.  */
+  add_dependence_list_and_free (deps, insn,
+   &deps->sched_before_next_jump, 1,
+   REG_DEP_ANTI);
+
+  sched_analyze_insn (deps, PATTERN (insn), insn);
+}
+  else if (NONJUMP_INSN_P (insn) || DEBUG_INSN_P (insn))
+{
   sched_analyze_insn (deps, PATTERN (insn), insn);
 }
   else if (CALL_P (insn))
@@ -3571,6 +3591,7 @@ init_deps (struct deps_desc *deps, bool lazy_reg_last)
   deps->last_function_call = 0;
   deps->last_function_call_may_noreturn = 0;
   deps->sched_before_next_call = 0;
+  deps->sched_before_next_jump = 0;
   deps->in_post_call_group_p = not_post_call;
   deps->last_debug_insn = 0;
   deps->last_reg_pending_barrier = NOT_A_BARRIER;
diff --git a/gcc/sched-int.h b/gcc/sched-int.h
index 1e5c71e..6797397 100644
--- a/gcc/sched-int.h
+++ b/gcc/sched-int.h
@@ -496,6 +496,9 @@ struct deps_desc
  scheduling is done.  */
   rtx sched_before_next_call;
 
+  /* Similarly, a list of insns which should not cross a branch.  */
+  rtx sched_before_next_jump;
+
   /* Used to keep post-call pseudo/hard reg movements together with
  the call.  */
   enum post_call_group in_post_call_group_p;

Re: [ARM] Fix minipool handling of aligned labels

[Richard Sandiford]

Steven Bosscher  writes:
> On Thu, Aug 11, 2011 at 1:56 PM, Richard Sandiford
>  wrote:
>
>> gcc/
>>        * config/arm/arm.c (get_label_padding): New function.
>>        (create_fix_barrier, md_reorg): Likewise.
>
> The ChangeLog doesn't match the patch:
> * create_fix_barrier is not a new function.
> * md_reorg should be arm_reorg

Sorry, now fixed.

Richard

Re: [rfa] Set alignment of pseudos via get_pointer_alignment

[Richard Guenther]

On Fri, Aug 12, 2011 at 6:04 PM, Michael Matz  wrote:
> Hi,
>
> On Tue, 9 Aug 2011, Michael Matz wrote:
>
>> > Are there any updates on the libada problem or other reasons why the
>> > patch cannot go in?
>>
>> Nope, I've solved that one.  Letme update it.
>
> Like so.  Regstrapped on x86_64-linux (all languages + Ada).  Okay for
> trunk?

Ok.

Thanks,
Richard.

>
> Ciao,
> Michael.
> --
>        * cfgexpand.c (expand_one_register_var): Use get_pointer_alignment.
>        (gimple_expand_cfg): Merge alignment info for coalesced pointer
>        SSA names.
>
> Index: cfgexpand.c
> ===
> --- cfgexpand.c (revision 177696)
> +++ cfgexpand.c (working copy)
> @@ -909,7 +909,7 @@ expand_one_register_var (tree var)
>     mark_user_reg (x);
>
>   if (POINTER_TYPE_P (type))
> -    mark_reg_pointer (x, TYPE_ALIGN (TREE_TYPE (type)));
> +    mark_reg_pointer (x, get_pointer_alignment (var));
>  }
>
>  /* A subroutine of expand_one_var.  Called to assign rtl to a VAR_DECL that
> @@ -4265,6 +4265,31 @@ gimple_expand_cfg (void)
>        }
>     }
>
> +  /* If we have a class containing differently aligned pointers
> +     we need to merge those into the corresponding RTL pointer
> +     alignment.  */
> +  for (i = 1; i < num_ssa_names; i++)
> +    {
> +      tree name = ssa_name (i);
> +      int part;
> +      rtx r;
> +
> +      if (!name
> +         || !POINTER_TYPE_P (TREE_TYPE (name))
> +         /* We might have generated new SSA names in
> +            update_alias_info_with_stack_vars.  They will have a NULL
> +            defining statements, and won't be part of the partitioning,
> +            so ignore those.  */
> +         || !SSA_NAME_DEF_STMT (name))
> +       continue;
> +      part = var_to_partition (SA.map, name);
> +      if (part == NO_PARTITION)
> +       continue;
> +      r = SA.partition_to_pseudo[part];
> +      if (REG_P (r))
> +       mark_reg_pointer (r, get_pointer_alignment (name));
> +    }
> +
>   /* If this function is `main', emit a call to `__main'
>      to run global initializers, etc.  */
>   if (DECL_NAME (current_function_decl)
>

Re: [PATCH 2/2] document ISL requirement for GCC installation

[Sven Verdoolaege]

On Fri, Aug 12, 2011 at 03:30:25PM -0400, Jack Howarth wrote:
> Skimo,
>Currently we don't have any checks for the minimal isl version required.

I assume they will be added at some point.
AFAIU, Sebastian just started working on this.
It will take some time for him to finish the transition.

Anyway, I'm not involved in graphite development.
I was just asked to review some patches on their use of isl.

skimo

Re: primary vtable not initialized properly

[Jason Merrill]

On 08/11/2011 08:06 PM, Xinliang David Li wrote:

A new patch with lightly modified the test case.



   if (lost)
 BV_LOST_PRIMARY (*virtuals) = true;
+  else
+BV_LOST_PRIMARY (*virtuals) = false;


Might as well just do

BV_LOST_PRIMARY (*virtuals) = lost;

OK for trunk and 4.6 with that change.

Jason

Re: [PATCH 2/2] document ISL requirement for GCC installation

[Sven Verdoolaege]

On Fri, Aug 12, 2011 at 07:28:52PM +, Joseph S. Myers wrote:
> On Fri, 12 Aug 2011, Sven Verdoolaege wrote:
> 
> > On Fri, Aug 12, 2011 at 07:16:55PM +, Joseph S. Myers wrote:
> > > Do you mean there is not only a requirement to build both libraries, but 
> > > there is a requirement to build CLooG *first*, then ISL, so that ISL's 
> > > libisl.a overwrites CLooG's rather than the other way round (supposing 
> > > that they are installed in the same prefix)?
> > 
> > No.  You build isl first and configure CLooG to use that isl.
> 
> Will CLooG give an error if you configure it in such a way that its isl 
> would overwrite one previously installed?  If not, this seems too 
> error-prone - there's no obvious way for CLooG to know whether a 
> previously installed isl comes from a previous installation of CLooG 
> (should be overwritten) or was installed on its own (so CLooG should be 
> built to use it).

If CLooG is told to use a previously built isl, it won't even compile
the bundled isl.

skimo

Re: [PATCH 2/2] document ISL requirement for GCC installation

[Jack Howarth]

On Fri, Aug 12, 2011 at 09:22:04PM +0200, Sven Verdoolaege wrote:
> On Fri, Aug 12, 2011 at 07:16:55PM +, Joseph S. Myers wrote:
> > Do you mean there is not only a requirement to build both libraries, but 
> > there is a requirement to build CLooG *first*, then ISL, so that ISL's 
> > libisl.a overwrites CLooG's rather than the other way round (supposing 
> > that they are installed in the same prefix)?
> 
> No.  You build isl first and configure CLooG to use that isl.
> 
> skimo

Skimo,
   Currently we don't have any checks for the minimal isl version required.
Since the proposed patches only include a requirement for cloog 0.16.3, this
clearly is insufficent to force the use of the correct isl version. Will isl
continue to be bundled with cloog such that the required version of both isl
and cloog will be determined from the cloog version numbering?
 Jack

Re: [PATCH 2/2] document ISL requirement for GCC installation

[Joseph S. Myers]

On Fri, 12 Aug 2011, Sven Verdoolaege wrote:

> On Fri, Aug 12, 2011 at 07:16:55PM +, Joseph S. Myers wrote:
> > Do you mean there is not only a requirement to build both libraries, but 
> > there is a requirement to build CLooG *first*, then ISL, so that ISL's 
> > libisl.a overwrites CLooG's rather than the other way round (supposing 
> > that they are installed in the same prefix)?
> 
> No.  You build isl first and configure CLooG to use that isl.

Will CLooG give an error if you configure it in such a way that its isl 
would overwrite one previously installed?  If not, this seems too 
error-prone - there's no obvious way for CLooG to know whether a 
previously installed isl comes from a previous installation of CLooG 
(should be overwritten) or was installed on its own (so CLooG should be 
built to use it).

The requirements for how CLooG is configured need to be clearly documented 
in GCC's documentation.  But, first, all these proposals (starting with 
the one to use CLooG-ISL instead of CLooG-PPL) need to be raised in their 
own threads on the gcc list, making clear exactly what is proposed, how it 
has been tested on different hosts and how many versions the requirements 
are expected to be stable for - patch submission should be the very last 
stage after sufficient discussion (and notice to the many GCC builders who 
may not follow gcc-patches) on the gcc list.

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

Re: [PATCH 2/2] document ISL requirement for GCC installation

[Sebastian Pop]

On Fri, Aug 12, 2011 at 12:50, Jack Howarth  wrote:
> On Fri, Aug 12, 2011 at 07:35:24PM +0200, Sven Verdoolaege wrote:
>> On Fri, Aug 12, 2011 at 05:02:18PM +, Joseph S. Myers wrote:
>> > On Fri, 12 Aug 2011, Sebastian Pop wrote:
>> > > +@item Integer Set Library (ISL) version 0.08
>> > > +
>> > > +Necessary to build GCC with the Graphite loop optimizations.
>> > > +It can be downloaded from @uref{http://www.kotnet.org/~skimo/isl/}.
>> >
>> > So have things changed relative to what was said in
>> >  about ISL being
>> > included in CLooG-ISL?
>>
>> isl is still included in CLooG, but Sebastian now wants to use isl
>> itself in graphite.
>>
>> skimo
>
>   Will graphite be totally converted to isl such that ppl can be deprecated
> in time for the gcc 4.7 release?
>                  Jack

Yes, having GCC only depend on ISL and CLooG-ISL (and not depend
anymore on PPL) is our plan for 4.7.

The rationale behind this is that with PPL it would be very difficult to fix
bugs due to wrap around unsigned types, like this one:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47594
With ISL it is possible to represent the wrapping types and fix this bug.

Sebastian

Re: [ARM] Fix minipool handling of aligned labels

[Steven Bosscher]

On Thu, Aug 11, 2011 at 1:56 PM, Richard Sandiford
 wrote:

> gcc/
>        * config/arm/arm.c (get_label_padding): New function.
>        (create_fix_barrier, md_reorg): Likewise.

The ChangeLog doesn't match the patch:
* create_fix_barrier is not a new function.
* md_reorg should be arm_reorg

Ciao!
Steven



> Index: gcc/config/arm/arm.c
> ===
> --- gcc/config/arm/arm.c        2011-08-11 11:49:18.780977049 +0100
> +++ gcc/config/arm/arm.c        2011-08-11 12:14:42.074629364 +0100
> @@ -11719,6 +11719,19 @@ get_jump_table_size (rtx insn)
>   return 0;
>  }
>
> +/* Return the maximum amount of padding that will be inserted before
> +   label LABEL.  */
> +
> +static HOST_WIDE_INT
> +get_label_padding (rtx label)
> +{
> +  HOST_WIDE_INT align, min_insn_size;
> +
> +  align = 1 << label_to_alignment (label);
> +  min_insn_size = TARGET_THUMB ? 2 : 4;
> +  return align > min_insn_size ? align - min_insn_size : 0;
> +}
> +
>  /* Move a minipool fix MP from its current location to before MAX_MP.
>    If MAX_MP is NULL, then MP doesn't need moving, but the addressing
>    constraints may need updating.  */
> @@ -12265,8 +12278,12 @@ create_fix_barrier (Mfix *fix, HOST_WIDE
>         within range.  */
>       gcc_assert (GET_CODE (from) != BARRIER);
>
> -      /* Count the length of this insn.  */
> -      count += get_attr_length (from);
> +      /* Count the length of this insn.  This must stay in sync with the
> +        code that pushes minipool fixes.  */
> +      if (LABEL_P (from))
> +       count += get_label_padding (from);
> +      else
> +       count += get_attr_length (from);
>
>       /* If there is a jump table, add its length.  */
>       tmp = is_jump_table (from);
> @@ -12696,6 +12713,11 @@ arm_reorg (void)
>              insn = table;
>            }
>        }
> +      else if (LABEL_P (insn))
> +       /* Add the worst-case padding due to alignment.  We don't add
> +          the _current_ padding because the minipool insertions
> +          themselves might change it.  */
> +       address += get_label_padding (insn);
>     }
>
>   fix = minipool_fix_head;
>

Re: [PATCH 2/2] document ISL requirement for GCC installation

[Sven Verdoolaege]

On Fri, Aug 12, 2011 at 07:16:55PM +, Joseph S. Myers wrote:
> Do you mean there is not only a requirement to build both libraries, but 
> there is a requirement to build CLooG *first*, then ISL, so that ISL's 
> libisl.a overwrites CLooG's rather than the other way round (supposing 
> that they are installed in the same prefix)?

No.  You build isl first and configure CLooG to use that isl.

skimo

[PATCH] PR c++/50055: Location information for the throw() specification in a function may be incorrect

[Siddhesh Poyarekar]

Hi,

When the location for throw() exception specification is not the same
as the function it is written against, it leads gcov to give incorrect
results. See bug 50055 for details of the the same. The following
patch makes sure that the exception specification block (nothrow or
otherwise) is always associated with the function definition line
number.

I have a test case included with the patch. I ran the c++ test suite
and found no regressions due to this patch.

--
Siddhesh

cp/ChangeLog:

PR c++/50055
* except.c (begin_eh_spec_block): Build EH_SPEC block on the
same line as the function.

testsuite/ChangeLog:

PR c++/50055
* g++.dg/gcov/gcov-7.C: New test.

Index: gcc/testsuite/g++.dg/gcov/gcov-7.C
===
--- gcc/testsuite/g++.dg/gcov/gcov-7.C  (revision 0)
+++ gcc/testsuite/g++.dg/gcov/gcov-7.C  (revision 0)
@@ -0,0 +1,28 @@
+/* Check that Exception handler specification is not
+   mapped to the curly braces below the function
+   declaration.  */
+
+/* { dg-options "-fprofile-arcs -ftest-coverage" } */
+/* { dg-do run { target native } } */
+
+struct foo
+{
+  foo () throw (int)
+{  /* count (-) */
+  throw (1);
+}
+};
+
+int main ()
+{
+  try
+{
+  foo f;
+}
+  catch ( ...)
+{
+  return 0;
+}
+}
+
+/* { dg-final { run-gcov gcov-7.C } } */
Index: gcc/cp/except.c
===
--- gcc/cp/except.c (revision 177613)
+++ gcc/cp/except.c (working copy)
@@ -527,15 +527,17 @@
 begin_eh_spec_block (void)
 {
   tree r;
+  location_t spec_location = DECL_SOURCE_LOCATION (current_function_decl);
+
   /* A noexcept specification (or throw() with -fnothrow-opt) is a
  MUST_NOT_THROW_EXPR.  */
   if (TYPE_NOEXCEPT_P (TREE_TYPE (current_function_decl)))
 {
-  r = build_stmt (input_location, MUST_NOT_THROW_EXPR, NULL_TREE);
+  r = build_stmt (spec_location, MUST_NOT_THROW_EXPR, NULL_TREE);
   TREE_SIDE_EFFECTS (r) = 1;
 }
   else
-r = build_stmt (input_location, EH_SPEC_BLOCK, NULL_TREE, NULL_TREE);
+r = build_stmt (spec_location, EH_SPEC_BLOCK, NULL_TREE, NULL_TREE);
   add_stmt (r);
   TREE_OPERAND (r, 0) = push_stmt_list ();
   return r;

Re: [PATCH 2/2] document ISL requirement for GCC installation

[Joseph S. Myers]

On Fri, 12 Aug 2011, Sven Verdoolaege wrote:

> On Fri, Aug 12, 2011 at 06:56:38PM +, Joseph S. Myers wrote:
> > I don't see why that should make any difference to the build requirements.  
> > If CLooG-ISL builds and installs a library libisl.a as well as 
> > libcloog-isl.a (as config/cloog.m4 thinks it does at present), why should 
> > someone need to download and install a separate ISL package rather than 
> > getting libisl.a from CLooG-ISL?
> 
> The one that comes with CLooG may not be recent enough.

Do you mean there is not only a requirement to build both libraries, but 
there is a requirement to build CLooG *first*, then ISL, so that ISL's 
libisl.a overwrites CLooG's rather than the other way round (supposing 
that they are installed in the same prefix)?  That's clearly not a 
sensible approach.  If you can't make the version included in CLooG the 
right one for GCC, then stop including it in CLooG altogether (like GMP 
stopped including MPFR some years ago).

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

Re: [PATCH 2/2] document ISL requirement for GCC installation

[Sven Verdoolaege]

On Fri, Aug 12, 2011 at 06:56:38PM +, Joseph S. Myers wrote:
> I don't see why that should make any difference to the build requirements.  
> If CLooG-ISL builds and installs a library libisl.a as well as 
> libcloog-isl.a (as config/cloog.m4 thinks it does at present), why should 
> someone need to download and install a separate ISL package rather than 
> getting libisl.a from CLooG-ISL?

The one that comes with CLooG may not be recent enough.

skimo

Re: [PATCH 2/2] document ISL requirement for GCC installation

[Joseph S. Myers]

On Fri, 12 Aug 2011, Sven Verdoolaege wrote:

> On Fri, Aug 12, 2011 at 05:02:18PM +, Joseph S. Myers wrote:
> > On Fri, 12 Aug 2011, Sebastian Pop wrote:
> > > +@item Integer Set Library (ISL) version 0.08
> > > +
> > > +Necessary to build GCC with the Graphite loop optimizations.
> > > +It can be downloaded from @uref{http://www.kotnet.org/~skimo/isl/}.
> > 
> > So have things changed relative to what was said in 
> >  about ISL being 
> > included in CLooG-ISL?
> 
> isl is still included in CLooG, but Sebastian now wants to use isl
> itself in graphite.

I don't see why that should make any difference to the build requirements.  
If CLooG-ISL builds and installs a library libisl.a as well as 
libcloog-isl.a (as config/cloog.m4 thinks it does at present), why should 
someone need to download and install a separate ISL package rather than 
getting libisl.a from CLooG-ISL?

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

Re: Remove LINEMAP_POSITION_FOR_COLUMN macro (issue4874043)

[Tom Tromey]

> "Gabriel" == Gabriel Charette  writes:

Gabriel> Removed LINEMAP_POSITION_FOR_COLUMN, it did the EXACT same
Gabriel> thing as linemap_position_for_column, so maintaining both in
Gabriel> parallel seems like overkill to me. The only thing I can think
Gabriel> of is that it's more optimal as it's inlined (but if that's
Gabriel> really needed we can always make linemap_position_for_column an
Gabriel> inline function directly).

I am sympathetic to this, but nobody is likely to do the performance
tests post-patch.

The libcpp parts are ok if it doesn't cause a noticeable slowdown in the
GCC bootstrap.

I can't approve the changes outside of libcpp.
Also, you didn't write a ChangeLog entry for those.

Tom

Re: [PATCH 2/2] document ISL requirement for GCC installation

[Jack Howarth]

On Fri, Aug 12, 2011 at 07:35:24PM +0200, Sven Verdoolaege wrote:
> On Fri, Aug 12, 2011 at 05:02:18PM +, Joseph S. Myers wrote:
> > On Fri, 12 Aug 2011, Sebastian Pop wrote:
> > > +@item Integer Set Library (ISL) version 0.08
> > > +
> > > +Necessary to build GCC with the Graphite loop optimizations.
> > > +It can be downloaded from @uref{http://www.kotnet.org/~skimo/isl/}.
> > 
> > So have things changed relative to what was said in 
> >  about ISL being 
> > included in CLooG-ISL?
> 
> isl is still included in CLooG, but Sebastian now wants to use isl
> itself in graphite.
> 
> skimo

   Will graphite be totally converted to isl such that ppl can be deprecated
in time for the gcc 4.7 release?
  Jack

Re: [PATCH 2/2] document ISL requirement for GCC installation

[Sven Verdoolaege]

On Fri, Aug 12, 2011 at 05:02:18PM +, Joseph S. Myers wrote:
> On Fri, 12 Aug 2011, Sebastian Pop wrote:
> > +@item Integer Set Library (ISL) version 0.08
> > +
> > +Necessary to build GCC with the Graphite loop optimizations.
> > +It can be downloaded from @uref{http://www.kotnet.org/~skimo/isl/}.
> 
> So have things changed relative to what was said in 
>  about ISL being 
> included in CLooG-ISL?

isl is still included in CLooG, but Sebastian now wants to use isl
itself in graphite.

skimo

Re: [trans-mem] Use per-transaction reader flags for the serial lock

[Richard Henderson]

On 08/05/2011 10:33 AM, Torvald Riegel wrote:
> Use per-transaction reader flags for the serial lock (gtm_rwlock).
> 
>   * config/posix/rwlock.cc (gtm_rwlock::read_lock): Changed locking
>   implementation.
>   (gtm_rwlock::read_unlock): Same.
>   (gtm_rwlock::write_lock_generic): New. Generalized from ...
>   (gtm_rwlock::write_lock, gtm_rwlock::write_upgrade): ... these.
>   * libitm_i.h (GTM::gtm_transaction): Added shared_state.
>   * config/posix/rwlock.h (GTM::gtm_rwlock): Removed a_reader and
>   w_upgrade. Replaced by per-transaction flags (in shared_state).
>   Added c_confirmed_writers.
>   (GTM::gtm_rwlock::read_lock, GTM::gtm_rwlock::read_unlock,
>   GTM::gtm_rwlock::write_upgrade): Add tx parameter.
>   * retry.cc (GTM::gtm_transaction::decide_retry_strategy): Same.
>   * method-serial.cc (GTM::gtm_transaction::serialirr_mode): Same.
>   * beginend.cc (GTM::gtm_transaction::begin_transaction,
>   _ITM_abortTransaction, GTM::gtm_transaction::trycommit): Same.
>   * libitm.texi: Document locking conventions and implementations in
>   libitm.

Ok.


r~

Re: [trans-mem] Use per-transaction reader flags for the serial lock

[Richard Henderson]

On 08/09/2011 05:01 AM, Torvald Riegel wrote:
> Maintain a list of all threads' transactions.
> 
>   * libitm_i.h (next_tx): Add list of all threads' transaction.
>   * beginend.cc (GTM::gtm_transaction::begin_transaction): Register
>   transaction with list of transactions and ...
>   (thread_exit_handler): ... deregister here.
>   * config/alpha/target.h: Add HW_CACHELINE_SIZE setting.
>   * config/x86/target.h: Same.

Ok.


r~

[pph] Remove most ties with LTO streamer (issue4869045)

[Diego Novillo]

Now that we do not depend on the LTO streamer anymore, these calls are
unnecessary.  There are still some remnants that will be necessary
until I factor the pickling buffers out of lto-streamer.h.

Tested on x86_64.  Committed to branch.


Diego.

* pph-streamer-in.c (pph_init_read): Do not call lto_reader_init.
* pph-streamer-out.c (pph_init_write): Do not call lto_streamer_init.
(pph_out_body): Do not call lto_output_decl_state_streams nor
lto_output_decl_state_refs.

diff --git a/gcc/cp/pph-streamer-in.c b/gcc/cp/pph-streamer-in.c
index 1e31427..e644113 100644
--- a/gcc/cp/pph-streamer-in.c
+++ b/gcc/cp/pph-streamer-in.c
@@ -87,8 +87,6 @@ pph_init_read (pph_stream *stream)
   const char *strtab, *body;
   char *new_strtab;
 
-  lto_reader_init ();
-
   /* Read STREAM->NAME into the memory buffer stream->encoder.r.file_data.  */
   retcode = fstat (fileno (stream->file), &st);
   gcc_assert (retcode == 0);
diff --git a/gcc/cp/pph-streamer-out.c b/gcc/cp/pph-streamer-out.c
index ec95532..2e5543a 100644
--- a/gcc/cp/pph-streamer-out.c
+++ b/gcc/cp/pph-streamer-out.c
@@ -45,7 +45,6 @@ static pph_stream *pph_out_stream = NULL;
 void
 pph_init_write (pph_stream *stream)
 {
-  lto_streamer_init ();
   stream->encoder.w.out_state = lto_new_out_decl_state ();
   lto_push_out_decl_state (stream->encoder.w.out_state);
   stream->encoder.w.decl_state_stream = XCNEW (struct lto_output_stream);
@@ -149,17 +148,7 @@ pph_out_body (pph_stream *stream)
   /* Write the string table.  */
   lto_write_stream (stream->encoder.w.ob->string_stream);
 
-  /* Write out the physical representation for every AST in all the
- streams in STREAM->ENCODER.W.OUT_STATE.  */
-  lto_output_decl_state_streams (stream->encoder.w.ob,
-stream->encoder.w.out_state);
-
-  /* Now write the vector of all AST references.  */
-  lto_output_decl_state_refs (stream->encoder.w.ob,
- stream->encoder.w.decl_state_stream,
- stream->encoder.w.out_state);
-
-  /* Finally, physically write all the streams.  */
+  /* Write the main stream where we have been pickling the parse trees.  */
   lto_write_stream (stream->encoder.w.ob->main_stream);
 }
 

--
This patch is available for review at http://codereview.appspot.com/4869045

Re: [build] Move unwinder to toplevel libgcc (v2)

[Paolo Bonzini]

On 08/12/2011 06:25 PM, H.J. Lu wrote:

>
>  I prefer to wait for testing results to commit it, the breakage is minor.

It bootstraps successfully with "make -j12" on a 24 core machine.

Thanks.


Committed.

Paolo

Re: [PATCH] [JAVA] Double.parseDouble(null) throw NullPointerException

[Tom Tromey]

> "Jie" == Jie Liu  writes:

Jie> In my debug, there appears no check for 'this' at start of String.length():

Yeah, I looked for uses of flag_check_references and didn't see one when
building a method's body.  So I guess I mis-remembered this.

In any case, the spot you found is just the tip of the problem.  Any
method call in any of the C++ code could potentially have the same
issue.

Tom

Re: [PATCH 2/2] document ISL requirement for GCC installation

[Joseph S. Myers]

On Fri, 12 Aug 2011, Sebastian Pop wrote:

> ---
>  gcc/doc/install.texi |8 +++-
>  1 files changed, 7 insertions(+), 1 deletions(-)
> 
> diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
> index 368221f..f2b2fd9 100644
> --- a/gcc/doc/install.texi
> +++ b/gcc/doc/install.texi
> @@ -368,6 +368,11 @@ It can be downloaded from 
> @uref{http://www.cs.unipr.it/ppl/Download/}.
>  The configure option @option{--with-ppl} should be used if PPL is not
>  installed in your default library search path.
>  
> +@item Integer Set Library (ISL) version 0.08
> +
> +Necessary to build GCC with the Graphite loop optimizations.
> +It can be downloaded from @uref{http://www.kotnet.org/~skimo/isl/}.

So have things changed relative to what was said in 
 about ISL being 
included in CLooG-ISL?

Please propose all changes to libraries for building GCC in separate 
threads on the gcc@ list rather than just in patches on gcc-patches - the 
principle of what would be needed should be clearly understood before 
things get to the point of patch posting.  Make very clear what different 
configurations have been tested, including both static and shared 
libraries, different hosts (as many as possible among the primary and 
secondary platforms) and Canadian cross configurations, and solicit 
assistance to test other platforms as needed.  See what was done for the 
original inclusion of Graphite and the associated use of PPL.  Make clear 
whether versions of the libraries in question might affect the code 
generated, and if so then default to version checks tight enough to avoid 
such dependence.

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

Re: [trans-mem] Removed gtm_thread and threadnum. Renamed gtm_transaction to gtm_thread.

[Richard Henderson]

On 08/05/2011 04:24 PM, Torvald Riegel wrote:
> Note that I did have code ready to have a single statically allocated
> __thread gtm_thread object. However, I then saw that unlike discussed
> off-list, the compiler does indeed complain about using non-trivial
> objects with __thread (which makes sense). Is there a way to avoid this
> and use the explicit dtors calls and ctor calls via placement new?

Maybe.  It seems awfully hackish though.

> Assuming that this is not possible, I'd rather want objects to have
> constructors (e.g., for the vectors, aa_tree, etc.) than to avoid the
> __thread helper object (gtm_thread_tls in config/generic/tls.h, only for
> targets without fast access to two TLS slots) by having statically
> allocated __thread gtm_thread objects.

Sure.

The patch is ok.


r~

[PATCH] PR middle-end/38509: add -Wfree-nonheap-object warning option

[Mark Heffernan]

This patch adds an option for enabling/disabling the warning for
attempting to free nonheap objects (PR/38509).  The warning is
imprecise and can issue false positives.

Bootstrapped on x86-64.  Ok for trunk?

Mark

2011-08-11  Mark Heffernan  

PR middle-end/38509
* common.opt (Wfree-nonheap-object): New option.
* doc/invoke.texi (Warning options): Document -Wfree-nonheap-object.
* builtins.c (maybe_emit_free_warning): Add OPT_Wfree_nonheap_object
to warning.



Index: gcc/doc/invoke.texi
===
--- gcc/doc/invoke.texi (revision 177684)
+++ gcc/doc/invoke.texi (working copy)
@@ -244,7 +244,8 @@ Objective-C and Objective-C++ Dialects}.
 -Wfatal-errors  -Wfloat-equal  -Wformat  -Wformat=2 @gol
 -Wno-format-contains-nul -Wno-format-extra-args -Wformat-nonliteral @gol
 -Wformat-security  -Wformat-y2k @gol
--Wframe-larger-than=@var{len} -Wjump-misses-init -Wignored-qualifiers @gol
+-Wframe-larger-than=@var{len} -Wno-free-nonheap-object -Wjump-misses-init @gol
+-Wignored-qualifiers @gol
 -Wimplicit  -Wimplicit-function-declaration  -Wimplicit-int @gol
 -Winit-self  -Winline -Wmaybe-uninitialized @gol
 -Wno-int-to-pointer-cast -Wno-invalid-offsetof @gol
@@ -3960,6 +3961,12 @@ via @code{alloca}, variable-length array
 is not included by the compiler when determining
 whether or not to issue a warning.

+@item -Wno-free-nonheap-object
+@opindex Wno-free-nonheap-object
+@opindex Wfree-nonheap-object
+Do not warn when attempting to free an object which was not allocated
+on the heap.
+
 @item -Wstack-usage=@var{len}
 @opindex Wstack-usage
 Warn if the stack usage of a function might be larger than @var{len} bytes.

Index: gcc/builtins.c
===
--- gcc/builtins.c  (revision 177684)
+++ gcc/builtins.c  (working copy)
@@ -6087,7 +6087,8 @@ expand_builtin (tree exp, rtx target, rt
   break;

 case BUILT_IN_FREE:
-  maybe_emit_free_warning (exp);
+  if (warn_free_nonheap_object)
+   maybe_emit_free_warning (exp);
   break;

 default:   /* just do library call, if unknown builtin */
@@ -11863,11 +11864,11 @@ maybe_emit_free_warning (tree exp)
 return;

   if (SSA_VAR_P (arg))
-warning_at (tree_nonartificial_location (exp),
-   0, "%Kattempt to free a non-heap object %qD", exp, arg);
+warning_at (tree_nonartificial_location (exp), OPT_Wfree_nonheap_object,
+   "%Kattempt to free a non-heap object %qD", exp, arg);
   else
-warning_at (tree_nonartificial_location (exp),
-   0, "%Kattempt to free a non-heap object", exp);
+warning_at (tree_nonartificial_location (exp), OPT_Wfree_nonheap_object,
+   "%Kattempt to free a non-heap object", exp);
 }

 /* Fold a call to __builtin_object_size with arguments PTR and OST,
Index: gcc/common.opt
===
--- gcc/common.opt  (revision 177684)
+++ gcc/common.opt  (working copy)
@@ -543,6 +543,10 @@ Wframe-larger-than=
 Common RejectNegative Joined UInteger
 -Wframe-larger-than=   Warn if a function's stack frame
requires more than  bytes

+Wfree-nonheap-object
+Common Var(warn_free_nonheap_object) Init(1) Warning
+Warn when attempting to free a non-heap object
+
 Winline
 Common Var(warn_inline) Warning
 Warn when an inlined function cannot be inlined

Re: RFA: Do not use cmpstrnsi to implement builtin memcmp

[Nick Clifton]

Hi Jeff,


The point of the patch is that the cmpstrnsi machine pattern should
not be used to implement the memcmp builtin function.  This is
because a string comparison will terminate if two zero bytes are read
whereas a memory comparison should continue.



OK.  Kindof surprised this wasn't dealt with before.


Me too.  Especially since the x86 port has a cmpstrnsi pattern and no 
cmpmemsi pattern...


I have applied the patch to the mainline and 4.6 and 4.5 branches.

Cheers
  Nick

Re: [build] Move unwinder to toplevel libgcc (v2)

[H.J. Lu]

On Fri, Aug 12, 2011 at 8:57 AM, Paolo Bonzini  wrote:
> On 08/12/2011 05:50 PM, H.J. Lu wrote:
>>
>> >  Thanks, you are correct.
>>
>> It should work.
>>
>> Thanks.
>
> I prefer to wait for testing results to commit it, the breakage is minor.

It bootstraps successfully with "make -j12" on a 24 core machine.

Thanks.


-- 
H.J.

Re: [PATCH] [JAVA] Double.parseDouble(null) throw NullPointerException

[Jie Liu]

> If you did, then I don't know, you'll have to debug it, sorry.
>
> I vaguely recollect that -fcheck-references adds a check for 'this' at
> the start of final methods.  If I'm misremembering, then that is
> probably the problem.

In my debug, there appears no check for 'this' at start of String.length():

(gdb) s
java::lang::VMDouble::parseDouble (str=0x0)
at ../../../gcc-trunk/libjava/java/lang/natVMDouble.cc:165
165   int length = str->length();
(gdb) s
java.lang.String.length()int (this=@336e44)
at /mnt/gcj/gcj-rtems-work/gcc-trunk/libjava/java/lang/String.java:451
451 return count;
(gdb) p count
$5 = -268370093
(gdb) p this
$6 = (java.lang.String *) 0x0

Thanks,
Jie

Re: [build] Move unwinder to toplevel libgcc (v2)

[Pedro Alves]

On Friday 12 August 2011 16:40:33, Paolo Bonzini wrote:
>  install-unwind_h:
> -   rm -f $(gcc_objdir)/include/unwind.h
> -   cp unwind.h $(gcc_objdir)/include/unwind.h
> -   chmod a+r $(gcc_objdir)/include/unwind.h
> +   dest=$(gcc_objdir)/include/tmp-unwind.h; \
> +   cp unwind.h $$dest; \
> +   chmod a+r $$dest; \
> +   sh $(srcdir)/../move-if-change $$dest $(gcc_objdir)/include/unwind.h

Thanks, that looks good to me.

-- 
Pedro Alves

[rfa] Set alignment of pseudos via get_pointer_alignment

[Michael Matz]

Hi,

On Tue, 9 Aug 2011, Michael Matz wrote:

> > Are there any updates on the libada problem or other reasons why the 
> > patch cannot go in?
> 
> Nope, I've solved that one.  Letme update it.

Like so.  Regstrapped on x86_64-linux (all languages + Ada).  Okay for 
trunk?


Ciao,
Michael.
-- 
* cfgexpand.c (expand_one_register_var): Use get_pointer_alignment.
(gimple_expand_cfg): Merge alignment info for coalesced pointer
SSA names.

Index: cfgexpand.c
===
--- cfgexpand.c (revision 177696)
+++ cfgexpand.c (working copy)
@@ -909,7 +909,7 @@ expand_one_register_var (tree var)
 mark_user_reg (x);
 
   if (POINTER_TYPE_P (type))
-mark_reg_pointer (x, TYPE_ALIGN (TREE_TYPE (type)));
+mark_reg_pointer (x, get_pointer_alignment (var));
 }
 
 /* A subroutine of expand_one_var.  Called to assign rtl to a VAR_DECL that
@@ -4265,6 +4265,31 @@ gimple_expand_cfg (void)
}
 }
 
+  /* If we have a class containing differently aligned pointers
+ we need to merge those into the corresponding RTL pointer
+ alignment.  */
+  for (i = 1; i < num_ssa_names; i++)
+{
+  tree name = ssa_name (i);
+  int part;
+  rtx r;
+
+  if (!name
+ || !POINTER_TYPE_P (TREE_TYPE (name))
+ /* We might have generated new SSA names in
+update_alias_info_with_stack_vars.  They will have a NULL
+defining statements, and won't be part of the partitioning,
+so ignore those.  */
+ || !SSA_NAME_DEF_STMT (name))
+   continue;
+  part = var_to_partition (SA.map, name);
+  if (part == NO_PARTITION)
+   continue;
+  r = SA.partition_to_pseudo[part];
+  if (REG_P (r))
+   mark_reg_pointer (r, get_pointer_alignment (name));
+}
+
   /* If this function is `main', emit a call to `__main'
  to run global initializers, etc.  */
   if (DECL_NAME (current_function_decl)

Re: [build] Move unwinder to toplevel libgcc (v2)

[Paolo Bonzini]

On 08/12/2011 05:50 PM, H.J. Lu wrote:

>  Thanks, you are correct.

It should work.

Thanks.


I prefer to wait for testing results to commit it, the breakage is minor.

Paolo

Re: [build] Move unwinder to toplevel libgcc (v2)

[H.J. Lu]

On Fri, Aug 12, 2011 at 8:40 AM, Paolo Bonzini  wrote:
>>> Can't this sequence happen?
>>>
>>> proc1:       cp unwind.h $(gcc_objdir)/include/tmp-unwind.h
>>> proc2:       cp unwind.h $(gcc_objdir)/include/tmp-unwind.h
>>> proc1:       sh $(srcdir)/../move-if-change \
>>>               $(gcc_objdir)/include/tmp-unwind.h \
>>>               $(gcc_objdir)/include/unwind.h
>>> proc2:       sh $(srcdir)/../move-if-change \
>>>               $(gcc_objdir)/include/tmp-unwind.h \
>>>               $(gcc_objdir)/include/unwind.h
>>>
>>> It sounds like the latter move-if-change could trip on
>>> a non-extant tmp-unwind.h.
>>
>> Yes, we should use an unique tmp unwind.h.
>
> Thanks, you are correct.
>

It should work.

Thanks.

-- 
H.J.

[v3] Add missing std::fmod overload

[Paolo Carlini]

Hi,

tested x86_64-linux, committed to mainline.

Paolo.

PS: will add separately tests for the C++11  facilities.

//
2011-08-12  Paolo Carlini  

* include/c_global/cmath (fmod(_Tp, _Up)): Add.
* include/c_std/cmath: Likewise.
Index: include/c_std/cmath
===
--- include/c_std/cmath (revision 177696)
+++ include/c_std/cmath (working copy)
@@ -268,6 +268,13 @@
   fmod(long double __x, long double __y)
   { return __builtin_fmodl(__x, __y); }
 
+  template
+inline typename __gnu_cxx::__enable_if<__is_integer<_Tp>::__value
+  && __is_integer<_Up>::__value, 
+  double>::__type
+fmod(_Tp __x, _Up __y)
+{ return __builtin_fmod(__x, __y); }
+
   using ::frexp;
 
   inline float
Index: include/c_global/cmath
===
--- include/c_global/cmath  (revision 177696)
+++ include/c_global/cmath  (working copy)
@@ -282,6 +282,18 @@
   fmod(long double __x, long double __y)
   { return __builtin_fmodl(__x, __y); }
 
+  template
+inline _GLIBCXX_CONSTEXPR
+typename __gnu_cxx::__promote_2<
+typename __gnu_cxx::__enable_if<__is_arithmetic<_Tp>::__value
+   && __is_arithmetic<_Up>::__value,
+   _Tp>::__type, _Up>::__type
+fmod(_Tp __x, _Up __y)
+{
+  typedef typename __gnu_cxx::__promote_2<_Tp, _Up>::__type __type;
+  return fmod(__type(__x), __type(__y));
+}
+
   using ::frexp;
 
   inline _GLIBCXX_CONSTEXPR float
@@ -313,8 +325,8 @@
 inline _GLIBCXX_CONSTEXPR
 typename __gnu_cxx::__enable_if<__is_integer<_Tp>::__value, 
 double>::__type
-  ldexp(_Tp __x, int __exp)
-  { return __builtin_ldexp(__x, __exp); }
+ldexp(_Tp __x, int __exp)
+{ return __builtin_ldexp(__x, __exp); }
 
   using ::log;
 

Re: [build] Move unwinder to toplevel libgcc (v2)

[Paolo Bonzini]

Can't this sequence happen?

proc1:   cp unwind.h $(gcc_objdir)/include/tmp-unwind.h
proc2:   cp unwind.h $(gcc_objdir)/include/tmp-unwind.h
proc1:   sh $(srcdir)/../move-if-change \
   $(gcc_objdir)/include/tmp-unwind.h \
   $(gcc_objdir)/include/unwind.h
proc2:   sh $(srcdir)/../move-if-change \
   $(gcc_objdir)/include/tmp-unwind.h \
   $(gcc_objdir)/include/unwind.h

It sounds like the latter move-if-change could trip on
a non-extant tmp-unwind.h.


Yes, we should use an unique tmp unwind.h.


Thanks, you are correct.

Paolo
2011-08-12  Paolo Bonzini  

	* Makefile.in (install-unwind_h): Create $(gcc_objdir)/include/unwind.h
	atomically.

Index: Makefile.in
===
--- Makefile.in	(revision 177688)
+++ Makefile.in	(working copy)
@@ -991,8 +1001,9 @@ gcc-extra-parts:
 all: $(extra-parts)
 
 install-unwind_h:
-	rm -f $(gcc_objdir)/include/unwind.h
-	cp unwind.h $(gcc_objdir)/include/unwind.h
-	chmod a+r $(gcc_objdir)/include/unwind.h
+	dest=$(gcc_objdir)/include/tmp-unwind.h; \
+	cp unwind.h $$dest; \
+	chmod a+r $$dest; \
+	sh $(srcdir)/../move-if-change $$dest $(gcc_objdir)/include/unwind.h
 
 all: install-unwind_h

Re: [PATCH 2/2] document ISL requirement for GCC installation

[Sven Verdoolaege]

On Fri, Aug 12, 2011 at 10:16:05AM -0500, Sebastian Pop wrote:
> ---
>  gcc/doc/install.texi |8 +++-
>  1 files changed, 7 insertions(+), 1 deletions(-)
> 
> diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
> index 368221f..f2b2fd9 100644
> --- a/gcc/doc/install.texi
> +++ b/gcc/doc/install.texi
> @@ -368,6 +368,11 @@ It can be downloaded from 
> @uref{http://www.cs.unipr.it/ppl/Download/}.
>  The configure option @option{--with-ppl} should be used if PPL is not
>  installed in your default library search path.
>  
> +@item Integer Set Library (ISL) version 0.08

Are you going to wait until 0.08 is available before
applying these patches?

> +Necessary to build GCC with the Graphite loop optimizations.
> +It can be downloaded from @uref{http://www.kotnet.org/~skimo/isl/}.

Please use http://freshmeat.net/projects/isl/ instead.

skimo

Re: [lto] Rename functions in tree/data streamer (issue4886041)

[Diego Novillo]

On Fri, Aug 12, 2011 at 11:16, Michael Matz  wrote:

> I see downthread that this is changed to hwi/uhwi already.  I even would
> have suggested int/uint directly, as we never stream other numbers than
> host_wide_ints or chars.

For now, that's true.  Over in PPH we do stream out ints/uints, and
those will likely move up to data-streamer.[ch].


Diego.

[PATCH 2/2] document ISL requirement for GCC installation

[Sebastian Pop]

---
 gcc/doc/install.texi |8 +++-
 1 files changed, 7 insertions(+), 1 deletions(-)

diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
index 368221f..f2b2fd9 100644
--- a/gcc/doc/install.texi
+++ b/gcc/doc/install.texi
@@ -368,6 +368,11 @@ It can be downloaded from 
@uref{http://www.cs.unipr.it/ppl/Download/}.
 The configure option @option{--with-ppl} should be used if PPL is not
 installed in your default library search path.
 
+@item Integer Set Library (ISL) version 0.08
+
+Necessary to build GCC with the Graphite loop optimizations.
+It can be downloaded from @uref{http://www.kotnet.org/~skimo/isl/}.
+
 @item CLooG-ISL 0.16
 
 Necessary to build GCC with the Graphite loop optimizations.  It is
@@ -1620,7 +1625,8 @@ a cross compiler, they will not be used to configure 
target libraries.
 @itemx --with-cloog=@var{pathname}
 @itemx --with-cloog-include=@var{pathname}
 @itemx --with-cloog-lib=@var{pathname}
-If you do not have PPL (the Parma Polyhedra Library) and the CLooG
+If you do not have ISL (the Integer Set Library),
+PPL (the Parma Polyhedra Library), and the CLooG (the Chunky Loop Generator)
 libraries installed in a standard location and you want to build GCC,
 you can explicitly specify the directory where they are installed
 (@samp{--with-ppl=@/@var{pplinstalldir}},
-- 
1.7.4.1

[PATCH 1/2] use cloog_isl_state_malloc

[Sebastian Pop]

---
 gcc/graphite.c |   11 ++-
 1 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/gcc/graphite.c b/gcc/graphite.c
index b2cf7c6..7d124c7 100644
--- a/gcc/graphite.c
+++ b/gcc/graphite.c
@@ -41,6 +41,7 @@ along with GCC; see the file COPYING3.  If not see
 #include 
 #include 
 #include 
+#include 
 #endif
 
 #include "system.h"
@@ -196,7 +197,7 @@ print_graphite_statistics (FILE* file, VEC (scop_p, heap) 
*scops)
 /* Initialize graphite: when there are no loops returns false.  */
 
 static bool
-graphite_initialize (void)
+graphite_initialize (isl_ctx *ctx)
 {
   int ppl_initialized;
 
@@ -208,6 +209,7 @@ graphite_initialize (void)
   if (dump_file && (dump_flags & TDF_DETAILS))
print_global_statistics (dump_file);
 
+  isl_ctx_free (ctx);
   return false;
 }
 
@@ -218,7 +220,7 @@ graphite_initialize (void)
   ppl_initialized = ppl_initialize ();
   gcc_assert (ppl_initialized == 0);
 
-  cloog_state = cloog_state_malloc ();
+  cloog_state = cloog_isl_state_malloc (ctx);
 
   if (dump_file && dump_flags)
 dump_function_to_file (current_function_decl, dump_file, dump_flags);
@@ -260,12 +262,11 @@ graphite_transform_loops (void)
   bool need_cfg_cleanup_p = false;
   VEC (scop_p, heap) *scops = NULL;
   htab_t bb_pbb_mapping;
-  isl_ctx *ctx;
+  isl_ctx *ctx = isl_ctx_alloc ();
 
-  if (!graphite_initialize ())
+  if (!graphite_initialize (ctx))
 return;
 
-  ctx = isl_ctx_alloc ();
   build_scops (&scops);
 
   if (dump_file && (dump_flags & TDF_DETAILS))
-- 
1.7.4.1

Re: [lto] Rename functions in tree/data streamer (issue4886041)

[Michael Matz]

Hi,

On Fri, 12 Aug 2011, Diego Novillo wrote:

> 3- Replaces dwarf terminology for numbers with C-like terminology:
>   sleb128 -> wide_int
>   uleb128 -> wide_uint

I see downthread that this is changed to hwi/uhwi already.  I even would 
have suggested int/uint directly, as we never stream other numbers than 
host_wide_ints or chars.

Other than this, no bikeshedding from me.


Ciao,
Michael.

[PATCH] add pbb->schedule

[Sebastian Pop]

---
 gcc/graphite-poly.c |6 
 gcc/graphite-sese-to-poly.c |   54 --
 2 files changed, 57 insertions(+), 3 deletions(-)

diff --git a/gcc/graphite-poly.c b/gcc/graphite-poly.c
index 1828727..2835311 100644
--- a/gcc/graphite-poly.c
+++ b/gcc/graphite-poly.c
@@ -886,6 +886,9 @@ new_poly_bb (scop_p scop, void *black_box)
 
   PBB_DOMAIN (pbb) = NULL;
   pbb->domain = NULL;
+  pbb->schedule = NULL;
+  pbb->transformed = NULL;
+  pbb->saved = NULL;
   PBB_SCOP (pbb) = scop;
   pbb_set_black_box (pbb, black_box);
   PBB_TRANSFORMED (pbb) = NULL;
@@ -911,6 +914,9 @@ free_poly_bb (poly_bb_p pbb)
 ppl_delete_Pointset_Powerset_C_Polyhedron (PBB_DOMAIN (pbb));
 
   isl_set_free (pbb->domain);
+  isl_map_free (pbb->schedule);
+  isl_map_free (pbb->transformed);
+  isl_map_free (pbb->saved);
 
   if (PBB_TRANSFORMED (pbb))
 poly_scattering_free (PBB_TRANSFORMED (pbb));
diff --git a/gcc/graphite-sese-to-poly.c b/gcc/graphite-sese-to-poly.c
index 28c5d98..aec637b 100644
--- a/gcc/graphite-sese-to-poly.c
+++ b/gcc/graphite-sese-to-poly.c
@@ -407,6 +407,16 @@ build_scop_bbs (scop_p scop)
   sbitmap_free (visited);
 }
 
+/* Return an ISL identifier for the polyhedral basic block PBB.  */
+
+static isl_id *
+isl_id_for_pbb (scop_p s, poly_bb_p pbb)
+{
+  char name[50];
+  snprintf (name, sizeof (name), "S_%d", pbb_index (pbb));
+  return isl_id_alloc (s->ctx, name, pbb);
+}
+
 /* Converts the STATIC_SCHEDULE of PBB into a scattering polyhedron.
We generate SCATTERING_DIMENSIONS scattering dimensions.
 
@@ -441,7 +451,8 @@ build_scop_bbs (scop_p scop)
| 0   0   1   0   0   0   0   0  -5  = 0  */
 
 static void
-build_pbb_scattering_polyhedrons (ppl_Linear_Expression_t static_schedule,
+build_pbb_scattering_polyhedrons (isl_aff *static_sched,
+ ppl_Linear_Expression_t static_schedule,
  poly_bb_p pbb, int scattering_dimensions)
 {
   int i;
@@ -452,9 +463,11 @@ build_pbb_scattering_polyhedrons (ppl_Linear_Expression_t 
static_schedule,
   ppl_Coefficient_t c;
   ppl_dimension_type dim = scattering_dimensions + nb_iterators + nb_params;
   mpz_t v;
+  isl_int val;
 
   gcc_assert (scattering_dimensions >= used_scattering_dimensions);
 
+  isl_int_init (val);
   mpz_init (v);
   ppl_new_Coefficient (&c);
   PBB_TRANSFORMED (pbb) = poly_scattering_new ();
@@ -463,6 +476,15 @@ build_pbb_scattering_polyhedrons (ppl_Linear_Expression_t 
static_schedule,
 
   PBB_NB_SCATTERING_TRANSFORM (pbb) = scattering_dimensions;
 
+  {
+isl_dim *dc = isl_set_get_dim (scop->context);
+isl_dim *dm = isl_dim_add (isl_dim_from_domain (dc),
+  isl_dim_out, scattering_dimensions);
+pbb->schedule = isl_map_universe (dm);
+pbb->schedule = isl_map_set_tuple_id (pbb->schedule, isl_dim_out,
+ isl_id_for_pbb (scop, pbb));
+  }
+
   for (i = 0; i < scattering_dimensions; i++)
 {
   ppl_Constraint_t cstr;
@@ -481,6 +503,20 @@ build_pbb_scattering_polyhedrons (ppl_Linear_Expression_t 
static_schedule,
  mpz_neg (v, v);
  ppl_assign_Coefficient_from_mpz_t (c, v);
  ppl_Linear_Expression_add_to_inhomogeneous (expr, c);
+
+ {
+   isl_constraint *c = isl_equality_alloc
+ (isl_map_get_dim (pbb->schedule));
+
+   if (0 != isl_aff_get_coefficient (static_sched, isl_dim_set,
+ i / 2, &val))
+ gcc_unreachable ();
+
+   isl_int_neg (val, val);
+   c = isl_constraint_set_constant (c, val);
+   c = isl_constraint_set_coefficient_si (c, isl_dim_out, i, 1);
+   pbb->schedule = isl_map_add_constraint (pbb->schedule, c);
+ }
}
 
   /* Iterations of this loop.  */
@@ -492,6 +528,9 @@ build_pbb_scattering_polyhedrons (ppl_Linear_Expression_t 
static_schedule,
  ppl_assign_Coefficient_from_mpz_t (c, v);
  ppl_Linear_Expression_add_to_coefficient
(expr, scattering_dimensions + loop, c);
+
+ pbb->schedule = isl_map_equate (pbb->schedule, isl_dim_in, loop,
+ isl_dim_out, i);
}
 
   ppl_new_Constraint (&cstr, expr, PPL_CONSTRAINT_TYPE_EQUAL);
@@ -500,10 +539,12 @@ build_pbb_scattering_polyhedrons (ppl_Linear_Expression_t 
static_schedule,
   ppl_delete_Constraint (cstr);
 }
 
+  isl_int_clear (val);
   mpz_clear (v);
   ppl_delete_Coefficient (c);
 
   PBB_ORIGINAL (pbb) = poly_scattering_copy (PBB_TRANSFORMED (pbb));
+  pbb->transformed = isl_map_copy (pbb->schedule);
 }
 
 /* Build for BB the static schedule.
@@ -551,6 +592,8 @@ build_scop_scattering (scop_p scop)
   ppl_Linear_Expression_t static_schedule;
   ppl_Coefficient_t c;
   mpz_t v;
+  isl_dim *dc = isl_set_get_dim (scop->context);
+  isl_aff *static_sched = isl_aff_zero (isl_local_space_from_dim (dc));
 
   mpz_init (v);
   ppl_new_Coeff

Re: [PATCH 09/11] Add scop->context

[Sebastian Pop]

On Fri, Aug 12, 2011 at 02:22, Sven Verdoolaege  wrote:
> On Thu, Aug 11, 2011 at 05:44:37PM -0500, Sebastian Pop wrote:
>> +  ctx = isl_ctx_alloc ();
>
> I can't find the call to cloog_isl_state_malloc in this patch
> that Tobi correctly requested.

Yes, sorry, I forgot about this one after I merged my patches
on top of Tobi's changes.  I will do this and document the new
ISL requrements.

Thanks.

[Patch, fortran] PR fortran/50050 out of bounds whilst freeing an allocate-object.

[Mikael Morin]

Hello, 

This fixes an ICE triggered by resolve.c's gfc_expr_to_initialize reseting a 
range array ref into a full array ref, updating the rank, but leaving the 
shape as is, which eventually leads to an out of bound error.

The right fix would probably be to avoid this kind of tricks. But I don't know 
what a patch impleting that would look like.

This patch instead keeps the trick as is. It just frees the shape and re-
resolves the expression, so that rank and shape are updated. It also does a 
bit of refactoring about shape freeing.

I think it should be on the safe side, and I'm testing it on x86_64-unknown-
freebsd8.2. OK for trunk if it passes? What about the branches? It is not a 
regression, but it looks like a genuine bug.

Mikael
2011-08-12  Mikael Morin  

	PR fortran/50050
	* gfortran.h (gfc_clear_shape, gfc_free_shape): New prototypes.
	* expr.c (gfc_clear_shape, gfc_free_shape): New functions.
	(free_expr0): Re-use gfc_free_shape.
	* trans-expr.c (gfc_trans_subarray_assign): Ditto.
	* trans-io.c (transfer_array_component): Ditto.
	* resolve.c (check_host_association): Ditto.
	(gfc_expr_to_initialize): Don't force the rank value and free the shape
	after updating the expression. Recalculate shape and rank.
	(resolve_where_shape): Re-use gfc_clear_shape.
	* array.c (gfc_array_ref_shape): Ditto.

2011-08-12  Mikael Morin  

	* gfortran.dg/alloc_comp_initializer_3.f90: New test.

diff --git a/array.c b/array.c
index 3074275..aa9cc0c 100644
--- a/array.c
+++ b/array.c
@@ -2281,9 +2281,7 @@ gfc_array_ref_shape (gfc_array_ref *ar, mpz_t *shape)
 }
 
 cleanup:
-  for (d--; d >= 0; d--)
-mpz_clear (shape[d]);
-
+  gfc_clear_shape (shape, d);
   return FAILURE;
 }
 
diff --git a/expr.c b/expr.c
index 549feee..c2f1553 100644
--- a/expr.c
+++ b/expr.c
@@ -396,6 +396,25 @@ gfc_copy_expr (gfc_expr *p)
 }
 
 
+void
+gfc_clear_shape (mpz_t *shape, int rank)
+{
+  int i;
+
+  for (i = 0; i < rank; i++)
+mpz_clear (shape[i]);
+}
+
+
+void
+gfc_free_shape (mpz_t **shape, int rank)
+{
+  gfc_clear_shape (*shape, rank);
+  free (*shape);
+  *shape = NULL;
+}
+
+
 /* Workhorse function for gfc_free_expr() that frees everything
beneath an expression node, but not the node itself.  This is
useful when we want to simplify a node and replace it with
@@ -404,8 +423,6 @@ gfc_copy_expr (gfc_expr *p)
 static void
 free_expr0 (gfc_expr *e)
 {
-  int n;
-
   switch (e->expr_type)
 {
 case EXPR_CONSTANT:
@@ -474,12 +491,7 @@ free_expr0 (gfc_expr *e)
 
   /* Free a shape array.  */
   if (e->shape != NULL)
-{
-  for (n = 0; n < e->rank; n++)
-	mpz_clear (e->shape[n]);
-
-  free (e->shape);
-}
+gfc_free_shape (&e->shape, e->rank);
 
   gfc_free_ref_list (e->ref);
 
diff --git a/gfortran.h b/gfortran.h
index 34afae4..09f2fe3 100644
--- a/gfortran.h
+++ b/gfortran.h
@@ -2711,6 +2711,8 @@ gfc_expr *gfc_get_int_expr (int, locus *, int);
 gfc_expr *gfc_get_logical_expr (int, locus *, bool);
 gfc_expr *gfc_get_iokind_expr (locus *, io_kind);
 
+void gfc_clear_shape (mpz_t *shape, int rank);
+void gfc_free_shape (mpz_t **shape, int rank);
 void gfc_free_expr (gfc_expr *);
 void gfc_replace_expr (gfc_expr *, gfc_expr *);
 mpz_t *gfc_copy_shape (mpz_t *, int);
diff --git a/resolve.c b/resolve.c
index b8a8ebb..a4645a2 100644
--- a/resolve.c
+++ b/resolve.c
@@ -5198,12 +5198,7 @@ check_host_association (gfc_expr *e)
 	{
 	  /* Clear the shape, since it might not be valid.  */
 	  if (e->shape != NULL)
-	{
-	  for (n = 0; n < e->rank; n++)
-		mpz_clear (e->shape[n]);
-
-	  free (e->shape);
-	}
+	gfc_free_shape (&e->shape, e->rank);
 
 	  /* Give the expression the right symtree!  */
 	  gfc_find_sym_tree (e->symtree->name, NULL, 1, &st);
@@ -6558,10 +6553,13 @@ gfc_expr_to_initialize (gfc_expr *e)
 	for (i = 0; i < ref->u.ar.dimen; i++)
 	  ref->u.ar.start[i] = ref->u.ar.end[i] = ref->u.ar.stride[i] = NULL;
 
-	result->rank = ref->u.ar.dimen;
 	break;
   }
 
+  gfc_free_shape (&result->shape, result->rank);
+
+  /* Recalculate rank, shape, etc.  */
+  gfc_resolve_expr (result);
   return result;
 }
 
@@ -8429,11 +8427,8 @@ ignore:
   result = SUCCESS;
 
 over:
-  for (i--; i >= 0; i--)
-{
-  mpz_clear (shape[i]);
-  mpz_clear (shape2[i]);
-}
+  gfc_clear_shape (shape, i);
+  gfc_clear_shape (shape2, i);
   return result;
 }
 
diff --git a/trans-expr.c b/trans-expr.c
index 96510c2..b8ed4c5 100644
--- a/trans-expr.c
+++ b/trans-expr.c
@@ -4411,10 +4411,7 @@ gfc_trans_subarray_assign (tree dest, gfc_component * cm, gfc_expr * expr)
   gfc_add_block_to_block (&block, &loop.pre);
   gfc_add_block_to_block (&block, &loop.post);
 
-  for (n = 0; n < cm->as->rank; n++)
-mpz_clear (lss->shape[n]);
-  free (lss->shape);
-
+  gfc_free_shape (&lss->shape, cm->as->rank);
   gfc_cleanup_loop (&loop);
 
   return gfc_finish_block (&block);
diff --git a/trans-io.c b/trans-io.c
index 4e019a3..2ae34d8 100644
--- a/trans-io.c
+++ b/trans-io.c
@@ -1999,10 +1999,7 @@ t

Re: [PATCH][C++] Remove last use of can_trust_pointer_alignment

[H.J. Lu]

On Thu, Aug 11, 2011 at 1:57 AM, Richard Guenther  wrote:
> On Wed, 10 Aug 2011, Richard Guenther wrote:
>
>> On Wed, 10 Aug 2011, Richard Guenther wrote:
>>
>> > On Wed, 10 Aug 2011, Jason Merrill wrote:
>> >
>> > > On 08/10/2011 08:35 AM, Richard Guenther wrote:
>> > > >         * call.c (build_over_call): Call memcpy unconditionally.
>> > >
>> > > OK.  Have you tested the MEM_REF patch?
>> >
>> > No, not yet.  I'll throw it to testing now.
>>
>> The following is what passed bootstrap sofar and is in testing now.
>
> With the patch SRA now causes g++.dg/tree-ssa/pr41186.C to be fully
> optimized, making FRE useless.  Thus the patch needs to disable SRA
> when testing for FRE features.  This is somewhat expected as
> when no longer using memcpy nothing keeps the source/destination
> having their address taken and thus they get exposed to SRA.
>
> Bootstrapped and tested on x86_64-unknown-linux-gnu, ok for trunk?
>
> Thanks,
> Richard.
>
> 2011-08-11  Richard Guenther  
>
>        cp/
>        * call.c (build_over_call): Instead of memcpy use an
>        assignment of two MEM_REFs.
>

This caused:

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


-- 
H.J.

[Patch ARM] Fix PR target/48328 part 1

[Ramana Radhakrishnan]

Hi,

The Thumb2 tbh instruction can take half word values that are
multiplied by 2 which implies the maximum offset is 0x1 when you
add it to the pc ,
rather than 0xFFF which is what the current range check of 0x2000 for
HImode values indicates. Checked that a pre-compiled insn-recog.i that
I had lying around got about 5 more tbh's *and* assembled and
generally looks sane.

Tests running for T2 v7-a on qemu. Will commit after results come out.

cheers
Ramana

2011-08-12  Ramana Radhakrishnan  

PR target/48328
* config/arm/arm.h (CASE_VECTOR_SHORTEN_MODE): Fix distance
for tbh instructions.

diff --git a/gcc/config/arm/arm.h b/gcc/config/arm/arm.h
index 869b9a9..0a6e6f2 100644
--- a/gcc/config/arm/arm.h
+++ b/gcc/config/arm/arm.h
@@ -1906,7 +1906,7 @@ typedef struct
   : min >= -4096 && max < 4096 \
   ? (ADDR_DIFF_VEC_FLAGS (body).offset_unsigned = 0, HImode)   \
   : SImode)
 \
-   : ((min < 0 || max >= 0x2000 || !TARGET_THUMB2) ? SImode\
+   : ((min < 0 || max >= 0x2 || !TARGET_THUMB2) ? SImode   \
   : (max >= 0x200) ? HImode
 \
   : QImode))

[PATCH]: Fix -fbranch-probabilities

[Christian Bruel]

Hello,

-fbranch-probabilities fails to find the gcda information, because they 
are initialized only if flag_profile_use.


The problem is easily observable by recompiling with 
-fbranch-probabilities instead of -fprofile-use (after profile 
information generation)

This fails with "xxx.gcda not found, execution counts estimated".

This trivial patch fixes it. testsuite ok.

OK ?

Christian

2011-08-12  Christian Bruel  

	* coverage.c (coverage_init): Check flag_branch_probabilities instead of
	flag_profile_use.
	
Index: gcc/coverage.c
===
--- gcc/coverage.c	(revision 177690)
+++ gcc/coverage.c	(working copy)
@@ -1056,7 +1056,7 @@
   strcpy (bbg_file_name, filename);
   strcat (bbg_file_name, GCOV_NOTE_SUFFIX);
 
-  if (flag_profile_use)
+  if (flag_branch_probabilities)
 read_counts_file ();
 }
 

Re: [lto] Rename functions in tree/data streamer (issue4886041)

[Diego Novillo]

On Fri, Aug 12, 2011 at 09:50, Richard Guenther  wrote:

> Oh, how even more confusing ;)  So maybe hwi and uhwi instead then?
> That's what we use elsewhere.

Sounds good.  Done.


Diego.

Re: [lto] Rename functions in tree/data streamer (issue4886041)

[Richard Guenther]

On Fri, 12 Aug 2011, Diego Novillo wrote:

> On Fri, Aug 12, 2011 at 09:45, Richard Guenther  wrote:
> > On Fri, 12 Aug 2011, Diego Novillo wrote:
> >
> >>
> >> This is mind numbing but mechanical.  This rename does two things:
> >>
> >> 1- Replaces the 'lto_' prefix with 'streamer_' in all the public functions
> >>    that deal with generic streaming functionality (everything in
> >>    tree-streamer.h and data-streamer.h, essentially).
> >>
> >> 2- Replaces 'output' with 'write' and 'input' with 'read'.
> >>
> >> 3- Replaces dwarf terminology for numbers with C-like terminology:
> >>       sleb128 -> wide_int
> >>       uleb128 -> wide_uint
> >
> > hmm, rather int128 and uint128?  wide_int I'd confuse with HOST_WIDE_INT.
> 
> They *are* HOST_WIDE_INT.  That's why I renamed them to 'wide'.

Oh, how even more confusing ;)  So maybe hwi and uhwi instead then?
That's what we use elsewhere.

Richard.

Re: [lto] Rename functions in tree/data streamer (issue4886041)

[Diego Novillo]

On Fri, Aug 12, 2011 at 09:45, Richard Guenther  wrote:
> On Fri, 12 Aug 2011, Diego Novillo wrote:
>
>>
>> This is mind numbing but mechanical.  This rename does two things:
>>
>> 1- Replaces the 'lto_' prefix with 'streamer_' in all the public functions
>>    that deal with generic streaming functionality (everything in
>>    tree-streamer.h and data-streamer.h, essentially).
>>
>> 2- Replaces 'output' with 'write' and 'input' with 'read'.
>>
>> 3- Replaces dwarf terminology for numbers with C-like terminology:
>>       sleb128 -> wide_int
>>       uleb128 -> wide_uint
>
> hmm, rather int128 and uint128?  wide_int I'd confuse with HOST_WIDE_INT.

They *are* HOST_WIDE_INT.  That's why I renamed them to 'wide'.


Diego.

Re: [build] Move unwinder to toplevel libgcc (v2)

[H.J. Lu]

On Fri, Aug 12, 2011 at 5:38 AM, Pedro Alves  wrote:
> On Friday 12 August 2011 13:17:21, Paolo Bonzini wrote:
>>   2011-08-12  Paolo Bonzini  
>>
>>         * Makefile.in (install-unwind_h): Create 
>> $(gcc_objdir)/include/unwind.h
>>         atomically.
>>
>> Index: Makefile.in
>> ===
>> --- Makefile.in (revision 177688)
>> +++ Makefile.in (working copy)
>> @@ -991,8 +1001,10 @@ gcc-extra-parts:
>>  all: $(extra-parts)
>>
>>  install-unwind_h:
>> -       rm -f $(gcc_objdir)/include/unwind.h
>> -       cp unwind.h $(gcc_objdir)/include/unwind.h
>> +       cp unwind.h $(gcc_objdir)/include/tmp-unwind.h
>> +       sh $(srcdir)/../move-if-change \
>> +               $(gcc_objdir)/include/tmp-unwind.h \
>> +               $(gcc_objdir)/include/unwind.h
>>         chmod a+r $(gcc_objdir)/include/unwind.h
>>
>
> Can't this sequence happen?
>
> proc1:       cp unwind.h $(gcc_objdir)/include/tmp-unwind.h
> proc2:       cp unwind.h $(gcc_objdir)/include/tmp-unwind.h
> proc1:       sh $(srcdir)/../move-if-change \
>               $(gcc_objdir)/include/tmp-unwind.h \
>               $(gcc_objdir)/include/unwind.h
> proc2:       sh $(srcdir)/../move-if-change \
>               $(gcc_objdir)/include/tmp-unwind.h \
>               $(gcc_objdir)/include/unwind.h
>
> It sounds like the latter move-if-change could trip on
> a non-extant tmp-unwind.h.
>

Yes, we should use an unique tmp unwind.h.


-- 
H.J.

Re: [RFC ARM] Audit uses of optimize_size in the ARM backend.

[Richard Sandiford]

Ramana Radhakrishnan  writes:
> While the ARM backend doesn't support hot cold partitioning of basic blocks
> because of issues with the mini-pool placements, I suspect
> this by itself is a good cleanup. The bits of the use that I'm not
> convinced about
> yet are the changes of optimize_size in thumb_legitimize_address
> to optimize_insn_for_size_p and I'm looking for some comments there.

I'm not sure it's correct for the define_insns either.  I think it can
only be called during passes that produce new code, and which explicitly
set the global state appropriately (e.g. expand, split and peephole2).
I might be wrong, but as things stand, I don't think you can guarantee
that the global state describes the insn under test every time that
recog is called.

For existing insns, I think optimize_bb_for_speed_p (BLOCK_FOR_INSN (insn))
is the canonical check.

Richard

Re: [build] Move unwinder to toplevel libgcc (v2)

[Pedro Alves]

On Friday 12 August 2011 13:17:21, Paolo Bonzini wrote:
>   2011-08-12  Paolo Bonzini  
> 
> * Makefile.in (install-unwind_h): Create 
> $(gcc_objdir)/include/unwind.h
> atomically.
> 
> Index: Makefile.in
> ===
> --- Makefile.in (revision 177688)
> +++ Makefile.in (working copy)
> @@ -991,8 +1001,10 @@ gcc-extra-parts:
>  all: $(extra-parts)
>  
>  install-unwind_h:
> -   rm -f $(gcc_objdir)/include/unwind.h
> -   cp unwind.h $(gcc_objdir)/include/unwind.h
> +   cp unwind.h $(gcc_objdir)/include/tmp-unwind.h
> +   sh $(srcdir)/../move-if-change \
> +   $(gcc_objdir)/include/tmp-unwind.h \
> +   $(gcc_objdir)/include/unwind.h
> chmod a+r $(gcc_objdir)/include/unwind.h
>  

Can't this sequence happen?

proc1:   cp unwind.h $(gcc_objdir)/include/tmp-unwind.h
proc2:   cp unwind.h $(gcc_objdir)/include/tmp-unwind.h
proc1:   sh $(srcdir)/../move-if-change \
   $(gcc_objdir)/include/tmp-unwind.h \
   $(gcc_objdir)/include/unwind.h
proc2:   sh $(srcdir)/../move-if-change \
   $(gcc_objdir)/include/tmp-unwind.h \
   $(gcc_objdir)/include/unwind.h

It sounds like the latter move-if-change could trip on
a non-extant tmp-unwind.h.

-- 
Pedro Alves

Re: [PATCH, middle end]: Introduce BUILT_IN_I{CEIL_FLOOR_ROUND_RINT} FP-to-int conversion functions

[Uros Bizjak]

On Fri, Aug 12, 2011 at 2:18 PM, Richard Guenther  wrote:

>> Attached patch adds testcases for all conversion builtins. The gcc.dg
>> one tests that we are always able to link executable correctly, no
>> matter if target implements convresion optabs or not, the
>> gcc.target/i386 test exercises x86 specific code generation paths and
>> check if these builtins leak anything with -ffast-math.
>>
>> 2011-08-12  Uros Bizjak  
>>
>>       * gcc.dg/builtins-67.c: New test.
>>       * gcc.target/i386/conversion.c: Ditto.
>>
>> Tested on x86_64-pc-linux-gnu {,-m32}. OK for mainline?

Just FTR, attached was older version of the patch,

#include "builtins-config.h"

is needed in gcc.dg/builtins-67.c

and

#include "../../gcc.dg/builtins-config.h"

in gcc.target/i386/conversion.c.

Uros.

[RFC ARM] Audit uses of optimize_size in the ARM backend.

[Ramana Radhakrishnan]

Hi,

Quite some time back someone had pointed out that the ARM backend
used optimize_size in quite a few areas and that backends shouldn't
use this directly in patterns any more. I had written this patch up a few weeks
back and it was in one of my trees and had gone through some degree of
testing.

While the ARM backend doesn't support hot cold partitioning of basic blocks
because of issues with the mini-pool placements, I suspect
this by itself is a good cleanup. The bits of the use that I'm not
convinced about
yet are the changes of optimize_size in thumb_legitimize_address
to optimize_insn_for_size_p and I'm looking for some comments there.

There are still other uses of optimize_size and here are some thoughts
on what we should do there. I will go back and do this when I have
some more free time next but I hope to have the changes in by the time
stage1 is over if these are deemed to be useful.


   - arm/aout.h : ASM_OUTPUT_ADDR_DIFF_ELT : replace with
optimize_function_for_size_p ?
   - arm/arm.h : TARGET_USE_MOVT (probably again something that could
   benefit with the change.)
   - arm/arm.h : CONSTANT_ALIGNMENT - probably should retain optimize_size .
   - arm/arm.h : DATA_ALIGNMENT - Likewise.
   - arm/arm.h : CASE_VECTOR_PC_RELATIVE should go hand in glove with
addr_diff_elt output.
   - arm/coff.h or arm/elf.h : JUMP_TABLES_IN_TEXT_SECTION :
optimize_function_for_size_p () ?
   - arm/arm.c  (arm_compute_save_reg_mask) : Replace optimize_size
with optimize_function_for_size_p ().
   - arm/arm.c  (arm_output_epilogue): Replace optimize_size with
optimize_function_for_size_p ().
   - arm/arm.c ( arm_expand_prologue): Likewise
   - arm/arm.c (thumb1_extra_regs_pushed): optimize_function_for_size_p
   - arm/arm.c (arm_final_prescan_insn): Probably optimize_insn_for_size_p () .
   - arm/arm.c (arm_conditional_register_usage): optimize_function_for_size_p.


Ok for trunk after a bootstrap, test run ? Thoughts about what we do
with the rest of the uses ?

cheers
Ramana


  * config/arm/arm.md ("*mulsi3_compare0_v6"): Replace optimize_size
with optimize_insn_for_size_p.
("*mulsi_compare0_scratch_v6"): Likewise.
("*mulsi3addsi_compare0_v6"): Likewise.
("casesi"): Likewise.
(dimode_general_splitter): Name existing splitter and like above.
("bswapsi2"): Likewise.
* config/arm/thumb2.md (t2_muls_peepholes): Likewise.
* config/arm/arm.c (thumb_legitimize_address): Replace optimize_size
with optimize_insn_for_size_p.
(adjacent_mem_locations): Likewise.
(arm_const_double_by_parts): Likewise.
* config/arm/arm.h (FUNCTION_BOUNDARY): Use
optimize_function_for_size_p.
(MODE_BASE_REG_CLASS): Likewise.
* config/arm/constraints.md (constraint "Dc"): Use
optimize_insn_for_size_p.
diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index 6cd80f8..97dd249 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -6359,7 +6359,7 @@ thumb_legitimize_address (rtx x, rtx orig_x, enum 
machine_mode mode)
   /* Try and fold the offset into a biasing of the base register and
 then offsetting that.  Don't do this when optimizing for space
 since it can cause too many CSEs.  */
-  if (optimize_size && offset >= 0
+  if (optimize_insn_for_size_p () && offset >= 0
  && offset < 256 + 31 * GET_MODE_SIZE (mode))
{
  HOST_WIDE_INT delta;
@@ -9787,7 +9787,7 @@ adjacent_mem_locations (rtx a, rtx b)
  /* If the target has load delay slots, then there's no benefit
 to using an ldm instruction unless the offset is zero and
 we are optimizing for size.  */
- return (optimize_size && (REGNO (reg0) == REGNO (reg1))
+ return (optimize_insn_for_size_p () && (REGNO (reg0) == REGNO (reg1))
  && (val0 == 0 || val1 == 0 || val0 == 4 || val1 == 4)
  && (val_diff == 4 || val_diff == -4));
}
@@ -9868,7 +9868,7 @@ multiple_operation_profitable_p (bool is_store 
ATTRIBUTE_UNUSED,
 
  As a compromise, we use ldr for counts of 1 or 2 regs, and ldm
  for counts of 3 or 4 regs.  */
-  if (nops <= 2 && arm_tune_xscale && !optimize_size)
+  if (nops <= 2 && arm_tune_xscale && !optimize_insn_for_size_p ())
 return false;
   return true;
 }
@@ -12445,7 +12445,7 @@ arm_const_double_by_parts (rtx val)
   enum machine_mode mode = GET_MODE (val);
   rtx part;
 
-  if (optimize_size || arm_ld_sched)
+  if (optimize_insn_for_size_p () || arm_ld_sched)
 return true;
 
   if (mode == VOIDmode)
diff --git a/gcc/config/arm/arm.h b/gcc/config/arm/arm.h
index 869b9a9..b18f08e 100644
--- a/gcc/config/arm/arm.h
+++ b/gcc/config/arm/arm.h
@@ -533,7 +533,7 @@ extern int arm_arch_thumb_hwdiv;
 #define PREFERRED_STACK_BOUNDARY \
 (arm_abi == ARM_ABI_ATPCS ? 64 : STACK_BOUNDARY)
 
-#define FUNCTION_BOUNDARY  ((TARGET_THUMB && optimize_

Re: [PATCH, middle end]: Introduce BUILT_IN_I{CEIL_FLOOR_ROUND_RINT} FP-to-int conversion functions

[Richard Guenther]

On Fri, 12 Aug 2011, Uros Bizjak wrote:

> On Thu, Aug 11, 2011 at 2:50 PM, Richard Guenther  wrote:
> 
> >> Currently, conversion from floating point to integer on 64bit targets
> >> goes through DImode temporary, due to missing BUILT_IN_ICEIL (and
> >> other) builtins that can convert directly from FP to integer.
> 
> > Please document those in doc/extend.texi and make sure they do not
> > leak into the global namespace as ifloor, etc., but are only available
> > as __builtin_ifloor, etc..  Please also add at least a testcase
> > that excercises expanding all of the variants - like by simply
> > writing wrappers with the non-__builtin_ name variant like
> 
> Attached patch adds testcases for all conversion builtins. The gcc.dg
> one tests that we are always able to link executable correctly, no
> matter if target implements convresion optabs or not, the
> gcc.target/i386 test exercises x86 specific code generation paths and
> check if these builtins leak anything with -ffast-math.
> 
> 2011-08-12  Uros Bizjak  
> 
>   * gcc.dg/builtins-67.c: New test.
>   * gcc.target/i386/conversion.c: Ditto.
> 
> Tested on x86_64-pc-linux-gnu {,-m32}. OK for mainline?

Ok.

Thanks,
Richard.

Re: [build] Move unwinder to toplevel libgcc (v2)

[Paolo Bonzini]

On 08/12/2011 02:13 PM, H.J. Lu wrote:

We may have a race condition here.


I opened:

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


Does the attached patch work?


Can you provide a patch instead of the whole Makefile.in?


Sorry, that was not intended.

Paolo

2011-08-12  Paolo Bonzini  

	* Makefile.in (install-unwind_h): Create $(gcc_objdir)/include/unwind.h
	atomically.

Index: Makefile.in
===
--- Makefile.in	(revision 177688)
+++ Makefile.in	(working copy)
@@ -991,8 +1001,10 @@ gcc-extra-parts:
 all: $(extra-parts)
 
 install-unwind_h:
-	rm -f $(gcc_objdir)/include/unwind.h
-	cp unwind.h $(gcc_objdir)/include/unwind.h
+	cp unwind.h $(gcc_objdir)/include/tmp-unwind.h
+	sh $(srcdir)/../move-if-change \
+		$(gcc_objdir)/include/tmp-unwind.h \
+		$(gcc_objdir)/include/unwind.h
 	chmod a+r $(gcc_objdir)/include/unwind.h
 
 all: install-unwind_h

Re: [PATCH, middle end]: Introduce BUILT_IN_I{CEIL_FLOOR_ROUND_RINT} FP-to-int conversion functions

[Uros Bizjak]

On Thu, Aug 11, 2011 at 2:50 PM, Richard Guenther  wrote:

>> Currently, conversion from floating point to integer on 64bit targets
>> goes through DImode temporary, due to missing BUILT_IN_ICEIL (and
>> other) builtins that can convert directly from FP to integer.

> Please document those in doc/extend.texi and make sure they do not
> leak into the global namespace as ifloor, etc., but are only available
> as __builtin_ifloor, etc..  Please also add at least a testcase
> that excercises expanding all of the variants - like by simply
> writing wrappers with the non-__builtin_ name variant like

Attached patch adds testcases for all conversion builtins. The gcc.dg
one tests that we are always able to link executable correctly, no
matter if target implements convresion optabs or not, the
gcc.target/i386 test exercises x86 specific code generation paths and
check if these builtins leak anything with -ffast-math.

2011-08-12  Uros Bizjak  

* gcc.dg/builtins-67.c: New test.
* gcc.target/i386/conversion.c: Ditto.

Tested on x86_64-pc-linux-gnu {,-m32}. OK for mainline?

Uros.
Index: gcc.target/i386/conversion.c
===
--- gcc.target/i386/conversion.c(revision 0)
+++ gcc.target/i386/conversion.c(revision 0)
@@ -0,0 +1,54 @@
+/* Check that conversion functions don't leak into global namespace.  */
+
+/* { dg-do link } */
+/* { dg-options "-ffast-math" }  */
+
+int ifloor (double a) { return __builtin_ifloor (a); }
+#ifdef HAVE_C99_RUNTIME
+int ifloorf (float a) { return __builtin_ifloorf (a); }
+int ifloorl (long double a) { return __builtin_ifloorl (a); }
+#endif
+
+long lfloor (double a) { return __builtin_lfloor (a); }
+#ifdef HAVE_C99_RUNTIME
+long lfloorf (float a) { return __builtin_lfloorf (a); }
+long lfloorl (long double a) { return __builtin_lfloorl (a); }
+#endif
+
+long long llfloor (double a) { return __builtin_llfloor (a); }
+#ifdef HAVE_C99_RUNTIME
+long long llfloorf (float a) { return __builtin_llfloorf (a); }
+long long llfloorl (long double a) { return __builtin_llfloorl (a); }
+#endif
+
+int iceil (double a) { return __builtin_iceil (a); }
+#ifdef HAVE_C99_RUNTIME
+int iceilf (float a) { return __builtin_iceilf (a); }
+int iceill (long double a) { return __builtin_iceill (a); }
+#endif
+
+long lceil (double a) { return __builtin_lceil (a); }
+#ifdef HAVE_C99_RUNTIME
+long lceilf (float a) { return __builtin_lceilf (a); }
+long lceill (long double a) { return __builtin_lceill (a); }
+#endif
+
+long long llceil (double a) { return __builtin_llceil (a); }
+#ifdef HAVE_C99_RUNTIME
+long long llceilf (float a) { return __builtin_llceilf (a); }
+long long llceill (long double a) { return __builtin_llceill (a); }
+#endif
+
+int iround (double a) { return __builtin_iround (a); }
+#ifdef HAVE_C99_RUNTIME
+int iroundf (float a) { return __builtin_iroundf (a); }
+int iroundl (long double a) { return __builtin_iroundl (a); }
+#endif
+
+int irint (double a) { return __builtin_irint (a); }
+#ifdef HAVE_C99_RUNTIME
+int irintf (float a) { return __builtin_irintf (a); }
+int irintl (long double a) { return __builtin_irintl (a); }
+#endif
+
+int main () { return 0; }
Index: gcc.dg/builtins-67.c
===
--- gcc.dg/builtins-67.c(revision 0)
+++ gcc.dg/builtins-67.c(revision 0)
@@ -0,0 +1,71 @@
+/* Check that conversion functions link correctly with -ffast-math.  */
+
+/* { dg-do link } */
+/* { dg-options "-ffast-math -lm" }  */
+
+
+double floor (double);
+float floorf (float);
+long double floorl (long double);
+
+double ceil (double);
+float ceilf (float);
+long double ceill (long double);
+
+double round (double);
+float roundf (float);
+long double roundl (long double);
+
+double rint (double);
+float rintf (float);
+long double rintl (long double);
+
+int ifloor (double a) { return (int) floor (a); }
+#ifdef HAVE_C99_RUNTIME
+int ifloorf (float a) { return (int) floorf (a); }
+int ifloorl (long double a) { return (int) floorl (a); }
+#endif
+
+long lfloor (double a) { return (long) floor (a); }
+#ifdef HAVE_C99_RUNTIME
+long lfloorf (float a) { return (long) floorf (a); }
+long lfloorl (long double a) { return (long) floorl (a); }
+#endif
+
+long long llfloor (double a) { return (long long) floor (a); }
+#ifdef HAVE_C99_RUNTIME
+long long llfloorf (float a) { return (long long) floorf (a); }
+long long llfloorl (long double a) { return (long long) floorl (a); }
+#endif
+
+int iceil (double a) { return (int) ceil (a); }
+#ifdef HAVE_C99_RUNTIME
+int iceilf (float a) { return (int) ceilf (a); }
+int iceill (long double a) { return (int) ceill (a); }
+#endif
+
+long lceil (double a) { return (long) ceil (a); }
+#ifdef HAVE_C99_RUNTIME
+long lceilf (float a) { return (long) ceilf (a); }
+long lceill (long double a) { return (long) ceill (a); }
+#endif
+
+long long llceil (double a) { return (long long) ceil (a); }
+#ifdef HAVE_C99_RUNTIME
+long

Re: [build] Move unwinder to toplevel libgcc (v2)

[H.J. Lu]

On Fri, Aug 12, 2011 at 12:04 AM, Paolo Bonzini  wrote:
> On 08/11/2011 08:24 PM, H.J. Lu wrote:
>>
>> On Thu, Aug 11, 2011 at 11:19 AM, H.J. Lu  wrote:
>>>
>>> On Thu, Aug 11, 2011 at 8:23 AM, Rainer Orth
>>>   wrote:

 Paolo Bonzini  writes:

> On 08/10/2011 06:05 PM, Rainer Orth wrote:
>>
>>  True: it is called once per multilib.

  Just to doublecheck, are we sure that unwind.h is always the same?
>>
>> Yep: it's unwind-generic.h for almost all targets, just a few arm
>> targets use config/arm/unwind-arm.h for all multilibs.
>
> Patch doing rm -f is preapproved then.

 Here's what I installed, after making libgcc/unwind-generic.h read-only,
 reconfiguring and rebuilding first without and with the patch and
 observe the bug gone on i386-pc-solaris2.10.

        Rainer


 2011-08-11  Rainer Orth

        * Makefile.in (install-unwind_h): Remove destination file first.

 diff --git a/libgcc/Makefile.in b/libgcc/Makefile.in
 --- a/libgcc/Makefile.in
 +++ b/libgcc/Makefile.in
 @@ -994,6 +994,7 @@ gcc-extra-parts:
  all: $(extra-parts)

  install-unwind_h:
 +       rm -f $(gcc_objdir)/include/unwind.h
        cp unwind.h $(gcc_objdir)/include/unwind.h
        chmod a+r $(gcc_objdir)/include/unwind.h

>>>
>>> It breaks bootstrap with "make -j12" on a 24 core Linux/x86-64  :
>>>
>>> http://gcc.gnu.org/ml/gcc-regression/2011-08/msg00179.html
>>>
>>> rm -f ../../.././gcc/include/unwind.h
>>> cp unwind.h ../../.././gcc/include/unwind.h
>>> rm -f ../.././gcc/include/unwind.h
>>> chmod a+r ../../.././gcc/include/unwind.h
>>> cp unwind.h ../.././gcc/include/unwind.h
>>> chmod: cannot access `../../.././gcc/include/unwind.h': No such file
>>> or directory
>>> make[8]: *** [install-unwind_h] Error 1
>>> make[8]: *** Waiting for unfinished jobs
>>> chmod a+r ../.././gcc/include/unwind.h
>>>
>>> We may have a race condition here.
>>
>> I opened:
>>
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50047
>
> Does the attached patch work?
>

Can you provide a patch instead of the whole Makefile.in?


-- 
H.J.

[PATCH] More VRP TLC

[Richard Guenther]

This implements NEGATE_EXPR as 0 - X, re-using code we have for
MINUS_EXPR.

Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.

Richard.

2011-08-12  Richard Guenther  

* tree-vrp.c (extract_range_from_unary_expr_1): Implement
-X as 0 - X.

Index: gcc/tree-vrp.c
===
--- gcc/tree-vrp.c  (revision 177671)
+++ gcc/tree-vrp.c  (working copy)
@@ -2946,67 +2946,14 @@ extract_range_from_unary_expr_1 (value_r
 
   /* Apply the operation to each end of the range and see what we end
  up with.  */
-  if (code == NEGATE_EXPR
-  && !TYPE_UNSIGNED (type))
+  if (code == NEGATE_EXPR)
 {
-  /* NEGATE_EXPR flips the range around.  We need to treat
-TYPE_MIN_VALUE specially.  */
-  if (is_positive_overflow_infinity (vr0.max))
-   min = negative_overflow_infinity (type);
-  else if (is_negative_overflow_infinity (vr0.max))
-   min = positive_overflow_infinity (type);
-  else if (!vrp_val_is_min (vr0.max))
-   min = fold_unary_to_constant (code, type, vr0.max);
-  else if (needs_overflow_infinity (type))
-   {
- if (supports_overflow_infinity (type)
- && !is_overflow_infinity (vr0.min)
- && !vrp_val_is_min (vr0.min))
-   min = positive_overflow_infinity (type);
- else
-   {
- set_value_range_to_varying (vr);
- return;
-   }
-   }
-  else
-   min = TYPE_MIN_VALUE (type);
-
-  if (is_positive_overflow_infinity (vr0.min))
-   max = negative_overflow_infinity (type);
-  else if (is_negative_overflow_infinity (vr0.min))
-   max = positive_overflow_infinity (type);
-  else if (!vrp_val_is_min (vr0.min))
-   max = fold_unary_to_constant (code, type, vr0.min);
-  else if (needs_overflow_infinity (type))
-   {
- if (supports_overflow_infinity (type))
-   max = positive_overflow_infinity (type);
- else
-   {
- set_value_range_to_varying (vr);
- return;
-   }
-   }
-  else
-   max = TYPE_MIN_VALUE (type);
-}
-  else if (code == NEGATE_EXPR
-  && TYPE_UNSIGNED (type))
-{
-  if (!range_includes_zero_p (&vr0))
-   {
- max = fold_unary_to_constant (code, type, vr0.min);
- min = fold_unary_to_constant (code, type, vr0.max);
-   }
-  else
-   {
- if (range_is_null (&vr0))
-   set_value_range_to_null (vr, type);
- else
-   set_value_range_to_varying (vr);
- return;
-   }
+  /* -X is simply 0 - X, so re-use existing code that also handles
+ anti-ranges fine.  */
+  value_range_t zero = { VR_UNDEFINED, NULL_TREE, NULL_TREE, NULL };
+  set_value_range_to_value (&zero, build_int_cst (type, 0), NULL);
+  extract_range_from_binary_expr_1 (vr, MINUS_EXPR, type, &zero, &vr0);
+  return;
 }
   else if (code == ABS_EXPR
&& !TYPE_UNSIGNED (type))

Re: [PATCH, middle end]: Introduce BUILT_IN_I{CEIL_FLOOR_ROUND_RINT} FP-to-int conversion functions

[Richard Guenther]

On Fri, 12 Aug 2011, Uros Bizjak wrote:

> On Thu, Aug 11, 2011 at 2:50 PM, Richard Guenther  wrote:
> 
> >> Currently, conversion from floating point to integer on 64bit targets
> >> goes through DImode temporary, due to missing BUILT_IN_ICEIL (and
> >> other) builtins that can convert directly from FP to integer.
> 
> > Please document those in doc/extend.texi and make sure they do not
> > leak into the global namespace as ifloor, etc., but are only available
> > as __builtin_ifloor, etc..  Please also add at least a testcase
> > that excercises expanding all of the variants - like by simply
> > writing wrappers with the non-__builtin_ name variant like
> 
> Regarding the documentation, I found this in the @section Other
> built-in functions provided by GCC:
> 
> 
> 
> GCC provides a large number of built-in functions other than the ones
> mentioned above.  Some of these are for internal use in the processing
> of exceptions or variable-length argument lists and will not be
> documented here because they may change from time to time; we do not
> recommend general use of these functions.
> 
> The remaining functions are provided for optimization purposes.
> 
> 
> 
> These new functions definitely fall under this category, and for the
> same reason we didn't document lceil/lfloor builtins. They are used
> internally for optimization purposes and the same functionality can be
> achieved by simply writing (int) ceil (...).

Hmm, I see.  It's unfortunate that we have no place to document
their semantics though, even if just internal (for lceil we have
the named pattern docs in md.texi).  Now, our internal documentation
is in a sorry enough state to not bother trying to add a new section
about internal builtins somewhere ... (?)  I'd add it to gimple.texi
in a new section 'Internal builtin functions'.

Richard.

Re: [PATCH, middle end]: Introduce BUILT_IN_I{CEIL_FLOOR_ROUND_RINT} FP-to-int conversion functions

[Uros Bizjak]

On Thu, Aug 11, 2011 at 2:50 PM, Richard Guenther  wrote:

>> Currently, conversion from floating point to integer on 64bit targets
>> goes through DImode temporary, due to missing BUILT_IN_ICEIL (and
>> other) builtins that can convert directly from FP to integer.

> Please document those in doc/extend.texi and make sure they do not
> leak into the global namespace as ifloor, etc., but are only available
> as __builtin_ifloor, etc..  Please also add at least a testcase
> that excercises expanding all of the variants - like by simply
> writing wrappers with the non-__builtin_ name variant like

Regarding the documentation, I found this in the @section Other
built-in functions provided by GCC:



GCC provides a large number of built-in functions other than the ones
mentioned above.  Some of these are for internal use in the processing
of exceptions or variable-length argument lists and will not be
documented here because they may change from time to time; we do not
recommend general use of these functions.

The remaining functions are provided for optimization purposes.



These new functions definitely fall under this category, and for the
same reason we didn't document lceil/lfloor builtins. They are used
internally for optimization purposes and the same functionality can be
achieved by simply writing (int) ceil (...).

Uros.

Re: [c++] Keep tm, div_t, ldiv_t, lconv mangling on Solaris (PR libstdc++-v3/1773)

[Rainer Orth]

Jason Merrill  writes:

> On 08/11/2011 10:49 AM, Rainer Orth wrote:
>> There might be an alternative implementation that is less invasive to
>> the C++ frontend, though: add
>>
>>  &&  TARGET_DECL_NAMESPACE_STD_P (decl)
>>
>> in write_unscoped_name, defaulting to true, override it in sol2.h (which
>> gets included via tm.h) and have the remaining logic in a new sol2-cxx.c
>> file.
>
> I would be OK with a target hook.  I think a cleaner place would be to hook

I'd found that this is the way to go when having a more detailed look
last night.

> decl_mangling_context and then change write_unscoped_name to use
> decl_mangling_context instead of CP_DECL_CONTEXT.

Thanks for the hint, I'll see what I can come up with.

Rainer

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

Re: [Patch ARM] Fix PR50022

[Richard Earnshaw]

On 12/08/11 10:28, Ramana Radhakrishnan wrote:
> On 12 August 2011 10:19, Ramana Radhakrishnan
>  wrote:
>> Hi,
>>
>> The attached patch fixes up PR50022 which exposed a problem in my reworking
> 
> And with the patch even :( ...
> 
> Ramana
> 
> 2011-08-12  Ramana Radhakrishnan  
> 
>PR target/50022
>* config/arm/arm.c (output_move_double): Add 2 parameters
>to count the number of insns emitted and whether to emit or not.
>Use the flag to decide when to emit and count number of instructions
>that will be emitted.
>Handle case where output_move_double might be called for calculating
>lengths with an invalid constant.
>(arm_count_output_move_double_insns): Define.
>* config/arm/arm-protos.h (arm_count_output_move_double_insns): 
> Declare.
>(output_move_double): Adjust prototype.
>* config/arm/vfp.md ("*movdi_vfp"): Adjust call to
>output_move_double.
>("*movdi_vfp_cortexa8"): Likewise and add attribute
>for ce_count.
>* config/arm/arm.md ("*arm_movdi"): Adjust call to output_move_double.
>("*movdf_soft_insn"): Likewise.
>* config/arm/cirrus.md ("*cirrus_arm_movdi"): Likewise.
>("*cirrus_thumb2_movdi"): Likewise.
>("*thumb2_cirrus_movdf_hard_insn"): Likewise.
>("*cirrus_movdf_hard_insn"): Likewise.
>* config/arm/neon.md (*neon_mov VD): Likewise.
>* config/arm/iwmmxt.md ("*iwmmxt_arm_movdi"): Likewise.
>("mov_internal VMMX"): Likewise.
> 

Use a bool for "emit".  Otherwise OK.

R.

> 
> final-pr50022-patch.txt
> 
> 
> diff --git a/gcc/config/arm/arm-protos.h b/gcc/config/arm/arm-protos.h
> index 2f7c508..d99d1ce 100644
> --- a/gcc/config/arm/arm-protos.h
> +++ b/gcc/config/arm/arm-protos.h
> @@ -131,8 +131,9 @@ extern const char *output_mov_long_double_arm_from_fpa 
> (rtx *);
>  extern const char *output_mov_long_double_arm_from_arm (rtx *);
>  extern const char *output_mov_double_fpa_from_arm (rtx *);
>  extern const char *output_mov_double_arm_from_fpa (rtx *);
> -extern const char *output_move_double (rtx *);
> +extern const char *output_move_double (rtx *, int, int *count);
>  extern const char *output_move_quad (rtx *);
> +extern int arm_count_output_move_double_insns (rtx *);
>  extern const char *output_move_vfp (rtx *operands);
>  extern const char *output_move_neon (rtx *operands);
>  extern int arm_attr_length_move_neon (rtx);
> diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
> index 6cd80f8..446be81 100644
> --- a/gcc/config/arm/arm.c
> +++ b/gcc/config/arm/arm.c
> @@ -13262,11 +13262,24 @@ output_mov_double_arm_from_fpa (rtx *operands)
>  /* Output a move between double words.  It must be REG<-MEM
> or MEM<-REG.  */
>  const char *
> -output_move_double (rtx *operands)
> +output_move_double (rtx *operands, int emit, int *count)
>  {
>enum rtx_code code0 = GET_CODE (operands[0]);
>enum rtx_code code1 = GET_CODE (operands[1]);
>rtx otherops[3];
> +  if (count)
> +*count = 1;
> +
> +  /* The only case when this might happen is when 
> + you are looking at the length of a DImode instruction
> + that has an invalid constant in it.  */
> +  if (code0 == REG && code1 != MEM)
> +{
> +  gcc_assert (!emit);
> +  *count = 2;
> +  return "";
> +}
> +  
>  
>if (code0 == REG)
>  {
> @@ -13279,35 +13292,49 @@ output_move_double (rtx *operands)
>switch (GET_CODE (XEXP (operands[1], 0)))
>   {
>   case REG:
> -   if (TARGET_LDRD
> -   && !(fix_cm3_ldrd && reg0 == REGNO(XEXP (operands[1], 0
> - output_asm_insn ("ldr%(d%)\t%0, [%m1]", operands);
> -   else
> - output_asm_insn ("ldm%(ia%)\t%m1, %M0", operands);
> +
> +   if (emit)
> + {
> +   if (TARGET_LDRD
> +   && !(fix_cm3_ldrd && reg0 == REGNO(XEXP (operands[1], 0
> + output_asm_insn ("ldr%(d%)\t%0, [%m1]", operands);
> +   else
> + output_asm_insn ("ldm%(ia%)\t%m1, %M0", operands);
> + }
> break;
>  
>   case PRE_INC:
> gcc_assert (TARGET_LDRD);
> -   output_asm_insn ("ldr%(d%)\t%0, [%m1, #8]!", operands);
> +   if (emit)
> + output_asm_insn ("ldr%(d%)\t%0, [%m1, #8]!", operands);
> +   
> break;
>  
>   case PRE_DEC:
> -   if (TARGET_LDRD)
> - output_asm_insn ("ldr%(d%)\t%0, [%m1, #-8]!", operands);
> -   else
> - output_asm_insn ("ldm%(db%)\t%m1!, %M0", operands);
> +   if (emit)
> + {
> +   if (TARGET_LDRD)
> + output_asm_insn ("ldr%(d%)\t%0, [%m1, #-8]!", operands);
> +   else
> + output_asm_insn ("ldm%(db%)\t%m1!, %M0", operands);
> + }
> break;
>  
>   case POST_INC:
> -   if (TARGET_LDRD)
> - output_asm_insn ("ldr%(d%)\t%0, [%m1], #8", operands);
> -   else
> - output_asm_insn ("ldm%(ia%)\t%m1!, %M0", operand

RE: [PATCH][C++] Remove last use of can_trust_pointer_alignment

[Richard Guenther]

On Fri, 12 Aug 2011, James Greenhalgh wrote:

> > 2011-08-10  Richard Guenther  
> > 
> > * tree.h (can_trust_pointer_alignment): Remove.
> > * builtins.c (can_trust_pointer_alignment): Remove.
> > 
> > cp/
> > * call.c (build_over_call): Call memcpy unconditionally.
> > 
> 
> Hi,
> 
> This appears to have caused a regression on arm-unknown-eabi
> 
> *** EXIT code 4242
> FAIL: g++.dg/init/copy7.C execution test

Ah, that looks "expected".  Can you verify the regression persists
at r177691?  If so it is a generic middle-end issue (see also
comment #18 mentioned in the PR).

Thanks,
Richard.

Re: [Patch ARM] Fix PR50022

[Ramana Radhakrishnan]

On 12 August 2011 10:19, Ramana Radhakrishnan
 wrote:
> Hi,
>
> The attached patch fixes up PR50022 which exposed a problem in my reworking

And with the patch even :( ...

Ramana

2011-08-12  Ramana Radhakrishnan  

   PR target/50022
   * config/arm/arm.c (output_move_double): Add 2 parameters
   to count the number of insns emitted and whether to emit or not.
   Use the flag to decide when to emit and count number of instructions
   that will be emitted.
   Handle case where output_move_double might be called for calculating
   lengths with an invalid constant.
   (arm_count_output_move_double_insns): Define.
   * config/arm/arm-protos.h (arm_count_output_move_double_insns): Declare.
   (output_move_double): Adjust prototype.
   * config/arm/vfp.md ("*movdi_vfp"): Adjust call to
   output_move_double.
   ("*movdi_vfp_cortexa8"): Likewise and add attribute
   for ce_count.
   * config/arm/arm.md ("*arm_movdi"): Adjust call to output_move_double.
   ("*movdf_soft_insn"): Likewise.
   * config/arm/cirrus.md ("*cirrus_arm_movdi"): Likewise.
   ("*cirrus_thumb2_movdi"): Likewise.
   ("*thumb2_cirrus_movdf_hard_insn"): Likewise.
   ("*cirrus_movdf_hard_insn"): Likewise.
   * config/arm/neon.md (*neon_mov VD): Likewise.
   * config/arm/iwmmxt.md ("*iwmmxt_arm_movdi"): Likewise.
   ("mov_internal VMMX"): Likewise.
diff --git a/gcc/config/arm/arm-protos.h b/gcc/config/arm/arm-protos.h
index 2f7c508..d99d1ce 100644
--- a/gcc/config/arm/arm-protos.h
+++ b/gcc/config/arm/arm-protos.h
@@ -131,8 +131,9 @@ extern const char *output_mov_long_double_arm_from_fpa (rtx 
*);
 extern const char *output_mov_long_double_arm_from_arm (rtx *);
 extern const char *output_mov_double_fpa_from_arm (rtx *);
 extern const char *output_mov_double_arm_from_fpa (rtx *);
-extern const char *output_move_double (rtx *);
+extern const char *output_move_double (rtx *, int, int *count);
 extern const char *output_move_quad (rtx *);
+extern int arm_count_output_move_double_insns (rtx *);
 extern const char *output_move_vfp (rtx *operands);
 extern const char *output_move_neon (rtx *operands);
 extern int arm_attr_length_move_neon (rtx);
diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index 6cd80f8..446be81 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -13262,11 +13262,24 @@ output_mov_double_arm_from_fpa (rtx *operands)
 /* Output a move between double words.  It must be REG<-MEM
or MEM<-REG.  */
 const char *
-output_move_double (rtx *operands)
+output_move_double (rtx *operands, int emit, int *count)
 {
   enum rtx_code code0 = GET_CODE (operands[0]);
   enum rtx_code code1 = GET_CODE (operands[1]);
   rtx otherops[3];
+  if (count)
+*count = 1;
+
+  /* The only case when this might happen is when 
+ you are looking at the length of a DImode instruction
+ that has an invalid constant in it.  */
+  if (code0 == REG && code1 != MEM)
+{
+  gcc_assert (!emit);
+  *count = 2;
+  return "";
+}
+  
 
   if (code0 == REG)
 {
@@ -13279,35 +13292,49 @@ output_move_double (rtx *operands)
   switch (GET_CODE (XEXP (operands[1], 0)))
{
case REG:
- if (TARGET_LDRD
- && !(fix_cm3_ldrd && reg0 == REGNO(XEXP (operands[1], 0
-   output_asm_insn ("ldr%(d%)\t%0, [%m1]", operands);
- else
-   output_asm_insn ("ldm%(ia%)\t%m1, %M0", operands);
+
+ if (emit)
+   {
+ if (TARGET_LDRD
+ && !(fix_cm3_ldrd && reg0 == REGNO(XEXP (operands[1], 0
+   output_asm_insn ("ldr%(d%)\t%0, [%m1]", operands);
+ else
+   output_asm_insn ("ldm%(ia%)\t%m1, %M0", operands);
+   }
  break;
 
case PRE_INC:
  gcc_assert (TARGET_LDRD);
- output_asm_insn ("ldr%(d%)\t%0, [%m1, #8]!", operands);
+ if (emit)
+   output_asm_insn ("ldr%(d%)\t%0, [%m1, #8]!", operands);
+ 
  break;
 
case PRE_DEC:
- if (TARGET_LDRD)
-   output_asm_insn ("ldr%(d%)\t%0, [%m1, #-8]!", operands);
- else
-   output_asm_insn ("ldm%(db%)\t%m1!, %M0", operands);
+ if (emit)
+   {
+ if (TARGET_LDRD)
+   output_asm_insn ("ldr%(d%)\t%0, [%m1, #-8]!", operands);
+ else
+   output_asm_insn ("ldm%(db%)\t%m1!, %M0", operands);
+   }
  break;
 
case POST_INC:
- if (TARGET_LDRD)
-   output_asm_insn ("ldr%(d%)\t%0, [%m1], #8", operands);
- else
-   output_asm_insn ("ldm%(ia%)\t%m1!, %M0", operands);
+ 
+ if (emit)
+   {
+ if (TARGET_LDRD)
+   output_asm_insn ("ldr%(d%)\t%0, [%m1], #8", operands);
+ else
+   output_asm_insn ("ldm%(ia%)\t%m1!, %M0", operands);
+   }
  break;
 
case POST_DEC:
 

[Patch ARM] Fix PR50022

[Ramana Radhakrishnan]

Hi,

The attached patch fixes up PR50022 which exposed a problem in my reworking
the movdi_vfp_cortex_a8 patterns.  The problem was the ce_count attribute
wasn't being set at all for alternatives that would have more than
one assembler instruction that could be generated as a result of
predication.

The ce_count attribute is used in the backend to determine how many
actual assembler instructions result from one pattern in the backend
to allow for proper packing of IT block instructions.

I know I have set the length field conservatively but checking for
each of the cases for Thumb2 to get the exact lengths can be the
subject of a follow-up patch.

A slightly different version of this patch was tested independently
by Matthias Klose to check that it fixed the Ada bootstrap issue.
The other alternative was to split this again into an ARM state pattern
and a Thumb2 state pattern with the Thumb2 pattern not being marked
as predicable.

Final testing in progress on qemu with armv7-a / Thumb2 and a
bootstrap for paranoia. Ok to commit if no regressions ?

Cheers
Ramana



2011-08-12  Ramana Radhakrishnan  

PR target/50022
* config/arm/arm.c (output_move_double): Add 2 parameters
to count the number of insns emitted and whether to emit or not.
Use the flag to decide when to emit and count number of instructions
that will be emitted.
Handle case where output_move_double might be called for calculating
lengths with an invalid constant.
(arm_count_output_move_double_insns): Define.
* config/arm/arm-protos.h (arm_count_output_move_double_insns): Declare.
(output_move_double): Adjust prototype.
* config/arm/vfp.md ("*movdi_vfp"): Adjust call to
output_move_double.
("*movdi_vfp_cortexa8"): Likewise and add attribute
for ce_count.
* config/arm/arm.md ("*arm_movdi"): Adjust call to output_move_double.
("*movdf_soft_insn"): Likewise.
* config/arm/cirrus.md ("*cirrus_arm_movdi"): Likewise.
("*cirrus_thumb2_movdi"): Likewise.
("*thumb2_cirrus_movdf_hard_insn"): Likewise.
("*cirrus_movdf_hard_insn"): Likewise.
* config/arm/neon.md (*neon_mov VD): Likewise.
* config/arm/iwmmxt.md ("*iwmmxt_arm_movdi"): Likewise.
("mov_internal VMMX"): Likewise.

RE: [PATCH][C++] Remove last use of can_trust_pointer_alignment

[James Greenhalgh]

> 2011-08-10  Richard Guenther  
> 
>   * tree.h (can_trust_pointer_alignment): Remove.
>   * builtins.c (can_trust_pointer_alignment): Remove.
> 
>   cp/
>   * call.c (build_over_call): Call memcpy unconditionally.
> 

Hi,

This appears to have caused a regression on arm-unknown-eabi

*** EXIT code 4242
FAIL: g++.dg/init/copy7.C execution test

Thanks,
James Greenhalgh

Re: [PATCH, ARM] Fix PR target/49437 Thumb2 epilog with stack realignment

[Ramana Radhakrishnan]

On 3 August 2011 01:44, Joey Ye  wrote:
>
> This patch fixes PR49437 with a single line change in ARM backend
> and a regression test case for ARM target
>
> ChangeLog:
> 2011-08-02  Matthew Gretton-Dann  
>        PR target/49437
>        * config/arm/arm.c (arm_output_epilogue): Properly handle epilogue
>        when stack was realigned in interrupt handler prologue.
>
> 2011-08-02  Joey Ye  
>        PR target/49437
>        * gcc.target/arm/handler-align.c: New test.
>        * lib/target-supports.exp (check_effective_target_arm_cortex_m):
>          New Function.
>

Please make sure your Changelogs have a blank line between
  

and the text for the Changelog.

The backend related changes are OK and the testsuite changes for ARM
are ok as well. However please allow 24 hours for a testsuite
maintainer to comment before committing though.


Ramana

Re: [PATCH] [JAVA] Double.parseDouble(null) throw NullPointerException

[Bryce McKinlay]

On Fri, Aug 12, 2011 at 8:27 AM, Jie Liu  wrote:

> The method length() is not a final method, as java/lang/String.java line 447:
>
>  public int length()
>  {
>    return count;
>  }
>
> Is this the problem?

As String is a final class, all its methods are implicitly final.

Bryce

Re: [PATCH] [JAVA] Double.parseDouble(null) throw NullPointerException

[Jie Liu]

> Jie> But it does not work as we want, is there something wrong?
>
> Did you rebuild all of libgcj?

Yes. :)
>
> If you did, then I don't know, you'll have to debug it, sorry.
>
> I vaguely recollect that -fcheck-references adds a check for 'this' at
> the start of final methods.  If I'm misremembering, then that is
> probably the problem.
>
The method length() is not a final method, as java/lang/String.java line 447:

  public int length()
  {
return count;
  }

Is this the problem?

Thanks,
Jie
> Tom
>

Re: [PATCH 09/11] Add scop->context

[Sven Verdoolaege]

On Thu, Aug 11, 2011 at 05:44:37PM -0500, Sebastian Pop wrote:
> +  ctx = isl_ctx_alloc ();

I can't find the call to cloog_isl_state_malloc in this patch
that Tobi correctly requested.

skimo

Re: [PATCH 09/11] Add scop->context

[Tobias Grosser]

diff --git a/gcc/graphite.c b/gcc/graphite.c
index 8f6d8a1..b2cf7c6 100644
--- a/gcc/graphite.c
+++ b/gcc/graphite.c
@@ -260,10 +260,12 @@ graphite_transform_loops (void)
bool need_cfg_cleanup_p = false;
VEC (scop_p, heap) *scops = NULL;
htab_t bb_pbb_mapping;
+  isl_ctx *ctx;

if (!graphite_initialize ())
  return;

+  ctx = isl_ctx_alloc ();
build_scops (&scops);

if (dump_file&&  (dump_flags&  TDF_DETAILS))
@@ -277,6 +279,7 @@ graphite_transform_loops (void)
FOR_EACH_VEC_ELT (scop_p, scops, i, scop)
  if (dbg_cnt (graphite_scop))
{
+   scop->ctx = ctx;
build_poly_scop (scop);

if (POLY_SCOP_P (scop)
@@ -288,6 +291,7 @@ graphite_transform_loops (void)
htab_delete (bb_pbb_mapping);
free_scops (scops);
graphite_finalize (need_cfg_cleanup_p);
+  isl_ctx_free (ctx);
  }


You should pass context to graphite_initialize() and use
CloogState *cloog_isl_state_malloc(struct isl_ctx *ctx);
to allocate the CloogState. It is defined in
cloog/isl/cloog.h

Tobi

Re: [PATCH 08/11] Add ISL data structures

[Sven Verdoolaege]

Shouldn't you document that you need isl now?

skimo

Re: [build] Move unwinder to toplevel libgcc (v2)

[Paolo Bonzini]

On 08/11/2011 08:24 PM, H.J. Lu wrote:

On Thu, Aug 11, 2011 at 11:19 AM, H.J. Lu  wrote:

On Thu, Aug 11, 2011 at 8:23 AM, Rainer Orth
  wrote:

Paolo Bonzini  writes:


On 08/10/2011 06:05 PM, Rainer Orth wrote:

  True: it is called once per multilib.


  Just to doublecheck, are we sure that unwind.h is always the same?

Yep: it's unwind-generic.h for almost all targets, just a few arm
targets use config/arm/unwind-arm.h for all multilibs.


Patch doing rm -f is preapproved then.


Here's what I installed, after making libgcc/unwind-generic.h read-only,
reconfiguring and rebuilding first without and with the patch and
observe the bug gone on i386-pc-solaris2.10.

Rainer


2011-08-11  Rainer Orth

* Makefile.in (install-unwind_h): Remove destination file first.

diff --git a/libgcc/Makefile.in b/libgcc/Makefile.in
--- a/libgcc/Makefile.in
+++ b/libgcc/Makefile.in
@@ -994,6 +994,7 @@ gcc-extra-parts:
  all: $(extra-parts)

  install-unwind_h:
+   rm -f $(gcc_objdir)/include/unwind.h
cp unwind.h $(gcc_objdir)/include/unwind.h
chmod a+r $(gcc_objdir)/include/unwind.h



It breaks bootstrap with "make -j12" on a 24 core Linux/x86-64  :

http://gcc.gnu.org/ml/gcc-regression/2011-08/msg00179.html

rm -f ../../.././gcc/include/unwind.h
cp unwind.h ../../.././gcc/include/unwind.h
rm -f ../.././gcc/include/unwind.h
chmod a+r ../../.././gcc/include/unwind.h
cp unwind.h ../.././gcc/include/unwind.h
chmod: cannot access `../../.././gcc/include/unwind.h': No such file
or directory
make[8]: *** [install-unwind_h] Error 1
make[8]: *** Waiting for unfinished jobs
chmod a+r ../.././gcc/include/unwind.h

We may have a race condition here.


I opened:

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


Does the attached patch work?

Paolo
# Makefile.in

# Copyright (C) 2005, 2006, 2009, 2010, 2011 Free Software Foundation
#
# This file is part of GCC.
#
# GCC is free software; you can redistribute it and/or modify it under the
# terms of the GNU Library General Public License as published by the Free
# Software Foundation; either version 3 of the License, or (at your option)
# any later version.
#
# GCC is distributed in the hope that it will be useful, but WITHOUT ANY
# WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS
# FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
# more details.
#
# You should have received a copy of the GNU General Public License along
# with GCC; see the file COPYING3.  If not see
# .
#

libgcc_topdir = @libgcc_topdir@
host_subdir = @host_subdir@

gcc_srcdir = $(libgcc_topdir)/gcc
gcc_objdir = $(MULTIBUILDTOP)../../$(host_subdir)/gcc

srcdir = @srcdir@

prefix = @prefix@

exec_prefix = @exec_prefix@
libdir = @libdir@
shlib_slibdir = @slibdir@

SHELL = @SHELL@

cpu_type = @cpu_type@
enable_shared = @enable_shared@
double_type_size = @double_type_size@
long_double_type_size = @long_double_type_size@
decimal_float = @decimal_float@
enable_decimal_float = @enable_decimal_float@
fixed_point = @fixed_point@

host_noncanonical = @host_noncanonical@
target_noncanonical = @target_noncanonical@

# List of extra object files that should be compiled for this target machine.
# The rules for compiling them should be in the t-* file for the machine.
EXTRA_PARTS = @extra_parts@

# Multilib support variables.
MULTISRCTOP =
MULTIBUILDTOP =
MULTIDIRS =
MULTISUBDIR =
MULTIDO = true
MULTICLEAN = true

INSTALL = @INSTALL@
INSTALL_PROGRAM = @INSTALL_PROGRAM@
INSTALL_DATA = @INSTALL_DATA@
mkinstalldirs = $(SHELL) $(libgcc_topdir)/mkinstalldirs

objext = .o

AR = @AR@
AR_FLAGS = rc

CC = @CC@
CFLAGS = @CFLAGS@
RANLIB = @RANLIB@
LN_S = @LN_S@

PWD_COMMAND = $${PWDCMD-pwd}

# Flags to pass to a recursive make.
FLAGS_TO_PASS = \
"AR=$(AR)" \
"AR_FLAGS=$(AR_FLAGS)" \
"CC=$(CC)" \
"CFLAGS=$(CFLAGS)" \
"DESTDIR=$(DESTDIR)" \
"EXTRA_OFILES=$(EXTRA_OFILES)" \
"HDEFINES=$(HDEFINES)" \
"INSTALL=$(INSTALL)" \
"INSTALL_DATA=$(INSTALL_DATA)" \
"INSTALL_PROGRAM=$(INSTALL_PROGRAM)" \
"LDFLAGS=$(LDFLAGS)" \
"LOADLIBES=$(LOADLIBES)" \
"RANLIB=$(RANLIB)" \
"SHELL=$(SHELL)" \
"prefix=$(prefix)" \
"exec_prefix=$(exec_prefix)" \
"libdir=$(libdir)" \
"libsubdir=$(libsubdir)" \
"tooldir=$(tooldir)"

# Dependencies for "all" are set later in the file.
all: all-multi
# Now that we have built all the objects, we need to copy
# them back to the GCC directory.  Too many things (other
# in-tree libraries, and DejaGNU) know about the layout
# of the build tree, for now.
$(MAKE) install-leaf DESTDIR=$(gcc_objdir) \
  slibdir= libsubdir= MULTIOSDIR=$(MULTIDIR)

.PHONY: all-multi
all-multi:
# If this is the top-level multilib, build all the other
# multilibs.
@: $(MAKE) ; exec $(MULTIDO) $(FLAGS_TO_PASS) multi-do DO=all

.