Re: [patch] Default to --enable-libstdcxx-time=auto

2013-05-25 Thread Jakub Jelinek
On Sat, May 25, 2013 at 08:21:46AM +0200, Jakub Jelinek wrote:
> In this _V2 inline namespace, I think we should change that:
> struct system_clock
> {
> #ifdef _GLIBCXX_USE_CLOCK_REALTIME
>   typedef chrono::nanoseconds   duration;
> #elif defined(_GLIBCXX_USE_GETTIMEOFDAY)
>   typedef chrono::microseconds  duration;
> #else
>   typedef chrono::seconds   duration;
> #endif
> into:
> struct system_clock
> {
>   typedef chrono::nanoseconds   duration;
> 
> Won't the templates then DTRT in:
>   return time_point(duration(chrono::seconds(tv.tv_sec)
>   + chrono::microseconds(tv.tv_usec)));
> (multiply microseconds by 1000 and seconds by 10)
>   return system_clock::from_time_t(__sec);
> (multiply seconds by 10)?
> 
> While this change isn't really necessary for Linux, where usually
> _GLIBCXX_USE_CLOCK_REALTIME will be in 4.8.1+ defined and thus the
> nanoseconds resolution will be used anyway, on other OSes it might
> be already a problem, say on Solaris or FreeBSD GCC 4.8.1 will have
> by default likely microseconds resolution, while on the trunk nanoseconds.
> By making it always count in nanoseconds, even if on some OSes the low
> 3 or 9 decimal digits will be always zero, we'd prepared to change the
> system_clock::now() implementation any time to provide better resolution, as
> a libstdc++ internal implementation detail.
> 
> Or is this undesirable for users for some reason?

Additional comment to that, the fact that the OS has clock_gettime with
CLOCK_REALTIME resp. gettimeofday still doesn't say anything about the
resolution/precision of the clock, you can have clock_gettime
(CLOCK_REALTIME, &tp) that only provides second or millisecond resolution,
or hundreds if microseconds, tens of nanoseconds etc.  There is clock_getres
in POSIX, but  doesn't query this and if the resolution decision
has to be static (nanoseconds vs. microseconds vs. seconds), I'd hope it
should be ok to always use nanoseconds duration, especially when most of the
important targets will either in 4.8.1+ or at least in 4.9.0+ use
clock_gettime.

Jakub


Re: [PATCH] Fix incorrect discriminator assignment.

2013-05-25 Thread Dominique Dhumieres
> Sure, will update the patch for that. ...

This cause pr57413.

Dominique

PS the escaping in the regexp seems strange: \[0-9]


Re: PR tree-optimization/57337

2013-05-25 Thread Richard Biener
Easwaran Raman  wrote:

>In that case, if my insert_stmt immediately follows dep_stmt and both
>have the same UID, not_dominated_by would return true and I will end
>up updating insert_stmt to dep_stmt which is wrong.

But there should be a safe default answer for
Equal uids. Unless we are asking different questions in different places. Thus, 
I do not like the stmt walking but rather have a safe fallback.

Richard.

>- Easwaran
>
>On Fri, May 24, 2013 at 1:07 AM, Richard Biener
> wrote:
>> On Thu, May 23, 2013 at 7:26 PM, Easwaran Raman 
>wrote:
>>> This addresses the case where UID alone is not sufficient to figure
>>> out which statement appears earlier in  a BB. Bootstraps and no test
>>> regressions in x86_64 on linux. Ok for trunk?
>>
>> Why not simply conservatively use gimple_uid (a) <= gimple_uid (b)
>> in not_dominated_by?
>>
>> Richard.
>>
>>
>>
>>> Thanks,
>>> Easwaran
>>>
>>>
>>> 2013-05-23  Easwaran Raman  
>>>
>>> PR tree-optimization/57337
>>> * tree-ssa-reassoc.c (appears_later_in_bb): New function.
>>> (find_insert_point): Correctly identify the insertion point
>>> when two statements with the same UID is compared.
>>>
>>> Index: gcc/tree-ssa-reassoc.c
>>> ===
>>> --- gcc/tree-ssa-reassoc.c  (revision 199211)
>>> +++ gcc/tree-ssa-reassoc.c  (working copy)
>>> @@ -2866,6 +2866,31 @@ not_dominated_by (gimple a, gimple b)
>>>
>>>  }
>>>
>>> +/* Among STMT1 and STMT2, return the statement that appears later.
>Both
>>> +   statements are in same BB and have the same UID.  */
>>> +
>>> +static gimple
>>> +appears_later_in_bb (gimple stmt1, gimple stmt2)
>>> +{
>>> +  unsigned uid = gimple_uid (stmt1);
>>> +  gimple_stmt_iterator gsi = gsi_for_stmt (stmt1);
>>> +  gsi_next (&gsi);
>>> +  if (gsi_end_p (gsi))
>>> +return stmt1;
>>> +  for (; !gsi_end_p (gsi); gsi_next (&gsi))
>>> +{
>>> +  gimple stmt = gsi_stmt (gsi);
>>> +
>>> +  /* If STMT has a different UID than STMT1 and we haven't seen
>>> + STMT2 during traversal, we know STMT1 appears later.  */
>>> +  if (gimple_uid (stmt) != uid)
>>> +return stmt1;
>>> +  else if (stmt == stmt2)
>>> +return stmt2;
>>> +}
>>> +  gcc_unreachable ();
>>> +}
>>> +
>>>  /* Find the statement after which STMT must be moved so that the
>>> dependency from DEP_STMT to STMT is maintained.  */
>>>
>>> @@ -2875,7 +2900,11 @@ find_insert_point (gimple stmt, gimple
>dep_stmt)
>>>gimple insert_stmt = stmt;
>>>if (dep_stmt == NULL)
>>>  return stmt;
>>> -  if (not_dominated_by (insert_stmt, dep_stmt))
>>> +  if (gimple_uid (insert_stmt) == gimple_uid (dep_stmt)
>>> +  && gimple_bb (insert_stmt) == gimple_bb (dep_stmt)
>>> +  && insert_stmt != dep_stmt)
>>> +insert_stmt = appears_later_in_bb (insert_stmt, dep_stmt);
>>> +  else if (not_dominated_by (insert_stmt, dep_stmt))
>>>  insert_stmt = dep_stmt;
>>>return insert_stmt;
>>>  }




[C++ testcase, committed] PR 52216

2013-05-25 Thread Paolo Carlini

Hi,

I'm adding the testcase and closing the bug as fixed for 4.9.0.

Thanks,
Paolo.


2013-05-25  Paolo Carlini  

PR c++/52216
* g++.dg/cpp0x/new1.C: New.
Index: g++.dg/cpp0x/new1.C
===
--- g++.dg/cpp0x/new1.C (revision 0)
+++ g++.dg/cpp0x/new1.C (working copy)
@@ -0,0 +1,8 @@
+// PR c++/52216
+// { dg-require-effective-target c++11 }
+
+#include 
+
+int n;
+
+static_assert(!noexcept(::new (std::nothrow) int[n]), "");


Re: Partial fix for PR opt/55177

2013-05-25 Thread Andreas Schwab
Eric Botcazou  writes:

> /* { dg-do compile { target arm*-*-* alpha*-*-* ia64*-*-* x86_64-*-* 
> s390x-*-* powerpc*-*-* rs6000-*-* } } */

What is the significance of the target selection?

builtin-bswap-9.c fails on ia64, it still generates bswap:DI for foo2,
foo3 and foo4.

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."


