Re: [PATCH][RTL-ifcvt] PR rtl-optimization/68841: Make sure one basic block doesn't clobber CC reg usage of the other

[Kyrill Tkachov]

Hi Bernd,

On 05/01/16 18:19, Kyrill Tkachov wrote:


On 05/01/16 17:06, Kyrill Tkachov wrote:


On 05/01/16 16:34, Bernd Schmidt wrote:

On 01/05/2016 03:22 PM, Kyrill Tkachov wrote:


This works around the issue but we don't want to do perform the check
for pairs of
simple basic blocks because then we'll end up rejecting code that does
things like:
x = cond ? x + 1 : x - 1
i.e. source of the set in both blocks reads and writes the same register.
We can deal with this safely later on in the function since we rename
the destinations
of the two sets, so we don't want to reject this case here.


So we need to teach bbs_ok_for_cmove_arith that this is going to happen. How 
about the approach below? Still seems to fix the issue, and it looks like the 
CC set is present in the df info so everything should work as intended. Right?



Yeah, this looks like it works.
However, now we reject if-conversion whereas with my patch we still tried 
switching the order in which
the blocks were emitted, which allowed for a bit more aggressive if-conversion.
I don't know if this approach is overly restrictive yet.
I'll try its effects on codegen quality on SPEC as soon as I get some cycles.
But this approach does look appealing to me.



Hmm, from a first look at SPEC, it seems to still overly restrict ifconversion 
in the
x = cond ? x + 1 : x - 1 case.
I'll look deeper tomorrow as to what's going on there.



Ok, found the problem.
bbs_ok_for_cmove_arith also checks that we don't perform any stores in the 
basic block, which kills opportunities
to convert operations of the form [addr] = c ? a : b. Since with your patch we 
now call this even for
simple basic blocks we miss these opportunities.

bb_valid_for_noce_process_p called earlier should have already ensured that for 
complex
blocks we allow only the last set to be a store, so we should be able to relax 
the restriction in
bbs_ok_for_cmove_arith. That change in combination with your patch fixes the 
testcase and has no code quality
fallout that I can see (it even slightly increases if-conversion 
opportunities). I'll test more thoroughly
and post a patch in due time.

Thanks,
Kyrill


Kyrill


Thanks for the help,
Kyrill



Bernd

Re: [PATCH] -Winvalid-memory-model warning not given for stdatomic.h macros (PR c/69104)

[Andreas Schwab]

* gcc.dg/atomic-invalid-2.c: Remove duplicated content.

diff --git a/gcc/testsuite/gcc.dg/atomic-invalid-2.c 
b/gcc/testsuite/gcc.dg/atomic-invalid-2.c
index 6bf5c96..c73458e 100644
--- a/gcc/testsuite/gcc.dg/atomic-invalid-2.c
+++ b/gcc/testsuite/gcc.dg/atomic-invalid-2.c
@@ -57,62 +57,3 @@ clear (atomic_int *i)
   atomic_flag_clear_explicit (i, memory_order_acquire); /* { dg-warning 
"invalid memory model" } */
   atomic_flag_clear_explicit (i, memory_order_acq_rel); /* { dg-warning 
"invalid memory model" } */
 }
-/* PR c/69104.  Test atomic routines for invalid memory model errors.  This
-   only needs to be tested on a single size.  */
-/* { dg-do compile } */
-/* { dg-require-effective-target sync_int_long } */
-
-#include 
-
-/* atomic_store_explicit():
-   The order argument shall not be memory_order_acquire,
-   memory_order_consume, nor memory_order_acq_rel.  */
-
-void
-store (atomic_int *i)
-{
-  atomic_store_explicit (i, 0, memory_order_consume); /* { dg-warning "invalid 
memory model" } */
-  atomic_store_explicit (i, 0, memory_order_acquire); /* { dg-warning "invalid 
memory model" } */
-  atomic_store_explicit (i, 0, memory_order_acq_rel); /* { dg-warning "invalid 
memory model" } */
-}
-
-/* atomic_load_explicit():
-   The order argument shall not be memory_order_release nor
-   memory_order_acq_rel.  */
-
-void
-load (atomic_int *i)
-{
-  atomic_int j = atomic_load_explicit (i, memory_order_release); /* { 
dg-warning "invalid memory model" } */
-  atomic_int k = atomic_load_explicit (i, memory_order_acq_rel); /* { 
dg-warning "invalid memory model" } */
-}
-
-/* atomic_compare_exchange():
-   The failure argument shall not be memory_order_release nor
-   memory_order_acq_rel.  The failure argument shall be no stronger than the
-   success argument.  */
-
-void
-exchange (atomic_int *i)
-{
-  int r;
-
-  atomic_compare_exchange_strong_explicit (i, , 0, memory_order_seq_cst, 
memory_order_release); /* { dg-warning "invalid failure memory" } */
-  atomic_compare_exchange_strong_explicit (i, , 0, memory_order_seq_cst, 
memory_order_acq_rel); /* { dg-warning "invalid failure memory" } */
-  atomic_compare_exchange_strong_explicit (i, , 0, memory_order_relaxed, 
memory_order_consume); /* { dg-warning "failure memory model cannot be 
stronger" } */
-
-  atomic_compare_exchange_weak_explicit (i, , 0, memory_order_seq_cst, 
memory_order_release); /* { dg-warning "invalid failure memory" } */
-  atomic_compare_exchange_weak_explicit (i, , 0, memory_order_seq_cst, 
memory_order_acq_rel); /* { dg-warning "invalid failure memory" } */
-  atomic_compare_exchange_weak_explicit (i, , 0, memory_order_relaxed, 
memory_order_consume); /* { dg-warning "failure memory model cannot be 
stronger" } */
-}
-
-/* atomic_flag_clear():
-   The order argument shall not be memory_order_acquire nor
-   memory_order_acq_rel.  */
-
-void
-clear (atomic_int *i)
-{
-  atomic_flag_clear_explicit (i, memory_order_acquire); /* { dg-warning 
"invalid memory model" } */
-  atomic_flag_clear_explicit (i, memory_order_acq_rel); /* { dg-warning 
"invalid memory model" } */
-}
-- 
2.7.0

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

Re: [patch] ARM FreeBSD fix bootstrap

[Richard Earnshaw (lists)]

