Re: [PATCH] fixincludes/Makefile for Interix Rev 2

[Paolo Bonzini]

On 06/07/2011 06:37 AM, Douglas B Rupp wrote:

Revised and retested patch attached.

OK to commit?


It should be enough to add AC_USE_SYSTEM_EXTENSIONS to configure.ac 
instead (right after AC_PROG_CC).


Paolo

Re: patch trunk: seek plugin also in a language specific directory when given a short name

[Jonathan Wakely]

On 7 June 2011 06:50, Basile Starynkevitch wrote:
> Also search short plugins also in a front-end
>        specific sub-directory.

That doesn't look like an improvement :)

Re: objc/objc++: switch all testcases to Modern Objective-C runtime API

[Nicola Pero]

> I checked on i686-darwin9 with both m32 and m32/abi=1 the only difference I 
> see is the XPASSes
> for m64 torture/forward-1.m for gnu runtime.

That is very comforting; I have committed the (revised) patch.
Thanks a lot for your help testing and reviewing. :-)

> I will try to test on darwin8 during the week - but time v. limited.

I expect there will be a few issues with darwin8; it's all supposed to work 
there,
but software never works until you test it, and I haven't tested it. ;-)

If you try, please send me the logs of the failures and I'll fix them.

Thanks

Re: [lto] Unify decl and type registration (issue4515186)

[Richard Guenther]

On Mon, 6 Jun 2011, Diego Novillo wrote:

> On Mon, Jun 6, 2011 at 10:27, Diego Novillo  wrote:
> > On Mon, Jun 6, 2011 at 04:50, Richard Guenther  wrote:
> >
> >> I'd have it done in the loop that computes canonical types, at this
> >> place we do not gain the advantage that the decl register functions
> >> get completely fixed up trees.
> >
> > Hm, yes, I had forgotten about the call to rest_of_decl_compilation.
> > Patch coming up.
> 
> You mean this?  Currently under testing.

Yes.

Thanks,
Richard.

> 
> * lto.c (uniquify_nodes): Move code to register decls to
> the loop that computes canonical types.
> 
> diff --git a/gcc/lto/lto.c b/gcc/lto/lto.c
> index 74dfecd..6e49ee7 100644
> --- a/gcc/lto/lto.c
> +++ b/gcc/lto/lto.c
> @@ -651,21 +651,13 @@ uniquify_nodes (struct data_in *data_in, unsigned from)
>/* Go backwards because children streamed for the first time come
>   as part of their parents, and hence are created after them.  */
> 
> -  /* First register all declarations and types in the cache.
> - This makes sure to have the original structure in the type cycles
> - when registering them and computing hashes.  */
> +  /* First register all the types in the cache.  This makes sure to
> + have the original structure in the type cycles when registering
> + them and computing hashes.  */
>for (i = len; i-- > from;)
>  {
>tree t = VEC_index (tree, cache->nodes, i);
> -
> -  if (t == NULL_TREE)
> -   continue;
> -
> -  if (TREE_CODE (t) == VAR_DECL)
> -   lto_register_var_decl_in_symtab (data_in, t);
> -  else if (TREE_CODE (t) == FUNCTION_DECL && !DECL_BUILT_IN (t))
> -   lto_register_function_decl_in_symtab (data_in, t);
> -  else if (TYPE_P (t))
> +  if (t && TYPE_P (t))
> gimple_register_type (t);
>  }
> 
> @@ -788,19 +780,23 @@ uniquify_nodes (struct data_in *data_in, unsigned from)
> }
>  }
> 
> -  /* Finally compute the canonical type of t.  From this point
> - there are no longer any types with TYPE_STRUCTURAL_EQUALITY_P
> - and its type-based alias problems.  This step requires the
> - TYPE_POINTER_TO lists being present, so make sure it is done
> - last.  */
> +  /* Finally compute the canonical type of all TREE_TYPEs and register
> + VAR_DECL and FUNCTION_DECL nodes in the symbol table.
> + From this point there are no longer any types with
> + TYPE_STRUCTURAL_EQUALITY_P and its type-based alias problems.
> + This step requires the TYPE_POINTER_TO lists being present, so
> + make sure it is done last.  */
>for (i = len; i-- > from;)
>  {
>tree t = VEC_index (tree, cache->nodes, i);
> -  if (!t
> - || !TYPE_P (t))
> +  if (t == NULL_TREE)
> continue;
> 
> -  if (!TYPE_CANONICAL (t))
> +  if (TREE_CODE (t) == VAR_DECL)
> +   lto_register_var_decl_in_symtab (data_in, t);
> +  else if (TREE_CODE (t) == FUNCTION_DECL && !DECL_BUILT_IN (t))
> +   lto_register_function_decl_in_symtab (data_in, t);
> +  else if (TYPE_P (t) && !TYPE_CANONICAL (t))
> TYPE_CANONICAL (t) = gimple_register_canonical_type (t);
>  }
>  }
> 
> 

-- 
Richard Guenther 
Novell / SUSE Labs
SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer

[v3] libstdc++/49293

[Paolo Carlini]

Hi,

sanity checked x86_64-linux, committed to mainline.

Paolo.

///
2011-06-07  Paolo Carlini  

PR libstdc++/49293
* testsuite/22_locale/time_get/get_weekday/char/38081-1.cc: Tweak
for glibc 2.14.
* testsuite/22_locale/time_get/get_weekday/char/38081-2.cc: Likewise.

Index: testsuite/22_locale/time_get/get_weekday/char/38081-1.cc
===
--- testsuite/22_locale/time_get/get_weekday/char/38081-1.cc(revision 
174735)
+++ testsuite/22_locale/time_get/get_weekday/char/38081-1.cc(working copy)
@@ -1,6 +1,6 @@
 // { dg-require-namedlocale "ru_RU.ISO-8859-5" }
 
-// Copyright (C) 2010 Free Software Foundation
+// Copyright (C) 2010, 2011 Free Software Foundation
 //
 // This file is part of the GNU ISO C++ Library.  This library is free
 // software; you can redistribute it and/or modify it under the
@@ -49,7 +49,11 @@
   // get_weekday(iter_type, iter_type, ios_base&, 
   // ios_base::iostate&, tm*) const
 
+#if __GLIBC__ > 2 || (__GLIBC__ == 2 && __GLIBC_MINOR__ >= 14)
+  iss.str("\xbf\xdd\x2e");
+#else
   iss.str("\xbf\xdd\xd4");
+#endif
   iterator_type is_it01(iss);
   tm time01;
   memset(&time01, -1, sizeof(tm));
@@ -67,7 +71,11 @@
   VERIFY( time02.tm_wday == 1 );
   VERIFY( errorstate == ios_base::eofbit );
 
+#if __GLIBC__ > 2 || (__GLIBC__ == 2 && __GLIBC_MINOR__ >= 14)
+  iss.str("\xbf\xdd\x2e\xd5\xd4\xd5\xdb\xec\xdd\xd8\xda");
+#else
   iss.str("\xbf\xdd\xd4\xd5\xd4\xd5\xdb\xec\xdd\xd8\xda");
+#endif
   iterator_type is_it03(iss);
   tm time03;
   memset(&time03, -1, sizeof(tm));
Index: testsuite/22_locale/time_get/get_weekday/char/38081-2.cc
===
--- testsuite/22_locale/time_get/get_weekday/char/38081-2.cc(revision 
174735)
+++ testsuite/22_locale/time_get/get_weekday/char/38081-2.cc(working copy)
@@ -2,7 +2,7 @@
 
 // 2010-01-05  Paolo Carlini  
 
-// Copyright (C) 2010 Free Software Foundation
+// Copyright (C) 2010, 2011 Free Software Foundation
 //
 // This file is part of the GNU ISO C++ Library.  This library is free
 // software; you can redistribute it and/or modify it under the
@@ -50,6 +50,15 @@
   // get_weekday(iter_type, iter_type, ios_base&, 
   // ios_base::iostate&, tm*) const
 