[PATCH 1/2] handwritten part of patch

2013-05-25 Thread David Malcolm
Eliminate all direct references to "cfun" from macros in
basic-block.h and introduce access methods to control_flow_graph

* basic-block.h (control_flow_graph::get_basic_block_by_idx): New
accessor methods.
(control_flow_graph::get_entry_block): New method.
(control_flow_graph::get_exit_block): New method.
(control_flow_graph::get_basic_block_info): New methods.
(control_flow_graph::get_n_basic_blocks): New methods.
(control_flow_graph::get_n_edges): New methods.
(control_flow_graph::get_last_basic_block): New methods.
(control_flow_graph::get_label_to_block_map): New methods.
(control_flow_graph::get_profile_status): New method.
(control_flow_graph::set_profile_status): New method.
(ENTRY_BLOCK_PTR): Eliminate this macro.
(EXIT_BLOCK_PTR): Likewise.
(basic_block_info): Likewise.
(n_basic_blocks): Likewise.
(n_edges): Likewise.
(last_basic_block): Likewise.
(label_to_block_map): Likewise.
(profile_status): Likewise.
(BASIC_BLOCK): Likewise.
(SET_BASIC_BLOCK): Likewise.
(FOR_EACH_BB_FN): Rewrite in terms of...
(FOR_EACH_BB_CFG): New macro
(FOR_EACH_BB): Eliminate this macro
(FOR_EACH_BB_REVERSE_FN): Rewrite in terms of...
(FOR_EACH_BB_REVERSE_FN_CFG): New macro
(FOR_EACH_BB_REVERSE): Eliminate this macro
(FOR_ALL_BB): Likewise.
(FOR_ALL_BB_CFG): New macro