On 05/01/16 21:03, Andreas Tobler wrote:
> On 05.01.16 11:32, Richard Earnshaw (lists) wrote:
>> On 23/12/15 19:28, Andreas Tobler wrote:
> 
>>> 2015-12-23  Andreas Tobler  
>>>
>>>  * config/arm/freebsd.h: Rename SUBTARGET_OVERRIDE_OPTIONS to
>>>  SUBTARGET_OVERRIDE_INTERNAL_OPTIONS. Adjust to check
>>>  unaligned_access on the gcc_options set.
>>>  * config/arm/arm.c (arm_option_override_internal): Use
>>>  SUBTARGET_OVERRIDE_INTERNAL_OPTIONS.
>>>
>>>
>>
>> This is OK.
>>
>> One question, though, is whether you should explicitly override a user
>> request for unaligned accesses without at least warning that this is
>> being done.
> 
> 
> Like this?
> 
> config/arm/freebsd.h:
> 
> #define SUBTARGET_OVERRIDE_INTERNAL_OPTIONS\
> do {\
> if (opts_set->x_unaligned_access == 1)\
> warning (0, "target CPU does not support unaligned accesses");\
> if (opts->x_unaligned_access)\
> opts->x_unaligned_access = 0;
> 

Something like that, but the problem is not that the CPU does not
support unaligned accesses, but that FreeBSD does not support CPUs doing
unaligned accesses.

Anyway, I'll pre-approve a patch adding a suitable warning here.

R.

> Thank you for the feedback.
> 
> Andreas   
> 

Re: [PATCH] -Winvalid-memory-model warning not given for stdatomic.h macros (PR c/69104)

[Marek Polacek]

On Wed, Jan 06, 2016 at 11:46:32AM +0100, Andreas Schwab wrote:
>   * gcc.dg/atomic-invalid-2.c: Remove duplicated content.

Thanks and sorry.  No idea how did that happen.

Marek

Re: [PATCH] Fix pr69012 ICE on building libgfortran for mips

[Bernd Edlinger]

On 05.01.2016 21:41, Richard Sandiford wrote:
> Matthew Fortune  writes:
>> Bernd Edlinger  writes:
>>> Yes, I agree, it _should_ be a no-op, but given the complexity of
>>> mips_compute_frame_info it is probably better to use cached values after
>>> reload completed.
>>>
>>> Before reload_completed, rtx_addr_can_trap_p is just trying to do an
>>> initial guess on the stack layout, it may well be possible that some
>>> important information is still missing here.  We will never call the
>>> target callback from here, before reload_completed.  It is however not
>>> completely impossible that rtx_addr_can_trap_p is called while
>>> lra/reload is already renaming the registers, see PR66614.
> It sounds like we could then have the same kind of problem when
> reload_in_progress though.  I.e. we'd have a predicate function like
> rtx_addr_can_trap_p changing global state.  I realise the symptoms
> wouldn't be the same as in this PR because the instructions that trigger
> the ICE are part of the prologue, but it might show up in other ways.

No, not really.  The logic in rtx_addr_can_trap_p is only dependent on 
reload_completed, when reload_completed is false, it uses a simplified 
stack layout, that only takes crtl->outgoing_args_size and 
get_frame_size () into account.  Only when reload_completed is true, it 
tries to get more accurate information from the 
INITIAL_ELIMINATION_OFFSET, which can easily skip the frame re-layout if 
reload_completed is true.

> E.g. LRA (like reload) loops until it reaches a stable stack layout.
> If one iteration of the loop does something that changes the stack
> layout (and so requires another go-round), calling rtx_addr_can_trap_p
> before the loop restarts would alter the global state unexpectedly.
> That might trigger an ICE.

It is impossible that it can happen again.

>
> If we need rtx_addr_can_trap_p to be as accurate as possible (rather
> than conservative) during LRA/reload, I suppose we should calculate
> the crtl fields I mentioned during each LRA/reload phase, rather than
> at the end.

Sure rtx_addr_can_trap_p is not always 100% accurate, but the data that 
is missing is not only the initial_elimination_offset, as it was used by 
reload, which may be already available with your patch while 
reload_in_progress (but the PR describes a case where the index register 
and the offset does not match, so that would not be fixed. Other than 
these I never observed false positives in the reload pass, so I assume 
that the simplified frame layout is sufficiently accurate though).

What could be improved is this, but it is not really simple: Actually 
most registers keep the same offset relative to each other, argp, fp, 
hfp are constant, but sp is something different. Sometimes, sp can keep 
the same value in the whole body, but even without alloca, sp can become 
different than what the function started with.  For instance we push 
parameters for a function call, and then reload knows that, and can 
still use [sp+x] to access the next value, but rtx_addr_can_trap_p does 
not have access to the insn, and thus can not know that sp is now 
different than at the beginning of the function.  I think the reg_notes 
on the insns should have the necessary data, but from 
rtx_addr_can_trap_p it is impossible to get to the corresponding insn.  
Maybe reload could add some annotations to the sp-relative offsets, to 
make it possible for rtx_addr_can_trap_p to find out, if there is a 
constant offset from the current sp to the initial sp.

>>> Of course the required information is already cached in
>>> cfun->machine->frame, but rtx_addr_can_trap_p can't use the information
>>> without a target callback.  And I just want to avoid to invent a new
>>> callback for that.
> Right.  I don't think we need or want a new callback.  My point was
> that reload and LRA already compute the offsets you need, so it seems
> better to cache them there than to try to recalculate them in rtlanal.c.
>
>>> I looked at how other targets handle this situation and found that most
>>> of them either have a more simple frame layout function or they keep the
>>> previously cached values if they are ever called after reload_completed.
>>>
>>> I found, previously mips_compute_frame_info was always called with
>>> reload_completed=false, either from mips_frame_pointer_required or from
>>> mips_initial_elimination_offset.  Reload seems to call the
>>> initial_elimination_offset repeatedly and seems to _expect_ the values
>>> to change from time to time.
> Yeah.  This happens if the first reload attempt fails because there aren't
> enough free registers or enough spill slots.  We then update the frame
> layout to account for the new spill slots and call-saved register save
> slots, then try again.
>
>>> However it does not seem to expect the
>>> result from mips_frame_pointer_required to change after reload/LRA has
>>> started.  But as it seems, that may be 

Re: [PATCH] c/68966 - atomic_fetch_* on atomic_bool not diagnosed

[Marek Polacek]

On Tue, Jan 05, 2016 at 11:46:52AM -0700, Martin Sebor wrote:
> I just downloaded and installed an Emacs equivalent called redspace.
> It does the same thing.  Unfortunately, it also has the effect of
> highlighting in red the one blank inserted by diff at the beginning
> of empty lines. I guess the way to deal with that is to avoid
> inserting blank spaces into changes to begin with rather than trying
> to remove them from the final patch.
 
Maybe some Emacs user can offer some advice (but we're slightly off topic here
;).

> I use the script on bigger patches.  I just haven't trained myself
> to use it consistently, for all of them, and each time I post a new
> revision of a patch for review.  (The script also complains about

I have a script called "P" that generates a patch, runs an ancient version of
mklog, adds "PR c/#" etc. and finally it runs check_GNU_style so that I won't
forget.

> tests where following the convention isn't always possible -- e.g.,
> lines over 80 characters are unavoidable due to dg-error directives,
> and periods can't be preceded by a space when they are part of
> regular expressions in dg- directives..)

Yes, you need to mentally filter out the output for tests.
 
> gcc/testsuite/ChangeLog:
> 2016-01-04  Martin Sebor  
> 
>   PR c/68966
>   * gcc.dg/atomic-fetch-bool.c: New test.
>   * gcc.dg/sync-fetch-bool.c: Same.

So the tradition is to repeat "New test." rather than to say "Same."

Otherwise ok, thanks.

Marek

Re: [PATCH 2/4 v2][AArch64] Add support for FCCMP

[Wilco Dijkstra]

Hi Evandro,

> Here's what I had in mind when I inquired about distinguishing FCMP from
> FCCMP.  As you can see in the patch, Exynos is the only target that
> cares about it, but I wonder if ThunderX or Xgene would too.
> 
> What do you think?

The new attributes look fine (I've got a similar outstanding change), however
please don't add them to non-AArch64 cores. We only need it for thunderx.md,
cortex-a53.md, cortex-a57.md, xgene1.md and exynos-m1.md.

Wilco

Re: [PATCH] PR target/68991: Add vector_memory_operand and "Bm" constraint

[Uros Bizjak]

On Tue, Jan 5, 2016 at 10:34 PM, Richard Sandiford
 wrote:
> Jakub Jelinek  writes:
>> On Mon, Jan 04, 2016 at 03:25:48PM -0800, H.J. Lu wrote:
>>> LRA is fine.  I should use
>>>
>>> (define_memory_constraint "Bm"
>>>   "@internal Vector memory operand."
>>>   (match_operand 0 "vector_memory_operand"))
>>>
>>> instead of
>>>
>>> (define_constraint "Bm"
>>>   "@internal Vector memory operand."
>>>   (match_operand 0 "vector_memory_operand"))
>>
>> I don't think so.  At least the documentation says that
>> define_memory_constraint is for MEM constraints where if they are not
>> satisfied they can be made to satisfy by forcing the address into a
>> register.  But that is not the case here, if a MEM is misaligned, no
>> equivalent changes to the XEXP (mem, 0) will make it aligned.
>
> Yeah.  It seems like a missing feature though.  Maybe
> define_memory_constraint should have two conditions, one for
> when the MEM is valid and one for when the address is?
> Guess that isn't stage 3 material though.  And maybe longer-term
> we should avoid define_memory_constraint altogether and have an
> automatic way of testing whether replacing the address with a
> register is OK.

If we are going in this direction, is it possible define_memory_constraint
> Thanks,
> Richard

Re: [PATCH 2/2] Ada: add XVE/XVU parallel types to lexical scopes

[Pierre-Marie de Rodat]

Committed. Thank you!

--
Pierre-Marie de Rodat

[PATCH] Fix usage of an uninitialized variable

[Martin Liška]

Simple fix of a warning reported during bootstrap:

../../lto-plugin/lto-plugin.c: In function ‘all_symbols_read_handler’:
../../lto-plugin/lto-plugin.c:673:20: warning: ‘linker_output_str’ may be used 
uninitialized in this function [-Wmaybe-uninitialized]
   *lto_arg_ptr++ = xstrdup (linker_output_str);

Ready for trunk?
Thanks,
Martin

lto-plugin/ChangeLog:

2016-01-06  Martin Liska  

* lto-plugin.c (all_symbols_read_handler): Assign default
value to a string variable.
---
 lto-plugin/lto-plugin.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lto-plugin/lto-plugin.c b/lto-plugin/lto-plugin.c
index 0a6a767..1ed0f08 100644
--- a/lto-plugin/lto-plugin.c
+++ b/lto-plugin/lto-plugin.c
@@ -628,7 +628,7 @@ all_symbols_read_handler (void)
   unsigned num_lto_args
 = num_claimed_files + num_offload_files + lto_wrapper_num_args + 2;
   char **lto_argv;
-  const char *linker_output_str;
+  const char *linker_output_str = NULL;
   const char **lto_arg_ptr;
   if (num_claimed_files + num_offload_files == 0)
 return LDPS_OK;
-- 
2.6.3

Re: [PATCH] PR target/68991: Add vector_memory_operand and "Bm" constraint

[Uros Bizjak]

On Wed, Jan 6, 2016 at 10:18 AM, Uros Bizjak  wrote:
> On Tue, Jan 5, 2016 at 10:34 PM, Richard Sandiford
>  wrote:
>> Jakub Jelinek  writes:
>>> On Mon, Jan 04, 2016 at 03:25:48PM -0800, H.J. Lu wrote:
 LRA is fine.  I should use

 (define_memory_constraint "Bm"
   "@internal Vector memory operand."
   (match_operand 0 "vector_memory_operand"))

 instead of

 (define_constraint "Bm"
   "@internal Vector memory operand."
   (match_operand 0 "vector_memory_operand"))
>>>
>>> I don't think so.  At least the documentation says that
>>> define_memory_constraint is for MEM constraints where if they are not
>>> satisfied they can be made to satisfy by forcing the address into a
>>> register.  But that is not the case here, if a MEM is misaligned, no
>>> equivalent changes to the XEXP (mem, 0) will make it aligned.
>>
>> Yeah.  It seems like a missing feature though.  Maybe
>> define_memory_constraint should have two conditions, one for
>> when the MEM is valid and one for when the address is?
>> Guess that isn't stage 3 material though.  And maybe longer-term
>> we should avoid define_memory_constraint altogether and have an
>> automatic way of testing whether replacing the address with a
>> register is OK.

If we are going in this direction, is it possible to make
define_memory_constraint more general, so it would return register
class, not only default BASE_REG_CLASS? Some x86_64 instructions can
use only non-REX registers (including registers in the address) when
high registers (%ah, %dh, %ch and %bh) are involved.

Uros.

Re: [PATCH] shrink-wrap: Once more PRs 67778, 68634, and now 68909

[Segher Boessenkool]

On Mon, Jan 04, 2016 at 03:24:10PM +0100, Bernd Schmidt wrote:
> >>This code is getting really quite confusing,
> >>and at the least I think we
> >>need more documentation of what exactly vec is supposed to contain at
> >>the entry to the inner while loop here.
> >
> >Same as in the other loop: vec is a stack of blocks that still need to
> >be looked at.  I can duplicate the comment if you want?
> 
> No, I think more is needed.

Thanks for the review.  New patch attached.

> The inner loop looks like it should be 
> emptying the vec, but this is not true if we break out of it, and your 
> patch now even adds an explicit push.

I added a big comment explaining the algorithm, and changed the push back
to do a peek instead.

> It also looks like it wants to use 
> the bb_tmp bitmap to cache results for future iterations of the outer 
> loop, but I'm not convinced this is actually correct. I can't follow 
> this behaviour anymore without clear a description of intent.

See the new comment.

> Also, it might be clearer to not modify "pro" in this loop - use a 
> "cand" variable, and modify "pro" instead of last_ok, getting rid of the 
> latter.

I tried that, and it doesn't make things clearer in my opinion.  Also
tried assigning "pro = pre" earlier, to make it more similar to the
previous loop; also not an improvement.

The patch also removes a superfluous (and confusing) bitmap set as well
as a bitmap test.

How's this?


Segher


Subject: [PATCH] shrink-wrap: Once more PRs 67778, 68634, and now 68909

If a candidate PRE cannot get the prologue because a block BB is
reachable from it, but PRE does not dominate BB, we try again with the
dominators of PRE.  That "try again" needs to again consider BB though,
we aren't done with it.

This fixes this problem.  Tested on the 68909 testcase, and bootstrapped
and regression checked on powerpc64-linux.  Is this okay for trunk?


2016-01-06  Segher Boessenkool  

PR rtl-optimization/67778
PR rtl-optimization/68634
PR rtl-optimization/68909
* shrink-wrap.c (try_shrink_wrapping): Add comment.  Don't pop
block from the stack until done with it.  Remove a superfluous
bitmap set.  Remove a superfluous bitmap test.
---
 gcc/shrink-wrap.c | 23 ---
 1 file changed, 16 insertions(+), 7 deletions(-)

diff --git a/gcc/shrink-wrap.c b/gcc/shrink-wrap.c
index e51bd36..84abd6b 100644
--- a/gcc/shrink-wrap.c
+++ b/gcc/shrink-wrap.c
@@ -750,9 +750,21 @@ try_shrink_wrapping (edge *entry_edge, bitmap_head 
*bb_with,
 
   /* If we can move PRO back without having to duplicate more blocks, do so.
  We do this because putting the prologue earlier is better for scheduling.
+
  We can move back to a block PRE if every path from PRE will eventually
  need a prologue, that is, PRO is a post-dominator of PRE.  PRE needs
- to dominate every block reachable from itself.  */
+ to dominate every block reachable from itself.  We keep in BB_TMP a
+ bitmap of the blocks reachable from PRE that we already found, and in
+ VEC a stack of those we still need to consider.
+
+ Any block reachable from PRE is also reachable from all predecessors
+ of PRE, so if we find we need to move PRE back further we can leave
+ everything not considered so far on the stack.  Any block dominated
+ by PRE is also dominated by all other dominators of PRE, so anything
+ found good for some PRE does not need to be reconsidered later.
+
+ We don't need to update BB_WITH because none of the new blocks found
+ can jump to a block that does not need the prologue.  */
 
   if (pro != entry)
 {
@@ -775,18 +787,15 @@ try_shrink_wrapping (edge *entry_edge, bitmap_head 
*bb_with,
  bool ok = true;
  while (!vec.is_empty ())
{
- basic_block bb = vec.pop ();
- bitmap_set_bit (bb_tmp, pre->index);
-
- if (!dominated_by_p (CDI_DOMINATORS, bb, pre))
+ if (!dominated_by_p (CDI_DOMINATORS, vec.last (), pre))
{
  ok = false;
  break;
}
 
+ basic_block bb = vec.pop ();
  FOR_EACH_EDGE (e, ei, bb->succs)
-   if (!bitmap_bit_p (bb_with, e->dest->index)
-   && bitmap_set_bit (bb_tmp, e->dest->index))
+   if (bitmap_set_bit (bb_tmp, e->dest->index))
  vec.quick_push (e->dest);
}
 
-- 
1.9.3

[patch] Rename bits/mutex.h to avoid clashing with glibc

[Jonathan Wakely]

Matthias discovered that the new  header I created on
trunk clashes with a libc header on GNU/Hurd, so this patch renames it
to something unique.

Tested powerpc64le-linux, committed to trunk.

commit cd573d5d7d0a13be626619fa4b663941e86cdf98
Author: Jonathan Wakely 
Date:   Wed Jan 6 12:43:07 2016 +

Rename bits/mutex.h to avoid clashing with glibc

	* include/Makefile.am: Adjust.
	* include/Makefile.in: Regenerate.
	* include/bits/mutex.h: Rename to bits/std_mutex.h.
	* include/std/condition_variable: Adjust include.
	* include/std/mutex: Likewise.

diff --git a/libstdc++-v3/include/Makefile.am b/libstdc++-v3/include/Makefile.am
index e657420..b0a9373 100644
--- a/libstdc++-v3/include/Makefile.am
+++ b/libstdc++-v3/include/Makefile.am
@@ -122,7 +122,7 @@ bits_headers = \
 	${bits_srcdir}/mask_array.h \
 	${bits_srcdir}/memoryfwd.h \
 	${bits_srcdir}/move.h \
-	${bits_srcdir}/mutex.h \
+	${bits_srcdir}/std_mutex.h \
 	${bits_srcdir}/ostream.tcc \
 	${bits_srcdir}/ostream_insert.h \
 	${bits_srcdir}/parse_numbers.h \
diff --git a/libstdc++-v3/include/bits/mutex.h b/libstdc++-v3/include/bits/mutex.h
deleted file mode 100644
index 67b7825..000
--- a/libstdc++-v3/include/bits/mutex.h
+++ /dev/null
@@ -1,373 +0,0 @@
-// std::mutex implementation -*- C++ -*-
-
-// Copyright (C) 2003-2016 Free Software Foundation, Inc.
-//
-// This file is part of the GNU ISO C++ Library.  This library is free
-// software; you can redistribute it and/or modify it under the
-// terms of the GNU General Public License as published by the
-// Free Software Foundation; either version 3, or (at your option)
-// any later version.
-
-// This library is distributed in the hope that it will be useful,
-// but WITHOUT ANY WARRANTY; without even the implied warranty of
-// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
-// GNU General Public License for more details.
-
-// Under Section 7 of GPL version 3, you are granted additional
-// permissions described in the GCC Runtime Library Exception, version
-// 3.1, as published by the Free Software Foundation.
-
-// You should have received a copy of the GNU General Public License and
-// a copy of the GCC Runtime Library Exception along with this program;
-// see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
-// .
-
-/** @file bits/mutex.h
- *  This is an internal header file, included by other library headers.
- *  Do not attempt to use it directly. @headername{mutex}
- */
-
-#ifndef _GLIBCXX_MUTEX_H
-#define _GLIBCXX_MUTEX_H 1
-
-#pragma GCC system_header
-
-#if __cplusplus < 201103L
-# include 
-#else
-
-#include 
-#include 
-#include 
-#include  // for std::swap
-
-#ifdef _GLIBCXX_USE_C99_STDINT_TR1
-
-namespace std _GLIBCXX_VISIBILITY(default)
-{
-_GLIBCXX_BEGIN_NAMESPACE_VERSION
-
-  /**
-   * @defgroup mutexes Mutexes
-   * @ingroup concurrency
-   *
-   * Classes for mutex support.
-   * @{
-   */
-
-#ifdef _GLIBCXX_HAS_GTHREADS
-  // Common base class for std::mutex and std::timed_mutex
-  class __mutex_base
-  {
-  protected:
-typedef __gthread_mutex_t			__native_type;
-
-#ifdef __GTHREAD_MUTEX_INIT
-__native_type  _M_mutex = __GTHREAD_MUTEX_INIT;
-
-constexpr __mutex_base() noexcept = default;
-#else
-__native_type  _M_mutex;
-
-__mutex_base() noexcept
-{
-  // XXX EAGAIN, ENOMEM, EPERM, EBUSY(may), EINVAL(may)
-  __GTHREAD_MUTEX_INIT_FUNCTION(&_M_mutex);
-}
-
-~__mutex_base() noexcept { __gthread_mutex_destroy(&_M_mutex); }
-#endif
-
-__mutex_base(const __mutex_base&) = delete;
-__mutex_base& operator=(const __mutex_base&) = delete;
-  };
-
-  /// The standard mutex type.
-  class mutex : private __mutex_base
-  {
-  public:
-typedef __native_type* 			native_handle_type;
-
-#ifdef __GTHREAD_MUTEX_INIT
-constexpr
-#endif
-mutex() noexcept = default;
-~mutex() = default;
-
-mutex(const mutex&) = delete;
-mutex& operator=(const mutex&) = delete;
-
-void
-lock()
-{
-  int __e = __gthread_mutex_lock(&_M_mutex);
-
-  // EINVAL, EAGAIN, EBUSY, EINVAL, EDEADLK(may)
-  if (__e)
-	__throw_system_error(__e);
-}
-
-bool
-try_lock() noexcept
-{
-  // XXX EINVAL, EAGAIN, EBUSY
-  return !__gthread_mutex_trylock(&_M_mutex);
-}
-
-void
-unlock()
-{
-  // XXX EINVAL, EAGAIN, EPERM
-  __gthread_mutex_unlock(&_M_mutex);
-}
-
-native_handle_type
-native_handle()
-{ return &_M_mutex; }
-  };
-
-#endif // _GLIBCXX_HAS_GTHREADS
-
-  /// Do not acquire ownership of the mutex.
-  struct defer_lock_t { explicit defer_lock_t() = default; };
-
-  /// Try to acquire ownership of the mutex without blocking.
-  struct try_to_lock_t { explicit try_to_lock_t() = default; };
-
-  /// Assume the calling thread has already obtained mutex ownership
-  /// and manage it.
-  struct adopt_lock_t { explicit adopt_lock_t() = default; };
-
-  

Re: [PATCH] v3 of diagnostic_show_locus and rich_location (was Re: [PATCH 2/5] Reimplement diagnostic_show_locus, introducing rich_location classes (v2))

[David Malcolm]

On Tue, 2015-12-29 at 12:53 -0800, Mike Stump wrote:
> On Sep 25, 2015, at 1:11 PM, David Malcolm 
> wrote:
> > +layout::layout (diagnostic_context * context,
> >> +  const diagnostic_info *diagnostic)
> >> 
> >> [...]
> >> 
> >> +  if (loc_range->m_finish.file != m_exploc.file)
> >> +  continue;
> >> +  if (loc_range->m_show_caret_p)
> >> +  if (loc_range->m_finish.file != m_exploc.file)
> >> +continue;
> >> 
> >> I think the second if clause is redundant.
> > 
> > Good catch; thanks.
> 
> And one other nit.  You don’t validate that the range finishes on or
> after the start.  Later in the code, you require this to be the case:
> 
> bool
> layout_range::contains_point (int row, int column) const
> {
>   gcc_assert (m_start.m_line <= m_finish.m_line);
> 
> this code cannot tolerate a range with that property.  So, either,
> such a range should never be generated, or, if it is to be generated,
> at least we should declare it awkward.  The below patch declares it to
> be awkward.  Without this, we ice on completely sane and normal code:
> 
>   #define max(i, j) sel((j), (i), (i) < (j))
>   yu = max(a2, a3);
> 
> giving a valid warning.  In the code, we start on the last line, and
> finish on the first line.  The underlying problem is that we don’t
> track macro contexts properly.  sel is a compiler built-in, so, it
> might be funnier that just a normal function call.  This is from a
> trunk compiler from 20151201.
> 
> So, I was wondering if the problem has been fixed, or, if we should
> put the below in now, or, would you prefer to try and do up the
> changes to better track macro expansions?

This is PR 68473.

I committed a workaround for it, similar to your one, as r231919 on
2015-12-22; I've been experimenting with a "deeper" fix for it that
would better respect macro expansions, but that might have to wait until
gcc 7.


> diff --git a/gcc/diagnostic-show-locus.c b/gcc/diagnostic-show-locus.c
> index 9e51b95..bea8423 100644
> --- a/gcc/diagnostic-show-locus.c
> +++ b/gcc/diagnostic-show-locus.c
> @@ -455,6 +455,9 @@ layout::layout (diagnostic_context * context,
>if (loc_range->m_show_caret_p)
> if (loc_range->m_caret.file != m_exploc.file)
>   continue;
> +  /* A range that finishes before it starts is awkward.  */
> +  if (loc_range->m_start.line > loc_range->m_finish.line)
> +   continue;
>  
>/* Passed all the tests; add the range to m_layout_ranges so
> that
>  it will be printed.  */
> 

Re: [PATCH] shrink-wrap: Once more PRs 67778, 68634, and now 68909

[Segher Boessenkool]

On Wed, Jan 06, 2016 at 06:36:19AM -0600, Segher Boessenkool wrote:
> This fixes this problem.  Tested on the 68909 testcase, and bootstrapped
> and regression checked on powerpc64-linux.  Is this okay for trunk?

Also tested on x86_64-linux now.


Segher


> 2016-01-06  Segher Boessenkool  
> 
>   PR rtl-optimization/67778
>   PR rtl-optimization/68634
>   PR rtl-optimization/68909
>   * shrink-wrap.c (try_shrink_wrapping): Add comment.  Don't pop
>   block from the stack until done with it.  Remove a superfluous
>   bitmap set.  Remove a superfluous bitmap test.

[openacc] fix unoptimized acc_on_device

[Nathan Sidwell]

I've committed this to trunk.  C++ needs a wrapper function to deal with the 
enumerated type argument.   Usually that's inlined, but when not optimizing we 
need to emit a definition of the wrapper.  That means marking it as an openacc 
routine.


nathan
2016-01-06  Nathan Sidwell  

	* openacc.c (acc_on_device): Add routine pragma for C++ wrapper.
	* testsuite/libgomp.oacc-c-c++-common/acc-on-device-2.c: New.

Index: openacc.h
===
--- openacc.h	(revision 232103)
+++ openacc.h	(working copy)
@@ -121,6 +121,7 @@ int acc_set_cuda_stream (int, void *) __
 
 /* Forwarding function with correctly typed arg.  */
 
+#pragma acc routine seq
 inline int acc_on_device (acc_device_t __arg) __GOACC_NOTHROW
 {
   return acc_on_device ((int) __arg);
Index: testsuite/libgomp.oacc-c-c++-common/acc-on-device-2.c
===
--- testsuite/libgomp.oacc-c-c++-common/acc-on-device-2.c	(revision 0)
+++ testsuite/libgomp.oacc-c-c++-common/acc-on-device-2.c	(working copy)
@@ -0,0 +1,23 @@
+/* { dg-additional-options "-O0" } */
+
+#include 
+
+/* acc_on_device might not be folded at -O0, but it should work. */
+
+int main ()
+{
+  int dev;
+  
+#pragma acc parallel copyout (dev)
+  {
+dev = acc_on_device (acc_device_not_host);
+  }
+
+  int expect = 1;
+  
+#if  ACC_DEVICE_TYPE_host
+  expect = 0;
+#endif
+  
+  return dev != expect;
+}

[wwwdocs] gcc-6/changes.html: diagnostics, Levenshtein, -Wmisleading-indentation, jit

[David Malcolm]

The attached patch adds information on various things to the
gcc-6/changes.html page:

* source-range-tracking (the patch merges the description of the string
location work into this, and updates the colorization of the example to
reflect gcc-6's behavior)
* fix-it hints
* hints for misspelled member names
* -Wmisleading-indentation
* jit improvements
* hints for misspelled command-line options

OK to commit?
Dave
Index: htdocs/gcc-6/changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-6/changes.html,v
retrieving revision 1.46
diff -u -p -r1.46 changes.html
--- htdocs/gcc-6/changes.html	22 Dec 2015 19:23:31 -	1.46
+++ htdocs/gcc-6/changes.html	6 Jan 2016 14:41:45 -
@@ -63,13 +63,40 @@ enum {
   oldval __attribute__ ((deprecated ("too old")))
 };
 
-Initial support for precise diagnostic locations within strings:
+Source locations for the C and C++ compilers are now tracked as ranges,
+  rather than just points, making it easier to identify the subexpression
+  of interest within a complicated expression.
+  For example:
 
-format-strings.c:3:14: warning: field width specifier '*' expects a matching 'int' argument [-Wformat=]
+test.cc: In function 'int test(int, int, foo, int, int)':
+test.cc:5:16: error: no match for 'operator*' (operand types are 'int' and 'foo')
+   return p + q * r * s + t;
+  ~~^~~
+
+In addition, there is now initial support for precise diagnostic locations
+within strings:
+
+format-strings.c:3:14: warning: field width specifier '*' expects a matching 'int' argument [-Wformat=]
printf("%*d");
-^
+^
 
-
+Diagnostics can now contain "fix-it hints", which are displayed
+  in context underneath the relevant source code.  For example:
+  
+
+fixits.c: In function 'bad_deref':
+fixits.c:11:13: error: 'ptr' is a pointer; did you mean to use '->'?
+   return ptr.x;
+ ^
+ ->
+
+The C and C++ compilers now offer suggestions for misspelled field names:
+
+spellcheck-fields.cc:52:13: error: 'struct s' has no member named 'colour'; did you mean 'color'?
+   return ptr-colour;
+   ^~
+
+
 New command-line options have been added for the C and C++ compilers:
   
 -Wshift-negative-value warns about left shifting a
@@ -89,8 +116,29 @@ enum {
   depends on the optimization options used.
 -Wduplicated-cond warns about duplicated conditions
 	  in an if-else-if chain.
+-Wmisleading-indentation warns about places where the
+  indentation of the code gives a misleading idea of the block
+  structure of the code to a human reader.  For example, given
+  https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-1266;>CVE-2014-1266:
+
+sslKeyExchange.c: In function 'SSLVerifySignedServerKeyExchange':
+sslKeyExchange.c:631:8: warning: statement is indented as if it were guarded by... [-Wmisleading-indentation]
+goto fail;
+^~~~
+sslKeyExchange.c:629:4: note: ...this 'if' clause, but it is not
+if ((err = SSLHashSHA1.update(, )) != 0)
+^~
+
+  This warning is enabled by -Wall.
   
 
+The C and C++ compilers now emit saner error messages if
+  merge-conflict markers are present in a source file.
+
+test.c:3:1: error: version control conflict marker in file
+ <<< HEAD
+ ^~~
+
   
 
 C
@@ -166,8 +214,18 @@ enum {
 
 
 
-
-
+libgccjit
+  
+The driver code is now run in-process within libgccjit,
+  providing a small speed-up of the compilation process.
+The API has gained entrypoints for
+  
+https://gcc.gnu.org/onlinedocs/jit/topics/performance.html;>timing how long was spent in different parts of code,
+https://gcc.gnu.org/onlinedocs/jit/topics/functions.html#gcc_jit_block_end_with_switch;>creating switch statements,
+https://gcc.gnu.org/onlinedocs/jit/topics/contexts.html#gcc_jit_context_set_bool_allow_unreachable_blocks;>allowing unreachable basic blocks in a function, and
+https://gcc.gnu.org/onlinedocs/jit/topics/contexts.html#gcc_jit_context_add_command_line_option;>adding arbitrary command-line options to a compilation.
+  
+  
 
 
 New Targets and Target Specific Improvements
@@ -389,6 +447,12 @@ enum {
 Other significant improvements
 
   
+The gcc and g++ driver programs will now
+  provide suggestions for misspelled command line options.
+
+$ gcc -static-libfortran test.f95
+gcc: error: unrecognized command line option '-static-libfortran'; did you mean '-static-libgfortran'?
+
 The --enable-default-pie configure option enables
 	generation of PIE by default.
   

Re: [PATCH, ARM] PR68674 Fix LTO support for neon builtin and error catching (ping)

[Kyrill Tkachov]

Hi Christian,

On 06/01/16 14:02, Christian Bruel wrote:

ping/respin https://gcc.gnu.org/ml/gcc-patches/2015-12/msg01095.html.

This patch fixes LTO for neon builtins defined with attribute target or in a 
pragma region.
It also fixes a few discrepancies due to the unavailability of the neon builtins and types at function startup. So we now set up the builtins even if not available in the current arch to allow the user to compile different fragments with 
target specific attributes. The check is done in arm_expand_builtin.


The discussed chunk around arm_vector_mode_supported_p is now obsolete since 
https://gcc.gnu.org/ml/gcc-patches/2015-12/msg01714.html.

I also changed the error messages as suggested by Ramana

New regression tests describing the different issues included. Tested with no 
new failures for arm-sim/\{,-mfpu=vfp,-mfpu=neon}{,-march=armv7-a\}.



Thanks for following up.
I'd like to do perform a bootstrap of this patch.
If you didn't run one already, I'll kick one off overnight.
The patch looks ok to me upon inspection and having looked deeper at the 
previous version,
but I'll take a closer look while waiting for the bootstrap to run.
Also, could you please add the appropriate PR entries in your changelog so that 
we can keep track of
which PRs are being solved.

Thanks,
Kyrill


regards,

Re: [PATCH, ARM] PR68674 Fix LTO support for neon builtin and error catching (ping)

[Kyrill Tkachov]

Hi Christian,

On 06/01/16 14:02, Christian Bruel wrote:

ping/respin https://gcc.gnu.org/ml/gcc-patches/2015-12/msg01095.html.

This patch fixes LTO for neon builtins defined with attribute target or in a 
pragma region.
It also fixes a few discrepancies due to the unavailability of the neon builtins and types at function startup. So we now set up the builtins even if not available in the current arch to allow the user to compile different fragments with 
target specific attributes. The check is done in arm_expand_builtin.


The discussed chunk around arm_vector_mode_supported_p is now obsolete since 
https://gcc.gnu.org/ml/gcc-patches/2015-12/msg01714.html.

I also changed the error messages as suggested by Ramana

New regression tests describing the different issues included. Tested with no 
new failures for arm-sim/\{,-mfpu=vfp,-mfpu=neon}{,-march=armv7-a\}.



In my testing the new testcase gives an error
about __ARM_NEON_FP being redefined. I think this has something to do with 
changing the the fpu state
using the target pragmas.
The locations it reports as the definition and redefinition of __ARM_NEON_FP is 
the final pop_options pragma in arm_neon.h
and the target pragma "neon" in the testcase.

My compiler is configured with --with-float=hard --with-cpu=cortex-a57 
--with-fpu=neon-fp-armv8.

Any idea?

Thanks,
Kyrill


regards,

[gomp4] 2 fortran tests

[Nathan Sidwell]

These two tests ICE unless -ftree-parallelize-loops is 1.

nathan
2016-01-06  Nathan Sidwell  

	* gfortran.dg/goacc/reduction-2.f95: Set ftree-parallize-loops to 1.
	* gfortran.dg/goacc/combined-directives.f90: Likewise.

Index: gfortran.dg/goacc/reduction-2.f95
===
--- gfortran.dg/goacc/reduction-2.f95	(revision 232084)
+++ gfortran.dg/goacc/reduction-2.f95	(working copy)
@@ -1,5 +1,5 @@
 ! { dg-do compile } 
-! { dg-additional-options "-fdump-tree-gimple" }
+! { dg-additional-options "-fdump-tree-gimple  -ftree-parallelize-loops=1" }
 
 subroutine foo ()
   implicit none
Index: gfortran.dg/goacc/combined-directives.f90
===
--- gfortran.dg/goacc/combined-directives.f90	(revision 232084)
+++ gfortran.dg/goacc/combined-directives.f90	(working copy)
@@ -1,7 +1,7 @@
 ! Exercise combined OpenACC directives.
 
 ! { dg-do compile }
-! { dg-options "-fopenacc -fdump-tree-gimple" }
+! { dg-options "-fopenacc -fdump-tree-gimple -ftree-parallelize-loops=1" }
 
 ! TODO
 ! Fix OMP_LIST_PRIVATE and OMP_LIST_REDUCTION splitting in

[PATCH, rs6000] Use lxvx and stxvx for 128-bit float, etc., with -mcpu=power9

[Bill Schmidt]

Hi,

I previously added POWER9 support for lxvx and stxvx to replace the
load-swap and swap-store patterns for POWER8.  However, I missed the
fact that we have different patterns for loads and stores of 128-bit
floats and other scalars.  This patch expands the previous POWER9
override to catch these cases, and disables those other patterns when P9
vector support is available.

Bootstrapped and tested on powerpc64le-unknown-linux-gnu with no
regressions.  Ok for trunk?

Thanks,
Bill


[gcc]

2015-01-06  Bill Schmidt  

* config/rs6000/vsx.md (*p9_vecload_): Replace VSX_M
mode iterator with VSX_M2.
(*p9_vecstore_): Likewise.
(*vsx_le_permute_): Restrict to !TARGET_P9_VECTOR.
(*vsx_le_perm_load_ for VSX_LE_128): Likewise.
(*vsx_le_perm_store_ for VSX_LE_128): Likewise.
(define_split for VSX_LE128 stores): Likewise.
(define_peephole2 for TImode LE swaps): Likewise.
(define_split for VSX_LE128 post-reload stores): Likewise.

[gcc/testsuite]

2015-01-06  Bill Schmidt  

* gcc.target/powerpc/p9-lxvx-stxvx-3.c: New test.


Index: gcc/config/rs6000/vsx.md
===
--- gcc/config/rs6000/vsx.md(revision 232077)
+++ gcc/config/rs6000/vsx.md(working copy)
@@ -304,8 +304,8 @@
 ;; VSX (P9) moves
 
 (define_insn "*p9_vecload_"
-  [(set (match_operand:VSX_M 0 "vsx_register_operand" "=")
-(match_operand:VSX_M 1 "memory_operand" "Z"))]
+  [(set (match_operand:VSX_M2 0 "vsx_register_operand" "=")
+(match_operand:VSX_M2 1 "memory_operand" "Z"))]
   "TARGET_P9_VECTOR"
   "lxvx %x0,%y1"
   [(set_attr "type" "vecload")
@@ -312,8 +312,8 @@
(set_attr "length" "4")])
 
 (define_insn "*p9_vecstore_"
-  [(set (match_operand:VSX_M 0 "memory_operand" "=Z")
-(match_operand:VSX_M 1 "vsx_register_operand" ""))]
+  [(set (match_operand:VSX_M2 0 "memory_operand" "=Z")
+(match_operand:VSX_M2 1 "vsx_register_operand" ""))]
   "TARGET_P9_VECTOR"
   "stxvx %x1,%y0"
   [(set_attr "type" "vecstore")
@@ -680,7 +680,7 @@
(rotate:VSX_LE_128
 (match_operand:VSX_LE_128 1 "input_operand" ",Z,")
 (const_int 64)))]
-  "!BYTES_BIG_ENDIAN && TARGET_VSX"
+  "!BYTES_BIG_ENDIAN && TARGET_VSX && !TARGET_P9_VECTOR"
   "@
xxpermdi %x0,%x1,%x1,2
lxvd2x %x0,%y1
@@ -714,9 +714,9 @@
 (define_insn_and_split "*vsx_le_perm_load_"
   [(set (match_operand:VSX_LE_128 0 "vsx_register_operand" "=")
 (match_operand:VSX_LE_128 1 "memory_operand" "Z"))]
-  "!BYTES_BIG_ENDIAN && TARGET_VSX"
+  "!BYTES_BIG_ENDIAN && TARGET_VSX && !TARGET_P9_VECTOR"
   "#"
-  "!BYTES_BIG_ENDIAN && TARGET_VSX"
+  "!BYTES_BIG_ENDIAN && TARGET_VSX && !TARGET_P9_VECTOR"
   [(set (match_dup 2)
(rotate:VSX_LE_128 (match_dup 1)
   (const_int 64)))
@@ -735,7 +735,7 @@
 (define_insn "*vsx_le_perm_store_"
   [(set (match_operand:VSX_LE_128 0 "memory_operand" "=Z")
 (match_operand:VSX_LE_128 1 "vsx_register_operand" "+"))]
-  "!BYTES_BIG_ENDIAN && TARGET_VSX"
+  "!BYTES_BIG_ENDIAN && TARGET_VSX && !TARGET_P9_VECTOR"
   "#"
   [(set_attr "type" "vecstore")
(set_attr "length" "12")])
@@ -743,7 +743,7 @@
 (define_split
   [(set (match_operand:VSX_LE_128 0 "memory_operand" "")
 (match_operand:VSX_LE_128 1 "vsx_register_operand" ""))]
-  "!BYTES_BIG_ENDIAN && TARGET_VSX && !reload_completed"
+  "!BYTES_BIG_ENDIAN && TARGET_VSX && !reload_completed && !TARGET_P9_VECTOR"
   [(set (match_dup 2)
(rotate:VSX_LE_128 (match_dup 1)
   (const_int 64)))
@@ -765,7 +765,7 @@
(set (match_operand:TI 2 "vsx_register_operand" "")
(rotate:TI (match_dup 0)
   (const_int 64)))]
-  "!BYTES_BIG_ENDIAN && TARGET_VSX && TARGET_VSX_TIMODE
+  "!BYTES_BIG_ENDIAN && TARGET_VSX && TARGET_VSX_TIMODE && !TARGET_P9_VECTOR
&& (rtx_equal_p (operands[0], operands[2])
|| peep2_reg_dead_p (2, operands[0]))"
[(set (match_dup 2) (match_dup 1))])
@@ -775,7 +775,7 @@
 (define_split
   [(set (match_operand:VSX_LE_128 0 "memory_operand" "")
 (match_operand:VSX_LE_128 1 "vsx_register_operand" ""))]
-  "!BYTES_BIG_ENDIAN && TARGET_VSX && reload_completed"
+  "!BYTES_BIG_ENDIAN && TARGET_VSX && reload_completed && !TARGET_P9_VECTOR"
   [(set (match_dup 1)
(rotate:VSX_LE_128 (match_dup 1)
   (const_int 64)))
Index: gcc/testsuite/gcc.target/powerpc/p9-lxvx-stxvx-3.c
===
--- gcc/testsuite/gcc.target/powerpc/p9-lxvx-stxvx-3.c  (revision 0)
+++ gcc/testsuite/gcc.target/powerpc/p9-lxvx-stxvx-3.c  (working copy)
@@ -0,0 +1,30 @@
+/* { dg-do compile { target { powerpc64le-*-* } } } */
+/* { dg-skip-if "do not override -mcpu" { powerpc*-*-* } { "-mcpu=*" } { 
"-mcpu=power9" } } */
+/* { dg-options "-mcpu=power9 -O3" } */
+/* { dg-final { scan-assembler "lxvx" } 

Re: [PATCH, rs6000] Use lxvx and stxvx for 128-bit float, etc., with -mcpu=power9

[David Edelsohn]

On Wed, Jan 6, 2016 at 1:34 PM, Bill Schmidt
 wrote:
> Hi,
>
> I previously added POWER9 support for lxvx and stxvx to replace the
> load-swap and swap-store patterns for POWER8.  However, I missed the
> fact that we have different patterns for loads and stores of 128-bit
> floats and other scalars.  This patch expands the previous POWER9
> override to catch these cases, and disables those other patterns when P9
> vector support is available.
>
> Bootstrapped and tested on powerpc64le-unknown-linux-gnu with no
> regressions.  Ok for trunk?
>
> Thanks,
> Bill
>
>
> [gcc]
>
> 2015-01-06  Bill Schmidt  
>
> * config/rs6000/vsx.md (*p9_vecload_): Replace VSX_M
> mode iterator with VSX_M2.
> (*p9_vecstore_): Likewise.
> (*vsx_le_permute_): Restrict to !TARGET_P9_VECTOR.
> (*vsx_le_perm_load_ for VSX_LE_128): Likewise.
> (*vsx_le_perm_store_ for VSX_LE_128): Likewise.
> (define_split for VSX_LE128 stores): Likewise.
> (define_peephole2 for TImode LE swaps): Likewise.
> (define_split for VSX_LE128 post-reload stores): Likewise.
>
> [gcc/testsuite]
>
> 2015-01-06  Bill Schmidt  
>
> * gcc.target/powerpc/p9-lxvx-stxvx-3.c: New test.

Okay.

Thanks, David

Re: [openacc] fix unoptimized acc_on_device

[Jakub Jelinek]

On Wed, Jan 06, 2016 at 10:48:52AM -0500, Nathan Sidwell wrote:
> I've committed this to trunk.  C++ needs a wrapper function to deal with the
> enumerated type argument.   Usually that's inlined, but when not optimizing
> we need to emit a definition of the wrapper.  That means marking it as an
> openacc routine.
> 
> nathan

> 2016-01-06  Nathan Sidwell  
> 
>   * openacc.c (acc_on_device): Add routine pragma for C++ wrapper.

s/\.c/\.h/

>   * testsuite/libgomp.oacc-c-c++-common/acc-on-device-2.c: New.

Otherwise LGTM.

Jakub

[ping] pending patches

[David Malcolm]

PR c++/68795: fix uninitialized close_paren_loc in
cp_parser_postfix_expression (v2):
  https://gcc.gnu.org/ml/gcc-patches/2015-12/msg01915.html


[PATCH 1/4] PR c++/62314: add fixit hint for missing "template <> " in
explicit specialization:
  https://gcc.gnu.org/ml/gcc-patches/2015-12/msg01933.html


[PATCH 2/4] PR c++/62314: add fixit hint for "expected ';' after class
definition:
  https://gcc.gnu.org/ml/gcc-patches/2015-12/msg01935.html


[PATCH 3/4] PR c++/62314: C++: add fixit hint to misspelled member
names:
  https://gcc.gnu.org/ml/gcc-patches/2015-12/msg01936.html


[PATCH 4/4] C: add fixit hint to misspelled field names:
  https://gcc.gnu.org/ml/gcc-patches/2015-12/msg01934.html


[PATCH] C++ FE: Show both locations in string literal concatenation
error:
  https://gcc.gnu.org/ml/gcc-patches/2015-12/msg01497.html



Thanks in advance
Dave

Re: [PATCH, ARM] PR68674 Fix LTO support for neon builtin and error catching (ping)

[Kyrill Tkachov]

On 06/01/16 17:13, Christian Bruel wrote:



On 01/06/2016 05:23 PM, Kyrill Tkachov wrote:

On 06/01/16 16:04, Kyrill Tkachov wrote:

Hi Christian,

On 06/01/16 14:02, Christian Bruel wrote:

ping/respin https://gcc.gnu.org/ml/gcc-patches/2015-12/msg01095.html.

This patch fixes LTO for neon builtins defined with attribute target or in a 
pragma region.
It also fixes a few discrepancies due to the unavailability of the neon 
builtins and types at function startup. So we now set up the builtins even if 
not available in the current arch to allow the user to compile different 
fragments with
target specific attributes. The check is done in arm_expand_builtin.

The discussed chunk around arm_vector_mode_supported_p is now obsolete since 
https://gcc.gnu.org/ml/gcc-patches/2015-12/msg01714.html.

I also changed the error messages as suggested by Ramana

New regression tests describing the different issues included. Tested with no 
new failures for arm-sim/\{,-mfpu=vfp,-mfpu=neon}{,-march=armv7-a\}.


In my testing the new testcase gives an error
about __ARM_NEON_FP being redefined. I think this has something to do with 
changing the the fpu state
using the target pragmas.
The locations it reports as the definition and redefinition of __ARM_NEON_FP is 
the final pop_options pragma in arm_neon.h
and the target pragma "neon" in the testcase.



humm, just tried with the command line -mfloat-abi=hard -mcpu=cortex-a57 
-mfpu=neon-fp-armv8 instead of the configure options. don't see this error on 
the new testcases, which one is it ?



The full command line for me is:
arm-none-eabi-gcc -fno-diagnostics-show-caret -fdiagnostics-color=never -flto 
-mfloat-abi=hard -c -specs=aprofile-validation.specs -Wa,-mno-warn-deprecated 
-o c_lto_pr65837-attr_0.o pr65837-attr_0.c

But, as I said, I have it configured in the way I mentioned earlier.


It seems that changing the arm_cpu_builtins code in arm-c.c to do:
cpp_undef (pfile, "__ARM_NEON_FP");
if (TARGET_NEON_FP)
  builtin_define_with_int_value ("__ARM_NEON_FP", TARGET_NEON_FP);

instead of:
if (TARGET_NEON_FP)
  builtin_define_with_int_value ("__ARM_NEON_FP", TARGET_NEON_FP);
else
  cpp_undef (pfile, "__ARM_NEON_FP");

fixes this. I guess we should be undefing any macros before redefining them.I


I don't know, If we are going from v7 to v8, the __ARM_NEON_FP value indeed 
changes. The question is whether we want to hide this to the user ?


Well, the user explicitly changed the fpu level with the pragma in the 
testcase, which rightly has the effect of
changing the value of some predefines. I don't think warning is appropriate 
here, as long as the predefine
has the right value in the right pragma scope.

Thanks,
Kyrill




If this is a warning with the test due to a contrived code, not the semantic of 
the macro definition. maybe just add a dg-prune or -Wp,-w in the test ?




Kyrill


My compiler is configured with --with-float=hard --with-cpu=cortex-a57 
--with-fpu=neon-fp-armv8.

Any idea?

Thanks,
Kyrill


regards,

Re: [PATCH] c/68966 - atomic_fetch_* on atomic_bool not diagnosed

[Mike Stump]

On Jan 6, 2016, at 3:38 PM, Martin Sebor  wrote:
>>> gcc/testsuite/ChangeLog:
>>> 2016-01-04  Martin Sebor  
>>> 
>>> PR c/68966
>>> * gcc.dg/atomic-fetch-bool.c: New test.
>>> * gcc.dg/sync-fetch-bool.c: Same.
>> 
>> So the tradition is to repeat "New test." rather than to say "Same."
> 
> Can we try not to make the rules any more rigid than they need
> to be?  As we just discussed, following the required formatting
> rules is error-prone and time-consuming enough.  GCC's own
> Coding Conventions doesn't even require ChangeLog entries for
> new tests (https://gcc.gnu.org/codingconventions.html#ChangeLogs).
> People have been adding them and that's just fine with me, but
> I can't discern any established convention when it comes to the
> comment when a new test is being added.  I see examples of "New
> test" or "New file" followed by "Likewise" or "Ditto" as well
> as "New test" followed by "Same". I see no point in adding yet
> another hoop for people to have to remember to jump through.

And I thought it was Likewise.  :-)

$ grep Same *ChangeLog* | wc -l
3938
$ grep Likewise *ChangeLog* | wc -l
   69444

Re: [CilkPlus] fix issues when cilk_spawn is used with nontrivial expressions

[Mike Stump]

On Jan 6, 2016, at 12:11 PM, Ryan Burn  wrote:
> I could additionally check that the language is c++ before checking
> those flags,

Please, no.  Objective-C++ isn’t C++ and the string that names the language 
won’t strcmp with the name of the C++ language.

Re: [gomp4] kernels offload fns

[Cesar Philippidis]

On 12/29/2015 06:19 AM, Nathan Sidwell wrote:

> @@ -19385,7 +19415,7 @@ new_oacc_loop_routine (oacc_loop *parent
>  {
>oacc_loop *loop = new_oacc_loop_raw (parent, gimple_location (call));
>int dims[GOMP_DIM_MAX];
> -  int level = oacc_validate_dims (decl, attrs, dims);
> +  int level = oacc_fn_attrib_level (attrs);

dims is dead and that's causing a bootstrap failure. I've applied this
patch to gomp-4_0-branch to fix it.

Cesar
2016-01-06  Cesar Philippidis  

	gcc/
	* omp-low.c (new_oacc_loop_routine): Remove stale dims variable.


diff --git a/gcc/omp-low.c b/gcc/omp-low.c
index e11cefc..55b5da3 100644
--- a/gcc/omp-low.c
+++ b/gcc/omp-low.c
@@ -19454,7 +19454,6 @@ static void
 new_oacc_loop_routine (oacc_loop *parent, gcall *call, tree decl, tree attrs)
 {
   oacc_loop *loop = new_oacc_loop_raw (parent, gimple_location (call));
-  int dims[GOMP_DIM_MAX];
   int level = oacc_fn_attrib_level (attrs);
 
   gcc_assert (level >= 0);

Re: [PATCH], PowerPC IEEE 128-bit fp, #11-rev2 (enable libgcc conversions)

[Michael Meissner]

I have reworked the libgcc library interface that was in my original patch
#11.  There are 2 attachments, the first attachment is for patches in the gcc
space, and the second attachment is for the libgcc changes.

I added the conversions between IBM extended double and IEEE 128-bit floating
point to the code that is built for emulation support (using the KF functions)
and code that enables ISA 3.0 (power9) support using direct instructions.
Unfortunately, I discovered some problems with the builtins to pack and unpack
IBM extended double that only show up with -mcpu=power9.  So, I fixed the code
generation problem (involving & constraints and multi-register data types on
little endian systems) to generate correct code.  While I was modifying the
pack and unpack routines, I added support to allow pack to read values from
memory and use the upper registers.  I tightened up the iterators to not allow
TFmode if long double is IEEE 128-bit floating point.  In looking towards the
day when long double is IEEE 128-bit floating point, I also added builtins to
take/return explict __ibm128 instead of long double.

In terms of the libgcc library functions:

1)  I removed the extra clean rule, modifying Makefile.in.  Now the only
changes are to the toplevel configuration files and within the
config/rs6000 subdirectory.

2)  I removed creating ifunc descriptors for the 4 functions that convert
between signed/unsigned __int128 and __float128 since at present we
don't have specific ISA 3.0 code for these conversions (suggestion from
Joseph Myers).

3)  I modified the ISA 3.0 version of the comparison functions, to simplify
the code somewhat based on suggestions from Joseph Myers.

4)  I used __getauxval instead of getauxval in ifunc module.  Ideally, we
will soon have __builtin_cpu_supports to directly test if the machine
has hardware IEEE 128-bit floating point.

5)  I put the exception handling code under #ifndef _SOFT_FLOAT control so
that the 32-bit PowerPC machines that don't have hardware floating
point will not use this code (the exception handling uses hardware
instructions to cause a particular fault).

6)  In looking at the exception handling, I tweaked the asm code somewhat
to have an explicit target.

7)  As I mentioned above, I made the conversion between IFmode and KFmode
have IEEE 128-bit emulation and IEEE 128-bit hardware support
versions.  I modified it to use __builtin_unpack_ibm128 and
__builtin_pack_ibm128.

I have done bootstrap builds on a big endian Power7 and a little endian Power8
machine with no regressions.  Are these patches ok to install in the trunk?

[gcc]
2016-01-06  Michael Meissner  

* config/rs6000/rs6000-builtin.def (BU_FLOAT128_2): Add support
for pack/unpack functions for __ibm128.
(PACK_IF): Likewise.
(UNPACK_IF): Likewise.

* config/rs6000/rs6000.c (rs6000_builtin_mask_calculate): Add
support for __ibm128 pack/unpack functions.
(rs6000_invalid_builtin): Likewise.
(rs6000_init_builtins): Likewise.
(rs6000_opt_masks): Likewise.

* config/rs6000/rs6000.h (MASK_FLOAT128): Add short name.
(RS6000_BTM_FLOAT128): Add support for __ibm128 pack/unpack
functions
(RS6000_BTM_COMMON): Likewise.

* config/rs6000/rs6000.md (f128_vsx): New mode attribute.
(unpack): Use FMOVE128_FPR iterator instead of FMOVE128, to
disallow __builtin_{pack,unpack}_longdouble if long double is IEEE
128-bit floating point.  Add support for the double values to be
in Altivec registers for TF/IF packing and unpacking, but restrict
TD packing sub-fields to be FPR registers.  Don't allow overlapped
register support for packing.  Allow pack inputs to be memory
locations.  Don't build generator functions for unpack_dm
and unpack_nodm.
(unpack_dm): Likewise.
(unpack_nodm): Likewise.
(pack): Likewise.

* config/rs6000/rs6000-builtin.def (__builtin_pack_ibm128): Add
built-in functions to pack/unpack explicit __ibm128 values.
(__builtin_unpack_ibm128): Likewise.

* doc/extend.texi (PowerPC Built-in Functions): Document
__builtin_pack_ibm128 and __builtin_unpack_ibm128.

[libgcc]
2016-01-06  Michael Meissner  
Steven Munroe (munro...@linux.vnet.ibm.com)
Tulio Magno Quites Machado Filho 

* config/rs6000/floattikf.c: New files for IEEE 128-bit floating
point conversions.
* config/rs6000/floatuntikf.c: Likewise.
* config/rs6000/fixkfti.c: Likewise.
* config/rs6000/fixunskfti.c: Likewise.
* config/rs6000/extendkftf2-sw.c: Likewise.
* config/rs6000/trunctfkf2-sw.c: Likewise.

* 

Re: [Patch] Fix libstdc++ build when using uclibc instead of glibc

[Jonathan Wakely]

On 06/01/16 12:45 -0800, Steve Ellcey wrote:

On Wed, 2016-01-06 at 20:34 +, Jonathan Wakely wrote:

On 05/01/16 14:43 -0800, Steve Ellcey  wrote:
>While trying to build GCC with uclibc instead of glibc I ran into a build
>failure in libstdc++.  uclibc doesn't seem to provide the isfinite function
>like glibc does so that means that libstdc++ doesn't have std::isfinite.
>
>This in turn caused include/ext/random.tcc to not compile because it uses
>std::isfinite.  I can easily see how this might be considered a uclibc
>bug but given that it is the only build problem I ran into I was hoping
>we could fix it in libstdc++ by using __builtin_finite instead of

Shouldn't that be __builtin_isfinite not __builtin_finite ?


You are right.  For some reason I thought that isfinite was implemented
as __builtin_finite and that there was no __builtin_isfinite.  I am not
sure why I thought that but it does not seem to be the case.  I will
update my patch, retest, and resubmit.


Thanks.

Regarding the substance of the patch, the usual approach would be to
gate the relevant parts of  (or even the whole thing) on the
presence of std::isinfinite, but that would presumably disable the
 functionality completely for uclibc. If using the builtin
works reliably then I'm OK with that.

However, I would expect that for un-optimized code the builtin will
just emit a call to isfinite() in the C library, and so if uclibc
doesn't define that at all then that will result in a linker error.

If uclibc does define that function then we should figure out why
libstdc++ fails to see it, and see if we can fix that, so that
std::isfinite() gets declared and the existing code in  starts
working.

i.e. I'd like to be sure there isn't some deeper underlying problem
that should be addressed, rather than just working around it.

Re: [PATCH] c/68966 - atomic_fetch_* on atomic_bool not diagnosed

[Martin Sebor]

gcc/testsuite/ChangeLog:
2016-01-04  Martin Sebor  

PR c/68966
* gcc.dg/atomic-fetch-bool.c: New test.
* gcc.dg/sync-fetch-bool.c: Same.


So the tradition is to repeat "New test." rather than to say "Same."


Can we try not to make the rules any more rigid than they need
to be?  As we just discussed, following the required formatting
rules is error-prone and time-consuming enough.  GCC's own
Coding Conventions doesn't even require ChangeLog entries for
new tests (https://gcc.gnu.org/codingconventions.html#ChangeLogs).
People have been adding them and that's just fine with me, but
I can't discern any established convention when it comes to the
comment when a new test is being added.  I see examples of "New
test" or "New file" followed by "Likewise" or "Ditto" as well
as "New test" followed by "Same". I see no point in adding yet
another hoop for people to have to remember to jump through.

Thanks
Martin



Otherwise ok, thanks.

Marek

[PATCH, rs6000] Handle vector reductions in swap optimization

[Bill Schmidt]

Hi,

Swap optimization is missing some opportunities when vector reductions
are present.  This patch adds logic to recognize vector-reduction
patterns and mark them as swappable.  Some of these are very easy to
recognize, given the presence of a specific unspec.  For V2DF
reductions, we have to recognize a specific somewhat complex pattern.

I've added test cases to verify swap optimization works correctly on
reductions for V2DF and V4SF.

Bootstrapped and tested on powerpc64le-unknown-linux-gnu with no
regressions.  Is this ok for trunk?  I would also like to backport this
to GCC 5 after a settling period.

Thanks,
Bill


[gcc]

2016-01-06  Bill Schmidt  

* config/rs6000/rs6000.c (v2df_reduction_p): New function.
(rtx_is_swappable_p): Reductions are swappable.
(insn_is_swappable_p): V2DF reductions are swappable.

[gcc/testsuite]

2016-01-06  Bill Schmidt  

* gcc.target/powerpc/swaps-p8-23.c: New test.
* gcc.target/powerpc/swaps-p8-24.c: Likewise.


Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c  (revision 232109)
+++ gcc/config/rs6000/rs6000.c  (working copy)
@@ -36648,6 +36648,44 @@ const_load_sequence_p (swap_web_entry *insn_entry,
   return true;
 }
 
+/* Return TRUE iff OP matches a V2DF reduction pattern.  See the
+   definition of vsx_reduc__v2df in vsx.md.  */
+static bool
+v2df_reduction_p (rtx op)
+{
+  if (GET_MODE (op) != V2DFmode)
+return false;
+  
+  enum rtx_code code = GET_CODE (op);
+  if (code != PLUS && code != SMIN && code != SMAX)
+return false;
+
+  rtx concat = XEXP (op, 0);
+  if (GET_CODE (concat) != VEC_CONCAT)
+return false;
+
+  rtx select0 = XEXP (concat, 0);
+  rtx select1 = XEXP (concat, 1);
+  if (GET_CODE (select0) != VEC_SELECT || GET_CODE (select1) != VEC_SELECT)
+return false;
+
+  rtx reg0 = XEXP (select0, 0);
+  rtx reg1 = XEXP (select1, 0);
+  if (!rtx_equal_p (reg0, reg1) || !REG_P (reg0))
+return false;
+
+  rtx parallel0 = XEXP (select0, 1);
+  rtx parallel1 = XEXP (select1, 1);
+  if (GET_CODE (parallel0) != PARALLEL || GET_CODE (parallel1) != PARALLEL)
+return false;
+
+  if (!rtx_equal_p (XVECEXP (parallel0, 0, 0), const1_rtx)
+  || !rtx_equal_p (XVECEXP (parallel1, 0, 0), const0_rtx))
+return false;
+
+  return true;
+}
+
 /* Return 1 iff OP is an operand that will not be affected by having
vector doublewords swapped in memory.  */
 static unsigned int
@@ -36719,6 +36757,8 @@ rtx_is_swappable_p (rtx op, unsigned int *special)
  *special = SH_XXPERMDI;
  return 1;
}
+  else if (v2df_reduction_p (op))
+   return 1;
   else
return 0;
 
@@ -36783,6 +36823,9 @@ rtx_is_swappable_p (rtx op, unsigned int *special)
  case UNSPEC_VSPLT_DIRECT:
*special = SH_SPLAT;
return 1;
+ case UNSPEC_REDUC_PLUS:
+ case UNSPEC_REDUC:
+   return 1;
  }
   }
 
@@ -36907,6 +36950,15 @@ insn_is_swappable_p (swap_web_entry *insn_entry, r
   return 1;
 }
 
+  /* V2DF reductions are always swappable.  */
+  if (GET_CODE (body) == PARALLEL)
+{
+  rtx expr = XVECEXP (body, 0, 0);
+  if (GET_CODE (expr) == SET
+ && v2df_reduction_p (SET_SRC (expr)))
+   return 1;
+}
+
   /* An UNSPEC_VPERM is ok if the mask operand is loaded from the
  constant pool.  */
   if (GET_CODE (body) == SET
Index: gcc/testsuite/gcc.target/powerpc/swaps-p8-23.c
===
--- gcc/testsuite/gcc.target/powerpc/swaps-p8-23.c  (revision 0)
+++ gcc/testsuite/gcc.target/powerpc/swaps-p8-23.c  (working copy)
@@ -0,0 +1,26 @@
+/* { dg-do compile { target { powerpc64le-*-* } } } */
+/* { dg-skip-if "do not override -mcpu" { powerpc*-*-* } { "-mcpu=*" } { 
"-mcpu=power8" } } */
+/* { dg-options "-mcpu=power8 -O3 -ffast-math" } */
+/* { dg-final { scan-assembler "lxvd2x" } } */
+/* { dg-final { scan-assembler-not "xxpermdi" } } */
+
+/* Verify that swap optimization works correctly in the presence of
+   a V2DFmode reduction.  */
+
+extern double optvalue;
+extern void obfuscate (double, unsigned int);
+
+void
+foo (double *x, double *y, unsigned int n, unsigned int m)
+{
+  unsigned int i, j;
+  double sacc;
+  for (j = 0; j < m; ++j)
+{
+  sacc = 0.0;
+  for (i = 0; i < n; ++i)
+   sacc += x[i] * y[i];
+  obfuscate (sacc, n);
+}
+  optvalue = n * 2.0 * m;
+}
Index: gcc/testsuite/gcc.target/powerpc/swaps-p8-24.c
===
--- gcc/testsuite/gcc.target/powerpc/swaps-p8-24.c  (revision 0)
+++ gcc/testsuite/gcc.target/powerpc/swaps-p8-24.c  (working copy)
@@ -0,0 +1,26 @@
+/* { dg-do compile { target { powerpc64le-*-* } } } */
+/* { dg-skip-if "do not override -mcpu" { powerpc*-*-* } { "-mcpu=*" } { 

Re: [PATCH, i386]: Fix PR69140, stack alignment + O1 breaks with Microsoft ABI

[Eric Botcazou]

> Patch was bootstrapped and regression tested on x86_64-linux-gnu for
> all default languages, Obj-C++ and Go. The patch was also tested by
> the reporter by building and running Wine without problems.
> 
> I have to admit that prologue generation is hard to test, since it has
> many different code paths. I guess committing the one-liner in the
> hope that it won't break some target is the best approach one can do.

Thanks for devising the fix!

-- 
Eric Botcazou

Re: [PATCH] Fix PR66848 by enforcing 16-bit alignment on darwin

[Jack Howarth]

Hans,
  You can find some complete walks in lldb for the failing
boehm-gc test cases on darwin15 attached to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66848 as well as
stand-alone binaries for reproducing their failure on
x86_64-apple-darwin15 (should you have access to a Mac running El
Capitan).  The developers at Apple identified...

http://llvm.org/viewvc/llvm-project?view=revision=226751

as the change in llvm which sensitized Apple's libunwind.dylib to the
apparently latent boehm-gc bug. My limited understanding of the bug is
that the latent bug is a 16-bit alignment issue being exposed on
darwin since the failing test cases seem to go through...

libdyld.dylib`stack_not_16_byte_aligned_error

during the walks in lldb. I assumed that the use of ALIGNMENT 2 was
forcing the 16-bit alignment and suppressing the bug in current gcc's
boehm-gc.
 Jack



On Fri, Jan 1, 2016 at 1:28 PM, Hans Boehm  wrote:
> [Adding Ivan, the current bdwgc maintainer.]
>
> I don't fully understand the issue here.  Do we understand where the problem
> is coming from?  Are the compiler/linker generating misaligned pointers
> someplace?  That would strike me as a misfeature elsewhere.
>
> Setting ALIGNMENT to 2, as in the patch, is a pretty big hammer.  It causes
> the gc to look for pointers at every 2 byte offset, quadrupling the number
> of potential pointers that are tested, and significantly increasing the risk
> of finding "false" pointers.  I would expect more problems caused by large
> block allocations.
>
> Hans
>
> On Mon, Dec 28, 2015 at 1:44 PM, Mike Stump  wrote:
>>
>> On Dec 22, 2015, at 9:08 AM, Jack Howarth 
>> wrote:
>> > This bug doesn't exist in the more recent boehm-gc 7.2 or
>> > later releases. Until the exact change from 6.6 to 7.2 that suppresses
>> > this bug is identified or FSF gcc's boehm-gc is rebased on the 7.2
>> > version or later, the simple fix to suppress this issue on darwin is
>> > to enforce 16-bit alignment in boehm-gc/include/private/gcconfig.h for
>> > that target.
>>
>> It would be nice to just pull in 7.2 (or just the latest release)…  seems
>> like that should be easier to maintain to me.
>>
>> > Okay for gcc trunk and back ports to gcc-5-branch and gcc-4_9-branch?
>>
>> I’d like to punt the approval to a libboehm person, though, not sure we
>> have any.  Just checked we don’t have an official maintainer listed.  :-(
>> Do we have anybody that wants to review the patch or should I?  Though I
>> would prefer a new import of a newer library to fix the issue, I’m tempted
>> to just approve the patch.  Kinda don’t want to as any deviation makes
>> importing a new library annoying.  What do others think?
>
>

Re: [PATCH, rs6000] Handle vector reductions in swap optimization

[David Edelsohn]

On Wed, Jan 6, 2016 at 5:37 PM, Bill Schmidt
 wrote:
> Hi,
>
> Swap optimization is missing some opportunities when vector reductions
> are present.  This patch adds logic to recognize vector-reduction
> patterns and mark them as swappable.  Some of these are very easy to
> recognize, given the presence of a specific unspec.  For V2DF
> reductions, we have to recognize a specific somewhat complex pattern.
>
> I've added test cases to verify swap optimization works correctly on
> reductions for V2DF and V4SF.
>
> Bootstrapped and tested on powerpc64le-unknown-linux-gnu with no
> regressions.  Is this ok for trunk?  I would also like to backport this
> to GCC 5 after a settling period.
>
> Thanks,
> Bill
>
>
> [gcc]
>
> 2016-01-06  Bill Schmidt  
>
> * config/rs6000/rs6000.c (v2df_reduction_p): New function.
> (rtx_is_swappable_p): Reductions are swappable.
> (insn_is_swappable_p): V2DF reductions are swappable.
>
> [gcc/testsuite]
>
> 2016-01-06  Bill Schmidt  
>
> * gcc.target/powerpc/swaps-p8-23.c: New test.
> * gcc.target/powerpc/swaps-p8-24.c: Likewise.

This is okay for trunk, but not for GCC 5 branch because this is not a bug fix.

Thanks, David

[gomp4] private reductions

[Cesar Philippidis]

This patch updates the way that private reductions are handled in gomp4
to be more like trunk. Before, omp lower was using a complicated mapping
for private variables, but now it's treating them more like omp, with
the exception of reference-type variables. This complication originated
back when we were using ganglocal memory for private variables. Now that
private variables just regular local variables, I was able to remove a
lot of that old code.

It should be noted that reference-type variables still rely on
gimplifier creating a special OMP_CLAUSE_REDUCTION_PRIVATE_DECL, which
is basically a local copy of the reduction variable. Currently this is
used when the reduction variables are dummy arguments in fortran or
parallel (non-loop) reductions. I want to get rid of the
localize_reductions pass from the gimplifier eventually, but for the
time being this patch does fix pr/68813.

In the process of removing removing that old private code, I noticed
that lower_oacc_reductions couldn't handle reductions of the form

  #pragma acc loop reduction (+:v)
  for (...)
#pragma acc loop reduction (+:v)
 for (...)

That's fixed now. In addition to teaching lower_oacc_reductions about
private variables, I also taught it how to update any intermediate
reduction variable when present. I'll port over this change to trunk
once I've resolved the localize_reductions issue in the gimplifier.

I don't have recent baseline, but I am seeing these failures:

  g++.sum:c-c++-common/goacc/routine-7.c
  libgomp.oacc-c/../libgomp.oacc-c-c++-common/declare-4.c

I'll work on routine-7.c tomorrow. Jim, can you look at the declare-4.c
failure?

This patch has been applied to gomp-4_0-branch.

Cesar
2016-01-06  Cesar Philippidis  

	PR other/68813

	gcc/
	* omp-low.c (is_oacc_reduction_private): Delete.
	(build_outer_var_ref): Remove special handling for private reductions
	in openacc.
	(scan_sharing_clauses): Likewise.
	(lower_rec_input_clauses): Likewise.
	(lower_oacc_reductions): Update support for private reductions.

	libgomp/
	* testsuite/libgomp.oacc-fortran/pr68813.f90: New test.
	* testsuite/libgomp.oacc-fortran/reduction-7.f90: New test.


diff --git a/gcc/omp-low.c b/gcc/omp-low.c
index 8a6dc5e..e11cefc 100644
--- a/gcc/omp-low.c
+++ b/gcc/omp-low.c
@@ -316,53 +316,6 @@ is_oacc_kernels (omp_context *ctx)
 	  == GF_OMP_TARGET_KIND_OACC_KERNELS));
 }
 
-/* Return true if VAR is a is private reduction variable.  A reduction
-   variable is considered private if the variable is local to the
-   offloaded region, or if it is the first reduction to use a mapped
-   variable.  E.g., if V is mapped as 'copy', and loops L1 and L2 contain
-   reductions on V, and L2 is nested inside L1, V is not private in L1
-   but is private in L2.  */
-
-static bool
-is_oacc_reduction_private (tree var, omp_context *ctx, bool initial = true)
-{
-  tree c, clauses, decl;
-
-  if (ctx == NULL || !is_gimple_omp_oacc (ctx->stmt))
-return true;
-
-  if (gimple_code (ctx->stmt) == GIMPLE_OMP_FOR)
-clauses = gimple_omp_for_clauses (ctx->stmt);
-  else
-clauses = gimple_omp_target_clauses (ctx->stmt);
-
-  for (c = clauses; c; c = OMP_CLAUSE_CHAIN (c))
-{
-  switch (OMP_CLAUSE_CODE (c))
-	{
-	case OMP_CLAUSE_PRIVATE:
-	  decl = OMP_CLAUSE_DECL (c);
-	  if (decl == var)
-	return true;
-	  break;
-	case OMP_CLAUSE_MAP:
-	  decl = OMP_CLAUSE_DECL (c);
-	  if (decl == var)
-	return false;
-	  break;
-	case OMP_CLAUSE_REDUCTION:
-	  decl = OMP_CLAUSE_DECL (c);
-	  if (!initial && decl == var)
-	return true;
-	  break;
-	default:
-	  break;
-	}
-}
-
-  return is_oacc_reduction_private (var, ctx->outer, false);
-}
-
 /* If DECL is the artificial dummy VAR_DECL created for non-static
data member privatization, return the underlying "this" parameter,
otherwise return NULL.  */
@@ -1323,14 +1276,8 @@ static tree
 build_outer_var_ref (tree var, omp_context *ctx, bool lastprivate = false)
 {
   tree x;
-  tree outer_ref = maybe_lookup_decl_in_outer_ctx (var, ctx);
 
-  if (TREE_CODE (outer_ref) == INDIRECT_REF)
-{
-  gcc_assert (is_gimple_omp_oacc (ctx->stmt));
-  x = outer_ref;
-}
-  else if (is_global_var (outer_ref))
+  if (is_global_var (maybe_lookup_decl_in_outer_ctx (var, ctx)))
 x = var;
   else if (is_variable_sized (var))
 {
@@ -1384,26 +1331,9 @@ build_outer_var_ref (tree var, omp_context *ctx, bool lastprivate = false)
 	x = build_simple_mem_ref (x);
 	}
 }
-  else if (is_oacc_parallel (ctx))
-x = var;
   else if (ctx->outer)
-{
-  /* OpenACC may have multiple outer contexts (one per loop).  */
-  if (gimple_code (ctx->stmt) == GIMPLE_OMP_FOR
-	  && gimple_omp_for_kind (ctx->stmt) == GF_OMP_FOR_KIND_OACC_LOOP)
-	{
-	  do
-	{
-	  ctx = ctx->outer;
-	  x = maybe_lookup_decl (var, ctx);
-	}
-	  while(!x);
-	}
-  else
-	x = lookup_decl (var, ctx->outer);
-}
-  else if (is_reference (var)
-	   || 

[patch, nvptx] document "kernel" function attribute

[Sandra Loosemore]

I've been trying to fill in missing documentation for target-specific 
attributes.  I'm not 100% sure I've got this one correct.  OK to commit?


-Sandra

2016-01-06  Sandra Loosemore 

	PR 1078
	gcc/
	* doc/extend.texi (Nvidia PDX Function Attributes): New section.
Index: gcc/doc/extend.texi
===
--- gcc/doc/extend.texi	(revision 232092)
+++ gcc/doc/extend.texi	(working copy)
@@ -2271,6 +2271,7 @@ GCC plugins may provide their own attrib
 * MSP430 Function Attributes::
 * NDS32 Function Attributes::
 * Nios II Function Attributes::
+* Nvidia PTX Function Attributes::
 * PowerPC Function Attributes::
 * RL78 Function Attributes::
 * RX Function Attributes::
@@ -4633,6 +4634,23 @@ named @var{name}.
 @end table
 @end table
 
+@node Nvidia PTX Function Attributes
+@subsection Nvidia PTX Function Attributes
+
+These function attributes are supported by the Nvidia PTX back end:
+
+@table @code
+@item kernel
+@cindex @code{kernel} attribute, Nvidia PTX
+This attribute indicates that the corresponding function should be compiled
+as a kernel function, which is callable by host code.  
+By default, functions are compiled as device functions instead, 
+which are callable only by other device code.
+
+Kernel functions must have @code{void} return type.
+@end table
+
+
 @node PowerPC Function Attributes
 @subsection PowerPC Function Attributes
 

RE: Fix 61441 [5/5] Disable various transformations for signaling NaN operands

[Saraswati, Sujoy (OSTL)]

Hi,

> On Thu, Nov 26, 2015 at 08:38:55AM +, Saraswati, Sujoy (OSTL) wrote:
> > PR tree-optimization/61441
> > * gcc.dg/pr61441.c: New testcase.
> 
> Note the testcase fails on i686-linux, and even -fexcess-precision=standard
> doesn't help (-ffloat-store works, but that is a big hammer and we really
> don't want it for targets without excess precision).
> At least with -fexcess-precision=standard, the problem is in the fabs case,
> with -fexcess-precision=standard the value is then rounded from long
> double to double and that rounding affects the signalling bit.
> So, either the testcase should be compiled with -fexcess-precision=standard
> and the operation(Abs) case be guarded with #if __FLT_EVAL_METHOD__
> == 0, or something similar.

I modified the test case as below -

Index: testsuite/gcc.dg/pr61441.c
===
--- testsuite/gcc.dg/pr61441.c  (revision 232121)
+++ testsuite/gcc.dg/pr61441.c  (working copy)
@@ -1,5 +1,5 @@
 /* { dg-do run } */
-/* { dg-options "-O1 -lm" } */
+/* { dg-options "-O1 -lm -fexcess-precision=standard" } */

 #define _GNU_SOURCE
 #include 
@@ -56,6 +56,8 @@ int main (void)
   operation(Add);
   operation(Mult);
   operation(Div);
+#if __FLT_EVAL_METHOD__ == 0
   operation(Abs);
+#endif
   return 0;
 }

However, I do not have access to a i686-linux box to test it out. Let me know 
if this looks fine.

I did a search on the https://gcc.gnu.org/ml/gcc-testresults/2015-12/ but 
couldn't see a failure report for this - is there place where I could look up 
to see the test results for various architectures ?

There was another issue reported on 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61441, where the test fails on 
arm-none-eabi with unresolved symbol for issignaling(). Apparently, the 
newlib's math.h doesn't have the issignaling macro - let me know if I need to 
modify the test case to take care of this.

Regards,
Sujoy 

Re: [PATCH, testsuite] Fix g++.dg/pr67989.C test failure when running with -march or -mcpu

[Thomas Preud'homme]

On Tuesday, January 05, 2016 10:47:38 AM Kyrill Tkachov wrote:
> Hi Thomas,

Hi Kyrill,

> > 
> > diff --git a/gcc/testsuite/g++.dg/pr67989.C
> > b/gcc/testsuite/g++.dg/pr67989.C index
> > 90261c450b4b9429fb989f7df62f3743017c7363..61be8e172a96df5bb76f7ecd8543dadf
> > 825e7dc7 100644
> > --- a/gcc/testsuite/g++.dg/pr67989.C
> > +++ b/gcc/testsuite/g++.dg/pr67989.C
> > @@ -1,5 +1,6 @@
> > 
> >   /* { dg-do compile } */
> >   /* { dg-options "-std=c++11 -O2" } */
> > 
> > +/* { dg-skip-if "do not override -mcpu" { arm*-*-* } { "-march=*"
> > "-mcpu=*" } { "-march=armv4t" } } */
> > 
> >   /* { dg-additional-options "-marm -march=armv4t" { target arm*-*-* } }
> >   */
> 
> How about we try to do it using the add_options_for_arm_arch_v4t machinery
> and the arm_arch_v4t_ok check?

I don't quite understand. dg-add-options doesn't take a selector according to 
GCC internals documentation and dg-additional-options doesn't take feature. If 
I use dg-add-options with a require-effective-target that will limit this test 
to ARM.

Did I misunderstand your point?

Best regards,

Thomas

[testsuite] Skip gcc.target/sparc/20151219-1.c in 64-bit mode

[Eric Botcazou]

The test doesn't really make sense in 64-bit mode.

Applied on the mainline.


2016-01-06  Eric Botcazou  

* gcc.target/sparc/20151219-1.c: Skip in 64-bit mode.

-- 
Eric BotcazouIndex: gcc.target/sparc/20151219-1.c
===
--- gcc.target/sparc/20151219-1.c	(revision 232097)
+++ gcc.target/sparc/20151219-1.c	(working copy)
@@ -2,6 +2,7 @@
 /* Reported by Sebastian Huber  */
 
 /* { dg-do compile } */
+/* { dg-require-effective-target ilp32 } */
 /* { dg-options "-O2 -mtune=supersparc" } */
 
 typedef unsigned int size_t;

Re: [PATCH 2/2] PR c++/68819: libcpp fallbacks and -Wmisleading-indentation

[David Malcolm]

On Mon, 2015-12-21 at 22:20 +0100, Jakub Jelinek wrote:
> On Mon, Dec 21, 2015 at 02:10:17PM -0700, Jeff Law wrote:
> > On 12/18/2015 01:21 PM, David Malcolm wrote:
> > 
> > >I don't think there's a way to fix -Wmisleading-indentation if we're
> > >in this state, so the first part of the following patch detects if
> > >this has happened, and effectively turns off -Wmisleading-indentation
> > >from that point onwards.  To avoid a false sense of security, the
> > >patch issues a "sorry" at the that point, currently with this wording:
> > >location-overflow-test-1.c:17:0: sorry, unimplemented: 
> > >-Wmisleading-indentation is disabled from this point onwards, since 
> > >column-tracking was disabled due to the size of the code/headers
> > Seems reasonable.  I can't see any way to get indentation warnings if we
> > don't have column info.
> 
> sorry will set sorrycount to non-zero though, so seen_error () will be true
> and the compiler will exit with non-zero exit status.  That is IMHO not
> appripriate for warning (at least unless -Werror=misleading-indentation).

Some possibilities here:

(A, the patch): issue a "sorry" to indicate that the warning isn't
available anymore, leading to a nonzero exit status

(B) silently disable the warning

(C) issue a "warning" about the impaired warning, using
OPT_Wmisleading_indentation, so that it becomes an error if
-Werror=misleading-indentation.

(D) something else?

Do you have a preference as to what approach I should try?  I think I
like option (C) above.

Dave

[PATCH, i386]: Fix PR69140, stack alignment + O1 breaks with Microsoft ABI

[Uros Bizjak]

Hello!

Attached patch fixes a failure, where no base register can be found to
save the remaining SSE (and integer) registers to stack. Since we are
able to restore registers in the prollogue using:

  m->fs.sp_valid = (!frame_pointer_needed
   || (crtl->sp_is_unchanging
&& !stack_realign_fp));

we can use similar approach at the end of the ix86_expand_prologue:

  m->fs.sp_valid = !frame_pointer_needed;

This way, we will always use frame pointer, if one is available or if
frame pointer is not available, the (realigned) stack register for
saves.

2016-01-06  Uros Bizjak  

PR target/69140
* config/i386/i386.c (ix86_expand_prologue): Declare fs.sp_valid
depending on frame_pointer_needed before remaining integer and SSE
registers are saved.

testsuite/ChangeLog:

2016-01-06  Uros Bizjak  

PR target/69140
* gcc.target/i386/pr69140.c: New test

Patch was bootstrapped and regression tested on x86_64-linux-gnu for
all default languages, Obj-C++ and Go. The patch was also tested by
the reporter by building and running Wine without problems.

I have to admit that prologue generation is hard to test, since it has
many different code paths. I guess committing the one-liner in the
hope that it won't break some target is the best approach one can do.

So, the patch was committed to mainline. I plan to backport it to
gcc-5 branch after a week or two without problems in mainline.

Uros.
Index: config/i386/i386.c
===
--- config/i386/i386.c  (revision 232102)
+++ config/i386/i386.c  (working copy)
@@ -13065,6 +13065,8 @@ ix86_expand_prologue (void)
   m->fs.fp_valid = true;
 }
 
+  m->fs.sp_valid = !frame_pointer_needed;
+
   if (!int_registers_saved)
 ix86_emit_save_regs_using_mov (frame.reg_save_offset);
   if (!sse_registers_saved)
Index: testsuite/gcc.target/i386/pr69140.c
===
--- testsuite/gcc.target/i386/pr69140.c (nonexistent)
+++ testsuite/gcc.target/i386/pr69140.c (working copy)
@@ -0,0 +1,22 @@
+/* { dg-do compile { target lp64 } } */
+/* { dg-options "-O2 -mincoming-stack-boundary=3" } */
+
+typedef struct {
+  unsigned int buf[4];
+  unsigned char in[64];
+} MD4_CTX;
+
+static void MD4Transform(unsigned int buf[4], const unsigned int in[16])
+{
+  unsigned int a, b, c, d;
+  (b) += c)) & ((d))) | ((~(c)) & ((a + (in[7]);
+  (a) += b)) & ((c))) | ((~(b)) & ((d + (in[8]);
+  (d) += a)) & ((b))) | ((~(a)) & ((c + (in[9]);
+  buf[3] += d;
+}
+
+void __attribute__((ms_abi)) MD4Update( MD4_CTX *ctx, const unsigned char *buf)
+{
+  MD4Transform( ctx->buf, (unsigned int *)ctx->in);
+  MD4Transform( ctx->buf, (unsigned int *)ctx->in);
+}

Re: [PATCH 2/2] PR c++/68819: libcpp fallbacks and -Wmisleading-indentation

[David Malcolm]

On Mon, 2015-12-21 at 14:10 -0700, Jeff Law wrote:
> On 12/18/2015 01:21 PM, David Malcolm wrote:
> 
> > I don't think there's a way to fix -Wmisleading-indentation if we're
> > in this state, so the first part of the following patch detects if
> > this has happened, and effectively turns off -Wmisleading-indentation
> > from that point onwards.  To avoid a false sense of security, the
> > patch issues a "sorry" at the that point, currently with this wording:
> > location-overflow-test-1.c:17:0: sorry, unimplemented: 
> > -Wmisleading-indentation is disabled from this point onwards, since 
> > column-tracking was disabled due to the size of the code/headers
> Seems reasonable.  I can't see any way to get indentation warnings if we 
> don't have column info.
> 
> >
> > Should this greater chance of hitting LINE_MAP_MAX_LOCATION_WITH_COLS
> > be filed as a separate PR?
> I was originally going to say no, but I suspect there'll be a few folks 
> that are going to bump up against it.  Might as well have a canonical BZ 
> for it.

I've opened PR preprocessor/69177 to track fixing the increased tendency
to hit the LINE_MAP_MAX_LOCATION_WITH_COLS limit.

[...snip...]

Re: [CilkPlus] fix issues when cilk_spawn is used with nontrivial expressions

[Ryan Burn]

On Tue, Jan 5, 2016 at 2:35 PM, Jeff Law  wrote:
> On 12/25/2015 09:08 AM, Ryan Burn wrote:
>>
>> This patch fixes issues with cilk_spawn where bad diagnostics are
>> emitted for expressions invoking conversion operators or constructor
>> calls (PR69024, PR68997).
>>
>> It also fixes an issue with a missing CLEANUP_POINT_EXPR that causes
>> an ICE when gimplifying code containing a temporary with a destructor
>> (PR69048)
>>
>> Bootstrapped and regression tested on x86_64-linux
>>
>> 2015-12-25  Ryan Burn
>>
>> PR cilkplus/69024, PR cilkplus/68997, PR cilkplus/PR69048
>> * cilk.c (cilk_detect_spawn_and_unwrap): Use recursive function
>> find_spawn to search for the CILK_SPAWN_STMT.
>>   (cilk_ignorable_spawn_rhs_op): Also ignore COMPOUND_EXPR.
>>   (find_spawn): New.
>>   (is_conversion_operator_function_decl_p): New.
>>   (is_conversion_operator_call_p): New.
>>   (is_unary_constructor_aggr_init_p): New.
>>   (is_conversion_operator_aggr_init_p): New.
>>   (extract_free_variables): Don't extract the slot variable of
>> an AGGR_INIT_EXPR.
>>   (create_cilk_wrapper_body): Add CLEANUP_POINT_EXPR to the
>> spawn expression.
>>
>> * gcc/testsuite/g++.dg/cilk-plus/CK/pr68997.cc : New test.
>>
>> * gcc/testsuite/g++.dg/cilk-plus/CK/pr69024.cc : New test.
>>
>> * gcc/testsuite/g++.dg/cilk-plus/CK/pr69048.cc : New test.
>>
>> * gcc/testsuite/g++.dg/cilk-plus/CK/pr68001.cc : Removed check
>> depending on bad diagnostics.
>
> Do you have a copyright assignment on file with the FSF?  This seems large
> enough to require one.
>>
>>
>>
>> +static bool
>> +is_conversion_operator_function_decl_p (tree t) {
>> +  if (TREE_CODE (t) != FUNCTION_DECL)
>> +return false;
>> +
>> +  return DECL_NAME (t) && TREE_LANG_FLAG_4 (DECL_NAME (t));
>
> At the least the use of TREE_LANG_FLAG here ought to document what you're
> checking for.  However, more likely the use is an indicator that you're
> doing something wrong.
>
> Similarly for the use of TREE_LANG_FLAG_0.
>
> Essentially those flags are allowed to have different meanings for each
> language.  AFAICT that their meaning varies for C/C++, so using them in a
> shared file like this is definitely suspect.
>

I could additionally check that the language is c++ before checking
those flags, but I'm not sure I see a way around using them. For c++,
the cilk_spawn expression can be nested within implicit conversion
operators or constructors as in this case:

struct A { operator int() { return 0; } };
A f();
int x = cilk_spawn f();

So I have to check for the conversion operators or constructors when
traversing the expression to search for the spawn. cp-tree.h has
macros that could be used to avoid checking TREE_LANG_FLAG directly,
but I wasn't sure if shared code files are allowed to include c++
specific headers. The code could be split to have a different version
for c++, but that would be more significant changes and could lead to
some code redundancy.

Any suggestions?

>
> Each new function should have a block comment before it which briefly
> describes the function and return values.  See other existing functions for
> examples.
>
>> +  return VL_EXP_OPERAND_LENGTH (t) == 4
>> +&& TREE_CODE (fn) == ADDR_EXPR
>> +&& is_conversion_operator_function_decl_p (TREE_OPERAND (fn, 0));
>
> For multi-line expressions, please wrap them in a outer set of parenthesis.
> I think there was another instance earlier.
>
>
>
> Jeff

Re: [Patch] Fix libstdc++ build when using uclibc instead of glibc

[Jonathan Wakely]

On 05/01/16 14:43 -0800, Steve Ellcey  wrote:

While trying to build GCC with uclibc instead of glibc I ran into a build
failure in libstdc++.  uclibc doesn't seem to provide the isfinite function
like glibc does so that means that libstdc++ doesn't have std::isfinite.

This in turn caused include/ext/random.tcc to not compile because it uses
std::isfinite.  I can easily see how this might be considered a uclibc
bug but given that it is the only build problem I ran into I was hoping
we could fix it in libstdc++ by using __builtin_finite instead of


Shouldn't that be __builtin_isfinite not __builtin_finite ?


std::isfinite.  This fixes my uclibc build and also worked for glibc
with no regressions.

OK to checkin?



Steve Ellcey
sell...@imgtec.com


2016-01-05  Steve Ellcey  

* include/ext/random.tcc: Use __builtin_finite instead of
std::isfinite.


diff --git a/libstdc++-v3/include/ext/random.tcc 
b/libstdc++-v3/include/ext/random.tcc
index a9c5a2b..3467823 100644
--- a/libstdc++-v3/include/ext/random.tcc
+++ b/libstdc++-v3/include/ext/random.tcc
@@ -1570,7 +1570,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
  return __t; });
  __norm = std::sqrt(__sum);
}
- while (__norm == _RealType(0) || ! std::isfinite(__norm));
+ while (__norm == _RealType(0) || ! __builtin_finite(__norm));

  std::transform(__ret.begin(), __ret.end(), __ret.begin(),
 [__norm](_RealType __val){ return __val / __norm; });

[patch] libstdc++/69092 Remove noexcept from function template that can throw

[Jonathan Wakely]

The _S_copy_chars template can't assume that the iterators don't
throw, so shouldn't be noexcept.

Tested powerpc64le-linux, committed to trunk.

This is a regression from 4.8 so I'll commit to the branches too.

commit ea6e9cb5377b93b11c9923bc7eee1e4f7d547eeb
Author: Jonathan Wakely 
Date:   Wed Jan 6 19:33:19 2016 +

Remove noexcept from function template that can throw

	PR libstdc++/69092
	* include/bits/basic_string.h (basic_string::_S_copy_chars<_Iterator>):
	Remove _GLIBCXX_NOEXCEPT.
	testsuite/21_strings/basic_string/cons/char/69092.cc: New.

diff --git a/libstdc++-v3/include/bits/basic_string.h b/libstdc++-v3/include/bits/basic_string.h
index b9fcec3..e7460bb 100644
--- a/libstdc++-v3/include/bits/basic_string.h
+++ b/libstdc++-v3/include/bits/basic_string.h
@@ -323,7 +323,6 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
   template
 static void
 _S_copy_chars(_CharT* __p, _Iterator __k1, _Iterator __k2)
-	_GLIBCXX_NOEXCEPT
 {
 	  for (; __k1 != __k2; ++__k1, (void)++__p)
 	traits_type::assign(*__p, *__k1); // These types are off.
@@ -2901,7 +2900,6 @@ _GLIBCXX_END_NAMESPACE_CXX11
   template
 static void
 _S_copy_chars(_CharT* __p, _Iterator __k1, _Iterator __k2)
-	_GLIBCXX_NOEXCEPT
 {
 	  for (; __k1 != __k2; ++__k1, (void)++__p)
 	traits_type::assign(*__p, *__k1); // These types are off.
diff --git a/libstdc++-v3/testsuite/21_strings/basic_string/cons/char/69092.cc b/libstdc++-v3/testsuite/21_strings/basic_string/cons/char/69092.cc
new file mode 100644
index 000..483708b
--- /dev/null
+++ b/libstdc++-v3/testsuite/21_strings/basic_string/cons/char/69092.cc
@@ -0,0 +1,58 @@
+// Copyright (C) 2016 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library.  This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+// GNU General Public License for more details.
+
+// You should have received a copy of the GNU General Public License along
+// with this library; see the file COPYING3.  If not see
+// .
+
+// { dg-options "-std=gnu++11" }
+
+// PR libstdc++/69092
+
+#include 
+#include 
+
+struct hate_T_iterator : std::iterator {
+explicit hate_T_iterator(char* p) : p(p) {}
+char* p;
+
+hate_T_iterator& operator++() { ++p; return *this; }
+
+hate_T_iterator operator++(int)
+{
+  hate_T_iterator r = *this;
+  ++*this; return r;
+}
+
+char& operator*() const
+{
+  if (*p == 'T')
+throw 1;
+  return *p;
+}
+
+char* operator->() const { return p; }
+
+bool operator== (hate_T_iterator other) const { return p == other.p;}
+bool operator!= (hate_T_iterator other) const { return p != other.p;}
+};
+
+int main()
+{
+  char test_str[4] = "ATA";
+  try {
+std::string s(hate_T_iterator(test_str), hate_T_iterator(test_str+3));
+  }
+  catch(int) {
+  }
+}

Re: [Patch] Fix libstdc++ build when using uclibc instead of glibc

[Steve Ellcey]

On Wed, 2016-01-06 at 20:34 +, Jonathan Wakely wrote:
> On 05/01/16 14:43 -0800, Steve Ellcey  wrote:
> >While trying to build GCC with uclibc instead of glibc I ran into a build
> >failure in libstdc++.  uclibc doesn't seem to provide the isfinite function
> >like glibc does so that means that libstdc++ doesn't have std::isfinite.
> >
> >This in turn caused include/ext/random.tcc to not compile because it uses
> >std::isfinite.  I can easily see how this might be considered a uclibc
> >bug but given that it is the only build problem I ran into I was hoping
> >we could fix it in libstdc++ by using __builtin_finite instead of
> 
> Shouldn't that be __builtin_isfinite not __builtin_finite ?

You are right.  For some reason I thought that isfinite was implemented
as __builtin_finite and that there was no __builtin_isfinite.  I am not
sure why I thought that but it does not seem to be the case.  I will
update my patch, retest, and resubmit.

Steve Ellcey
sell...@imgtec.com

RE: [PATCH][MIPS] Reorder function types

[Robert Suchanek]

Hi Catherine,

> >
> > Robert Suchanek  writes:
> > > gcc/
> > > * config/mips/mips-ftypes.def: Sort to lexicographical order.
> >
> > The patch is fine. I don't know what we can/should commit at this stage.
> > Catherine: Any idea what is acceptable? I'd think this kind of small change 
> > to
> > be OK and make it easier to maintain MSA out of tree given I doubt it can be
> > committed now.
> >
> This is fine to commit now.

Committed as r232113.

Regards,
Robert

Re: [PATCH 2/4 v2][AArch64] Add support for FCCMP

[Evandro Menezes]

Hi, Wilco.

On 01/06/2016 06:04 AM, Wilco Dijkstra wrote:

Here's what I had in mind when I inquired about distinguishing FCMP from
FCCMP.  As you can see in the patch, Exynos is the only target that
cares about it, but I wonder if ThunderX or Xgene would too.

What do you think?

The new attributes look fine (I've got a similar outstanding change), however
please don't add them to non-AArch64 cores. We only need it for thunderx.md,
cortex-a53.md, cortex-a57.md, xgene1.md and exynos-m1.md.


Add support for the FCCMP insn types

2016-01-04  Evandro Menezes  

gcc/
* config/aarch64/aarch64.md (fccmp): Change insn type.
(fccmpe): Likewise.
* config/aarch64/thunderx.md (thunderx_fcmp): Add
   "fccmp{s,d}" types.
* config/arm/cortex-a53.md (cortex_a53_fpalu): Likewise.
* config/arm/cortex-a57.md (cortex_a57_fp_cmp): Likewise.
* config/arm/xgene1.md (xgene1_fcmp): Likewise.
* config/arm/exynos-m1.md (exynos_m1_fp_ccmp): New insn
   reservation.
* config/arm/types.md (fccmps): Add new insn type.
(fccmpd): Likewise.

Got it.  Here's an updated patch.  Again, assuming that your original 
patch is in place.  Perhaps you can build on it.


Thank you,

--
Evandro Menezes

>From b5b603880eb265536eb927499c8df3ca6c42e718 Mon Sep 17 00:00:00 2001
From: Evandro Menezes 
Date: Mon, 4 Jan 2016 18:44:30 -0600
Subject: [PATCH] Add support for the FCCMP insn types

2016-01-04  Evandro Menezes  

gcc/
	* config/aarch64/aarch64.md (fccmp): Change insn type.
	(fccmpe): Likewise.
	* config/aarch64/thunderx.md (thunderx_fcmp): Add "fccmp{s,d}" types.
	* config/arm/cortex-a53.md (cortex_a53_fpalu): Likewise.
	* config/arm/cortex-a57.md (cortex_a57_fp_cmp): Likewise.
	* config/arm/xgene1.md (xgene1_fcmp): Likewise.
	* config/arm/exynos-m1.md (exynos_m1_fp_ccmp): New insn reservation.
	* config/arm/types.md (fccmps): Add new insn type.
	(fccmpd): Likewise.
---
 gcc/config/aarch64/aarch64.md  | 4 ++--
 gcc/config/aarch64/thunderx.md | 2 +-
 gcc/config/arm/cortex-a53.md   | 4 ++--
 gcc/config/arm/cortex-a57.md   | 2 +-
 gcc/config/arm/exynos-m1.md| 5 +
 gcc/config/arm/types.md| 3 +++
 gcc/config/arm/xgene1.md   | 2 +-
 7 files changed, 15 insertions(+), 7 deletions(-)

diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md
index 8b737bc..9a7ebf4 100644
--- a/gcc/config/aarch64/aarch64.md
+++ b/gcc/config/aarch64/aarch64.md
@@ -335,7 +335,7 @@
 	  (match_operand 5 "immediate_operand")))]
   "TARGET_FLOAT"
   "fccmp\\t%2, %3, %k5, %m4"
-  [(set_attr "type" "fcmp")]
+  [(set_attr "type" "fccmp")]
 )
 
 (define_insn "fccmpe"
@@ -350,7 +350,7 @@
 	  (match_operand 5 "immediate_operand")))]
   "TARGET_FLOAT"
   "fccmpe\\t%2, %3, %k5, %m4"
-  [(set_attr "type" "fcmp")]
+  [(set_attr "type" "fccmp")]
 )
 
 ;; Expansion of signed mod by a power of 2 using CSNEG.
diff --git a/gcc/config/aarch64/thunderx.md b/gcc/config/aarch64/thunderx.md
index 922df39..058713a 100644
--- a/gcc/config/aarch64/thunderx.md
+++ b/gcc/config/aarch64/thunderx.md
@@ -156,7 +156,7 @@
 
 (define_insn_reservation "thunderx_fcmp" 3
   (and (eq_attr "tune" "thunderx")
-   (eq_attr "type" "fcmps,fcmpd"))
+   (eq_attr "type" "fcmps,fcmpd,fccmps,fccmpd"))
   "thunderx_pipe1")
 
 (define_insn_reservation "thunderx_fmul" 6
diff --git a/gcc/config/arm/cortex-a53.md b/gcc/config/arm/cortex-a53.md
index c1eeedb..fc60bc2 100644
--- a/gcc/config/arm/cortex-a53.md
+++ b/gcc/config/arm/cortex-a53.md
@@ -508,8 +508,8 @@
 (define_insn_reservation "cortex_a53_fpalu" 5
   (and (eq_attr "tune" "cortexa53")
 	(eq_attr "type" "ffariths, fadds, ffarithd, faddd, fmov,
-			f_cvt, fcmps, fcmpd, fcsel, f_rints, f_rintd,
-			f_minmaxs, f_minmaxd"))
+			f_cvt, fcmps, fcmpd, fccmps, fccmpd, fcsel,
+			f_rints, f_rintd, f_minmaxs, f_minmaxd"))
   "cortex_a53_slot_any,cortex_a53_fp_alu")
 
 (define_insn_reservation "cortex_a53_fconst" 3
diff --git a/gcc/config/arm/cortex-a57.md b/gcc/config/arm/cortex-a57.md
index 0d28951..f4c112c 100644
--- a/gcc/config/arm/cortex-a57.md
+++ b/gcc/config/arm/cortex-a57.md
@@ -716,7 +716,7 @@
 
 (define_insn_reservation "cortex_a57_fp_cmp" 7
   (and (eq_attr "tune" "cortexa57")
-   (eq_attr "type" "fcmps,fcmpd"))
+   (eq_attr "type" "fcmps,fcmpd,fccmps,fccmpd"))
   "ca57_cx2")
 
 (define_insn_reservation "cortex_a57_fp_arith" 4
diff --git a/gcc/config/arm/exynos-m1.md b/gcc/config/arm/exynos-m1.md
index 0448073..973c8a9 100644
--- a/gcc/config/arm/exynos-m1.md
+++ b/gcc/config/arm/exynos-m1.md
@@ -823,6 +823,11 @@
(eq_attr "type" "fcmps, fcmpd"))
   "em1_nmisc")
 
+(define_insn_reservation "exynos_m1_fp_ccmp" 7
+  (and (eq_attr "tune" "exynosm1")
+   (eq_attr "type" "fccmps, fccmpd"))
+  "em1_st, em1_nmisc")
+
 (define_insn_reservation "exynos_m1_fp_sel" 4
   (and (eq_attr "tune" "exynosm1")