Re: [PATCH] [graphite] Constrain only on INTEGER_TYPE

[Richard Biener]

On Thu, Aug 13, 2015 at 7:56 PM, Aditya K  wrote:
>
>
>> Date: Thu, 13 Aug 2015 12:02:43 +0200
>> Subject: Re: [PATCH] [graphite] Constrain only on INTEGER_TYPE
>> From: richard.guent...@gmail.com
>> To: tob...@grosser.es
>> CC: hiradi...@msn.com; gcc-patches@gcc.gnu.org; s@samsung.com;
>> seb...@gmail.com
>>
>> On Wed, Aug 12, 2015 at 10:41 PM, Tobias Grosser 
>> wrote:
>> > On 08/12/2015 10:33 PM, Aditya Kumar wrote:
>> >>
>> >> Passes bootstrap, no regressions.
>> >>
>> >> With this patch gcc bootstraps with graphite.
>> >> make BOOT_CFLAGS="-g -O2 -fgraphite-identity -floop-interchange
>> >> -floop-block"
>> >
>> >
>> > LGTM, but please use a longer sentence to explain what you do.
>>
>> As the middle-end generally freely exchanges INTEGER_TYPE
>> ENUMERAL_TYPE and BOOLEAN_TYPE
>> you want to use INTEGRAL_TYPE_P here.
>>
>
> Thanks.
> I tried INTEGRAL_TYPE_P, and that fails bootstrap. After a little bit of
> debugging I figured out that it is
> ENUMERAL_TYPE that causes the failure (miscompile) in tree-vect-data-refs.c.
> I can add INTEGER_TYPE and BOOLEAN_TYPE (bootstrap passes with these). But
> that would be inconsistent with the type-checks at other places in
> graphite-*.c.
> Currently, we are only checking for INTEGER_TYPE at other places.

This is weird - the code you replace did allow both ENUMERAL_TYPE and
BOOLEAN_TYPE.

my suggestion was

 /* We can not handle REAL_TYPE. Failed for pr39260.  */
-   || TREE_CODE (TREE_TYPE (op)) == REAL_TYPE)
+   || ! INTEGRAL_TYPE_P (TREE_TYPE (op))

you also need to adjust the comment btw.

Richard.

> -Aditya
>
>
>> RIchard.
>>
>> > Tobias

Re: [Patch] sext_hwi: Avoid left shift of negative value undefined behaviour

[Richard Biener]

On Thu, Aug 13, 2015 at 7:47 PM, Mike Stump  wrote:
> On Aug 13, 2015, at 3:05 AM, Richard Biener  
> wrote:
>> Ok, then guard the << >> with __GCC__ and do the expensive bit stuff
>> otherwise.  Just to cater for other host compilers doing sth unsensibly
>> implementation defined.
>
> Ick.  The guard should be specific to the implementation defined semantic or 
> undefined semantic, and then when compiling with gcc, we turn it on.  My take 
> is that when we do this, we should add the 5 or 10 other most popular 
> compilers to the list of how they behave so that they all do the cheap path 
> code as well.  If the language standard were serious in this area, it would 
> specify a header file that can define the implementation defined and 
> undefined semantics that are interesting for portable code.  It isn’t.  If it 
> were, we would then just use the standard defined guards.

GCC is always used to build stage2+ so I don't see the need to handle
alternate host compilers.

> The language standard should be improved to directly state the possible 
> implementation choices and to require the implementation to communicate to 
> the program which choice it made.

Re: [PATCH, libjava/classpath]: Fix overriding recipe for target 'gjdoc' build warning

[Richard Biener]

On Thu, Aug 13, 2015 at 11:31 PM, Jeff Law  wrote:
> On 08/13/2015 04:00 AM, Richard Biener wrote:
>>
>> On Wed, Aug 12, 2015 at 6:47 PM, Jeff Law  wrote:
>>>
>>> On 08/12/2015 10:24 AM, Ian Lance Taylor wrote:


 On Wed, Aug 12, 2015 at 9:21 AM, Tom Tromey  wrote:
>
>
> Jeff> In the past this has stalled on issues like how will
> asynch-exceptions
> Jeff> be tested and the like.
>
> It seems to me that either there is some other language which needs
> this
> -- in which case that language ought to have testing for the feature --
> or the feature is only used by gcj, in which case it doesn't matter.
>
> Of course is!=ought; but relying on gcj and libjava to provide this
> small amount of testing seems like a bad cost/benefit tradeoff.



 Go does use asynchronous exceptions, and has test cases that rely on
 them working.
>>>
>>>
>>> If you're comfortable with Go at this point and we have mechanisms in
>>> place
>>> to ensure Go only gets built on platforms that support Go, then I think
>>> we
>>> should go forward with replacing GCJ with Go.
>>
>>
>> I think replacing it with Ada makes more sense (still have some
>> systems where a ton
>> of Go tests fail presumably because of too old glibc/kernel).
>>
>> Or just replace it with nothing as effectively neither Go nor Ada are
>> going to be enabled
>> for all primary host platforms (as for Ada you need an Ada host
>> compiler for example).
>
> Neither Ada nor Go are perfect.  However, Ada should be at a point where, if
> you have a suitable host compiler, it should build and regression test.
>
> For Go, if there's platforms where the tests are unreliable, then it needs
> to be disabled on that platform until the tests are reliable. That's the key
> thing in my mind -- building and regression testing.
>
> Thus I'd support either or both between Ada and Go.  In fact the more I
> think about it, the more I think both ought to be enabled and GCJ disabled
> for the default build.

I am testing all my patches with all,ada,obj-c++,go (where go works for me)
plus -m32 multilib.  I really think that we should simply enable all languages
by default (thus go with that patch fixing 'all').

Removing Java from the picture only makes sense if we remove it from
the repository - an untested language / runtime doesn't help anybody.
Thus my suggestion to strip it down to the "boostrap" enabler (which
is I believe even only requiring the VM!).  We do not need to build
classpath or libgcj - people can do that on their own.  gij is fine with
a bytecode / native programs after all.

So what about removing classpath from the repository?  We still
retain basic language support via java/ javax/ and gnu/ that way
I believe.

Richard.

> jeff
>

Re: [PATCH 1/2] C++-ify dominance.c

[Richard Biener]

On Fri, Aug 14, 2015 at 2:55 AM, Mikhail Maltsev  wrote:
> Hi all.
>
> These two patches are refactoring of dominator-related code.
>
> The comment in dominance.c says: "We work in a poor-mans object oriented
> fashion, and carry an instance of this structure through all our 'methods'". 
> So,
> the first patch converts the mentioned structure (dom_info) into a class with
> proper encapsulation. It also adds a new member - m_fn (the function currently
> being compiled) to this structure and replaces some uses of cfun with m_fn. It
> also contains some fixes, related to current coding standards: move variable
> declarations to place of first use, replace elaborated type specifiers (i.e.
> "struct/enum foo") by simple ones (i.e., just "foo") in function prototypes.

Putting in m_fn looks backwards to me - it looks like we only need to remember
the entry and exit BBs and the number of blocks.  In fact initializing
dom_info from that would allow it to work on SESE regions as well?

+unsigned bb_dom_dfs_in (cdi_direction, basic_block);
+unsigned bb_dom_dfs_out (cdi_direction, basic_block);
+extern void verify_dominators (cdi_direction);
+basic_block recompute_dominator (cdi_direction, basic_block);
+extern void iterate_fix_dominators (cdi_direction, vec , bool);
+extern void add_to_dominance_info (cdi_direction, basic_block);

if you are here please fix the 'extern' vs. w/o 'extern' inconsistencies as well
(we prefer 'extern').

In general I'm biased and refactoring for the sake of refactoring
doesn't go well
with me ...

At least the above is a constructive comment, leaving the rest to Jeff.

Thanks,
Richard.

>
> Bootstrapped and regtested on x86_64-linux. Tested build of config-list.mk.
>
> gcc/ChangeLog:
>
> 2015-08-14  Mikhail Maltsev 
>
> * (ENABLE_CHECKING): Define as 0 by default.
> dominance.c (new_zero_array): Define.
> (dom_info): Define as class instead of struct.
> (dom_info::dom_info, ~dom_info): Define.  Use new/delete for memory
> allocations/deallocations.  Pass function as parameter (instead of
> using cfun).
> (dom_info::get_idom): Define accessor method.
> (dom_info::calc_dfs_tree_nonrec, calc_dfs_tree, compress, eval,
> link_roots, calc_idoms): Redefine as class members.  Use m_fn instead
> of cfun.
> (init_dom_info, free_dom_info): Remove (use dom_info ctor/dtor).
> (dom_convert_dir_to_idx): Fix prototype.
> (assign_dfs_numbers): Move variable declarations to their first uses.
> (calculate_dominance_info): Remove conditional compilation, move
> variables.
> (free_dominance_info, get_immediate_dominator, 
> set_immediate_dominator,
> get_dominated_b, get_dominated_by_region, get_dominated_to_depth,
> redirect_immediate_dominators, nearest_common_dominator_for_set,
> dominated_by_p, bb_dom_dfs_in, bb_dom_dfs_out, verify_dominators,
> determine_dominators_for_sons, iterate_fix_dominators, first_dom_son,
> next_dom_son, debug_dominance_info, debug_dominance_tree_1): Adjust to
> use class dom_info. Move variable declarations to the place of first
> use. Fix prototypes (remove struct/enum).
> * dominance.h: Fix prototypes (remove struct/enum).
>
> --
> Regards,
> Mikhail Maltsev

[patch,libgfortran] Handle invalid command line in EXECUTE_COMMAND_LINE

[FX]

The attached patch fixes PR 62296 
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62296). The Fortran 
interpretation there was a bit confused (see links to comp.lang.fortran thread 
from the PR), but the consensus is that the standard makes a difference between 
the command-line returning with nonzero status (which sets EXITSTAT) and the 
command-line not being able to execute at all (which sets CMDSTAT and CMDMSG).

The attached patch recognizes this by checking the return value of system() for 
magic values 126 and 127, which are used by various combinations of shells and 
libc to indicate that the shell could not be executed. The attached testcase 
checks that.

Bootstrapped and regtested on x86_64-apple-darwin14.
OK to commit to trunk?

FX



PS: I’ve also taken the opportunity to rework a bit the runtime error message 
issued when CMDSTAT is not present, to actually include the actual error 
condition message (that which would be CMDMSG if it were present) rather than a 
generic error message.




execute_command_line.ChangeLog
Description: Binary data


execute_command_line.diff
Description: Binary data

Re: [PATCH 2/2] Get rid of global state accesses in dominance.c

[Richard Biener]

On Fri, Aug 14, 2015 at 3:04 AM, Mikhail Maltsev  wrote:
> The second part removes all global state accesses (i.e. accesses to cfun and
> it's members) from dominance.c. This requires to change lots of code, but I 
> hope
> that this is a step in right direction (if my understanding of ongoing
> re-architecture w.r.t. to global state is correct).
>
> For now this second part lacks a changelog entry, but it's very "mechanical". 
> I
> will, of course, write it if the patch gets approved.

So the last time I did similar refactoring I wondered if we can somehow avoid
the "noise" in non-IPA passes.  Ideas I came up with are

 a)  Inherit gimple/rtl pass classes from a class which is initialized with the
  function the pass operates on and provides methods like

bool dom_info_available_p (..) { return dom_info_available_p (fn, ...); }

 thus wraps APIs working on a specific function.

 b)  Do sth similar but make it work with overloads and clever (no idea what!)
C++ that disables them if this_fn cannot be looked up

template 
bool dom_info_available_p (..., struct function *fn = this_fn);

all of the above would of course require that passes make all their
implementation
be methods of their pass class.  So even more refactoring.

Note that we do not have any IPA pass which accesses dominators, so the
implicit 'cfun' use was ok.  The cases I refactored were those where we had
to push/pop_cfun () in IPA passes (which can be expensive) because it
used APIs with implicit cfun.

Overall I'm not sure we want all APIs using 'cfun' to be refactored.
It is after
all useless noise to callers if all callers are effectively using 'cfun'.

Refactoring APIs that are used from IPA and make push/pop_cfun necessary
for them are another thing.  (there are still plenty left I think)

Richard.


> --
> Regards,
> Mikhail Maltsev

Re: [PATCH GCC]Improve bound information in loop niter analysis

[Richard Biener]

On Tue, Jul 28, 2015 at 11:36 AM, Bin Cheng  wrote:
> Hi,
> Loop niter computes inaccurate bound information for different loops.  This
> patch is to improve it by using loop initial condition in
> determine_value_range.  Generally, loop niter is computed by subtracting
> start var from end var in loop exit condition.  Moreover, loop bound is
> computed using value range information of both start and end variables.
> Basic idea of this patch is to check if loop initial condition implies more
> range information for both start/end variables.  If yes, we refine range
> information and use that to compute loop bound.
> With this improvement, more accurate loop bound information is computed for
> test cases added by this patch.

+  c0 = fold_convert (type, c0);
+  c1 = fold_convert (type, c1);
+
+  if (operand_equal_p (var, c0, 0))

I believe if c0 is not already of type type operand-equal_p will never succeed.

(side-note: we should get rid of the GMP use, that's expensive and now we
have wide-int available which should do the trick as well)

+ /* Case of comparing with the bounds of the type.  */
+ if (TYPE_MIN_VALUE (type)
+ && operand_equal_p (c1, TYPE_MIN_VALUE (type), 0))
+   cmp = GT_EXPR;
+ if (TYPE_MAX_VALUE (type)
+ && operand_equal_p (c1, TYPE_MAX_VALUE (type), 0))
+   cmp = LT_EXPR;

don't use TYPE_MIN/MAX_VALUE.  Instead use the types precision
and all wide_int operations (see match.pd wi::max_value use).

+  else if (!operand_equal_p (var, varc0, 0))
+goto end_2;

ick - goto.  We need sth like a auto_mpz class with a destructor.

struct auto_mpz
{
  auto_mpz () { mpz_init (m_val); }
  ~auto_mpz () { mpz_clear (m_val); }
  mpz& operator() { return m_val; }
  mpz m_val;
};

> Is it OK?

I see the code follows existing practice in niter analysis even though
my overall plan was to transition its copying of value-range related
optimizations to use VRP infrastructure.

I'm still ok with improving the existing code on the basis that I won't
get to that for GCC 6.

So - ok with the TYPE_MIN/MAX_VALUE change suggested above.

Refactoring with auto_mpz welcome.

Thanks,
RIchard.

> Thanks,
> bin
>
> 2015-07-28  Bin Cheng  
>
> * tree-ssa-loop-niter.c (refine_value_range_using_guard): New.
> (determine_value_range): Call refine_value_range_using_guard for
> each loop initial condition to improve value range.
>
> gcc/testsuite/ChangeLog
> 2015-07-28  Bin Cheng  
>
> * gcc.dg/tree-ssa/loop-bound-1.c: New test.
> * gcc.dg/tree-ssa/loop-bound-3.c: New test.
> * gcc.dg/tree-ssa/loop-bound-5.c: New test.

Re: [PATCH GCC]Improve loop bound info by simplifying conversions in iv base

[Richard Biener]

On Tue, Jul 28, 2015 at 11:38 AM, Bin Cheng  wrote:
> Hi,
> For now, SCEV may compute iv base in the form of "(signed T)((unsigned
> T)base + step))".  This complicates other optimizations/analysis depending
> on SCEV because it's hard to dive into type conversions.  For many cases,
> such type conversions can be simplified with additional range information
> implied by loop initial conditions.  This patch does such simplification.
> With simplified iv base, loop niter analysis can compute more accurate bound
> information since sensible value range can be derived for "base+step".  For
> example, accurate loop bound&may_be_zero information is computed for cases
> added by this patch.
> The code is actually borrowed from loop_exits_before_overflow.  Moreover,
> with simplified iv base, the second case handled in that function now
> becomes the first case.  I didn't remove that part of code because it may(?)
> still be visited in scev analysis itself and simple_iv isn't an interface
> for that.
>
> Is it OK?

It looks quite special given it only handles a very specific pattern.  Did you
do any larger collecting of statistics on how many times this triggers,
esp. how many times simplify_using_initial_conditions succeeds and
how many times not?  This function is somewhat expensive.

+  || !operand_equal_p (iv->step,
+  fold_convert (type,
+TREE_OPERAND (e, 1)), 0))

operand_equal_p can handle sign-differences in integer constants,
no need to fold_convert here.  Also if you know that you are comparing
integer constants please use tree_int_cst_equal_p.

+  extreme = lower_bound_in_type (type, type);

that's a strange function to call here (with two same types).  Looks like
just wide_int_to_tree (type, wi::max/min_value (type)).

+  extreme = fold_build2 (MINUS_EXPR, type, extreme, iv->step);

so as iv->step is an INTEGER_CST please do this whole thing using
wide_ints and only build trees here:

+  e = fold_build2 (code, boolean_type_node, base, extreme);

Thanks,
Richard.

> Thanks,
> bin
>
> 2015-07-28  Bin Cheng  
>
> * tree-ssa-loop-niter.c (tree_simplify_using_condition): Export
> the interface.
> * tree-ssa-loop-niter.h (tree_simplify_using_condition): Declare.
> * tree-scalar-evolution.c (simple_iv): Simplify type conversions
> in iv base using loop initial conditions.
>
> gcc/testsuite/ChangeLog
> 2015-07-28  Bin Cheng  
>
> * gcc.dg/tree-ssa/loop-bound-2.c: New test.
> * gcc.dg/tree-ssa/loop-bound-4.c: New test.
> * gcc.dg/tree-ssa/loop-bound-6.c: New test.

[patch,libgfortran,toplevel] Use libbacktrace in libgfortran

[FX]

Use libbacktrace (instead of our own unwind-based code) to display backtraces 
from libgfortran upon error or user request.

  1. In toplevel Makefile.def, make libgfortran depend on libbacktrace (needs 
global reviewer approval)
  2. In gcc/fortran/config-lang.in, add libbacktrace to target_libs
  3. In libgfortran, we remove our own code and substitute calls to libbacktrace

Bootstrapped and regtested on x86_64-pc-linux-gnu (which has full libbacktrace 
support) and x86_64-apple-darwin14 (which has minimal libbacktrace support). OK 
to commit to trunk?

FX

--

The fine print:

This is a great simplification of the library code, because we get rid of the 
unwind code, and don’t need all the code to find out our executable’s absolute 
path, find addr2line, pipe-fork-exec addr2line, etc. Just 
libgfortran/runtime/backtrace.c’s size is reduced by half. And we will benefit 
from future possible improvements in libbacktrace.

One choice I have made is to not display in backtraces the libgfortran 
functions, i.e. anything starting with _gfortran_ or _gfortrani_ is simply not 
printed. I think this is more convenient for some users, because it will avoid 
them being confused by symbols they don’t recognize. It means, however, that 
runtime backtraces are a little less useful for us in debugging… but then, we 
know how to use gdb :)  I am open to being convinced otherwise and remove these 
few lines of code.

Other than that deliberate choice, no functionality is lost. On dwarf/elf 
targets (the majority), we get beautiful backtraces as before if code is 
compiled with “-g”:

#0  0x4006f5 __foo_MOD_gee
/home/fx/gcc/irun/a.f90:4
#1  0x400706 bar
/home/fx/gcc/irun/a.f90:16
#2  0x40072e foo
/home/fx/gcc/irun/a.f90:12
#3  0x400715 test
/home/fx/gcc/irun/a.f90:9
#4  0x400765 main
/home/fx/gcc/irun/a.f90:9

and if not compiled with “-g”, we get the nonsymbolic backtrace, as before:

#0  0x4010bd ???
#1  0x4010ce ???
#2  0x4010f6 ???
#3  0x4010dd ???
#4  0x40112d ???
#5  0x42a6b3 ???
#6  0x400fbc ???


We will get backtraces on PE/COFF targets (i.e. Windows), where I don’t think 
we had them before (but cannot test).
And on non-elf targets such as Mac OS X, we stay with the same as before, i.e. 
non-symbolic backtraces.



PS: This is probably one of the last of my “summer” gfortran projects for this 
year. The end of holidays is near, and I’ll have to get back to work. It was 
fun, as always!




backtrace.ChangeLog
Description: application/applefile


backtrace.diff
Description: Binary data


backtrace_withregeneratedfiles.diff
Description: Binary data

[Patch ARM/AArch64] Add missing is_neon_type types

[James Greenhalgh]

Hi,

I spotted that these are missing from the "is_neon_type" attribute:

neon_fp_abs_s, neon_fp_abs_s_q, neon_fp_abs_d, neon_fp_abs_d_q,
neon_fp_neg_s, neon_fp_neg_s_q, neon_fp_neg_d, neon_fp_neg_d_q,
neon_fp_to_int_d, neon_fp_to_int_d_q,
neon_int_to_fp_d, neon_int_to_fp_d_q,

This patch adds them.  In principle this could have shown up by allowing
us to create a limited set of conditional neon instructions, or as a
scheduling quirk in the Cortex-A7 and Cortex-A53 scheduling models, but I
didn't see any impact in some smoke testing.

Bootstrapped on arm-none-linux-gnueabihf and aarch64-none-linux-gnu with
no issues.

OK?

Thanks,
James

---
2015-08-14  James Greenhalgh  

* config/arm/types.md (is_neon_type): Add missing types.

diff --git a/gcc/config/arm/types.md b/gcc/config/arm/types.md
index d368446..ec609ae 100644
--- a/gcc/config/arm/types.md
+++ b/gcc/config/arm/types.md
@@ -1146,10 +1146,12 @@
   neon_store3_one_lane, neon_store3_one_lane_q, neon_store4_4reg,\
   neon_store4_4reg_q, neon_store4_one_lane, neon_store4_one_lane_q,\
   neon_fp_abd_s, neon_fp_abd_s_q, neon_fp_abd_d, neon_fp_abd_d_q,\
+  neon_fp_abs_s, neon_fp_abs_s_q, neon_fp_abs_d, neon_fp_abs_d_q,\
   neon_fp_addsub_s, neon_fp_addsub_s_q, neon_fp_addsub_d,\
   neon_fp_addsub_d_q, neon_fp_compare_s, neon_fp_compare_s_q,\
   neon_fp_compare_d, neon_fp_compare_d_q, neon_fp_minmax_s,\
   neon_fp_minmax_s_q, neon_fp_minmax_d, neon_fp_minmax_d_q,\
+  neon_fp_neg_s, neon_fp_neg_s_q, neon_fp_neg_d, neon_fp_neg_d_q,\
   neon_fp_reduc_add_s, neon_fp_reduc_add_s_q, neon_fp_reduc_add_d,\
   neon_fp_reduc_add_d_q, neon_fp_reduc_minmax_s,
   neon_fp_reduc_minmax_s_q, neon_fp_reduc_minmax_d,\
@@ -1157,6 +1159,8 @@
   neon_fp_cvt_narrow_s_q, neon_fp_cvt_narrow_d_q,\
   neon_fp_cvt_widen_h, neon_fp_cvt_widen_s, neon_fp_to_int_s,\
   neon_fp_to_int_s_q, neon_int_to_fp_s, neon_int_to_fp_s_q,\
+  neon_fp_to_int_d, neon_fp_to_int_d_q,\
+  neon_int_to_fp_d, neon_int_to_fp_d_q,\
   neon_fp_round_s, neon_fp_round_s_q, neon_fp_recpe_s,\
   neon_fp_recpe_s_q,\
   neon_fp_recpe_d, neon_fp_recpe_d_q, neon_fp_recps_s,\

Re: [PATCH, libjava/classpath]: Fix overriding recipe for target 'gjdoc' build warning

[Andrew Haley]

On 14/08/15 08:43, Richard Biener wrote:
> So what about removing classpath from the repository?  We still
> retain basic language support via java/ javax/ and gnu/ that way
> I believe.

I don't think we do.

Andrew.

RE: [PATCH] [graphite] Constrain only on INTEGER_TYPE

[Aditya K]

> Date: Fri, 14 Aug 2015 09:31:32 +0200
> Subject: Re: [PATCH] [graphite] Constrain only on INTEGER_TYPE
> From: richard.guent...@gmail.com
> To: hiradi...@msn.com
> CC: tob...@grosser.es; gcc-patches@gcc.gnu.org; s@samsung.com; 
> seb...@gmail.com
>
> On Thu, Aug 13, 2015 at 7:56 PM, Aditya K  wrote:
>>
>>
>>> Date: Thu, 13 Aug 2015 12:02:43 +0200
>>> Subject: Re: [PATCH] [graphite] Constrain only on INTEGER_TYPE
>>> From: richard.guent...@gmail.com
>>> To: tob...@grosser.es
>>> CC: hiradi...@msn.com; gcc-patches@gcc.gnu.org; s@samsung.com;
>>> seb...@gmail.com
>>>
>>> On Wed, Aug 12, 2015 at 10:41 PM, Tobias Grosser 
>>> wrote:
 On 08/12/2015 10:33 PM, Aditya Kumar wrote:
>
> Passes bootstrap, no regressions.
>
> With this patch gcc bootstraps with graphite.
> make BOOT_CFLAGS="-g -O2 -fgraphite-identity -floop-interchange
> -floop-block"


 LGTM, but please use a longer sentence to explain what you do.
>>>
>>> As the middle-end generally freely exchanges INTEGER_TYPE
>>> ENUMERAL_TYPE and BOOLEAN_TYPE
>>> you want to use INTEGRAL_TYPE_P here.
>>>
>>
>> Thanks.
>> I tried INTEGRAL_TYPE_P, and that fails bootstrap. After a little bit of
>> debugging I figured out that it is
>> ENUMERAL_TYPE that causes the failure (miscompile) in tree-vect-data-refs.c.
>> I can add INTEGER_TYPE and BOOLEAN_TYPE (bootstrap passes with these). But
>> that would be inconsistent with the type-checks at other places in
>> graphite-*.c.
>> Currently, we are only checking for INTEGER_TYPE at other places.
>
> This is weird - the code you replace did allow both ENUMERAL_TYPE and
> BOOLEAN_TYPE.
>
> my suggestion was
>
> /* We can not handle REAL_TYPE. Failed for pr39260. */
> - || TREE_CODE (TREE_TYPE (op)) == REAL_TYPE)
> + || ! INTEGRAL_TYPE_P (TREE_TYPE (op))
>
> you also need to adjust the comment btw.

This is exactly what I did and that resulted in miscompile. Then out of 
curiosity I tried to debug by putting
 /* We can not handle REAL_TYPE. Failed for pr39260. */
 - || TREE_CODE (TREE_TYPE (op)) == REAL_TYPE)
 + || TREE_CODE (TREE_TYPE (op)) != INTEGER_TYPE)
 + || TREE_CODE (TREE_TYPE (op)) != BOOLEAN_TYPE))

And that passed bootstrap.

Update patch:

Passes bootstrap, no regressions.

With this patch gcc bootstraps with graphite.
make BOOT_CFLAGS="-g -O2 -fgraphite-identity -floop-interchange -floop-block"

gcc/ChangeLog:

2015-08-12  Aditya Kumar  

* graphite-scop-detection.c (stmt_simple_for_scop_p):
Constrain only on INTEGER_TYPE
---
 gcc/graphite-scop-detection.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gcc/graphite-scop-detection.c b/gcc/graphite-scop-detection.c
index fb7247e..0f02a71 100644
--- a/gcc/graphite-scop-detection.c
+++ b/gcc/graphite-scop-detection.c
@@ -409,8 +409,8 @@ stmt_simple_for_scop_p (basic_block scop_entry, loop_p 
outermost_loop,
  {
    tree op = gimple_op (stmt, i);
    if (!graphite_can_represent_expr (scop_entry, loop, op)
-   /* We can not handle REAL_TYPE. Failed for pr39260.  */
-   || TREE_CODE (TREE_TYPE (op)) == REAL_TYPE)
+   /* We can only constrain on integer type.  */
+   || (TREE_CODE (TREE_TYPE (op)) != INTEGER_TYPE))
      {
    if (dump_file && (dump_flags & TDF_DETAILS))
  {
-- 
2.1.4



>
> Richard.
>
>> -Aditya
>>
>>
>>> RIchard.
>>>
 Tobias
  

Re: [Patch ARM/AArch64] Add missing is_neon_type types

[Ramana Radhakrishnan]

On 14/08/15 10:23, James Greenhalgh wrote:
> 
> Hi,
> 
> I spotted that these are missing from the "is_neon_type" attribute:
> 
>   neon_fp_abs_s, neon_fp_abs_s_q, neon_fp_abs_d, neon_fp_abs_d_q,
>   neon_fp_neg_s, neon_fp_neg_s_q, neon_fp_neg_d, neon_fp_neg_d_q,
>   neon_fp_to_int_d, neon_fp_to_int_d_q,
>   neon_int_to_fp_d, neon_int_to_fp_d_q,
> 
> This patch adds them.  In principle this could have shown up by allowing
> us to create a limited set of conditional neon instructions, or as a
> scheduling quirk in the Cortex-A7 and Cortex-A53 scheduling models, but I
> didn't see any impact in some smoke testing.
> 
> Bootstrapped on arm-none-linux-gnueabihf and aarch64-none-linux-gnu with
> no issues.

This is OK - 

Thanks for catching this.

Ramana

> 
> OK?
> 
> Thanks,
> James
> 
> ---
> 2015-08-14  James Greenhalgh  
> 
>   * config/arm/types.md (is_neon_type): Add missing types.
> 

[PATCH] Improve performance for Haswell family.

[Yuri Rumyantsev]

Hi All,

Here is patch which contains
(1) modifying of core2.md  to conform Haswell pipeline and adding of
missed instruction reservation for instructions with vector operands.
(2) increase reassociation width for float-point operations for
Haswell family and 64-bit target, this allows to get +10% speedup on
spec2006/410.bwaves for Skylake processor.

Bootstrap and regression testing did not show any new failures.
Is it OK for trunk?

ChangeLog:
2015-08-14  Yuri Rumyantsev  

* config/i386/core2.md: Confrom instruction reservation to Haswell
pipeline.
* config/i386/i386.c (ix86_reassociation_width): Increase reassociation
width for float-point operations.


hsw.patch
Description: Binary data

[PATCH][AArch64][committed] Mark target_attr_1.c as compile-only

[Kyrill Tkachov]

As mentioned at
https://gcc.gnu.org/ml/gcc-patches/2015-08/msg00251.html

some assemblers don't support -mcpu=thunderx, so the dg-do assemble test will 
FAIL.
Mark this test as compile-only as assembling it is not essential to the 
functionality it tests.

Committed as obvious with r226886.

2015-08-14  Kyrylo Tkachov  

* gcc.target/aarch64/target_attr_1.c: Make test compile-only.
diff --git a/gcc/testsuite/gcc.target/aarch64/target_attr_1.c b/gcc/testsuite/gcc.target/aarch64/target_attr_1.c
index b1d52a6..852ce1e 100644
--- a/gcc/testsuite/gcc.target/aarch64/target_attr_1.c
+++ b/gcc/testsuite/gcc.target/aarch64/target_attr_1.c
@@ -1,4 +1,4 @@
-/* { dg-do assemble } */
+/* { dg-do compile } */
 /* { dg-options "-O2 -mcpu=thunderx -save-temps" } */
 
 /* Test that cpu attribute overrides the command-line -mcpu.  */

Re: [PATCH] [graphite] Constrain only on INTEGER_TYPE

[Richard Biener]

On Fri, Aug 14, 2015 at 11:25 AM, Aditya K  wrote:
>
>
> 
>> Date: Fri, 14 Aug 2015 09:31:32 +0200
>> Subject: Re: [PATCH] [graphite] Constrain only on INTEGER_TYPE
>> From: richard.guent...@gmail.com
>> To: hiradi...@msn.com
>> CC: tob...@grosser.es; gcc-patches@gcc.gnu.org; s@samsung.com; 
>> seb...@gmail.com
>>
>> On Thu, Aug 13, 2015 at 7:56 PM, Aditya K  wrote:
>>>
>>>
 Date: Thu, 13 Aug 2015 12:02:43 +0200
 Subject: Re: [PATCH] [graphite] Constrain only on INTEGER_TYPE
 From: richard.guent...@gmail.com
 To: tob...@grosser.es
 CC: hiradi...@msn.com; gcc-patches@gcc.gnu.org; s@samsung.com;
 seb...@gmail.com

 On Wed, Aug 12, 2015 at 10:41 PM, Tobias Grosser 
 wrote:
> On 08/12/2015 10:33 PM, Aditya Kumar wrote:
>>
>> Passes bootstrap, no regressions.
>>
>> With this patch gcc bootstraps with graphite.
>> make BOOT_CFLAGS="-g -O2 -fgraphite-identity -floop-interchange
>> -floop-block"
>
>
> LGTM, but please use a longer sentence to explain what you do.

 As the middle-end generally freely exchanges INTEGER_TYPE
 ENUMERAL_TYPE and BOOLEAN_TYPE
 you want to use INTEGRAL_TYPE_P here.

>>>
>>> Thanks.
>>> I tried INTEGRAL_TYPE_P, and that fails bootstrap. After a little bit of
>>> debugging I figured out that it is
>>> ENUMERAL_TYPE that causes the failure (miscompile) in tree-vect-data-refs.c.
>>> I can add INTEGER_TYPE and BOOLEAN_TYPE (bootstrap passes with these). But
>>> that would be inconsistent with the type-checks at other places in
>>> graphite-*.c.
>>> Currently, we are only checking for INTEGER_TYPE at other places.
>>
>> This is weird - the code you replace did allow both ENUMERAL_TYPE and
>> BOOLEAN_TYPE.
>>
>> my suggestion was
>>
>> /* We can not handle REAL_TYPE. Failed for pr39260. */
>> - || TREE_CODE (TREE_TYPE (op)) == REAL_TYPE)
>> + || ! INTEGRAL_TYPE_P (TREE_TYPE (op))
>>
>> you also need to adjust the comment btw.
>
> This is exactly what I did and that resulted in miscompile. Then out of 
> curiosity I tried to debug by putting
>  /* We can not handle REAL_TYPE. Failed for pr39260. */
>  - || TREE_CODE (TREE_TYPE (op)) == REAL_TYPE)
>  + || TREE_CODE (TREE_TYPE (op)) != INTEGER_TYPE)
>  + || TREE_CODE (TREE_TYPE (op)) != BOOLEAN_TYPE))
>