+#if __GLIBC__ > 2 || (__GLIBC__ == 2 && __GLIBC_MINOR__ >= 14)
+  const char* awdays[7] = { "\u0412\u0441\u002E",
+   "\u041F\u043D\u002E",
+   "\u0412\u0442\u002E",
+   "\u0421\u0440\u002E",
+   "\u0427\u0442\u002E",
+   "\u041F\u0442\u002E",
+   "\u0421\u0431\u002E" };
+#else
   const char* awdays[7] = { "\u0412\u0441\u043A",
"\u041F\u043D\u0434",
"\u0412\u0442\u0440",
@@ -57,6 +66,7 @@
"\u0427\u0442\u0432",
"\u041F\u0442\u043D",
"\u0421\u0431\u0442" };
+#endif
 
   for (int i = 0; i < 7; ++i)
 {

Re: [Patch, Fortran] (Coarray) Add parse support for LOCK/UNLOCK (part 1 of 2)

[Daniel Kraft]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Tobias,

On 06/06/11 23:40, Tobias Burnus wrote:
> This patch adds incomplete parsing support for the LOCK and UNLOCK
> statement. Missing part 2 is the addition of the LOCK_TYPE of the
> ISO_FORTRAN_ENV.
> 
> Build and tested on x86-64-linux.
> OK for the trunk?

Ok but you could consider the comments below (all not very important,
though, and I'm fine if you check in just as it is).

Thanks for the patch!  Yours,
Daniel

+  fputs ("lock-variable=", dumpfile);
+  if (c->expr1 != NULL)
+   show_expr (c->expr1);

Why do you dump "lock-variable=" in any case, while you only print the
names for the other arguments only if present?

- -  gfc_expr *expr1, *expr2, *expr3;
+  gfc_expr *expr1, *expr2, *expr3, *expr4;

Just a side-remark, but this makes me wonder whether we should at some
point use a union there if we keep adding more and more expressions?  So
that the code can be understood more easily and it is always clear what
something like c->expr3 actually references?

+ m = gfc_match_char (',');
+ if (m == MATCH_YES)
+   continue;
+
+  tmp = NULL;
+ break;

Looks like a white-space / tab mismatch in the tmp = NULL line.

For the same context (lock_unlock_statement function):  We're repeating
the same matching logic thrice for all stat-variables ... maybe I would
be tempted to think about a way out; possibly using a macro.  Although
this may of course also make the code harder to read.  I'm certainly ok
with the code as it is, just a thought.  (I personally don't really like
duplicating code so large, although it is a very simple and clear one.)

- -- 
http://www.pro-vegan.info/
- --
Done:  Arc-Bar-Cav-Kni-Ran-Rog-Sam-Tou-Val-Wiz
To go: Hea-Mon-Pri
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.1 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIVAwUBTe3rE1J+ebqjtTmYAQKkNQ/8C1UGEH3EFtsaLST+vEpU3drdgPM6XQ7v
mxRbb9RXwd6MuzgF1yBJbv+aAFxvTcpUbmlm1etuNDdnJDPEhqedHbUJOU4VjP1k
4IDGRt/YHVQyff8/kmsY9w2+ls5ETOyVpGyxL9B2HcHYWs46733WivpDE2Cvt2yb
b6VTsb03rvpJjRszSIH2XH3H9DB1udAQlAj0F17Lt+kcK07h7EodxbrEbUlQXrdh
Caqby9e5GU0dotVJdrWPax7we6wORGgQ2rI5fufSrELE3OOo3mNrnRWtidPywnbn
mM99XoR9HwHuTEFjfWgzix3js8fpqHJJWE3JECJXx5g5KIDBTN+IxruwWU/8L65O
QCPEBza3h6pb5PgkLe0QnerWDVJ/BrXynHJ9UP645R21k6VamE+/zN5E8xMMNDEq
beEvztTPHR6Ih5UmLk7leNBE0WLAhtJKRP1p529PBznQ5rAvtfXEuzsjNsvIZMsC
AIfE4/un2HHc4oGLHrGQ4YimQEVdg3Px4js1gmI6wcuXj68cpS2R6S1zih+bTcFV
+18gp6XOtGDJhrQyMO34xIGAfSLVxlIBqT/xntvT7uTYhVHtwX1Y5ih9cFZlo7kC
tN13bV1x9PdUaYtUtFTHb4Tf6GhsRMksFFUPvuh0ddzpR/peVmoB+d+U+yu0TZCm
A3U+CWmwv5o=
=sLG0
-END PGP SIGNATURE-

Re: Dump before flag

[Richard Guenther]

On Mon, Jun 6, 2011 at 6:20 PM, Xinliang David Li  wrote:
>>
>> Your patch doesn't really improve this but adds to the confusion.
>>
>> +  /* Override dump TODOs.  */
>> +  if (dump_file && (pass->todo_flags_finish & TODO_dump_func)
>> +      && (dump_flags & TDF_BEFORE))
>> +    {
>> +      pass->todo_flags_finish &= ~TODO_dump_func;
>> +      pass->todo_flags_start |= TODO_dump_func;
>> +    }
>>
>> and certainly writing to pass is not ok.  And the TDF_BEFORE flag
>> looks misplaced as it controls TODOs, not dumping behavior.
>> Yes, it's a mess right now but the above looks like a hack ontop
>> of that mess (maybe because of it, but well ...).
>>
>
> How about removing dumping TODO completely -- this can be done easily
> -- I don't understand why pass wants extra control on the dumping if
> user already asked for dumping -- it is annoying to see empty IR dump
> for a pass when I want to see it.
>
>> At least I would have expected to also get the dump after the
>> pass, not only the one before it with this dump flag.
>>
>> Now, why can't you look at the previous pass output for the
>> before-dump (as I do usually)?
>
> For one thing, you need to either remember what is the previous pass,
> or dump all passes which for large files can take very long time. Even
> with all the dumps, you will need to eyeballing to find the previous
> pass which may or may not have the IR dumped.
>
> How about removing dump TODO?

Yeah, I think this would go in the right direction.  Currently some passes
do not dump function bodies because they presumably do no IL
modification.  But this is certainly the minority (and some passes do not
dump bodies even though they are modifying the IL ...).

So I'd say we should by default dump function bodies.

Note that there are three useful dumping positions (maybe four),
before todo-start, after todo-start, before todo-finish and after todo-finish.
By default we'd want after todo-finish.  When we no longer dump via
a TODO then we could indeed use dump-flags to control this
(maybe -original for the body before todo-start).

What to others think?

Richard.

> Thanks,
>
> David
>
>
>>
>> Richard.
>>
>

Re: [PATCH] Fix -fprofile-use optimization of a noreturn indirect call (PR gcov-profile/49299)

[Richard Guenther]

On Mon, Jun 6, 2011 at 7:58 PM, Jakub Jelinek  wrote:
> Hi!
>
> When an indirect noreturn call has a likely call target, value-prof.c
> ICEs on it, as there is no fallthru edge after the call (nor a join bb).
> Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux,
> ok for trunk/4.6?

Ok.

Thanks,
Richard.

> 2011-06-06  Jakub Jelinek  
>
>        PR gcov-profile/49299
>        * value-prof.c (gimple_ic): Don't assume icall has
>        a fallthru edge.
>
>        * gcc.dg/tree-prof/pr49299-1.c: New test.
>        * gcc.dg/tree-prof/pr49299-2.c: New test.
>
> --- gcc/value-prof.c.jj 2011-05-02 18:39:28.0 +0200
> +++ gcc/value-prof.c    2011-06-06 12:37:30.0 +0200
> @@ -1145,9 +1145,9 @@ gimple_ic (gimple icall_stmt, struct cgr
>  {
>   gimple dcall_stmt, load_stmt, cond_stmt;
>   tree tmp0, tmp1, tmpv, tmp;
> -  basic_block cond_bb, dcall_bb, icall_bb, join_bb;
> +  basic_block cond_bb, dcall_bb, icall_bb, join_bb = NULL;
>   tree optype = build_pointer_type (void_type_node);
> -  edge e_cd, e_ci, e_di, e_dj, e_ij;
> +  edge e_cd, e_ci, e_di, e_dj = NULL, e_ij;
>   gimple_stmt_iterator gsi;
>   int lp_nr;
>
> @@ -1194,12 +1194,19 @@ gimple_ic (gimple icall_stmt, struct cgr
>   else
>     {
>       e_ij = find_fallthru_edge (icall_bb->succs);
> -      e_ij->probability = REG_BR_PROB_BASE;
> -      e_ij->count = all - count;
> -      e_ij = single_pred_edge (split_edge (e_ij));
> +      /* The indirect call might be noreturn.  */
> +      if (e_ij != NULL)
> +       {
> +         e_ij->probability = REG_BR_PROB_BASE;
> +         e_ij->count = all - count;
> +         e_ij = single_pred_edge (split_edge (e_ij));
> +       }
> +    }
> +  if (e_ij != NULL)
> +    {
> +      join_bb = e_ij->dest;
> +      join_bb->count = all;
>     }
> -  join_bb = e_ij->dest;
> -  join_bb->count = all;
>
>   e_cd->flags = (e_cd->flags & ~EDGE_FALLTHRU) | EDGE_TRUE_VALUE;
>   e_cd->probability = prob;
> @@ -1211,12 +1218,15 @@ gimple_ic (gimple icall_stmt, struct cgr
>
>   remove_edge (e_di);
>
> -  e_dj = make_edge (dcall_bb, join_bb, EDGE_FALLTHRU);
> -  e_dj->probability = REG_BR_PROB_BASE;
> -  e_dj->count = count;
> +  if (e_ij != NULL)
> +    {
> +      e_dj = make_edge (dcall_bb, join_bb, EDGE_FALLTHRU);
> +      e_dj->probability = REG_BR_PROB_BASE;
> +      e_dj->count = count;
>
> -  e_ij->probability = REG_BR_PROB_BASE;
> -  e_ij->count = all - count;
> +      e_ij->probability = REG_BR_PROB_BASE;
> +      e_ij->count = all - count;
> +    }
>
>   /* Insert PHI node for the call result if necessary.  */
>   if (gimple_call_lhs (icall_stmt)
> --- gcc/testsuite/gcc.dg/tree-prof/pr49299-1.c.jj       2011-06-06 
> 11:34:58.0 +0200
> +++ gcc/testsuite/gcc.dg/tree-prof/pr49299-1.c  2011-06-06 11:34:51.0 
> +0200
> @@ -0,0 +1,34 @@
> +/* { dg-options "-O2" } */
> +
> +__attribute__((noreturn)) void (*fn) (void);
> +
> +volatile int v;
> +
> +__attribute__((noreturn)) void
> +fn0 (void)
> +{
> +  __builtin_exit (0);
> +}
> +
> +__attribute__((noreturn)) void
> +fn1 (void)
> +{
> +  __builtin_exit (1);
> +}
> +
> +__attribute__((noinline, noclone)) void
> +setfn (__attribute__((noreturn)) void (*x) (void))
> +{
> +  fn = x;
> +}
> +
> +int
> +main ()
> +{
> +  int i;
> +  if (v < 1)
> +    setfn (fn0);
> +  else
> +    setfn (fn1);
> +  fn ();
> +}
> --- gcc/testsuite/gcc.dg/tree-prof/pr49299-2.c.jj       2011-06-06 
> 12:46:25.0 +0200
> +++ gcc/testsuite/gcc.dg/tree-prof/pr49299-2.c  2011-06-06 12:39:15.0 
> +0200
> @@ -0,0 +1,34 @@
> +/* { dg-options "-O2" } */
> +
> +void (*fn) (void);
> +
> +volatile int v;
> +
> +__attribute__((noreturn)) void
> +fn0 (void)
> +{
> +  __builtin_exit (0);
> +}
> +
> +void
> +fn1 (void)
> +{
> +}
> +
> +__attribute__((noinline, noclone)) void
> +setfn (void (*x) (void))
> +{
> +  fn = x;
> +}
> +
> +int
> +main ()
> +{
> +  int i;
> +  if (v < 1)
> +    setfn (fn0);
> +  else
> +    setfn (fn1);
> +  fn ();
> +  return 0;
> +}
>
>        Jakub
>

Re: [PATCH: ARM] PR 45335 Use ldrd and strd to access two consecutive words

[Nick Clifton]

Hi Carrot,


ChangeLog:
2011-03-29  Wei Guozhi  

PR target/45335
* gcc/config/arm/ldmstm.md (ldm2_ia, stm2_ia, ldm2_ib, stm2_ib, ldm2_da,
stm2_da, ldm2_db, stm2_db): Add condition !arm_arch7 to these insns.
(ldrd, ldrd_reg1, ldrd_reg2 and peephole2): New insn patterns and
related peephole2.
(strd, strd_reg1, strd_reg2 and peephole2): New insn patterns and
related peephole2.
* gcc/config/arm/arm-protos.h (arm_check_ldrd_operands): New prototype.
(arm_legitimate_ldrd_p): New prototype.
(arm_output_ldrd): New prototype.
* gcc/config/arm/arm.c (arm_check_ldrd_operands): New function.
(arm_legitimate_ldrd_p): New function.
(arm_output_ldrd): New function.


2011-03-29  Wei Guozhi  

PR target/45335
* gcc.target/arm/pr45335.c: New test.
* gcc.target/arm/pr45335-2.c: New test.
* gcc.target/arm/pr45335-3.c: New test.
* gcc.target/arm/pr40457-1.c: Add another possible output "ldrd".
* gcc.target/arm/pr40457-2.c: Changed to store 3 words.
* gcc.target/arm/pr40457-3.c: Changed to store 3 words.


Approved - please apply.

Cheers
  Nick

Re: [Design notes, RFC] Address-lowering prototype design (PR46556)

[Richard Guenther]

On Mon, Jun 6, 2011 at 8:07 PM, William J. Schmidt
 wrote:
> It's been some time since I last posted about the address lowering issue from
> PR46556 (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46556).  I've had a basic
> prototype in place for some time, but I ran into some issues that initially
> caused performance regressions; I've had to jump through several hoops to
> resolve these.  At this time, I'm now seeing decent performance improvements
> from address lowering for PowerPC (about 2% overall on SPEC cpu2000).  A
> couple of minor degradations still occur that I am looking into.
>
> I thought this would be a good time to put out another RFC.  However, the code
> has grown over time, and I doubt whether all you busy people are particularly
> interested in reviewing a 2700-line prototype patch in detail.  Instead, I've
> written up some notes on the design, some of the challenges I ran into, and my
> current approach to handling those.
>
> I'd like to first get comments from interested parties on the prototype
> design, and get consensus on whether this is the appropriate overall
> approach.  If so, the next step would be to decide how to go about reviewing
> the code.  Since smaller patches are much easier to review, one possibility
> would be for me to gate the new pass on a flag that's off by default, and
> submit patches incrementally for review.  I.e., start with the bare-bones
> algorithm, and gradually add in the complexities as folks have time to review
> the code.  I'm quite new to the community, so any advice on how to handle
> this would be very welcome.
>
> In any case, here are my notes.  Thanks in advance for your views!
>
> Bill
>
>
> Basic algorithm
> ===
> A new pass is added late in the gimple phases, currently between
> pass_phi_only_cprop and pass_cd_dce.  I chose this placement because the new
> pass can generate a fair amount of dead code.
>
> Address lowering walks the CFG in predominator order.  Common subexpression
> elimination is performed on operations that could participate in addressing
> expressions.  These operations may have been made available in the current
> block, or in any dominating block.
>
> Any statement that may contain a memory access (excluding calls) is considered
> for address lowering.  The memory access is expanded into an affine
> combination of trees by looking back at feeding statements, using logic
> originally developed for IVopts.  The affine combination is subjected to a
> number of tests to determine whether it's legal and profitable to lower the
> addressing expression into a TARGET_MEM_REF (or MEM_REF, when addressing is
> sufficiently simple).  If so, the conversion to a TMR is performed, again
> using logic originally developed for IVopts.
>
> The resulting memory reference is again subjected to a number of conditions
> testing for legality and profitability.  If these conditions are all met, the
> reference data is copied from the original expression to the TMR, and the TMR
> replaces the original expression in the gimple statement.
>
> The conversion of a memory access into a TMR generally creates a number of new
> gimple statements preceding the statement under analysis.  CSE is performed on
> the fly for these new statements as well, using the available expressions data
> discussed earlier.  This produces naturally shared addressability for members
> of the same structure, for example.
>
> Inhibitors
> ==
> As mentioned, a number of conditions are checked before replacing a memory
> access with a TMR.  Conditions that inhibit replacement include the following.
>
>  * There is not yet any handling for bitfields.
>
>  * An expression containing a direct field reference from a small nonvolatile
>   structure is left alone.  It is assumed that these values will be
>   register-assigned, so exposing their addresses is counterproductive.
>
>  * I have seen odd cases in C++ code such as
>
>     lhs = MEM[(struct foo *) 0B].bar;
>
>   This results in an affine combination of trees with no elements, so an
>   explicit check for such empty combinations is required.
>
>  * If the affine combination of trees introduces an ADDR_EXPR for any decl
>   that is not already marked as addressable, we refuse to make the
>   replacement.  Taking the address of something for the first time defeats
>   downstream optimizations that would otherwise be possible.
>
>  * create_mem_ref can occasionally produce a TMR or MEM_REF with a base
>   expression of constant zero.  One way this can happen is with questionable
>   coding practices, such as treating an integer paramter as a pointer.  It's
>   an open question whether create_mem_ref should ever produce such a tree.
>   In any case, the base expression of zero again confuses the may-aliasing
>   machinery, so I refuse the replacement in this case.
>
>  * If the original expression will be recognized as a "hidden global store" in
>   tree-ssa-sink.c:is_hidden_global_store, but the replaceme

Re: [PATCH] gimple_val_nonnegative_real_p (PR46728 patch 7 of 7)

[Richard Guenther]

On Mon, Jun 6, 2011 at 8:59 PM, William J. Schmidt
 wrote:
> Hi Richard,
>
> Here's the reworked patch addressing the noted concerns.  Regtested for
> powerpc-linux.  OK for trunk?

Ok with ...

> Thanks,
> Bill
>
>
> 2011-06-06  Bill Schmidt  
>
>        PR tree-optimization/46728
>        * tree-ssa-math-opts.c (gimple_expand_builtin_pow): Change FIXME
>        to use gimple_val_nonnegative_real_p.
>        * gimple-fold.c (gimple_val_nonnegative_real_p): New function.
>        * gimple.h (gimple_val_nonnegative_real_p): New declaration.
>
>
> Index: gcc/tree-ssa-math-opts.c
> ===
> --- gcc/tree-ssa-math-opts.c    (revision 174708)
> +++ gcc/tree-ssa-math-opts.c    (working copy)
> @@ -1172,13 +1172,7 @@ gimple_expand_builtin_pow (gimple_stmt_iterator *g
>
>   if (flag_unsafe_math_optimizations
>       && cbrtfn
> -      /* FIXME: The following line was originally
> -        && (tree_expr_nonnegative_p (arg0) || !HONOR_NANS (mode)),
> -        but since arg0 is a gimple value, the first predicate
> -        will always return false.  It needs to be replaced with a
> -        call to a similar gimple_val_nonnegative_p function to be
> -         added in gimple-fold.c.  */
> -      && !HONOR_NANS (mode)
> +      && (gimple_val_nonnegative_real_p (arg0) || !HONOR_NANS (mode))
>       && REAL_VALUES_EQUAL (c, dconst1_3))
>     return build_and_insert_call (gsi, loc, &target, cbrtfn, arg0);
>
> @@ -1190,13 +1184,7 @@ gimple_expand_builtin_pow (gimple_stmt_iterator *g
>   if (flag_unsafe_math_optimizations
>       && sqrtfn
>       && cbrtfn
> -      /* FIXME: The following line was originally
> -        && (tree_expr_nonnegative_p (arg0) || !HONOR_NANS (mode)),
> -        but since arg0 is a gimple value, the first predicate
> -        will always return false.  It needs to be replaced with a
> -        call to a similar gimple_val_nonnegative_p function to be
> -         added in gimple-fold.c.  */
> -      && !HONOR_NANS (mode)
> +      && (gimple_val_nonnegative_real_p (arg0) || !HONOR_NANS (mode))
>       && optimize_function_for_speed_p (cfun)
>       && hw_sqrt_exists
>       && REAL_VALUES_EQUAL (c, dconst1_6))
> @@ -1270,13 +1258,7 @@ gimple_expand_builtin_pow (gimple_stmt_iterator *g
>
>   if (flag_unsafe_math_optimizations
>       && cbrtfn
> -      /* FIXME: The following line was originally
> -        && (tree_expr_nonnegative_p (arg0) || !HONOR_NANS (mode)),
> -        but since arg0 is a gimple value, the first predicate
> -        will always return false.  It needs to be replaced with a
> -        call to a similar gimple_val_nonnegative_p function to be
> -         added in gimple-fold.c.  */
> -      && !HONOR_NANS (mode)
> +      && (gimple_val_nonnegative_real_p (arg0) || !HONOR_NANS (mode))
>       && real_identical (&c2, &c)
>       && optimize_function_for_speed_p (cfun)
>       && powi_cost (n / 3) <= POWI_MAX_MULTS)
> Index: gcc/gimple-fold.c
> ===
> --- gcc/gimple-fold.c   (revision 174708)
> +++ gcc/gimple-fold.c   (working copy)
> @@ -3433,3 +3433,134 @@ fold_const_aggregate_ref (tree t)
>  {
>   return fold_const_aggregate_ref_1 (t, NULL);
>  }
> +
> +/* Return true iff VAL is a gimple expression that is known to be
> +   non-negative.  Restricted to floating-point inputs.  */
> +
> +bool
> +gimple_val_nonnegative_real_p (tree val)
> +{
> +  gimple def_stmt;
> +
> +  gcc_assert (val && (TREE_CODE (TREE_TYPE (val)) == REAL_TYPE));

SCALAR_FLOAT_TYPE_P (TREE_TYPE (val))

Thanks,
Richard.

> +  /* Use existing logic for non-gimple trees.  */
> +  if (tree_expr_nonnegative_p (val))
> +    return true;
> +
> +  if (TREE_CODE (val) != SSA_NAME)
> +    return false;
> +
> +  /* Currently we look only at the immediately defining statement
> +     to make this determination, since recursion on defining
> +     statements of operands can lead to quadratic behavior in the
> +     worst case.  This is expected to catch almost all occurrences
> +     in practice.  It would be possible to implement limited-depth
> +     recursion if important cases are lost.  Alternatively, passes
> +     that need this information (such as the pow/powi lowering code
> +     in the cse_sincos pass) could be revised to provide it through
> +     dataflow propagation.  */
> +
> +  def_stmt = SSA_NAME_DEF_STMT (val);
> +
> +  if (is_gimple_assign (def_stmt))
> +    {
> +      tree op0, op1;
> +
> +      /* See fold-const.c:tree_expr_nonnegative_p for additional
> +        cases that could be handled with recursion.  */
> +
> +      switch (gimple_assign_rhs_code (def_stmt))
> +       {
> +       case ABS_EXPR:
> +         /* Always true for floating-point operands.  */
> +         return true;
> +
> +       case MULT_EXPR:
> +         /* True if the two operands are identical (since we are
> +            restricted to floating-point inputs).  */
> +         op0 = gimple_assign_rhs1 (def_s

Re: -fdump-passes -fenable-xxx=func_name_list

[Richard Guenther]

On Mon, Jun 6, 2011 at 6:00 PM, Xinliang David Li  wrote:
> On Mon, Jun 6, 2011 at 4:38 AM, Richard Guenther
>  wrote:
>> On Thu, Jun 2, 2011 at 9:12 AM, Xinliang David Li  wrote:
>>> This is the version of the patch that walks through pass lists.
>>>
>>> Ok with this one?
>>
>> +/* Dump all optimization passes.  */
>> +
>> +void
>> +dump_passes (void)
>> +{
>> +  struct cgraph_node *n, *node = NULL;
>> +  tree save_fndecl = current_function_decl;
>> +
>> +  fprintf (stderr, "MAX_UID = %d\n", cgraph_max_uid);
>>
>> this isn't accurate info - cloning can cause more cgraph nodes to
>> appear (it also looks completely unrelated to dump_passes ...).
>> Please drop it.
>
> Ok.
>
>
>>
>> +  create_pass_tab();
>> +  gcc_assert (pass_tab);
>>
>> you have quite many asserts of this kind - we don't want them when
>> the previous stmt as in this case indicates everything is ok.
>
> ok.
>
>>
>> +  push_cfun (DECL_STRUCT_FUNCTION (node->decl));
>>
>> this has side-effects, I'm not sure we want this here.  Why do you
>> need it?  Probably because of
>>
>> +  is_really_on = override_gate_status (pass, current_function_decl, is_on);
>>
>> ?  But that is dependent on the function given which should have no
>> effect (unless it is overridden globally in which case override_gate_status
>> and friends should deal with a NULL cfun).
>
> As we discussed, currently some pass gate functions depend on per node
> information -- those checks need to be pushed into execute functions.
> I would like to clean those up later -- at which time, the push/pop
> can be removed.

I'd like to do it the other way around, first clean up the gate functions then
drop in this patch without the cfun push/pop.  The revised patch looks ok
to me with the cfun push/pop removed.

Thanks,
Richard.

>>
>> I don't understand why you need another table mapping pass to name
>> when pass->name is available and the info is trivially re-constructible.
>
> This is needed as the pass->name is not the canonicalized name (i.e.,
> not with number suffix etc), so the extra mapping from id to
> normalized name is needed.
>
> Thanks,
>
> David
>
>>
>> Thanks,
>> Richard.
>>
>>> David
>>>
>>> On Wed, Jun 1, 2011 at 12:45 PM, Xinliang David Li  
>>> wrote:
 On Wed, Jun 1, 2011 at 12:29 PM, Richard Guenther
  wrote:
> On Wed, Jun 1, 2011 at 6:16 PM, Xinliang David Li  
> wrote:
>> On Wed, Jun 1, 2011 at 1:51 AM, Richard Guenther
>>  wrote:
>>> On Wed, Jun 1, 2011 at 1:34 AM, Xinliang David Li  
>>> wrote:
 The following patch implements the a new option that dumps gcc PASS
 configuration. The sample output is attached.  There is one
 limitation: some placeholder passes that are named with '*xxx' are
 note registered thus they are not listed. They are not important as
 they can not be turned on/off anyway.

 The patch also enhanced -fenable-xxx and -fdisable-xx to allow a list
 of function assembler names to be specified.

 Ok for trunk?
>>>
>>> Please split the patch.
>>>
>>> I'm not too happy how you dump the pass configuration.  Why not simply,
>>> at a _single_ place, walk the pass tree?  Instead of doing pieces of it
>>> at pass execution time when it's not already dumped - that really looks
>>> gross.
>>
>> Yes, that was the original plan -- but it has problems
>> 1) the dumper needs to know the root pass lists -- which can change
>> frequently -- it can be a long term maintanance burden;
>> 2) the centralized dumper needs to be done after option processing
>> 3) not sure if gate functions have any side effects or have dependencies 
>> on cfun
>>
>> The proposed solutions IMHO is not that intrusive -- just three hooks
>> to do the dumping and tracking indentation.
>
> Well, if you have a CU that is empty or optimized to nothing at some point
> you will not get a complete pass list.  I suppose optimize attributes 
> might
> also confuse output.  Your solution might not be that intrusive
> but it is still ugly.  I don't see 1) as an issue, for 2) you can just 
> call the
> dumping from toplev_main before calling do_compile (), 3) gate functions
> shouldn't have side-effects, but as they could gate on optimize_for_speed 
> ()
> your option summary output will be bogus anyway.
>
> So - what is the output intended for if it isn't reliable?

 This needs to be cleaned up at some point -- the gate function should
 behave the same for all functions and per-function decisions need to
 be pushed down to the executor body.  I will try to rework the patch
 as you suggested to see if there are problems.

 David


>
> Richard.
>
>>>
>>> The documentation should also link this option to the -fenable/disable
>>> options as obviously the pass names in that dump are those to be
>>> used for those

Re: -fdump-passes -fenable-xxx=func_name_list

[Richard Guenther]

On Mon, Jun 6, 2011 at 9:20 PM, Xinliang David Li  wrote:
> Please take a look at the revised one.

Ok.

Thanks,
Richard.

> Thanks,
>
> David
>
> On Mon, Jun 6, 2011 at 4:22 AM, Richard Guenther
>  wrote:
>> On Wed, Jun 1, 2011 at 7:24 PM, Xinliang David Li  wrote:
>>> The attached is the split #1 patch that enhances -fenable/disable.
>>>
>>> Ok after testing?
>>
>> I expect the testcases will be quite fragile, so while I appreciate
>> test coverage for new options I think we should go without those
>> that involve any kind of UID.  Those which use assembler names
>> also will fail randomly dependent on how targets mangle their
>> functions - so I think we have to drop all testcases.
>>
>> Also
>>
>> +/* A helper function to determine if an identifier is valid to
>> +   be an assembler name (better to use target specific hook).  */
>> +
>> +static bool
>> +is_valid_assembler_name (const char *str)
>> +{
>> +  const char *p = str;
>> +  char c;
>> +
>> +  c = *p;
>> +  if (!((c >= 'a' && c <= 'z')
>> +        || (c >= 'A' && c <= 'Z')
>> +        || *p == '_'))
>> +    return false;
>> +
>> +  p++;
>> +  while ((c = *p))
>> +   {
>> +     if (!((c >= 'a' && c <= 'z')
>> +           || (c >= 'A' && c <= 'Z')
>> +           || (c >= '0' && c <= '9')
>> +           || *p == '_'))
>> +       return false;
>> +     p++;
>> +   }
>> +
>> +  return true;
>> +}
>>
>> why all that complicated checks?  Why not just check for p[0]
>> in [^0-9] and re-structure the range parsing to switch between
>> UIDs and assembler-names that way?
>>
>> Thanks,
>> Richard.
>>
>>> Thanks,
>>> David
>>>
>>> On Wed, Jun 1, 2011 at 9:16 AM, Xinliang David Li  
>>> wrote:
 On Wed, Jun 1, 2011 at 1:51 AM, Richard Guenther
  wrote:
> On Wed, Jun 1, 2011 at 1:34 AM, Xinliang David Li  
> wrote:
>> The following patch implements the a new option that dumps gcc PASS
>> configuration. The sample output is attached.  There is one
>> limitation: some placeholder passes that are named with '*xxx' are
>> note registered thus they are not listed. They are not important as
>> they can not be turned on/off anyway.
>>
>> The patch also enhanced -fenable-xxx and -fdisable-xx to allow a list
>> of function assembler names to be specified.
>>
>> Ok for trunk?
>
> Please split the patch.
>
> I'm not too happy how you dump the pass configuration.  Why not simply,
> at a _single_ place, walk the pass tree?  Instead of doing pieces of it
> at pass execution time when it's not already dumped - that really looks
> gross.

 Yes, that was the original plan -- but it has problems
 1) the dumper needs to know the root pass lists -- which can change
 frequently -- it can be a long term maintanance burden;
 2) the centralized dumper needs to be done after option processing
 3) not sure if gate functions have any side effects or have dependencies 
 on cfun

 The proposed solutions IMHO is not that intrusive -- just three hooks
 to do the dumping and tracking indentation.

>
> The documentation should also link this option to the -fenable/disable
> options as obviously the pass names in that dump are those to be
> used for those flags (and not readily available anywhere else).

 Ok.

>
> I also think that it would be way more useful to note in the individual
> dump files the functions (at the place they would usually appear) that
> have the pass explicitly enabled/disabled.

 Ok -- for ipa passes or tree/rtl passes where all functions are
 explicitly disabled.

 Thanks,

 David

>
> Richard.
>
>> Thanks,
>>
>> David
>>
>

>>>
>>
>

Re: RFA (fold): PATCH for c++/49290 (folding *(T*)(ar+10))

[Richard Guenther]

On Tue, Jun 7, 2011 at 7:39 AM, Jason Merrill  wrote:
> In the testcase, fold_indirect_ref_1 won't fold *(T*)(s1+10) to an ARRAY_REF
> because T != unsigned.  Even if it were just a typedef to unsigned, that
> isn't close enough, but in this case it's a typedef to const unsigned.
>
> I'm not sure what the type coherence rules are for ARRAY_REF.  Is it really
> necessary that the type of the ARRAY_REF match exactly the element type of
> the array?

I _think_ that you can unconditionally change the code to do

  TYPE_MAIN_VARIANT (t1) == TYPE_MAIN_VARIANT (t2)
  && TYPE_QUALS (t1) == TYPE_QUALS (t2)

now, I'm not sure if for the testcase T and unsigned differ in qualifiers.
Do they?

> In any case, constexpr expansion can be more flexible about type coherence
> because it is just trying to get a constant value; if that doesn't work out,
> we throw it away and fall back on the original expression.  We already
> handle some cases in cxx_eval_indirect_ref that aren't appropriate for
> fold_indirect_ref_1, but this testcase demonstrates that we also want to
> adjust the cases that are handled by that function.
>
> So my options would seem to be either duplicating the whole of
> fold_indirect_ref_1, which tempts undesirable divergence, or adding a flag
> to that function to enable the more permissive type checking that the
> constexpr code wants.
>
> Does this seem like a reasonable thing to do?

So, I'd rather go the above way if it works for this case.

Thanks,
Richard.

>

Re: [4.6 PATCH] Workaround for stack slot sharing problems with unrolling (PR fortran/49103)

[Richard Guenther]

On Tue, Jun 7, 2011 at 8:31 AM, Jakub Jelinek  wrote:
> Hi!
>
> While for the trunk I hope Michael will finalize a much better fix,
> this patch provides a quick workaround for 4.6 branch.
>
> In particular, I'd like to avoid reverting the
> http://gcc.gnu.org/ml/gcc-patches/2011-01/msg01442.html
> patch, because if GIMPLE passes don't do any significant code motion,
> sharing the stack slots e.g. for Fortran I/O parameter block helps quite a
> bit.  So, what this patch attempts to do is (only for the cases which
> changed by the above mentioned patch) make the stack slot sharing
> conditional on no significant code motion (loop {,complete} unrolling and 
> other
> kind of bb duplication).
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for 4.6 branch?
> Or is it way too ugly and should I rather revert there my patch?

Ugh ...

> 2011-06-07  Jakub Jelinek  
>
>        PR fortran/49103
>        * tree.h (DECL_NONSHAREABLE): Define.
>        (struct tree_decl_common): Change decl_common_unused to
>        decl_nonshareable_flag.
>        * cfgexpand.c (expand_used_vars_for_block, clear_tree_used):
>        Ignore vars with DECL_NONSHAREABLE bit set.
>        * tree-cfg.c (gimple_duplicate_bb): Set DECL_NONSHAREABLE
>        on stores to automatic aggregate vars.
>
>        * gfortran.dg/pr49103.f90: New test.
>
> --- gcc/tree.h.jj       2011-03-14 14:12:15.0 +0100
> +++ gcc/tree.h  2011-05-31 14:05:34.0 +0200
> @@ -1330,6 +1330,10 @@ extern void omp_clause_range_check_faile
>  #define DECL_READ_P(NODE) \
>   (TREE_CHECK2 (NODE, VAR_DECL, PARM_DECL)->decl_common.decl_read_flag)
>
> +#define DECL_NONSHAREABLE(NODE) \
> +  (TREE_CHECK2 (NODE, VAR_DECL, \
> +               RESULT_DECL)->decl_common.decl_nonshareable_flag)
> +
>  /* In a CALL_EXPR, means that the call is the jump from a thunk to the
>    thunked-to function.  */
>  #define CALL_FROM_THUNK_P(NODE) (CALL_EXPR_CHECK (NODE)->base.protected_flag)
> @@ -2787,8 +2791,9 @@ struct GTY(()) tree_decl_common {
>      being set.  */
>   unsigned decl_read_flag : 1;
>
> -  /* Padding so that 'off_align' can be on a 32-bit boundary.  */
> -  unsigned decl_common_unused : 1;
> +  /* In VAR_DECL or RESULT_DECL set when significant code movement precludes
> +     attempting to share the stack slot with some other variable.  */
> +  unsigned decl_nonshareable_flag : 1;
>
>   /* DECL_OFFSET_ALIGN, used only for FIELD_DECLs.  */
>   unsigned int off_align : 8;
> --- gcc/cfgexpand.c.jj  2011-05-04 10:46:52.0 +0200
> +++ gcc/cfgexpand.c     2011-05-31 14:08:36.0 +0200
> @@ -1134,7 +1134,9 @@ expand_used_vars_for_block (tree block,
>
>   /* Expand all variables at this level.  */
>   for (t = BLOCK_VARS (block); t ; t = DECL_CHAIN (t))
> -    if (TREE_USED (t))
> +    if (TREE_USED (t)
> +        && ((TREE_CODE (t) != VAR_DECL && TREE_CODE (t) != RESULT_DECL)
> +           || !DECL_NONSHAREABLE (t)))
>       expand_one_var (t, toplevel, true);
>
>   this_sv_num = stack_vars_num;
> @@ -1167,6 +1169,8 @@ clear_tree_used (tree block)
>
>   for (t = BLOCK_VARS (block); t ; t = DECL_CHAIN (t))
>     /* if (!TREE_STATIC (t) && !DECL_EXTERNAL (t)) */
> +    if ((TREE_CODE (t) != VAR_DECL && TREE_CODE (t) != RESULT_DECL)
> +       || !DECL_NONSHAREABLE (t))
>       TREE_USED (t) = 0;
>
>   for (t = BLOCK_SUBBLOCKS (block); t ; t = BLOCK_CHAIN (t))
> --- gcc/tree-cfg.c.jj   2011-03-14 14:12:15.0 +0100
> +++ gcc/tree-cfg.c      2011-05-31 15:22:14.0 +0200
> @@ -5117,6 +5117,7 @@ gimple_duplicate_bb (basic_block bb)
>     {
>       def_operand_p def_p;
>       ssa_op_iter op_iter;
> +      tree lhs;
>
>       stmt = gsi_stmt (gsi);
>       if (gimple_code (stmt) == GIMPLE_LABEL)
> @@ -5130,6 +5131,29 @@ gimple_duplicate_bb (basic_block bb)
>       maybe_duplicate_eh_stmt (copy, stmt);
>       gimple_duplicate_stmt_histograms (cfun, copy, cfun, stmt);
>
> +      /* When copying around a stmt writing into a local non-user
> +        aggregate, make sure it won't share stack slot with other
> +        vars.  */
> +      lhs = gimple_get_lhs (stmt);
> +      if (lhs
> +         && (handled_component_p (lhs)
> +             || TREE_CODE (lhs) == MEM_REF
> +             || TREE_CODE (lhs) == TARGET_MEM_REF
> +             || TREE_CODE (lhs) == VAR_DECL
> +             || TREE_CODE (lhs) == RESULT_DECL))
> +       {
> +         tree base = get_base_address (lhs);

Probably easier and more complete to do

if (lhs && TREE_CODE (lhs) != SSA_NAME)
  {
 tree base = get_base_address (lhs);


I don't like the patch too much, but it looks reasonable.  At least reverting
your patch doesn't really fix anything.

Any opinions from others?

Thanks,
Richard.

> +         if (base
> +             && (TREE_CODE (base) == VAR_DECL
> +                 || TREE_CODE (base) == RESULT_DECL)
> +             && DECL_IGNORED_P (base)
> +             && !TREE_STATIC (base)
> +             && !DECL_EXTERNAL (base

Re: RFA (fold): PATCH for c++/49290 (folding *(T*)(ar+10))

[Jakub Jelinek]

On Tue, Jun 07, 2011 at 12:19:59PM +0200, Richard Guenther wrote:
> On Tue, Jun 7, 2011 at 7:39 AM, Jason Merrill  wrote:
> > In the testcase, fold_indirect_ref_1 won't fold *(T*)(s1+10) to an ARRAY_REF
> > because T != unsigned.  Even if it were just a typedef to unsigned, that
> > isn't close enough, but in this case it's a typedef to const unsigned.
> >
> > I'm not sure what the type coherence rules are for ARRAY_REF.  Is it really
> > necessary that the type of the ARRAY_REF match exactly the element type of
> > the array?
> 
> I _think_ that you can unconditionally change the code to do
> 
>   TYPE_MAIN_VARIANT (t1) == TYPE_MAIN_VARIANT (t2)
>   && TYPE_QUALS (t1) == TYPE_QUALS (t2)
> 
> now, I'm not sure if for the testcase T and unsigned differ in qualifiers.

I guess folding into array_ref that way is fine, but you should in the end
fold_convert_loc it to the expected type, while the middle-end has the
notion of useless type conversions, fold-const.c is also used by FEs and
I think it is expected to have the types exactly matching.
So (T)s1[10] instead of s1[10] in this case.

Jakub

Re: [vta, graphite?] propagate degenerate phi nodes into debug stmts

[Alexandre Oliva]

On Jun  6, 2011, Richard Guenther  wrote:

>> You meant 4.6 stage1, but I missed it.  How's it for 4.7 stage1?
>> Regstrapped on x86_64-linux-gnu and i686-linux-gnu.

> Isn't exactly ICEing for num_ssa_operands/delink_stmt_imm_use.

Uhh.  Looks like I didn't update the patch per your comments before
putting it aside for stage1, after all.  Sorry.

> So, the op_iter_init change is ok, the other two not - they should
> either ICE or work for PHIs (by using FOR_EACH_PHI_OR_STMT_USE
> in them).

The latter is legitimately called for GIMPLE_PHI, so I changed it to use
FOR_EACH_PHI_OR_STMT_USE.  The former was never called for GIMPLE_PHIs,
so I put in an assert there.

Regstrapped on x86_64-linux-gnu and i686-linux-gnu.  Ok?

for  gcc/ChangeLog
from  Alexandre Oliva  

	* tree-flow-inline.h (op_iter_init): Reject GIMPLE_PHI stmts.
	(num_ssa_operands): Likewise.
	(op_iter_init_phiuse): Forward-declare.
	(delink_stmt_imm_use): Iterate with FOR_EACH_PHI_OR_STMT_USE.

Index: gcc/tree-flow-inline.h
===
--- gcc/tree-flow-inline.h.orig	2011-06-03 11:56:24.619482744 -0300
+++ gcc/tree-flow-inline.h	2011-06-07 04:15:18.344729725 -0300
@@ -737,9 +737,11 @@ clear_and_done_ssa_iter (ssa_op_iter *pt
 static inline void
 op_iter_init (ssa_op_iter *ptr, gimple stmt, int flags)
 {
-  /* We do not support iterating over virtual defs or uses without
+  /* PHI nodes require a different iterator initialization path.  We
+ do not support iterating over virtual defs or uses without
  iterating over defs or uses at the same time.  */
-  gcc_checking_assert ((!(flags & SSA_OP_VDEF) || (flags & SSA_OP_DEF))
+  gcc_checking_assert (gimple_code (stmt) != GIMPLE_PHI
+		   && (!(flags & SSA_OP_VDEF) || (flags & SSA_OP_DEF))
 		   && (!(flags & SSA_OP_VUSE) || (flags & SSA_OP_USE)));
   ptr->defs = (flags & (SSA_OP_DEF|SSA_OP_VDEF)) ? gimple_def_ops (stmt) : NULL;
   if (!(flags & SSA_OP_VDEF)
@@ -868,11 +870,14 @@ num_ssa_operands (gimple stmt, int flags
   tree t;
   int num = 0;
 
+  gcc_checking_assert (gimple_code (stmt) != GIMPLE_PHI);
   FOR_EACH_SSA_TREE_OPERAND (t, stmt, iter, flags)
 num++;
   return num;
 }
 
+static inline use_operand_p
+op_iter_init_phiuse (ssa_op_iter *ptr, gimple phi, int flags);
 
 /* Delink all immediate_use information for STMT.  */
 static inline void
@@ -882,7 +887,7 @@ delink_stmt_imm_use (gimple stmt)
use_operand_p use_p;
 
if (ssa_operands_active ())
- FOR_EACH_SSA_USE_OPERAND (use_p, stmt, iter, SSA_OP_ALL_USES)
+ FOR_EACH_PHI_OR_STMT_USE (use_p, stmt, iter, SSA_OP_ALL_USES)
delink_imm_use (use_p);
 }
 


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

Re: [PATCH, ARM] PR47855 Compute attr length for thumb2 insns, 3/3 (issue4475042)

[Nick Clifton]

Hi Carrot,


2011-05-06  Guozhi Wei  

PR target/47855
* config/arm/thumb2.md (thumb2_movsi_insn): Add length addtribute.
(thumb2_shiftsi3_short and peephole2): Remove 3-register case.
(thumb2_cbz): Refine length computation.
(thumb2_cbnz): Likewise.


Not approved - yet.

The problem is the change to thumb2_movsi_insn.  You are still adding in 
the support for the STM instruction despite the fact that Richard is 
still researching how this will work with unaligned addresses.  Given 
the fact that this change is not mentioned in the ChangeLog entry, I 
will assume that you intended to remove it and just forgot.


I have no issues with the rest of your patch, so if you could submit an 
updated patch I will be happy to review it again.


One small point - when/if you do resubmit the STM part of the patch, you 
could make the code slightly cleaner by enclosing it in curly 
parentheses, thus avoiding the need to escape the double quote marks.  Ie:


+  {
+  switch (which_alternative)
+{
+case 0:
+case 1:
+  return "mov%?\t%0, %1";
+
+case 2:
+  return "mvn%?\t%0, #%B1";
+
+case 3:
+  return "movw%?\t%0, %1";
+
+case 4:
+  if (GET_CODE (XEXP (operands[1], 0)) == POST_INC)
+   {
+ operands[1] = XEXP (XEXP (operands[1], 0), 0);
+ return "ldm%(ia%)\t%1!, {%0}";
+   }
+ /* Fall through.  */
+case 5:
+  return "ldr%?\t%0, %1";
+
+case 6:
+  if (GET_CODE (XEXP (operands[0], 0)) == POST_INC)
+   {
+ operands[0] = XEXP (XEXP (operands[0], 0), 0);
+ return "stm%(ia%)\t%0!, {%1}";
+   }
+  /* Fall through.  */
+case 7:
+  return "str%?\t%1, %0";
+
+default:
+  gcc_unreachable ();
+}
+  }

Cheers
  Nick

Re: [patch][simplify-rtx] Fix 16-bit -> 64-bit multiply and accumulate

[Andrew Stubbs]

On 02/06/11 10:46, Richard Earnshaw wrote:

OK.


Committed, thanks.

Andrew

Re: [PATCH][ARM] add support for some missing 16-bit multiplication insns

[Andrew Stubbs]

On 02/06/11 16:47, Richard Earnshaw wrote:

OK.


Committed, thanks.

Andrew

Re: [PATCH: PR target/46975] Replace 32 bit instructions with 16 bit instructions in thumb2

[Nick Clifton]

Hi Carrot,


ChangeLog:
2011-05-16 Wei Guozhi 

PR target/46975
* config/arm/arm.md (*addsi3_carryin_compare0_): New pattern.
   (peephole2 for conditional move): Generate 16 bit instructions.

ChangeLog:
2010-05-16 Wei Guozhi 

PR target/46975
* gcc.target/arm/pr46975.c: New testcase.


Approved - please apply.

Cheers
  Nick

Re: Remove separate tarballs

[Joseph S. Myers]

On Sun, 29 May 2011, Gerald Pfeifer wrote:

> ...at least having the testsuite and Java separate makes a lot of sense.
> 
> The vast majority of users does not need the former and the latter is

If building GCC from source, running tests is generally considered a good 
idea...

> on the verge of becoming practically irrelevant.  As one datapoint, the

 ... and while there may be a case for modifying what's on trunk of the 
repository, separate tarballs are a case where having rarely-used, 
rarely-tested different configurations (because the rest of the compiler 
may be affected by what disabled languages are present in the source tree, 
which is what led to this change) seems not justified by the limited space 
savings.  If you want to remove some directories from your source tree, 
you are still free to do so and to submit fixes for any problems found; 
it's just not encouraged.

> Also, changing this for older release branches as happened now does 
> cause all sorts of fun (for dubious definitions of this word) for
> distribution packagers. :-(

Nothing changed for release from previous branches, which use the script 
present on the branch in question; it's only snapshots that always use the 
trunk version of this script.

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

Re: Remove separate tarballs

[Joseph S. Myers]

On Sun, 29 May 2011, Richard Guenther wrote:

> For libjava I would argue to split out only libjava/classpath which
> is what we drop in (in a slightly modified form?) from elsewhere.
> So splitting that would eventually make sense (maybe even
> with making java also compile w/o that classpath dir).

Splitting out only in the way that ECJ is split out, I think: ceasing to 
include it on trunk of the repository but supporting dropping in a 
separately made release from its separate repository.  Not making tarballs 
not contain parts of what you get in a default checkout.

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

Re: [testsuite] Provide TLS access model testcases

[Joseph S. Myers]

On Sun, 29 May 2011, Kaz Kojima wrote:

> Hi,
> 
> Rainer Orth  wrote:
> > 2010-12-30  Uros Bizjak 
> > Rainer Orth  
> > 
> > * gcc.dg/torture/tls/run-gd.c: New test.
> > * gcc.dg/torture/tls/run-ie.c: New test.
> > * gcc.dg/torture/tls/run-ld.c: New test.
> > * gcc.dg/torture/tls/run-le.c: New test.
> > * lib/target-supports.exp (check_effective_target_tls_runtime):
> > Build testcase with TLS options.
> 
> gcc.dg/torture/tls/run-gd.c fails on SH because SH assumes
> -fpic for global and local dynamic tls models.  Although a line

That sounds like an SH target bug to me.

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

Re: RFA (fold): PATCH for c++/49290 (folding *(T*)(ar+10))

[Richard Guenther]

On Tue, Jun 7, 2011 at 12:27 PM, Jakub Jelinek  wrote:
> On Tue, Jun 07, 2011 at 12:19:59PM +0200, Richard Guenther wrote:
>> On Tue, Jun 7, 2011 at 7:39 AM, Jason Merrill  wrote:
>> > In the testcase, fold_indirect_ref_1 won't fold *(T*)(s1+10) to an 
>> > ARRAY_REF
>> > because T != unsigned.  Even if it were just a typedef to unsigned, that
>> > isn't close enough, but in this case it's a typedef to const unsigned.
>> >
>> > I'm not sure what the type coherence rules are for ARRAY_REF.  Is it really
>> > necessary that the type of the ARRAY_REF match exactly the element type of
>> > the array?
>>
>> I _think_ that you can unconditionally change the code to do
>>
>>   TYPE_MAIN_VARIANT (t1) == TYPE_MAIN_VARIANT (t2)
>>   && TYPE_QUALS (t1) == TYPE_QUALS (t2)
>>
>> now, I'm not sure if for the testcase T and unsigned differ in qualifiers.
>
> I guess folding into array_ref that way is fine, but you should in the end
> fold_convert_loc it to the expected type, while the middle-end has the
> notion of useless type conversions, fold-const.c is also used by FEs and
> I think it is expected to have the types exactly matching.
> So (T)s1[10] instead of s1[10] in this case.

I'm not sure that's a good idea if the caller wants an lvalue.

Richard.

>        Jakub
>

Re: [vta, graphite?] propagate degenerate phi nodes into debug stmts

[Richard Guenther]

On Tue, Jun 7, 2011 at 12:38 PM, Alexandre Oliva  wrote:
> On Jun  6, 2011, Richard Guenther  wrote:
>
>>> You meant 4.6 stage1, but I missed it.  How's it for 4.7 stage1?
>>> Regstrapped on x86_64-linux-gnu and i686-linux-gnu.
>
>> Isn't exactly ICEing for num_ssa_operands/delink_stmt_imm_use.
>
> Uhh.  Looks like I didn't update the patch per your comments before
> putting it aside for stage1, after all.  Sorry.
>
>> So, the op_iter_init change is ok, the other two not - they should
>> either ICE or work for PHIs (by using FOR_EACH_PHI_OR_STMT_USE
>> in them).
>
> The latter is legitimately called for GIMPLE_PHI, so I changed it to use
> FOR_EACH_PHI_OR_STMT_USE.  The former was never called for GIMPLE_PHIs,
> so I put in an assert there.
>
> Regstrapped on x86_64-linux-gnu and i686-linux-gnu.  Ok?

Ok.

Thanks,
Richard.

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

Re: RFA (fold): PATCH for c++/49290 (folding *(T*)(ar+10))

[Richard Guenther]

On Tue, 7 Jun 2011, Richard Guenther wrote:

> On Tue, Jun 7, 2011 at 12:27 PM, Jakub Jelinek  wrote:
> > On Tue, Jun 07, 2011 at 12:19:59PM +0200, Richard Guenther wrote:
> >> On Tue, Jun 7, 2011 at 7:39 AM, Jason Merrill  wrote:
> >> > In the testcase, fold_indirect_ref_1 won't fold *(T*)(s1+10) to an 
> >> > ARRAY_REF
> >> > because T != unsigned.  Even if it were just a typedef to unsigned, that
> >> > isn't close enough, but in this case it's a typedef to const unsigned.
> >> >
> >> > I'm not sure what the type coherence rules are for ARRAY_REF.  Is it 
> >> > really
> >> > necessary that the type of the ARRAY_REF match exactly the element type 
> >> > of
> >> > the array?
> >>
> >> I _think_ that you can unconditionally change the code to do
> >>
> >>   TYPE_MAIN_VARIANT (t1) == TYPE_MAIN_VARIANT (t2)
> >>   && TYPE_QUALS (t1) == TYPE_QUALS (t2)
> >>
> >> now, I'm not sure if for the testcase T and unsigned differ in qualifiers.
> >
> > I guess folding into array_ref that way is fine, but you should in the end
> > fold_convert_loc it to the expected type, while the middle-end has the
> > notion of useless type conversions, fold-const.c is also used by FEs and
> > I think it is expected to have the types exactly matching.
> > So (T)s1[10] instead of s1[10] in this case.
> 
> I'm not sure that's a good idea if the caller wants an lvalue.

Rather build the array-ref with type T directly (thus, with a mismatch
between the type of the array-ref and the element type).

Richard.

[PATCH] Fix ICE in reset_unmarked_insns_debug_uses (PR middle-end/49308)

[Jakub Jelinek]

On Mon, Jun 06, 2011 at 10:27:51AM -0300, Alexandre Oliva wrote:
> On Jun  6, 2011, Eric Botcazou  wrote:
> 
> >> It might be too late for DF to do anything sensible to preserve the
> >> debug info rather than just throw it away, as your partial approval
> >> suggests.
> 
> > OK, let me think about this a little more.
> 
> >> Indeed, sorry, I misread it.
> 
> > Mind installing these bits separately?  My understanding is that they are 
> > independent correctness fixes.
> 
> Tested, installed.

This broke e.g. the attached testcase.
The problem is that after resetting+rescanning a debug insn
reset_unmarked_insns_debug_uses continued walking the DF chains for that
debug insn, but those were all invalidated by the
df_insn_rescan_debug_internal call.

Fixed thusly.  Additionally I've renamed a variable that was shadowing
a variable of the same name, which confused me quite a bit when debugging
it - I was expecting insn to be a DEBUG_INSN, while it was something
completely different.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

2011-06-07  Jakub Jelinek  

PR middle-end/49308
* dce.c (reset_unmarked_insns_debug_uses): Avoid shadowing insn
variable.  After resetting and rescanning insn continue with previous
statement.

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

--- gcc/dce.c.jj2011-06-06 19:07:08.0 +0200
+++ gcc/dce.c   2011-06-07 11:08:12.0 +0200
@@ -514,11 +514,11 @@ reset_unmarked_insns_debug_uses (void)
  struct df_link *defs;
  for (defs = DF_REF_CHAIN (use); defs; defs = defs->next)
{
- rtx insn;
+ rtx ref_insn;
  if (DF_REF_IS_ARTIFICIAL (defs->ref))
continue;
- insn = DF_REF_INSN (defs->ref);
- if (!marked_insn_p (insn))
+ ref_insn = DF_REF_INSN (defs->ref);
+ if (!marked_insn_p (ref_insn))
break;
}
  if (!defs)
@@ -527,6 +527,7 @@ reset_unmarked_insns_debug_uses (void)
 each of the DEFs?  */
  INSN_VAR_LOCATION_LOC (insn) = gen_rtx_UNKNOWN_VAR_LOC ();
  df_insn_rescan_debug_internal (insn);
+ break;
}
}
 }
--- gcc/testsuite/gfortran.dg/pr49308.f90.jj2011-06-07 11:39:39.0 
+0200
+++ gcc/testsuite/gfortran.dg/pr49308.f90   2011-06-07 11:30:25.0 
+0200
@@ -0,0 +1,28 @@
+! PR middle-end/49308
+! { dg-do compile }
+! { dg-options "-O2 -funroll-loops -g" }
+
+subroutine foo(n, b, d, e)
+  type t
+integer :: f
+  end type t
+  type s
+type(t), pointer :: g
+  end type s
+  type u
+type(s), dimension(:), pointer :: h
+  end type
+  integer :: i, k, n
+  type(u), pointer :: a, e
+  character(len=250) :: b, c, d
+  logical :: l
+  do i = 1, n
+j = i - 1
+if (j/=0) c = trim(b) // adjustl(d(j))
+  end do
+  a => e
+  do k = 1, size(a%h)
+ l = (a%h(k)%g%f == a%h(1)%g%f)
+ if (.not.(l)) call bar()
+  enddo
+end subroutine foo


Jakub

Re: [ARM] TLS Descriptor support

[Richard Earnshaw]

On 06/07/11 07:11, Nathan Sidwell wrote:
> On 06/06/11 17:27, Richard Earnshaw wrote:
> 
>> Eh? This is backwards. There is blx , but no bl . If the assembler
>> gets confused with 'bl r0' then it needs to be fixed urgently.
> 
> Are you requiring the assembler be fixed before this patch can be committed 
> (without the '+'?)
> 
> nathan
> 

Yes, the assembler output here should be "bl\\t%c0(tlsdesc)" for all
variants.

I'd also much prefer that the named variant be GNU and GNU2, as they are
for x86.  It's much less confusing to users that way (the fact that the
first (GNU) variant is documented in the ARM ABI specification is simply
down to a lack of external documentation to refer to, but the underlying
model is the same as that used elsewere for the first GNU version).

R.

[PING] [PATCH][JAVA] Sanitize Java frontend global tree building

[Richard Guenther]

On Thu, 26 May 2011, Richard Guenther wrote:

> 
> In preparation to move all frontends common tree node building to
> the middle-end this makes the Java frontend actually use the
> standard routines.  It's still severely broken in overriding
> things with stuff that does not match the targets C ABI, but well,
> Java ...
> 
> Bootstrapped and tested on x86_64-unknown-linux-gnu, ok for trunk?

Ping.

> Thanks,
> Richard.
> 
> 2011-05-26  Richard Guenther  
> 
>   java/
>   * decl.c (java_init_decl_processing): Call build_common_nodes,
>   set_sizetype and build_common_nodes_2 at the beginning.  Remove
>   then duplicate initializations.
> 
> Index: gcc/java/decl.c
> ===
> --- gcc/java/decl.c   (revision 174281)
> +++ gcc/java/decl.c   (working copy)
> @@ -566,13 +566,22 @@ java_init_decl_processing (void)
>pushlevel (0); /* make the binding_level structure for global names */
>global_binding_level = current_binding_level;
>  
> -  /* The code here must be similar to build_common_tree_nodes{,_2} in
> - tree.c, especially as to the order of initializing common nodes.  */
> -  error_mark_node = make_node (ERROR_MARK);
> -  TREE_TYPE (error_mark_node) = error_mark_node;
> +  /* Build common tree nodes, Java has an unsigned char.  */
> +  build_common_tree_nodes (false);
>  
> -  /* Create sizetype first - needed for other types. */
> -  initialize_sizetypes ();
> +  /* This is not a java type, however tree-dfa requires a definition for
> + size_type_node.  */
> +  size_type_node = make_unsigned_type (POINTER_SIZE);
> +  set_sizetype (size_type_node);
> +
> +  /* Build the rest of the common tree nodes.  */
> +  build_common_tree_nodes_2 (0);
> +
> +  /* ???  Now we continue and override some of the built types again
> + with Java specific types.  As the above generated types are
> + supposed to match the targets C ABI this isn't really the way
> + to go and any Java specifics should _not_ use those global types
> + if the Java ABI does not match the C one.  */
>  
>byte_type_node = make_signed_type (8);
>pushdecl (build_decl (BUILTINS_LOCATION,
> @@ -604,11 +613,6 @@ java_init_decl_processing (void)
>   TYPE_DECL, get_identifier ("unsigned long"),
>   unsigned_long_type_node));
>  
> -  /* This is not a java type, however tree-dfa requires a definition for
> - size_type_node.  */
> -  size_type_node = make_unsigned_type (POINTER_SIZE);
> -  set_sizetype (size_type_node);
> -
>/* Define these next since types below may used them.  */
>integer_type_node = java_type_for_size (INT_TYPE_SIZE, 0);
>integer_zero_node = build_int_cst (NULL_TREE, 0);
> @@ -624,39 +628,22 @@ java_init_decl_processing (void)
>  = double_int_to_tree (unsigned_long_type_node,
> double_int_setbit (double_int_zero, 64));
>  
> -  size_zero_node = size_int (0);
> -  size_one_node = size_int (1);
> -  bitsize_zero_node = bitsize_int (0);
> -  bitsize_one_node = bitsize_int (1);
> -  bitsize_unit_node = bitsize_int (BITS_PER_UNIT);
> -
>long_zero_node = build_int_cst (long_type_node, 0);
>  
> -  void_type_node = make_node (VOID_TYPE);
>pushdecl (build_decl (BUILTINS_LOCATION,
>   TYPE_DECL, get_identifier ("void"), void_type_node));
> -  layout_type (void_type_node);  /* Uses size_zero_node */
> -
> -  ptr_type_node = build_pointer_type (void_type_node);
> -  const_ptr_type_node
> -= build_pointer_type (build_type_variant (void_type_node, 1, 0));
>  
>t = make_node (VOID_TYPE);
>layout_type (t); /* Uses size_zero_node */
>return_address_type_node = build_pointer_type (t);
>  
> -  null_pointer_node = build_int_cst (ptr_type_node, 0);
> -
> -  char_type_node = make_node (INTEGER_TYPE);
> +  char_type_node = make_unsigned_type (16);
>TYPE_STRING_FLAG (char_type_node) = 1;
> -  TYPE_PRECISION (char_type_node) = 16;
> -  fixup_unsigned_type (char_type_node);
>pushdecl (build_decl (BUILTINS_LOCATION,
>   TYPE_DECL, get_identifier ("char"), char_type_node));
>  
> -  boolean_type_node = make_node (BOOLEAN_TYPE);
> -  TYPE_PRECISION (boolean_type_node) = 1;
> -  fixup_unsigned_type (boolean_type_node);
> +  boolean_type_node = make_unsigned_type (1);
> +  TREE_SET_CODE (boolean_type_node, BOOLEAN_TYPE);
>pushdecl (build_decl (BUILTINS_LOCATION,
>   TYPE_DECL, get_identifier ("boolean"),
>   boolean_type_node));
> 

Re: [testsuite] Provide TLS access model testcases

[Kaz Kojima]

"Joseph S. Myers"  wrote:
>> gcc.dg/torture/tls/run-gd.c fails on SH because SH assumes
>> -fpic for global and local dynamic tls models.  Although a line
> 
> That sounds like an SH target bug to me.

Ok, I'd like to fix the SH backend so that those tests pass
without -fpic/-fpie.

Regards,
kaz

Re: [PATCH, i386]: Remaining FP moves cleanups

[H.J. Lu]

On Sun, Jun 5, 2011 at 1:46 PM, Uros Bizjak  wrote:
> Hello!
>
> 2011-06-05  Uros Bizjak  
>
>        * config/i386/i386.md (*movdf_internal_rex64) :
>        Remove MODE_TI handling.  Remove SSE1 handling in attribute "mode"
>        calculation.
>        (*movdf_internal_rex64) : Remove MODE_TI handling.
>        Simplify MODE_V1DF and MODE_V2SF handling.
>        (*movsf_internal): Remove x constraint from operand 1 alternative 7.
>        Simplify MODE_SF handling.
>
> Patch was bootstrapped and regression tested on x86_64-pc-linux-gnuj
> {,-m32} AVX target. Committed to mainline SVN.
>

Hi Uros,

The new *movsf_internal patter has

 [(set (match_operand:SF 0 "nonimmediate_operand"
  "=f,m,f,?r ,?m,x,x,x,m,!*y,!m,!*y,?Yi,?r,!*Ym,!r")
(match_operand:SF 1 "general_operand"
  "fm,f,G,rmF,Fr,C,x,m,x,m  ,*y,*y ,r  ,Yi,r   ,*Ym"))]
...
case 7:
case 8:
  if (TARGET_AVX && REG_P (operands[0]) && REG_P (operands[1]))
return "vmovss\t{%1, %0, %0|%0, %0, %1}";
  return "%vmovss\t{%1, %0|%0, %1}";

Since 7 is store and 8 is load,

if (TARGET_AVX && REG_P (operands[0]) && REG_P (operands[1]))

will always be false.  Should we remove it?

Thanks.

-- 
H.J.

Re: RFA (fold): PATCH for c++/49290 (folding *(T*)(ar+10))

[Michael Matz]

Hi,

On Tue, 7 Jun 2011, Richard Guenther wrote:

> > > fold_convert_loc it to the expected type, while the middle-end has 
> > > the notion of useless type conversions, fold-const.c is also used by 
> > > FEs and I think it is expected to have the types exactly matching. 
> > > So (T)s1[10] instead of s1[10] in this case.
> > 
> > I'm not sure that's a good idea if the caller wants an lvalue.
> 
> Rather build the array-ref with type T directly (thus, with a mismatch 
> between the type of the array-ref and the element type).

Ick.  Sooner or later such inconsistency will bite us.  It always does.


Ciao,
Michael.

Re: [lra] A new branch

[Joseph S. Myers]

On Mon, 30 May 2011, Vladimir Makarov wrote:

>   * doc/tm.texi.in (TARGET_REGISTER_BANK): New hook.

Please include the text of documentation for new hooks in target.def 
instead of tm.texi.in where possible (so tm.texi.in just has the @hook 
line) - that is, unless it's based on older GFDL-only text.

A lot of the new source files appear to include toplev.h but I don't see 
any uses of functions declared there.  I cleaned up toplev.h includes last 
year; please make sure that source files only include headers they 
actually need.

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

Re: RFA (fold): PATCH for c++/49290 (folding *(T*)(ar+10))

[Richard Guenther]

On Tue, 7 Jun 2011, Michael Matz wrote:

> Hi,
> 
> On Tue, 7 Jun 2011, Richard Guenther wrote:
> 
> > > > fold_convert_loc it to the expected type, while the middle-end has 
> > > > the notion of useless type conversions, fold-const.c is also used by 
> > > > FEs and I think it is expected to have the types exactly matching. 
> > > > So (T)s1[10] instead of s1[10] in this case.
> > > 
> > > I'm not sure that's a good idea if the caller wants an lvalue.
> > 
> > Rather build the array-ref with type T directly (thus, with a mismatch 
> > between the type of the array-ref and the element type).
> 
> Ick.  Sooner or later such inconsistency will bite us.  It always does.

There are already some similar "weak" type matchings done in fold-const.c.

But yeah ... I'm sure adding strong type checks to the tree checker
will detect may pre-existing inconsistencies...

Richard.

Re: [4.6 PATCH] Workaround for stack slot sharing problems with unrolling (PR fortran/49103)

[Michael Matz]

Hi,

On Tue, 7 Jun 2011, Richard Guenther wrote:

> > +         tree base = get_base_address (lhs);
> 
> Probably easier and more complete to do
> 
> if (lhs && TREE_CODE (lhs) != SSA_NAME)
>   {
>  tree base = get_base_address (lhs);
> 
> 
> I don't like the patch too much, but it looks reasonable.  At least 
> reverting your patch doesn't really fix anything.
> 
> Any opinions from others?

It's ugly.  But ... well, IMHO such hacks are acceptable for released 
branches.


Ciao,
Michael.

Re: RFA (fold): PATCH for c++/49290 (folding *(T*)(ar+10))

[Jason Merrill]

On 06/07/2011 06:19 AM, Richard Guenther wrote:

I _think_ that you can unconditionally change the code to do

   TYPE_MAIN_VARIANT (t1) == TYPE_MAIN_VARIANT (t2)
   &&  TYPE_QUALS (t1) == TYPE_QUALS (t2)

now, I'm not sure if for the testcase T and unsigned differ in qualifiers.
Do they?


Hmm, I think with the changes I made to the testcase they end up with 
the same qualifiers.  But for constexpr I need to handle them having 
different qualifiers, too.


Jason

Commit: Add support for configuring for other V850 architectures

[Nick Clifton]

Hi Guys,

  I am applying the patch below to tidy up the V850 architecture
  selection in config.gcc and to add support for newer V850
  architectures (eg V850e2v3).

Cheers
  Nick

gcc/ChangeLog
2011-06-07  Nick Clifton  

* config.gcc: Unify V850 architecture options and add support for
newer V850 architectures.
* config/v850/t-v850e: Delete.

Index: gcc/config.gcc
===
--- gcc/config.gcc  (revision 174737)
+++ gcc/config.gcc  (working copy)
@@ -2559,11 +2559,28 @@
c_target_objs="${c_target_objs} spu-c.o"
cxx_target_objs="${cxx_target_objs} spu-c.o"
;;
-v850e1-*-*)
-   target_cpu_default="TARGET_CPU_v850e1"
+
+v850*-*-*)
+   case ${target} in
+   v850e2v3-*-*)
+   target_cpu_default="TARGET_CPU_v850e2v3"
+   ;;
+   v850e2-*-*)
+   target_cpu_default="TARGET_CPU_v850e2"
+   ;;
+   v850e1-*-* | v850es-*-*)
+   target_cpu_default="TARGET_CPU_v850e1"
+   ;;
+   v850e-*-*)
+   target_cpu_default="TARGET_CPU_v850e"
+   ;;
+   v850-*-*)
+   target_cpu_default="TARGET_CPU_generic"
+   ;;
+   esac
tm_file="dbxelf.h elfos.h newlib-stdint.h v850/v850.h"
tm_p_file=v850/v850-protos.h
-   tmake_file=v850/t-v850e
+   tmake_file=v850/t-v850
md_file=v850/v850.md
extra_modes=v850/v850-modes.def
out_file=v850/v850.c
@@ -2577,37 +2594,6 @@
cxx_target_objs="v850-c.o"
use_gcc_stdint=wrap
;;
-v850e-*-*)
-   target_cpu_default="TARGET_CPU_v850e"
-   tm_file="dbxelf.h elfos.h newlib-stdint.h v850/v850.h"
-   tm_p_file=v850/v850-protos.h
-   tmake_file=v850/t-v850e
-   md_file=v850/v850.md
-   extra_modes=v850/v850-modes.def
-   out_file=v850/v850.c
-   extra_options="${extra_options} v850/v850.opt"
-   if test x$stabs = xyes
-   then
-   tm_file="${tm_file} dbx.h"
-   fi
-   use_collect2=no
-   c_target_objs="v850-c.o"
-   cxx_target_objs="v850-c.o"
-   use_gcc_stdint=wrap
-   ;;
-v850-*-*)
-   target_cpu_default="TARGET_CPU_generic"
-   tm_file="dbxelf.h elfos.h newlib-stdint.h ${tm_file}"
-   tmake_file=v850/t-v850
-   if test x$stabs = xyes
-   then
-   tm_file="${tm_file} dbx.h"
-   fi
-   use_collect2=no
-   c_target_objs="v850-c.o"
-   cxx_target_objs="v850-c.o"
-   use_gcc_stdint=wrap
-   ;;
 vax-*-linux*)
tm_file="${tm_file} dbxelf.h elfos.h gnu-user.h linux.h vax/elf.h 
vax/linux.h"
extra_options="${extra_options} vax/elf.opt"
@@ -3493,7 +3479,7 @@
v850*-*-*)
supported_defaults=cpu
case ${with_cpu} in
-   "" | v850e | v850e1)
+   "" | v850e | v850e1 | v850e2 | v850es | v850e2v3)
# OK
;;
*)
@@ -3621,14 +3607,15 @@
;;
 
v850*-*-*)
-   # FIXME: The v850 is "special" in that it does not support
-   # runtime CPU selection, only --with-cpu.
case "x$with_cpu" in
x)
;;
-   xv850e)
+   xv850e | xv850e1 | xv850e2 | xv850e2v3)
target_cpu_default2="TARGET_CPU_$with_cpu"
;;
+   xv850es)
+   target_cpu_default2="TARGET_CPU_v850e1"
+   ;;
esac
;;
 esac