---
diff --git a/gcc/basic-block.h b/gcc/basic-block.h
index eed320c..3949417 100644
--- a/gcc/basic-block.h
+++ b/gcc/basic-block.h
@@ -276,6 +276,57 @@ enum profile_status_d
fields of this struct are interpreted as the defines for backward
source compatibility following the definition of this struct.  */
 struct GTY(()) control_flow_graph {
+public:
+  basic_block get_basic_block_by_idx (int idx) const
+  {
+return (*x_basic_block_info)[idx];
+  }
+  void set_basic_block_by_idx (int idx, basic_block bb)
+  {
+(*x_basic_block_info)[idx] = bb;
+  }
+
+  basic_block get_entry_block () const { return x_entry_block_ptr; }
+
+  basic_block get_exit_block () const { return x_exit_block_ptr; }
+
+  vec *get_basic_block_info () const
+  {
+return x_basic_block_info;
+  }
+  vec *&get_basic_block_info ()
+  {
+return x_basic_block_info;
+  }
+
+  int get_n_basic_blocks () const { return x_n_basic_blocks; }
+  int& get_n_basic_blocks () { return x_n_basic_blocks; }
+
+  int get_n_edges () const { return x_n_edges; }
+  int& get_n_edges () { return x_n_edges; }
+
+  int get_last_basic_block () const { return x_last_basic_block; }
+  int& get_last_basic_block () { return x_last_basic_block; }
+
+  vec *get_label_to_block_map () const
+  {
+return x_label_to_block_map;
+  }
+  vec *&get_label_to_block_map ()
+  {
+return x_label_to_block_map;
+  }
+
+  enum profile_status_d get_profile_status () const
+  {
+return x_profile_status;
+  }
+  void set_profile_status (enum profile_status_d status)
+  {
+x_profile_status = status;
+  }
+
+public:
   /* Block pointers for the exit and entry of a function.
  These are always the head and tail of the basic block list.  */
   basic_block x_entry_block_ptr;
@@ -328,32 +379,20 @@ struct GTY(()) control_flow_graph {
 #define SET_BASIC_BLOCK_FOR_FUNCTION(FN,N,BB) \
   ((*basic_block_info_for_function(FN))[(N)] = (BB))
 
-/* Defines for textual backward source compatibility.  */
-#define ENTRY_BLOCK_PTR(cfun->cfg->x_entry_block_ptr)
-#define EXIT_BLOCK_PTR (cfun->cfg->x_exit_block_ptr)
-#define basic_block_info   (cfun->cfg->x_basic_block_info)
-#define n_basic_blocks (cfun->cfg->x_n_basic_blocks)
-#define n_edges(cfun->cfg->x_n_edges)
-#define last_basic_block   (cfun->cfg->x_last_basic_block)
-#define label_to_block_map (cfun->cfg->x_label_to_block_map)
-#define profile_status (cfun->cfg->x_profile_status)
-
-#define BASIC_BLOCK(N) ((*basic_block_info)[(N)])
-#define SET_BASIC_BLOCK(N,BB)  ((*basic_block_info)[(N)] = (BB))
-
 /* For iterating over basic blocks.  */
 #define FOR_BB_BETWEEN(BB, FROM, TO, DIR) \
   for (BB = FROM; BB != TO; BB = BB->DIR)
 
-#define FOR_EACH_BB_FN(BB, FN) \
-  FOR_BB_BETWEEN (BB, (FN)->cfg->x_entry_block_ptr->next_bb, 
(FN)->cfg->x_exit_block_ptr, next_bb)
+#define FOR_EACH_BB_CFG(BB, CFG) \
+  FOR_BB_BETWEEN (BB, (CFG)->x_entry_block_ptr->next_bb, 
(CFG)->x_exit_block_ptr, next_bb)
 
-#define FOR_EACH_BB(BB) FOR_EACH_BB_FN (BB, cfun)
+#define FOR_EACH_BB_FN(BB, FN) FOR_EACH_BB_CFG (BB, (FN)->cfg)
 
-#define FOR_EACH_BB_REVERSE_FN(BB, FN) \
-  FOR_BB_BETWEEN (BB, (FN)->cfg->x_exit_block_ptr->prev_bb, 
(FN)->cfg->x_entry_block_ptr, prev_bb)
+#define FOR_EACH_BB_REVERSE_CFG(BB, CFG) \
+  FOR_BB_BETWEEN (BB, (CFG)->x_exit_block_ptr->prev_bb, 
(CFG)->x_entry_block_ptr, prev_bb)
 
-#define FOR_EACH_BB_REVERSE(BB) FOR_EACH_BB_REVERSE_FN

[PATCH 0/2] Proof-of-concept towards removal of the "cfun" global

2013-05-25 Thread David Malcolm
Here's an idea that could make it easier to remove the "cfun" global.

"cfun" is a major piece of global state within gcc: it's the 5th most
accessed variable in the build (accessed in ~4600 places within one stage
of a build, based on [1]).   This is an obstacle to making gcc's code be
usable as a library.

I can think of three approaches to "cfun":
(a) status quo: a global variable, with macros to prevent direct
assignment, and an API for changing cfun.
(b) have a global "context" or "universe" object, and put cfun in
there (perhaps with tricks to be able to make this a singleton in a
non-library build, optimizing away the context lookups somehow
- see [2] for discussion on this)
(c) go through all of the places where cfun is used, and somehow ensure
that they're passed in the data they need.  Often it's not the
function that's used, but its cfg.

I think (c) is the ideal from a modularity perspective (it unlocks the
ability to have optimization passes be working on different functions in
different threads), but the most difficult.

One part of the puzzle is that various header files in the build define
macros that reference the "cfun" global, e.g.:

  #define n_basic_blocks (cfun->cfg->x_n_basic_blocks)

This one isn't in block caps, which might mislead a new contributor into
thinking it's a variable, rather than a macro, so there may be virtue in
removing these macros for that reason alone.  (I know that these confused
me for a while when I first started writing my plugin) [3]

So I had a go at removing these macros, to make usage of "cfun" be
explicit.

I wrote a script to do most of the gruntwork automatically: [4]

The following patches introduce accessor methods to control_flow_graph,
then remove all of the macros that reference cfun from basic-block.h,
replacing all of the places that use them with explicit uses of
"cfun->cfg->get_foo ()" as appropriate.  There are various other headers
that define macros that use cfun, but I thought I'd post this to get a
sense of how maintainers feel about this approach.

I notice that we're constantly accessing:

  some loop
{
  ...
  use cfun->cfg->x_some_field; 
  ...
}

Would it potentially be faster to replace some of these with:

  control_flow_graph &cfg = *cfun->cfg;
  some loop
{
  ...
  use cfg.get_some_field () // assuming inlining of accessor
  ...
}
  
to avoid constantly derefing cfun->cfg?  (That said, would
 -fstrict-aliasing
be able to note that cfun->cfg doesn't change, or in a non-LTO build I'm
guessing it can't make that assumption if the loop calls into functions it
can't see inside?).

I bootstrapped and tested the following on x86_64-unknown-linux-gnu
against r199323, and it has the same test results as an unpatched
bootstrap of that revision.

If expanded to cover the other header files, this approach would at least
make it explicit when we're using cfun, which may make approach (c) easier
to implement (the "pass around the data we need" approach).

(Potentially the fields in control_flow_graph could be made private also,
but I haven't tested that out yet)

Thoughts?
Dave

[1] http://gcc.gnu.org/ml/gcc/2013-05/msg00015.html
[2] http://gcc.gnu.org/ml/gcc-patches/2013-05/msg01318.html
[3] As an extra wrinkle, in testsuite/gcc.dg/tree-ssa/20041122-1.c there's a:
  extern int n_basic_blocks;
that genuinely is a variable.
[4] 
https://github.com/davidmalcolm/gcc-refactoring-scripts/blob/master/refactor_cfun.py
 along with a test suite:
https://github.com/davidmalcolm/gcc-refactoring-scripts/blob/master/test_refactor_cfun.py

David Malcolm (2):
  handwritten
  autogenerated

 gcc/ChangeLog| 634 +++
 gcc/alias.c  |   4 +-
 gcc/asan.c   |   4 +-
 gcc/auto-inc-dec.c   |   2 +-
 gcc/basic-block.h|  82 ++--
 gcc/bb-reorder.c |  84 ++--
 gcc/bt-load.c|  46 +--
 gcc/caller-save.c|   8 +-
 gcc/cfg.c|  56 +--
 gcc/cfganal.c| 124 +++---
 gcc/cfgbuild.c   |  34 +-
 gcc/cfgcleanup.c |  68 ++--
 gcc/cfgexpand.c  |  90 ++---
 gcc/cfghooks.c   |  38 +-
 gcc/cfgloop.c|  52 +--
 gcc/cfgloopanal.c|  14 +-
 gcc/cfgloopmanip.c   |  24 +-
 gcc/cfgrtl.c | 214 +--
 gcc/cgraphbuild.c|  10 +-
 gcc/cgraphunit.c |   8 +-
 gcc/combine-stack-adj.c  |   2 +-
 gcc/combine.c|  28 +-
 gcc/compare-elim.c   |   2 +-
 gcc/config/alpha/alpha.c |   2 +-
 gcc/config/arm/arm.c |   

[PATCH 2/2] autogenerated part of patch

2013-05-25 Thread David Malcolm
This patch is 547K in size, so I've uploaded it to:

http://dmalcolm.fedorapeople.org/gcc/large-patches/928e2d33daafe1943766dfb437f6ba7b795dfa41-0002-autogenerated-part-of-cfun-expansion.patch

Patch autogenerated by refactor_cfun.py from
https://github.com/davidmalcolm/gcc-refactoring-scripts
revision 3badf4e33b0f66e4c9276efedd4e7f4cb6117f12
(the revision quoted in the ChangeLog is off-by-one)

There's a slight bug in the ChangeLog generation affecting the filenames
in testsuite/ChangeLog

The script doesn't yet check/update copyright years in files that it
touches.


Re: Partial fix for PR opt/55177

2013-05-25 Thread Eric Botcazou
> What is the significance of the target selection?

Copied from optimize-bswapdi-1.c, but I should probably have copied it from 
optimize-bswapsi-1.c for the bswapsi case.  Will adjust.

> builtin-bswap-9.c fails on ia64, it still generates bswap:DI for foo2,
> foo3 and foo4.

OK, I'll take a look.

-- 
Eric Botcazou


[committed] PR 55777: inlining nomips16 into mips16

2013-05-25 Thread Richard Sandiford
This patch prevents inlining between functions of different ISA modes.

Tested on mips64-linux-gnu and applied.

Richard


gcc/
PR target/55777
* config/mips/mips.c (mips_can_inline_p): New function.
(TARGET_CAN_INLINE_P): Define.

gcc/testsuite/
PR target/55777
* gcc.target/mips/mips16-attributes-5.c,
* gcc.target/mips/mips16-attributes-6.c: New tests.

Index: gcc/config/mips/mips.c
===
--- gcc/config/mips/mips.c  2013-05-21 19:20:41.821261620 +0100
+++ gcc/config/mips/mips.c  2013-05-25 09:35:42.073502492 +0100
@@ -1426,6 +1426,16 @@ mips_merge_decl_attributes (tree olddecl
   return merge_attributes (DECL_ATTRIBUTES (olddecl),
   DECL_ATTRIBUTES (newdecl));
 }
+
+/* Implement TARGET_CAN_INLINE_P.  */
+
+static bool
+mips_can_inline_p (tree caller, tree callee)
+{
+  if (mips_get_compress_mode (callee) != mips_get_compress_mode (caller))
+return false;
+  return default_target_can_inline_p (caller, callee);
+}
 
 /* If X is a PLUS of a CONST_INT, return the two terms in *BASE_PTR
and *OFFSET_PTR.  Return X in *BASE_PTR and 0 in *OFFSET_PTR otherwise.  */
@@ -18600,6 +18610,8 @@ #define TARGET_FUNCTION_OK_FOR_SIBCALL m
 #define TARGET_INSERT_ATTRIBUTES mips_insert_attributes
 #undef TARGET_MERGE_DECL_ATTRIBUTES
 #define TARGET_MERGE_DECL_ATTRIBUTES mips_merge_decl_attributes
+#undef TARGET_CAN_INLINE_P
+#define TARGET_CAN_INLINE_P mips_can_inline_p
 #undef TARGET_SET_CURRENT_FUNCTION
 #define TARGET_SET_CURRENT_FUNCTION mips_set_current_function
 
Index: gcc/testsuite/gcc.target/mips/mips16-attributes-5.c
===
--- /dev/null   2013-05-20 18:02:16.162117076 +0100
+++ gcc/testsuite/gcc.target/mips/mips16-attributes-5.c 2013-05-25 
09:44:44.576251467 +0100
@@ -0,0 +1,22 @@
+/* { dg-do compile } */
+/* { dg-options "(-mips16) addressing=absolute" } */
+/* { dg-skip-if "requires inlining" { *-*-* } { "-O0" } { "" } } */
+
+static inline MIPS16 int i1 (void) { return 1; }
+static inline NOMIPS16 int i2 (void) { return 2; }
+static inline MIPS16 int i3 (void) { return 3; }
+static inline NOMIPS16 int i4 (void) { return 4; }
+
+int NOMIPS16 f1 (void) { return i1 (); }
+int MIPS16 f2 (void) { return i2 (); }
+int MIPS16 f3 (void) { return i3 (); }
+int NOMIPS16 f4 (void) { return i4 (); }
+
+/* { dg-final { scan-assembler "i1:" } } */
+/* { dg-final { scan-assembler "i2:" } } */
+/* { dg-final { scan-assembler-not "i3:" } } */
+/* { dg-final { scan-assembler-not "i4:" } } */
+/* { dg-final { scan-assembler "\tjal\ti1" } } */
+/* { dg-final { scan-assembler "\tjal\ti2" } } */
+/* { dg-final { scan-assembler-not "\tjal\ti3" } } */
+/* { dg-final { scan-assembler-not "\tjal\ti4" } } */
Index: gcc/testsuite/gcc.target/mips/mips16-attributes-6.c
===
--- /dev/null   2013-05-20 18:02:16.162117076 +0100
+++ gcc/testsuite/gcc.target/mips/mips16-attributes-6.c 2013-05-25 
09:50:55.531807654 +0100
@@ -0,0 +1,13 @@
+/* { dg-do compile } */
+/* { dg-options "-mips16 addressing=absolute -mips3d" } */
+
+static inline NOMIPS16 float
+i1 (float f)
+{
+  return __builtin_mips_recip1_s (f);
+}
+
+float f1 (float f) { return i1 (f); }
+
+/* { dg-final { scan-assembler "\trecip1.s\t" } } */
+/* { dg-final { scan-assembler "\tjal\ti1" } } */


[committed] PR 53916: divmod not effective for MIPS16

2013-05-25 Thread Richard Sandiford
PR 53916 was originally about a wrong-code division bug in 4.6 and earlier.
Although that in itself has been fixed, the reported pointed out that the
new code isn't able to reuse the same MIPS16 instruction for both division
and modulus results.  The problem is that, for MIPS16, we now expose the
(fixed) LO register from the outset, which stops the rtl optimisers
from reusing the result of an earlier instruction.

As explained in the comment, this patch hides the LO register until
after CSE, but still tries to expose it before register allocation.

Tested on mips64-linux-gnu and applied.

Richard


gcc/
PR target/53916
* config/mips/constraints.md (kl): New constraint.
* config/mips/mips.md (divmod4, udivmod4): Delete.
(divmod4_internal): Rename to divmod4.  Use "kl" as the
constraint for operand 0.  Split after CSE for MIPS16.  Emit a move
from LO for MIPS16.
(udivmod4_internal): Likewise udivmod4.

gcc/testsuite/
PR target/53916
* gcc.target/mips/div-13.c: New test.

Index: gcc/config/mips/constraints.md
===
--- gcc/config/mips/constraints.md  2013-05-25 12:15:32.050687848 +0100
+++ gcc/config/mips/constraints.md  2013-05-25 12:19:29.723476968 +0100
@@ -92,6 +92,12 @@ (define_register_constraint "D" "COP3_RE
 ;; but the DSP version allows any accumulator target.
 (define_register_constraint "ka" "ISA_HAS_DSP_MULT ? ACC_REGS : MD_REGS")
 
+;; The register class to use for an allocatable division result.
+;; MIPS16 uses M16_REGS because LO is fixed.
+(define_register_constraint "kl"
+  "TARGET_MIPS16 ? M16_REGS : TARGET_BIG_ENDIAN ? MD1_REG : MD0_REG"
+  "@internal")
+
 (define_constraint "kf"
   "@internal"
   (match_operand 0 "force_to_mem_operand"))
Index: gcc/config/mips/mips.md
===
--- gcc/config/mips/mips.md 2013-05-25 12:14:10.900077754 +0100
+++ gcc/config/mips/mips.md 2013-05-25 12:15:14.393555017 +0100
@@ -2560,80 +2560,50 @@ (define_insn "*recip3"
 
 ;; VR4120 errata MD(A1): signed division instructions do not work correctly
 ;; with negative operands.  We use special libgcc functions instead.
-(define_expand "divmod4"
-  [(set (match_operand:GPR 0 "register_operand")
-   (div:GPR (match_operand:GPR 1 "register_operand")
-(match_operand:GPR 2 "register_operand")))
-   (set (match_operand:GPR 3 "register_operand")
-   (mod:GPR (match_dup 1)
-(match_dup 2)))]
-  "!TARGET_FIX_VR4120"
-{
-  if (TARGET_MIPS16)
-{
-  emit_insn (gen_divmod4_split (operands[3], operands[1],
- operands[2]));
-  emit_move_insn (operands[0], gen_rtx_REG (mode, LO_REGNUM));
-}
-  else
-emit_insn (gen_divmod4_internal (operands[0], operands[1],
-  operands[2], operands[3]));
-  DONE;
-})
-
-(define_insn_and_split "divmod4_internal"
-  [(set (match_operand:GPR 0 "muldiv_target_operand" "=l")
+;;
+;; Expand generates divmod instructions for individual division and modulus
+;; operations.  We then rely on CSE to reuse earlier divmods where possible.
+;; This means that, when generating MIPS16 code, it is better not to expose
+;; the fixed LO register until after CSE has finished.  However, it's still
+;; better to split before register allocation, so that we don't allocate
+;; one of the scarce MIPS16 registers to an unused result.
+(define_insn_and_split "divmod4"
+  [(set (match_operand:GPR 0 "register_operand" "=kl")
(div:GPR (match_operand:GPR 1 "register_operand" "d")
 (match_operand:GPR 2 "register_operand" "d")))
(set (match_operand:GPR 3 "register_operand" "=d")
(mod:GPR (match_dup 1)
 (match_dup 2)))]
-  "!TARGET_FIX_VR4120 && !TARGET_MIPS16"
+  "!TARGET_FIX_VR4120"
   "#"
-  "&& reload_completed"
+  "&& ((TARGET_MIPS16 && cse_not_expected) || reload_completed)"
   [(const_int 0)]
 {
   emit_insn (gen_divmod4_split (operands[3], operands[1], operands[2]));
+  if (TARGET_MIPS16)
+emit_move_insn (operands[0], gen_rtx_REG (mode, LO_REGNUM));
   DONE;
 }
  [(set_attr "type" "idiv")
   (set_attr "mode" "")
   (set_attr "length" "8")])
 
-(define_expand "udivmod4"
-  [(set (match_operand:GPR 0 "register_operand")
-   (udiv:GPR (match_operand:GPR 1 "register_operand")
- (match_operand:GPR 2 "register_operand")))
-   (set (match_operand:GPR 3 "register_operand")
-   (umod:GPR (match_dup 1)
- (match_dup 2)))]
-  ""
-{
-  if (TARGET_MIPS16)
-{
-  emit_insn (gen_udivmod4_split (operands[3], operands[1],
-  operands[2]));
-  emit_move_insn (operands[0], gen_rtx_REG (mode, LO_REGNUM));
-}
-  else
-emit_insn (gen_udivmod4_internal (operands[0], operands[1],
-   operands[2], operands[3]));
- 

gcc-patches@gcc.gnu.org

2013-05-25 Thread Richard Sandiford
Tidy some mips.h preprocessor goo now that we're allowed to use #elif.

Tested on mips64-linux-gnu and applied.

Richard


gcc/
* config/mips/mips.h: Use #elif in preprocessor conditions.

Index: gcc/config/mips/mips.h
===
--- gcc/config/mips/mips.h  2013-05-25 12:14:10.833077251 +0100
+++ gcc/config/mips/mips.h  2013-05-25 12:15:51.269832461 +0100
@@ -614,39 +614,25 @@ #define MULTILIB_ENDIAN_DEFAULT "EB"
 #endif
 
 #ifndef MULTILIB_ISA_DEFAULT
-#  if MIPS_ISA_DEFAULT == 1
-#define MULTILIB_ISA_DEFAULT "mips1"
-#  else
-#if MIPS_ISA_DEFAULT == 2
-#  define MULTILIB_ISA_DEFAULT "mips2"
-#else
-#  if MIPS_ISA_DEFAULT == 3
-#define MULTILIB_ISA_DEFAULT "mips3"
-#  else
-#if MIPS_ISA_DEFAULT == 4
-#  define MULTILIB_ISA_DEFAULT "mips4"
-#else
-#  if MIPS_ISA_DEFAULT == 32
-#define MULTILIB_ISA_DEFAULT "mips32"
-#  else
-#if MIPS_ISA_DEFAULT == 33
-#  define MULTILIB_ISA_DEFAULT "mips32r2"
-#else
-#  if MIPS_ISA_DEFAULT == 64
-#define MULTILIB_ISA_DEFAULT "mips64"
-#  else
-#   if MIPS_ISA_DEFAULT == 65
-# define MULTILIB_ISA_DEFAULT "mips64r2"
-#   else
-#  define MULTILIB_ISA_DEFAULT "mips1"
-#   endif
-#  endif
-#endif
-#  endif
-#endif
-#  endif
-#endif
-#  endif
+#if MIPS_ISA_DEFAULT == 1
+#define MULTILIB_ISA_DEFAULT "mips1"
+#elif MIPS_ISA_DEFAULT == 2
+#define MULTILIB_ISA_DEFAULT "mips2"
+#elif MIPS_ISA_DEFAULT == 3
+#define MULTILIB_ISA_DEFAULT "mips3"
+#elif MIPS_ISA_DEFAULT == 4
+#define MULTILIB_ISA_DEFAULT "mips4"
+#elif MIPS_ISA_DEFAULT == 32
+#define MULTILIB_ISA_DEFAULT "mips32"
+#elif MIPS_ISA_DEFAULT == 33
+#define MULTILIB_ISA_DEFAULT "mips32r2"
+#elif MIPS_ISA_DEFAULT == 64
+#define MULTILIB_ISA_DEFAULT "mips64"
+#elif MIPS_ISA_DEFAULT == 65
+#define MULTILIB_ISA_DEFAULT "mips64r2"
+#else
+#define MULTILIB_ISA_DEFAULT "mips1"
+#endif
 #endif
 
 #ifndef MIPS_ABI_DEFAULT
@@ -657,21 +643,13 @@ #define MIPS_ABI_DEFAULT ABI_32
 
 #if MIPS_ABI_DEFAULT == ABI_32
 #define MULTILIB_ABI_DEFAULT "mabi=32"
-#endif
-
-#if MIPS_ABI_DEFAULT == ABI_O64
+#elif MIPS_ABI_DEFAULT == ABI_O64
 #define MULTILIB_ABI_DEFAULT "mabi=o64"
-#endif
-
-#if MIPS_ABI_DEFAULT == ABI_N32
+#elif MIPS_ABI_DEFAULT == ABI_N32
 #define MULTILIB_ABI_DEFAULT "mabi=n32"
-#endif
-
-#if MIPS_ABI_DEFAULT == ABI_64
+#elif MIPS_ABI_DEFAULT == ABI_64
 #define MULTILIB_ABI_DEFAULT "mabi=64"
-#endif
-
-#if MIPS_ABI_DEFAULT == ABI_EABI
+#elif MIPS_ABI_DEFAULT == ABI_EABI
 #define MULTILIB_ABI_DEFAULT "mabi=eabi"
 #endif
 
@@ -743,9 +721,9 @@ #define MIPS_32BIT_OPTION_SPEC \
 #define MIPS_ISA_SYNCI_SPEC \
   "%{msynci|mno-synci:;:%{mips32r2|mips64r2:-msynci;:-mno-synci}}"
 
-#if MIPS_ABI_DEFAULT == ABI_O64 \
-  || MIPS_ABI_DEFAULT == ABI_N32 \
-  || MIPS_ABI_DEFAULT == ABI_64
+#if (MIPS_ABI_DEFAULT == ABI_O64 \
+ || MIPS_ABI_DEFAULT == ABI_N32 \
+ || MIPS_ABI_DEFAULT == ABI_64)
 #define OPT_ARCH64 "mabi=32|mgp32:;"
 #define OPT_ARCH32 "mabi=32|mgp32"
 #else
@@ -1365,8 +1343,8 @@ #define LONG_LONG_ACCUM_TYPE_SIZE (TARGE
 #define MAX_FIXED_MODE_SIZE LONG_DOUBLE_TYPE_SIZE
 
 #ifdef IN_LIBGCC2
-#if  (defined _ABIN32 && _MIPS_SIM == _ABIN32) \
-  || (defined _ABI64 && _MIPS_SIM == _ABI64)
+#if ((defined _ABIN32 && _MIPS_SIM == _ABIN32) \
+ || (defined _ABI64 && _MIPS_SIM == _ABI64))
 #  define LIBGCC2_LONG_DOUBLE_TYPE_SIZE 128
 # else
 #  define LIBGCC2_LONG_DOUBLE_TYPE_SIZE 64
@@ -2872,9 +2850,8 @@ #define CRT_CALL_STATIC_FUNCTION(SECTION
jal " USER_LABEL_PREFIX #FUNC "\n\
.set pop\n\
" TEXT_SECTION_ASM_OP);
-#endif /* Switch to #elif when we're no longer limited by K&R C.  */
-#if (defined _ABIN32 && _MIPS_SIM == _ABIN32) \
-   || (defined _ABI64 && _MIPS_SIM == _ABI64)
+#elif ((defined _ABIN32 && _MIPS_SIM == _ABIN32) \
+   || (defined _ABI64 && _MIPS_SIM == _ABI64))
 #define CRT_CALL_STATIC_FUNCTION(SECTION_OP, FUNC) \
asm (SECTION_OP "\n\
.set push\n\


Re: [PATCH] Fix incorrect discriminator assignment.

2013-05-25 Thread Eric Botcazou
> gcc/ChangeLog:
> 
> * tree-cfg.c (locus_descrim_hasher::hash): Only hash lineno.
> (locus_descrim_hasher::equal): Likewise.
> (next_discriminator_for_locus): Likewise.
> (assign_discriminator): Add return value.
> (make_edges): Assign more discriminator if necessary.
> (make_cond_expr_edges): Likewise.
> (make_goto_expr_edges): Likewise.
> 
> gcc/testsuite/ChangeLog:
> 
> * gcc.dg/debug/dwarf2/discriminator.c: New Test.

The above ChangeLog entries are good, but the ones you installed aren't (wrong 
gcc/ prefix, wrong location for the testsuite entry, several typos, etc).

Please fix.

-- 
Eric Botcazou


Simplify (double)i != 0

2013-05-25 Thread Marc Glisse

Hello,

this patch only handles the simple case where the constant is 0, I'll keep 
the PR open for the more general case. Note that if we split 
flag_trapping_math into no|weak|strict, the test here would be !=strict, 
since we only remove trapping operations.


Passes bootstrap+testsuite on x86_64-linux-gnu.

2013-05-27  Marc Glisse  

PR tree-optimization/57371
gcc/
* fold-const.c (fold_comparison): Fold comparison of a FLOAT_EXPR
with 0.

gcc/testsuite/
* gcc.dg/pr57371-1.c: New testcase.
* gcc.dg/pr57371-2.c: Likewise.
* gcc.dg/pr57371-3.c: Likewise.

--
Marc GlisseIndex: fold-const.c
===
--- fold-const.c(revision 199323)
+++ fold-const.c(working copy)
@@ -9362,20 +9362,38 @@ fold_comparison (location_t loc, enum tr
}
 
  /* Fold comparisons against infinity.  */
  if (REAL_VALUE_ISINF (cst)
  && MODE_HAS_INFINITIES (TYPE_MODE (TREE_TYPE (arg1
{
  tem = fold_inf_compare (loc, code, type, arg0, arg1);
  if (tem != NULL_TREE)
return tem;
}
+
+ /* (double)i CMP 0 is just i CMP 0.  See PR 57371 for how this
+can be extended to non-zero constants.  */
+ if (TREE_CODE (arg0) == FLOAT_EXPR && real_zerop (arg1))
+   {
+ tree inner = TREE_OPERAND (arg0, 0);
+ tree itype = TREE_TYPE (inner);
+ tree ftype = TREE_TYPE (arg0);
+ /* If ftype cannot represent exactly all values of itype,
+we may have an inexact exception.  If the conversion from
+itype to ftype may overflow (unsigned __int128 to float),
+we may have an overflow exception.  */
+ if (!flag_trapping_math
+ || (unsigned) significand_size (TYPE_MODE (ftype))
+>= element_precision (itype) - !TYPE_UNSIGNED (itype))
+   return fold_build2_loc (loc, code, type, inner,
+   build_zero_cst (itype));
+   }
}
 
   /* If this is a comparison of a real constant with a PLUS_EXPR
 or a MINUS_EXPR of a real constant, we can convert it into a
 comparison with a revised real constant as long as no overflow
 occurs when unsafe_math_optimizations are enabled.  */
   if (flag_unsafe_math_optimizations
  && TREE_CODE (arg1) == REAL_CST
  && (TREE_CODE (arg0) == PLUS_EXPR
  || TREE_CODE (arg0) == MINUS_EXPR)
Index: testsuite/gcc.dg/pr57371-3.c
===
--- testsuite/gcc.dg/pr57371-3.c(revision 0)
+++ testsuite/gcc.dg/pr57371-3.c(revision 0)
@@ -0,0 +1,11 @@
+/* { dg-do compile } */
+/* { dg-options "-O -fdump-tree-optimized -ftrapping-math" } */
+
+int f (unsigned long long x)
+{
+  float y = x;
+  return y <= 0;
+}
+
+/* { dg-final { scan-tree-dump "float" "optimized" } } */
+/* { dg-final { cleanup-tree-dump "optimized" } } */

Property changes on: testsuite/gcc.dg/pr57371-3.c
___
Added: svn:keywords
   + Author Date Id Revision URL
Added: svn:eol-style
   + native

Index: testsuite/gcc.dg/pr57371-1.c
===
--- testsuite/gcc.dg/pr57371-1.c(revision 0)
+++ testsuite/gcc.dg/pr57371-1.c(revision 0)
@@ -0,0 +1,11 @@
+/* { dg-do compile } */
+/* { dg-options "-O -fdump-tree-optimized -ftrapping-math" } */
+
+int f (char x)
+{
+  long double y = x;
+  return y <= 0;
+}
+
+/* { dg-final { scan-tree-dump-not "double" "optimized" } } */
+/* { dg-final { cleanup-tree-dump "optimized" } } */

Property changes on: testsuite/gcc.dg/pr57371-1.c
___
Added: svn:keywords
   + Author Date Id Revision URL
Added: svn:eol-style
   + native

Index: testsuite/gcc.dg/pr57371-2.c
===
--- testsuite/gcc.dg/pr57371-2.c(revision 0)
+++ testsuite/gcc.dg/pr57371-2.c(revision 0)
@@ -0,0 +1,11 @@
+/* { dg-do compile } */
+/* { dg-options "-O -fdump-tree-optimized -fno-trapping-math" } */
+
+int f (unsigned long long x)
+{
+  float y = x;
+  return y <= 0;
+}
+
+/* { dg-final { scan-tree-dump-not "float" "optimized" } } */
+/* { dg-final { cleanup-tree-dump "optimized" } } */

Property changes on: testsuite/gcc.dg/pr57371-2.c
___
Added: svn:eol-style
   + native
Added: svn:keywords
   + Author Date Id Revision URL



Re: [patch] Default to --enable-libstdcxx-time=auto

2013-05-25 Thread Benjamin De Kosnik

> > It scraps the renaming/aliasing approach, and just creates a
> > compatibility-chrono.cc that mimics the default configuration in
> > 4.8.0.
> 
> Yeah, I think that is reasonable, with one nit, see below.

Cool, incorporated.
 
> > Users who specially-configured a build with --enable-libstdcxx-time
> > configure options in 4.8.0 are breaking an experimental
> > C++ ABI anyway, so I'm not going to solve for anything but the
> > default case.
> > 
> > For chrono.cc, there is an inline namespace that mangles
> > system_clock and steady_clock in a new way to prevent ambiguous
> > uses. In addition, I make a controversial decision and just
> > forward-declare clocks that libstdc++ cannot do correctly, instead
> > of using typedefs that clearly are only going to get us into
> > trouble as we change things down the road. That's probably only
> > appropriate for trunk.
> 
> > +// To support the (forward) evolving definition of the
> > library's
> > +// defined clocks, wrap inside inline namespace so that these
> > +// types are uniquely mangled. This way, new code can use the
> > +// current clocks, while the library can contain old
> > definitions.
> > +// At some point, when these clocks settle down, the inlined
> > +// namespaces can be removed.
> > +// XXX GLIBCXX_ABI Deprecated
> > +inline namespace _V2 {
> > +
> >  /// system_clock
> >  struct system_clock
> >  {
> 
> In this _V2 inline namespace, I think we should change that:
> struct system_clock
> {
> #ifdef _GLIBCXX_USE_CLOCK_REALTIME
>   typedef chrono::nanoseconds
> duration; #elif defined(_GLIBCXX_USE_GETTIMEOFDAY)
>   typedef chrono::microseconds
> duration; #else
>   typedef chrono::seconds
> duration; #endif
> into:
> struct system_clock
> {
>   typedef chrono::nanoseconds
> duration;
> 
> Won't the templates then DTRT in:
>   return time_point(duration(chrono::seconds(tv.tv_sec)
>   + chrono::microseconds(tv.tv_usec)));
> (multiply microseconds by 1000 and seconds by 10)
>   return system_clock::from_time_t(__sec);
> (multiply seconds by 10)?

Yes.
 
> While this change isn't really necessary for Linux, where usually
> _GLIBCXX_USE_CLOCK_REALTIME will be in 4.8.1+ defined and thus the
> nanoseconds resolution will be used anyway, on other OSes it might
> be already a problem, say on Solaris or FreeBSD GCC 4.8.1 will have
> by default likely microseconds resolution, while on the trunk
> nanoseconds. By making it always count in nanoseconds, even if on
> some OSes the low 3 or 9 decimal digits will be always zero, we'd
> prepared to change the system_clock::now() implementation any time to
> provide better resolution, as a libstdc++ internal implementation
> detail.
> 
> Or is this undesirable for users for some reason?

I think your rationale is sound here. I've added some of these comments
to the code.

> 
> > @@ -742,10 +751,18 @@ _GLIBCXX_END_NAMESPACE_VERSION
> >now() noexcept;
> >  };
> >  #else
> > -typedef system_clock steady_clock;
> > +// Forward declare only.
> > +struct steady_clock;
> >  #endif
> >  
> > +#ifdef _GLIBCXX_USE_CLOCK_REALTIME
> >  typedef system_clock high_resolution_clock;
> > +#else
> > +// Forward declare only.
> > +struct high_resolution_clock;
> > +#endif
> > +
> > +  } // end inline namespace _V2
> 
> Yeah, I bet this hunk should be left out from 4.8.1 version of the
> patch.

I did something different, anyway.

Un-guardedly declare the clocks, and then just use the definitions in
the .cc file to define QoI. That way there is a symbol exported in all
configs, but one that can be improve in the future w/o pain. 

> Perhaps we also want some testcase that will roughly test it, like
> grab time(NULL), std::chrono::system_clock::now() and
> std::chrono::steady_clock::now(), then sleep(3), grab both clocks
> again and time(NULL) last, then if the difference between time() is
> at least 2 seconds and less than say 10, verify the difference
> between the clocks is say in a 1 to 20 seconds interval (yeah, it
> could fail badly if one changes system time in between once or
> several times)?  But maybe it would be too flakey.

Agreed, certainly room for improvement. Let's separate out this part
though.

I'm tempted to check this patch into trunk. Jakub?

tested x86_64/linux

-benjamin
2013-05-24  Benjamin Kosnik  

* include/std/chrono: Wrap clocks in inline namespace _V2.
* src/c++11/chrono.cc: Same.
* src/c++11/compatibility-chrono.cc: Revert to previous chrono.cc
file, with default configure macros selected.

* config/abi/pre/gnu.ver (GLIBCXX_3.4.19): Use symbols from inline
namespace.
* config/abi/post/x86_64-linux-gnu/baseline_symbols.txt: Fix up.

* config/abi/post/i386-linux-gnu/baseline_symbols.txt: Regenerated.
* config/abi/post/s390x-linux-gnu/baseline_symbols.txt: Regenerated.
* config/

Re: [patch] Default to --enable-libstdcxx-time=auto

2013-05-25 Thread Jakub Jelinek
On Sat, May 25, 2013 at 11:56:31AM -0700, Benjamin De Kosnik wrote:
> I'm tempted to check this patch into trunk. Jakub?

Looks good to me.  Will you prepare corresponding patch for the 4.8 branch
too (I guess it should be pretty much the same, not sure if it should keep
using typedef system_clock steady_clock as before for the non-MONOTONIC
configuration, or if it should just do the same thing as trunk)?

Thanks.

Jakub


Re: [PATCH 0/2] Proof-of-concept towards removal of the "cfun" global

2013-05-25 Thread Jan Hubicka
> Here's an idea that could make it easier to remove the "cfun" global.
> 
> "cfun" is a major piece of global state within gcc: it's the 5th most
> accessed variable in the build (accessed in ~4600 places within one stage
> of a build, based on [1]).   This is an obstacle to making gcc's code be
> usable as a library.

Yep, note that cfun is not the only beast of this.  For 99% of backend it needs
to be kept in sync with current_function_decl pointing to the declaration such
that DECL_STRUCT_FUNCTION (current_function_decl) = cfun.
There is also implicit notion of "current cgraph node" that is accessed by
cgraph_get_node (current_function_decl) many times that can get expensive
since it leads to hashtable lookup.
Finally there is "crtl" that is macro hidding a global variable x_rtl
data for RTL data of the currently compiled function.

In many ways these four are all closely related and data in between them
are not distributed in very engineered way.
> 
> I can think of three approaches to "cfun":
> (a) status quo: a global variable, with macros to prevent direct
> assignment, and an API for changing cfun.

We have push_cfun/pop_cfun for that.  If you did not look into what they
really do, you may be disappointed. They are huge&expensive beasts switching
a lot of global state in compiler for optimize attribute.  So it means that
on the track removing them we will need to cleanup this area, too.

> (b) have a global "context" or "universe" object, and put cfun in
> there (perhaps with tricks to be able to make this a singleton in a
> non-library build, optimizing away the context lookups somehow
> - see [2] for discussion on this)
> (c) go through all of the places where cfun is used, and somehow ensure
> that they're passed in the data they need.  Often it's not the
> function that's used, but its cfg.
> 
> I think (c) is the ideal from a modularity perspective (it unlocks the
> ability to have optimization passes be working on different functions in
> different threads), but the most difficult.

(c) is direction I was trying to push IPA code to in longer run.  We need
a single object holding "function" and that should be passed to most
of the macros.

I am not entirely happy with contents of the "struct function" at all
(it is kind of kitchen sink for all the data we randomly need to associate
with function), but it is closest to it. Most of IPA node considers the
ultimate function pointer to be the cgraph node however.

We do not want to melt those all thogether, since the data in there have 
different
lifetime.  In particular struct_function is not in memory during WPA.
> 
> One part of the puzzle is that various header files in the build define
> macros that reference the "cfun" global, e.g.:
> 
>   #define n_basic_blocks (cfun->cfg->x_n_basic_blocks)
> 
> This one isn't in block caps, which might mislead a new contributor into
> thinking it's a variable, rather than a macro, so there may be virtue in

Yep yo umany notice there are already _FN variants for that.  The macors
are lower case since historically they were variables. I agree they should
be replaced.

> removing these macros for that reason alone.  (I know that these confused
> me for a while when I first started writing my plugin) [3]
> 
> So I had a go at removing these macros, to make usage of "cfun" be
> explicit.
> 
> I wrote a script to do most of the gruntwork automatically: [4]
> 
> The following patches introduce accessor methods to control_flow_graph,
> then remove all of the macros that reference cfun from basic-block.h,
> replacing all of the places that use them with explicit uses of
> "cfun->cfg->get_foo ()" as appropriate.  There are various other headers
> that define macros that use cfun, but I thought I'd post this to get a
> sense of how maintainers feel about this approach.
> 
> I notice that we're constantly accessing:
> 
>   some loop
> {
>   ...
>   use cfun->cfg->x_some_field; 
>   ...
> }
> 
> Would it potentially be faster to replace some of these with:
> 
>   control_flow_graph &cfg = *cfun->cfg;
>   some loop
> {
>   ...
>   use cfg.get_some_field () // assuming inlining of accessor
>   ...
> }
>   
> to avoid constantly derefing cfun->cfg?  (That said, would
>  -fstrict-aliasing
> be able to note that cfun->cfg doesn't change, or in a non-LTO build I'm
> guessing it can't make that assumption if the loop calls into functions it
> can't see inside?).

I like the general direction (i.e. it is what I was hoping for to happen for
years, but was too lazy to enforce it more curefully).
We should have single "function" object that is passed around and it should
have substructures or pointers to all the various stuff we hold about function
globally (gimple body, cfg, loop tree, profile, IPA data).

Just some random toughts. I epxect there will be more discussion ;)
Honza


Re: [patch] Default to --enable-libstdcxx-time=auto

2013-05-25 Thread Benjamin De Kosnik

> Looks good to me.  

Great, trunk patch in.

> Will you prepare corresponding patch for the 4.8
> branch too (I guess it should be pretty much the same, not sure if it
> should keep using typedef system_clock steady_clock as before for the
> non-MONOTONIC configuration, or if it should just do the same thing
> as trunk)?

Same thing, I think. Testing now, ok when it completes?

-benjamin


Re: [SH] PR 6526

2013-05-25 Thread Kaz Kojima
Oleg Endo  wrote:
> I'd like to fix this ancient PR.
> The attached patch picks up the suggested changes mentioned in comment
> #3 to avoid changing the FPSCR.FR bit in the sdivsi3_i4 and udivsi3_i4
> library functions.  As mentioned in the PR, this makes integer division
> a bit slower when using -mdiv=call-fp, but it allows better utilization
> of the SH4 matrix multiplication feature.
> I've also added SH4A versions of the library functions which utilize the
> fpchg instruction.
> 
> 
> Tested on rev 199102 with
> make -k check RUNTESTFLAGS="--target_board=sh-sim
> \{-m4/-mb/-mdiv=call-fp,-m4-single/-mb/-mdiv=call-fp,-m4a/-mb/-mdiv=call-fp,
> -m4a-single/-mb/-mdiv=call-fp,-m4/-ml/-mdiv=call-fp,
> -m4-single/-ml/-mdiv=call-fp,-m4a/-ml/-mdiv=call-fp,
> -m4a-single/-ml/-mdiv=call-fp}"
> 
> and no new failures.
> 
> OK for trunk?

OK.

Regards,
kaz


Re: PR tree-optimization/57337

2013-05-25 Thread Easwaran Raman
On Sat, May 25, 2013 at 4:46 AM, Richard Biener
 wrote:
> Easwaran Raman  wrote:
>
>>In that case, if my insert_stmt immediately follows dep_stmt and both
>>have the same UID, not_dominated_by would return true and I will end
>>up updating insert_stmt to dep_stmt which is wrong.
>
> But there should be a safe default answer for
> Equal uids. Unless we are asking different questions in different places.
> Thus, I do not like the stmt walking but rather have a safe fallback.

I am lost here. I don't see how we could avoid doing the stmt walking
to resolve the equal uid case. How to ensure that not_dominated_by (a,
b) returns true and not_dominated_by (b, a) returns false if A and B
have the same UID and A appears before B without doing the statement
walk. And, I don't see why the statement walk is bad. It is not likely
that there is a long sequence of statements with the same UID.

Thanks,
Easwaran

>
> Richard.
>
>>- Easwaran
>>
>>On Fri, May 24, 2013 at 1:07 AM, Richard Biener
>> wrote:
>>> On Thu, May 23, 2013 at 7:26 PM, Easwaran Raman 
>>wrote:
 This addresses the case where UID alone is not sufficient to figure
 out which statement appears earlier in  a BB. Bootstraps and no test
 regressions in x86_64 on linux. Ok for trunk?
>>>
>>> Why not simply conservatively use gimple_uid (a) <= gimple_uid (b)
>>> in not_dominated_by?
>>>
>>> Richard.
>>>
>>>
>>>
 Thanks,
 Easwaran


 2013-05-23  Easwaran Raman  

 PR tree-optimization/57337
 * tree-ssa-reassoc.c (appears_later_in_bb): New function.
 (find_insert_point): Correctly identify the insertion point
 when two statements with the same UID is compared.

 Index: gcc/tree-ssa-reassoc.c
 ===
 --- gcc/tree-ssa-reassoc.c  (revision 199211)
 +++ gcc/tree-ssa-reassoc.c  (working copy)
 @@ -2866,6 +2866,31 @@ not_dominated_by (gimple a, gimple b)

  }

 +/* Among STMT1 and STMT2, return the statement that appears later.
>>Both
 +   statements are in same BB and have the same UID.  */
 +
 +static gimple
 +appears_later_in_bb (gimple stmt1, gimple stmt2)
 +{
 +  unsigned uid = gimple_uid (stmt1);
 +  gimple_stmt_iterator gsi = gsi_for_stmt (stmt1);
 +  gsi_next (&gsi);
 +  if (gsi_end_p (gsi))
 +return stmt1;
 +  for (; !gsi_end_p (gsi); gsi_next (&gsi))
 +{
 +  gimple stmt = gsi_stmt (gsi);
 +
 +  /* If STMT has a different UID than STMT1 and we haven't seen
 + STMT2 during traversal, we know STMT1 appears later.  */
 +  if (gimple_uid (stmt) != uid)
 +return stmt1;
 +  else if (stmt == stmt2)
 +return stmt2;
 +}
 +  gcc_unreachable ();
 +}
 +
  /* Find the statement after which STMT must be moved so that the
 dependency from DEP_STMT to STMT is maintained.  */

 @@ -2875,7 +2900,11 @@ find_insert_point (gimple stmt, gimple
>>dep_stmt)
gimple insert_stmt = stmt;
if (dep_stmt == NULL)
  return stmt;
 -  if (not_dominated_by (insert_stmt, dep_stmt))
 +  if (gimple_uid (insert_stmt) == gimple_uid (dep_stmt)
 +  && gimple_bb (insert_stmt) == gimple_bb (dep_stmt)
 +  && insert_stmt != dep_stmt)
 +insert_stmt = appears_later_in_bb (insert_stmt, dep_stmt);
 +  else if (not_dominated_by (insert_stmt, dep_stmt))
  insert_stmt = dep_stmt;
return insert_stmt;
  }
>
>


Re: [patch,fortran] PR50405 - Statement function with itself as argument SEGV's

2013-05-25 Thread Bud Davis
The changes suggested by:

http://gcc.gnu.org/ml/fortran/2013-05/msg00057.html

have been made in the below diff and test file.

Could someone please commit this ?  

It has been approved, see the above referenced message.

thanks,
Bud Davis





Index: gcc/gcc/fortran/resolve.c
===
--- gcc/gcc/fortran/resolve.c   (revision 199330)
+++ gcc/gcc/fortran/resolve.c   (working copy)
@@ -306,6 +306,14 @@
   && !resolve_procedure_interface (sym))
return;
 
+  if (strcmp (proc->name, sym->name) == 0)
+{
+  gfc_error ("Self-referential argument "
+ "'%s' at %L is not allowed", sym->name,
+ &proc->declared_at);
+  return;
+}
+
   if (sym->attr.if_source != IFSRC_UNKNOWN)
resolve_formal_arglist (sym);
 


!{ dg-do compile }
! pr50405
! submitted by zec...@gmail.com
!{ dg-prune-output "Obsolescent feature: Statement function at" }
   f(f) = 0 ! { dg-error "Self referential argument" }
   end

2013-05-26  Bud Davis  

PR fortran/50405
resolve.c (resolve_formal_arglist): Detect error when an argument
has the same name as the function.
 


Re: [patch] Default to --enable-libstdcxx-time=auto

2013-05-25 Thread Jakub Jelinek
On Sat, May 25, 2013 at 04:07:11PM -0700, Benjamin De Kosnik wrote:
> 
> > Looks good to me.  
> 
> Great, trunk patch in.
> 
> > Will you prepare corresponding patch for the 4.8
> > branch too (I guess it should be pretty much the same, not sure if it
> > should keep using typedef system_clock steady_clock as before for the
> > non-MONOTONIC configuration, or if it should just do the same thing
> > as trunk)?
> 
> Same thing, I think. Testing now, ok when it completes?

Yes, thanks.

Jakub