well, each op is either != INTEGER or != BOOLEAN ... this is equal to
doing || true

> And that passed bootstrap.
>
> Update patch:
>
> Passes bootstrap, no regressions.
>
> With this patch gcc bootstraps with graphite.
> make BOOT_CFLAGS="-g -O2 -fgraphite-identity -floop-interchange -floop-block"
>
> gcc/ChangeLog:
>
> 2015-08-12  Aditya Kumar  
>
> * graphite-scop-detection.c (stmt_simple_for_scop_p):
> Constrain only on INTEGER_TYPE
> ---
>  gcc/graphite-scop-detection.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/gcc/graphite-scop-detection.c b/gcc/graphite-scop-detection.c
> index fb7247e..0f02a71 100644
> --- a/gcc/graphite-scop-detection.c
> +++ b/gcc/graphite-scop-detection.c
> @@ -409,8 +409,8 @@ stmt_simple_for_scop_p (basic_block scop_entry, loop_p 
> outermost_loop,
>   {
> tree op = gimple_op (stmt, i);
> if (!graphite_can_represent_expr (scop_entry, loop, op)
> -   /* We can not handle REAL_TYPE. Failed for pr39260.  */
> -   || TREE_CODE (TREE_TYPE (op)) == REAL_TYPE)
> +   /* We can only constrain on integer type.  */
> +   || (TREE_CODE (TREE_TYPE (op)) != INTEGER_TYPE))
>   {
> if (dump_file && (dump_flags & TDF_DETAILS))
>   {
> --
> 2.1.4
>
>
>
>>
>> Richard.
>>
>>> -Aditya
>>>
>>>
 RIchard.

> Tobias
>

Forwarding -foffload=[...] from the driver (compile-time) to libgomp (run-time) (was: [PATCH 2/n] OpenMP 4.0 offloading infrastructure: LTO streaming)

[Thomas Schwinge]

Hi!

Assuming that the overall approach (my option a) is fine, this is now
primarily a question about how to teach the driver to "the right thing".
(Joseph CCed as driver reviewer.)

On Wed, 5 Aug 2015 18:09:04 +0300, Ilya Verbin  wrote:
> On Wed, Aug 05, 2015 at 10:40:44 +0200, Richard Biener wrote:
> > On Fri, Jul 31, 2015 at 4:20 PM, Ilya Verbin  wrote:
> > > On Fri, Jul 31, 2015 at 16:08:27 +0200, Thomas Schwinge wrote:
> > >> We had established the use of a boolean flag have_offload in gcc::context
> > >> to indicate whether during compilation, we've actually seen any code to
> > >> be offloaded (see cited below the relevant parts of the patch by Ilya et
> > >> al.).  This means that currently, the whole offload machinery will not be
> > >> run unless we actually have any offloaded data.  This means that the
> > >> configured mkoffload programs (-foffload=[...], defaulting to
> > >> configure-time --enable-offload-targets=[...]) will not be invoked unless
> > >> we actually have any offloaded data.  This means that we will not
> > >> actually generate constructor code to call libgomp's
> > >> GOMP_offload_register unless we actually have any offloaded data.
> > >
> > > Yes, that was the plan.
> > >
> > >> runtime, in libgomp, we then cannot reliably tell which -foffload=[...]
> > >> targets have been specified during compilation.
> > >>
> > >> But: at runtime, I'd like to know which -foffload=[...] targets have been
> > >> specified during compilation, so that we can, for example, reliably
> > >> resort to host fallback execution for -foffload=disable instead of
> > >> getting error message that an offloaded function is missing.
> > >
> > > It's easy to fix:
> > >
> > > diff --git a/libgomp/target.c b/libgomp/target.c
> > > index a5fb164..f81d570 100644
> > > --- a/libgomp/target.c
> > > +++ b/libgomp/target.c
> > > @@ -1066,9 +1066,6 @@ gomp_get_target_fn_addr (struct gomp_device_descr 
> > > *devicep,
> > >k.host_end = k.host_start + 1;
> > >splay_tree_key tgt_fn = splay_tree_lookup (&devicep->mem_map, &k);
> > >gomp_mutex_unlock (&devicep->lock);
> > > -  if (tgt_fn == NULL)
> > > -   gomp_fatal ("Target function wasn't mapped");
> > > -
> > >return (void *) tgt_fn->tgt_offset;
> > >  }

Won't that possibly result in a NULL pointer dereference (tgt_fn) --
instead return NULL, I think?

> > > @@ -1095,6 +1092,8 @@ GOMP_target (int device, void (*fn) (void *), const 
> > > void *unused,
> > >  return gomp_target_fallback (fn, hostaddrs);
> > >
> > >void *fn_addr = gomp_get_target_fn_addr (devicep, fn);
> > > +  if (fn_addr == NULL)
> > > +return gomp_target_fallback (fn, hostaddrs);

Is that reliable?  Consider the following scenario, with f1 and f2
implemented in separate TUs:

#pragma omp target data [map clauses]
{
  f1([...]);
  f2([...]);
}

Consider that in f1 we have a OpenMP target region with offloading data
available, and in f2 we have a OpenMP target region without offloading
data available.  In this case, the GOMP_target in f1 will execute on the
offloading target, but the GOMP_target in f2 will resort to host fallback
-- and we then likely have data inconsistencies, as the data specified by
the map clauses is not synchronized between host and device.

Admittedly, this is user error (inconsistent set of offloading functions
available -- need either all, or none), but in such a scenario probably
we should be doing a better job (at detecting this).  (Note, I'm not sure
whether my current patch actually does any better.)  ;-)

> > >> other hand, for example, for -foffload=nvptx-none, even if user program
> > >> code doesn't contain any offloaded data (and thus the offload machinery
> > >> has not been run), the user program might still contain any executable
> > >> directives or OpenACC runtime library calls, so we'd still like to use
> > >> the libgomp nvptx plugin.  However, we currently cannot detect this
> > >> situation.
> > >>
> > >> I see two ways to resolve this: a) embed the compile-time -foffload=[...]
> > >> configuration in the executable (as a string, for example) for libgomp to
> > >> look that up, or b) make it a requirement that (if configured via
> > >> -foffload=[...]), the offload machinery is run even if there is not
> > >> actually any data to be offloaded, so we then reliably get the respective
> > >> constructor call to libgomp's GOMP_offload_register.  I once began to
> > >> implement a), but this to get a big ugly, so then looked into b) instead.
> > >> Compared to the status quo, always running the whole offloading machinery
> > >> for the configured -foffload=[...] targets whenever -fopenacc/-fopenmp
> > >> are active, certainly does introduce some overhead when there isn't
> > >> actually any code to be offloaded, so I'm not sure whether that is
> > >> acceptable?
> > >
> > > I vote for (a).

OK.  Any other opinions?

> > What happens for conflicting -fofffload=[...] options in different T

Re: [PATCH] Add extensions to dwarf2.def

[Pierre-Marie de Rodat]

Cary,

Thank you for your answer!

On 08/13/2015 09:01 PM, Cary Coutant wrote:

I don't think you really need a new TAG here -- DW_TAG_constant could
just as easily take DW_AT_GNU_numerator and DW_AT_GNU_denominator as
an alternative to DW_AT_const_value.


Good idea! I updated the patch accordingly.


I'm not really sure why DW_AT_small was defined to refer to a
DW_TAG_constant DIE rather than just providing the constant as the
attribute value. It would seem more efficient, space-wise, to have a
DW_AT_scale attribute that would provide a multiplicative scale
factor, and an optional DW_AT_scale_divisor to provide the denominator
if necessary.


Agreed.


Another, perhaps far-fetched, alternative would be to introduce a new
form that would represent a rational constant as two unsigned LEB128
values, and allow that form for DW_AT_const_value and/or for
DW_AT_small.


Indeed, that's an option, but I find it not very convenient: a new form 
would require us to enhance all DWARF reading tools whereas adding new 
tags and attributes is very smooth (not sure this is a good reason, but 
anyway...).



For now, I'd suggest going with your proposal, except use the existing
DW_TAG_constant instead of a new TAG. (I.e., just add the two new
DW_AT_numerator and DW_AT_denominator attributes.)


That's what I did.


include/
 * dwarf2.def (DW_AT_GNU_bias): New attribute.


This is OK. Looks like a good idea to me.


Great. Thank you again! I comitted the two attached (and updated) 
patches. I will update the corresponding dwarf2out.c changes I submitted 
on July as well.