Re: [build] Move ENABLE_EXECUTE_STACK to toplevel libgcc

[Joseph S. Myers]

On Tue, 31 May 2011, Paolo Bonzini wrote:

> > I'd thought about it, but refrained since HAVE_ENABLE_EXECUTE_STACK
> > affects only three cpus.  Currently, our documentation of libgcc
> > configury and macros used is close to non-existant.  That's probably for
> > someone who has implemented this stuff.
> 
> True, OTOH HAVE_ENABLE_EXECUTE_STACK is a target macro, and those are well
> documented.  Just say that it has to be defined if libgcc provides a
> non-trivial implementation of __enable_execute_stack; it doesn't need to delve
> into how to hack libgcc.

As I understand it, HAVE_ENABLE_EXECUTE_STACK is only used in code under 
gcc/config/.  That is, it is not a target macro as usually understood but 
is logically private to a few back ends (and it would be a bug to 
introduce uses of it elsewhere, just like it was a bug to introduce uses 
of TARGET_64BIT outside gcc/config/ when that macro also is logically 
private).

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

Re: [PATCH, i386]: Remaining FP moves cleanups

[Uros Bizjak]

On Tue, Jun 7, 2011 at 3:42 PM, H.J. Lu  wrote:

>> 2011-06-05  Uros Bizjak  
>>
>>        * config/i386/i386.md (*movdf_internal_rex64) :
>>        Remove MODE_TI handling.  Remove SSE1 handling in attribute "mode"
>>        calculation.
>>        (*movdf_internal_rex64) : Remove MODE_TI handling.
>>        Simplify MODE_V1DF and MODE_V2SF handling.
>>        (*movsf_internal): Remove x constraint from operand 1 alternative 7.
>>        Simplify MODE_SF handling.
>>
>> Patch was bootstrapped and regression tested on x86_64-pc-linux-gnuj
>> {,-m32} AVX target. Committed to mainline SVN.
>>
>
> Hi Uros,
>
> The new *movsf_internal patter has
>
>  [(set (match_operand:SF 0 "nonimmediate_operand"
>          "=f,m,f,?r ,?m,x,x,x,m,!*y,!m,!*y,?Yi,?r,!*Ym,!r")
>        (match_operand:SF 1 "general_operand"
>          "fm,f,G,rmF,Fr,C,x,m,x,m  ,*y,*y ,r  ,Yi,r   ,*Ym"))]
> ...
>    case 7:
>    case 8:
>      if (TARGET_AVX && REG_P (operands[0]) && REG_P (operands[1]))
>        return "vmovss\t{%1, %0, %0|%0, %0, %1}";
>      return "%vmovss\t{%1, %0|%0, %1}";
>
> Since 7 is store and 8 is load,
>
> if (TARGET_AVX && REG_P (operands[0]) && REG_P (operands[1]))
>
> will always be false.  Should we remove it?

No, because it also handles fallthru from case 6.

OTOH, you are right, this statement can be moved to case 6, without
the check for registers.

Thanks,
Uros.

Re: RFA (fold): PATCH for c++/49290 (folding *(T*)(ar+10))

[Richard Guenther]

On Tue, Jun 7, 2011 at 3:55 PM, Jason Merrill  wrote:
> On 06/07/2011 06:19 AM, Richard Guenther wrote:
>>
>> I _think_ that you can unconditionally change the code to do
>>
>>   TYPE_MAIN_VARIANT (t1) == TYPE_MAIN_VARIANT (t2)
>>   &&  TYPE_QUALS (t1) == TYPE_QUALS (t2)
>>
>> now, I'm not sure if for the testcase T and unsigned differ in qualifiers.
>> Do they?
>
> Hmm, I think with the changes I made to the testcase they end up with the
> same qualifiers.  But for constexpr I need to handle them having different
> qualifiers, too.

In that case you could do what Jakub suggested - but only for rvalues
of course.  I'm not sure if we already avoid calling the folding where we
require lvalues.

Can't you instead adjust the type you feed to fold_indirect_ref_1 in
the caller in the C++ FE?

Richard.

> Jason
>

Re: [PATCH, i386]: Remaining FP moves cleanups

[H.J. Lu]

On Tue, Jun 7, 2011 at 7:02 AM, Uros Bizjak  wrote:
> On Tue, Jun 7, 2011 at 3:42 PM, H.J. Lu  wrote:
>
>>> 2011-06-05  Uros Bizjak  
>>>
>>>        * config/i386/i386.md (*movdf_internal_rex64) :
>>>        Remove MODE_TI handling.  Remove SSE1 handling in attribute "mode"
>>>        calculation.
>>>        (*movdf_internal_rex64) : Remove MODE_TI handling.
>>>        Simplify MODE_V1DF and MODE_V2SF handling.
>>>        (*movsf_internal): Remove x constraint from operand 1 alternative 7.
>>>        Simplify MODE_SF handling.
>>>
>>> Patch was bootstrapped and regression tested on x86_64-pc-linux-gnuj
>>> {,-m32} AVX target. Committed to mainline SVN.
>>>
>>
>> Hi Uros,
>>
>> The new *movsf_internal patter has
>>
>>  [(set (match_operand:SF 0 "nonimmediate_operand"
>>          "=f,m,f,?r ,?m,x,x,x,m,!*y,!m,!*y,?Yi,?r,!*Ym,!r")
>>        (match_operand:SF 1 "general_operand"
>>          "fm,f,G,rmF,Fr,C,x,m,x,m  ,*y,*y ,r  ,Yi,r   ,*Ym"))]
>> ...
>>    case 7:
>>    case 8:
>>      if (TARGET_AVX && REG_P (operands[0]) && REG_P (operands[1]))
>>        return "vmovss\t{%1, %0, %0|%0, %0, %1}";
>>      return "%vmovss\t{%1, %0|%0, %1}";
>>
>> Since 7 is store and 8 is load,
>>
>> if (TARGET_AVX && REG_P (operands[0]) && REG_P (operands[1]))
>>
>> will always be false.  Should we remove it?
>
> No, because it also handles fallthru from case 6.
>
> OTOH, you are right, this statement can be moved to case 6, without
> the check for registers.
>

Like this?  OK for trunk with a ChangeLog entry?

Thanks.

-- 
H.J.

diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
index 58de87b..a61bffb 100644
--- a/gcc/config/i386/i386.md
+++ b/gcc/config/i386/i386.md
@@ -3207,11 +3207,11 @@
 case 6:
   if (get_attr_mode (insn) == MODE_V4SF)
return "%vmovaps\t{%1, %0|%0, %1}";
+  else if (TARGET_AVX && REG_P (operands[0]) && REG_P (operands[1]))
+   return "vmovss\t{%1, %0, %0|%0, %0, %1}";

 case 7:
 case 8:
-  if (TARGET_AVX && REG_P (operands[0]) && REG_P (operands[1]))
-   return "vmovss\t{%1, %0, %0|%0, %0, %1}";
   return "%vmovss\t{%1, %0|%0, %1}";

 case 9:

Re: [PATCH, i386]: Remaining FP moves cleanups

[Uros Bizjak]

On Tue, Jun 7, 2011 at 4:07 PM, H.J. Lu  wrote:

>> OTOH, you are right, this statement can be moved to case 6, without
>> the check for registers.
>>
>
> Like this?  OK for trunk with a ChangeLog entry?
>
> Thanks.
>
> --
> H.J.
> 
> diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
> index 58de87b..a61bffb 100644
> --- a/gcc/config/i386/i386.md
> +++ b/gcc/config/i386/i386.md
> @@ -3207,11 +3207,11 @@
>     case 6:
>       if (get_attr_mode (insn) == MODE_V4SF)
>        return "%vmovaps\t{%1, %0|%0, %1}";
> +      else if (TARGET_AVX && REG_P (operands[0]) && REG_P (operands[1]))

if (TARGET_AVX)

> +       return "vmovss\t{%1, %0, %0|%0, %0, %1}";
>
>     case 7:
>     case 8:
> -      if (TARGET_AVX && REG_P (operands[0]) && REG_P (operands[1]))
> -       return "vmovss\t{%1, %0, %0|%0, %0, %1}";
>       return "%vmovss\t{%1, %0|%0, %1}";
>
>     case 9:
>

OK with this change and suitable ChangeLog entry.

Thanks,
Uros.

Re: RFA (fold): PATCH for c++/49290 (folding *(T*)(ar+10))

[Jason Merrill]

On 06/07/2011 10:05 AM, Richard Guenther wrote:

In that case you could do what Jakub suggested - but only for rvalues
of course.


Right, and I need to handle lvalues as well.


I'm not sure if we already avoid calling the folding where we
require lvalues.


No, we don't.


Can't you instead adjust the type you feed to fold_indirect_ref_1 in
the caller in the C++ FE?


Not without digging down into the operand to see what type it wants.  At 
that point I might as well just copy the whole function into the FE.


Jason

Re: Committed: fix PR49285, breakage building libgcc2 for MMIX

[Richard Sandiford]

Hans-Peter Nilsson  writes:
> I needed a baseline for PR48542 (problems with setjmp/longjmp), but
> building MMIX was broken on trunk.  It was "bitten" by the fixups to
> predicate matching done recentlish.  The comment above the MMIX
> truncdfsf2 expander complains about having to use an expander to
> force an operand to memory - and then goes on and uses memory_operand
> for that operand anyway!  That accidentally worked before the fixup,
> because after copying the failing operand to a new pseudo, the
> expander was called without the optabs machinery doublechecking the
> new pseudo against the predicate.  While I stand by the comment and
> still think the optabs machinery could automatically fix up operands
> as needed to force an operand into memory when the predicate says so,
> it hasn't worked like that before, and I guess it's no use adding
> something like that just for one port, where an expander will do.

FWIW, having a target-independent feature sounds like a good idea to me.
It's similar in spirit to the new code that tries to force addresses
into registers if a memory predicate rejects a mem.  That too is something
that was often handled by expanders, but which is nicer without.

The implementation could be along the same lines.  Have an allows_reg
field in recog_data that says whether the predicate allows registers.
If it doesn't, try forcing to a stack slot instead of to registers.

Richard

Re: Remove separate tarballs

[Andrew Haley]

On 05/29/2011 02:07 AM, Gerald Pfeifer wrote:
> 
> The vast majority of users does not need the former and the latter is
> on the verge of becoming practically irrelevant.  As one datapoint, the
> entire FreeBSD Ports Collection has a single(!) port relying on GCJ.

It's not quite as irrelevant as you think: The IcedTea bootrapping
process that's used to port OpenJDK depends on gcj.  The first thing
we have to do an any target is get gcj working.  I'm doing that right
now.

Andrew.

Re: [Design notes, RFC] Address-lowering prototype design (PR46556)

[William J. Schmidt]

On Tue, 2011-06-07 at 12:06 +0200, Richard Guenther wrote:
> On Mon, Jun 6, 2011 at 8:07 PM, William J. Schmidt
>  wrote:



> >  * If the original expression will be recognized as a "hidden global store" 
> > in
> >   tree-ssa-sink.c:is_hidden_global_store, but the replacement expression 
> > will
> >   not, it is possible for the dead code eliminator to remove the modified
> >   statement.  It seems to me this shouldn't normally happen in practice.  
> > For
> >   now I detect this case and refuse to do the replacement, but I suspect a
> >   possible front-end or upstream-optimization problem here.  The test case
> >   that fails here is libstdc++-v3/testsuite/23_containers/vector/
> >   ext_pointer_modifiers/insert.cc.  More investigation required.
> 
> That indeed sounds odd.

When I looked into it, the addressing expression was fairly complex
initially, with templates and inheritance involved.  The code to create
the affine tree combination was able to collapse a great deal of the
arithmetic and produce something much simpler that no longer referenced
the item that had made it look like a global store originally.  (I.e.,
buried in the expression were an (&x + a) and a -(&x + a) that cancelled
out and removed all traces of x.)  It appeared to me that this was being
done correctly, but it was a very complex expression and I might have
missed something.

The result was that essentially the entire procedure ended up going
dead.  It's possible that some information was either lost or not
provided by the front end that should have prevented that.



> > Loss of aliasing information
> > 
> > The most serious problem I've run into is degraded performance due to poorer
> > instruction scheduling choices.  I tracked this down to
> > alias.c:nonoverlapping_component_refs_p.
> >
> > This code proves that two memory accesses don't overlap by attempting to 
> > prove
> > that they access different fields of the same structure.  This is done using
> > the MEM_EXPRs of the two rtx's, which record the expression trees that were
> > translated into the rtx's during expand.  When address lowering is not
> > present, a simple COMPONENT_REF will appear in the MEM_EXPR:  x.a, for
> > example.  However, address lowering changes the simple COMPONENT_REF into a
> > [TARGET_]MEM_REF that is no longer necessarily identifiable as a field
> > reference.  Thus the aliasing machinery can no longer prove that two such
> > field references are disjoint.
> >
> > This has severe consequences for performance, and has to be dealt with if
> > address lowering is to be successful.
> >
> > I've worked around this with an admittedly fragile solution; I'll discuss 
> > the
> > drawbacks below.  The idea is to construct a mapping from replacement 
> > mem_refs
> > to the original expressions that they replaced.  When a MEM_EXPR is being 
> > set
> > during expand, we first look up the mem_ref in the mapping.  If present, the
> > MEM_EXPR is set to the original expression, rather than to the mem_ref.  
> > This
> > essentially duplicates the behavior in the absence of address lowering.
> 
> Ick.  We had this in the past via TMR_ORIGINAL which caused all sorts
> of problems.  Removing it didn't cause much degradation because we now
> preserve points-to information.
> 
> Originally I played with lowering all memory accesses to MEM_REFs
> (see the old mem-ref branch), and the loss of type-based alias
> disambiguation was indeed an issue.
> 
> But - I definitely do not like the idea of preserving something similar
> to TMR_ORIGINAL.  Instead we can try preserving some information
> we derive from it.  We keep the original access type that we can use
> for TBAA but do not retain knowledge on whether the type of the
> MEM_REF is valid for TBAA or if it is view-converted.

Yes, I really don't like what I have at the moment, either.  I put it in
place as a stopgap to let me proceed to look for other performance
problems.

The question is how we can infer useful information for TBAA from the
MEM_REFs and TMRs.  I poked at trying to identify types and offsets from
the MEM_EXPRs, but this ended up being useless; I had to constrain too
many cases to maintain correctness, and couldn't prove the type
information for the important cases in SPEC I was trying to address.

Unfortunately, the whole design goes down the drain if we can't find a
way to solve the TBAA issue.  The performance degradations are too
costly.



Thanks,
Bill

[PATCH] Remove set_sizetype

[Richard Guenther]

Now that there is a single place left to call set_sizetype we can
remove it and initialize sizetypes properly from the start
(in initialize_sizetypes).

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

Richard.

2011-06-07  Richard Guenther  

* stor-layout.c (initialize_sizetypes): Initialize all
sizetypes based on target definitions.
(set_sizetype): Remove.
* tree.c (build_common_tree_nodes): Do not call set_sizetype.
* tree.h (set_sizetype): Remove.

Index: gcc/stor-layout.c
===
*** gcc/stor-layout.c.orig  2011-06-06 12:26:32.0 +0200
--- gcc/stor-layout.c   2011-06-07 15:04:44.0 +0200
*** make_accum_type (int precision, int unsi
*** 2189,2281 
return type;
  }
  
! /* Initialize sizetype and bitsizetype to a reasonable and temporary
!value to enable integer types to be created.  */
  
  void
  initialize_sizetypes (void)
  {
!   tree t = make_node (INTEGER_TYPE);
!   int precision = GET_MODE_BITSIZE (SImode);
  
!   SET_TYPE_MODE (t, SImode);
!   TYPE_ALIGN (t) = GET_MODE_ALIGNMENT (SImode);
!   TYPE_IS_SIZETYPE (t) = 1;
!   TYPE_UNSIGNED (t) = 1;
!   TYPE_SIZE (t) = build_int_cst (t, precision);
!   TYPE_SIZE_UNIT (t) = build_int_cst (t, GET_MODE_SIZE (SImode));
!   TYPE_PRECISION (t) = precision;
! 
!   set_min_and_max_values_for_integral_type (t, precision,
/*is_unsigned=*/true);
- 
-   sizetype = t;
-   bitsizetype = build_distinct_type_copy (t);
- }
- 
- /* Make sizetype a version of TYPE, and initialize *sizetype accordingly.
-We do this by overwriting the stub sizetype and bitsizetype nodes created
-by initialize_sizetypes.  This makes sure that (a) anything stubby about
-them no longer exists and (b) any INTEGER_CSTs created with such a type,
-remain valid.  */
- 
- void
- set_sizetype (tree type)
- {
-   tree t, max;
-   int oprecision = TYPE_PRECISION (type);
-   /* The *bitsizetype types use a precision that avoids overflows when
-  calculating signed sizes / offsets in bits.  However, when
-  cross-compiling from a 32 bit to a 64 bit host, we are limited to 64 bit
-  precision.  */
-   int precision
- = MIN (oprecision + BITS_PER_UNIT_LOG + 1, MAX_FIXED_MODE_SIZE);
-   precision
- = GET_MODE_PRECISION (smallest_mode_for_size (precision, MODE_INT));
-   if (precision > HOST_BITS_PER_WIDE_INT * 2)
- precision = HOST_BITS_PER_WIDE_INT * 2;
- 
-   /* sizetype must be an unsigned type.  */
-   gcc_assert (TYPE_UNSIGNED (type));
- 
-   t = build_distinct_type_copy (type);
-   /* We want to use sizetype's cache, as we will be replacing that type.  */
-   TYPE_CACHED_VALUES (t) = TYPE_CACHED_VALUES (sizetype);
-   TYPE_CACHED_VALUES_P (t) = TYPE_CACHED_VALUES_P (sizetype);
-   TYPE_UID (t) = TYPE_UID (sizetype);
-   TYPE_IS_SIZETYPE (t) = 1;
- 
-   /* Replace our original stub sizetype.  */
-   memcpy (sizetype, t, tree_size (sizetype));
-   TYPE_MAIN_VARIANT (sizetype) = sizetype;
-   TYPE_CANONICAL (sizetype) = sizetype;
- 
/* sizetype is unsigned but we need to fix TYPE_MAX_VALUE so that it is
   sign-extended in a way consistent with force_fit_type.  */
-   max = TYPE_MAX_VALUE (sizetype);
TYPE_MAX_VALUE (sizetype)
! = double_int_to_tree (sizetype, tree_to_double_int (max));
  
!   t = make_node (INTEGER_TYPE);
!   TYPE_NAME (t) = get_identifier ("bit_size_type");
!   /* We want to use bitsizetype's cache, as we will be replacing that type.  
*/
!   TYPE_CACHED_VALUES (t) = TYPE_CACHED_VALUES (bitsizetype);
!   TYPE_CACHED_VALUES_P (t) = TYPE_CACHED_VALUES_P (bitsizetype);
!   TYPE_PRECISION (t) = precision;
!   TYPE_UID (t) = TYPE_UID (bitsizetype);
!   TYPE_IS_SIZETYPE (t) = 1;
! 
!   /* Replace our original stub bitsizetype.  */
!   memcpy (bitsizetype, t, tree_size (bitsizetype));
!   TYPE_MAIN_VARIANT (bitsizetype) = bitsizetype;
!   TYPE_CANONICAL (bitsizetype) = bitsizetype;
! 
!   fixup_unsigned_type (bitsizetype);
  
/* Create the signed variants of *sizetype.  */
!   ssizetype = make_signed_type (oprecision);
TYPE_IS_SIZETYPE (ssizetype) = 1;
!   sbitsizetype = make_signed_type (precision);
TYPE_IS_SIZETYPE (sbitsizetype) = 1;
  }
  
--- 2189,2257 
return type;
  }
  