I also tried to create the new pages on the wiki but it says "You are 
not allowed to edit this page." 
(, 
I'm logged in as pmderodat). Does anyone know how I should proceed?


--
Pierre-Marie de Rodat
>From 5b18866caaa8206788baf086c02a7aaf91d555a6 Mon Sep 17 00:00:00 2001
From: Pierre-Marie de Rodat 
Date: Tue, 9 Jun 2015 10:31:50 +0200
Subject: [PATCH 1/2] DWARF2: add extensions to handle fixed point types

include/ChangeLog:

	* dwarf2.def (DW_AT_GNU_numerator, DW_AT_GNU_denominator): New
	attributes.
---
 include/ChangeLog  | 5 +
 include/dwarf2.def | 4 
 2 files changed, 9 insertions(+)

diff --git a/include/ChangeLog b/include/ChangeLog
index 46a4a28..ee59133 100644
--- a/include/ChangeLog
+++ b/include/ChangeLog
@@ -1,3 +1,8 @@
+2015-08-14  Pierre-Marie de Rodat  
+
+	* dwarf2.def (DW_AT_GNU_numerator, DW_AT_GNU_denominator): New
+	attributes.
+
 2015-08-11  Trevor Saunders  
 
 	* ansidecl.h (GCC_FINAL): New macro.
diff --git a/include/dwarf2.def b/include/dwarf2.def
index e61cfbe..9603c04 100644
--- a/include/dwarf2.def
+++ b/include/dwarf2.def
@@ -404,6 +404,10 @@ DW_AT (DW_AT_VMS_rtnbeg_pd_address, 0x2201)
See http://gcc.gnu.org/wiki/DW_AT_GNAT_descriptive_type .  */
 DW_AT (DW_AT_use_GNAT_descriptive_type, 0x2301)
 DW_AT (DW_AT_GNAT_descriptive_type, 0x2302)
+/* Rational constant extension.
+   See https://gcc.gnu.org/wiki/DW_AT_GNU_numerator_denominator .  */
+DW_TAG (DW_AT_GNU_numerator, 0x2303)
+DW_TAG (DW_AT_GNU_denominator, 0x2304)
 /* UPC extension.  */
 DW_AT (DW_AT_upc_threads_scaled, 0x3210)
 /* PGI (STMicroelectronics) extensions.  */
-- 
2.4.6

>From fcddb9fe71187eca4f49576c4f36e5a3d051b669 Mon Sep 17 00:00:00 2001
From: Pierre-Marie de Rodat 
Date: Tue, 9 Jun 2015 10:31:50 +0200
Subject: [PATCH 2/2] DWARF2: add extensions to handle biased types

include/ChangeLog:

	* dwarf2.def (DW_AT_GNU_bias): New attribute.
---
 include/ChangeLog  | 4 
 include/dwarf2.def | 3 +++
 2 files changed, 7 insertions(+)

diff --git a/include/ChangeLog b/include/ChangeLog
index ee59133..6962f85 100644
--- a/include/ChangeLog
+++ b/include/ChangeLog
@@ -1,5 +1,9 @@
 2015-08-14  Pierre-Marie de Rodat  
 
+	* dwarf2.def (DW_AT_GNU_bias): New attribute.
+
+2015-08-14  Pierre-Marie de Rodat  
+
 	* dwarf2.def (DW_AT_GNU_numerator, DW_AT_GNU_denominator): New
 	attributes.
 
diff --git a/include/dwarf2.def b/include/dwarf2.def
index 9603c04..2dfee56 100644
--- a/include/dwarf2.def
+++ b/include/dwarf2.def
@@ -408,6 +408,9 @@ DW_AT (DW_AT_GNAT_descriptive_type, 0x2302)
See https://gcc.gnu.org/wiki/DW_AT_GNU_numerator_denominator .  */
 DW_TAG (DW_AT_GNU_numerator, 0x2303)
 DW_TAG (DW_AT_GNU_denominator, 0x2304)
+/* Biased integer extension.
+   See https://gcc.gnu.org/wiki/DW_AT_GNU_bias .  */
+DW_TAG (DW_AT_GNU_bias, 0x2305)
 /* UPC extension.  */
 DW_AT (DW_AT_upc_threads_scaled, 0x3210)
 /* PGI (STMicroelectronics) extensions.  */
-- 
2.4.6

[PATCH][AArch64][committed] Fix some target attribute inlining tests for -fPIC

[Kyrill Tkachov]

Hi all,

Some of the new target attribute tests fail when testing with an explicit -fPIC:
NA->FAIL: gcc.target/aarch64/target_attr_14.c scan-assembler-not bl.*bar
NA->FAIL: gcc.target/aarch64/target_attr_5.c scan-assembler-not bl.*bar
NA->FAIL: gcc.target/aarch64/target_attr_8.c scan-assembler-not bl.*bar

The fix for that is to add a static modifier to the function being inlined.
Committed as obvious with r226889.

Thanks,
Kyrill

2015-08-14  Kyrylo Tkachov  

* gcc.target/aarch64/target_attr_5.c: Add static modifier to bar.
* gcc.target/aarch64/target_attr_8.c: Likewise.
* gcc.target/aarch64/target_attr_14.c: Likewise.
diff --git a/gcc/testsuite/gcc.target/aarch64/target_attr_14.c b/gcc/testsuite/gcc.target/aarch64/target_attr_14.c
index a4e481d..916b5a6 100644
--- a/gcc/testsuite/gcc.target/aarch64/target_attr_14.c
+++ b/gcc/testsuite/gcc.target/aarch64/target_attr_14.c
@@ -4,7 +4,7 @@
 /* Inlining non-strict-align functions into strict-align
functions is allowed.  */
 
-int
+static int
 bar (int a)
 {
   return a - 6;
diff --git a/gcc/testsuite/gcc.target/aarch64/target_attr_5.c b/gcc/testsuite/gcc.target/aarch64/target_attr_5.c
index 4fc0709..9eac06e 100644
--- a/gcc/testsuite/gcc.target/aarch64/target_attr_5.c
+++ b/gcc/testsuite/gcc.target/aarch64/target_attr_5.c
@@ -4,7 +4,7 @@
 /* Make sure that bar is inlined into bam.  */
 
 __attribute__ ((target ("arch=armv8-a+nocrc")))
-int
+static int
 bar (int a)
 {
   return a - 6;
diff --git a/gcc/testsuite/gcc.target/aarch64/target_attr_8.c b/gcc/testsuite/gcc.target/aarch64/target_attr_8.c
index 32d173c..00ebd8c 100644
--- a/gcc/testsuite/gcc.target/aarch64/target_attr_8.c
+++ b/gcc/testsuite/gcc.target/aarch64/target_attr_8.c
@@ -5,7 +5,7 @@
Inlining should be allowed.  */
 
 __attribute__ ((target ("arch=armv8-a+nocrc")))
-int
+static int
 bar (int a)
 {
   return a - 6;

[PATCH][ARM] Use %wd format for lane printing in bounds_check

[Kyrill Tkachov]

Hi all,

I'm seeing these warnings when building arm.c:
warning: format ‘%lld’ expects argument of type ‘long long int’, but argument 5 
has type ‘long int’ [-Wformat=]

These appear in the bounds_check function when it tries to print out 
HOST_WIDE_INTs using the %lld format.
I believe the right way to print these is with %wd, which is what the 
equivalent aarch64 function does.

With this patch I don't see the warnings any more.
Bootstrapped and tested on arm.

Ok for trunk?

Thanks,
Kyrill

2015-08-14  Kyrylo Tkachov  

* config/arm/arm.c (bounds_check): Use %wd print format
for HOST_WIDE_INT arguments.
commit 004a6baac827ae61c6be32f570decff56e987995
Author: Kyrylo Tkachov 
Date:   Thu Aug 13 14:20:38 2015 +0100

[ARM] Use %wd format for lane printing in bounds_check

diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index a401f70..c9c8d7c 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -12847,10 +12847,10 @@ bounds_check (rtx operand, HOST_WIDE_INT low, HOST_WIDE_INT high,
   if (lane < low || lane >= high)
 {
   if (exp)
-	error ("%K%s %lld out of range %lld - %lld",
+	error ("%K%s %wd out of range %wd - %wd",
 	   exp, desc, lane, low, high - 1);
   else
-	error ("%s %lld out of range %lld - %lld", desc, lane, low, high - 1);
+	error ("%s %wd out of range %wd - %wd", desc, lane, low, high - 1);
 }
 }
 

Re: [PATCH] Improve performance for Haswell family.

[Uros Bizjak]

On Fri, Aug 14, 2015 at 11:44 AM, Yuri Rumyantsev  wrote:
> Hi All,
>
> Here is patch which contains
> (1) modifying of core2.md  to conform Haswell pipeline and adding of
> missed instruction reservation for instructions with vector operands.
> (2) increase reassociation width for float-point operations for
> Haswell family and 64-bit target, this allows to get +10% speedup on
> spec2006/410.bwaves for Skylake processor.
>
> Bootstrap and regression testing did not show any new failures.
> Is it OK for trunk?
>
> ChangeLog:
> 2015-08-14  Yuri Rumyantsev  
>
> * config/i386/core2.md: Confrom instruction reservation to Haswell
> pipeline.
> * config/i386/i386.c (ix86_reassociation_width): Increase reassociation
> width for float-point operations.

The i386.c change is OK.

Other that this, your patch substantially changes core2.md, and I'm
afraid this would hurt pipeline description of older processors. IMO,
it is better to introduce new haswell.md file and put the whole
haswell description here.

Uros.

Re: ptx debugging patch

[Thomas Schwinge]

Hi!

Approved long ago:

On Fri, 05 Dec 2014 16:38:32 -0700, Jeff Law  wrote:
> On 11/14/14 11:17, Bernd Schmidt wrote:
> > The situation with debugging on ptx is a little strange - it allows
> > .file and .loc directives for line numbers, and it provides a way to
> > define dwarf2 debug sections - but as far as I can tell, there's no way
> > of putting useful or accurate information into the latter. There's also
> > the slight problem that the data output directives used within those
> > sections differ from the ones used everywhere else in ptx code.
> >
> > The following patch adds a variant of dwarf2 debugging that supports
> > just line numbers. [...]
> >
> > How does this look? [...]

> I'll resist the temptation to bikeshed on the name :-)
> 
> OK.

..., and -- after minor modifiations a while ago, to adjust to current
trunk, and re-testing -- now actually committed in r226890.  I'm
confirming this does placate GCC's testsuite some more, but have not
actually done any tests with a consumer of PTX debug information.

commit a328e031d5e328eab6a2697b95f5c5e89d396604
Author: tschwinge 
Date:   Fri Aug 14 10:37:14 2015 +

Add DWARF2_LINENO_DEBUGGING_INFO, and use it for nvptx

gcc/
* config/nvptx/nvptx.c (nvptx_option_override): Don't override
debug options.
* config/nvptx/nvptx.h (DWARF2_LINENO_DEBUGGING_INFO): Define.
(DWARF2_DEBUGGING_INFO): Don't define.
* debug.h (dwarf2_lineno_debug_hooks): Declare.
* toplev.c (process_options): Add a case for it.
* dwarf2out.c (dwarf2_lineno_debug_hooks): New variable.
(dwarf2out_init): Skip most initializations if
DWARF2_LINENO_DEBUGGING_INFO, but set cur_line_info_table in that
case.
* defaults.h (PREFERRED_DEBUGGING_TYPE): Also use DWARF2_DEBUG if
DWARF2_LINENO_DEBUGGING_INFO.
* opts.c (set_debug_level): Likewise.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@226890 
138bc75d-0d04-0410-961f-82ee72b054a4
---
 gcc/ChangeLog|   17 +
 gcc/config/nvptx/nvptx.c |2 --
 gcc/config/nvptx/nvptx.h |2 +-
 gcc/debug.h  |1 +
 gcc/defaults.h   |2 +-
 gcc/dwarf2out.c  |   43 +++
 gcc/opts.c   |2 +-
 gcc/toplev.c |4 
 8 files changed, 68 insertions(+), 5 deletions(-)

diff --git gcc/ChangeLog gcc/ChangeLog
index af5e73c..154c077 100644
--- gcc/ChangeLog
+++ gcc/ChangeLog
@@ -1,3 +1,20 @@
+2015-08-14  Thomas Schwinge  
+   Bernd Schmidt  
+
+   * config/nvptx/nvptx.c (nvptx_option_override): Don't override
+   debug options.
+   * config/nvptx/nvptx.h (DWARF2_LINENO_DEBUGGING_INFO): Define.
+   (DWARF2_DEBUGGING_INFO): Don't define.
+   * debug.h (dwarf2_lineno_debug_hooks): Declare.
+   * toplev.c (process_options): Add a case for it.
+   * dwarf2out.c (dwarf2_lineno_debug_hooks): New variable.
+   (dwarf2out_init): Skip most initializations if
+   DWARF2_LINENO_DEBUGGING_INFO, but set cur_line_info_table in that
+   case.
+   * defaults.h (PREFERRED_DEBUGGING_TYPE): Also use DWARF2_DEBUG if
+   DWARF2_LINENO_DEBUGGING_INFO.
+   * opts.c (set_debug_level): Likewise.
+
 2015-08-14  James Greenhalgh  
 
* config/arm/types.md (is_neon_type): Add missing types.
diff --git gcc/config/nvptx/nvptx.c gcc/config/nvptx/nvptx.c
index 5d9b41f..a356967 100644
--- gcc/config/nvptx/nvptx.c
+++ gcc/config/nvptx/nvptx.c
@@ -103,8 +103,6 @@ nvptx_option_override (void)
   flag_toplevel_reorder = 1;
   /* Assumes that it will see only hard registers.  */
   flag_var_tracking = 0;
-  write_symbols = NO_DEBUG;
-  debug_info_level = DINFO_LEVEL_NONE;
 
   declared_fndecls_htab = hash_table::create_ggc (17);
   needed_fndecls_htab = hash_table::create_ggc (17);
diff --git gcc/config/nvptx/nvptx.h gcc/config/nvptx/nvptx.h
index 9cb46cc..afe4fcd 100644
--- gcc/config/nvptx/nvptx.h
+++ gcc/config/nvptx/nvptx.h
@@ -339,7 +339,7 @@ struct GTY(()) machine_function
 
 /* Misc.  */
 
-#define DWARF2_DEBUGGING_INFO 1
+#define DWARF2_LINENO_DEBUGGING_INFO 1
 
 #define CLZ_DEFINED_VALUE_AT_ZERO(MODE, VALUE) \
   ((VALUE) = GET_MODE_BITSIZE ((MODE)), 2)
diff --git gcc/debug.h gcc/debug.h
index 269c4d8..9784300 100644
--- gcc/debug.h
+++ gcc/debug.h
@@ -207,6 +207,7 @@ extern const struct gcc_debug_hooks dbx_debug_hooks;
 extern const struct gcc_debug_hooks sdb_debug_hooks;
 extern const struct gcc_debug_hooks xcoff_debug_hooks;
 extern const struct gcc_debug_hooks dwarf2_debug_hooks;
+extern const struct gcc_debug_hooks dwarf2_lineno_debug_hooks;
 extern const struct gcc_debug_hooks vmsdbg_debug_hooks;
 
 /* Dwarf2 frame information.  */
diff --git gcc/defaults.h gcc/defaults.h
index 9d38ba1..713ca07 100644
--- gcc/defaults.h
+++ gcc/defaults.h
@@ -932,7 +932,7 @@ see the files COPYING3 and COPYING.RUNTIME respectively.  
If not, see
 #elif defined SDB_DEBUGGING_INFO
 

Add checkpoint to libgomp dg-shouldfail tests (was: [PR testsuite/65205] Fix dg-shouldfail usage in OpenACC libgomp tests)

[Thomas Schwinge]

Hi!

(Can a Fortran person please comment on this: as it's nontrivial to write
to stderr, let's just write to stdout followed by a flush, which does
have the same ordering effect -- OK?)

On Thu, 30 Apr 2015 14:47:03 +0200, I wrote:
> Here is a patch, prepared by Jim Norris, to fix dg-shouldfail usage in
> OpenACC libgomp tests.  [...]

(These dg-shouldfail tests are expected to exit with a non-zero exit
status, and we're checking for a specific messages on stdout/stderr.)

> As obvious, committed to trunk in r222620:
> 
> commit cf9c09c49e63176ff8a1fba429971cb13226260b
> Author: tschwinge 
> Date:   Thu Apr 30 12:44:39 2015 +
> 
> [PR testsuite/65205] Fix dg-shouldfail usage in OpenACC libgomp tests
> 
>   PR testsuite/65205

> --- libgomp/testsuite/libgomp.oacc-c-c++-common/clauses-2.c
> +++ libgomp/testsuite/libgomp.oacc-c-c++-common/clauses-2.c
> @@ -64,4 +64,5 @@ main (int argc, char **argv)
>  
>  return 0;
>  }
> -/* { dg-shouldfail "libgomp: \[\h+,\d+\] is not mapped" } */
> +/* { dg-output "Trying to map into device 
> \\\[0x\[0-9a-f\]+..0x\[0-9a-f\]+\\\) object when 
> \\\[0x\[0-9a-f\]+..0x\[0-9a-f\]+\\\) is already mapped" }
> +/* { dg-shouldfail "" } */

It once occurred to me that it's also a good idea to verify that we're
actually reaching the expected checkpoint before terminating -- OK to
commit?

commit 105522789919a4c69246b32c368e242bcb5ed108
Author: Thomas Schwinge 
Date:   Thu Aug 13 14:03:09 2015 +0200

Add checkpoint to libgomp dg-shouldfail tests

That is, verify that we're actually reaching the expected checkpoint before
terminating.
---
 libgomp/testsuite/libgomp.oacc-c-c++-common/abort-1.c   |5 +++--
 libgomp/testsuite/libgomp.oacc-c-c++-common/abort-3.c   |5 +++--
 libgomp/testsuite/libgomp.oacc-c-c++-common/clauses-2.c |3 +++
 .../testsuite/libgomp.oacc-c-c++-common/data-already-1.c|3 +++
 .../testsuite/libgomp.oacc-c-c++-common/data-already-2.c|8 +++-
 .../testsuite/libgomp.oacc-c-c++-common/data-already-3.c|   11 ---
 .../testsuite/libgomp.oacc-c-c++-common/data-already-4.c|7 +--
 .../testsuite/libgomp.oacc-c-c++-common/data-already-5.c|7 +--
 .../testsuite/libgomp.oacc-c-c++-common/data-already-6.c|7 +--
 .../testsuite/libgomp.oacc-c-c++-common/data-already-7.c|7 +--
 .../testsuite/libgomp.oacc-c-c++-common/data-already-8.c|8 +++-
 libgomp/testsuite/libgomp.oacc-c-c++-common/lib-1.c |3 +++
 libgomp/testsuite/libgomp.oacc-c-c++-common/lib-11.c|3 +++
 libgomp/testsuite/libgomp.oacc-c-c++-common/lib-16.c|3 +++
 libgomp/testsuite/libgomp.oacc-c-c++-common/lib-17.c|3 +++
 libgomp/testsuite/libgomp.oacc-c-c++-common/lib-18.c|5 +++--
 libgomp/testsuite/libgomp.oacc-c-c++-common/lib-2.c |3 +++
 libgomp/testsuite/libgomp.oacc-c-c++-common/lib-20.c|3 +++
 libgomp/testsuite/libgomp.oacc-c-c++-common/lib-21.c|3 +++
 libgomp/testsuite/libgomp.oacc-c-c++-common/lib-22.c|3 +++
 libgomp/testsuite/libgomp.oacc-c-c++-common/lib-23.c|3 +++
 libgomp/testsuite/libgomp.oacc-c-c++-common/lib-25.c|3 +++
 libgomp/testsuite/libgomp.oacc-c-c++-common/lib-26.c|3 +++
 libgomp/testsuite/libgomp.oacc-c-c++-common/lib-27.c|3 +++
 libgomp/testsuite/libgomp.oacc-c-c++-common/lib-28.c|3 +++
 libgomp/testsuite/libgomp.oacc-c-c++-common/lib-29.c|3 +++
 libgomp/testsuite/libgomp.oacc-c-c++-common/lib-3.c |3 +++
 libgomp/testsuite/libgomp.oacc-c-c++-common/lib-30.c|3 +++
 libgomp/testsuite/libgomp.oacc-c-c++-common/lib-34.c|3 +++
 libgomp/testsuite/libgomp.oacc-c-c++-common/lib-35.c|3 +++
 libgomp/testsuite/libgomp.oacc-c-c++-common/lib-36.c|3 +++
 libgomp/testsuite/libgomp.oacc-c-c++-common/lib-39.c|3 +++
 libgomp/testsuite/libgomp.oacc-c-c++-common/lib-4.c |3 +++
 libgomp/testsuite/libgomp.oacc-c-c++-common/lib-40.c|3 +++
 libgomp/testsuite/libgomp.oacc-c-c++-common/lib-42.c|3 +++
 libgomp/testsuite/libgomp.oacc-c-c++-common/lib-43.c|3 +++
 libgomp/testsuite/libgomp.oacc-c-c++-common/lib-44.c|3 +++
 libgomp/testsuite/libgomp.oacc-c-c++-common/lib-47.c|3 +++
 libgomp/testsuite/libgomp.oacc-c-c++-common/lib-48.c|3 +++
 libgomp/testsuite/libgomp.oacc-c-c++-common/lib-52.c|3 +++
 libgomp/testsuite/libgomp.oacc-c-c++-common/lib-53.c|3 +++
 libgomp/testsuite/libgomp.oacc-c-c++-common/lib-54.c|3 +++
 libgomp/testsuite/libgomp.oacc-c-c++-common/lib-57.c|8 
 libgomp/testsuite/libgomp.oacc-c-c++-common/lib-58.c|8 
 libgomp/testsuite/libgomp.oacc-c-c++-common/lib-62.c|3 +++
 libgomp/testsuite/libgomp.oacc-c-c++-common/lib-63.c|3 +++
 libgomp/test

Re: Add checkpoint to libgomp dg-shouldfail tests (was: [PR testsuite/65205] Fix dg-shouldfail usage in OpenACC libgomp tests)

[Janne Blomqvist]

On Fri, Aug 14, 2015 at 1:56 PM, Thomas Schwinge
 wrote:
> Hi!
>
> (Can a Fortran person please comment on this: as it's nontrivial to write
> to stderr, let's just write to stdout followed by a flush, which does
> have the same ordering effect -- OK?)

If you want to write to stderr, with gfortran you can just do

  write(0, *) "Foo"

instead of

  print *, "Foo"

(With GFortran, unit=0 corresponds to stderr).




-- 
Janne Blomqvist

Re: Add checkpoint to libgomp dg-shouldfail tests (was: [PR testsuite/65205] Fix dg-shouldfail usage in OpenACC libgomp tests)

[FX]

> (Can a Fortran person please comment on this: as it's nontrivial to write
> to stderr, let's just write to stdout followed by a flush, which does
> have the same ordering effect -- OK?)

Although there are no absolute guarantees on flushing, it should work in 
practice.

Note that the FLUSH subroutine (as in “call flush”) is nonstandard. The 
standard way to achieve this is the FLUSH statement:

  use iso_fortran_env, only : output_unit
  flush output_unit

where the first line (“use …”) goes at the very top of the routine/program, 
above “implicit none”. So the patch for, e.g., 
libgomp.oacc-fortran/data-already-7.f would be:

Index: libgomp/testsuite/libgomp.oacc-fortran/data-already-7.f
===
--- libgomp/testsuite/libgomp.oacc-fortran/data-already-7.f (revision 
226823)
+++ libgomp/testsuite/libgomp.oacc-fortran/data-already-7.f (working copy)
@@ -1,5 +1,6 @@
 ! { dg-skip-if "" { *-*-* } { "*" } { "-DACC_MEM_SHARED=0" } }
 
+  USE ISO_FORTRAN_ENV, ONLY: OUTPUT_UNIT
   IMPLICIT NONE
   INCLUDE "openacc_lib.h"
 
@@ -7,6 +8,8 @@
 
 !$ACC ENTER DATA CREATE (I)
   CALL ACC_CREATE (I)
+  PRINT *, "CheCKpOInT"
+  FLUSH OUTPUT_UNIT
 
   END
 


I hope this helps,
FX

[PATCH] Fix middle-end/67133, part 1

[Marek Polacek]

As outlined in the PR, this fixes one ICE.  The code in question here
tries to determine whether OP can be derived as non-NULL.  In case the
function has the nonnull attribute that applies to all the arguments,
we want to see whether OP is in this argument list.  But nonnull only
appertains to pointers.  Some ssa_names don't have a type so check for
that first instead of segv before looking at its tree code.

Bootstrapped/regtested on x86_64-linux, ok for trunk?

2015-08-14  Marek Polacek  

PR middle-end/67133
* gimple.c (infer_nonnull_range_by_attribute): Handle null TREE_TYPE.

* g++.dg/torture/pr67133.C: New test.

diff --git gcc/gimple.c gcc/gimple.c
index cca328a..1482eb4 100644
--- gcc/gimple.c
+++ gcc/gimple.c
@@ -2678,14 +2678,16 @@ infer_nonnull_range_by_attribute (gimple stmt, tree op)
  if (attrs == NULL_TREE)
return false;
 
- /* If "nonnull" applies to all the arguments, then ARG
+ /* If "nonnull" applies to all the arguments, then OP
 is non-null if it's in the argument list.  */
  if (TREE_VALUE (attrs) == NULL_TREE)
{
  for (unsigned int i = 0; i < gimple_call_num_args (stmt); i++)
{
- if (POINTER_TYPE_P (TREE_TYPE (gimple_call_arg (stmt, i)))
- && operand_equal_p (op, gimple_call_arg (stmt, i), 0))
+ tree arg = gimple_call_arg (stmt, i);
+ if (TREE_TYPE (arg) != NULL_TREE
+ && POINTER_TYPE_P (TREE_TYPE (arg))
+ && operand_equal_p (op, arg, 0))
return true;
}
  return false;
diff --git gcc/testsuite/g++.dg/torture/pr67133.C 
gcc/testsuite/g++.dg/torture/pr67133.C
index e69de29..0f23572 100644
--- gcc/testsuite/g++.dg/torture/pr67133.C
+++ gcc/testsuite/g++.dg/torture/pr67133.C
@@ -0,0 +1,46 @@
+// { dg-do compile }
+// { dg-additional-options "-fisolate-erroneous-paths-attribute" }
+
+class A;
+struct B {
+  typedef A type;
+};
+template  struct I : B {};
+class C {
+public:
+  C(char *);
+  int size();
+};
+template  struct D;
+template > class F {
+  class G {
+template  static _Tp *__test();
+typedef int _Del;
+
+  public:
+typedef decltype(__test<_Del>()) type;
+  };
+
+public:
+  typename I<_Tp>::type operator*() {
+typename G::type a = 0;
+return *a;
+  }
+};
+class H {
+  F Out;
+  H();
+};
+void fn1(void *, void *, int) __attribute__((__nonnull__));
+class A {
+  int OutBufEnd, OutBufCur;
+
+public:
+  void operator<<(C p1) {
+int b, c = p1.size();
+if (OutBufEnd)
+  fn1(&OutBufCur, &b, c);
+  }
+};
+char* a;
+H::H() { *Out << a; }

Marek

Re: [patch] Add SD-6 features test macros for recent libstdc++ changes

[Jonathan Wakely]

And another one. Committed to trunk.
commit 6c9731439357e2a385b16ad6521c05776ecf0562
Author: Jonathan Wakely 
Date:   Thu Aug 13 16:11:43 2015 +0100

	* include/experimental/array: Add feature-test macro.
	* testsuite/experimental/array/neg.cc: Update dg-error.

diff --git a/libstdc++-v3/include/experimental/array b/libstdc++-v3/include/experimental/array
index a6e983a..9617481 100644
--- a/libstdc++-v3/include/experimental/array
+++ b/libstdc++-v3/include/experimental/array
@@ -47,6 +47,7 @@ inline namespace fundamentals_v2
 {
 _GLIBCXX_BEGIN_NAMESPACE_VERSION
 
+#define __cpp_lib_experimental_make_array 201505
   /**
* @defgroup make_array Array creation functions
* @ingroup experimental
diff --git a/libstdc++-v3/testsuite/experimental/array/neg.cc b/libstdc++-v3/testsuite/experimental/array/neg.cc
index df532d1..5db2a18 100644
--- a/libstdc++-v3/testsuite/experimental/array/neg.cc
+++ b/libstdc++-v3/testsuite/experimental/array/neg.cc
@@ -24,5 +24,5 @@ int main()
 {
   int dummy;
   auto bad = std::experimental::make_array(std::ref(dummy));
-  // { dg-error "make_array cannot be used without an explicit target type if any of the types given is a reference_wrapper" "" { target *-*-* } 76 }
+  // { dg-error "make_array cannot be used without an explicit target type if any of the types given is a reference_wrapper" "" { target *-*-* } 77 }
 }

Re: [v3 patch] Fix self-assignment in std::experimental::any

[Jonathan Wakely]

On 30/07/15 11:00 +0100, Jonathan Wakely wrote:

When I fixed any's copying of non-trivial types I broke the
self-assignment case. This adds an explicit check for it.

Thanks to Axel Menzel for noticing the bug.


Similar checks in move-assign and swap members, and a better test.

Tested powerpc64le-linux, committed to trunk.
commit d1f50d92b49bec8849bdfd6ea56fbfd1480c5edf
Author: Jonathan Wakely 
Date:   Fri Aug 14 10:45:19 2015 +0100

	* include/experimental/any (any::operator=(const any&)): Move check
	for self-assignment.
	(any::operator=(any&&)): Add check for self-assignment.
	(any::operator=(_ValueType&&)): Constrain template argument.
	(any::swap(any&)): Add check for self-swap.
	* testsuite/experimental/any/assign/self.cc: Test move and swap.
	* testsuite/experimental/any/misc/any_cast_neg.cc: Update dg-error.

diff --git a/libstdc++-v3/include/experimental/any b/libstdc++-v3/include/experimental/any
index fbb70a7..dae82b5 100644
--- a/libstdc++-v3/include/experimental/any
+++ b/libstdc++-v3/include/experimental/any
@@ -175,12 +175,9 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 /// Copy the state of another object.
 any& operator=(const any& __rhs)
 {
-  if (this == &__rhs)
-	return *this;
-
   if (__rhs.empty())
 	clear();
-  else
+  else if (this != &__rhs)
 	{
 	  if (!empty())
 	_M_manager(_Op_destroy, this, nullptr);
@@ -200,7 +197,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 {
   if (__rhs.empty())
 	clear();
-  else
+  else if (this != &__rhs)
 	{
 	  if (!empty())
 	_M_manager(_Op_destroy, this, nullptr);
@@ -213,7 +210,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 
 /// Store a copy of @p __rhs as the contained object.
 template
-  any& operator=(_ValueType&& __rhs)
+  enable_if_t>::value, any&>
+  operator=(_ValueType&& __rhs)
   {
 	*this = any(std::forward<_ValueType>(__rhs));
 	return *this;
@@ -233,30 +231,33 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 
 /// Exchange state with another object.
 void swap(any& __rhs) noexcept
-  {
-	if (empty() && __rhs.empty())
-	  return;
+{
+  if (empty() && __rhs.empty())
+	return;
 
-	if (!empty() && !__rhs.empty())
-	  {
-	any __tmp;
-	_Arg __arg;
-	__arg._M_any = &__tmp;
-	__rhs._M_manager(_Op_xfer, &__rhs, &__arg);
-	__arg._M_any = &__rhs;
-	_M_manager(_Op_xfer, this, &__arg);
-	__arg._M_any = this;
-	__tmp._M_manager(_Op_xfer, &__tmp, &__arg);
-	  }
-	else
-	  {
-	any* __empty = empty() ? this : &__rhs;
-	any* __full = empty() ? &__rhs : this;
-	_Arg __arg;
-	__arg._M_any = __empty;
-	__full->_M_manager(_Op_xfer, __full, &__arg);
-	  }
-  }
+  if (!empty() && !__rhs.empty())
+	{
+	  if (this == &__rhs)
+	return;
+
+	  any __tmp;
+	  _Arg __arg;
+	  __arg._M_any = &__tmp;
+	  __rhs._M_manager(_Op_xfer, &__rhs, &__arg);
+	  __arg._M_any = &__rhs;
+	  _M_manager(_Op_xfer, this, &__arg);
+	  __arg._M_any = this;
+	  __tmp._M_manager(_Op_xfer, &__tmp, &__arg);
+	}
+  else
+	{
+	  any* __empty = empty() ? this : &__rhs;
+	  any* __full = empty() ? &__rhs : this;
+	  _Arg __arg;
+	  __arg._M_any = __empty;
+	  __full->_M_manager(_Op_xfer, __full, &__arg);
+	}
+}
 
 // observers
 
diff --git a/libstdc++-v3/testsuite/experimental/any/assign/self.cc b/libstdc++-v3/testsuite/experimental/any/assign/self.cc
index 0fb9566..79c6f0f 100644
--- a/libstdc++-v3/testsuite/experimental/any/assign/self.cc
+++ b/libstdc++-v3/testsuite/experimental/any/assign/self.cc
@@ -18,8 +18,17 @@
 // { dg-options "-std=gnu++14" }
 
 #include 
+#include 
 #include 
 
+std::set live_objects;
+
+struct A {
+  A() { live_objects.insert(this); }
+  ~A() { live_objects.erase(this); }
+  A(const A& a) { VERIFY(live_objects.count(&a)); live_objects.insert(this); }
+};
+
 void
 test01()
 {
@@ -29,13 +38,56 @@ test01()
   a = a;
   VERIFY( a.empty() );
 
-  a = 1;
+  a = A{};
   a = a;
   VERIFY( !a.empty() );
+
+  a.clear();
+  VERIFY( live_objects.empty() );
+}
+
+void
+test02()
+{
+  using std::experimental::any;
+
+  struct X {
+any a;
+  };
+
+  X x;
+  std::swap(x, x); // results in "self-move-assignment" of X::a
+  VERIFY( x.a.empty() );
+
+  x.a = A{};
+  std::swap(x, x); // results in "self-move-assignment" of X::a
+  VERIFY( !x.a.empty() );
+
+  x.a.clear();
+  VERIFY( live_objects.empty() );
+}
+
+void
+test03()
+{
+  using std::experimental::any;
+
+  any a;
+  a.swap(a);
+  VERIFY( a.empty() );
+
+  a = A{};
+  a.swap(a);
+  VERIFY( !a.empty() );
+
+  a.clear();
+  VERIFY( live_objects.empty() );
 }
 
 int
 main()
 {
   test01();
+  test02();
+  test03();
 }
diff --git a/libstdc++-v3/testsuite/experimental/any/misc/any_cast_neg.cc b/libstdc++-v3/testsuite/experimental/any/misc/any_cast_neg.cc
index b88592a..1d1180c 100644
--- a/libstdc++-v3/testsuite/experimental/any/misc/any_cast_neg.cc
+++ b/libstdc++-v3/testsuite/experimental/any/misc/any_cast_neg.cc
@@ -26,5 +26,5 @@ void test01()
   using std::

RE: [PATCH][MIPS] Fix register renaming in the interrupt handlers

[Robert Suchanek]

Hi,

> > You also need to do the same thing for TARGET_HARD_REGNO_SCRATCH_OK,
> > to stop peephole2 from using unsaved registers as scratch registers.
> >
> > I should dig out my patches to clean up this interface.  It's just
> > too brittle to have two macros that say what registers can be used
> > after reload.

Indeed. I naively thought that there would be a single place that needed
an update and overlooked this hook. 

> Gosh, I don't like the interface of them at all.  I have interrupt functions
> and I want all the goodness out of gcc and I want gcc to just know that it
> can't use registers it doesn't want to save for any reason that the port
> marked as saved by the calling api of the function.  :-(  Very few ports (3)
> define TARGET_HARD_REGNO_SCRATCH_OK and many port (19 or so) don't define
> this but do seem to have interrupt functions.  The existing documentation
> seems not give be enough information to let me decide if I need to define it
> or not.  I read through all the ports that do define it, and none of them
> shed any light on to allow me to decide if my port needs to or not.
> 
> So, first question is, are the 16 other ports that have interrupt functions
> and don't define this just buggy (or non-optimal)?  How can I tell if I need
> to or not?  A single example of that does cause a port to see it and a single
> example of why a port would not need to define it would be instructive.
> 
> Along the lines of TARGET_CALL_FUSAGE_CONTAINS_NON_CALLEE_CLOBBERS, I'd be
> willing to explain the required abi of each function, and then I just want
> gcc to just work. All functions are normal, except for interrupt functions,
> all allocatable register need to be saved.  I think this is a universally
> true thing, and it just happens to be true on my port as well.
> 
> Anyway, I'd love to see gcc improved in this area.
> 
> This one is a pet peeve of mine as I've seen what happens to software when a
> single register that should have been saved, wasn't.  It was slightly
> annoying to track down and find.  Fixing was trivial.

The cleanup as Richard suggested would probably be a good start. It's 
interesting
that this kind of bug wasn't discovered earlier and likely existing for
several years.

The below is an updated version of the patch to include the other hook.

Regards,
Robert

gcc/
* config/mips/mips-protos.h (mips_hard_regno_rename_ok): New prototype.
* config/mips/mips.c (mips_hard_regno_rename_ok): New function.
(mips_hard_regno_scratch_ok): Likewise.
(TARGET_HARD_REGNO_SCRATCH_OK): Define macro.
* config/mips/mips.h (HARD_REGNO_RENAME_OK): New.

gcc/testsuite/
* gcc.target/mips/interrupt_handler-bug-1.c: New test.
---
 gcc/config/mips/mips-protos.h  |  1 +
 gcc/config/mips/mips.c | 30 ++
 gcc/config/mips/mips.h |  3 +++
 .../gcc.target/mips/interrupt_handler-bug-1.c  | 11 
 4 files changed, 45 insertions(+)
 create mode 100644 gcc/testsuite/gcc.target/mips/interrupt_handler-bug-1.c

diff --git a/gcc/config/mips/mips-protos.h b/gcc/config/mips/mips-protos.h
index 6ce3d70..e43 100644
--- a/gcc/config/mips/mips-protos.h
+++ b/gcc/config/mips/mips-protos.h
@@ -317,6 +317,7 @@ extern unsigned int mips_sync_loop_insns (rtx, rtx *);
 extern const char *mips_output_division (const char *, rtx *);
 extern const char *mips_msa_output_division (const char *, rtx *);
 extern const char *mips_output_probe_stack_range (rtx, rtx);
+extern bool mips_hard_regno_rename_ok (unsigned int, unsigned int);
 extern unsigned int mips_hard_regno_nregs (int, machine_mode);
 extern bool mips_linked_madd_p (rtx, rtx);
 extern bool mips_store_data_bypass_p (rtx, rtx);
diff --git a/gcc/config/mips/mips.c b/gcc/config/mips/mips.c
index a9829bd..d0851e9 100644
--- a/gcc/config/mips/mips.c
+++ b/gcc/config/mips/mips.c
@@ -12959,6 +12959,33 @@ mips_hard_regno_mode_ok_p (unsigned int regno, 
machine_mode mode)
   return false;
 }
 
+/* Return nonzero if register OLD_REG can be renamed to register NEW_REG.  */
+
+bool
+mips_hard_regno_rename_ok (unsigned int old_reg ATTRIBUTE_UNUSED,
+  unsigned int new_reg)
+{
+  /* Interrupt functions can only use registers that have already been
+ saved by the prologue, even if they would normally be call-clobbered.  */
+  if (cfun->machine->interrupt_handler_p && !df_regs_ever_live_p (new_reg))
+return false;
+
+  return true;
+}
+
+/* Return nonzero if register REGNO can be used as a scratch register
+   in peephole2.  */
+
+bool
+mips_hard_regno_scratch_ok (unsigned int regno)
+{
+  /* See mips_hard_regno_rename_ok.  */
+  if (cfun->machine->interrupt_handler_p && !df_regs_ever_live_p (regno))
+return false;
+
+  return true;
+}
+
 /* Implement HARD_REGNO_NREGS.  */
 
 unsigned int
@@ -22428,6 +22455,9 @@ mips_lra_p (void)
 #undef TARGET_SCHED_SET_SCHED_FLAGS
 #define TARGET_SCHED_SET_SCHED_FL

[PATCH] Disable -mbranch-likely for -Os when targetting generic architecture

[Robert Suchanek]

Hi,

The patch below disables generation of the branch likely instructions for -Os
but only for generic architecture.  The branch likely may result in some
code size reduction but the cost of running the code on R6 core is significant.

Disabling this for generic architecture would therefore be desirable for now.

Ok to apply?

Regards,
Robert

gcc/
* mips.c (mips_option_override): Enable branch likely for non-generic
architecture.
---
 gcc/config/mips/mips.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/config/mips/mips.c b/gcc/config/mips/mips.c
index a9829bd..68def06 100644
--- a/gcc/config/mips/mips.c
+++ b/gcc/config/mips/mips.c
@@ -19564,7 +19564,7 @@ mips_option_override (void)
   if ((target_flags_explicit & MASK_BRANCHLIKELY) == 0)
 {
   if (ISA_HAS_BRANCHLIKELY
- && (optimize_size
+ && ((optimize_size && strncmp (mips_arch_info->name, "mips", 4) != 0)
  || (mips_tune_info->tune_flags & PTF_AVOID_BRANCHLIKELY) == 0))
target_flags |= MASK_BRANCHLIKELY;
   else
-- 
2.4.5

Re: [PATCH] Fix middle-end/67133, part 1

[Richard Biener]

On Fri, Aug 14, 2015 at 1:20 PM, Marek Polacek  wrote:
> As outlined in the PR, this fixes one ICE.  The code in question here
> tries to determine whether OP can be derived as non-NULL.  In case the
> function has the nonnull attribute that applies to all the arguments,
> we want to see whether OP is in this argument list.  But nonnull only
> appertains to pointers.  Some ssa_names don't have a type so check for
> that first instead of segv before looking at its tree code.

Huh?  All but released SSA names have a type.  So this gets invoked on dead code
somehow?

RIchard.

>
> Bootstrapped/regtested on x86_64-linux, ok for trunk?
>
> 2015-08-14  Marek Polacek  
>
> PR middle-end/67133
> * gimple.c (infer_nonnull_range_by_attribute): Handle null TREE_TYPE.
>
> * g++.dg/torture/pr67133.C: New test.
>
> diff --git gcc/gimple.c gcc/gimple.c
> index cca328a..1482eb4 100644
> --- gcc/gimple.c
> +++ gcc/gimple.c
> @@ -2678,14 +2678,16 @@ infer_nonnull_range_by_attribute (gimple stmt, tree 
> op)
>   if (attrs == NULL_TREE)
> return false;
>
> - /* If "nonnull" applies to all the arguments, then ARG
> + /* If "nonnull" applies to all the arguments, then OP
>  is non-null if it's in the argument list.  */
>   if (TREE_VALUE (attrs) == NULL_TREE)
> {
>   for (unsigned int i = 0; i < gimple_call_num_args (stmt); i++)
> {
> - if (POINTER_TYPE_P (TREE_TYPE (gimple_call_arg (stmt, i)))
> - && operand_equal_p (op, gimple_call_arg (stmt, i), 0))
> + tree arg = gimple_call_arg (stmt, i);
> + if (TREE_TYPE (arg) != NULL_TREE
> + && POINTER_TYPE_P (TREE_TYPE (arg))
> + && operand_equal_p (op, arg, 0))
> return true;
> }
>   return false;
> diff --git gcc/testsuite/g++.dg/torture/pr67133.C 
> gcc/testsuite/g++.dg/torture/pr67133.C
> index e69de29..0f23572 100644
> --- gcc/testsuite/g++.dg/torture/pr67133.C
> +++ gcc/testsuite/g++.dg/torture/pr67133.C
> @@ -0,0 +1,46 @@
> +// { dg-do compile }
> +// { dg-additional-options "-fisolate-erroneous-paths-attribute" }
> +
> +class A;
> +struct B {
> +  typedef A type;
> +};
> +template  struct I : B {};
> +class C {
> +public:
> +  C(char *);
> +  int size();
> +};
> +template  struct D;
> +template > class F {
> +  class G {
> +template  static _Tp *__test();
> +typedef int _Del;
> +
> +  public:
> +typedef decltype(__test<_Del>()) type;
> +  };
> +
> +public:
> +  typename I<_Tp>::type operator*() {
> +typename G::type a = 0;
> +return *a;
> +  }
> +};
> +class H {
> +  F Out;
> +  H();
> +};
> +void fn1(void *, void *, int) __attribute__((__nonnull__));
> +class A {
> +  int OutBufEnd, OutBufCur;
> +
> +public:
> +  void operator<<(C p1) {
> +int b, c = p1.size();
> +if (OutBufEnd)
> +  fn1(&OutBufCur, &b, c);
> +  }
> +};
> +char* a;
> +H::H() { *Out << a; }
>
> Marek

Re: [patch,libgfortran,toplevel] Use libbacktrace in libgfortran

[Uros Bizjak]

Hello!

> Use libbacktrace (instead of our own unwind-based code) to display backtraces 
> from libgfortran
> upon error or user request.
>
>  1. In toplevel Makefile.def, make libgfortran depend on libbacktrace (needs 
> global reviewer
> approval)
>   2. In gcc/fortran/config-lang.in, add libbacktrace to target_libs
>   3. In libgfortran, we remove our own code and substitute calls to 
> libbacktrace
>
> Bootstrapped and regtested on x86_64-pc-linux-gnu (which has full 
> libbacktrace support) and
> x86_64-apple-darwin14 (which has minimal libbacktrace support). OK to commit 
> to trunk?

backtrace.ChangeLog is unreadable for me ...

Uros.

Re: Forwarding -foffload=[...] from the driver (compile-time) to libgomp (run-time) (was: [PATCH 2/n] OpenMP 4.0 offloading infrastructure: LTO streaming)

[Ilya Verbin]

2015-08-14 11:47 GMT+02:00 Thomas Schwinge :
> On Wed, 5 Aug 2015 18:09:04 +0300, Ilya Verbin  wrote:
>> > > @@ -1095,6 +1092,8 @@ GOMP_target (int device, void (*fn) (void *), 
>> > > const void *unused,
>> > >  return gomp_target_fallback (fn, hostaddrs);
>> > >
>> > >void *fn_addr = gomp_get_target_fn_addr (devicep, fn);
>> > > +  if (fn_addr == NULL)
>> > > +return gomp_target_fallback (fn, hostaddrs);
>
> Is that reliable?  Consider the following scenario, with f1 and f2
> implemented in separate TUs:
>
> #pragma omp target data [map clauses]
> {
>   f1([...]);
>   f2([...]);
> }
>
> Consider that in f1 we have a OpenMP target region with offloading data
> available, and in f2 we have a OpenMP target region without offloading
> data available.  In this case, the GOMP_target in f1 will execute on the
> offloading target, but the GOMP_target in f2 will resort to host fallback
> -- and we then likely have data inconsistencies, as the data specified by
> the map clauses is not synchronized between host and device.
>
> Admittedly, this is user error (inconsistent set of offloading functions
> available -- need either all, or none), but in such a scenario probably
> we should be doing a better job (at detecting this).  (Note, I'm not sure
> whether my current patch actually does any better.)  ;-)

You're right. That's why I didn't send this patch for review yet.
My current plan is as follows:
* Use this approach for architectures with shared memory, since it
allows mixing host and target functions.
* For non-shared memory, at the first splay tree lookup:
** If target fn is not found, run the whole program in host-fallback mode.
** If it's found, then all target fns must exist. I.e. if some
tgt_addr (not first) is NULL, then libgomp will issue an error as it
does now.

  -- Ilya

Re: [PATCH] Fix middle-end/67133, part 1

[Marek Polacek]

On Fri, Aug 14, 2015 at 03:14:10PM +0200, Richard Biener wrote:
> On Fri, Aug 14, 2015 at 1:20 PM, Marek Polacek  wrote:
> > As outlined in the PR, this fixes one ICE.  The code in question here
> > tries to determine whether OP can be derived as non-NULL.  In case the
> > function has the nonnull attribute that applies to all the arguments,
> > we want to see whether OP is in this argument list.  But nonnull only
> > appertains to pointers.  Some ssa_names don't have a type so check for
> > that first instead of segv before looking at its tree code.
> 
> Huh?  All but released SSA names have a type.  So this gets invoked on dead 
> code

I suppose so.  It gets
 def_stmt 

version 13 in-free-list>

(it didn't ICE before r209891 because the operand_equal_p check came first and
returned false so we didn't check the type).

Marek

Re: [Aarch64][target/PR 67143] Use correct constraints on operands for atomic operations.

[James Greenhalgh]

On Thu, Aug 13, 2015 at 03:48:22PM +0100, Matthew Wahab wrote:
> On 12/08/15 22:26, Joseph Myers wrote:
> > On Tue, 11 Aug 2015, Matthew Wahab wrote:
> >
> >>PR target/67143
> >>* gcc.target/aarch64/pr67143.c: New
> >
> > What's architecture-specific about this test?  That is, why doesn't it
> > just go in gcc.c-torture/compile (no dg- directives needed, automatically
> > looped over optimization options)?
> >
> 
> Attached is an updated patch which puts the pr67143.c test case in
> gcc.c-torture/compile and drops the dg- directives.
> 
> Tested for aarch64-none-eabi with cross-compiled check-gcc. Also ran
> check-gcc for x86_64-none-linux-gnu, to check the new test case.
> 
> Ok?
> Matthew

OK, and please backport it to the 5.x (and 4.9.x if needed) branches.

Thanks,
James

> gcc/
> 2015-08-13  Matthew Wahab  
> 
>   PR target/67143
>   * config/aarch64/atomics.md (atomic_): Replace
>   'lconst_atomic' with 'const_atomic'.
>   (atomic_fetch_): Likewise.
>   (atomic__fetch): Likewise.
>   * config/aarch64/iterators.md (lconst-atomic): Move below
>   'const_atomic'.
>   (const_atomic): New.
> 
> gcc/testsuite/
> 2015-08-13  Matthew Wahab  
>   Matthias Klose  
> 
>   PR target/67143
>   * gcc.c-torture/compile/pr67143.c: New
>   * gcc.target/aarch64/atomic-op-imm.c
>   (atomic_fetch_add_negative_RELAXED): New.
>   (atomic_fetch_sub_negative_ACQUIRE): New.
> 

[Aarch64] Adjust tests to take LSE extension into account.

[Matthew Wahab]

Tests for the code generated by the Aarch64 backends for the __sync and
__atomic builtins assume that they are implemented using sequences based
on load-exclusive and store-exclusive instructions. ARMv8.1 introduces
atomic instructions which can be used to implement __sync and __atomic
builtins. This means that the tests could fail if the default target is
set to a cpu that enables the atomic instructions.

This patch adjusts the tests to explicitly disable the LSE extension
providing the atomic instructions so that the compiler falls back to
generating the load-excluclusive/store-exclusive sequences.

Tested for aarch64-none-elf with cross-compiled check-gcc. Also tested
aarch64-none-elf with check-gcc using a custom build of the compiler
with LSE extensions (atomic CAS) enabled by default.

Ok for trunk?
Matthew

gcc/testsuite
2015-08-14  Matthew Wahab  

* gcc.target/aarch64/atomic-comp-swap-release-acquire.c: Adjust
dg-options to disable LSE extensions.
* gcc.target/aarch64/atomic-op-acq_rel.c: Likewise.
* gcc.target/aarch64/atomic-op-acquire.c: Likewise.
* gcc.target/aarch64/atomic-op-char.c: Likewise.
* gcc.target/aarch64/atomic-op-consume.c: Likewise.
* gcc.target/aarch64/atomic-op-long.c: Likewise.
* gcc.target/aarch64/atomic-op-relaxed.c: Likewise.
* gcc.target/aarch64/atomic-op-seq_cst.c: Likewise.
* gcc.target/aarch64/atomic-op-short.c: Likewise.
* gcc.target/aarch64/sync-comp-swap.c: Likewise.
* gcc.target/aarch64/sync-op-acquire.c: Likewise.
* gcc.target/aarch64/sync-op-full.c: Likewise.
* gcc.target/aarch64/sync-op-release.c: Likewise.
diff --git a/gcc/testsuite/gcc.target/aarch64/atomic-comp-swap-release-acquire.c b/gcc/testsuite/gcc.target/aarch64/atomic-comp-swap-release-acquire.c
index b8f098d..49ca5d0 100644
--- a/gcc/testsuite/gcc.target/aarch64/atomic-comp-swap-release-acquire.c
+++ b/gcc/testsuite/gcc.target/aarch64/atomic-comp-swap-release-acquire.c
@@ -1,5 +1,5 @@
 /* { dg-do compile } */
-/* { dg-options "-O2 -fno-ipa-icf" } */
+/* { dg-options "-march=armv8-a+nolse -O2 -fno-ipa-icf" } */
 
 #include "atomic-comp-swap-release-acquire.x"
 
diff --git a/gcc/testsuite/gcc.target/aarch64/atomic-op-acq_rel.c b/gcc/testsuite/gcc.target/aarch64/atomic-op-acq_rel.c
index 8569ac0..74f2634 100644
--- a/gcc/testsuite/gcc.target/aarch64/atomic-op-acq_rel.c
+++ b/gcc/testsuite/gcc.target/aarch64/atomic-op-acq_rel.c
@@ -1,5 +1,5 @@
 /* { dg-do compile } */
-/* { dg-options "-O2" } */
+/* { dg-options "-march=armv8-a+nolse -O2" } */
 
 #include "atomic-op-acq_rel.x"
 
diff --git a/gcc/testsuite/gcc.target/aarch64/atomic-op-acquire.c b/gcc/testsuite/gcc.target/aarch64/atomic-op-acquire.c
index 57e6d57..66c1b1e 100644
--- a/gcc/testsuite/gcc.target/aarch64/atomic-op-acquire.c
+++ b/gcc/testsuite/gcc.target/aarch64/atomic-op-acquire.c
@@ -1,5 +1,5 @@
 /* { dg-do compile } */
-/* { dg-options "-O2" } */
+/* { dg-options "-march=armv8-a+nolse -O2" } */
 
 #include "atomic-op-acquire.x"
 
diff --git a/gcc/testsuite/gcc.target/aarch64/atomic-op-char.c b/gcc/testsuite/gcc.target/aarch64/atomic-op-char.c
index d6c2aa5..c09d043 100644
--- a/gcc/testsuite/gcc.target/aarch64/atomic-op-char.c
+++ b/gcc/testsuite/gcc.target/aarch64/atomic-op-char.c
@@ -1,5 +1,5 @@
 /* { dg-do compile } */
-/* { dg-options "-O2" } */
+/* { dg-options "-march=armv8-a+nolse -O2" } */
 
 #include "atomic-op-char.x"
 
diff --git a/gcc/testsuite/gcc.target/aarch64/atomic-op-consume.c b/gcc/testsuite/gcc.target/aarch64/atomic-op-consume.c
index 26ebbdf..5783ab8 100644
--- a/gcc/testsuite/gcc.target/aarch64/atomic-op-consume.c
+++ b/gcc/testsuite/gcc.target/aarch64/atomic-op-consume.c
@@ -1,5 +1,5 @@
 /* { dg-do compile } */
-/* { dg-options "-O2" } */
+/* { dg-options "-march=armv8-a+nolse -O2" } */
 
 #include "atomic-op-consume.x"
 
diff --git a/gcc/testsuite/gcc.target/aarch64/atomic-op-long.c b/gcc/testsuite/gcc.target/aarch64/atomic-op-long.c
index 0672d48..d011f8c 100644
--- a/gcc/testsuite/gcc.target/aarch64/atomic-op-long.c
+++ b/gcc/testsuite/gcc.target/aarch64/atomic-op-long.c
@@ -1,5 +1,5 @@
 /* { dg-do compile } */
-/* { dg-options "-O2" } */
+/* { dg-options "-march=armv8-a+nolse -O2" } */
 
 long v = 0;
 
diff --git a/gcc/testsuite/gcc.target/aarch64/atomic-op-relaxed.c b/gcc/testsuite/gcc.target/aarch64/atomic-op-relaxed.c
index cd3fe2c..ed96bfd 100644
--- a/gcc/testsuite/gcc.target/aarch64/atomic-op-relaxed.c
+++ b/gcc/testsuite/gcc.target/aarch64/atomic-op-relaxed.c
@@ -1,5 +1,5 @@
 /* { dg-do compile } */
-/* { dg-options "-O2" } */
+/* { dg-options "-march=armv8-a+nolse -O2" } */
 
 #include "atomic-op-relaxed.x"
 
diff --git a/gcc/testsuite/gcc.target/aarch64/atomic-op-release.c b/gcc/testsuite/gcc.target/aarch64/atomic-op-release.c
index 2fc04b2..fc4be17 100644
--- a/gcc/testsuite/gcc.target/aarch64/atomic-op-release.c
+++ b/gcc/testsuite/gcc.target/aarch64/atomic-op-release.c
@@ -1,5 +1,5 @@
 /* { dg-

Re: [patch,libgfortran,toplevel] Use libbacktrace in libgfortran

[Ian Lance Taylor]

On Fri, Aug 14, 2015 at 1:32 AM, FX  wrote:
> Use libbacktrace (instead of our own unwind-based code) to display backtraces 
> from libgfortran upon error or user request.
>
>   1. In toplevel Makefile.def, make libgfortran depend on libbacktrace (needs 
> global reviewer approval)

This change (and the corresponding change to Makefile.in) is OK.

Thanks.

Ian

Re: [patch,libgfortran,toplevel] Use libbacktrace in libgfortran

[FX]

>> Use libbacktrace (instead of our own unwind-based code) to display 
>> backtraces from libgfortran
>> upon error or user request.
>> 
>> 1. In toplevel Makefile.def, make libgfortran depend on libbacktrace (needs 
>> global reviewer
>> approval)
>>  2. In gcc/fortran/config-lang.in, add libbacktrace to target_libs
>>  3. In libgfortran, we remove our own code and substitute calls to 
>> libbacktrace
>> 
>> Bootstrapped and regtested on x86_64-pc-linux-gnu (which has full 
>> libbacktrace support) and
>> x86_64-apple-darwin14 (which has minimal libbacktrace support). OK to commit 
>> to trunk?
> 
> backtrace.ChangeLog is unreadable for me …

Sending again, this time with .txt extension, hoping this makes it go through 
OK.

FX

2015-08-14  Francois-Xavier Coudert  

PR libfortran/54572
* Makefile.def: Make libgfortran depend on libbacktrace.
* Makefile.in: Regenerate.


2015-08-14  Francois-Xavier Coudert  

PR libfortran/54572
* config-lang.in: Add libbacktrace to target_libs.


2015-08-14  Francois-Xavier Coudert  

PR libfortran/54572
* Makefile.am (libgfortran_la_LDFLAGS): Link in libbacktrace.
(AM_CPPFLAGS): Add libbacktrace directories to include paths.
* Makefile.in: Regenerate.
* aclocal.m4: Regenerate.
* config.h.in: Regenerate.
* configure: Regenerate.
* configure.ac: Remove checks for strtok_r, wait, execve, pipe,
and dup2. Remove call to GCC_CHECK_UNWIND_GETIPINFO.
* libgfortran.h (full_exe_path, find_addr2line, backtrace): Remove
prototypes.
(show_backtrace): Add prototype.
* runtime/backtrace.c: Rework file entirely.
* runtime/compile_options.c (backtrace_handler): Rename backtrace
to show_backtrace.
(maybe_find_addr2line): Remove function.
(set_options): Remove call to maybe_find_addr2line.
* runtime/error.c (sys_abort): Rename backtrace to show_backtrace.
* runtime/main.c (store_exe_path): Empty function body.
(full_exe_path, gfstrtok_r, find_addr2line): Remove functions.
(cleanup): Don't free removed variables.
* runtime/minimal.c (full_exe_path): Remove function.
(set_args): Don't set exe_path.


2015-08-14  Francois-Xavier Coudert  

PR libfortran/54572
* gfortran.dg/backtrace_1.f90: New test.



backtrace.diff
Description: Binary data


backtrace_withregeneratedfiles.diff
Description: Binary data

RE: [PATCH] [graphite] Constrain only on INTEGER_TYPE

[Aditya K]

> Date: Fri, 14 Aug 2015 11:47:05 +0200
> Subject: Re: [PATCH] [graphite] Constrain only on INTEGER_TYPE
> From: richard.guent...@gmail.com
> To: hiradi...@msn.com
> CC: tob...@grosser.es; gcc-patches@gcc.gnu.org; s@samsung.com; 
> seb...@gmail.com
>
> On Fri, Aug 14, 2015 at 11:25 AM, Aditya K  wrote:
>>
>>
>> 
>>> Date: Fri, 14 Aug 2015 09:31:32 +0200
>>> Subject: Re: [PATCH] [graphite] Constrain only on INTEGER_TYPE
>>> From: richard.guent...@gmail.com
>>> To: hiradi...@msn.com
>>> CC: tob...@grosser.es; gcc-patches@gcc.gnu.org; s@samsung.com; 
>>> seb...@gmail.com
>>>
>>> On Thu, Aug 13, 2015 at 7:56 PM, Aditya K  wrote:


> Date: Thu, 13 Aug 2015 12:02:43 +0200
> Subject: Re: [PATCH] [graphite] Constrain only on INTEGER_TYPE
> From: richard.guent...@gmail.com
> To: tob...@grosser.es
> CC: hiradi...@msn.com; gcc-patches@gcc.gnu.org; s@samsung.com;
> seb...@gmail.com
>
> On Wed, Aug 12, 2015 at 10:41 PM, Tobias Grosser 
> wrote:
>> On 08/12/2015 10:33 PM, Aditya Kumar wrote:
>>>
>>> Passes bootstrap, no regressions.
>>>
>>> With this patch gcc bootstraps with graphite.
>>> make BOOT_CFLAGS="-g -O2 -fgraphite-identity -floop-interchange
>>> -floop-block"
>>
>>
>> LGTM, but please use a longer sentence to explain what you do.
>
> As the middle-end generally freely exchanges INTEGER_TYPE
> ENUMERAL_TYPE and BOOLEAN_TYPE
> you want to use INTEGRAL_TYPE_P here.
>

 Thanks.
 I tried INTEGRAL_TYPE_P, and that fails bootstrap. After a little bit of
 debugging I figured out that it is
 ENUMERAL_TYPE that causes the failure (miscompile) in 
 tree-vect-data-refs.c.
 I can add INTEGER_TYPE and BOOLEAN_TYPE (bootstrap passes with these). But
 that would be inconsistent with the type-checks at other places in
 graphite-*.c.
 Currently, we are only checking for INTEGER_TYPE at other places.
>>>
>>> This is weird - the code you replace did allow both ENUMERAL_TYPE and
>>> BOOLEAN_TYPE.
>>>
>>> my suggestion was
>>>
>>> /* We can not handle REAL_TYPE. Failed for pr39260. */
>>> - || TREE_CODE (TREE_TYPE (op)) == REAL_TYPE)
>>> + || ! INTEGRAL_TYPE_P (TREE_TYPE (op))
>>>
>>> you also need to adjust the comment btw.
>>
>> This is exactly what I did and that resulted in miscompile. Then out of 
>> curiosity I tried to debug by putting
>> /* We can not handle REAL_TYPE. Failed for pr39260. */
>> - || TREE_CODE (TREE_TYPE (op)) == REAL_TYPE)
>> + || TREE_CODE (TREE_TYPE (op)) != INTEGER_TYPE)
>> + || TREE_CODE (TREE_TYPE (op)) != BOOLEAN_TYPE))
>>
>
> well, each op is either != INTEGER or != BOOLEAN ... this is equal to
> doing || true


My bad, thanks for correction.
I tried this way (using BOOLEAN_TYPE) and this also failed bootstrap.

@@ -410,7 +410,8 @@ stmt_simple_for_scop_p (basic_block scop_entry, loop_p 
outermost_loop,
            tree op = gimple_op (stmt, i);
            if (!graphite_can_represent_expr (scop_entry, loop, op)
                /* We can not handle REAL_TYPE. Failed for pr39260.  */
-               || TREE_CODE (TREE_TYPE (op)) == REAL_TYPE)
+               || ((TREE_CODE (TREE_TYPE (op)) != INTEGER_TYPE)
+               && (TREE_CODE (TREE_TYPE (op)) != BOOLEAN_TYPE)))
              {
                if (dump_file && (dump_flags & TDF_DETAILS))


While, using ENUMERAL_TYPE passed bootstrap.
@@ -410,7 +410,8 @@ stmt_simple_for_scop_p (basic_block scop_entry, loop_p 
outermost_loop,
            tree op = gimple_op (stmt, i);
            if (!graphite_can_represent_expr (scop_entry, loop, op)
                /* We can not handle REAL_TYPE. Failed for pr39260.  */
-               || TREE_CODE (TREE_TYPE (op)) == REAL_TYPE)
+               || ((TREE_CODE (TREE_TYPE (op)) != INTEGER_TYPE)
+               && (TREE_CODE (TREE_TYPE (op)) != ENUMERAL_TYPE)))
              {
                if (dump_file && (dump_flags & TDF_DETAILS))

Where,
BOOT_CFLAGS="-g -O2 -fgraphite-identity  -floop-block -floop-interchange"

-Aditya










>
>> And that passed bootstrap.
>>
>> Update patch:
>>
>> Passes bootstrap, no regressions.
>>
>> With this patch gcc bootstraps with graphite.
>> make BOOT_CFLAGS="-g -O2 -fgraphite-identity -floop-interchange -floop-block"
>>
>> gcc/ChangeLog:
>>
>> 2015-08-12 Aditya Kumar 
>>
>> * graphite-scop-detection.c (stmt_simple_for_scop_p):
>> Constrain only on INTEGER_TYPE
>> ---
>> gcc/graphite-scop-detection.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/gcc/graphite-scop-detection.c b/gcc/graphite-scop-detection.c
>> index fb7247e..0f02a71 100644
>> --- a/gcc/graphite-scop-detection.c
>> +++ b/gcc/graphite-scop-detection.c
>> @@ -409,8 +409,8 @@ stmt_simple_for_scop_p (basic_block scop_entry, loop_p 
>> outermost_loop,
>> {
>> tree op = gimple_op (stmt, i);
>> if (!graphite_can_represent_expr (scop_entry, loop, op)

RE: [PATCH] [graphite] Constrain only on INTEGER_TYPE

[Richard Biener]

On August 14, 2015 4:31:23 PM GMT+02:00, Aditya K  wrote:
>
>
>
>> Date: Fri, 14 Aug 2015 11:47:05 +0200
>> Subject: Re: [PATCH] [graphite] Constrain only on INTEGER_TYPE
>> From: richard.guent...@gmail.com
>> To: hiradi...@msn.com
>> CC: tob...@grosser.es; gcc-patches@gcc.gnu.org; s@samsung.com;
>seb...@gmail.com
>>
>> On Fri, Aug 14, 2015 at 11:25 AM, Aditya K  wrote:
>>>
>>>
>>> 
 Date: Fri, 14 Aug 2015 09:31:32 +0200
 Subject: Re: [PATCH] [graphite] Constrain only on INTEGER_TYPE
 From: richard.guent...@gmail.com
 To: hiradi...@msn.com
 CC: tob...@grosser.es; gcc-patches@gcc.gnu.org; s@samsung.com;
>seb...@gmail.com

 On Thu, Aug 13, 2015 at 7:56 PM, Aditya K 
>wrote:
>
>
>> Date: Thu, 13 Aug 2015 12:02:43 +0200
>> Subject: Re: [PATCH] [graphite] Constrain only on INTEGER_TYPE
>> From: richard.guent...@gmail.com
>> To: tob...@grosser.es
>> CC: hiradi...@msn.com; gcc-patches@gcc.gnu.org;
>s@samsung.com;
>> seb...@gmail.com
>>
>> On Wed, Aug 12, 2015 at 10:41 PM, Tobias Grosser
>
>> wrote:
>>> On 08/12/2015 10:33 PM, Aditya Kumar wrote:

 Passes bootstrap, no regressions.

 With this patch gcc bootstraps with graphite.
 make BOOT_CFLAGS="-g -O2 -fgraphite-identity -floop-interchange
 -floop-block"
>>>
>>>
>>> LGTM, but please use a longer sentence to explain what you do.
>>
>> As the middle-end generally freely exchanges INTEGER_TYPE
>> ENUMERAL_TYPE and BOOLEAN_TYPE
>> you want to use INTEGRAL_TYPE_P here.
>>
>
> Thanks.
> I tried INTEGRAL_TYPE_P, and that fails bootstrap. After a little
>bit of
> debugging I figured out that it is
> ENUMERAL_TYPE that causes the failure (miscompile) in
>tree-vect-data-refs.c.
> I can add INTEGER_TYPE and BOOLEAN_TYPE (bootstrap passes with
>these). But
> that would be inconsistent with the type-checks at other places in
> graphite-*.c.
> Currently, we are only checking for INTEGER_TYPE at other places.

 This is weird - the code you replace did allow both ENUMERAL_TYPE
>and
 BOOLEAN_TYPE.

 my suggestion was

 /* We can not handle REAL_TYPE. Failed for pr39260. */
 - || TREE_CODE (TREE_TYPE (op)) == REAL_TYPE)
 + || ! INTEGRAL_TYPE_P (TREE_TYPE (op))

 you also need to adjust the comment btw.
>>>
>>> This is exactly what I did and that resulted in miscompile. Then out
>of curiosity I tried to debug by putting
>>> /* We can not handle REAL_TYPE. Failed for pr39260. */
>>> - || TREE_CODE (TREE_TYPE (op)) == REAL_TYPE)
>>> + || TREE_CODE (TREE_TYPE (op)) != INTEGER_TYPE)
>>> + || TREE_CODE (TREE_TYPE (op)) != BOOLEAN_TYPE))
>>>
>>
>> well, each op is either != INTEGER or != BOOLEAN ... this is equal to
>> doing || true
>
>
>My bad, thanks for correction.
>I tried this way (using BOOLEAN_TYPE) and this also failed bootstrap.

As previously said the REAL_TYPE condition also allowed BOOLEAN_TYPE and thus 
also should have failed to bootstrap then(?)

Richard.

>@@ -410,7 +410,8 @@ stmt_simple_for_scop_p (basic_block scop_entry,
>loop_p outermost_loop,
>            tree op = gimple_op (stmt, i);
>            if (!graphite_can_represent_expr (scop_entry, loop, op)
>                /* We can not handle REAL_TYPE. Failed for pr39260.  */
>-               || TREE_CODE (TREE_TYPE (op)) == REAL_TYPE)
>+               || ((TREE_CODE (TREE_TYPE (op)) != INTEGER_TYPE)
>+               && (TREE_CODE (TREE_TYPE (op)) != BOOLEAN_TYPE)))
>              {
>                if (dump_file && (dump_flags & TDF_DETAILS))
>
>
>While, using ENUMERAL_TYPE passed bootstrap.
>@@ -410,7 +410,8 @@ stmt_simple_for_scop_p (basic_block scop_entry,
>loop_p outermost_loop,
>            tree op = gimple_op (stmt, i);
>            if (!graphite_can_represent_expr (scop_entry, loop, op)
>                /* We can not handle REAL_TYPE. Failed for pr39260.  */
>-               || TREE_CODE (TREE_TYPE (op)) == REAL_TYPE)
>+               || ((TREE_CODE (TREE_TYPE (op)) != INTEGER_TYPE)
>+               && (TREE_CODE (TREE_TYPE (op)) != ENUMERAL_TYPE)))
>              {
>                if (dump_file && (dump_flags & TDF_DETAILS))
>
>Where,
>BOOT_CFLAGS="-g -O2 -fgraphite-identity  -floop-block
>-floop-interchange"
>
>-Aditya
>
>
>
>
>
>
>
>
>
>
>>
>>> And that passed bootstrap.
>>>
>>> Update patch:
>>>
>>> Passes bootstrap, no regressions.
>>>
>>> With this patch gcc bootstraps with graphite.
>>> make BOOT_CFLAGS="-g -O2 -fgraphite-identity -floop-interchange
>-floop-block"
>>>
>>> gcc/ChangeLog:
>>>
>>> 2015-08-12 Aditya Kumar 
>>>
>>> * graphite-scop-detection.c (stmt_simple_for_scop_p):
>>> Constrain only on INTEGER_TYPE
>>> ---
>>> gcc/graphite-scop-detection.c | 4 ++--
>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/gcc/graphite-scop-detection.c
>b/gcc/graphit

Re: [PATCH] Fix middle-end/67133, part 1

[Jeff Law]

On 08/14/2015 07:29 AM, Marek Polacek wrote:

On Fri, Aug 14, 2015 at 03:14:10PM +0200, Richard Biener wrote:

On Fri, Aug 14, 2015 at 1:20 PM, Marek Polacek  wrote:

As outlined in the PR, this fixes one ICE.  The code in question here
tries to determine whether OP can be derived as non-NULL.  In case the
function has the nonnull attribute that applies to all the arguments,
we want to see whether OP is in this argument list.  But nonnull only
appertains to pointers.  Some ssa_names don't have a type so check for
that first instead of segv before looking at its tree code.


Huh?  All but released SSA names have a type.  So this gets invoked on dead code


I suppose so.  It gets
  def_stmt

 version 13 in-free-list>

(it didn't ICE before r209891 because the operand_equal_p check came first and
returned false so we didn't check the type).
Let's track this down -- nothing should be referencing anything in the 
SSA_NAME freelist.


Jeff

Re: New patch: [AArch64] [BE] [1/2] Make large opaque integer modes endianness-safe.

[Christophe Lyon]

On 25 January 2015 at 22:33, Christophe Lyon  wrote:
> On 17 December 2014 at 18:02, Tejas Belagod  wrote:
>> On 17/12/14 16:46, Marcus Shawcroft wrote:
>>>
>>> On 17 December 2014 at 15:15, Tejas Belagod  wrote:
>>>
> It isn;t clear to me how far through the various BE patches we need to
> get before 59810 is actually resolved?



 David's 2 patches

 https://gcc.gnu.org/ml/gcc-patches/2014-11/msg01431.html
 https://gcc.gnu.org/ml/gcc-patches/2014-10/msg01099.html

 and Alan's 2 patches:

 https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02797.html
>>>
>>>
>>> OK, thanks, my understanding is that all of the above are now blocked
>>> waiting some resolution on this patch to rtlanal.c:
>>
>>
>> I believe so.
>>
>> Thanks,
>> Tejas.
>>
>
> Hi,
> If I'm not mistaken, this has been committed as r219959, and is
> causing regressions on aarch64_be for several AdvSimd intrinsic tests:
> vldX_lane, vtrn, vuzp, vzip, as well as vldN_1 and vstN_1
>
> See:
> http://abe.tcwglab.linaro.org/logs/validations/cross-validation/gcc/trunk/219959/report-build-info.html
>
> These tests started passing at the previous commit (r219958) with the
> other half of this patch.
>
> I haven't looked at the details yet.
>

I've been looking at these failures for some time. I currently have a
patch which mostly reverts the one discussed in this thread, and makes
the AdvSIMD tests pass.

However, it creates regressions in some of the vectorizer tests. When
r219959 was committed, I observed that these tests started to pass:
gcc.dg/torture/pr52028.c
gcc.dg/torture/pr53366-1.c
gcc.dg/vect/pr37539.c
gcc.dg/vect/pr40074.c
gcc.dg/vect/pr51074.c
gcc.dg/vect/pr59354.c
gcc.dg/vect/pr64252.c
gcc.dg/vect/slp-12b.c
gcc.dg/vect/slp-19b.c
gcc.dg/vect/slp-perm-8.c
gcc.dg/vect/slp-perm-9.c
gcc.dg/vect/vect-107.c
gcc.dg/vect/vect-over-widen-1-big-array.c
gcc.dg/vect/vect-over-widen-1.c
gcc.dg/vect/vect-over-widen-2-big-array.c
gcc.dg/vect/vect-over-widen-2.c
gcc.dg/vect/vect-over-widen-3-big-array.c
gcc.dg/vect/vect-over-widen-3.c
gcc.dg/vect/vect-over-widen-4-big-array.c
gcc.dg/vect/vect-over-widen-4.c
gcc.dg/vect/vect-strided-store-a-u8-i2.c
gcc.dg/vect/vect-strided-store-u16-i4.c
gcc.dg/vect/vect-strided-store-u32-i2.c
gcc.dg/vect/vect-strided-u16-i3.c

I am looking at the pr59354.c testcase, which seems to be one the
simplest showing a regression. The vectorizer does a pretty good at
generating obfuscated code :-) and I find it quite difficult to debug,
given the lack of debug environment.

In fact, I still don't understand what r219959 actually fixed. I
believe that https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59810 is
covered by the AdvSIMD tests, which r219959 actually breaks.

In summary, I have the feeling that r219959 should be somewhat
reverted such that the AdvSIMD tests pass on aarch64_be, but that this
would expose a bug related to vectorization.

Any advice appreciated.

Thanks,

Christophe.

> Christophe.
>
>>>
 https://gcc.gnu.org/ml/gcc-patches/2014-12/msg01087.html
>>>
>>>
>>> /Marcus
>>>
>>
>>

[patch,libgfortran] Fix configure test for weakref support

[FX]

This patch fixes PR 47571 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571) 
by providing an adequate configure check (with AC_LINK_IFELSE) for weakref 
(which we use in intrinsics/system_clock.c).

Tested by building libgfortran on x86_64-pc-linux-gnu, where SUPPORTS_WEAKREF 
gets defined to 1 as it should, and x86_64-apple-darwin14, where 
SUPPORTS_WEAKREF gets defined to 0 as it should. Then regtested on both targets.

OK to commit to trunk?

FX

2015-08-14  Francois-Xavier Coudert  

PR libfortran/47571
* acinclude.m4 (LIBGFOR_GTHREAD_WEAK): Remove.
(LIBGFOR_CHECK_WEAKREF): New test.
* configure.ac: Call LIBGFOR_CHECK_WEAKREF instead of
LIBGFOR_GTHREAD_WEAK.
* config.h.in: Regenerate.
* configure: Regenerate.
* intrinsics/system_clock.c: Use SUPPORTS_WEAKREF instead of
SUPPORTS_WEAK and GTHREAD_USE_WEAK.



weakref.diff
Description: Binary data

Re: [PATCH] Improve performance for Haswell family.

[Yuri Rumyantsev]

Thanks Uros.

Will it be fine for you if I split core2.md to instruction reservation
definition for core2 (old core2.md got old cpu core2) and new
nehalem.md (my changes for core2.md but for cpu nehalem only)?

Thanks.
Yuri.

2015-08-14 13:20 GMT+03:00 Uros Bizjak :
> On Fri, Aug 14, 2015 at 11:44 AM, Yuri Rumyantsev  wrote:
>> Hi All,
>>
>> Here is patch which contains
>> (1) modifying of core2.md  to conform Haswell pipeline and adding of
>> missed instruction reservation for instructions with vector operands.
>> (2) increase reassociation width for float-point operations for
>> Haswell family and 64-bit target, this allows to get +10% speedup on
>> spec2006/410.bwaves for Skylake processor.
>>
>> Bootstrap and regression testing did not show any new failures.
>> Is it OK for trunk?
>>
>> ChangeLog:
>> 2015-08-14  Yuri Rumyantsev  
>>
>> * config/i386/core2.md: Confrom instruction reservation to Haswell
>> pipeline.
>> * config/i386/i386.c (ix86_reassociation_width): Increase reassociation
>> width for float-point operations.
>
> The i386.c change is OK.
>
> Other that this, your patch substantially changes core2.md, and I'm
> afraid this would hurt pipeline description of older processors. IMO,
> it is better to introduce new haswell.md file and put the whole
> haswell description here.
>
> Uros.

RE: [PATCH] [graphite] Constrain only on INTEGER_TYPE

[Aditya K]

> Subject: RE: [PATCH] [graphite] Constrain only on INTEGER_TYPE
> From: richard.guent...@gmail.com
> Date: Fri, 14 Aug 2015 16:47:41 +0200
> To: hiradi...@msn.com
> CC: tob...@grosser.es; gcc-patches@gcc.gnu.org; s@samsung.com; 
> seb...@gmail.com
>
> On August 14, 2015 4:31:23 PM GMT+02:00, Aditya K  wrote:
>>
>>
>>
>>> Date: Fri, 14 Aug 2015 11:47:05 +0200
>>> Subject: Re: [PATCH] [graphite] Constrain only on INTEGER_TYPE
>>> From: richard.guent...@gmail.com
>>> To: hiradi...@msn.com
>>> CC: tob...@grosser.es; gcc-patches@gcc.gnu.org; s@samsung.com;
>>seb...@gmail.com
>>>
>>> On Fri, Aug 14, 2015 at 11:25 AM, Aditya K  wrote:


 
> Date: Fri, 14 Aug 2015 09:31:32 +0200
> Subject: Re: [PATCH] [graphite] Constrain only on INTEGER_TYPE
> From: richard.guent...@gmail.com
> To: hiradi...@msn.com
> CC: tob...@grosser.es; gcc-patches@gcc.gnu.org; s@samsung.com;
>>seb...@gmail.com
>
> On Thu, Aug 13, 2015 at 7:56 PM, Aditya K 
>>wrote:
>>
>>
>>> Date: Thu, 13 Aug 2015 12:02:43 +0200
>>> Subject: Re: [PATCH] [graphite] Constrain only on INTEGER_TYPE
>>> From: richard.guent...@gmail.com
>>> To: tob...@grosser.es
>>> CC: hiradi...@msn.com; gcc-patches@gcc.gnu.org;
>>s@samsung.com;
>>> seb...@gmail.com
>>>
>>> On Wed, Aug 12, 2015 at 10:41 PM, Tobias Grosser
>>
>>> wrote:
 On 08/12/2015 10:33 PM, Aditya Kumar wrote:
>
> Passes bootstrap, no regressions.
>
> With this patch gcc bootstraps with graphite.
> make BOOT_CFLAGS="-g -O2 -fgraphite-identity -floop-interchange
> -floop-block"


 LGTM, but please use a longer sentence to explain what you do.
>>>
>>> As the middle-end generally freely exchanges INTEGER_TYPE
>>> ENUMERAL_TYPE and BOOLEAN_TYPE
>>> you want to use INTEGRAL_TYPE_P here.
>>>
>>
>> Thanks.
>> I tried INTEGRAL_TYPE_P, and that fails bootstrap. After a little
>>bit of
>> debugging I figured out that it is
>> ENUMERAL_TYPE that causes the failure (miscompile) in
>>tree-vect-data-refs.c.
>> I can add INTEGER_TYPE and BOOLEAN_TYPE (bootstrap passes with
>>these). But
>> that would be inconsistent with the type-checks at other places in
>> graphite-*.c.
>> Currently, we are only checking for INTEGER_TYPE at other places.
>
> This is weird - the code you replace did allow both ENUMERAL_TYPE
>>and
> BOOLEAN_TYPE.
>
> my suggestion was
>
> /* We can not handle REAL_TYPE. Failed for pr39260. */
> - || TREE_CODE (TREE_TYPE (op)) == REAL_TYPE)
> + || ! INTEGRAL_TYPE_P (TREE_TYPE (op))
>
> you also need to adjust the comment btw.

 This is exactly what I did and that resulted in miscompile. Then out
>>of curiosity I tried to debug by putting
 /* We can not handle REAL_TYPE. Failed for pr39260. */
 - || TREE_CODE (TREE_TYPE (op)) == REAL_TYPE)
 + || TREE_CODE (TREE_TYPE (op)) != INTEGER_TYPE)
 + || TREE_CODE (TREE_TYPE (op)) != BOOLEAN_TYPE))

>>>
>>> well, each op is either != INTEGER or != BOOLEAN ... this is equal to
>>> doing || true
>>
>>
>>My bad, thanks for correction.
>>I tried this way (using BOOLEAN_TYPE) and this also failed bootstrap.
>
> As previously said the REAL_TYPE condition also allowed BOOLEAN_TYPE and thus 
> also should have failed to bootstrap then(?)
>

Yet it did fail before. I started working on this patch because gcc was failing 
bootstrap with 
BOOT_CFLAGS="-g -O2 -fgraphite-identity -floop-block -floop-interchange"
-Aditya

> Richard.
>
>
  

Re: [Aarch64] Adjust tests to take LSE extension into account.

[Matthew Wahab]

On 14/08/15 14:36, Matthew Wahab wrote:

Tests for the code generated by the Aarch64 backends for the __sync and
__atomic builtins assume that they are implemented using sequences based
on load-exclusive and store-exclusive instructions. ARMv8.1 introduces
atomic instructions which can be used to implement __sync and __atomic
builtins. This means that the tests could fail if the default target is
set to a cpu that enables the atomic instructions.

This patch adjusts the tests to explicitly disable the LSE extension
providing the atomic instructions so that the compiler falls back to
generating the load-excluclusive/store-exclusive sequences.

Tested for aarch64-none-elf with cross-compiled check-gcc. Also tested
aarch64-none-elf with check-gcc using a custom build of the compiler
with LSE extensions (atomic CAS) enabled by default.



I've noticed another test that should be adjusted; it doesn't use CAS but would use 
other atomic instructions. I'll respin the patch to include it.


Matthew

Re: [PATCH] Fix middle-end/67133, part 1

[Marek Polacek]

On Fri, Aug 14, 2015 at 08:50:22AM -0600, Jeff Law wrote:
> On 08/14/2015 07:29 AM, Marek Polacek wrote:
> >On Fri, Aug 14, 2015 at 03:14:10PM +0200, Richard Biener wrote:
> >>On Fri, Aug 14, 2015 at 1:20 PM, Marek Polacek  wrote:
> >>>As outlined in the PR, this fixes one ICE.  The code in question here
> >>>tries to determine whether OP can be derived as non-NULL.  In case the
> >>>function has the nonnull attribute that applies to all the arguments,
> >>>we want to see whether OP is in this argument list.  But nonnull only
> >>>appertains to pointers.  Some ssa_names don't have a type so check for
> >>>that first instead of segv before looking at its tree code.
> >>
> >>Huh?  All but released SSA names have a type.  So this gets invoked on dead 
> >>code
> >
> >I suppose so.  It gets
> >  def_stmt
> >
> > version 13 in-free-list>
> >
> >(it didn't ICE before r209891 because the operand_equal_p check came first 
> >and
> >returned false so we didn't check the type).
> Let's track this down -- nothing should be referencing anything in the
> SSA_NAME freelist.

Ok, I'll investigate and come back to y'all when/if I find something.

Marek

[PATCH] Fix middle-end/67133, part 2

[Marek Polacek]

This is the second fix for this PR.  Here the problem was that we were
accessing arguments that don't exist.  We first need to check that the
call stmt has sufficient number of arguments.  For details see the PR.

Bootstrapped/regtested on x86_64-linux, ok for trunk?

2015-08-14  Marek Polacek  

PR middle-end/67133
* gimple.c (infer_nonnull_range_by_attribute): Check that the
nonnull argument position is not outside function arguments.

* gcc.dg/torture/pr67133.c: New test.

diff --git gcc/gimple.c gcc/gimple.c
index cca328a..1bfa8c7 100644
--- gcc/gimple.c
+++ gcc/gimple.c
@@ -2694,10 +2694,13 @@ infer_nonnull_range_by_attribute (gimple stmt, tree op)
  /* Now see if op appears in the nonnull list.  */
  for (tree t = TREE_VALUE (attrs); t; t = TREE_CHAIN (t))
{
- int idx = TREE_INT_CST_LOW (TREE_VALUE (t)) - 1;
- tree arg = gimple_call_arg (stmt, idx);
- if (operand_equal_p (op, arg, 0))
-   return true;
+ unsigned int idx = TREE_INT_CST_LOW (TREE_VALUE (t)) - 1;
+ if (idx < gimple_call_num_args (stmt))
+   {
+ tree arg = gimple_call_arg (stmt, idx);
+ if (operand_equal_p (op, arg, 0))
+   return true;
+   }
}
}
 }
diff --git gcc/testsuite/gcc.dg/torture/pr67133.c 
gcc/testsuite/gcc.dg/torture/pr67133.c
index e69de29..4eb552e 100644
--- gcc/testsuite/gcc.dg/torture/pr67133.c
+++ gcc/testsuite/gcc.dg/torture/pr67133.c
@@ -0,0 +1,34 @@
+/* { dg-do compile } */
+/* { dg-additional-options "-fisolate-erroneous-paths-attribute" } */
+
+int printf (const char *, ...);
+int foo (int);
+
+int a, *b, c;
+
+static int
+fn1 ()
+{ 
+  if (a)
+return (a = 0);
+  for (; a; )
+a = 0;
+  return 0;
+}
+
+static int
+fn2 (int p)
+{ 
+  fn1 ();
+  c = 0;
+  if (p)
+printf ("%d", 0);
+  foo (b != &p);
+  return 0;
+}
+
+void
+fn3 ()
+{ 
+  fn2 (0);
+}

Marek

Re: [PATCH] Fix middle-end/67133, part 1

[Jeff Law]

On 08/14/2015 09:32 AM, Marek Polacek wrote:

On Fri, Aug 14, 2015 at 08:50:22AM -0600, Jeff Law wrote:

On 08/14/2015 07:29 AM, Marek Polacek wrote:

On Fri, Aug 14, 2015 at 03:14:10PM +0200, Richard Biener wrote:

On Fri, Aug 14, 2015 at 1:20 PM, Marek Polacek  wrote:

As outlined in the PR, this fixes one ICE.  The code in question here
tries to determine whether OP can be derived as non-NULL.  In case the
function has the nonnull attribute that applies to all the arguments,
we want to see whether OP is in this argument list.  But nonnull only
appertains to pointers.  Some ssa_names don't have a type so check for
that first instead of segv before looking at its tree code.


Huh?  All but released SSA names have a type.  So this gets invoked on dead code


I suppose so.  It gets
  def_stmt

 version 13 in-free-list>

(it didn't ICE before r209891 because the operand_equal_p check came first and
returned false so we didn't check the type).

Let's track this down -- nothing should be referencing anything in the
SSA_NAME freelist.


Ok, I'll investigate and come back to y'all when/if I find something.
Thanks.  I still regret using the TREE_TYPE as a way to chain elements 
in the free list:(  I didn't want to add another pointer field...


jeff

Re: [v3 PATCH] Add C++11

[Ed Smith-Rowland]

On 08/13/2015 10:51 AM, Jonathan Wakely wrote:

On 13/08/15 10:37 -0400, Ed Smith-Rowland wrote:

Greetings,

Now that most systems have uchar.h for conversion between char16_t* 
and char32_t* to multibyte (analogue of wchar.h and cwchar) i think 
we should check off this last little crumb of C++11.


Ooh, I forgot about this, thanks!


Add C++11 header .
* acinclude.m4: Regenerate.


This file isn't auto-generated, so the changelog is wrong. Maybe
something like:

 acinclude.m4 (GLIBCXX_ENABLE_CUCHAR): Define.


Done.



Index: include/Makefile.am
===
--- include/Makefile.am(revision 226808)
+++ include/Makefile.am(working copy)
@@ -709,6 +709,7 @@
${c_base_srcdir}/cstring \
${c_base_srcdir}/ctgmath \
${c_base_srcdir}/ctime \
+${c_base_srcdir}/cuchar \
${c_base_srcdir}/cwchar \
${c_base_srcdir}/cwctype

@@ -751,10 +752,19 @@
${c_compatibility_srcdir}/string.h \
${c_compatibility_srcdir}/tgmath.h \
${c_compatibility_srcdir}/time.h \
+${c_compatibility_srcdir}/uchar.h \
${c_compatibility_srcdir}/wchar.h \
${c_compatibility_srcdir}/wctype.h
endif

+if ENABLE_CUCHAR
+cuchar_headers = \
+${c_base_srcdir}/cuchar \
+${c_compatibility_srcdir}/uchar.h
+else
+cuchar_headers =
+endif


This cuchar_headers variable doesn't seem to be used anywhere, am I
missing something?

It looks like the headers are installed unconditionally, and this
ENABLE_CUCHAR block isn't needed (and so the GLIBCXX_CONDITIONAL that
creates it in acinclude.m4 isn't needed either).


I really want to not install unconditionally.  I fixed this too.



+// Copyright (C) 2013 Free Software Foundation, Inc.


A few of the new files have 2013 as the copyright date, not 2015
(I'm always forgetting to update the dates when I return to old
patches that have been uncommitted for a while!)



LOL.  Fixed.

Rebuilt retested on x86_64-linux.  OK?

Ed


2015-08-14  Edward Smith-Rowland  <3dw...@verizon.net>

Add C++11 header .
* acinclude.m4 (GLIBCXX_ENABLE_CUCHAR): Define.
* config.h.in: Regenerate.
* configure: Regenerate.
* configure.ac: Check for .
* include/Makefile.am: Check for .
* include/Makefile.in: Regenerate.
* include/c/cuchar: New.
* include/c_compatibility/uchar.h: New.
* include/c_global/cuchar: New.
* include/c_std/cuchar: New.
* include/precompiled/stdc++.h: Include .
* testsuite/17_intro/headers/c++200x/stdc++.cc: Include .
* testsuite/17_intro/headers/c++200x/stdc++_multiple_inclusion.cc:
Include .
Index: acinclude.m4
===
--- acinclude.m4(revision 226866)
+++ acinclude.m4(working copy)
@@ -1926,6 +1926,51 @@
 ])
 
 dnl
+dnl Check for uchar.h and usability.
+dnl
+AC_DEFUN([GLIBCXX_ENABLE_CUCHAR], [
+
+  # Test uchar.h.
+  AC_MSG_CHECKING([for ISO C11 support for  for C++11 ])
+  AC_CHECK_HEADERS(uchar.h, ac_has_uchar_h=yes, ac_has_uchar_h=no)
+  AC_MSG_RESULT($ac_has_uchar_h)
+
+  AC_LANG_SAVE
+  AC_LANG_CPLUSPLUS
+
+  if test x"$ac_has_uchar_h" = x"yes"; then
+AC_TRY_COMPILE([#include 
+   #ifdef __STDC_UTF_16__
+   long i = __STDC_UTF_16__;
+   #endif
+   #ifdef __STDC_UTF_32__
+   long j = __STDC_UTF_32__;
+   #endif
+   namespace test
+   {
+ using ::c16rtomb;
+ using ::c32rtomb;
+ using ::mbrtoc16;
+ using ::mbrtoc32;
+   }
+  ],
+  [], [ac_c11_uchar_cxx11=yes], [ac_c11_uchar_cxx11=no])
+  else
+ac_c11_uchar_cxx11=no
+  fi
+  AC_MSG_RESULT($ac_c11_uchar_cxx11)
+  if test x"$ac_c11_uchar_cxx11" = x"yes"; then
+AC_DEFINE(_GLIBCXX_USE_C11_UCHAR_CXX11, 1,
+ [Define if C11 functions in  should be imported in
+  in namespace std.])
+  fi
+
+  AC_LANG_RESTORE
+  AC_MSG_RESULT($enable_libstdcxx_cuchar)
+  GLIBCXX_CONDITIONAL(ENABLE_CUCHAR, test $enable_libstdcxx_cuchar = yes)
+])
+
+dnl
 dnl Check for what type of C headers to use.
 dnl
 dnl --enable-cheaders= [does stuff].
Index: config.h.in
===
--- config.h.in (revision 226866)
+++ config.h.in (working copy)
@@ -454,6 +454,9 @@
 /* Define to 1 if the target supports thread-local storage. */
 #undef HAVE_TLS
 
+/* Define to 1 if you have the  header file. */
+#undef HAVE_UCHAR_H
+
 /* Define to 1 if you have the  header file. */
 #undef HAVE_UNISTD_H
 
@@ -780,6 +783,10 @@
 /* Define to use Sun versioning in the shared library. */
 #undef _GLIBCXX_SYMVER_SUN
 
+/* Define if C11 functions in  should be imported in  in
+   namespace std. */
+#undef _GLIBCXX_USE_C11_UCHAR_CXX11
+
 /* Define if C99 functions or mac

Re: [PATCH], PowerPC IEEE 128-bit patch #5

[Michael Meissner]

There are 3 patches left in the basic IEEE 128-bit floating point support for
the compiler. I will submit these at the same time. They are split to make the
review process similar.  Patch #5 and #6 are indpendent of each other and can
be applied in either order. Patch #7 assumes that patches 1-6 have been
applied.

Patch #5 adds the following:
 * Support for the reload handlers that will be enabled in patch #7.
 * Adds IFmode/KFmode to other iterators as appropriate.
 * Adds the basic negate, absolute value, and negative absolute value support.
 * Adds the insns for the 128-bit pack/unpack routines.

Patch #6 adds the following:
 * Adds support for comparisons.
 * Updates the cannot change mode support.

Patch #7 finishes up the initial basic support.
 * It defines macros for IEEE 128-bit floating point users.
 * It defines the basic move support.
 * It sets up the calling sequence.
 * It registers the __float128 and __ibm128 keywords.
 * It sets up the various handler functions.
 * It adds 'q' and 'Q' as the suffix for IEEE 128-bit floating point.
 * It adds target attribute/pragma support for the IEEE 128-bit options.
 * It treats IEEE 128-bit in VSX register modes as vector.
 * It uses a unique mangling for IEEE 128-bit in VSX registers.
 * It moves vector modes tieable above scalar floating point.
 * It adds a simple minded test to make sure IEEE args are passed as vectors.

Things to be done:
 * Work with GDB to add debug support.
 * Work with GLIBC to add basic software emulation support.
 * Work with GLIBC on other IEEE 128-bit support.
 * Look into Complex support.
 * Look into libquadmath support.
 * Enable -mfloat128-software if -mvsx.
 * Add more tests.
 * Fix bugs that show up if -mabi=ieeelongdouble is used.

Each patch bootstraps without error and has no regressions. Are they ok to
install in the trunk?

This is patch #5:

2015-08-13  Michael Meissner  

* config/rs6000/predicates.md (int_reg_operand_not_pseudo): New
predicate for only GPR hard registers.

* config/rs6000/rs6000.md (FP): Add IEEE 128-bit floating point
modes to iterators. Add new iterators for moving 128-bit values in
scalar FPR registers and VSX registers.
(FMOVE128): Likewise.
(FMOVE128_FPR): Likewise.
(FMOVE128_GPR): Likewise.
(FMOVE128_VSX): Likewise.
(FLOAT128_SFDFTF): New iterators for IEEE 128-bit floating point
in VSX registers.
(IFKF): Likewise.
(IBM128): Likewise.
(TFIFKF): Likewise.
(RELOAD): Add IEEE 128-bit floating point modes.
(signbittf2): Convert TF insns to add support for new IEEE 128-bit
floating point in VSX registers modes.
(signbit2, IBM128 iterator): Likewise.
(mov_64bit_dm, FMOVE128_FPR iterator): Likewise.
(mov_32bit, FMOVE128_FPR iterator): Likewise.
(negtf2): Likewise.
(neg2, TFIFKF iterator): Likewise.
(negtf2_internal): Likewise.
(abstf2): Likewise.
(abs2, TFIFKF iterator): Likewise.
(ieee_128bit_negative_zero): New IEEE 128-bit floating point in
VSX insn support for negate, absolute value, and negative absolute
value.
(ieee_128bit_vsx_neg2): Likewise.
(ieee_128bit_vsx_neg2_internal): Likewise.
(ieee_128bit_vsx_abs2): Likewise.
(ieee_128bit_vsx_abs2_internal): Likewise.
(ieee_128bit_vsx_nabs2): Likewise.
(ieee_128bit_vsx_nabs2_internal): Likewise.
(FP128_64): Update pack/unpack 128-bit insns for IEEE 128-bit
floating point in VSX registers.
(unpack_dm): Likewise.
(unpack_nodm): Likewise.
(pack): Likewise.
(unpackv1ti): Likewise.
(unpack, FMOVE128_VSX iterator): Likewise.
(packv1ti): Likewise.
(pack, FMOVE128_VSX iterator): Likewise.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797
Index: gcc/config/rs6000/predicates.md
===
--- gcc/config/rs6000/predicates.md (revision 226869)
+++ gcc/config/rs6000/predicates.md (working copy)
@@ -239,6 +239,25 @@ (define_predicate "int_reg_operand"
   return INT_REGNO_P (REGNO (op));
 })
 
+;; Like int_reg_operand, but don't return true for pseudo registers
+(define_predicate "int_reg_operand_not_pseudo"
+  (match_operand 0 "register_operand")
+{
+  if ((TARGET_E500_DOUBLE || TARGET_SPE) && invalid_e500_subreg (op, mode))
+return 0;
+
+  if (GET_CODE (op) == SUBREG)
+op = SUBREG_REG (op);
+
+  if (!REG_P (op))
+return 0;
+
+  if (REGNO (op) >= FIRST_PSEUDO_REGISTER)
+return 0;
+
+  return INT_REGNO_P (REGNO (op));
+})
+
 ;; Like int_reg_operand, but only return true for base registers
 (define_predicate "base_reg_operand"
   (match_operand 0 "int_reg_operand")
Index: gcc/config/rs6000/rs6000.md
=

[PATCH], PowerPC IEEE 128-bit patch #6

[Michael Meissner]

There are 3 patches left in the basic IEEE 128-bit floating point support for
the compiler. I will submit these at the same time. They are split to make the
review process similar.  Patch #5 and #6 are indpendent of each other and can
be applied in either order. Patch #7 assumes that patches 1-6 have been
applied.

Patch #5 adds the following:
 * Support for the reload handlers that will be enabled in patch #7.
 * Adds IFmode/KFmode to other iterators as appropriate.
 * Adds the basic negate, absolute value, and negative absolute value support.
 * Adds the insns for the 128-bit pack/unpack routines.

Patch #6 adds the following:
 * Adds support for comparisons.
 * Updates the cannot change mode support.

Patch #7 finishes up the initial basic support.
 * It defines macros for IEEE 128-bit floating point users.
 * It defines the basic move support.
 * It sets up the calling sequence.
 * It registers the __float128 and __ibm128 keywords.
 * It sets up the various handler functions.
 * It adds 'q' and 'Q' as the suffix for IEEE 128-bit floating point.
 * It adds target attribute/pragma support for the IEEE 128-bit options.
 * It treats IEEE 128-bit in VSX register modes as vector.
 * It uses a unique mangling for IEEE 128-bit in VSX registers.
 * It moves vector modes tieable above scalar floating point.
 * It adds a simple minded test to make sure IEEE args are passed as vectors.

Things to be done:
 * Work with GDB to add debug support.
 * Work with GLIBC to add basic software emulation support.
 * Work with GLIBC on other IEEE 128-bit support.
 * Look into Complex support.
 * Look into libquadmath support.
 * Enable -mfloat128-software if -mvsx.
 * Add more tests.
 * Fix bugs that show up if -mabi=ieeelongdouble is used.

Each patch bootstraps without error and has no regressions. Are they ok to
install in the trunk?

This is patch #6:

2015-08-13  Michael Meissner  

* config/rs6000/rs6000-protos.h (rs6000_expand_float128_convert):
Add declaration.

* config/rs6000/rs6000.c (rs6000_emit_le_vsx_store): Fix a
comment.
(rs6000_cannot_change_mode_class): Add support for IEEE 128-bit
floating point in VSX registers.
(rs6000_output_move_128bit): Always print out the set insn if we
can't generate an appropriate 128-bit move.
(rs6000_generate_compare): Add support for IEEE 128-bit floating
point in VSX registers comparisons.
(rs6000_expand_float128_convert): Likewise.

* config/rs6000/rs6000.md (extenddftf2): Add support for IEEE
128-bit floating point in VSX registers.
(extenddftf2_internal): Likewise.
(trunctfdf2): Likewise.
(trunctfdf2_internal2): Likewise.
(fix_trunc_helper): Likewise.
(fix_trunctfdi2"): Likewise.
(floatditf2): Likewise.
(floatunstf2): Likewise.
(extend2): Likewise.
(trunc2): Likewise.
(fix_trunc2): Likewise.
(fixuns_trunc2): Likewise.
(float2): Likewise.
(floatuns2): Likewise.


-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797
2015-08-13  Michael Meissner  

* config/rs6000/rs6000-protos.h (rs6000_expand_float128_convert):
Add declaration.

* config/rs6000/rs6000.c (rs6000_emit_le_vsx_store): Fix a
comment.
(rs6000_cannot_change_mode_class): Add support for IEEE 128-bit
floating point in VSX registers.
(rs6000_output_move_128bit): Always print out the set insn if we
can't generate an appropriate 128-bit move.
(rs6000_generate_compare): Add support for IEEE 128-bit floating
point in VSX registers comparisons.
(rs6000_expand_float128_convert): Likewise.

* config/rs6000/rs6000.md (extenddftf2): Add support for IEEE
128-bit floating point in VSX registers.
(extenddftf2_internal): Likewise.
(trunctfdf2): Likewise.
(trunctfdf2_internal2): Likewise.
(fix_trunc_helper): Likewise.
(fix_trunctfdi2"): Likewise.
(floatditf2): Likewise.
(floatunstf2): Likewise.
(extend2): Likewise.
(trunc2): Likewise.
(fix_trunc2): Likewise.
(fixuns_trunc2): Likewise.
(float2): Likewise.
(floatuns2): Likewise.

[PATCH], PowerPC IEEE 128-bit patch #7

[Michael Meissner]

There are 3 patches left in the basic IEEE 128-bit floating point support for
the compiler. I will submit these at the same time. They are split to make the
review process similar.  Patch #5 and #6 are indpendent of each other and can
be applied in either order. Patch #7 assumes that patches 1-6 have been
applied.

Patch #5 adds the following:
 * Support for the reload handlers that will be enabled in patch #7.
 * Adds IFmode/KFmode to other iterators as appropriate.
 * Adds the basic negate, absolute value, and negative absolute value support.
 * Adds the insns for the 128-bit pack/unpack routines.

Patch #6 adds the following:
 * Adds support for comparisons.
 * Updates the cannot change mode support.

Patch #7 finishes up the initial basic support.
 * It defines macros for IEEE 128-bit floating point users.
 * It defines the basic move support.
 * It sets up the calling sequence.
 * It registers the __float128 and __ibm128 keywords.
 * It sets up the various handler functions.
 * It adds 'q' and 'Q' as the suffix for IEEE 128-bit floating point.
 * It adds target attribute/pragma support for the IEEE 128-bit options.
 * It treats IEEE 128-bit in VSX register modes as vector.
 * It uses a unique mangling for IEEE 128-bit in VSX registers.
 * It moves vector modes tieable above scalar floating point.
 * It adds a simple minded test to make sure IEEE args are passed as vectors.

Things to be done:
 * Work with GDB to add debug support.
 * Work with GLIBC to add basic software emulation support.
 * Work with GLIBC on other IEEE 128-bit support.
 * Look into Complex support.
 * Look into libquadmath support.
 * Enable -mfloat128-software if -mvsx.
 * Add more tests.
 * Fix bugs that show up if -mabi=ieeelongdouble is used.

Each patch bootstraps without error and has no regressions. Are they ok to
install in the trunk?

This is patch #7:

[gcc]
2015-08-13  Michael Meissner  

* config/rs6000/rs6000-c.c (rs6000_cpu_cpp_builtins): Define user
macros for IEEE 128-bit floating point in VSX registers.

* config/rs6000/rs6000.c (TARGET_C_MODE_FOR_SUFFIX): Add 'q' or
'Q' as the suffix for IEEE 128-bit floating point in VSX
registers.
(rs6000_c_mode_for_suffix): Likewise.
(rs6000_init_hard_regno_mode_ok): Set up IEEE 128-bit floating
point in VSX register mode support.
(rs6000_gen_le_vsx_permute): Use ROTATE instead of VEC_SELECT for
IEEE 128-bit floating point in VSX registers.
(init_cumulative_args): When calling the library support
functions, suppress passing values to IEEE 128-bit floating point
in VSX registers in both the GPRs and VSX registers.
(rs6000_function_arg): Likewise.
(rs6000_arg_partial_bytes): Likewise.
(rs6000_init_builtins): Likewise.
(init_float128_ibm): Split 128-bit floating point support into two
functions, and add support for IEEE 128-bit floating point in VSX
registers.
(init_float128_ieee): Likewise.
(rs6000_init_libfuncs): Likewise.
(rs6000_mangle_type): Use U10__float128 as the mangled type for
IEEE 128-bit floating point in VSX registers.
(struct rs6000_opt_var): Fix typo.
(struct rs6000_float128_var): Add target attribute and pragma
support for the IEEE 128-bit floating point in VSX registers.
(rs6000_float128_vars): Likewise.
(rs6000_inner_target_options): Likewise.

* config/rs6000/rs6000.h (ALTIVEC_VECTOR_MODE): Treat IEEE 128-bit
floating point in vector registers as a vector type.
(MODES_TIEABLE_P): Move vector tests above floating point scalar
tests, so that IEEE 128-bit floating point in VSX registers ties
like a vector operand and not a scalar floating point operand.
(struct rs6000_args): Add libcall field to support IEEE 128-bit
floating point in VSX registers.

* doc/extend.texi (additional floating types): Document PowerPC
use of __float128 and __ibm128 types.

* doc/invoke.texi (RS/6000 and PowerPC Options): Document
-mfloat128-software and -mfloat128-none.

[gcc/testsuite]
2015-08-13  Michael Meissner  

* gcc.target/powerpc/float128-call.c: New function, test whether
IEEE 128-bit floating point in VSX registers is passed correctly.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797
Index: gcc/config/rs6000/rs6000-c.c
===
--- gcc/config/rs6000/rs6000-c.c(revision 226838)
+++ gcc/config/rs6000/rs6000-c.c(working copy)
@@ -410,6 +410,10 @@ rs6000_cpu_cpp_builtins (cpp_reader *pfi
 builtin_define ("__RSQRTE__");
   if (TARGET_FRSQRTES)
 builtin_define ("__RSQRTEF__");
+  if (TARGET_FLOAT128)
+builtin_define ("__FLOAT128__");
+  if (TARGET_FLOAT128 == FLOAT128_SW)
+ 

Re: Add checkpoint to libgomp dg-shouldfail tests

[Thomas Schwinge]

Hi!

On Fri, 14 Aug 2015 12:56:00 +0200, I wrote:
> (Can a Fortran person please comment on this: as it's nontrivial to write
> to stderr, let's just write to stdout followed by a flush, which does
> have the same ordering effect -- OK?)

OK, turns out it's actually not very difficult to write to stderr --
thanks FX and Janne for your suggestions!  Here, I went with Janne's,
which is a little simpler yet sufficient.

> On Thu, 30 Apr 2015 14:47:03 +0200, I wrote:
> > Here is a patch, prepared by Jim Norris, to fix dg-shouldfail usage in
> > OpenACC libgomp tests.  [...]
> 
> (These dg-shouldfail tests are expected to exit with a non-zero exit
> status, and we're checking for a specific messages on stdout/stderr.)
> 
> > As obvious, committed to trunk in r222620:
> > 
> > commit cf9c09c49e63176ff8a1fba429971cb13226260b
> > Author: tschwinge 
> > Date:   Thu Apr 30 12:44:39 2015 +
> > 
> > [PR testsuite/65205] Fix dg-shouldfail usage in OpenACC libgomp tests
> > 
> > PR testsuite/65205
> 
> > --- libgomp/testsuite/libgomp.oacc-c-c++-common/clauses-2.c
> > +++ libgomp/testsuite/libgomp.oacc-c-c++-common/clauses-2.c
> > @@ -64,4 +64,5 @@ main (int argc, char **argv)
> >  
> >  return 0;
> >  }
> > -/* { dg-shouldfail "libgomp: \[\h+,\d+\] is not mapped" } */
> > +/* { dg-output "Trying to map into device 
> > \\\[0x\[0-9a-f\]+..0x\[0-9a-f\]+\\\) object when 
> > \\\[0x\[0-9a-f\]+..0x\[0-9a-f\]+\\\) is already mapped" }
> > +/* { dg-shouldfail "" } */
> 
> It once occurred to me that it's also a good idea to verify that we're
> actually reaching the expected checkpoint before terminating -- OK to
> commit?

OK for trunk?

commit 97f963dc86199ef2237fffa6293d4dfdacbd1e59
Author: Thomas Schwinge 
Date:   Fri Aug 14 17:51:03 2015 +0200

Add checkpoint to libgomp dg-shouldfail tests

That is, verify that we're actually reaching the expected checkpoint before
terminating.
---
 libgomp/testsuite/libgomp.oacc-c-c++-common/abort-1.c   |5 +++--
 libgomp/testsuite/libgomp.oacc-c-c++-common/abort-3.c   |5 +++--
 libgomp/testsuite/libgomp.oacc-c-c++-common/clauses-2.c |3 +++
 .../testsuite/libgomp.oacc-c-c++-common/data-already-1.c|3 +++
 .../testsuite/libgomp.oacc-c-c++-common/data-already-2.c|8 +++-
 .../testsuite/libgomp.oacc-c-c++-common/data-already-3.c|   11 ---
 .../testsuite/libgomp.oacc-c-c++-common/data-already-4.c|7 +--
 .../testsuite/libgomp.oacc-c-c++-common/data-already-5.c|7 +--
 .../testsuite/libgomp.oacc-c-c++-common/data-already-6.c|7 +--
 .../testsuite/libgomp.oacc-c-c++-common/data-already-7.c|7 +--
 .../testsuite/libgomp.oacc-c-c++-common/data-already-8.c|8 +++-
 libgomp/testsuite/libgomp.oacc-c-c++-common/lib-1.c |3 +++
 libgomp/testsuite/libgomp.oacc-c-c++-common/lib-11.c|3 +++
 libgomp/testsuite/libgomp.oacc-c-c++-common/lib-16.c|3 +++
 libgomp/testsuite/libgomp.oacc-c-c++-common/lib-17.c|3 +++
 libgomp/testsuite/libgomp.oacc-c-c++-common/lib-18.c|5 +++--
 libgomp/testsuite/libgomp.oacc-c-c++-common/lib-2.c |3 +++
 libgomp/testsuite/libgomp.oacc-c-c++-common/lib-20.c|3 +++
 libgomp/testsuite/libgomp.oacc-c-c++-common/lib-21.c|3 +++
 libgomp/testsuite/libgomp.oacc-c-c++-common/lib-22.c|3 +++
 libgomp/testsuite/libgomp.oacc-c-c++-common/lib-23.c|3 +++
 libgomp/testsuite/libgomp.oacc-c-c++-common/lib-25.c|3 +++
 libgomp/testsuite/libgomp.oacc-c-c++-common/lib-26.c|3 +++
 libgomp/testsuite/libgomp.oacc-c-c++-common/lib-27.c|3 +++
 libgomp/testsuite/libgomp.oacc-c-c++-common/lib-28.c|3 +++
 libgomp/testsuite/libgomp.oacc-c-c++-common/lib-29.c|3 +++
 libgomp/testsuite/libgomp.oacc-c-c++-common/lib-3.c |3 +++
 libgomp/testsuite/libgomp.oacc-c-c++-common/lib-30.c|3 +++
 libgomp/testsuite/libgomp.oacc-c-c++-common/lib-34.c|3 +++
 libgomp/testsuite/libgomp.oacc-c-c++-common/lib-35.c|3 +++
 libgomp/testsuite/libgomp.oacc-c-c++-common/lib-36.c|3 +++
 libgomp/testsuite/libgomp.oacc-c-c++-common/lib-39.c|3 +++
 libgomp/testsuite/libgomp.oacc-c-c++-common/lib-4.c |3 +++
 libgomp/testsuite/libgomp.oacc-c-c++-common/lib-40.c|3 +++
 libgomp/testsuite/libgomp.oacc-c-c++-common/lib-42.c|3 +++
 libgomp/testsuite/libgomp.oacc-c-c++-common/lib-43.c|3 +++
 libgomp/testsuite/libgomp.oacc-c-c++-common/lib-44.c|3 +++
 libgomp/testsuite/libgomp.oacc-c-c++-common/lib-47.c|3 +++
 libgomp/testsuite/libgomp.oacc-c-c++-common/lib-48.c|3 +++
 libgomp/testsuite/libgomp.oacc-c-c++-common/lib-52.c|3 +++
 libgomp/testsuite/libgomp.oacc-c-c++-common/lib-53.c|3 +++
 libgomp/testsuite/libgomp.oacc-c-c++-common/lib-54.c|   

Re: [PATCH] Improve performance for Haswell family.

[Uros Bizjak]

On Fri, Aug 14, 2015 at 5:09 PM, Yuri Rumyantsev  wrote:

> Will it be fine for you if I split core2.md to instruction reservation
> definition for core2 (old core2.md got old cpu core2) and new
> nehalem.md (my changes for core2.md but for cpu nehalem only)?

I'm looking at [1], where targets from core2 up to IvyBridge look
similar (having defined latencies for 5 ports). Haswell introduces
additional ports, and looking at your patch, many reservations are
changed to accommodate these additional ports.

I think the best way is to leave "nehalem" scheduling model to older
targets, and introduce "haswell" scheduling model (a.k.a "cpu"
attribute). Then add "hw_core", "hw_load" and "hw_store" automata,
"hw_p6" and "hw_p7" cpu units, and add new reservations for haswell
scheduling model (IOW; introduce for example "hw_imov_load"
reservation instead of changing existing "c2_imov_load).

IMO, these new patterns could be grouped in a new haswell.md file.

[1] http://www.agner.org/optimize/instruction_tables.pdf

Uros.

Re: [v3 PATCH] Add C++11

[Ed Smith-Rowland]

OK.

This tested clean because it didn't install the headers.

So Jonathan.  I am going to throw in the sponge on the configury.

Could you have a look and carry this over the finish line?

Ed

Re: [PATCH], PowerPC IEEE 128-bit patch #7

[Michael Meissner]

I meant to say splitting the patches was meant to make the reviewing simpler,
not similar.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797

Re: [PATCH], PowerPC IEEE 128-bit patch #6

[Michael Meissner]

Evidently I attached the wrong file for patch #6.

2015-08-13  Michael Meissner  

* config/rs6000/rs6000-protos.h (rs6000_expand_float128_convert):
Add declaration.

* config/rs6000/rs6000.c (rs6000_emit_le_vsx_store): Fix a
comment.
(rs6000_cannot_change_mode_class): Add support for IEEE 128-bit
floating point in VSX registers.
(rs6000_output_move_128bit): Always print out the set insn if we
can't generate an appropriate 128-bit move.
(rs6000_generate_compare): Add support for IEEE 128-bit floating
point in VSX registers comparisons.
(rs6000_expand_float128_convert): Likewise.

* config/rs6000/rs6000.md (extenddftf2): Add support for IEEE
128-bit floating point in VSX registers.
(extenddftf2_internal): Likewise.
(trunctfdf2): Likewise.
(trunctfdf2_internal2): Likewise.
(fix_trunc_helper): Likewise.
(fix_trunctfdi2"): Likewise.
(floatditf2): Likewise.
(floatunstf2): Likewise.
(extend2): Likewise.
(trunc2): Likewise.
(fix_trunc2): Likewise.
(fixuns_trunc2): Likewise.
(float2): Likewise.
(floatuns2): Likewise.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797
Index: gcc/config/rs6000/rs6000-protos.h
===
--- gcc/config/rs6000/rs6000-protos.h   (revision 226838)
+++ gcc/config/rs6000/rs6000-protos.h   (working copy)
@@ -54,6 +54,7 @@ extern const char *output_vec_const_move
 extern const char *rs6000_output_move_128bit (rtx *);
 extern bool rs6000_move_128bit_ok_p (rtx []);
 extern bool rs6000_split_128bit_ok_p (rtx []);
+extern void rs6000_expand_float128_convert (rtx, rtx, bool);
 extern void rs6000_expand_vector_init (rtx, rtx);
 extern void paired_expand_vector_init (rtx, rtx);
 extern void rs6000_expand_vector_set (rtx, rtx, int);
Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c  (revision 226838)
+++ gcc/config/rs6000/rs6000.c  (working copy)
@@ -8462,7 +8462,7 @@ rs6000_emit_le_vsx_store (rtx dest, rtx 
  during expand.  */
   gcc_assert (!reload_in_progress && !lra_in_progress && !reload_completed);
 
-  /* Use V2DImode to do swaps of types with 128-bit scalare parts (TImode,
+  /* Use V2DImode to do swaps of types with 128-bit scalar parts (TImode,
  V1TImode).  */
   if (mode == TImode || mode == V1TImode)
 {
@@ -18519,6 +18519,8 @@ rs6000_cannot_change_mode_class (machine
{
  unsigned to_nregs = hard_regno_nregs[FIRST_FPR_REGNO][to];
  unsigned from_nregs = hard_regno_nregs[FIRST_FPR_REGNO][from];
+ bool to_float128_vector_p = FLOAT128_VECTOR_P (to);
+ bool from_float128_vector_p = FLOAT128_VECTOR_P (from);
 
  /* Don't allow 64-bit types to overlap with 128-bit types that take a
 single register under VSX because the scalar part of the register
@@ -18527,7 +18529,10 @@ rs6000_cannot_change_mode_class (machine
 IEEE floating point can't overlap, and neither can small
 values.  */
 
- if (TARGET_IEEEQUAD && (to == TFmode || from == TFmode))
+ if (to_float128_vector_p && from_float128_vector_p)
+   return false;
+
+ else if (to_float128_vector_p || from_float128_vector_p)
return true;
 
  /* TDmode in floating-mode registers must always go into a register
@@ -18555,6 +18560,8 @@ rs6000_cannot_change_mode_class (machine
   if (TARGET_E500_DOUBLE
   && to) == DFmode) + ((from) == DFmode)) == 1
  || (((to) == TFmode) + ((from) == TFmode)) == 1
+ || (((to) == IFmode) + ((from) == IFmode)) == 1
+ || (((to) == KFmode) + ((from) == KFmode)) == 1
  || (((to) == DDmode) + ((from) == DDmode)) == 1
  || (((to) == TDmode) + ((from) == TDmode)) == 1
  || (((to) == DImode) + ((from) == DImode)) == 1))
@@ -18751,13 +18758,7 @@ rs6000_output_move_128bit (rtx operands[
return output_vec_const_move (operands);
 }
 
-  if (TARGET_DEBUG_ADDR)
-{
-  fprintf (stderr, "\n= Bad 128 bit move:\n");
-  debug_rtx (gen_rtx_SET (dest, src));
-}
-
-  gcc_unreachable ();
+  fatal_insn ("Bad 128-bit move", gen_rtx_SET (dest, src));
 }
 
 /* Validate a 128-bit move.  */
@@ -19801,6 +19802,8 @@ rs6000_generate_compare (rtx cmp, machin
  break;
 
case TFmode:
+   case IFmode:
+   case KFmode:
  cmp = (flag_finite_math_only && !flag_trapping_math)
? gen_tsttfeq_gpr (compare_result, op0, op1)
: gen_cmptfeq_gpr (compare_result, op0, op1);
@@ -19828,6 +19831,8 @@ rs6000_generate_compare (rtx cmp, machin
  break;
 
case TFmode:
+   case IFmode:
+ 

Re: [PATCH] Fix middle-end/67133, part 2

[Richard Biener]

On August 14, 2015 5:27:15 PM GMT+02:00, Marek Polacek  
wrote:
>This is the second fix for this PR.  Here the problem was that we were
>accessing arguments that don't exist.  We first need to check that the
>call stmt has sufficient number of arguments.  For details see the PR.
>
>Bootstrapped/regtested on x86_64-linux, ok for trunk?

OK.

Thanks,
Richard.

>2015-08-14  Marek Polacek  
>
>   PR middle-end/67133
>   * gimple.c (infer_nonnull_range_by_attribute): Check that the
>   nonnull argument position is not outside function arguments.
>
>   * gcc.dg/torture/pr67133.c: New test.
>
>diff --git gcc/gimple.c gcc/gimple.c
>index cca328a..1bfa8c7 100644
>--- gcc/gimple.c
>+++ gcc/gimple.c
>@@ -2694,10 +2694,13 @@ infer_nonnull_range_by_attribute (gimple stmt,
>tree op)
> /* Now see if op appears in the nonnull list.  */
> for (tree t = TREE_VALUE (attrs); t; t = TREE_CHAIN (t))
>   {
>-int idx = TREE_INT_CST_LOW (TREE_VALUE (t)) - 1;
>-tree arg = gimple_call_arg (stmt, idx);
>-if (operand_equal_p (op, arg, 0))
>-  return true;
>+unsigned int idx = TREE_INT_CST_LOW (TREE_VALUE (t)) - 1;
>+if (idx < gimple_call_num_args (stmt))
>+  {
>+tree arg = gimple_call_arg (stmt, idx);
>+if (operand_equal_p (op, arg, 0))
>+  return true;
>+  }
>   }
>   }
> }
>diff --git gcc/testsuite/gcc.dg/torture/pr67133.c
>gcc/testsuite/gcc.dg/torture/pr67133.c
>index e69de29..4eb552e 100644
>--- gcc/testsuite/gcc.dg/torture/pr67133.c
>+++ gcc/testsuite/gcc.dg/torture/pr67133.c
>@@ -0,0 +1,34 @@
>+/* { dg-do compile } */
>+/* { dg-additional-options "-fisolate-erroneous-paths-attribute" } */
>+
>+int printf (const char *, ...);
>+int foo (int);
>+
>+int a, *b, c;
>+
>+static int
>+fn1 ()
>+{ 
>+  if (a)
>+return (a = 0);
>+  for (; a; )
>+a = 0;
>+  return 0;
>+}
>+
>+static int
>+fn2 (int p)
>+{ 
>+  fn1 ();
>+  c = 0;
>+  if (p)
>+printf ("%d", 0);
>+  foo (b != &p);
>+  return 0;
>+}
>+
>+void
>+fn3 ()
>+{ 
>+  fn2 (0);
>+}
>
>   Marek

Re: [v3 PATCH] Add C++11

[Jonathan Wakely]

On 14 August 2015 at 17:01, Ed Smith-Rowland wrote:
> OK.
>
> This tested clean because it didn't install the headers.
>
> So Jonathan.  I am going to throw in the sponge on the configury.

:-)

> Could you have a look and carry this over the finish line?

Will do, getting that stuff right is always a pain!

[gomp4] non-acc loop reductions implicit copy bugfix

[Cesar Philippidis]

This patch teaches the c and c++ front ends not to add a 'copy' clause
for each non-loop OpenACC reduction. Without this patch, this construct
would error with a duplicate mapping for 'sum':

  #pragma acc parallel num_gangs (10) copy (sum) reduction (+:sum)

While the intent behind adding a 'copy' clause for the reduction
variable was good, it is inconsistent with the behavior of the other
data clauses in the OpenACC spec. Without an explicit copy, 'sum' should
probably be transferred to the accelerator as firstprivate. Anyway, it's
probably better to correct this behavior in the gimplifier later on if
necessary.

I'll apply this patch to gomp-4_0-branch shortly.

Cesar
2015-08-14  Cesar Philippidis  

	gcc/
	* c/c-typeck.c (c_finish_omp_clauses): Permit variables to appear
	in both OpenACC data and reduction clauses.
	* cp/semantics.c (finish_omp_clauses): Likewise.

	gcc/testsuite/
	* c-c++-common/goacc/parallel-reduction.c: New test.


diff --git a/gcc/c/c-typeck.c b/gcc/c/c-typeck.c
index ed748c8..fe54799f 100644
--- a/gcc/c/c-typeck.c
+++ b/gcc/c/c-typeck.c
@@ -12059,11 +12059,10 @@ tree
 c_finish_omp_clauses (tree clauses, bool oacc)
 {
   bitmap_head generic_head, firstprivate_head, lastprivate_head;
-  bitmap_head aligned_head, oacc_data_head;
+  bitmap_head aligned_head, oacc_data_head, oacc_reduction_head;
   tree c, t, *pc;
   bool branch_seen = false;
   bool copyprivate_seen = false;
-  bool oacc_data = false;
   tree *nowait_clause = NULL;
 
   bitmap_obstack_initialize (NULL);
@@ -12072,12 +12071,15 @@ c_finish_omp_clauses (tree clauses, bool oacc)
   bitmap_initialize (&lastprivate_head, &bitmap_default_obstack);
   bitmap_initialize (&aligned_head, &bitmap_default_obstack);
   bitmap_initialize (&oacc_data_head, &bitmap_default_obstack);
+  bitmap_initialize (&oacc_reduction_head, &bitmap_default_obstack);
 
   for (pc = &clauses, c = clauses; c ; c = *pc)
 {
   bool remove = false;
   bool need_complete = false;
   bool need_implicitly_determined = false;
+  bool oacc_data = false;
+  bool reduction = false;
 
   switch (OMP_CLAUSE_CODE (c))
 	{
@@ -12095,8 +12097,8 @@ c_finish_omp_clauses (tree clauses, bool oacc)
 	goto check_dup_generic;
 
 	case OMP_CLAUSE_REDUCTION:
-	  need_implicitly_determined = true;
-	  oacc_data = false;
+	  need_implicitly_determined = !oacc;
+	  reduction = true;
 	  t = OMP_CLAUSE_DECL (c);
 	  if (OMP_CLAUSE_REDUCTION_PLACEHOLDER (c) == NULL_TREE
 	  && (FLOAT_TYPE_P (TREE_TYPE (t))
@@ -12312,12 +12314,23 @@ c_finish_omp_clauses (tree clauses, bool oacc)
 	  else
 		bitmap_set_bit (&oacc_data_head, DECL_UID (t));
 	}
+	  else if (reduction)
+	{
+	  if (oacc && bitmap_bit_p (&oacc_reduction_head, DECL_UID (t)))
+		{
+		  error_at (OMP_CLAUSE_LOCATION (c),
+			"%qE appears in multiple reduction clauses", t);
+		  remove = true;
+		}
+	  else
+		bitmap_set_bit (&oacc_reduction_head, DECL_UID (t));
+	}
 	  else
 	{
 	  if (bitmap_bit_p (&generic_head, DECL_UID (t)))
 		{
 		  error_at (OMP_CLAUSE_LOCATION (c),
-			"%qE appears more than once in data clauses", t);
+			"%qE appears more than one non-data clause", t);
 		  remove = true;
 		}
 	  else
diff --git a/gcc/cp/semantics.c b/gcc/cp/semantics.c
index 0b13ca2..cf1790c 100644
--- a/gcc/cp/semantics.c
+++ b/gcc/cp/semantics.c
@@ -5281,11 +5281,10 @@ tree
 finish_omp_clauses (tree clauses, bool oacc)
 {
   bitmap_head generic_head, firstprivate_head, lastprivate_head;
-  bitmap_head aligned_head, oacc_data_head;
+  bitmap_head aligned_head, oacc_data_head, oacc_reduction_head;
   tree c, t, *pc;
   bool branch_seen = false;
   bool copyprivate_seen = false;
-  bool oacc_data = false;
 
   bitmap_obstack_initialize (NULL);
   bitmap_initialize (&generic_head, &bitmap_default_obstack);
@@ -5293,10 +5292,13 @@ finish_omp_clauses (tree clauses, bool oacc)
   bitmap_initialize (&lastprivate_head, &bitmap_default_obstack);
   bitmap_initialize (&aligned_head, &bitmap_default_obstack);
   bitmap_initialize (&oacc_data_head, &bitmap_default_obstack);
+  bitmap_initialize (&oacc_reduction_head, &bitmap_default_obstack);
 
   for (pc = &clauses, c = clauses; c ; c = *pc)
 {
   bool remove = false;
+  bool oacc_data = false;
+  bool reduction = false;
 
   switch (OMP_CLAUSE_CODE (c))
 	{
@@ -5314,6 +5316,7 @@ finish_omp_clauses (tree clauses, bool oacc)
 	  if (oacc)
 	{
 	  oacc_data = false;
+	  reduction = true;
 	  goto check_dup_oacc;
 	}
 	  else
@@ -5426,6 +5429,17 @@ finish_omp_clauses (tree clauses, bool oacc)
 	  else
 		bitmap_set_bit (&oacc_data_head, DECL_UID (t));
 	}
+	  else if (reduction)
+	{
+	  if (oacc && bitmap_bit_p (&oacc_reduction_head, DECL_UID (t)))
+		{
+		  error_at (OMP_CLAUSE_LOCATION (c),
+			"%qE appears in multiple reduction clauses", t);
+		  remove = true;
+		}
+	  else
+		bitmap_set_bit (&oacc_reduction_head, DECL_UID (t));
+	}
 	  e

Re: Forwarding -foffload=[...] from the driver (compile-time) to libgomp (run-time) (was: [PATCH 2/n] OpenMP 4.0 offloading infrastructure: LTO streaming)

[Joseph Myers]

On Fri, 14 Aug 2015, Thomas Schwinge wrote:

> This function »generate[s] a C source file containing a constructor call
> to GOMP_set_offload_targets [...], and adds that as an infile«.  This
> "basically" works ;-) -- but really only for C source code, and for C++
> and Fortran it fails if there are command-line options used that conflict
> with the C compilation of add-omp-infile, such as (from a libgomp
> testsuite run): for C++: -std=c++11, -fno-extern-tls-init, or for
> Fortran: -fcray-pointer, -fintrinsic-modules-path.  Any suggestion about
> how to overcome that?

I suppose you need to use the option-handling information about which 
options are for which languages to filter out any options that aren't 
valid for C or Common.

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

Re: [PATCH 1/2] C++-ify dominance.c

[Jeff Law]

On 08/14/2015 01:54 AM, Richard Biener wrote:

On Fri, Aug 14, 2015 at 2:55 AM, Mikhail Maltsev  wrote:

Hi all.

These two patches are refactoring of dominator-related code.

The comment in dominance.c says: "We work in a poor-mans object oriented
fashion, and carry an instance of this structure through all our 'methods'". So,
the first patch converts the mentioned structure (dom_info) into a class with
proper encapsulation. It also adds a new member - m_fn (the function currently
being compiled) to this structure and replaces some uses of cfun with m_fn. It
also contains some fixes, related to current coding standards: move variable
declarations to place of first use, replace elaborated type specifiers (i.e.
"struct/enum foo") by simple ones (i.e., just "foo") in function prototypes.


Putting in m_fn looks backwards to me - it looks like we only need to remember
the entry and exit BBs and the number of blocks.  In fact initializing
dom_info from that would allow it to work on SESE regions as well?
Or a SEME region.   While I don't have an immediate use for dominators 
regions in the CFG, I believe they'd be useful.




+unsigned bb_dom_dfs_in (cdi_direction, basic_block);
+unsigned bb_dom_dfs_out (cdi_direction, basic_block);
+extern void verify_dominators (cdi_direction);
+basic_block recompute_dominator (cdi_direction, basic_block);
+extern void iterate_fix_dominators (cdi_direction, vec , bool);
+extern void add_to_dominance_info (cdi_direction, basic_block);

if you are here please fix the 'extern' vs. w/o 'extern' inconsistencies as well
(we prefer 'extern').
Presumably we're not at a point where we can push these down as methods 
in the class?ie, are we providing a class to query and manipulate 
the dominator tree from outside dominance.c or are we doing it just for 
internal stuff.   I believe the former is more strategic, the latter may 
have value as well, but I believe it's more limited.




In general I'm biased and refactoring for the sake of refactoring
doesn't go well with me ...
But if we're taking something that's essentially C++ implemented in C 
and turn it into real C++ with encapsulation, that's a step in the right 
direction to me.


jeff

Go patch committed: Issue error for invalid receiver types

[Ian Lance Taylor]

This patch by Chris Manghane fixes the Go frontend to issue an error
for invalid receiver types, rather than crashing.  This fixes
https://golang.org/issue/11557 .  Bootstrapped and ran Go testsuite on
x86_64-unknown-linux-gnu.  Committed to mainline.

Ian
Index: gcc/go/gofrontend/MERGE
===
--- gcc/go/gofrontend/MERGE (revision 226846)
+++ gcc/go/gofrontend/MERGE (working copy)
@@ -1,4 +1,4 @@
-fc9da313b4f5c13b4ac3b98e699fd1c89613
+448d30b696461a39870d1b8beb1195e411300bfd
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
Index: gcc/go/gofrontend/gogo.cc
===
--- gcc/go/gofrontend/gogo.cc   (revision 226846)
+++ gcc/go/gofrontend/gogo.cc   (working copy)
@@ -1927,7 +1927,11 @@ Gogo::declare_function(const std::string
  return ftype->add_method_declaration(name, NULL, type, location);
}
   else
-   go_unreachable();
+{
+  error_at(type->receiver()->location(),
+   "invalid receiver type (receiver must be a named type)");
+  return Named_object::make_erroneous_name(name);
+}
 }
 }
 

Re: [Patch/rtl-expand] Take tree range info into account to improve LSHIFT_EXP expanding

[Jiong Wang]

Jeff Law writes:

> On 04/29/2015 03:36 PM, Jiong Wang wrote:
>>
>> Jeff Law writes:
>>
>>> On 04/27/2015 02:21 PM, Jiong Wang wrote:
>>>
 Jeff,

 Sorry, I can't understand the meaning of "overlap between t_low and 
 low",
 assume "right" in "right value" means the opposite of "left" not
 "correct".

 So what you mean is t_low and low share the same pseudo regiser?
>>> My concern is sharing the same pseudo or memory location.  But thinking
>>> more about it, the shifted value has to have range information, so it
>>> must have been an SSA_NAME, right?  If so, then it can't overlap with
>>> the destination, so this is a non-issue.  Sorry for the confusion.
>>
>> Thanks for the light. By looking at related code, looks like even it's
>> SSA_NAME, it's still possible to share the same pseudo given the
>> destination is in the same SSA map parition after ssa name coleascing?
> If they're the same size and have non-overlapping lifetimes, then yes, 
> they could be the same pseudo.  That ought to be easy to check. 
> Thankfully we don't have to worry about MEMs, which is a harder check.
>
>> OK. I will rework the patch, and I found there is a function named
>> "expand_doubleword_shift" which looks like a more natural place to do
>> this optimization, although it's hard to get range info there. I will do
>> further explore on this.
> Sounds good.
>
> jeff

Jeff,

  Sorry for the slow response.

  I found we can't integrate this transformation into
  "expand_doubleword_shift" as it's at quite deep layer in the call
  stack, when we reach there, we have lost some high level info.

  So I am keeping this transformaion still in expr.c, and attachment is
  the updated version of this patch. The main changes are:

  * Figuring out whether the shift source is coming from sign extension
by checking SSA_NAME_DEF_STMT instead of deducing from tree range
info. I fell checking the gimple statement is more reliable and
straigtforward.

  * For the pseudo register overlaping issue, given:

  RTX target = TREE source << TREE amount

I was trying to make sure those two SSA_NAME won't get the same
pseudo register by comparing their assigned partition using
var_to_partition, but I can't get the associated tree representation
for "target" which is RTX.

Then I just expand "source" and compare the register number with
"target".

But I found the simplest way maybe just reorder

  low_part (target) = low_part (source) << amount
  high_part (target) = low_part (source) >> amount1

to:

  high_part (target) = low_part (source) >> amount1
  low_part (target) = low_part (source) << amount

then, even target and source share the same pseudo register, we can
still get what we want, as we are operating on their subreg.

  * Added checking on the result value of expand_variable_shift, if it's
not the same as "target" then call emit_move_insn to do that.

  How is the re-worked patch looks to you?

  x86 bootstrap OK, regression OK. aarch64 bootstrap OK.

2015-08-14  Jiong.Wang  

gcc/
  * expr.c (expand_expr_real_2): Check tree format to optimize
  LSHIFT_EXPR expand.

gcc/testsuite
  * gcc.dg/wide_shift_64_1.c: New testcase.
  * gcc.dg/wide_shift_128_1.c: Likewise.
  * gcc.target/aarch64/ashlti3_1.c: Likewise.
  * gcc.target/arm/ashldisi_1.c: Likewise.
--
Regards,
Jiong

diff --git a/gcc/expr.c b/gcc/expr.c
index 31b4573..8a25e98 100644
--- a/gcc/expr.c
+++ b/gcc/expr.c
@@ -8836,23 +8836,90 @@ expand_expr_real_2 (sepops ops, rtx target, machine_mode tmode,
 
 case LSHIFT_EXPR:
 case RSHIFT_EXPR:
-  /* If this is a fixed-point operation, then we cannot use the code
-	 below because "expand_shift" doesn't support sat/no-sat fixed-point
- shifts.   */
-  if (ALL_FIXED_POINT_MODE_P (mode))
-	goto binop;
+  {
+	/* If this is a fixed-point operation, then we cannot use the code
+	   below because "expand_shift" doesn't support sat/no-sat fixed-point
+	   shifts.  */
+	if (ALL_FIXED_POINT_MODE_P (mode))
+	  goto binop;
+
+	if (! safe_from_p (subtarget, treeop1, 1))
+	  subtarget = 0;
+	if (modifier == EXPAND_STACK_PARM)
+	  target = 0;
+	op0 = expand_expr (treeop0, subtarget,
+			   VOIDmode, EXPAND_NORMAL);
+	/* Left shfit optimization:
+
+	   If mode == GET_MODE_WIDER_MODE (word_mode), then normally there isn't
+	   native instruction to support this wide mode left shift.  Given below
+	   example:
+
+	Type A = (Type) B  << C
+
+|<   T	>|
+|   high |   low |
+
+ |<- size  ->|
+
+	   By checking tree shape, if operand B is coming from signed extension,
+	   then the left shift operand can be simplified into:
+
+	  1. high = low >> (size - C);
+	  2. low = low << C;
+	  */
+
+	temp = NULL_RTX;
+	if (code == LSHIFT_EXPR
+	&& target
+	&& REG_P (target)
+	&& ! unsignedp
+	&& mode == GET_MODE_WIDER_MODE (word_

[committed] Fix typo in tree_base comment

[Marek Polacek]

While looking into something else I noticed this.

Applying to trunk.

2015-08-14  Marek Polacek  

* tree-core.h (tree_base): Fix typo.

diff --git gcc/tree-core.h gcc/tree-core.h
index 560ce4b..64d1fe4 100644
--- gcc/tree-core.h
+++ gcc/tree-core.h
@@ -1088,7 +1088,7 @@ struct GTY(()) tree_base {
TREE_THIS_NOTRAP in
   INDIRECT_REF, MEM_REF, TARGET_MEM_REF, ARRAY_REF, ARRAY_RANGE_REF
 
-   SSA_NAME_IN_FREELIST in
+   SSA_NAME_IN_FREE_LIST in
   SSA_NAME
 
DECL_NONALIASED in

Marek

Re: [PATCH 1/2] C++-ify dominance.c

[Jeff Law]

On 08/13/2015 06:55 PM, Mikhail Maltsev wrote:

Hi all.

These two patches are refactoring of dominator-related code.

The comment in dominance.c says: "We work in a poor-mans object oriented
fashion, and carry an instance of this structure through all our 'methods'". So,
the first patch converts the mentioned structure (dom_info) into a class with
proper encapsulation. It also adds a new member - m_fn (the function currently
being compiled) to this structure and replaces some uses of cfun with m_fn. It
also contains some fixes, related to current coding standards: move variable
declarations to place of first use, replace elaborated type specifiers (i.e.
"struct/enum foo") by simple ones (i.e., just "foo") in function prototypes.

Bootstrapped and regtested on x86_64-linux. Tested build of config-list.mk.

gcc/ChangeLog:

2015-08-14  Mikhail Maltsev

 * (ENABLE_CHECKING): Define as 0 by default.
 dominance.c (new_zero_array): Define.
 (dom_info): Define as class instead of struct.
 (dom_info::dom_info, ~dom_info): Define.  Use new/delete for memory
 allocations/deallocations.  Pass function as parameter (instead of
 using cfun).
 (dom_info::get_idom): Define accessor method.
 (dom_info::calc_dfs_tree_nonrec, calc_dfs_tree, compress, eval,
 link_roots, calc_idoms): Redefine as class members.  Use m_fn instead
 of cfun.
 (init_dom_info, free_dom_info): Remove (use dom_info ctor/dtor).
 (dom_convert_dir_to_idx): Fix prototype.
 (assign_dfs_numbers): Move variable declarations to their first uses.
 (calculate_dominance_info): Remove conditional compilation, move
 variables.
 (free_dominance_info, get_immediate_dominator, set_immediate_dominator,
 get_dominated_b, get_dominated_by_region, get_dominated_to_depth,
 redirect_immediate_dominators, nearest_common_dominator_for_set,
 dominated_by_p, bb_dom_dfs_in, bb_dom_dfs_out, verify_dominators,
 determine_dominators_for_sons, iterate_fix_dominators, first_dom_son,
 next_dom_son, debug_dominance_info, debug_dominance_tree_1): Adjust to
 use class dom_info. Move variable declarations to the place of first
 use. Fix prototypes (remove struct/enum).
 * dominance.h: Fix prototypes (remove struct/enum).

-- Regards, Mikhail Maltsev

It looks like your patch is primarily concerned with converting all the 
internal stuff into a C++ style and not exposing a class to the users of 
dominance.h. Correct?


As a whole I don't see anything objectionable here, but I also don't see 
that it really takes us forward in a real significant way.  I guess 
there's some value in having dominance.c brought up to current 
standards, but my recollection was we weren't going to do through the 
entire source base and do things like move variable declarations to 
their initial use and more generally c++-ify the code base en-masse.


Similarly losing the elaborated type specifiers doesn't really gain us 
anything, except perhaps one less token when people parse the code. 
Again, not objectionable, but also not a big gain.


I could argue that those kind of changes are independent of turning 
dom_info into a real class and if they're going to go forward, they 
would have to stand alone on their merits and go in independently if 
turning dom_info into a class (which AFIACT is the meat of this patch).





refactor_dom1.patch


diff --git a/gcc/dominance.c b/gcc/dominance.c
index d8d87ca..3c4f228 100644
--- a/gcc/dominance.c
+++ b/gcc/dominance.c
@@ -44,6 +44,10 @@
  #include "timevar.h"
  #include "graphds.h"

+#ifndef ENABLE_CHECKING
+# define ENABLE_CHECKING 0
+#endif
Umm, isn't ENABLE_CHECKING defined in auto-host.h (as set up by 
configure?)  What's the reason for this change?


Is the issue that auto-host.h won't define checking at all for 
--disable-checking?


I think that the ENABLE_CHECKING conversion from #ifdef testing to 
testing for a value should probably be done separately.  It also 
probably has higher value than this refactoring.




+
+  /* The function being processed.  */
+  function *m_fn;
So presumably the idea here is to avoid explicitly hitting cfun which in 
theory we could recompute the dominance tree for another function. But 
is that really all that useful?


I'm a bit torn here.  Richi mentioned the idea of stuffing away a 
pointer to cfun looked backwards to him and he'd pretty stuffing away 
the entry, exit & # blocks and perhaps take us a step towards the 
ability to compute dominance on sub-graphs.


The problem I see with Richi's idea now that I think about it more is 
keeping that information up-to-date.  Ie, if we've stuffed away those 
pointers, what happens if (for example) a block gets deleted from the 
graph.  What if that block happens to be the exit block we've recorded?


So I guess I'm starting to lean towards saving away the cfun  like as is 
done in this patch

Re: [PATCH 2/2] Get rid of global state accesses in dominance.c

[Jeff Law]

On 08/14/2015 02:02 AM, Richard Biener wrote:

On Fri, Aug 14, 2015 at 3:04 AM, Mikhail Maltsev  wrote:

The second part removes all global state accesses (i.e. accesses to cfun and
it's members) from dominance.c. This requires to change lots of code, but I hope
that this is a step in right direction (if my understanding of ongoing
re-architecture w.r.t. to global state is correct).

For now this second part lacks a changelog entry, but it's very "mechanical". I
will, of course, write it if the patch gets approved.


So the last time I did similar refactoring I wondered if we can somehow avoid
the "noise" in non-IPA passes.  Ideas I came up with are

  a)  Inherit gimple/rtl pass classes from a class which is initialized with the
   function the pass operates on and provides methods like

 bool dom_info_available_p (..) { return dom_info_available_p (fn, ...); }

  thus wraps APIs working on a specific function.

  b)  Do sth similar but make it work with overloads and clever (no idea what!)
 C++ that disables them if this_fn cannot be looked up

 template 
 bool dom_info_available_p (..., struct function *fn = this_fn);

all of the above would of course require that passes make all their
implementation
be methods of their pass class.  So even more refactoring.

Note that we do not have any IPA pass which accesses dominators, so the
implicit 'cfun' use was ok.  The cases I refactored were those where we had
to push/pop_cfun () in IPA passes (which can be expensive) because it
used APIs with implicit cfun.

Overall I'm not sure we want all APIs using 'cfun' to be refactored.
It is after
all useless noise to callers if all callers are effectively using 'cfun'.
And since the main driver for eliminating global state is David's work 
on the JIT, perhaps see if any of this helps David in a noticeable way 
before giving it a yea/nea.


Jeff

Re: [PATCH GCC]Improve bound information in loop niter analysis

[Jeff Law]

On 08/13/2015 09:06 PM, Bin.Cheng wrote:


Thanks for the comment.
IIUC, the niter information in struct tree_niter_desc means the number
of executions of the latch of the loop, so it's 254, rather than 255.
And same the bound information.  Of course, statements in the loop
body could execute bound+1 times depending on its position in loop.
For example, struct nb_iter_bound is to describe number of iterations
of statements(exit conditions).
Ah, if we go to tree_niter_desc, niter is defined as the # executions of 
the loop latch.  That's what I was missing.  Now back to the real review 
work :-)


jeff

Re: [PATCH GCC]Improve bound information in loop niter analysis

[Jeff Law]

On 08/14/2015 02:17 AM, Richard Biener wrote:

On Tue, Jul 28, 2015 at 11:36 AM, Bin Cheng  wrote:

Hi,
Loop niter computes inaccurate bound information for different loops.  This
patch is to improve it by using loop initial condition in
determine_value_range.  Generally, loop niter is computed by subtracting
start var from end var in loop exit condition.  Moreover, loop bound is
computed using value range information of both start and end variables.
Basic idea of this patch is to check if loop initial condition implies more
range information for both start/end variables.  If yes, we refine range
information and use that to compute loop bound.
With this improvement, more accurate loop bound information is computed for
test cases added by this patch.


+  c0 = fold_convert (type, c0);
+  c1 = fold_convert (type, c1);
+
+  if (operand_equal_p (var, c0, 0))

I believe if c0 is not already of type type operand-equal_p will never succeed.
It's a bit looser than that.  Given two user defined types with the same 
signedness & precision operand_equal_p will consider the types OK.  One 
could argue that it ought to be using the useless type conversion check.


jeff

[patch] Remove useless variables, class Gt, and struct CompLast

[Kai Zhao]

Hi,

There are some useless variables, class Gt, and struct CompLast in

testsuite/25_algorithms/*

This patch is to remove those useless variables, class Gt and struct
CompLast.

The patch is attached.

commit d13ea592473ccbd29276908782877156e669b28a
Author: Kai Zhao 
Date:   Sat Aug 15 02:23:14 2015 +0800

2015-08-15  Kai Zhao  

testsuite/25_algorithms/nth_element/3.cc: Remove useless variables,
class Gt, and struct CompLast.

testsuite/25_algorithms/partial_sort/2.cc: Likewise.
testsuite/25_algorithms/partial_sort_copy/2.cc: Likewise.
testsuite/25_algorithms/sort/1.cc: Likewise.
testsuite/25_algorithms/stable_sort/2.cc: Likewise.


Thanks,

Kai
commit d13ea592473ccbd29276908782877156e669b28a
Author: Kai Zhao 
Date:   Sat Aug 15 02:23:14 2015 +0800

2015-08-15  Kai Zhao  

testsuite/25_algorithms/nth_element/3.cc: Remove useless variables,
class Gt, and struct CompLast.

testsuite/25_algorithms/partial_sort/2.cc: Likewise.
testsuite/25_algorithms/partial_sort_copy/2.cc: Likewise.
testsuite/25_algorithms/sort/1.cc: Likewise.
testsuite/25_algorithms/stable_sort/2.cc: Likewise.

diff --git a/libstdc++-v3/testsuite/25_algorithms/nth_element/3.cc 
b/libstdc++-v3/testsuite/25_algorithms/nth_element/3.cc
index 29a0450..4f9bc8a 100644
--- a/libstdc++-v3/testsuite/25_algorithms/nth_element/3.cc
+++ b/libstdc++-v3/testsuite/25_algorithms/nth_element/3.cc
@@ -26,8 +26,6 @@ const int A[] = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 
14, 15, 16, 17, 18,
 const int B[] = {10, 20, 1, 11, 2, 12, 3, 13, 4, 14, 5, 15, 6, 16, 7, 17, 8, 
18, 9, 19};
 const int C[] = {20, 19, 18, 17, 16, 15, 14, 13, 12, 11, 10, 9, 8, 7, 6, 5, 4, 
3, 2, 1};
 const int N = sizeof(A) / sizeof(int);
-const int logN = 3; // ln(N) rounded up
-const int P = 7;
 
 // comparison predicate for stable_sort: order by rightmost digit
 struct CompLast
@@ -37,28 +35,6 @@ struct CompLast
   { return x % 10 < y % 10; }
 };
 
-// This functor has the equivalent functionality of std::geater<>,
-// but there is no dependency on  and it also tracks the
-// number of invocations since creation.
-class Gt
-{
-public:
-  static int count() { return itsCount; }
-  static void reset() { itsCount = 0; }
-  
-  bool
-  operator()(const int& x, const int& y)
-  {
-++itsCount;
-return x > y; 
-  }
-
-private:
-static int itsCount;
-};
-
-int Gt::itsCount = 0;
-
 // 25.3.2 nth_element()
 void
 test05()
diff --git a/libstdc++-v3/testsuite/25_algorithms/partial_sort/2.cc 
b/libstdc++-v3/testsuite/25_algorithms/partial_sort/2.cc
index 4ec511a..f68cca5 100644
--- a/libstdc++-v3/testsuite/25_algorithms/partial_sort/2.cc
+++ b/libstdc++-v3/testsuite/25_algorithms/partial_sort/2.cc
@@ -26,39 +26,19 @@ const int A[] = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 
14, 15, 16, 17, 18,
 const int B[] = {10, 20, 1, 11, 2, 12, 3, 13, 4, 14, 5, 15, 6, 16, 7, 17, 8, 
18, 9, 19};
 const int C[] = {20, 19, 18, 17, 16, 15, 14, 13, 12, 11, 10, 9, 8, 7, 6, 5, 4, 
3, 2, 1};
 const int N = sizeof(A) / sizeof(int);
-const int logN = 3; // ln(N) rounded up
 const int P = 7;
 
-// comparison predicate for stable_sort: order by rightmost digit
-struct CompLast
-{
-  bool
-  operator()(const int x, const int y)
-  { return x % 10 < y % 10; }
-};
-
 // This functor has the equivalent functionality of std::geater<>,
 // but there is no dependency on  and it also tracks the
 // number of invocations since creation.
 class Gt
 {
 public:
-  static int count() { return itsCount; }
-  static void reset() { itsCount = 0; }
-  
   bool
   operator()(const int& x, const int& y)
-  {
-++itsCount;
-return x > y; 
-  }
-
-private:
-static int itsCount;
+  { return x > y; }
 };
 
-int Gt::itsCount = 0;
-
 // 25.3.1.3 partial_sort()
 void
 test03()
@@ -71,7 +51,6 @@ test03()
 VERIFY(std::equal(s1, s1 + P, A));
 
 Gt gt;
-gt.reset();
 std::partial_sort(s1, s1 + P, s1 + N, gt);
 VERIFY(std::equal(s1, s1 + P, C));
 }
diff --git a/libstdc++-v3/testsuite/25_algorithms/partial_sort_copy/2.cc 
b/libstdc++-v3/testsuite/25_algorithms/partial_sort_copy/2.cc
index 3659666..5943148 100644
--- a/libstdc++-v3/testsuite/25_algorithms/partial_sort_copy/2.cc
+++ b/libstdc++-v3/testsuite/25_algorithms/partial_sort_copy/2.cc
@@ -26,40 +26,19 @@ const int A[] = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 
14, 15, 16, 17, 18,
 const int B[] = {10, 20, 1, 11, 2, 12, 3, 13, 4, 14, 5, 15, 6, 16, 7, 17, 8, 
18, 9, 19};
 const int C[] = {20, 19, 18, 17, 16, 15, 14, 13, 12, 11, 10, 9, 8, 7, 6, 5, 4, 
3, 2, 1};
 const int N = sizeof(A) / sizeof(int);
-const int logN = 3; // ln(N) rounded up
 const int P = 7;
 
-// comparison predicate for stable_sort: order by rightmost digit
-struct CompLast
-{
-  bool
-  operator()(const int x, const int y)
-  { return x % 10 < y % 10; }
-};
-
 // This functor has the equivalent functionality of std::geater<>,
 // but there is no dependency on  and it also tracks the
 // number of invocations since creati

Re: [PR64164] drop copyrename, integrate into expand

[Alexandre Oliva]

On Aug 11, 2015, Patrick Marlier  wrote:

> On Mon, Aug 10, 2015 at 5:14 PM, Jeff Law  wrote:
>> On 08/10/2015 02:23 AM, James Greenhalgh wrote:

>>> For what it is worth, I bootstrapped and tested the consolidated patch
>>> on arm-none-linux-gnueabihf and aarch64-none-linux-gnu with trunk at
>>> r226516 over the weekend, and didn't see any new issues.

Thanks!

> Especially as the bug reporter, I am impressed how a slight problem
> can lead to such a patch! ;)
> Thanks a lot Alexandre!

You're welcome.  I'm glad it appears to be working to everyone's
satisfaction now.  I've just committed it as r226901, with only a
context adjustment to account for a change in use_register_for_decl in
function.c.  /me crosses fingers :-)

Here's the patch as checked in:

for  gcc/ChangeLog

PR rtl-optimization/64164
PR bootstrap/66978
PR middle-end/66983
PR rtl-optimization/67000
PR middle-end/67034
PR middle-end/67035
* Makefile.in (OBJS): Drop tree-ssa-copyrename.o.
* tree-ssa-copyrename.c: Removed.
* opts.c (default_options_table): Drop -ftree-copyrename.  Add
-ftree-coalesce-vars.
* passes.def: Drop all occurrences of pass_rename_ssa_copies.
* common.opt (ftree-copyrename): Ignore.
(ftree-coalesce-inlined-vars): Likewise.
* doc/invoke.texi: Remove the ignored options above.
* gimple-expr.h (gimple_can_coalesce_p): Move declaration
* tree-ssa-coalesce.h: ... here.
* tree-ssa-uncprop.c: Include tree-ssa-coalesce.h and other
headers required by it.
* gimple-expr.c (gimple_can_coalesce_p): Allow coalescing
across variables when flag_tree_coalesce_vars.  Check register
use and promoted modes to allow coalescing.  Do not coalesce
maybe-byref parms with SSA_NAMEs of other variables, or
anonymous SSA_NAMEs.  Moved to tree-ssa-coalesce.c.
* tree-ssa-live.c (struct tree_int_map_hasher): Move along
with its member functions to tree-ssa-coalesce.c.
(var_map_base_init): Likewise.  Renamed to
compute_samebase_partition_bases.
(partition_view_normal): Drop want_bases parameter.
(partition_view_bitmap): Likewise.
* tree-ssa-live.h: Adjust declarations.
* tree-ssa-coalesce.c: Include explow.h and cfgexpand.h.
(build_ssa_conflict_graph): Process PARM_ and RESULT_DECLs's
default defs at the entry point.
(dump_part_var_map): New.
(compute_optimized_partition_bases): New, called by...
(coalesce_ssa_name): ... when flag_tree_coalesce_vars, instead
of compute_samebase_partition_bases.  Adjust.
* alias.c (nonoverlapping_memrefs_p): Disregard gimple-regs.
* cfgexpand.c (leader_merge, parm_maybe_byref_p): New.
(ssa_default_def_partition): New.
(get_rtl_for_parm_ssa_default_def): New.
(align_local_variable, add_stack_var): Support anonymous SSA
names.
(defer_stack_allocation): Likewise.  Declare earlier.
(set_rtl): Merge exprs and attrs, even for MEMs and non-SSA
vars.  Update DECL_RTL for PARM_DECLs and RESULT_DECLs too.
Do no record deferred-allocation marker in
SA.partition_to_pseudo.
(expand_stack_vars): Adjust check for the marker in it.
(expand_one_stack_var_at): Handle anonymous SSA_NAMEs.  Drop
redundant MEM attr setting.
(expand_one_stack_var_1): Handle anonymous SSA_NAMEs.  Renamed
from...
(expand_one_stack_var): ... this.  New wrapper to check and
skip already expanded SSA partitions.
(record_alignment_for_reg_var): New, factored out of...
(expand_one_var): ... this.
(expand_one_ssa_partition): New.
(adjust_one_expanded_partition_var): New.
(expand_one_register_var): Check and skip already expanded SSA
partitions.
(expand_used_vars): Don't create DECLs for anonymous SSA
names.  Expand all SSA partitions, then adjust all SSA names.
(pass::execute): Replace the loops that set
SA.partition_to_pseudo from partition leaders and cleared
DECL_RTL for multi-location variables, and that which used to
rename vars and set attrs, with one that clears DECL_RTL and
checks that PARMs and RESULTs default_defs match DECL_RTL.
* cfgexpand.h (get_rtl_for_parm_ssa_default_def): Declare.
* emit-rtl.c: Include stor-layout.h.
(set_reg_attrs_for_parm): Handle NULL decl.
(set_reg_attrs_for_decl_rtl): Take mode from expression if
it's not a DECL.
* stmt.c (emit_case_decision_tree): Pass it the SSA_NAME
rather than its possibly-NULL DECL.
* explow.c (promote_ssa_mode): New.
* explow.h (promote_ssa_mode): Declare.
* expr.c (expand_expr_real_1): Handle anonymous SSA_NAMEs.
(read_complex_part): Export.
* expr.h (read_complex_part): Dec

RE: [RFA] Compact EH Patch

[Moore, Catherine]

Hi Jason,
Are you going to be able to review this patch sometime soon?
Thanks,
Catherine

> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Moore, Catherine
> Sent: Thursday, July 30, 2015 4:15 PM
> To: gcc-patches@gcc.gnu.org
> Cc: ja...@redhat.com; Matthew Fortune
> Subject: [RFA] Compact EH Patch
> 
> This patch implements a more compact format for exception handling data.
> Although I don't have recent numbers for the amount of compression
> achieved, an earlier measurement showed a 30% reduction in the size of EH
> data for libstdc++.
> 
> A design document detailing the new format is available
> (https://github.com/MentorEmbedded/cxx-
> abi/blob/master/MIPSCompactEH.pdf).
> 
> This implementation enables the new format for MIPS targets only, but the
> generic pieces to enable the new format for other architectures is in place.
> I couldn't really think of a good way to split up the patch to make the review
> easier, but I am open to suggestions.
> I've successfully bootstrapped with the patch and completed testing across
> many of the MIPS targets and multilibs.
> I also ran a test series for the x86 without regressions.
> Thanks,
> Catherine
> 
> 

Re: [PATCH] Fix middle-end/67133, part 1

[Marek Polacek]

On Fri, Aug 14, 2015 at 09:33:46AM -0600, Jeff Law wrote:
> >Ok, I'll investigate and come back to y'all when/if I find something.
> Thanks.  I still regret using the TREE_TYPE as a way to chain elements in
> the free list:(  I didn't want to add another pointer field...

It's actually plain to see what's happening.  Before isolate-paths we've got

  :
  ...
  SR.5_10 = MEM[(const struct A &)0B];
  ...
  c_13 = C::size (&p1);
  ...
  if (_14 != 0)
goto ; 
  else
goto ; 

  : 
  fn1 (&D.2434.OutBufCur, &b, c_13);

Then in isolate-paths in find_explicit_erroneous_behaviour we're walking the
stmts in bb 2 and we find a null dereference, so 
insert_trap_and_remove_trailing_statements
comes in play and turns bb 2 into: 

  :
  ...
  SR.5_10 = MEM[(const struct A &)0B];
  __builtin_trap ();

i.e. it removs the defining statement for c_13.  Then 
find_explicit_erroneous_behaviour
walks over bb 3, hits the fn1 (&D.2434.OutBufCur, &b, c_13); statement, and
ICEs on the c_13 argument: it's a released SSA name with NULL TREE_TYPE.

The question now is what to do with that.  Skip SSA_NAME_IN_FREE_LIST?  That
sounds weird.  Note that we're going to remove bb 3 and bb 4 anyway... 

Marek

Re: [PATCH 2/2] Get rid of global state accesses in dominance.c

[David Malcolm]

On Fri, 2015-08-14 at 12:25 -0600, Jeff Law wrote:
> On 08/14/2015 02:02 AM, Richard Biener wrote:
> > On Fri, Aug 14, 2015 at 3:04 AM, Mikhail Maltsev  wrote:
> >> The second part removes all global state accesses (i.e. accesses to cfun 
> >> and
> >> it's members) from dominance.c. This requires to change lots of code, but 
> >> I hope
> >> that this is a step in right direction (if my understanding of ongoing
> >> re-architecture w.r.t. to global state is correct).
> >>
> >> For now this second part lacks a changelog entry, but it's very 
> >> "mechanical". I
> >> will, of course, write it if the patch gets approved.
> >
> > So the last time I did similar refactoring I wondered if we can somehow 
> > avoid
> > the "noise" in non-IPA passes.  Ideas I came up with are
> >
> >   a)  Inherit gimple/rtl pass classes from a class which is initialized 
> > with the
> >function the pass operates on and provides methods like
> >
> >  bool dom_info_available_p (..) { return dom_info_available_p (fn, 
> > ...); }
> >
> >   thus wraps APIs working on a specific function.
> >
> >   b)  Do sth similar but make it work with overloads and clever (no idea 
> > what!)
> >  C++ that disables them if this_fn cannot be looked up
> >
> >  template 
> > 
> >  bool dom_info_available_p (..., struct function *fn = this_fn);
> >
> > all of the above would of course require that passes make all their
> > implementation
> > be methods of their pass class.  So even more refactoring.
> >
> > Note that we do not have any IPA pass which accesses dominators, so the
> > implicit 'cfun' use was ok.  The cases I refactored were those where we had
> > to push/pop_cfun () in IPA passes (which can be expensive) because it
> > used APIs with implicit cfun.
> >
> > Overall I'm not sure we want all APIs using 'cfun' to be refactored.
> > It is after
> > all useless noise to callers if all callers are effectively using 'cfun'.
> And since the main driver for eliminating global state is David's work 
> on the JIT, perhaps see if any of this helps David in a noticeable way 
> before giving it a yea/nea.

The JIT guards all access to GCC's state in a big mutex ("jit_mutex", in
gcc/jit/jit-playback.c).

For example, this includes everything to do with GC and GTY, since
there's implicitly a single set of GC roots and the GC code isn't thread
safe.

So in theory this patch might reduce the amount of things that need to
be guarded by the mutex, but sadly the mountain of work there is so
large that I'm not sure how helpful it is.  (sigh)

I've been tackling things on an as-needed basis - for example, the
recent timevar global-state removal was motivated by wanting to expose a
profiling API to jit client code.

So if there are other benefits beyond merely eliminating accesses to
globals, then maybe it's good.  Does the code become simpler, more easy
to understand?  Does it eliminate the need to change "cfun" (IIRC that
can be expensive).

For example, the jit has some rather ugly code to purge global state
after each in-process invocation.  If that can be simplified or made
less ugly, that's good.

Hope this is constructive.
Dave

Re: [Patch/rtl-expand] Take tree range info into account to improve LSHIFT_EXP expanding

[Jeff Law]

On 08/14/2015 11:40 AM, Jiong Wang wrote:


   * Figuring out whether the shift source is coming from sign extension
 by checking SSA_NAME_DEF_STMT instead of deducing from tree range
 info. I fell checking the gimple statement is more reliable and
 straigtforward.
I suspect it'll also apply more often if you're looking for the 
nop-conversion rather than looking at range information.


I keep thinking there ought to be a generalization here so that we're 
not so restrictive on the modes, but it's probably not worth doing.


In a perfect world we'd also integrate the other strategies for 
double-word shifts that exist in the various ports as special cases in 
expansion and remove the double-word shift patterns for ports that don't 
actually have them in hardware.  But that's probably a bit much to ask 
-- however, it probably couldn't hurt to see if there are any that are 
easily handled.





   * For the pseudo register overlaping issue, given:

   RTX target = TREE source << TREE amount

 I was trying to make sure those two SSA_NAME won't get the same
 pseudo register by comparing their assigned partition using
 var_to_partition, but I can't get the associated tree representation
 for "target" which is RTX.

 Then I just expand "source" and compare the register number with
 "target".
Right.  Which is what I would have suggested.  Given two pseudos, you 
can just compare them for equality.  If they're unequal, then its safe 
to assume they do not overlap.




 But I found the simplest way maybe just reorder

   low_part (target) = low_part (source) << amount
   high_part (target) = low_part (source) >> amount1

 to:

   high_part (target) = low_part (source) >> amount1
   low_part (target) = low_part (source) << amount

 then, even target and source share the same pseudo register, we can
 still get what we want, as we are operating on their subreg.

Yes.  This would work too and avoids the need to find source's pseudo.



   * Added checking on the result value of expand_variable_shift, if it's
 not the same as "target" then call emit_move_insn to do that.

Excellent.



   How is the re-worked patch looks to you?

   x86 bootstrap OK, regression OK. aarch64 bootstrap OK.

2015-08-14  Jiong.Wang

gcc/
   * expr.c (expand_expr_real_2): Check tree format to optimize
   LSHIFT_EXPR expand.

gcc/testsuite
   * gcc.dg/wide_shift_64_1.c: New testcase.
   * gcc.dg/wide_shift_128_1.c: Likewise.
   * gcc.target/aarch64/ashlti3_1.c: Likewise.
   * gcc.target/arm/ashldisi_1.c: Likewise.





+   /* Left shfit optimization:

s/shfit/shift/



+
+  If mode == GET_MODE_WIDER_MODE (word_mode), then normally there isn't
+  native instruction to support this wide mode left shift.  Given below
+  example:
+
+   Type A = (Type) B  << C
+
+|<   T  >|
+|   high |   low |
+
+ |<- size  ->|
+
+  By checking tree shape, if operand B is coming from signed extension,
+  then the left shift operand can be simplified into:
+
+ 1. high = low >> (size - C);
+ 2. low = low << C;

You'll want to reorder those to match the code you generate.

Doesn't this require that C be less than the bitsize of a word?

If C is larger than the bitsize of a word, then you need some 
adjustments, something like:



  1. high = low << (C - size)
  2. low = 0

Does this transformation require that the wider mode be exactly 2X the 
narrower mode?  If so, that needs to be verified.



+   if (GET_MODE_SIZE (rmode) < GET_MODE_SIZE (mode)

So we're assured we have a widening conversion.


+   && ((TREE_INT_CST_LOW (treeop1) + GET_MODE_BITSIZE (rmode))
+   >= GET_MODE_BITSIZE (word_mode)))
This test seems wrong.  I'm not sure what you're really trying to test 
here.  It seems you want to look at the shift count relative to the 
bitsize of word_mode.  If it's less, then generate the code you 
mentioned above in the comment.  If it's more, then generate the 
sequence I referenced?  Right?


I do think you need to be verifying that rmode == wordmode here.  If I 
understand everything correctly, the final value is "mode" which must be 
2X the size size of rmode/wordmode here, right?




The other question is are we endianness-safe in these transformations?





+ {
+   rtx low = simplify_gen_subreg (word_mode, op0, mode, 0);
+   rtx tlow = simplify_gen_subreg (word_mode, target, mode, 0);
+   rtx thigh = simplify_gen_subreg (word_mode, target, mode,
+UNITS_PER_WORD);
+   HOST_WIDE_INT ramount = (BITS_PER_WORD
+- TREE_INT_CST_LOW (treeop1));
+   tree rshift = build_int_cst (TREE_TYPE (tre

RE: [PATCH, MIPS] Compact branch support for MIPS32R6/MIPS64R6

[Moore, Catherine]

Hi Matthew,

> -Original Message-
> From: Matthew Fortune [mailto:matthew.fort...@imgtec.com]
> Sent: Wednesday, July 22, 2015 6:19 PM
> Subject: [PATCH, MIPS] Compact branch support for MIPS32R6/MIPS64R6
> 
This patch looks really good.  I have a couple of questions and a couple of 
nits that need to be fixed up.

> A full range of 'compact' branch instructions were introduced to MIPS
> as part of Release 6. The compact term is used to identify the fact
> that these do not have a delay slot.
> 
> So how does all this work in GCC?
> 
> Compact branches are used based on a branch policy. The polices are:
> 
> never: Only use delay slot branches
> optimal: Do whatever is best for the current architecture.  This will
>  generally mean that delay slot branches will be used if the delay
>  slot gets filled but otherwise a compact branch will be used. A
>  special case here is that JAL and J will not be used in R6 code
>  regardless of whether the delay slot could be filled.
> always: Never emit a delay slot form of a branch if a compact form exists.
> This policy cannot apply 100% as FP branches (and MSA branches when
> committed) only have delay slot forms.
> 
> These user choices are combined with the features available in the chosen
> architecture and, in particular, the optimal form will get handled like
> 'never' when there are no compact branches available and will get handled
> like 'always' when there are no delay slot branches available.
> 

Why did you choose to make this a user-selectable option?  Why not always 
generated optimal?
I don't have a strong opinion about it, but the options seem to complicate 
things and I'm interested in your rationale.

> 
> The most complicated aspect of this change is to the MIPS_CALL and
> MICROMIPS_J macros. These have been rewritten from scratch as a function
> that generates an instruction instead.  

Thank you for cleaning this up.  The new function is much easier to follow.
 
> diff --git a/gcc/config/mips/mips.c b/gcc/config/mips/mips.c
> index c3cd52d..c0f2884 100644
> --- a/gcc/config/mips/mips.c
> +++ b/gcc/config/mips/mips.c
> 
> +/* Return the asm template for a call.  OPERANDS are the operands,
> TARGET_OPNO
> +   is the operand number of the target.  SIZE_OPNO is the operand number
> of
> +   the argument size operand that can optionally hold the call attributes.  
> If
> +   SIZE_OPNO is not -1 and the call is indirect, use the function symbol from
> +   the call attributes to attach a R_MIPS_JALR relocation to the call.
> +

Might as well mention LINK_P here as well.

> +   When generating GOT code without explicit relocation operators, all calls
> +   should use assembly macros.  Otherwise, all indirect calls should use "jr"
> +   or "jalr"; we will arrange to restore $gp afterwards if necessary.  
> Finally,
> +   we can only generate direct calls for -mabicalls by temporarily switching
> +   to non-PIC mode.
> +
> +   For microMIPS jal(r), we try to generate jal(r)s when a 16-bit
> +   instruction is in the delay slot of jal(r).
> +
> +   Where compact branches are available, we try to use them if the delay
> slot
> +   has a NOP (or equivalently delay slots were not enabled for the 
> instruction
> +   anyway).  */
> +
> +const char *
> +mips_output_jump (rtx *operands, int target_opno, int size_opno, bool
> link_p)
> +{
> @@ -13038,6 +13165,59 @@ mips_output_conditional_branch (rtx_insn
> *insn, rtx *operands,
>return "";
>  }
> 
> +const char *
> +mips_output_equal_conditional_branch (rtx_insn* insn, rtx *operands,
> +   bool inverted_p)

This function needs a comment.

diff --git a/gcc/config/mips/mips.opt b/gcc/config/mips/mips.opt
index 348c6e0..84887d1 100644
--- a/gcc/config/mips/mips.opt
+++ b/gcc/config/mips/mips.opt
@@ -418,3 +418,20 @@ Driver
 mload-store-pairs
 Target Report Var(TARGET_LOAD_STORE_PAIRS) Init(1)
 Enable load/store bonding.
+
+mcompact-branches=
+Target RejectNegative JoinedOrMissing Var(mips_cb) Report 
Enum(mips_cb_setting) Init(MIPS_CB_OPTIMAL)
+Specify the compact branch usage policy
+
+Enum
+Name(mips_cb_setting) Type(enum mips_cb_setting)
+Policies available for use with -mcompact-branches=:
+
+EnumValue
+Enum(mips_cb_setting) String(never) Value(MIPS_CB_NEVER)
+
+EnumValue
+Enum(mips_cb_setting) String(optimal) Value(MIPS_CB_OPTIMAL)
+
+EnumValue
+Enum(mips_cb_setting) String(always) Value(MIPS_CB_ALWAYS)

These need to be documented in invoke.texi.

diff --git a/gcc/config/mips/mips.h b/gcc/config/mips/mips.h
index 5bc562e..04fe6d0 100644
--- a/gcc/config/mips/mips.h
+++ b/gcc/config/mips/mips.h
> @@ -92,6 +92,23 @@ struct mips_cpu_info {
>  /* True if we are generating position-independent VxWorks RTP code.  */
>  #define TARGET_RTP_PIC (TARGET_VXWORKS_RTP && flag_pic)
> 
> +/* Set based on a combination of compact branch policy and ISA support.
> */
> +#define TARGET_CB_NEVER (mips_cb == MIPS_CB_NEVER\
> +   

Re: [PATCH] Fix middle-end/67133, part 1

[Jeff Law]

On 08/14/2015 01:58 PM, Marek Polacek wrote:

On Fri, Aug 14, 2015 at 09:33:46AM -0600, Jeff Law wrote:

Ok, I'll investigate and come back to y'all when/if I find something.

Thanks.  I still regret using the TREE_TYPE as a way to chain elements in
the free list:(  I didn't want to add another pointer field...


It's actually plain to see what's happening.  Before isolate-paths we've got

   :
   ...
   SR.5_10 = MEM[(const struct A &)0B];
   ...
   c_13 = C::size (&p1);
   ...
   if (_14 != 0)
 goto ;
   else
 goto ;

   :
   fn1 (&D.2434.OutBufCur, &b, c_13);

Then in isolate-paths in find_explicit_erroneous_behaviour we're walking the
stmts in bb 2 and we find a null dereference, so 
insert_trap_and_remove_trailing_statements
comes in play and turns bb 2 into:

   :
   ...
   SR.5_10 = MEM[(const struct A &)0B];
   __builtin_trap ();

i.e. it removs the defining statement for c_13.  Then 
find_explicit_erroneous_behaviour
walks over bb 3, hits the fn1 (&D.2434.OutBufCur, &b, c_13); statement, and
ICEs on the c_13 argument: it's a released SSA name with NULL TREE_TYPE.

The question now is what to do with that.  Skip SSA_NAME_IN_FREE_LIST?  That
sounds weird.  Note that we're going to remove bb 3 and bb 4 anyway...
Jeez, looking at the code N years later, I feel like a complete idiot. 
Of course that's not going to work.


We certainly don't want to peek at SSA_NAME_IN_FREE_LIST.

I wonder if we should be walking in backwards dominator order to avoid 
these effects.  Or maybe just ignoring any BB with no preds.  I'll 
ponder those over the weekend.


Jeff

RE: [PATCH][MIPS] Fix register renaming in the interrupt handlers

[Moore, Catherine]

> -Original Message-
> From: Robert Suchanek [mailto:robert.sucha...@imgtec.com]
> Sent: Friday, August 14, 2015 8:01 AM
> To: Mike Stump; Richard Sandiford
> Cc: Moore, Catherine; Matthew Fortune; gcc-patches@gcc.gnu.org
> Subject: RE: [PATCH][MIPS] Fix register renaming in the interrupt handlers
> 
> Hi,
> 
> > > You also need to do the same thing for
> TARGET_HARD_REGNO_SCRATCH_OK,
> > > to stop peephole2 from using unsaved registers as scratch registers.
> > >
> > > I should dig out my patches to clean up this interface.  It's just
> > > too brittle to have two macros that say what registers can be used
> > > after reload.
> 
> Indeed. I naively thought that there would be a single place that needed an
> update and overlooked this hook.
> 

Sorry for missing this as well.  
> 
> gcc/
>   * config/mips/mips-protos.h (mips_hard_regno_rename_ok): New
> prototype.
>   * config/mips/mips.c (mips_hard_regno_rename_ok): New
> function.
>   (mips_hard_regno_scratch_ok): Likewise.
>   (TARGET_HARD_REGNO_SCRATCH_OK): Define macro.
>   * config/mips/mips.h (HARD_REGNO_RENAME_OK): New.
> 
> gcc/testsuite/
>   * gcc.target/mips/interrupt_handler-bug-1.c: New test.
> ---

Based on the feedback from Richard and Mike, this looks OK now.
Thanks,
Catherine

Re: [PATCH] Fix middle-end/67133, part 1

[Marek Polacek]

On Fri, Aug 14, 2015 at 02:32:20PM -0600, Jeff Law wrote:
> On 08/14/2015 01:58 PM, Marek Polacek wrote:
> >On Fri, Aug 14, 2015 at 09:33:46AM -0600, Jeff Law wrote:
> >>>Ok, I'll investigate and come back to y'all when/if I find something.
> >>Thanks.  I still regret using the TREE_TYPE as a way to chain elements in
> >>the free list:(  I didn't want to add another pointer field...
> >
> >It's actually plain to see what's happening.  Before isolate-paths we've got
> >
> >   :
> >   ...
> >   SR.5_10 = MEM[(const struct A &)0B];
> >   ...
> >   c_13 = C::size (&p1);
> >   ...
> >   if (_14 != 0)
> > goto ;
> >   else
> > goto ;
> >
> >   :
> >   fn1 (&D.2434.OutBufCur, &b, c_13);
> >
> >Then in isolate-paths in find_explicit_erroneous_behaviour we're walking the
> >stmts in bb 2 and we find a null dereference, so 
> >insert_trap_and_remove_trailing_statements
> >comes in play and turns bb 2 into:
> >
> >   :
> >   ...
> >   SR.5_10 = MEM[(const struct A &)0B];
> >   __builtin_trap ();
> >
> >i.e. it removs the defining statement for c_13.  Then 
> >find_explicit_erroneous_behaviour
> >walks over bb 3, hits the fn1 (&D.2434.OutBufCur, &b, c_13); statement, and
> >ICEs on the c_13 argument: it's a released SSA name with NULL TREE_TYPE.
> >
> >The question now is what to do with that.  Skip SSA_NAME_IN_FREE_LIST?  That
> >sounds weird.  Note that we're going to remove bb 3 and bb 4 anyway...
> Jeez, looking at the code N years later, I feel like a complete idiot. Of
> course that's not going to work.
> 
> We certainly don't want to peek at SSA_NAME_IN_FREE_LIST.

Yeh, I thought as much.
 
> I wonder if we should be walking in backwards dominator order to avoid these
> effects.  Or maybe just ignoring any BB with no preds.  I'll ponder those
> over the weekend.

I suppose both ought to work.  Or at least theoretically we could run e.g.
cleanup_cfg to prune the IR after we've inserted trap and removed trailing
stmts so that it gets rid of unreachable bbs.  Would that make sense?

Anyway, if you think of how would you like to solve this I can take a crack
at it next week.

Marek

Re: Forwarding -foffload=[...] from the driver (compile-time) to libgomp (run-time)

[Thomas Schwinge]

Hi!

On Fri, 14 Aug 2015 16:56:25 +, Joseph Myers  
wrote:
> On Fri, 14 Aug 2015, Thomas Schwinge wrote:
> 
> > This function »generate[s] a C source file containing a constructor call
> > to GOMP_set_offload_targets [...], and adds that as an infile«.  This
> > "basically" works ;-) -- but really only for C source code, and for C++
> > and Fortran it fails if there are command-line options used that conflict
> > with the C compilation of add-omp-infile, such as (from a libgomp
> > testsuite run): for C++: -std=c++11, -fno-extern-tls-init, or for
> > Fortran: -fcray-pointer, -fintrinsic-modules-path.  Any suggestion about
> > how to overcome that?

The "problem", as (I hope) I understand it, is that gcc/gcc.c:cc1_options
includes %{std*[...]} and %{f*}, which will match/accept the
C++/Fortran-specific command-line arguments (as cited above) even if
actually operating in C language mode for the add-omp-infile compilation.

> I suppose you need to use the option-handling information about which 
> options are for which languages to filter out any options that aren't 
> valid for C or Common.

OK, that sounds simple enough, conceptually.  So, you are invalidating my
worry that the driver might in fact not be able to do this kind of thing
(mixed language compilation).

I'm currently trying to understand how all that command-line option
parsing code works, and the handoff from the driver to the frontends;
processing of the specs language.

Can you suggest off-hand where you'd expect this option filtering to
happen?  Should this be during specs parsing in the driver; something
like adding a lang_mask to gcc/gcc.c:struct switchstr, and then in
gcc/gcc.c:give_switch ignore any switches that don't match the expected
CL_*?  I seem to have difficulties to properly populate/deduce that
lang_mask at the call sites of gcc/gcc.c:save_switch.  Or, did you
imagine that to be done differently?

Alternatively, what about changing gcc/opts-global.c:complain_wrong_lang
to silently ignore options that don't apply instead of emitting a »is
valid for [...] but not for [...]« diagnostic, if a (new) flag
(-f[something]?) has been set, which would be active only during the
add-omp-infile compilation?


Grüße,
 Thomas


pgp8sVpxQ9Zgf.pgp
Description: PGP signature

Re: [Patch/rtl-expand] Take tree range info into account to improve LSHIFT_EXP expanding

[Jiong Wang]

Jeff Law writes:

> On 08/14/2015 11:40 AM, Jiong Wang wrote:
>>
>>* Figuring out whether the shift source is coming from sign extension
>>  by checking SSA_NAME_DEF_STMT instead of deducing from tree range
>>  info. I fell checking the gimple statement is more reliable and
>>  straigtforward.
> I suspect it'll also apply more often if you're looking for the 
> nop-conversion rather than looking at range information.
>
> I keep thinking there ought to be a generalization here so that we're 
> not so restrictive on the modes, but it's probably not worth doing.
>
> In a perfect world we'd also integrate the other strategies for 
> double-word shifts that exist in the various ports as special cases in 
> expansion and remove the double-word shift patterns for ports that don't 
> actually have them in hardware.  But that's probably a bit much to ask 
> -- however, it probably couldn't hurt to see if there are any that are 
> easily handled.

Agree.

Doing these in early tree/rtl expand stage is more clean & safe, and
expose more details to later RTL optimization passes as I think if you
handle double-word by defining insn pattern, then you will try to split
it in RTL split pass which happens later after some important
optimizations.

>
>> +
>> +   If mode == GET_MODE_WIDER_MODE (word_mode), then normally there isn't
>> +   native instruction to support this wide mode left shift.  Given below
>> +   example:
>> +
>> +Type A = (Type) B  << C
>> +
>> +|<   T  >|
>> +|   high |   low |
>> +
>> + |<- size  ->|
>> +
>> +   By checking tree shape, if operand B is coming from signed extension,
>> +   then the left shift operand can be simplified into:
>> +
>> +  1. high = low >> (size - C);
>> +  2. low = low << C;
> You'll want to reorder those to match the code you generate.
>
> Doesn't this require that C be less than the bitsize of a word?

Yes.

Above transformation is to handle double word left shift which shift the
original source across the word boundary.

Part of the contents shifted into the high half of destination, and the
other remain in the low half.

So if C is bigger than bitsize of a word, the the whole source will be
shifted into high half, thus should generate what you have listed below
and that's what gcc is generating, looks like the existed double word
shift logic can recognize this special cases.

So, I should check the value of C,if it's bigger than bitsize of a word,
then just fall through to default expand logic.

> If C is larger than the bitsize of a word, then you need some 
> adjustments, something like:
>
>
> 1. high = low << (C - size)
>2. low = 0
>
> Does this transformation require that the wider mode be exactly 2X the 
> narrower mode?  If so, that needs to be verified.

I think so, the wider mode should be exactly 2X the word_mode, will
add the check.

>
>> +if (GET_MODE_SIZE (rmode) < GET_MODE_SIZE (mode)
> So we're assured we have a widening conversion.
>
>> +&& ((TREE_INT_CST_LOW (treeop1) + GET_MODE_BITSIZE (rmode))
>> +>= GET_MODE_BITSIZE (word_mode)))
> This test seems wrong.  I'm not sure what you're really trying to test 
> here.  It seems you want to look at the shift count relative to the 
> bitsize of word_mode.  If it's less, then generate the code you 
> mentioned above in the comment.  If it's more, then generate the 
> sequence I referenced?  Right?

As explained above, I am trying to check whether the left shift is
causing the original source across word boundary while I should make sure
TREE_INT_CST_LOW (treeop1) < GET_MODE_BITSIZE (word_mode) at the same
time, otherwise fall through to default expand logic.

>
> I do think you need to be verifying that rmode == wordmode here.  If I 
> understand everything correctly, the final value is "mode" which must be 
> 2X the size size of rmode/wordmode here, right?

I think rmode don't need to equal wordmode. For example the
transformation is OK for the following, where rmode = SImode, and final
mode = TImode.

int b;
__128_int a = (__128_int) b;

the expand_expr (treeop0... in the start of those code will generate
necessary instruction sequences to extend whatever mode b is into TImode
register (op0 in the patch);

>
>
>
> The other question is are we endianness-safe in these transformations?

I think it is. As this transformation is done with register involved
only. I think endianness issue will only happen if there is operation on
memory object.

>> +temp = expand_variable_shift (code, word_mode, low, treeop1,
>> +  tlow, unsignedp);
> Why use "code" here right than just using LSHIFT_EXPR?  As noted
> earlier,

Yes, better to use the constant LSHIFT_EXPR.

Thanks.

-- 
Regards,
Jiong

[PATCH] Remove pointless -fPIC warning on Windows platforms

[Paolo Bonzini]

There are plenty of targets that do not require -fPIC because they always
generate position independent code, but none of them feels the need to
complain with the user about an unnecessary but perfectly valid option,
on each and every .c->.o rule, and without a way to disable it.

Adding insult to injury, the warning is also wrong in 3 cases out of four.
For 32-bit, warning may make a small amount of sense because there is
simply no such thing as PIC code (Windows just uses a "preferred base
address" for DLLs); but then the text is wrong.

For 64-bit, -fpic does not warn, but "all code is position independent"
would apply just as well!

As a summary, googling for the warning text finds exactly two categories
of people: those that are annoyed by the message because they want to
use -Werror (this includes me), and those that suggest replacing -fPIC
with -fpic.  Just zap it.

Paolo

* config/i386/cygming.h (SUBTARGET_OVERRIDE_OPTIONS): Do
not warn.

diff --git a/gcc/config/i386/cygming.h b/gcc/config/i386/cygming.h
index fda59fb..71506ec 100644
--- a/gcc/config/i386/cygming.h
+++ b/gcc/config/i386/cygming.h
@@ -198,20 +198,7 @@ along with GCC; see the file COPYING3.  If not see
 #undef  SUBTARGET_OVERRIDE_OPTIONS
 #define SUBTARGET_OVERRIDE_OPTIONS \
 do {   \
-  if (TARGET_64BIT && flag_pic != 1)   \
-{  \
-  if (flag_pic > 1)
\
-warning (0,\
-"-fPIC ignored for target (all code is position independent)"\
- );\
-  flag_pic = 1;\
-}  \
-  else if (!TARGET_64BIT && flag_pic)  \
-{  \
-  warning (0, "-f%s ignored for target (all code is position 
independent)",\
-  (flag_pic > 1) ? "PIC" : "pic"); \
-  flag_pic = 0;\
-}  \
+  flag_pic = TARGET_64BIT ? 1 : 0;  \
 } while (0)
 
 /* Define this macro if references to a symbol must be treated

Re: [PATCH 2/2] replace several uses of the anon namespace with GCC_FINAL

[Trevor Saunders]

On Thu, Aug 13, 2015 at 07:56:47PM +0300, Mikhail Maltsev wrote:
> On 08/12/2015 11:36 PM, Trevor Saunders wrote:
> > In many places gcc puts classes in the anon namespace so the compiler can 
> > tell
> > they do not get inheritted from to enable better devirtualization.
> C++ does not allow class members to have static linkage, so there is no way to
> tell the compiler that a member function will not be called from another
> translation unit except for placing it into an anonymous namespace. AFAIK this
> affects inliner decisions rather significantly (i.e. devirtualization is not
> the only reason).

In general that seems valid though in these particular cases I don't
think the compiler could eliminate many members because most of them are
virtual functions, and pointers to objects of there type escape the TU.

> > are they actually all that common?  I think gcc is the only C++ with
> > which I'm familiar that uses them much.
> LLVM is an example of another large project, which uses anonymous namespaces
> extensively: http://llvm.org/docs/CodingStandards.html#anonymous-namespaces

interesting

> BTW, I noticed that LLVM developers put small inline functions into anon.
> namespaces (instead of just declaring them static). I wonder, whether it is 
> just a
> matter of style or there is some other, more important reason...

I can't think of one, and that seems to contradict the style guide you
linked?

> >> The problem is you can't get to stuff in the anonymous namespace easily in
> >> the debugger.  There was talk of fixing that, but I don't think it ever 
> >> went
> >> forward on the gdb side.
> I think, a possible solution is to define a macro which expands to "namespace 
> {"
> during normal build and expands to nothing in some sort of "debug build" (for
> example, when ENABLE_CHECKING is defined).

I'm wary of it being easy to write code that works with it defined one
way but not the other.

Trev

> 
> -- 
> Regards,
> Mikhail Maltsev

Re: Forwarding -foffload=[...] from the driver (compile-time) to libgomp (run-time)

[Joseph Myers]

On Fri, 14 Aug 2015, Thomas Schwinge wrote:

> Can you suggest off-hand where you'd expect this option filtering to
> happen?  Should this be during specs parsing in the driver; something
> like adding a lang_mask to gcc/gcc.c:struct switchstr, and then in
> gcc/gcc.c:give_switch ignore any switches that don't match the expected
> CL_*?  I seem to have difficulties to properly populate/deduce that
> lang_mask at the call sites of gcc/gcc.c:save_switch.  Or, did you
> imagine that to be done differently?

I don't have a particular design in mind; I was simply noting that the 
relevant information is available to the driver through the option 
handling data.

> Alternatively, what about changing gcc/opts-global.c:complain_wrong_lang
> to silently ignore options that don't apply instead of emitting a »is
> valid for [...] but not for [...]« diagnostic, if a (new) flag
> (-f[something]?) has been set, which would be active only during the
> add-omp-infile compilation?

That would be a possibility, yes.

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

Re: [PATCH 1/2] C++-ify dominance.c

[Mikhail Maltsev]

On 08/14/2015 10:54 AM, Richard Biener wrote:
> Putting in m_fn looks backwards to me - it looks like we only need to remember
> the entry and exit BBs and the number of blocks. 

Fixed.

> In fact initializing
> dom_info from that would allow it to work on SESE regions as well?

Can't tell for sure. We would need a way to iterate through region's basic
blocks (I'm not familiar with that code, but it seems to me that they are not
contiguous: build_sese_loop_nests function iterates through the region by
iterating through all BBs and filtering out ones which are not in region). Also
we have a mapping from some global BB index to it's number in DFS-order walk,
i.e. we will either need to allocate enough space for it, or use a hash map
instead of an array. Never the less, initializing start/end blocks and "reverse"
flag in constructor makes the code look cleaner because we avoid repeating these
initializations.

> if you are here please fix the 'extern' vs. w/o 'extern' inconsistencies as 
> well
> (we prefer 'extern').
Reverted (see later).

On 08/14/2015 09:20 PM, Jeff Law wrote:
> It looks like your patch is primarily concerned with converting all the 
> internal
> stuff into a C++ style and not exposing a class to the users of dominance.h.
> Correct?
Well, sort of. But I think this class also provides some API (though it's used
internally in dominance.c): it computes some initial dominance tree and other
functions either query it or update incrementally. And, as Richard said, this
class could be modified to be used on SESE regions.

> I could argue that those kind of changes are independent of turning dom_info
> into a real class and if they're going to go forward, they would have to stand
> alone on their merits and go in independently if turning dom_info into a class
> (which AFIACT is the meat of this patch).
Actually I thought that putting all these non-functional changes into a single
patch would make the churn less (after all, it's a single commit). But I
understand this rather obvious cue, that these changes are, well, unlikely to be
accepted.
So, the updated patch contains only the dom_info-related changes.

> Umm, isn't ENABLE_CHECKING defined in auto-host.h (as set up by configure?)
> What's the reason for this change?
>
> Is the issue that auto-host.h won't define checking at all for 
> --disable-checking?
Yes, it does not get defined even for --enable-checking=release.

>
> I think that the ENABLE_CHECKING conversion from #ifdef testing to testing 
> for a
> value should probably be done separately.  It also probably has higher value
> than this refactoring.
Well, I'll try to work on that. After all, it's the most frequently used
condition for conditional compilation in GCC. And removing part of #ifdef-s will
probably help to avoid some errors (e.g. warnings which only appear in "release"
builds).

>
>
>> +
>> +  /* The function being processed.  */
>> +  function *m_fn;
> So presumably the idea here is to avoid explicitly hitting cfun which in 
> theory
> we could recompute the dominance tree for another function. But is that really
> all that useful?
No, I was thinking more of moving toward having a self-contained compilation
context and being able to run compilation in multiple threads. I know that we
are far away from this goal but never the less. BTW, do we actually have such
goal or not? :)

>
> I'm a bit torn here.  Richi mentioned the idea of stuffing away a pointer to
> cfun looked backwards to him and he'd pretty stuffing away the entry, exit & #
> blocks and perhaps take us a step towards the ability to compute dominance on
> sub-graphs.
>
> The problem I see with Richi's idea now that I think about it more is keeping
> that information up-to-date.  Ie, if we've stuffed away those pointers, what
> happens if (for example) a block gets deleted from the graph.  What if that
> block happens to be the exit block we've recorded?
All this information is discarded after we have the dominator tree computed. The
tree itself is stored in et_node-s (which are "attached" to basic blocks).
dom_info is not used for incremental updates.


gcc/ChangeLog:

2015-08-15  Mikhail Maltsev 

* dominance.c (new_zero_array): Define.
(dom_info): Redefine as class with proper encapsulation.
(dom_info::m_n_basic_blocks, m_reverse, m_start_block, m_end_block):
Add new members.
(dom_info::dom_info, ~dom_info): Define.  Use new/delete for memory
allocations/deallocations.  Pass function as parameter (instead of
using cfun).
(dom_info::get_idom): Define accessor method.
(dom_info::calc_dfs_tree_nonrec, calc_dfs_tree, compress, eval,
link_roots, calc_idoms): Redefine as class members.  Do not use cfun.
(calculate_dominance_info): Adjust to use dom_info class.
(verify_dominators): Likewise.

-- 
Regards,
Mikhail Maltsev

diff --git a/gcc/dominance.c b/gcc/dominance.c
index d8d87ca..e9b24ef 100644
--- a/gcc/dominance.c

Re: [PATCH 2/2] Get rid of global state accesses in dominance.c

[Mikhail Maltsev]

On 08/14/2015 11:02 AM, Richard Biener wrote:
> So the last time I did similar refactoring I wondered if we can somehow avoid
> the "noise" in non-IPA passes.  Ideas I came up with are
> 
>  a)  Inherit gimple/rtl pass classes from a class which is initialized with 
> the
>   function the pass operates on and provides methods like
> 
> bool dom_info_available_p (..) { return dom_info_available_p (fn, ...); }
> 
>  thus wraps APIs working on a specific function.
> 
>  b)  Do sth similar but make it work with overloads and clever (no idea what!)
> C++ that disables them if this_fn cannot be looked up
> 
> template 
> bool dom_info_available_p (..., struct function *fn = this_fn);
> 
I attached some sketch of what this "clever C++" could look like. It still
requires some changes in classes which would use this new base class, but they
are not very significant compared to converting pass functions into members of
these classes.

> all of the above would of course require that passes make all their
> implementation
> be methods of their pass class.  So even more refactoring.
The good thing is that this can be done incrementally, i.e. changing one pass at
a time.

> Refactoring APIs that are used from IPA and make push/pop_cfun necessary
> for them are another thing.  (there are still plenty left I think)
What I could find is:
1. ipa_analyze_node
2. some transactional memory-related stuff: ipa_tm_scan_irr_function,
ipa_tm_transform_transaction, ipa_tm_transform_clone, ipa_tm_execute.
3. tree_profiling

Presumably there are no more calculate_dominance_info/free_dominance_info call
sites with push_cfun/pop_cfun nearby (except for passes.c, but they are not
related to IPA). So now I need to figure out, what other global state (which is
set up by push_cfun) can these functions use? Could you give some advice about
that, in sense, what should I look for (e.g., push_cfun calls some target hooks,
but I did not try to look in detail, what kind of actions are performed by it)?

As for the API. I propose to, at least, remove uses of cfun from dominance.c
itself, but provide helper functions which will allow to leave the callers
unchanged, but make it possible to use all dominance-related API on functions
other than cfun.
Does such change sound reasonable to you?


On 08/14/2015 11:11 PM, David Malcolm wrote:
> The JIT guards all access to GCC's state in a big mutex ("jit_mutex", in
> gcc/jit/jit-playback.c).
Yeah, I know, I looked through JIT documentation briefly.
> 
> For example, this includes everything to do with GC and GTY, since
> there's implicitly a single set of GC roots and the GC code isn't thread
> safe.
And GGC is a "stop-the-world" collector, which is just not designed for
multithreaded environment. (sigh)

As for the patch, I think reviewing this variant does not make much sense,
because of Richard suggestion on how to avoid changing the callers. But still
thanks for looking.

> 
> I've been tackling things on an as-needed basis - for example, the
> recent timevar global-state removal was motivated by wanting to expose a
> profiling API to jit client code.
> 
By the way, speaking of timevars. I wrote about my concerns w.r.t. them, but did
not get any feedback:
https://gcc.gnu.org/ml/gcc/2015-07/msg00165.html
Briefly speaking, I noticed that our timers introduce rather significant
measurement errors and proposed some ideas about reducing them. What do you 
think?

-- 
Regards,
Mikhail Maltsev
#include 

//===- various headers - Existing GCC code ===//
//
// No changes required
//===--===//

enum cdi_direction {
CDI_DOMINATORS,
CDI_POSTDOMINATORS
};

struct basic_block_def { };
typedef basic_block_def *basic_block;
struct function
{
};

function *cfun;

class gimple_opt_pass
{
public:
virtual unsigned int execute(function *) = 0;
};

//===- dominance.h - Refactored version ---===//
//
// Allow passing function as an additional parameter (with default value), so
// that dominaince.c does not directly use cfun any more.
//===--===//

// We will need cfun to be in scope. Alternatively, we can put a 3-argument
// overload of domainted_by_p in another header, where cfun is available.
extern function *cfun;

bool
dominated_by_p(cdi_direction, basic_block, basic_block, function *fun = cfun)
{
(void)fun;
printf("\t4-argument overload\n");
return false;
}

//===- old_pass.c - This pass uses cfun ---===//
//
// We don't need to change anything here
//===--===//

class old_pass : public gimple_opt_pass
{
public:
virtual unsigned int execute(function *);
};

void old_pass_do_stuff()
{
basic_block bb1 = 0, bb2 = 0;
// ...
if (dominated_by_p(CDI_DOMINATORS, bb1

[GOOGLE] Reset lambda scope information when popping module for LIPO

[Teresa Johnson]

This patch resets the lambda scope based sequence numbering used to assign
numbers to lambdas during parsing when we pop a module scope. This resets
the numbering for subsequent modules imported during LIPO compilation.

It also renames cp_clear_deferred_fns to reset_parsing_state, as that
routine now (and has for awhile) encompasses more than just deferred
function clearing.

Passes regression tests. Ok for google 4_9?

2015-08-14  Teresa Johnson  

Google ref b/23176787.
* cp/cp-lang.c: Rename clear_deferred_fns to reset_parsing_state.
* cp/cp-tree.h: Ditto, declare clear_lambda_scope.
* cp/decl2.c (cp_reset_parsing_state): Ditto, call clear_lambda_scope.
* cp/parser.c (clear_lambda_scope): New function.
* l-ipo.c (pop_module_scope): Rename clear_deferred_fns to
reset_parsing_state.
* langhooks-def.h: Ditto.
* langhooks.h: Ditto.

Index: cp/cp-lang.c
===
--- cp/cp-lang.c(revision 226875)
+++ cp/cp-lang.c(working copy)
@@ -109,8 +109,8 @@ static tree get_template_argument_pack_elems_folde
 #define LANG_HOOKS_COPY_LANG_TYPE cp_lipo_copy_lang_type
 #undef LANG_HOOKS_PROCESS_PENDING_DECLS
 #define LANG_HOOKS_PROCESS_PENDING_DECLS cp_process_pending_declarations
-#undef LANG_HOOKS_CLEAR_DEFFERED_FNS
-#define LANG_HOOKS_CLEAR_DEFFERED_FNS cp_clear_deferred_fns
+#undef LANG_HOOKS_RESET_PARSING_STATE
+#define LANG_HOOKS_RESET_PARSING_STATE cp_reset_parsing_state
 #undef LANG_HOOKS_IS_GENERATED_TYPE
 #define LANG_HOOKS_IS_GENERATED_TYPE cp_is_compiler_generated_type
 #undef LANG_HOOKS_CMP_LANG_TYPE
Index: cp/cp-tree.h
===
--- cp/cp-tree.h(revision 226875)
+++ cp/cp-tree.h(working copy)
@@ -4385,6 +4385,7 @@ extern int cp_unevaluated_operand;
 extern tree cp_convert_range_for (tree, tree, tree, bool);
 extern bool parsing_nsdmi (void);
 extern void inject_this_parameter (tree, cp_cv_quals);
+extern void clear_lambda_scope (void);

 /* in pt.c  */

@@ -5342,7 +5343,7 @@ extern void cplus_decl_attributes (tree *, tree,
 extern void finish_anon_union  (tree);
 extern void cp_write_global_declarations   (void);
 extern void cp_process_pending_declarations (location_t);
-extern void cp_clear_deferred_fns   (void);
+extern void cp_reset_parsing_state  (void);
 extern void cp_clear_constexpr_hashtable(void);
 extern void cp_clear_conv_type_map  (void);
 extern tree coerce_new_type(tree);
Index: cp/decl2.c
===
--- cp/decl2.c  (revision 226875)
+++ cp/decl2.c  (working copy)
@@ -4178,10 +4178,10 @@ no_linkage_error (tree decl)
   "to declare function %q#D with linkage", t, decl);
 }

-/* Clear the list of deferred functions.  */
+/* Reset the parsing state for the next module.  */

 void
-cp_clear_deferred_fns (void)
+cp_reset_parsing_state (void)
 {
   vec_free (deferred_fns);
   deferred_fns = NULL;
@@ -4192,6 +4192,7 @@ void
   clear_pending_templates ();
   reset_anon_name ();
   reset_temp_count ();
+  clear_lambda_scope ();
 }

 /* Collect declarations from all namespaces relevant to SOURCE_FILE.  */
Index: cp/parser.c
===
--- cp/parser.c (revision 226875)
+++ cp/parser.c (working copy)
@@ -8705,6 +8705,16 @@ finish_lambda_scope (void)
   lambda_scope_stack->pop ();
 }

+void
+clear_lambda_scope (void)
+{
+  if (!lambda_scope_stack)
+return;
+  gcc_assert(lambda_scope_stack->is_empty());
+  lambda_scope = NULL_TREE;
+  lambda_count = 0;
+}
+
 /* Parse a lambda expression.

lambda-expression:
Index: l-ipo.c
===
--- l-ipo.c (revision 226875)
+++ l-ipo.c (working copy)
@@ -414,7 +414,7 @@ pop_module_scope (void)
   at_eof = 1;
   cgraph_process_same_body_aliases ();
   lang_hooks.l_ipo.process_pending_decls (input_location);
-  lang_hooks.l_ipo.clear_deferred_fns ();
+  lang_hooks.l_ipo.reset_parsing_state ();
   at_eof = 0;

   is_last = is_last_module (current_module_id);
Index: langhooks-def.h
===
--- langhooks-def.h (revision 226875)
+++ langhooks-def.h (working copy)
@@ -214,7 +214,7 @@ extern tree lhd_make_node (enum tree_code);
 #define LANG_HOOKS_DUP_LANG_TYPE lhd_do_nothing_t_t
 #define LANG_HOOKS_COPY_LANG_TYPE lhd_do_nothing_t_t
 #define LANG_HOOKS_PROCESS_PENDING_DECLS lhd_do_nothing_u
-#define LANG_HOOKS_CLEAR_DEFFERED_FNS lhd_do_nothing
+#define LANG_HOOKS_RESET_PARSING_STATE lhd_do_nothing
 #define LANG_HOOKS_IS_GENERATED_TYPE lhd_do_nothing_t_return_bool
 #define LANG_HOOKS_CMP_LANG_TYPE lhd_do_nothing_t_t_return_int

@@ -231,7 +231,7 @@ extern tree lhd_make_node (enum tree_code);
   LANG_HOOKS_D

Re: [PATCH 1/2] C++-ify dominance.c

[Richard Biener]

On August 14, 2015 8:20:18 PM GMT+02:00, Jeff Law  wrote:
>On 08/13/2015 06:55 PM, Mikhail Maltsev wrote:
>> Hi all.
>>
>> These two patches are refactoring of dominator-related code.
>>
>> The comment in dominance.c says: "We work in a poor-mans object
>oriented
>> fashion, and carry an instance of this structure through all our
>'methods'". So,
>> the first patch converts the mentioned structure (dom_info) into a
>class with
>> proper encapsulation. It also adds a new member - m_fn (the function
>currently
>> being compiled) to this structure and replaces some uses of cfun with
>m_fn. It
>> also contains some fixes, related to current coding standards: move
>variable
>> declarations to place of first use, replace elaborated type
>specifiers (i.e.
>> "struct/enum foo") by simple ones (i.e., just "foo") in function
>prototypes.
>>
>> Bootstrapped and regtested on x86_64-linux. Tested build of
>config-list.mk.
>>
>> gcc/ChangeLog:
>>
>> 2015-08-14  Mikhail Maltsev
>>
>>  * (ENABLE_CHECKING): Define as 0 by default.
>>  dominance.c (new_zero_array): Define.
>>  (dom_info): Define as class instead of struct.
>>  (dom_info::dom_info, ~dom_info): Define.  Use new/delete for
>memory
>>  allocations/deallocations.  Pass function as parameter
>(instead of
>>  using cfun).
>>  (dom_info::get_idom): Define accessor method.
>>  (dom_info::calc_dfs_tree_nonrec, calc_dfs_tree, compress,
>eval,
>>  link_roots, calc_idoms): Redefine as class members.  Use
>m_fn instead
>>  of cfun.
>>  (init_dom_info, free_dom_info): Remove (use dom_info
>ctor/dtor).
>>  (dom_convert_dir_to_idx): Fix prototype.
>>  (assign_dfs_numbers): Move variable declarations to their
>first uses.
>>  (calculate_dominance_info): Remove conditional compilation,
>move
>>  variables.
>>  (free_dominance_info, get_immediate_dominator,
>set_immediate_dominator,
>>  get_dominated_b, get_dominated_by_region,
>get_dominated_to_depth,
>>  redirect_immediate_dominators,
>nearest_common_dominator_for_set,
>>  dominated_by_p, bb_dom_dfs_in, bb_dom_dfs_out,
>verify_dominators,
>>  determine_dominators_for_sons, iterate_fix_dominators,
>first_dom_son,
>>  next_dom_son, debug_dominance_info, debug_dominance_tree_1):
>Adjust to
>>  use class dom_info. Move variable declarations to the place
>of first
>>  use. Fix prototypes (remove struct/enum).
>>  * dominance.h: Fix prototypes (remove struct/enum).
>>
>> -- Regards, Mikhail Maltsev
>>
>It looks like your patch is primarily concerned with converting all the
>
>internal stuff into a C++ style and not exposing a class to the users
>of 
>dominance.h. Correct?
>
>As a whole I don't see anything objectionable here, but I also don't
>see 
>that it really takes us forward in a real significant way.  I guess 
>there's some value in having dominance.c brought up to current 
>standards, but my recollection was we weren't going to do through the 
>entire source base and do things like move variable declarations to 
>their initial use and more generally c++-ify the code base en-masse.
>
>Similarly losing the elaborated type specifiers doesn't really gain us 
>anything, except perhaps one less token when people parse the code. 
>Again, not objectionable, but also not a big gain.
>
>I could argue that those kind of changes are independent of turning 
>dom_info into a real class and if they're going to go forward, they 
>would have to stand alone on their merits and go in independently if 
>turning dom_info into a class (which AFIACT is the meat of this patch).
>
>
>
>> refactor_dom1.patch
>>
>>
>> diff --git a/gcc/dominance.c b/gcc/dominance.c
>> index d8d87ca..3c4f228 100644
>> --- a/gcc/dominance.c
>> +++ b/gcc/dominance.c
>> @@ -44,6 +44,10 @@
>>   #include "timevar.h"
>>   #include "graphds.h"
>>
>> +#ifndef ENABLE_CHECKING
>> +# define ENABLE_CHECKING 0
>> +#endif
>Umm, isn't ENABLE_CHECKING defined in auto-host.h (as set up by 
>configure?)  What's the reason for this change?
>
>Is the issue that auto-host.h won't define checking at all for 
>--disable-checking?
>
>I think that the ENABLE_CHECKING conversion from #ifdef testing to 
>testing for a value should probably be done separately.  It also 
>probably has higher value than this refactoring.
>
>
>> +
>> +  /* The function being processed.  */
>> +  function *m_fn;
>So presumably the idea here is to avoid explicitly hitting cfun which
>in 
>theory we could recompute the dominance tree for another function. But 
>is that really all that useful?
>
>I'm a bit torn here.  Richi mentioned the idea of stuffing away a 
>pointer to cfun looked backwards to him and he'd pretty stuffing away 
>the entry, exit & # blocks and perhaps take us a step towards the 
>ability to compute dominance on sub-graphs.
>
>The problem I see with Richi's idea now that I think about it more is 
>keeping that