! /* Initialize sizetypes so layout_type can use them.  */
  
  void
  initialize_sizetypes (void)
  {
!   int precision, bprecision;
  
!   /* Get sizetypes precision from the SIZE_TYPE target macro.  */
!   if (strcmp (SIZE_TYPE, "unsigned int") == 0)
! precision = INT_TYPE_SIZE;
!   else if (strcmp (SIZE_TYPE, "long unsigned int") == 0)
! precision = LONG_TYPE_SIZE;
!   else if (strcmp (SIZE_TYPE, "long long unsigned int") == 0)
! precision = LONG_LONG_TYPE_SIZE;
!   else
! gcc_unreachable ();
! 
!   bprecision
! = MIN (precision + BITS_PER_UNIT_LOG + 1, MAX_FIXED_MODE_SIZE);
!   bprecision
! = GET_MODE_PREC

Re: [Design notes, RFC] Address-lowering prototype design (PR46556)

[Richard Guenther]

On Tue, Jun 7, 2011 at 4:14 PM, William J. Schmidt
 wrote:
>
> On Tue, 2011-06-07 at 12:06 +0200, Richard Guenther wrote:
>> On Mon, Jun 6, 2011 at 8:07 PM, William J. Schmidt
>>  wrote:
>
> 
>
>> >  * If the original expression will be recognized as a "hidden global 
>> > store" in
>> >   tree-ssa-sink.c:is_hidden_global_store, but the replacement expression 
>> > will
>> >   not, it is possible for the dead code eliminator to remove the modified
>> >   statement.  It seems to me this shouldn't normally happen in practice.  
>> > For
>> >   now I detect this case and refuse to do the replacement, but I suspect a
>> >   possible front-end or upstream-optimization problem here.  The test case
>> >   that fails here is libstdc++-v3/testsuite/23_containers/vector/
>> >   ext_pointer_modifiers/insert.cc.  More investigation required.
>>
>> That indeed sounds odd.
>
> When I looked into it, the addressing expression was fairly complex
> initially, with templates and inheritance involved.  The code to create
> the affine tree combination was able to collapse a great deal of the
> arithmetic and produce something much simpler that no longer referenced
> the item that had made it look like a global store originally.  (I.e.,
> buried in the expression were an (&x + a) and a -(&x + a) that cancelled
> out and removed all traces of x.)  It appeared to me that this was being
> done correctly, but it was a very complex expression and I might have
> missed something.
>
> The result was that essentially the entire procedure ended up going
> dead.  It's possible that some information was either lost or not
> provided by the front end that should have prevented that.
>
> 
>
>> > Loss of aliasing information
>> > 
>> > The most serious problem I've run into is degraded performance due to 
>> > poorer
>> > instruction scheduling choices.  I tracked this down to
>> > alias.c:nonoverlapping_component_refs_p.
>> >
>> > This code proves that two memory accesses don't overlap by attempting to 
>> > prove
>> > that they access different fields of the same structure.  This is done 
>> > using
>> > the MEM_EXPRs of the two rtx's, which record the expression trees that were
>> > translated into the rtx's during expand.  When address lowering is not
>> > present, a simple COMPONENT_REF will appear in the MEM_EXPR:  x.a, for
>> > example.  However, address lowering changes the simple COMPONENT_REF into a
>> > [TARGET_]MEM_REF that is no longer necessarily identifiable as a field
>> > reference.  Thus the aliasing machinery can no longer prove that two such
>> > field references are disjoint.
>> >
>> > This has severe consequences for performance, and has to be dealt with if
>> > address lowering is to be successful.
>> >
>> > I've worked around this with an admittedly fragile solution; I'll discuss 
>> > the
>> > drawbacks below.  The idea is to construct a mapping from replacement 
>> > mem_refs
>> > to the original expressions that they replaced.  When a MEM_EXPR is being 
>> > set
>> > during expand, we first look up the mem_ref in the mapping.  If present, 
>> > the
>> > MEM_EXPR is set to the original expression, rather than to the mem_ref.  
>> > This
>> > essentially duplicates the behavior in the absence of address lowering.
>>
>> Ick.  We had this in the past via TMR_ORIGINAL which caused all sorts
>> of problems.  Removing it didn't cause much degradation because we now
>> preserve points-to information.
>>
>> Originally I played with lowering all memory accesses to MEM_REFs
>> (see the old mem-ref branch), and the loss of type-based alias
>> disambiguation was indeed an issue.
>>
>> But - I definitely do not like the idea of preserving something similar
>> to TMR_ORIGINAL.  Instead we can try preserving some information
>> we derive from it.  We keep the original access type that we can use
>> for TBAA but do not retain knowledge on whether the type of the
>> MEM_REF is valid for TBAA or if it is view-converted.
>
> Yes, I really don't like what I have at the moment, either.  I put it in
> place as a stopgap to let me proceed to look for other performance
> problems.
>
> The question is how we can infer useful information for TBAA from the
> MEM_REFs and TMRs.  I poked at trying to identify types and offsets from
> the MEM_EXPRs, but this ended up being useless; I had to constrain too
> many cases to maintain correctness, and couldn't prove the type
> information for the important cases in SPEC I was trying to address.
>
> Unfortunately, the whole design goes down the drain if we can't find a
> way to solve the TBAA issue.  The performance degradations are too
> costly.

If you look at what basic TBAA the alias oracle performs then it boils
down to the fact that get_alias_set for a.b.c might end up using the
alias-set of the type of C but for MEM[&a + 4] it will use the alias set
of the type of a.  The tree alias-oracle extracts both alias sets, that
of the outermost valid type and that of the inn

Re: [PATCH, i386]: Remaining FP moves cleanups

[H.J. Lu]

On Tue, Jun 7, 2011 at 7:12 AM, Uros Bizjak  wrote:
> On Tue, Jun 7, 2011 at 4:07 PM, H.J. Lu  wrote:
>
>>> OTOH, you are right, this statement can be moved to case 6, without
>>> the check for registers.
>>>
>>
>> Like this?  OK for trunk with a ChangeLog entry?
>>
>> Thanks.
>>
>> --
>> H.J.
>> 
>> diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
>> index 58de87b..a61bffb 100644
>> --- a/gcc/config/i386/i386.md
>> +++ b/gcc/config/i386/i386.md
>> @@ -3207,11 +3207,11 @@
>>     case 6:
>>       if (get_attr_mode (insn) == MODE_V4SF)
>>        return "%vmovaps\t{%1, %0|%0, %1}";
>> +      else if (TARGET_AVX && REG_P (operands[0]) && REG_P (operands[1]))
>
> if (TARGET_AVX)
>
>> +       return "vmovss\t{%1, %0, %0|%0, %0, %1}";
>>
>>     case 7:
>>     case 8:
>> -      if (TARGET_AVX && REG_P (operands[0]) && REG_P (operands[1]))
>> -       return "vmovss\t{%1, %0, %0|%0, %0, %1}";
>>       return "%vmovss\t{%1, %0|%0, %1}";
>>
>>     case 9:
>>
>
> OK with this change and suitable ChangeLog entry.
>

This is what I checked in.

Thanks.


-- 
H.J.

2011-06-07  H.J. Lu  

* config/i386/i386.md (*movsf_internal): Optimize AVX check.
diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
index 58de87b..3e18e7a 100644
--- a/gcc/config/i386/i386.md
+++ b/gcc/config/i386/i386.md
@@ -3207,11 +3207,11 @@
 case 6:
   if (get_attr_mode (insn) == MODE_V4SF)
return "%vmovaps\t{%1, %0|%0, %1}";
+  if (TARGET_AVX)
+   return "vmovss\t{%1, %0, %0|%0, %0, %1}";

 case 7:
 case 8:
-  if (TARGET_AVX && REG_P (operands[0]) && REG_P (operands[1]))
-   return "vmovss\t{%1, %0, %0|%0, %0, %1}";
   return "%vmovss\t{%1, %0|%0, %1}";

 case 9:

Re: [build] Move ENABLE_EXECUTE_STACK to toplevel libgcc

[Rainer Orth]

"Joseph S. Myers"  writes:

> On Tue, 31 May 2011, Paolo Bonzini wrote:
>
>> > I'd thought about it, but refrained since HAVE_ENABLE_EXECUTE_STACK
>> > affects only three cpus.  Currently, our documentation of libgcc
>> > configury and macros used is close to non-existant.  That's probably for
>> > someone who has implemented this stuff.
>> 
>> True, OTOH HAVE_ENABLE_EXECUTE_STACK is a target macro, and those are well
>> documented.  Just say that it has to be defined if libgcc provides a
>> non-trivial implementation of __enable_execute_stack; it doesn't need to 
>> delve
>> into how to hack libgcc.
>
> As I understand it, HAVE_ENABLE_EXECUTE_STACK is only used in code under 
> gcc/config/.  That is, it is not a target macro as usually understood but 
> is logically private to a few back ends (and it would be a bug to 
> introduce uses of it elsewhere, just like it was a bug to introduce uses 
> of TARGET_64BIT outside gcc/config/ when that macro also is logically 
> private).

That was my reasoning when originally not including the documenation in
my patch.  So I'll just remove the HAVE_ENABLE_EXECUTE_STACK docs from
my revised patch

http://gcc.gnu.org/ml/gcc-patches/2011-06/msg00366.html

Are you ok with that and the __TRAMPOLINE_SIZE__ definition in
c-cppbuiltin.c (c_cpp_builtins)?

Thanks.
Rainer

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

Re: [build] Remove LIB2ADDEHDEP

[Joseph S. Myers]

On Fri, 3 Jun 2011, Rainer Orth wrote:

> * The gcc/unwind* files and gcc/emutls.c can move, too.

And the other files listed in LIB2ADDEH for various targets, I expect.

arm/libunwind.S
arm/pr-support.c
arm/unwind-arm.c
arm/unwind-arm.h
ia64/fde-vms.c
ia64/unwind-ia64.c
ia64/unwind-ia64.h
rs6000/darwin-fallback.c
xtensa/unwind-dw2-xtensa.c
xtensa/unwind-dw2-xtensa.h

(at least)

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

Re: C++ PATCH for c++/48780 (non-promotion of scoped enums)

[Jason Merrill]

A bug report on IRC pointed out that we were giving the -Wabi warning in 
cases that don't affect the ABI at all, namely use of scoped enums in 
switch.  So this patch limits the warning to the varargs case by 
catching scoped enums in perform_integral_promotions so that only 
callers that use the type_promotes_to hook directly will get the warning.


Tested x86_64-pc-linux-gnu, applied to trunk and 4.6.

commit 7ceaa2bef7e4e9599fc7cd67b58b39736dd35d85
Author: Jason Merrill 
Date:   Mon Jun 6 17:35:18 2011 -0400

	PR c++/48780
	* typeck.c (perform_integral_promotions): Don't promote scoped enums.
	* call.c (convert_arg_to_ellipsis): Promote them here in old ABI.

diff --git a/gcc/cp/call.c b/gcc/cp/call.c
index 246fb6d..7019da9 100644
--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -5724,7 +5724,15 @@ convert_arg_to_ellipsis (tree arg)
   else if (NULLPTR_TYPE_P (arg_type))
 arg = null_pointer_node;
   else if (INTEGRAL_OR_ENUMERATION_TYPE_P (arg_type))
-arg = perform_integral_promotions (arg);
+{
+  if (SCOPED_ENUM_P (arg_type) && !abi_version_at_least (6))
+	{
+	  warning (OPT_Wabi, "scoped enum %qT will not promote to an "
+		   "integral type in a future version of GCC", arg_type);
+	  arg = cp_convert (ENUM_UNDERLYING_TYPE (arg_type), arg);
+	}
+  arg = perform_integral_promotions (arg);
+}
 
   arg = require_complete_type (arg);
   arg_type = TREE_TYPE (arg);
diff --git a/gcc/cp/typeck.c b/gcc/cp/typeck.c
index 2022f0f..6214452 100644
--- a/gcc/cp/typeck.c
+++ b/gcc/cp/typeck.c
@@ -1946,6 +1946,9 @@ perform_integral_promotions (tree expr)
   if (!type || TREE_CODE (type) != ENUMERAL_TYPE)
 type = TREE_TYPE (expr);
   gcc_assert (INTEGRAL_OR_ENUMERATION_TYPE_P (type));
+  /* Scoped enums don't promote.  */
+  if (SCOPED_ENUM_P (type))
+return expr;
   promoted_type = type_promotes_to (type);
   if (type != promoted_type)
 expr = cp_convert (promoted_type, expr);
diff --git a/gcc/testsuite/g++.dg/cpp0x/enum19.C b/gcc/testsuite/g++.dg/cpp0x/enum19.C
new file mode 100644
index 000..acdd86c
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/enum19.C
@@ -0,0 +1,12 @@
+// We shouldn't give an ABI warning about promotion in switch.
+// { dg-options "-std=c++0x -fabi-version=5 -Wabi" }
+
+enum class Foo { X };
+void test(Foo val)
+{
+switch(val)
+{
+case Foo::X:
+break;
+}
+};

Re: [build] Remove LIB2ADDEHDEP

[Rainer Orth]

"Joseph S. Myers"  writes:

> On Fri, 3 Jun 2011, Rainer Orth wrote:
>
>> * The gcc/unwind* files and gcc/emutls.c can move, too.
>
> And the other files listed in LIB2ADDEH for various targets, I expect.
>
> arm/libunwind.S
> arm/pr-support.c
> arm/unwind-arm.c
> arm/unwind-arm.h
> ia64/fde-vms.c
> ia64/unwind-ia64.c
> ia64/unwind-ia64.h
> rs6000/darwin-fallback.c
> xtensa/unwind-dw2-xtensa.c
> xtensa/unwind-dw2-xtensa.h
>
> (at least)

Right, my plan was to move all files only referenced by LIB2ADDEH*.

Does the plan seem ok otherwise?

Rainer

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

Re: [build] Move ENABLE_EXECUTE_STACK to toplevel libgcc

[Joseph S. Myers]

On Mon, 6 Jun 2011, Rainer Orth wrote:

> Paolo Bonzini  writes:
> 
> >> * Except for Darwin, the code uses TRAMPOLINE_SIZE.  This only exists in
> >>the backend headers.  While it could be duplicated somewhere in the
> >>libgcc configury, I'd rather propose that gcc define
> >>__TRAMPOLINE_SIZE__ (in gcc/c-family/c-cppbuiltin.c (c_cpp_builtins)
> >>to avoid this.  On PowerPC Darwin, one cannot use TRAMPOLINE_SIZE
> >>definition right now since the macro calls the rs6000_trampoline_size
> >>function in rs6000/rs6000.c.  This would be solved nicely by
> >>__TRAMPOLINE_SIZE__.
> >
> > Good idea.
> 
> Included in the revised patch below.  This part will need Joseph's approval.

Is this definition ever going to be of use to user code, or even to system 
headers?  It looks purely like an implementation detail rather than 
something meaningful for users.  That would tend to suggest conditioning 
it on the proposed new -fbuilding-libgcc option that I suggested in 
.  (There are a 
*lot* of target macros that are in a similar position - see the list under 
"used by the compiler itself and libgcc" in 
.  Even if we could 
define and document public semantics for corresponding predefined macros, 
I don't think they would be of practical use to users of GCC, so for most 
of them I expect defining __LIBGCC_, only if -fbuilding-libgcc, is 
the best way of eliminating the dependence on host tm.h without making 
implementation details visible to users of GCC.)

So my view is that you should define __LIBGCC_TRAMPOLINE_SIZE__, only if 
-fbuilding-libgcc.

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

Re: [build] Move ENABLE_EXECUTE_STACK to toplevel libgcc

[Rainer Orth]

"Joseph S. Myers"  writes:

> On Mon, 6 Jun 2011, Rainer Orth wrote:
>
>> Paolo Bonzini  writes:
>> 
>> >> * Except for Darwin, the code uses TRAMPOLINE_SIZE.  This only exists in
>> >>the backend headers.  While it could be duplicated somewhere in the
>> >>libgcc configury, I'd rather propose that gcc define
>> >>__TRAMPOLINE_SIZE__ (in gcc/c-family/c-cppbuiltin.c (c_cpp_builtins)
>> >>to avoid this.  On PowerPC Darwin, one cannot use TRAMPOLINE_SIZE
>> >>definition right now since the macro calls the rs6000_trampoline_size
>> >>function in rs6000/rs6000.c.  This would be solved nicely by
>> >>__TRAMPOLINE_SIZE__.
>> >
>> > Good idea.
>> 
>> Included in the revised patch below.  This part will need Joseph's approval.
>
> Is this definition ever going to be of use to user code, or even to system 
> headers?  It looks purely like an implementation detail rather than 
> something meaningful for users.  That would tend to suggest conditioning 
> it on the proposed new -fbuilding-libgcc option that I suggested in 
> .  (There are a 
> *lot* of target macros that are in a similar position - see the list under 
> "used by the compiler itself and libgcc" in 
> .  Even if we could 
> define and document public semantics for corresponding predefined macros, 
> I don't think they would be of practical use to users of GCC, so for most 
> of them I expect defining __LIBGCC_, only if -fbuilding-libgcc, is 
> the best way of eliminating the dependence on host tm.h without making 
> implementation details visible to users of GCC.)
>
> So my view is that you should define __LIBGCC_TRAMPOLINE_SIZE__, only if 
> -fbuilding-libgcc.

I can give it a try if I can figure out how to define -fbuilding-libgcc
via the option handling machinery.  I just want to avoid having to
implement too many unrelated cleanups, otherwise it will take a year to
get this single patch done.

Rainer

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

Re: [build] Move ENABLE_EXECUTE_STACK to toplevel libgcc

[Paolo Bonzini]

On 06/07/2011 05:30 PM, Rainer Orth wrote:

>  So my view is that you should define __LIBGCC_TRAMPOLINE_SIZE__, only if
>  -fbuilding-libgcc.

I can give it a try if I can figure out how to define -fbuilding-libgcc
via the option handling machinery.  I just want to avoid having to
implement too many unrelated cleanups, otherwise it will take a year to
get this single patch done.


Agreed, what about just renaming the macro to __LIBGCC_TRAMPOLINE_SIZE__ 
for now?  I don't think it's fair to put on Rainer the burden of 
implementing the new flag right now.


If no one beats me to it, I'll look at it when coming back from holidays 
in two weeks.


Paolo

Re: PATCH [1/n]: Add initial -x32 support

[Joseph S. Myers]

On Sun, 5 Jun 2011, H.J. Lu wrote:

>   * config.gcc: Support --enable-x32/--enable-ia32 for x86 Linux
>   targets.
> 
>   * configure.ac: Support --enable-x32/--enable-ia32.
>   * configure: Regenerated.

New configure options need documenting in install.texi.

>  #undef ASM_SPEC
> -#define ASM_SPEC "%{" SPEC_32 ":--32} %{" SPEC_64 ":--64} \
> +#define ASM_SPEC "%{" SPEC_32 ":%{!mx32:--32}} %{" \
> + SPEC_64 ":%{!mx32:--64}} %{mx32:--x32} \
>   %{!mno-sse2avx:%{mavx:-msse2avx}} %{msse2avx:%{!mavx:-msse2avx}}"

This looks wrong.  You should define SPEC_32, SPEC_64 and SPEC_X32 to be 
the three mutually exclusive cases, then use those three here and in other 
specs without any nesting.

>  Generate code for a 32-bit or 64-bit environment.
> -The 32-bit environment sets int, long and pointer to 32 bits and
> +The -m32 option sets int, long and pointer to 32 bits and

@option{-m32}.  Likewise later in this paragraph for various option names.

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

Re: PATCH [1/n]: Add initial -x32 support

[Joseph S. Myers]

An additional comment on the specs: OPTION_DEFAULT_SPECS needs updating 
(-mx32 should use the --with-arch-64 etc. settings).

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

Re: Patch: aesthetics for gcc/cp/cxx-pretty-print.c

[Paolo Bonzini]

On 06/06/2011 04:17 AM, Bruce Korb wrote:

It also caused a code analysis tool to wander off into the weeds.


And "x, break;" didn't? :)

(First time I see it, I swear).

Paolo

[v3] Use move_if_noexcept in std::vector

[Paolo Carlini]

Hi,

the below starts using it, for correctness wrt move constructors which 
can throw. For sure we are missing the optimization which uses the 
default-constructor + swap when the type isn't nothrow move 
constructible, per Note 5 in n3050, for example.


Tested x86_64-linux, committed.

Paolo.

/
2011-06-07  Paolo Carlini  

* include/bits/move.h (struct __move_if_noexcept_cond): Add.
(move_if_noexcept): Use the latter.
* include/bits/stl_iterator.h (__make_move_if_noexcept_iterator,
_GLIBCXX_MAKE_MOVE_IF_NOEXCEPT_ITERATOR): Add.
* include/bits/stl_uninitialized.h
(__uninitialized_move_if_noexcept_a): Add.
* include/bits/vector.tcc (vector<>::reserve): Use
_GLIBCXX_MAKE_MOVE_IF_NOEXCEPT_ITERATOR.
(vector<>::_M_insert_aux, _M_fill_insert, _M_default_append,
_M_range_insert): Use __uninitialized_move_if_noexcept_a.
* testsuite/util/testsuite_rvalref.h (throwing_move_constructor):
Add.
(copycounter::copycounter(copycounter&&)): Use noexcept.
* testsuite/23_containers/vector/modifiers/moveable2.cc: New.
* testsuite/23_containers/vector/capacity/resize/moveable2.cc:
Likewise.
* testsuite/23_containers/vector/capacity/reserve/moveable2.cc:
Likewise.
Index: include/bits/move.h
===
--- include/bits/move.h (revision 174739)
+++ include/bits/move.h (working copy)
@@ -82,6 +82,12 @@
 move(_Tp&& __t) noexcept
 { return static_cast::type&&>(__t); }
 
+
+  template
+struct __move_if_noexcept_cond
+: public __and_<__not_>,
+is_copy_constructible<_Tp>>::type { };
+
   /**
*  @brief Move unless it could throw and the type is copyable.
*  @ingroup utilities
@@ -90,9 +96,7 @@
*/
   template
 inline typename
-conditional<__and_<__not_>,
-   is_copy_constructible<_Tp>>::value,
-const _Tp&, _Tp&&>::type
+conditional<__move_if_noexcept_cond<_Tp>::value, const _Tp&, _Tp&&>::type
 move_if_noexcept(_Tp& __x) noexcept
 { return std::move(__x); }
 
Index: include/bits/stl_uninitialized.h
===
--- include/bits/stl_uninitialized.h(revision 174739)
+++ include/bits/stl_uninitialized.h(working copy)
@@ -269,6 +269,19 @@
 __result, __alloc);
 }
 
+  template
+inline _ForwardIterator
+__uninitialized_move_if_noexcept_a(_InputIterator __first,
+  _InputIterator __last,
+  _ForwardIterator __result,
+  _Allocator& __alloc)
+{
+  return std::__uninitialized_copy_a
+   (_GLIBCXX_MAKE_MOVE_IF_NOEXCEPT_ITERATOR(__first),
+_GLIBCXX_MAKE_MOVE_IF_NOEXCEPT_ITERATOR(__last), __result, __alloc);
+}
+
   template
 void
 __uninitialized_fill_a(_ForwardIterator __first, _ForwardIterator __last,
Index: include/bits/stl_iterator.h
===
--- include/bits/stl_iterator.h (revision 174739)
+++ include/bits/stl_iterator.h (working copy)
@@ -1118,14 +1118,25 @@
 make_move_iterator(const _Iterator& __i)
 { return move_iterator<_Iterator>(__i); }
 
+  template::value_type>::value,
+_Iterator, move_iterator<_Iterator>>::type>
+inline _ReturnType
+__make_move_if_noexcept_iterator(_Iterator __i)
+{ return _ReturnType(__i); }
+
   // @} group iterators
 
 _GLIBCXX_END_NAMESPACE_VERSION
 } // namespace
 
 #define _GLIBCXX_MAKE_MOVE_ITERATOR(_Iter) std::make_move_iterator(_Iter)
+#define _GLIBCXX_MAKE_MOVE_IF_NOEXCEPT_ITERATOR(_Iter) \
+  std::__make_move_if_noexcept_iterator(_Iter)
 #else
 #define _GLIBCXX_MAKE_MOVE_ITERATOR(_Iter) (_Iter)
+#define _GLIBCXX_MAKE_MOVE_IF_NOEXCEPT_ITERATOR(_Iter) (_Iter)
 #endif // __GXX_EXPERIMENTAL_CXX0X__
 
 #endif
Index: include/bits/vector.tcc
===
--- include/bits/vector.tcc (revision 174739)
+++ include/bits/vector.tcc (working copy)
@@ -72,8 +72,8 @@
{
  const size_type __old_size = size();
  pointer __tmp = _M_allocate_and_copy(__n,
-_GLIBCXX_MAKE_MOVE_ITERATOR(this->_M_impl._M_start),
-_GLIBCXX_MAKE_MOVE_ITERATOR(this->_M_impl._M_finish));
+   _GLIBCXX_MAKE_MOVE_IF_NOEXCEPT_ITERATOR(this->_M_impl._M_start),
+   _GLIBCXX_MAKE_MOVE_IF_NOEXCEPT_ITERATOR(this->_M_impl._M_finish));
  std::_Destroy(this->_M_impl._M_start, this->_M_impl._M_finish,
_M_get_Tp_allocator());
  _M_deallocate(this->_M_impl._M_start,
@@ -337,17 +337,17 @@
 #endif
  __new_finish = 0;
 
- __new_finish =
-   std::__uninitialized_move_a(this->_M_impl._M_start,
-   

Re: Dump before flag

[Xinliang David Li]

On Tue, Jun 7, 2011 at 2:36 AM, Richard Guenther
 wrote:
> On Mon, Jun 6, 2011 at 6:20 PM, Xinliang David Li  wrote:
>>>
>>> Your patch doesn't really improve this but adds to the confusion.
>>>
>>> +  /* Override dump TODOs.  */
>>> +  if (dump_file && (pass->todo_flags_finish & TODO_dump_func)
>>> +      && (dump_flags & TDF_BEFORE))
>>> +    {
>>> +      pass->todo_flags_finish &= ~TODO_dump_func;
>>> +      pass->todo_flags_start |= TODO_dump_func;
>>> +    }
>>>
>>> and certainly writing to pass is not ok.  And the TDF_BEFORE flag
>>> looks misplaced as it controls TODOs, not dumping behavior.
>>> Yes, it's a mess right now but the above looks like a hack ontop
>>> of that mess (maybe because of it, but well ...).
>>>
>>
>> How about removing dumping TODO completely -- this can be done easily
>> -- I don't understand why pass wants extra control on the dumping if
>> user already asked for dumping -- it is annoying to see empty IR dump
>> for a pass when I want to see it.
>>
>>> At least I would have expected to also get the dump after the
>>> pass, not only the one before it with this dump flag.
>>>
>>> Now, why can't you look at the previous pass output for the
>>> before-dump (as I do usually)?
>>
>> For one thing, you need to either remember what is the previous pass,
>> or dump all passes which for large files can take very long time. Even
>> with all the dumps, you will need to eyeballing to find the previous
>> pass which may or may not have the IR dumped.
>>
>> How about removing dump TODO?
>
> Yeah, I think this would go in the right direction.  Currently some passes
> do not dump function bodies because they presumably do no IL
> modification.  But this is certainly the minority (and some passes do not
> dump bodies even though they are modifying the IL ...).
>
> So I'd say we should by default dump function bodies.
>
> Note that there are three useful dumping positions (maybe four),
> before todo-start, after todo-start, before todo-finish and after todo-finish.
> By default we'd want after todo-finish.  When we no longer dump via
> a TODO then we could indeed use dump-flags to control this
> (maybe -original for the body before todo-start).
>
> What to others think?

I think  that is a very good thing to have.

David


>
> Richard.
>
>> Thanks,
>>
>> David
>>
>>
>>>
>>> Richard.
>>>
>>
>

[PATCH] Better propagation of flags in access trees of SRA

[Martin Jambor]

Hi,

the way we propagate flags in SRA access tree has evolved in an
unfortunate way, this patch simplifies the whole thing while doing
exactly the same thing.

Bootstrapped and tested on x86_64-linux, OK for trunk?

Thanks,

Martin



2011-06-06  Martin Jambor  

* tree-sra.c (mark_rw_status): Removed.
(analyze_access_subtree): New parameter parent instead of
mark_read and mark_write, propagate from that.

Index: src/gcc/tree-sra.c
===
*** src.orig/gcc/tree-sra.c
--- src/gcc/tree-sra.c
*** expr_with_var_bounded_array_refs_p (tree
*** 1864,1871 
return false;
  }
  
- enum mark_rw_status { SRA_MRRW_NOTHING, SRA_MRRW_DIRECT, SRA_MRRW_ASSIGN};
- 
  /* Analyze the subtree of accesses rooted in ROOT, scheduling replacements 
when
 both seeming beneficial and when ALLOW_REPLACEMENTS allows it.  Also set 
all
 sorts of access flags appropriately along the way, notably always set
--- 1864,1869 
*** enum mark_rw_status { SRA_MRRW_NOTHING,
*** 1905,1913 
 1  1   1   1   Yes Any of the above yeses  */
  
  static bool
! analyze_access_subtree (struct access *root, bool allow_replacements,
!   enum mark_rw_status mark_read,
!   enum mark_rw_status mark_write)
  {
struct access *child;
HOST_WIDE_INT limit = root->offset + root->size;
--- 1903,1910 
 1  1   1   1   Yes Any of the above yeses  */
  
  static bool
! analyze_access_subtree (struct access *root, struct access *parent,
!   bool allow_replacements)
  {
struct access *child;
HOST_WIDE_INT limit = root->offset + root->size;
*** analyze_access_subtree (struct access *r
*** 1915,1943 
bool scalar = is_gimple_reg_type (root->type);
bool hole = false, sth_created = false;
  
!   if (root->grp_assignment_read)
! mark_read = SRA_MRRW_ASSIGN;
!   else if (mark_read == SRA_MRRW_ASSIGN)
! {
!   root->grp_read = 1;
!   root->grp_assignment_read = 1;
! }
!   else if (mark_read == SRA_MRRW_DIRECT)
! root->grp_read = 1;
!   else if (root->grp_read)
! mark_read = SRA_MRRW_DIRECT;
! 
!   if (root->grp_assignment_write)
! mark_write = SRA_MRRW_ASSIGN;
!   else if (mark_write == SRA_MRRW_ASSIGN)
  {
!   root->grp_write = 1;
!   root->grp_assignment_write = 1;
  }
-   else if (mark_write == SRA_MRRW_DIRECT)
- root->grp_write = 1;
-   else if (root->grp_write)
- mark_write = SRA_MRRW_DIRECT;
  
if (root->grp_unscalarizable_region)
  allow_replacements = false;
--- 1912,1928 
bool scalar = is_gimple_reg_type (root->type);
bool hole = false, sth_created = false;
  
!   if (parent)
  {
!   if (parent->grp_read)
!   root->grp_read = 1;
!   if (parent->grp_assignment_read)
!   root->grp_assignment_read = 1;
!   if (parent->grp_write)
!   root->grp_write = 1;
!   if (parent->grp_assignment_write)
!   root->grp_assignment_write = 1;
  }
  
if (root->grp_unscalarizable_region)
  allow_replacements = false;
*** analyze_access_subtree (struct access *r
*** 1952,1960 
else
covered_to += child->size;
  
!   sth_created |= analyze_access_subtree (child,
!allow_replacements && !scalar,
!mark_read, mark_write);
  
root->grp_unscalarized_data |= child->grp_unscalarized_data;
hole |= !child->grp_covered;
--- 1937,1944 
else
covered_to += child->size;
  
!   sth_created |= analyze_access_subtree (child, root,
!allow_replacements && !scalar);
  
root->grp_unscalarized_data |= child->grp_unscalarized_data;
hole |= !child->grp_covered;
*** analyze_access_trees (struct access *acc
*** 2002,2009 
  
while (access)
  {
!   if (analyze_access_subtree (access, true,
! SRA_MRRW_NOTHING, SRA_MRRW_NOTHING))
ret = true;
access = access->next_grp;
  }
--- 1986,1992 
  
while (access)
  {
!   if (analyze_access_subtree (access, NULL, true))
ret = true;
access = access->next_grp;
  }

Re: -fdump-passes -fenable-xxx=func_name_list

[Xinliang David Li]

Ok -- that sounds good.

David

On Tue, Jun 7, 2011 at 3:10 AM, Richard Guenther
 wrote:
> On Mon, Jun 6, 2011 at 6:00 PM, Xinliang David Li  wrote:
>> On Mon, Jun 6, 2011 at 4:38 AM, Richard Guenther
>>  wrote:
>>> On Thu, Jun 2, 2011 at 9:12 AM, Xinliang David Li  
>>> wrote:
 This is the version of the patch that walks through pass lists.

 Ok with this one?
>>>
>>> +/* Dump all optimization passes.  */
>>> +
>>> +void
>>> +dump_passes (void)
>>> +{
>>> +  struct cgraph_node *n, *node = NULL;
>>> +  tree save_fndecl = current_function_decl;
>>> +
>>> +  fprintf (stderr, "MAX_UID = %d\n", cgraph_max_uid);
>>>
>>> this isn't accurate info - cloning can cause more cgraph nodes to
>>> appear (it also looks completely unrelated to dump_passes ...).
>>> Please drop it.
>>
>> Ok.
>>
>>
>>>
>>> +  create_pass_tab();
>>> +  gcc_assert (pass_tab);
>>>
>>> you have quite many asserts of this kind - we don't want them when
>>> the previous stmt as in this case indicates everything is ok.
>>
>> ok.
>>
>>>
>>> +  push_cfun (DECL_STRUCT_FUNCTION (node->decl));
>>>
>>> this has side-effects, I'm not sure we want this here.  Why do you
>>> need it?  Probably because of
>>>
>>> +  is_really_on = override_gate_status (pass, current_function_decl, is_on);
>>>
>>> ?  But that is dependent on the function given which should have no
>>> effect (unless it is overridden globally in which case override_gate_status
>>> and friends should deal with a NULL cfun).
>>
>> As we discussed, currently some pass gate functions depend on per node
>> information -- those checks need to be pushed into execute functions.
>> I would like to clean those up later -- at which time, the push/pop
>> can be removed.
>
> I'd like to do it the other way around, first clean up the gate functions then
> drop in this patch without the cfun push/pop.  The revised patch looks ok
> to me with the cfun push/pop removed.
>
> Thanks,
> Richard.
>
>>>
>>> I don't understand why you need another table mapping pass to name
>>> when pass->name is available and the info is trivially re-constructible.
>>
>> This is needed as the pass->name is not the canonicalized name (i.e.,
>> not with number suffix etc), so the extra mapping from id to
>> normalized name is needed.
>>
>> Thanks,
>>
>> David
>>
>>>
>>> Thanks,
>>> Richard.
>>>
 David

 On Wed, Jun 1, 2011 at 12:45 PM, Xinliang David Li  
 wrote:
> On Wed, Jun 1, 2011 at 12:29 PM, Richard Guenther
>  wrote:
>> On Wed, Jun 1, 2011 at 6:16 PM, Xinliang David Li  
>> wrote:
>>> On Wed, Jun 1, 2011 at 1:51 AM, Richard Guenther
>>>  wrote:
 On Wed, Jun 1, 2011 at 1:34 AM, Xinliang David Li  
 wrote:
> The following patch implements the a new option that dumps gcc PASS
> configuration. The sample output is attached.  There is one
> limitation: some placeholder passes that are named with '*xxx' are
> note registered thus they are not listed. They are not important as
> they can not be turned on/off anyway.
>
> The patch also enhanced -fenable-xxx and -fdisable-xx to allow a list
> of function assembler names to be specified.
>
> Ok for trunk?

 Please split the patch.

 I'm not too happy how you dump the pass configuration.  Why not simply,
 at a _single_ place, walk the pass tree?  Instead of doing pieces of it
 at pass execution time when it's not already dumped - that really looks
 gross.
>>>
>>> Yes, that was the original plan -- but it has problems
>>> 1) the dumper needs to know the root pass lists -- which can change
>>> frequently -- it can be a long term maintanance burden;
>>> 2) the centralized dumper needs to be done after option processing
>>> 3) not sure if gate functions have any side effects or have 
>>> dependencies on cfun
>>>
>>> The proposed solutions IMHO is not that intrusive -- just three hooks
>>> to do the dumping and tracking indentation.
>>
>> Well, if you have a CU that is empty or optimized to nothing at some 
>> point
>> you will not get a complete pass list.  I suppose optimize attributes 
>> might
>> also confuse output.  Your solution might not be that intrusive
>> but it is still ugly.  I don't see 1) as an issue, for 2) you can just 
>> call the
>> dumping from toplev_main before calling do_compile (), 3) gate functions
>> shouldn't have side-effects, but as they could gate on 
>> optimize_for_speed ()
>> your option summary output will be bogus anyway.
>>
>> So - what is the output intended for if it isn't reliable?
>
> This needs to be cleaned up at some point -- the gate function should
> behave the same for all functions and per-function decisions need to
> be pushed down to the executor body.  I will try to rework the patch
> as you suggested to see if there are proble

Re: Dump before flag

[Diego Novillo]

On Tue, Jun 7, 2011 at 02:36, Richard Guenther
 wrote:

>> For one thing, you need to either remember what is the previous pass,
>> or dump all passes which for large files can take very long time. Even
>> with all the dumps, you will need to eyeballing to find the previous
>> pass which may or may not have the IR dumped.
>>
>> How about removing dump TODO?
>
> Yeah, I think this would go in the right direction.

Agreed.


Diego.

Re: [testsuite] Run TLS torture tests with -fpic etc.

[Rainer Orth]

Jakub,

any word on this patch?   I think I only need approval for the gcc.c
part.

Thanks.
Rainer


Rainer Orth  writes:

> Jakub Jelinek  writes:
>
>> On Fri, Jun 03, 2011 at 09:38:31PM +0200, Rainer Orth wrote:
>>> Rainer Orth  writes:
>>> Jakub, any suggestion how to properly test for -fpie/-fPIE support?
>>> Otherwise, I'll remove that part of the patch for now and just commit
>>> the -fpic/-fPIC one.
>>
>> You want to compile/link the program with -pie -fpie rather than just -fpie,
>> if it links, otherwise you are testing just linking PIC code into normal
>> executables.
>
> Ok, thanks.  Unfortunately, this didn't work out of the box since for
> targets where the linker doesn't support -pie, gcc silently ignores it
> which I think is bad style.
>
> The following patch corrects this by rejecting -pie in this case.  I've
> also added a effective-target keyword pie for testsuite use, both below
> and in the revised TLS torture tests to be submitted separately.
>
> I didn't introduce a separte fpie keyword since e.g. gcc.dg/tls/pie-1.c
> uses fpic for that purpose, but maybe I should?
>
> One other question: gcc.target/i386/pr39013-[12].c is currently
> restricted to *-*-linux*.  Any particular reason for that?
>
> Bootstrapped without regressions on i386-pc-solaris2.11 with Sun ld (no
> -pie support, pie-link becomes UNSUPPORTED) and with GNU ld 2.21 (-pie
> support, 32-bit pie-link works, 64-bit pie-link becomes unsupported:
>
> /vol/gcc/bin/gld-2.21: /usr/lib/amd64/crt1.o: relocation R_X86_64_32S against 
> `_DYNAMIC' can not be used when making a shared object; recompile with -fPIC
> /usr/lib/amd64/crt1.o: could not read symbols: Bad value
>
> ).  Ok for mainline?
>
> Thanks.
> Rainer
>
>
> 2011-06-04  Rainer Orth  
>
>   gcc:
>   * gcc.c [!HAVE_LD_PIE] (LINK_PIE_SPEC): Reject -pie.
>   * doc/sourcebuild.texi (Effective-Target Keywords, pie): Document it.
>
>   gcc/testsuite:
>   * lib/target-supports.exp (check_effective_target_pie): New proc.
>   * gcc.dg/pie-link.c: Use target pie.
>   Add -pie to dg-options.
>
> diff --git a/gcc/doc/sourcebuild.texi b/gcc/doc/sourcebuild.texi
> --- a/gcc/doc/sourcebuild.texi
> +++ b/gcc/doc/sourcebuild.texi
> @@ -1782,6 +1782,9 @@ Target defines @code{PCC_BITFIELD_TYPE_M
>  @item pe_aligned_commons
>  Target supports @option{-mpe-aligned-commons}.
>  
> +@item pie
> +Target supports @option{-pie}, @option{-fpie} and @option{-fPIE}.
> +
>  @item section_anchors
>  Target supports section anchors.
>  
> diff --git a/gcc/gcc.c b/gcc/gcc.c
> --- a/gcc/gcc.c
> +++ b/gcc/gcc.c
> @@ -612,7 +612,7 @@ proper position among the other output f
>  #ifdef HAVE_LD_PIE
>  #define LINK_PIE_SPEC "%{pie:-pie} "
>  #else
> -#define LINK_PIE_SPEC "%{pie:} "
> +#define LINK_PIE_SPEC "%{pie:%e-pie is not supported in this configuration} "
>  #endif
>  #endif
>  
> diff --git a/gcc/testsuite/gcc.dg/pie-link.c b/gcc/testsuite/gcc.dg/pie-link.c
> --- a/gcc/testsuite/gcc.dg/pie-link.c
> +++ b/gcc/testsuite/gcc.dg/pie-link.c
> @@ -1,5 +1,5 @@
> -/* { dg-do link { target *-*-darwin[912]* *-*-linux* } } */
> -/* { dg-options "-fpie" } */
> +/* { dg-do link { target pie } } */
> +/* { dg-options "-pie -fpie" } */
>  
>  int main(void)
>  {
> diff --git a/gcc/testsuite/lib/target-supports.exp 
> b/gcc/testsuite/lib/target-supports.exp
> --- a/gcc/testsuite/lib/target-supports.exp
> +++ b/gcc/testsuite/lib/target-supports.exp
> @@ -788,6 +788,18 @@ proc check_effective_target_fpic { } {
>  return 0
>  }
>  
> +# Return 1 if -pie, -fpie and -fPIE are supported, as in no warnings or 
> errors
> +# emitted, 0 otherwise.
> +
> +proc check_effective_target_pie { } {
> +if [check_no_compiler_messages pie executable {
> + int main (void) { return 0; }
> +} "-pie -fpie"] {
> + return 1
> +}
> +return 0
> +}
> +
>  # Return true if the target supports -mpaired-single (as used on MIPS).
>  
>  proc check_effective_target_mpaired_single { } {

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

Re: Dump before flag

[Xinliang David Li]

Any suggestions on the dump position specification string, before and
after is not enough. How about

start, before, after, and finish?

I.e.

-fdump-tree-pre-start --> dump IR before TODO_start of PRE pass
-fdump-tree-pre-before --> dump IR just before PRE after its TODO start finishes
-fdump-tree-pre-after --> dump IR just after PRE
-fdump-tree-pre-finish --> dump it after TODO_finish of PRE?

Thanks,

David


On Tue, Jun 7, 2011 at 9:43 AM, Diego Novillo  wrote:
> On Tue, Jun 7, 2011 at 02:36, Richard Guenther
>  wrote:
>
>>> For one thing, you need to either remember what is the previous pass,
>>> or dump all passes which for large files can take very long time. Even
>>> with all the dumps, you will need to eyeballing to find the previous
>>> pass which may or may not have the IR dumped.
>>>
>>> How about removing dump TODO?
>>
>> Yeah, I think this would go in the right direction.
>
> Agreed.
>
>
> Diego.
>

Re: [testsuite] Run TLS torture tests with -fpic etc.

[Jakub Jelinek]

On Tue, Jun 07, 2011 at 06:48:08PM +0200, Rainer Orth wrote:
> any word on this patch?   I think I only need approval for the gcc.c

I'm not a maintainer of gcc.c, and I think it is a bad idea.
PIE is just a (slightly) more secure form of an executable, therefore
if a target doesn't support position independent executables, linking
it as normal executable is IMHO just fine.

Jakub

Re: [testsuite] Run TLS torture tests with -fpic etc.

[Rainer Orth]

Jakub Jelinek  writes:

> On Tue, Jun 07, 2011 at 06:48:08PM +0200, Rainer Orth wrote:
>> any word on this patch?   I think I only need approval for the gcc.c
>
> I'm not a maintainer of gcc.c, and I think it is a bad idea.
> PIE is just a (slightly) more secure form of an executable, therefore
> if a target doesn't support position independent executables, linking
> it as normal executable is IMHO just fine.

I don't think so: silently ignoring a user-provided option seems like a
bad idea to me.  At the very least, there should be a warning.

Rainer

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

Re: Dump before flag

[Diego Novillo]

On Tue, Jun 7, 2011 at 09:51, Xinliang David Li  wrote:
> Any suggestions on the dump position specification string, before and
> after is not enough. How about
>
> start, before, after, and finish?
>
> I.e.
>
> -fdump-tree-pre-start --> dump IR before TODO_start of PRE pass
> -fdump-tree-pre-before --> dump IR just before PRE after its TODO start 
> finishes

What would be the difference between these two?  The TODO_start
actions don't affect the IL, in general.

> -fdump-tree-pre-after --> dump IR just after PRE
> -fdump-tree-pre-finish --> dump it after TODO_finish of PRE?

This would be to catch changes like cfg cleanup and SSA update
actions, right?  Sure.

I don't mind too much about the naming.  Anything that makes sense is
good with me.


Diego.

Re: Dump before flag

[Xinliang David Li]

On Tue, Jun 7, 2011 at 10:01 AM, Diego Novillo  wrote:
> On Tue, Jun 7, 2011 at 09:51, Xinliang David Li  wrote:
>> Any suggestions on the dump position specification string, before and
>> after is not enough. How about
>>
>> start, before, after, and finish?
>>
>> I.e.
>>
>> -fdump-tree-pre-start --> dump IR before TODO_start of PRE pass
>> -fdump-tree-pre-before --> dump IR just before PRE after its TODO start 
>> finishes
>
> What would be the difference between these two?  The TODO_start
> actions don't affect the IL, in general.

But by design, it can right?

David

>
>> -fdump-tree-pre-after --> dump IR just after PRE
>> -fdump-tree-pre-finish --> dump it after TODO_finish of PRE?
>
> This would be to catch changes like cfg cleanup and SSA update
> actions, right?  Sure.
>
> I don't mind too much about the naming.  Anything that makes sense is
> good with me.
>
>
> Diego.
>

Re: Ping: Re: Improve DSE in the presence of calls

[Easwaran Raman]

Ping.

Diego, David,
 Is this patch OK for google/main?

-Easwaran

On Thu, Jun 2, 2011 at 4:48 PM, Easwaran Raman  wrote:
> Ping.
>
> On Sat, May 14, 2011 at 8:01 AM, Easwaran Raman  wrote:
>> http://gcc.gnu.org/ml/gcc-patches/2011-05/msg00781.html
>>
>

Re: Ping: Re: Improve DSE in the presence of calls

[Xinliang David Li]

On Tue, Jun 7, 2011 at 10:11 AM, Easwaran Raman  wrote:
> Ping.
>
> Diego, David,
>  Is this patch OK for google/main?

Yes -- but I would like to see it in trunk too if possible -- both
llvm and icc do very good job in these cases.

Thanks,

David

>
> -Easwaran
>
> On Thu, Jun 2, 2011 at 4:48 PM, Easwaran Raman  wrote:
>> Ping.
>>
>> On Sat, May 14, 2011 at 8:01 AM, Easwaran Raman  wrote:
>>> http://gcc.gnu.org/ml/gcc-patches/2011-05/msg00781.html
>>>
>>
>

Re: Dump before flag

[Diego Novillo]

On Tue, Jun 7, 2011 at 10:06, Xinliang David Li  wrote:
> On Tue, Jun 7, 2011 at 10:01 AM, Diego Novillo  wrote:
>> On Tue, Jun 7, 2011 at 09:51, Xinliang David Li  wrote:
>>> Any suggestions on the dump position specification string, before and
>>> after is not enough. How about
>>>
>>> start, before, after, and finish?
>>>
>>> I.e.
>>>
>>> -fdump-tree-pre-start --> dump IR before TODO_start of PRE pass
>>> -fdump-tree-pre-before --> dump IR just before PRE after its TODO start 
>>> finishes
>>
>> What would be the difference between these two?  The TODO_start
>> actions don't affect the IL, in general.
>
> But by design, it can right?

Hmm, now that I think of it, yes it can.  There are some TODOs that
may modify the IL.  For instance, in PRE we split or critical edges
before the pass starts (I think we still do, not sure).


Diego.

Re: Initialize INSN_COND

[Alexander Monakov]

On Fri, 3 Jun 2011, Bernd Schmidt wrote:

> >> Ok. Although I wonder how sel-sched can end up reusing an entry in
> >> h_d_i_d?

Unlike Haifa scheduler, we recompute INSN_LUIDs for each region.  However, we
call sched_deps_{init,finish} once per function (like Haifa) and that makes us
reuse entries in h_d_i_d.

The proposed patch clears h_d_i_d when finishing a region in sel-sched.
Bootstrapped and regtested on ia64-linux, OK for trunk?  I also verified that
HPUX failure mentioned by Steve is fixed on a cross-compiler.

> >> How does it use this machinery? If it's not doing a normal
> >> forward scan as in sched_analyze, the INSN_COND mechanism may break in
> >> other ways.

Normal forward scan is only done to compute insn priorities; now, it will also
reset INSN_CONDs for instructions followed by an assignment to their
predicate (for exposed-pipeline targets). After that, sel-sched's dependency
analysis will treat such instructions as if they had no predicate, which is
very conservative.  Unfortunately, correctness still may be broken after a
predicate assignment is moved into a different BB (or copied to one as a
bookkeeping copy).  I'll try to think of a way to fix it when preparing the
predication patch.


2011-06-07  Alexander Monakov  

* sel-sched.c (move_op): Use correct type for 'res'.  Verify that
code_motion_path_driver returned 0 or 1.
(sel_region_finish): Clear h_d_i_d.

diff --git a/gcc/sel-sched.c b/gcc/sel-sched.c
index 3f22a3c..8a39d80 100644
--- a/gcc/sel-sched.c
+++ b/gcc/sel-sched.c
@@ -6675,7 +6675,7 @@ move_op (insn_t insn, av_set_t orig_ops, expr_t expr_vliw,
 {
   struct moveop_static_params sparams;
   struct cmpd_local_params lparams;
-  bool res;
+  int res;
 
   /* Init params for code_motion_path_driver.  */
   sparams.dest = dest;
@@ -6694,6 +6694,8 @@ move_op (insn_t insn, av_set_t orig_ops, expr_t expr_vliw,
   code_motion_path_driver_info = &move_op_hooks;
   res = code_motion_path_driver (insn, orig_ops, NULL, &lparams, &sparams);
 
+  gcc_assert (res != -1);
+
   if (sparams.was_renamed)
 EXPR_WAS_RENAMED (expr_vliw) = true;
 
@@ -7269,6 +7271,7 @@ sel_region_finish (bool reset_sched_cycles_p)
 
   finish_deps_global ();
   sched_finish_luids ();
+  VEC_free (haifa_deps_insn_data_def, heap, h_d_i_d);
 
   sel_finish_bbs ();
   BITMAP_FREE (blocks_to_reschedule);

Re: Initialize INSN_COND

[Gary Funck]

On 06/07/11 21:39:57, Alexander Monakov wrote:
> 2011-06-07  Alexander Monakov  
> 
>   * sel-sched.c (move_op): Use correct type for 'res'.  Verify that
>   code_motion_path_driver returned 0 or 1.
>   (sel_region_finish): Clear h_d_i_d.

Alexander, will this patch fix the recently reported PR49303 and PR49304?
If so, can a note be added to the ChangeLog entry?  Also, would a
DG test case make sense to help find future regressions, or is this
failure mode simply too specific?

Re: [pph] Removing pth implementation from pph implementation (issue4571047)

[Diego Novillo]

On Mon, Jun 6, 2011 at 16:12, Gabriel Charette  wrote:
> Ok removed the tests as well.
>
> Executed the full test suite with no errors (except for currently known 
> ones..)

Thanks.  Committed as rev 174761.


Diego.

Re: [pph] Clean up PPH tests (issue4572042)

[Diego Novillo]

After getting new failures due to an unrelated fix, I think this will
be more trouble than it's worth.

First, we can't get rid of the XPASSes, so those will always be noisy.

Second, some XPASSes will need to be unmarked because we just fixed
the underlying problem.

Third, we are at such an early stage, that fixes to a test case will
generally expose failures in other already failing tests, but these
failures will be in a different place.  So more noise.

I really think that for now the easiest way to keep track of this is
to have a clean build to compare against.


Diego.

[pph] Stream TREE_TYPE for identifier node (issue4550121)

[Gabriel Charette]

We need to stream TREE_TYPE for identifier node.

This fixes some ICEs, but introduces some new assembly mismatch errors.

Here is the testing diff:
47,49d46
< XPASS: g++.dg/pph/x1autometh.cc  -fpph-map=pph.map -I.  (test for bogus 
messages, line )
< XPASS: g++.dg/pph/x1autometh.cc  -fpph-map=pph.map -I. (test for excess 
errors)
< FAIL: g++.dg/pph/x1autometh.cc  (assembly mismatch)
51c48
< XPASS: g++.dg/pph/x1functions.cc  -fpph-map=pph.map -I. (test for excess 
errors)
---
> XPASS: g++.dg/pph/x1functions.cc  -I.  (test for bogus messages, line )
53,54d49
< XPASS: g++.dg/pph/x1special.cc  -fpph-map=pph.map -I.  (test for bogus 
messages, line )
< XPASS: g++.dg/pph/x1special.cc  -fpph-map=pph.map -I. (test for excess errors)
62d56
< XPASS: g++.dg/pph/x1typerefs.cc  -fpph-map=pph.map -I.  (test for bogus 
messages, line )
70,74c64,68
< # of expected passes  174
< # of unexpected failures  2
< # of unexpected successes 21
< # of expected failures37
< /usr/local/google/gchare/gcc/dbg/gcc/testsuite/g++/../../g++  version 
4.7.0-pph 20110606 (experimental) (GCC) 
---
> # of expected passes  177
> # of unexpected failures  1
> # of unexpected successes 16
> # of expected failures46
> /usr/local/google/gchare/gcc-clean/bld/gcc/testsuite/g++/../../g++  version 
> 4.7.0-pph 20110606 (experimental) (GCC)

2011-06-07  Gabriel Charette  

* gcc/cp/pph-streamer-in.c (pph_read_tree): 
Read TREE_TYPE from id_node.
* gcc/cp/pph-streamer-out.c (pph_write_tree):
Write TREE_TYPE from id_node.
* gcc/testsuite/g++.dg/pph/x1functions.cc (dg-xfail-if "ICE"): Remove.
(dg-xfail-if "ERROR"): Add.

Index: gcc/cp/pph-streamer-in.c
===
--- gcc/cp/pph-streamer-in.c(revision 174760)
+++ gcc/cp/pph-streamer-in.c(working copy)
@@ -1027,6 +1027,7 @@
 id->bindings = pph_in_cxx_binding (stream);
 id->class_template_info = pph_in_tree (stream);
 id->label_value = pph_in_tree (stream);
+   TREE_TYPE (expr) = pph_in_tree (stream);
   }
   break;
 
Index: gcc/cp/pph-streamer-out.c
===
--- gcc/cp/pph-streamer-out.c   (revision 174760)
+++ gcc/cp/pph-streamer-out.c   (working copy)
@@ -983,6 +983,7 @@
 pph_out_cxx_binding (stream, id->bindings, ref_p);
 pph_out_tree_or_ref_1 (stream, id->class_template_info, ref_p, 3);
 pph_out_tree_or_ref_1 (stream, id->label_value, ref_p, 3);
+   pph_out_tree_or_ref_1 (stream, TREE_TYPE (expr), ref_p, 3);
   }
   break;
 
Index: gcc/testsuite/g++.dg/pph/x1functions.cc
===
--- gcc/testsuite/g++.dg/pph/x1functions.cc (revision 174760)
+++ gcc/testsuite/g++.dg/pph/x1functions.cc (working copy)
@@ -1,6 +1,5 @@
-// { dg-xfail-if "ICE" { "*-*-*" } { "-fpph-map=pph.map" } }
+// { dg-xfail-if "ERROR" { "*-*-*" } { "-fpph-map=pph.map" } }
 // { dg-bogus "'mbr_decl_inline' was not declared in this scope" "" { xfail 
*-*-* } 0 }
-// { dg-bogus "c1functions.h:8:34: internal compiler error: Segmentation 
fault" "" { xfail *-*-* } 0 }
 // { dg-prune-output "In file included from " }
 // { dg-prune-output "In member function " }
 // { dg-prune-output "At global scope:" }

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

Re: PATCH [1/n]: Add initial -x32 support

[H.J. Lu]

On Tue, Jun 7, 2011 at 8:47 AM, Joseph S. Myers  wrote:
> On Sun, 5 Jun 2011, H.J. Lu wrote:
>
>>       * config.gcc: Support --enable-x32/--enable-ia32 for x86 Linux
>>       targets.
>>
>>       * configure.ac: Support --enable-x32/--enable-ia32.
>>       * configure: Regenerated.
>
> New configure options need documenting in install.texi.

I will fix it.

>>  #undef ASM_SPEC
>> -#define ASM_SPEC "%{" SPEC_32 ":--32} %{" SPEC_64 ":--64} \
>> +#define ASM_SPEC "%{" SPEC_32 ":%{!mx32:--32}} %{" \
>> + SPEC_64 ":%{!mx32:--64}} %{mx32:--x32} \
>>   %{!mno-sse2avx:%{mavx:-msse2avx}} %{msse2avx:%{!mavx:-msse2avx}}"
>
> This looks wrong.  You should define SPEC_32, SPEC_64 and SPEC_X32 to be
> the three mutually exclusive cases, then use those three here and in other
> specs without any nesting.

I thought about it when I started working on it.  But I couldn't find a way
to do it properly.  What we have are

#if TARGET_64BIT_DEFAULT
#define SPEC_32 "m32"
#define SPEC_64 "!m32"
#else
#define SPEC_32 "!m64"
#define SPEC_64 "m64"
#endif

I don't know how  to make -mx32, -m32 and -m64 mutually exclusive with
GCC spec processing in GCC driver.

>>  Generate code for a 32-bit or 64-bit environment.
>> -The 32-bit environment sets int, long and pointer to 32 bits and
>> +The -m32 option sets int, long and pointer to 32 bits and
>
> @option{-m32}.  Likewise later in this paragraph for various option names.
>

I will fix it.

Thanks.


-- 
H.J.

Re: Initialize INSN_COND

[Alexander Monakov]

On Tue, Jun 7, 2011 at 10:09 PM, Gary Funck  wrote:
> On 06/07/11 21:39:57, Alexander Monakov wrote:
>> 2011-06-07  Alexander Monakov  
>>
>>       * sel-sched.c (move_op): Use correct type for 'res'.  Verify that
>>       code_motion_path_driver returned 0 or 1.
>>       (sel_region_finish): Clear h_d_i_d.
>
> Alexander, will this patch fix the recently reported PR49303 and PR49304?

Yes.

> If so, can a note be added to the ChangeLog entry?  Also, would a
> DG test case make sense to help find future regressions, or is this
> failure mode simply too specific?

I will amend the Changelog entry and add a smaller testcase that I
have reduced from combine.c. Thanks for reporting this — I was in a
hurry to submit this for approval before leaving.

Alexander

Re: -fdump-passes -fenable-xxx=func_name_list

[Xinliang David Li]

Please review the attached two patches.

In the first patch, gate functions are cleaned up. All the per
function legality checks are moved into the executor and the
optimization heuristic checks (optimize for size) remain in the
gators. These allow the the following overriding order:

common flags (O2, -ftree-vrp, -fgcse etc)   <---  compiler
heuristic (optimize for size/speed) <--- -fdisable/enable forcing pass
options  <--- legality check

Testing under going. Ok for trunk?

Thanks,

David

On Tue, Jun 7, 2011 at 9:24 AM, Xinliang David Li  wrote:
> Ok -- that sounds good.
>
> David
>
> On Tue, Jun 7, 2011 at 3:10 AM, Richard Guenther
>  wrote:
>> On Mon, Jun 6, 2011 at 6:00 PM, Xinliang David Li  wrote:
>>> On Mon, Jun 6, 2011 at 4:38 AM, Richard Guenther
>>>  wrote:
 On Thu, Jun 2, 2011 at 9:12 AM, Xinliang David Li  
 wrote:
> This is the version of the patch that walks through pass lists.
>
> Ok with this one?

 +/* Dump all optimization passes.  */
 +
 +void
 +dump_passes (void)
 +{
 +  struct cgraph_node *n, *node = NULL;
 +  tree save_fndecl = current_function_decl;
 +
 +  fprintf (stderr, "MAX_UID = %d\n", cgraph_max_uid);

 this isn't accurate info - cloning can cause more cgraph nodes to
 appear (it also looks completely unrelated to dump_passes ...).
 Please drop it.
>>>
>>> Ok.
>>>
>>>

 +  create_pass_tab();
 +  gcc_assert (pass_tab);

 you have quite many asserts of this kind - we don't want them when
 the previous stmt as in this case indicates everything is ok.
>>>
>>> ok.
>>>

 +  push_cfun (DECL_STRUCT_FUNCTION (node->decl));

 this has side-effects, I'm not sure we want this here.  Why do you
 need it?  Probably because of

 +  is_really_on = override_gate_status (pass, current_function_decl, 
 is_on);

 ?  But that is dependent on the function given which should have no
 effect (unless it is overridden globally in which case override_gate_status
 and friends should deal with a NULL cfun).
>>>
>>> As we discussed, currently some pass gate functions depend on per node
>>> information -- those checks need to be pushed into execute functions.
>>> I would like to clean those up later -- at which time, the push/pop
>>> can be removed.
>>
>> I'd like to do it the other way around, first clean up the gate functions 
>> then
>> drop in this patch without the cfun push/pop.  The revised patch looks ok
>> to me with the cfun push/pop removed.
>>
>> Thanks,
>> Richard.
>>

 I don't understand why you need another table mapping pass to name
 when pass->name is available and the info is trivially re-constructible.
>>>
>>> This is needed as the pass->name is not the canonicalized name (i.e.,
>>> not with number suffix etc), so the extra mapping from id to
>>> normalized name is needed.
>>>
>>> Thanks,
>>>
>>> David
>>>

 Thanks,
 Richard.

> David
>
> On Wed, Jun 1, 2011 at 12:45 PM, Xinliang David Li  
> wrote:
>> On Wed, Jun 1, 2011 at 12:29 PM, Richard Guenther
>>  wrote:
>>> On Wed, Jun 1, 2011 at 6:16 PM, Xinliang David Li  
>>> wrote:
 On Wed, Jun 1, 2011 at 1:51 AM, Richard Guenther
  wrote:
> On Wed, Jun 1, 2011 at 1:34 AM, Xinliang David Li 
>  wrote:
>> The following patch implements the a new option that dumps gcc PASS
>> configuration. The sample output is attached.  There is one
>> limitation: some placeholder passes that are named with '*xxx' are
>> note registered thus they are not listed. They are not important as
>> they can not be turned on/off anyway.
>>
>> The patch also enhanced -fenable-xxx and -fdisable-xx to allow a list
>> of function assembler names to be specified.
>>
>> Ok for trunk?
>
> Please split the patch.
>
> I'm not too happy how you dump the pass configuration.  Why not 
> simply,
> at a _single_ place, walk the pass tree?  Instead of doing pieces of 
> it
> at pass execution time when it's not already dumped - that really 
> looks
> gross.

 Yes, that was the original plan -- but it has problems
 1) the dumper needs to know the root pass lists -- which can change
 frequently -- it can be a long term maintanance burden;
 2) the centralized dumper needs to be done after option processing
 3) not sure if gate functions have any side effects or have 
 dependencies on cfun

 The proposed solutions IMHO is not that intrusive -- just three hooks
 to do the dumping and tracking indentation.
>>>
>>> Well, if you have a CU that is empty or optimized to nothing at some 
>>> point
>>> you will not get a complete pass list.  I suppose optimize attributes 
>>> might
>>> also con

Re: PATCH [1/n]: Add initial -x32 support

[H.J. Lu]

On Tue, Jun 7, 2011 at 8:59 AM, Joseph S. Myers  wrote:
> An additional comment on the specs: OPTION_DEFAULT_SPECS needs updating
> (-mx32 should use the --with-arch-64 etc. settings).
>

The current x32 branch works like this:

[hjl@gnu-6 gcc]$  ./xgcc -B./ -v -O /tmp/x.i -S
Reading specs from ./specs
COLLECT_GCC=./xgcc
COLLECT_LTO_WRAPPER=./lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /export/gnu/import/git/gcc-x32/configure
--enable-languages=c --disable-bootstrap --prefix=/usr/gcc-4.7.0-x32
--with-local-prefix=/usr/local --enable-gnu-indirect-function
--enable-x32 --with-arch-32=atom --with-cpu-64=corei7
--enable-cloog-backend=isl --with-ppl-include=/opt/gnu/include
--with-ppl-lib=/opt/gnu/lib64 --with-cloog-include=/opt/gnu/include
--with-cloog-lib=/opt/gnu/lib64 --with-fpmath=sse
Thread model: posix
gcc version 4.7.0 20110607 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-B' './' '-v' '-O' '-S' '-mtune=corei7' '-march=x86-64'
 ./cc1 -fpreprocessed /tmp/x.i -quiet -dumpbase x.i -mtune=corei7
-march=x86-64 -auxbase x -O -version -o x.s
GNU C (GCC) version 4.7.0 20110607 (experimental) (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.6.0 20110509 (Red Hat 4.6.0-7), GMP
version 4.3.2, MPFR version 3.0.0, MPC version 0.8.3-dev
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU C (GCC) version 4.7.0 20110607 (experimental) (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.6.0 20110509 (Red Hat 4.6.0-7), GMP
version 4.3.2, MPFR version 3.0.0, MPC version 0.8.3-dev
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 4ce06b87a1cd6526b31d62b0b2a64ecd
COMPILER_PATH=./
LIBRARY_PATH=./:/lib/../lib64/:/usr/lib/../lib64/:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-B' './' '-v' '-O' '-S' '-mtune=corei7' '-march=x86-64'
[hjl@gnu-6 gcc]$  ./xgcc -B./ -v -O /tmp/x.i -S -mx32
Reading specs from ./specs
COLLECT_GCC=./xgcc
COLLECT_LTO_WRAPPER=./lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /export/gnu/import/git/gcc-x32/configure
--enable-languages=c --disable-bootstrap --prefix=/usr/gcc-4.7.0-x32
--with-local-prefix=/usr/local --enable-gnu-indirect-function
--enable-x32 --with-arch-32=atom --with-cpu-64=corei7
--enable-cloog-backend=isl --with-ppl-include=/opt/gnu/include
--with-ppl-lib=/opt/gnu/lib64 --with-cloog-include=/opt/gnu/include
--with-cloog-lib=/opt/gnu/lib64 --with-fpmath=sse
Thread model: posix
gcc version 4.7.0 20110607 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-B' './' '-v' '-O' '-S' '-mx32' '-mtune=corei7'
'-march=x86-64'
 ./cc1 -fpreprocessed /tmp/x.i -quiet -dumpbase x.i -mx32
-mtune=corei7 -march=x86-64 -auxbase x -O -version -o x.s
GNU C (GCC) version 4.7.0 20110607 (experimental) (x86_64-unknown-linux-gnu)
    compiled by GNU C version 4.6.0 20110509 (Red Hat 4.6.0-7), GMP
version 4.3.2, MPFR version 3.0.0, MPC version 0.8.3-dev
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU C (GCC) version 4.7.0 20110607 (experimental) (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.6.0 20110509 (Red Hat 4.6.0-7), GMP
version 4.3.2, MPFR version 3.0.0, MPC version 0.8.3-dev
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 4ce06b87a1cd6526b31d62b0b2a64ecd
COMPILER_PATH=./
LIBRARY_PATH=./x32/:/lib/../libx32/:/usr/lib/../libx32/:./:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-B' './' '-v' '-O' '-S' '-mx32' '-mtune=corei7'
'-march=x86-64'
[hjl@gnu-6 gcc]$  ./xgcc -B./ -v -O /tmp/x.i -S -m32
Reading specs from ./specs
COLLECT_GCC=./xgcc
COLLECT_LTO_WRAPPER=./lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /export/gnu/import/git/gcc-x32/configure
--enable-languages=c --disable-bootstrap --prefix=/usr/gcc-4.7.0-x32
--with-local-prefix=/usr/local --enable-gnu-indirect-function
--enable-x32 --with-arch-32=atom --with-cpu-64=corei7
--enable-cloog-backend=isl --with-ppl-include=/opt/gnu/include
--with-ppl-lib=/opt/gnu/lib64 --with-cloog-include=/opt/gnu/include
--with-cloog-lib=/opt/gnu/lib64 --with-fpmath=sse
Thread model: posix
gcc version 4.7.0 20110607 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-B' './' '-v' '-O' '-S' '-m32' '-mtune=generic'
'-march=atom'
 ./cc1 -fpreprocessed /tmp/x.i -quiet -dumpbase x.i -m32
-mtune=generic -march=atom -auxbase x -O -version -o x.s
GNU C (GCC) version 4.7.0 20110607 (experimental) (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.6.0 20110509 (Red Hat 4.6.0-7), GMP
version 4.3.2, MPFR version 3.0.0, MPC version 0.8.3-dev
GGC heuristics: --param ggc-min-expan

Re: [build] Remove LIB2ADDEHDEP

[Joseph S. Myers]

On Tue, 7 Jun 2011, Rainer Orth wrote:

> Right, my plan was to move all files only referenced by LIB2ADDEH*.
> 
> Does the plan seem ok otherwise?

Yes, it seems plausible.  Thanks for working on this transition.

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

Re: [build] Move ENABLE_EXECUTE_STACK to toplevel libgcc

[Joseph S. Myers]

On Tue, 7 Jun 2011, Rainer Orth wrote:

> > So my view is that you should define __LIBGCC_TRAMPOLINE_SIZE__, only if 
> > -fbuilding-libgcc.
> 
> I can give it a try if I can figure out how to define -fbuilding-libgcc
> via the option handling machinery.  I just want to avoid having to

That should be no more than

; Define extra predefined macros for use in libgcc.
fbuilding-libgcc
C ObjC C++ ObjC++ Undocumented Var(flag_building_libgcc)

in c.opt.

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

Re: PATCH [1/n]: Add initial -x32 support

[Joseph S. Myers]

On Tue, 7 Jun 2011, H.J. Lu wrote:

> I thought about it when I started working on it.  But I couldn't find a way
> to do it properly.  What we have are
> 
> #if TARGET_64BIT_DEFAULT
> #define SPEC_32 "m32"
> #define SPEC_64 "!m32"
> #else
> #define SPEC_32 "!m64"
> #define SPEC_64 "m64"
> #endif
> 
> I don't know how  to make -mx32, -m32 and -m64 mutually exclusive with
> GCC spec processing in GCC driver.

The use of Negative in the .opt file means that only one such option will 
be visible for specs.  So you define specs such as "m64|mx32:;" to mean 
"neither -m64 nor -mx32 is passed (see the MIPS definitions of OPT_ARCH64 
and OPT_ARCH32, for example).

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

Re: PATCH [1/n]: Add initial -x32 support

[Joseph S. Myers]

On Tue, 7 Jun 2011, H.J. Lu wrote:

> That is -mx32 takes the same default as -m64. It is the correct
> behavior for -mx32.

I think it's only right in the case where -m64 is the default, and the 
specs for the case where -m32 is the default need changing to handle -mx32 
properly.

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

[x32] PATCH: Document --enable-ia32 and --enable-x32

[H.J. Lu]

Hi,

I checked this patch into x32 branch.

H.J.
commit d41e1fd1c4d8114532152647e5fc5b6bc3bce5dd
Author: H.J. Lu 
Date:   Tue Jun 7 11:39:27 2011 -0700

Document --enable-ia32 and --enable-x32.

diff --git a/gcc/ChangeLog.x32 b/gcc/ChangeLog.x32
index 06d931a..3ce5fa1 100644
--- a/gcc/ChangeLog.x32
+++ b/gcc/ChangeLog.x32
@@ -1,3 +1,7 @@
+2011-06-07  H.J. Lu  
+
+   * doc/install.texi: Document --enable-ia32 and --enable-x32.
+
 2011-06-06  H.J. Lu  
 
* config.gcc: Replace i386/t-linuxx32 with i386/t-linux-x32.
diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
index 7ebcd92..f63094c 100644
--- a/gcc/doc/install.texi
+++ b/gcc/doc/install.texi
@@ -1155,6 +1155,16 @@ assumptions made by the configure test are incorrect.
 Specify that the target does not support TLS.
 This is an alias for @option{--enable-tls=no}.
 
+@item --enable-ia32
+This option enables ia32 library support for multiple ABIs.  By
+default, ia32 library support is enabled.  It is only supported for
+x86-64.
+
+@item --enable-x32
+This option enables x32 library support for multiple ABIs. By
+default, x32 library support is disabled.  It is only supported for
+x86-64.
+
 @item --with-cpu=@var{cpu}
 @itemx --with-cpu-32=@var{cpu}
 @itemx --with-cpu-64=@var{cpu}

[x32] PATCH: Use @option{} on -mx32, -m64 and -mx32

[H.J. Lu]

Hi,

I checked this patch into x32 branch.

H.J.
---
commit e8fa82850eaa92e660e06d4a939a0cc313b5aa3e
Author: H.J. Lu 
Date:   Tue Jun 7 11:44:34 2011 -0700

Use @option{} on -mx32, -m64 and -mx32.

diff --git a/gcc/ChangeLog.x32 b/gcc/ChangeLog.x32
index 3ce5fa1..5655c61 100644
--- a/gcc/ChangeLog.x32
+++ b/gcc/ChangeLog.x32
@@ -1,5 +1,9 @@
 2011-06-07  H.J. Lu  
 
+   * doc/invoke.texi: Use @option{} on -mx32, -m64 and -mx32.
+
+2011-06-07  H.J. Lu  
+
* doc/install.texi: Document --enable-ia32 and --enable-x32.
 
 2011-06-06  H.J. Lu  
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 12080ca..b4ccfe9 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -12829,14 +12829,14 @@ on AMD x86-64 processors in 64-bit environments.
 @opindex m64
 @opindex mx32
 Generate code for a 32-bit or 64-bit environment.
-The -m32 option sets int, long and pointer to 32 bits and
+The @option{-m32} option sets int, long and pointer to 32 bits and
 generates code that runs on any i386 system.
-The -m64 option sets int to 32 bits and long and pointer
+The @option{-m64} option sets int to 32 bits and long and pointer
 to 64 bits and generates code for AMD's x86-64 architecture.
-The -mx32 option sets int, long and pointer to 32 bits and generates
-code for AMD's x86-64 architecture.
-For darwin only the -m64 option turns off the @option{-fno-pic} and
-@option{-mdynamic-no-pic} options.
+The @option{-mx32} option sets int, long and pointer to 32 bits and
+generates code for AMD's x86-64 architecture.
+For darwin only the @option{-m64} option turns off the @option{-fno-pic}
+and @option{-mdynamic-no-pic} options.
 
 @item -mno-red-zone
 @opindex mno-red-zone

objc/objc++: fix most testsuite failures on darwin8

[Nicola Pero]

This patch (prepared by me and Iain) fixes almost all failures of the testsuite 
on Darwin 8
caused by the large testsuite changes I committed yesterday.

The patch fixes all the failures but 2.  These two require a different small 
fix that is being
developed/tested and will be submitted separately.

Thanks Iain for the help! :-)

OK to commit ?

Thanks

Index: ChangeLog
===
--- ChangeLog   (revision 174760)
+++ ChangeLog   (working copy)
@@ -1,3 +1,10 @@
+2011-06-07  Nicola Pero  
+   Iain Sandoe  
+
+   * objc-obj-c++-shared/TestsuiteObject.h ([-free]): Return 'id'.
+   * objc-obj-c++-shared/TestsuiteObject.m ([-free]): Return 'id'.
+   Added cast.
+   
 2011-06-07  Rainer Orth  
 
gcc/testsuite:
Index: objc-obj-c++-shared/TestsuiteObject.h
===
--- objc-obj-c++-shared/TestsuiteObject.h   (revision 174760)
+++ objc-obj-c++-shared/TestsuiteObject.h   (working copy)
@@ -35,7 +35,7 @@ along with GCC; see the file COPYING3.  If not see
 + (id) new;
 + (id) alloc;
 - (id) init;
-- (void) free;
+- (id) free;
 
 /* Auxiliary methods.  */
 + (Class) class;
Index: objc-obj-c++-shared/TestsuiteObject.m
===
--- objc-obj-c++-shared/TestsuiteObject.m   (revision 174760)
+++ objc-obj-c++-shared/TestsuiteObject.m   (working copy)
@@ -41,9 +41,14 @@ along with GCC; see the file COPYING3.  If not see
 {
   return self;
 }
-- (void) free
+/* We return 'id' to have the same signature as [Object -free] in
+   older runtimes and avoid warnings about conflicting signatures.  */
+- (id) free
 {
-  object_dispose (self);
+  /* Cast 'self' to 'id' because the NeXT runtime in darwin8 (Apple
+ Mac OS X 10.4) declares object_dispose to take an "Object *"
+ argument.  */
+  return object_dispose ((id)self);
 }
 + (Class) class
 {

Re: -fdump-passes -fenable-xxx=func_name_list

[Xinliang David Li]

The dump-pass patch with test case.

David

On Tue, Jun 7, 2011 at 11:54 AM, Xinliang David Li  wrote:
> Please review the attached two patches.
>
> In the first patch, gate functions are cleaned up. All the per
> function legality checks are moved into the executor and the
> optimization heuristic checks (optimize for size) remain in the
> gators. These allow the the following overriding order:
>
>    common flags (O2, -ftree-vrp, -fgcse etc)   <---  compiler
> heuristic (optimize for size/speed) <--- -fdisable/enable forcing pass
> options  <--- legality check
>
> Testing under going. Ok for trunk?
>
> Thanks,
>
> David
>
> On Tue, Jun 7, 2011 at 9:24 AM, Xinliang David Li  wrote:
>> Ok -- that sounds good.
>>
>> David
>>
>> On Tue, Jun 7, 2011 at 3:10 AM, Richard Guenther
>>  wrote:
>>> On Mon, Jun 6, 2011 at 6:00 PM, Xinliang David Li  
>>> wrote:
 On Mon, Jun 6, 2011 at 4:38 AM, Richard Guenther
  wrote:
> On Thu, Jun 2, 2011 at 9:12 AM, Xinliang David Li  
> wrote:
>> This is the version of the patch that walks through pass lists.
>>
>> Ok with this one?
>
> +/* Dump all optimization passes.  */
> +
> +void
> +dump_passes (void)
> +{
> +  struct cgraph_node *n, *node = NULL;
> +  tree save_fndecl = current_function_decl;
> +
> +  fprintf (stderr, "MAX_UID = %d\n", cgraph_max_uid);
>
> this isn't accurate info - cloning can cause more cgraph nodes to
> appear (it also looks completely unrelated to dump_passes ...).
> Please drop it.

 Ok.


>
> +  create_pass_tab();
> +  gcc_assert (pass_tab);
>
> you have quite many asserts of this kind - we don't want them when
> the previous stmt as in this case indicates everything is ok.

 ok.

>
> +  push_cfun (DECL_STRUCT_FUNCTION (node->decl));
>
> this has side-effects, I'm not sure we want this here.  Why do you
> need it?  Probably because of
>
> +  is_really_on = override_gate_status (pass, current_function_decl, 
> is_on);
>
> ?  But that is dependent on the function given which should have no
> effect (unless it is overridden globally in which case 
> override_gate_status
> and friends should deal with a NULL cfun).

 As we discussed, currently some pass gate functions depend on per node
 information -- those checks need to be pushed into execute functions.
 I would like to clean those up later -- at which time, the push/pop
 can be removed.
>>>
>>> I'd like to do it the other way around, first clean up the gate functions 
>>> then
>>> drop in this patch without the cfun push/pop.  The revised patch looks ok
>>> to me with the cfun push/pop removed.
>>>
>>> Thanks,
>>> Richard.
>>>
>
> I don't understand why you need another table mapping pass to name
> when pass->name is available and the info is trivially re-constructible.

 This is needed as the pass->name is not the canonicalized name (i.e.,
 not with number suffix etc), so the extra mapping from id to
 normalized name is needed.

 Thanks,

 David

>
> Thanks,
> Richard.
>
>> David
>>
>> On Wed, Jun 1, 2011 at 12:45 PM, Xinliang David Li  
>> wrote:
>>> On Wed, Jun 1, 2011 at 12:29 PM, Richard Guenther
>>>  wrote:
 On Wed, Jun 1, 2011 at 6:16 PM, Xinliang David Li  
 wrote:
> On Wed, Jun 1, 2011 at 1:51 AM, Richard Guenther
>  wrote:
>> On Wed, Jun 1, 2011 at 1:34 AM, Xinliang David Li 
>>  wrote:
>>> The following patch implements the a new option that dumps gcc PASS
>>> configuration. The sample output is attached.  There is one
>>> limitation: some placeholder passes that are named with '*xxx' are
>>> note registered thus they are not listed. They are not important as
>>> they can not be turned on/off anyway.
>>>
>>> The patch also enhanced -fenable-xxx and -fdisable-xx to allow a 
>>> list
>>> of function assembler names to be specified.
>>>
>>> Ok for trunk?
>>
>> Please split the patch.
>>
>> I'm not too happy how you dump the pass configuration.  Why not 
>> simply,
>> at a _single_ place, walk the pass tree?  Instead of doing pieces of 
>> it
>> at pass execution time when it's not already dumped - that really 
>> looks
>> gross.
>
> Yes, that was the original plan -- but it has problems
> 1) the dumper needs to know the root pass lists -- which can change
> frequently -- it can be a long term maintanance burden;
> 2) the centralized dumper needs to be done after option processing
> 3) not sure if gate functions have any side effects or have 
> dependencies on cfun
>
> The proposed solutions IMHO is not that intrusive -

Re: Initialize INSN_COND

[Bernd Schmidt]

On 06/07/2011 07:39 PM, Alexander Monakov wrote:
> 
> 
> On Fri, 3 Jun 2011, Bernd Schmidt wrote:
> 
 Ok. Although I wonder how sel-sched can end up reusing an entry in
 h_d_i_d?
> 
> Unlike Haifa scheduler, we recompute INSN_LUIDs for each region.  However, we
> call sched_deps_{init,finish} once per function (like Haifa) and that makes us
> reuse entries in h_d_i_d.
> 
> The proposed patch clears h_d_i_d when finishing a region in sel-sched.
> Bootstrapped and regtested on ia64-linux, OK for trunk?

You probably know best, so I'll approve it. Thanks for working on this.

> Normal forward scan is only done to compute insn priorities; now, it will also
> reset INSN_CONDs for instructions followed by an assignment to their
> predicate (for exposed-pipeline targets). After that, sel-sched's dependency
> analysis will treat such instructions as if they had no predicate, which is
> very conservative.  Unfortunately, correctness still may be broken after a
> predicate assignment is moved into a different BB (or copied to one as a
> bookkeeping copy).  I'll try to think of a way to fix it when preparing the
> predication patch.

It's probably not urgent. We can't really use sel-sched on c6x, as I'd
have to add the backtracking machinery to sel-sched for scheduling delay
slots, and I don't understand it well enough to do so.


Bernd

Re: objc/objc++: fix most testsuite failures on darwin8

[Nicola Pero]

This patch (written with Iain) fixes all the testsuite failiures on Darwin8.  
It includes the previous one.

OK to commit ?

Thanks

Index: ChangeLog
===
--- ChangeLog   (revision 174760)
+++ ChangeLog   (working copy)
@@ -1,3 +1,18 @@
+2011-06-07  Nicola Pero  
+   Iain Sandoe  
+
+   * objc-obj-c++-shared/runtime.h (protocol_getMethodDescription):
+   Added code to deal with the case when [Protocol
+   -descriptionForInstanceMethod:] or [Protocol
+   -descriptionForClassMethod:] returns NULL.
+
+2011-06-07  Nicola Pero  
+   Iain Sandoe  
+
+   * objc-obj-c++-shared/TestsuiteObject.h ([-free]): Return 'id'.
+   * objc-obj-c++-shared/TestsuiteObject.m ([-free]): Return 'id'.
+   Added cast.
+   
 2011-06-07  Rainer Orth  
 
gcc/testsuite:
Index: objc-obj-c++-shared/TestsuiteObject.h
===
--- objc-obj-c++-shared/TestsuiteObject.h   (revision 174761)
+++ objc-obj-c++-shared/TestsuiteObject.h   (working copy)
@@ -35,7 +35,7 @@ along with GCC; see the file COPYING3.  If not see
 + (id) new;
 + (id) alloc;
 - (id) init;
-- (void) free;
+- (id) free;
 
 /* Auxiliary methods.  */
 + (Class) class;
Index: objc-obj-c++-shared/runtime.h
===
--- objc-obj-c++-shared/runtime.h   (revision 174761)
+++ objc-obj-c++-shared/runtime.h   (working copy)
@@ -93,14 +93,16 @@ struct objc_method_description protocol_getMethodD
   struct objc_method_description result;
 
   if (instanceMethod)
-{
-  tmp = [protocol descriptionForInstanceMethod: selector];
-  result = *tmp;
-}
+tmp = [protocol descriptionForInstanceMethod: selector];
   else
+tmp = [protocol descriptionForClassMethod: selector];
+
+  if (tmp)
+result = *tmp;
+  else
 {
-  tmp = [protocol descriptionForClassMethod: selector];
-  result = *tmp;  
+  result.name = (SEL)0;
+  result.types = (char *)0;
 }
 
   return result;
Index: objc-obj-c++-shared/TestsuiteObject.m
===
--- objc-obj-c++-shared/TestsuiteObject.m   (revision 174761)
+++ objc-obj-c++-shared/TestsuiteObject.m   (working copy)
@@ -41,9 +41,14 @@ along with GCC; see the file COPYING3.  If not see
 {
   return self;
 }
-- (void) free
+/* We return 'id' to have the same signature as [Object -free] in
+   older runtimes and avoid warnings about conflicting signatures.  */
+- (id) free
 {
-  object_dispose (self);
+  /* Cast 'self' to 'id' because the NeXT runtime in darwin8 (Apple
+ Mac OS X 10.4) declares object_dispose to take an "Object *"
+ argument.  */
+  return object_dispose ((id)self);
 }
 + (Class) class
 {

Re: objc/objc++: fix most testsuite failures on darwin8

[Mike Stump]

On Jun 7, 2011, at 1:38 PM, Nicola Pero wrote:
> This patch (written with Iain) fixes all the testsuite failiures on Darwin8.  
> It includes the previous one.
> 
> OK to commit ?

Ok.

Re: [patch] Improve detection of widening multiplication in the vectorizer

[H.J. Lu]

On Wed, Jun 1, 2011 at 2:23 AM, Ira Rosen  wrote:
> Hi,
>
> The vectorizer expects widening multiplication pattern to be:
>
>     type a_t, b_t;
>     TYPE a_T, b_T, prod_T;
>
>     a_T = (TYPE) a_t;
>     b_T = (TYPE) b_t;
>     prod_T = a_T * b_T;
>
> where type 'TYPE' is double the size of type 'type'. This works fine
> when the types are signed. For the unsigned types the code looks like:
>
>     unsigned type a_t, b_t;
>     unsigned TYPE u_prod_T;
>     TYPE a_T, b_T, prod_T;
>
>      a_T = (TYPE) a_t;
>      b_T = (TYPE) b_t;
>      prod_T = a_T * b_T;
>      u_prod_T = (unsigned TYPE) prod_T;
>
> i.e., the multiplication is done on signed, followed by a cast to unsigned.
> This patch adds a support of such patterns and generates
> WIDEN_MULT_EXPR for the unsigned type.
>
> Another unsupported case is multiplication by a constant (e.g., b_T is
> a constant). This patch checks that the constant fits the smaller type
> 'type' and recognizes such cases as widening multiplication.
>
> Bootstrapped and tested on powerpc64-suse-linux. Tested the
> vectorization testsuite on arm-linux-gnueabi.
> I'll commit the patch shortly if there are no comments/objections.
>
> Ira
>
> ChangeLog:
>
>       * tree-vectorizer.h (vect_recog_func_ptr): Make last argument to be
>       a pointer.
>       * tree-vect-patterns.c (vect_recog_widen_sum_pattern,
>       vect_recog_widen_mult_pattern, vect_recog_dot_prod_pattern,
>       vect_recog_pow_pattern): Likewise.
>       (vect_pattern_recog_1): Remove declaration.
>       (widened_name_p): Remove declaration.  Add new argument to specify
>       whether to check that both types are either signed or unsigned.
>       (vect_recog_widen_mult_pattern): Update documentation.  Handle
>       unsigned patterns and multiplication by constants.
>       (vect_pattern_recog_1): Update vect_recog_func references.  Use
>       statement information from the statement returned from pattern
>       detection functions.
>       (vect_pattern_recog): Update vect_recog_func reference.
>       * tree-vect-stmts.c (vectorizable_type_promotion): For widening
>       multiplication by a constant use the type of the other operand.
>
.

This caused:

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

-- 
H.J.

[testsuite] skip ARM tests with conflicting options

[Janis Johnson]

Several tests in gcc.target/arm use dg-options with -mcpu=, which
causes compiler warnings or errors when the multilib flags include
-march=.  This patch causes those tests to be skipped.  It also
prevents gcc.target/arm/20090811-1.c from running with multilibs that
would override -mcpu or -mfloat-abi options specified for the test.

Tested on arm-none-linux-gnueabi for several multilibs; these tests
are compile-only so it didn't matter that I didn't have runtime
support for them.

OK for trunk and 4.6 branch?  (This is just the tip of the iceberg.)
2011-06-07  Janis Johnson  

* gcc.target/arm/20090811-1.c: Skip for incompatible options, do not
override other options.
* gcc.target/arm/combine-cmp-shift.c: Skip for incompatible options.
* gcc.target/arm/pr45094.c: Likewise.
* gcc.target/arm/scd42-1.c: Likewise.
* gcc.target/arm/scd42-3.c: Likewise.
* gcc.target/arm/thumb-ltu.c: Likewise.

Index: gcc/testsuite/gcc.target/arm/20090811-1.c
===
--- gcc/testsuite/gcc.target/arm/20090811-1.c   (revision 174706)
+++ gcc/testsuite/gcc.target/arm/20090811-1.c   (working copy)
@@ -1,4 +1,7 @@
 /* { dg-do compile } */
+/* { dg-skip-if "incompatible options" { arm*-*-* } { "-march=*" } { "" } } */
+/* { dg-skip-if "do not override -mcpu" { *-*-* } { "-mcpu=*" } { 
"-mcpu=cortex-a8" } } */
+/* { dg-skip-if "do not override -mfloat-abi" { *-*-* } { "-mfloat-abi=*" } { 
"-mfloat-abi=softfp" } } */
 /* { dg-options "-O3 -mcpu=cortex-a8 -mfpu=vfp3 -mfloat-abi=softfp" } */
 
 typedef struct cb
Index: gcc/testsuite/gcc.target/arm/combine-cmp-shift.c
===
--- gcc/testsuite/gcc.target/arm/combine-cmp-shift.c(revision 174706)
+++ gcc/testsuite/gcc.target/arm/combine-cmp-shift.c(working copy)
@@ -1,3 +1,4 @@
+/* { dg-skip-if "incompatible options" { arm*-*-* } { "-march=*" } { "" } } */
 /* { dg-options "-O2 -mcpu=cortex-a8" }  */
 /* { dg-final { scan-assembler "cmp\tr\[0-9\]*, r\[0-9\]*, asr #31" } } */
 
Index: gcc/testsuite/gcc.target/arm/pr45094.c
===
--- gcc/testsuite/gcc.target/arm/pr45094.c  (revision 174706)
+++ gcc/testsuite/gcc.target/arm/pr45094.c  (working copy)
@@ -1,4 +1,5 @@
 /* { dg-do run } */
+/* { dg-skip-if "incompatible options" { arm*-*-* } { "-march=*" } { "" } } */
 /* { dg-require-effective-target arm_neon_hw } */
 /* { dg-options "-O2 -mcpu=cortex-a8" } */
 /* { dg-add-options arm_neon } */
Index: gcc/testsuite/gcc.target/arm/scd42-1.c
===
--- gcc/testsuite/gcc.target/arm/scd42-1.c  (revision 174706)
+++ gcc/testsuite/gcc.target/arm/scd42-1.c  (working copy)
@@ -1,5 +1,6 @@
 /* Verify that mov is preferred on XScale for loading a 1 byte constant. */
 /* { dg-do compile } */
+/* { dg-skip-if "incompatible options" { arm*-*-* } { "-march=*" } { "" } } */
 /* { dg-options "-mcpu=xscale -O" } */
 
 unsigned load1(void) __attribute__ ((naked));
Index: gcc/testsuite/gcc.target/arm/scd42-3.c
===
--- gcc/testsuite/gcc.target/arm/scd42-3.c  (revision 174706)
+++ gcc/testsuite/gcc.target/arm/scd42-3.c  (working copy)
@@ -1,5 +1,6 @@
 /* Verify that ldr is preferred on XScale for loading a 3 or 4 byte constant. 
*/
 /* { dg-do compile } */
+/* { dg-skip-if "incompatible options" { arm*-*-* } { "-march=*" } { "" } } */
 /* { dg-options "-mcpu=xscale -O" } */
 
 unsigned load4(void) __attribute__ ((naked));
Index: gcc/testsuite/gcc.target/arm/thumb-ltu.c
===
--- gcc/testsuite/gcc.target/arm/thumb-ltu.c(revision 174706)
+++ gcc/testsuite/gcc.target/arm/thumb-ltu.c(working copy)
@@ -1,4 +1,5 @@
 /* { dg-do compile } */
+/* { dg-skip-if "incompatible options" { arm*-*-* } { "-march=*" } { "" } } */
 /* { dg-options "-mcpu=arm1136jf-s -mthumb -O2" } */
 
 void f(unsigned a, unsigned b, unsigned c, unsigned d)

Re: [testsuite] skip ARM tests with conflicting options

[Joseph S. Myers]

On Tue, 7 Jun 2011, Janis Johnson wrote:

> Several tests in gcc.target/arm use dg-options with -mcpu=, which
> causes compiler warnings or errors when the multilib flags include
> -march=.  This patch causes those tests to be skipped.  It also
> prevents gcc.target/arm/20090811-1.c from running with multilibs that
> would override -mcpu or -mfloat-abi options specified for the test.

I think you should allow compatible -march options - for example, if 
dg-options has -mcpu=cortex-a8, allow -march=armv7-a but disallow all 
other -march options.

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

Re: [pph] Stream TREE_TYPE for identifier node (issue4550121)

[Steven Bosscher]

On Tue, Jun 7, 2011 at 8:44 PM, Gabriel Charette  wrote:
> We need to stream TREE_TYPE for identifier node.

That seems unlikely, as identifiers do not have a type. There is some
TREE_TYPE abuse in cp-tree.h, perhaps you should find out what you're
streaming.

Why are you not using accessor macros for the other fields of
lang_identifier, e.g. not id->label_value but
IDENTIFIER_LABEL_VALUE(id)?

Ciao!
Steven

libobjc: remove unused code (patch 1)

[Nicola Pero]

This patch removes some obsolete code (which used to be used by the Traditional 
API)
and that is no longer used anywhere.

Committed to trunk.

Thanks

Index: class.c
===
--- class.c (revision 174766)
+++ class.c (working copy)
@@ -203,41 +203,6 @@ class_table_insert (const char *class_name, Class
   objc_mutex_unlock (__class_table_lock);
 }
 
-/* Replace a class in the table (used only by poseAs:).  */
-static void 
-class_table_replace (Class old_class_pointer, Class new_class_pointer)
-{
-  int hash;
-  class_node_ptr node;
-
-  objc_mutex_lock (__class_table_lock);
-  
-  hash = 0;
-  node = class_table_array[hash];
-  
-  while (hash < CLASS_TABLE_SIZE)
-{
-  if (node == NULL)
-{
-  hash++;
-  if (hash < CLASS_TABLE_SIZE)
-   node = class_table_array[hash];
-}
-  else
-{
-  Class class1 = node->pointer;
-
-  if (class1 == old_class_pointer)
-   node->pointer = new_class_pointer;
-
-  node = node->next;
-}
-}
-
-  objc_mutex_unlock (__class_table_lock);
-}
-
-
 /* Get a class from the table.  This does not need mutex protection.
Currently, this function is called each time you call a static
method, this is why it must be very fast.  */
@@ -760,16 +725,6 @@ objc_disposeClassPair (Class class_)
   objc_free (class_);
 }
 
-/* Traditional GNU Objective-C Runtime API.  */
-/* Get the class object for the class named NAME.  If NAME does not
-   identify a known class, the hook _objc_lookup_class is called.  If
-   this fails, nil is returned.  */
-Class
-objc_lookup_class (const char *name)
-{
-  return objc_getClass (name);
-}
-
 /* Traditional GNU Objective-C Runtime API.  Important: this method is
called automatically by the compiler while messaging (if using the
traditional ABI), so it is worth keeping it fast; don't make it
@@ -802,38 +757,13 @@ objc_get_class (const char *name)
   return 0;
 }
 
+/* This is used by the compiler too.  */
 Class
 objc_get_meta_class (const char *name)
 {
   return objc_get_class (name)->class_pointer;
 }
 
-/* This function provides a way to enumerate all the classes in the
-   executable.  Pass *ENUM_STATE == NULL to start the enumeration.  The
-   function will return 0 when there are no more classes.  
-   For example: 
-   id class; 
-   void *es = NULL;
-   while ((class = objc_next_class (&es)))
- ... do something with class; 
-*/
-Class
-objc_next_class (void **enum_state)
-{
-  Class class;
-
-  objc_mutex_lock (__objc_runtime_mutex);
-  
-  /* Make sure the table is there.  */
-  assert (__class_table_lock);
-
-  class = class_table_next ((struct class_table_enumerator **) enum_state);
-
-  objc_mutex_unlock (__objc_runtime_mutex);
-  
-  return class;
-}
-
 /* This is used when the implementation of a method changes.  It goes
through all classes, looking for the ones that have these methods
(either method_a or method_b; method_b can be NULL), and reloads
@@ -1035,83 +965,3 @@ class_getInstanceSize (Class class_)
   return class_->instance_size;
 }
 
-#define CLASSOF(c) ((c)->class_pointer)
-
-Class
-class_pose_as (Class impostor, Class super_class)
-{
-  if (! CLS_ISRESOLV (impostor))
-__objc_resolve_class_links ();
-
-  /* Preconditions */
-  assert (impostor);
-  assert (super_class);
-  assert (impostor->super_class == super_class);
-  assert (CLS_ISCLASS (impostor));
-  assert (CLS_ISCLASS (super_class));
-  assert (impostor->instance_size == super_class->instance_size);
-
-  {
-Class *subclass = &(super_class->subclass_list);
-
-/* Move subclasses of super_class to impostor.  */
-while (*subclass)
-  {
-Class nextSub = (*subclass)->sibling_class;
-
-if (*subclass != impostor)
-  {
-Class sub = *subclass;
-
-/* Classes */
-sub->sibling_class = impostor->subclass_list;
-sub->super_class = impostor;
-impostor->subclass_list = sub;
-
-/* It will happen that SUB is not a class object if it is
-   the top of the meta class hierarchy chain (root
-   meta-class objects inherit their class object).  If
-   that is the case... don't mess with the meta-meta
-   class.  */
-if (CLS_ISCLASS (sub))
-  {
-/* Meta classes */
-CLASSOF (sub)->sibling_class = 
-  CLASSOF (impostor)->subclass_list;
-CLASSOF (sub)->super_class = CLASSOF (impostor);
-CLASSOF (impostor)->subclass_list = CLASSOF (sub);
-  }
-  }
-
-*subclass = nextSub;
-  }
-
-/* Set subclasses of superclass to be impostor only.  */
-super_class->subclass_list = impostor;
-CLASSOF (super_class)->subclass_list = CLASSOF (impostor);
-
-/* Set impostor to have no sibling classes.  */

Re: RFA (diags): PATCH to allow %S in pp_verbatim in C++ front end

[Gabriel Dos Reis]

Jason Merrill  writes:

| I want to add a %S format to the C++ front end for printing a
| template/args pair during template argument deduction substitution.  I
| want to print this during print_instantiation_partial_context, which
| uses pp_verbatim.  But for some reason the format attribute on
| pp_verbatim doesn't allow C++ front end formats even though they work
| fine, so this patch adjusts the format attribute to use GCC_DIAG_STYLE
| if it has already been set.
| 
| Tested x86_64-pc-linux-gnu.  OK for trunk?

Yes, both patches look OK to me.  Thanks!

| 
| I've also attached the front end patch that I want this change to support.
| commit a4175256ff83ee2d3d8626a137d817f44cbafc5a
| Author: Jason Merrill 
| Date:   Tue Jun 7 15:57:56 2011 -0400

-- Gaby