Re: [PATCH] longlong: fix sh -Wundef builds

[Oleg Endo]

On Jan 8, 2016, at 7:18 AM, Mike Frysinger  wrote:

> On 08 Jan 2016 06:54, Oleg Endo wrote:
>> On Jan 8, 2016, at 4:39 AM, Mike Frysinger  wrote:
>>> This file fails when building for SuperH as it assumes __SHMEDIA__ is
>>> always defined.  Update the code to check if it's defined.
>> 
>> This is OK for trunk.  Thanks for spotting it.
> 
> i had checked only the first case previously (as i don't have sh5
> systems), but there's a logic error in the second i fixed before
> committing.  this is what i merged:

SH5 has been obsoleted.  There are no known SH5 systems.  So it's fine if it 
just fixes some build issues.

Cheers,
Oleg

> --- include/longlong.h(revision 232142)
> +++ include/longlong.h(working copy)
> @@ -1086,7 +1086,7 @@ extern UDItype __umulsidi3 (USItype, USI
>   } while (0)
> #endif
> 
> -#if defined(__sh__) && !__SHMEDIA__ && W_TYPE_SIZE == 32
> +#if defined(__sh__) && (!defined (__SHMEDIA__) || !__SHMEDIA__) && 
> W_TYPE_SIZE == 32
> #ifndef __sh1__
> #define umul_ppmm(w1, w0, u, v) \
>   __asm__ (\
> @@ -1159,7 +1159,7 @@ extern UDItype __umulsidi3 (USItype, USI
> 
> #endif /* __sh__ */
> 
> -#if defined (__SH5__) && __SHMEDIA__ && W_TYPE_SIZE == 32
> +#if defined (__SH5__) && defined (__SHMEDIA__) && __SHMEDIA__ && W_TYPE_SIZE 
> == 32
> #define __umulsidi3(u,v) ((UDItype)(USItype)u*(USItype)v)
> #define count_leading_zeros(count, x) \
>   do\
> -mike

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

[Martin Sebor]

On 01/07/2016 05:07 AM, Marek Polacek wrote:

On Wed, Jan 06, 2016 at 04:38:20PM -0700, 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.


Sorry, I didn't mean to nitpick; I just thought it's something worth
pointing out, mostly for the future.


No problem.  It's easy enough to automate so I've modified my
ChangeLog script to print "New test." for each newly added test.
(I can't promise to use it consistently, though :)

Martin

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

[Richard Earnshaw (lists)]

On 07/01/16 09:15, Kyrill Tkachov wrote:
> 
> On 07/01/16 07:34, Thomas Preud'homme wrote:
>> 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?
> 
> Humph, you're right. I thought that dg-add-options could take a target
> selector.
> In this case perhaps we should go the route of just removing the
> target-specific option
> altogether.
> 
> Richard, that's the approach you recommended, right?
> 

Yes.

I think if you really need to test a specific set of target flags, then
it might be acceptable to have a duplicate of the test in dg.target/arm
(but please put a comment in the (arm version of the) test to explain
why it has been duplicated.

R.

> Thanks,
> Kyrill
> 
>> Best regards,
>>
>> Thomas
> 

Re: [ping] pending patches

[Bernd Schmidt]

On 01/06/2016 08:15 PM, David Malcolm wrote:

[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


My gut feeling on these is that they should wait for the next stage 1 at 
this point.



Bernd

Re: [PATCH : RL78] Disable interrupts during hardware multiplication routines

[Kaushik M Phatak]

 Hi Mike,
Thanks for the feedback regarding the ABI.

I have added Nick and DJ in the loop to see if they can review this
patch posted last month,
https://gcc.gnu.org/ml/gcc-patches/2015-12/msg00733.html

Best Regards,
Kaushik


On Wed, Dec 9, 2015 at 10:23 PM, Mike Stump  wrote:
> On Dec 9, 2015, at 1:53 AM, Kaushik M Phatak  wrote:
>> Thank you for your feedback on my patch. (27 August 2015)
>> I have posted an updated patch for this issue,
>> https://gcc.gnu.org/ml/gcc-patches/2015-12/msg00733.html
>>
>> To reply to your question, the RL78 ABI does not specify anything for the 
>> MDUC
>> registers (Multiply/Divide).
>
> Three options then, either you're inventing the abi, then you decide and 
> document what you did, you ask someone else what the abi is, or you follow 
> the abi set by another compiler.  You cannot escape the abi.  As port 
> contributor, you get to pick and make the best choice you can.  If you 
> cannot, then I will pick, the registers are always saved.  Correspondingly, 
> they are free to code-gen to be used by the compiler and optimizer.  If 
> that's the case, then there should be no flag.  An os (aka target) that wants 
> a different choice will responsible for adding in the code that can do 
> something else.
>
> Let us know what your choice is.   Maybe Nick knows of a reason why the abi 
> should be a certain way, Nick?  One we know the choice, we can then judge the 
> patch to see if it implements the abi.

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

[Marek Polacek]

On Wed, Jan 06, 2016 at 04:38:20PM -0700, 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.

Sorry, I didn't mean to nitpick; I just thought it's something worth
pointing out, mostly for the future.

But it's not like I actually care as long as there's something reasonable in
the CL entry :).  And, as you noticed, you don't have to bother with testsuite
CLs at all, and that's fine with me as well.

Marek

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 06/01/16 10:36, Kyrill Tkachov wrote:

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.




And here is the updated patch.
It is a modified version of the patch with the restriction on stores in the 
basic block lifted.
Also I chose instead to pass the register 'x' on which we should not be 
recording conflicts
rather than a boolean will_remain.

I found if we don't do this we will pessimise cases where
one basic block is something like:
t1 = x + y;
x = t1 + 2;

and the other is something like:
x = x + 1.

We want to ignore the conflict on x in both invocations of 
bbs_ok_for_cmove_arith.

With this patch the testcase passes and there is no codegen fallout on SPEC.
Bootstrapped and tested on arm, aarch64, x86_64.

How does this look?

Thanks,
Kyrill

2016-01-06  Bernd Schmidt  
Kyrylo Tkachov  

PR rtl-optimization/68841
* ifcvt.c (bbs_ok_for_cmove_arith): Add to_rename parameter.
Don't record conflicts on to_rename if it's present.
Allow memory destinations in sets.
(noce_try_cmove_arith): Call bbs_ok_for_cmove_arith even on simple
blocks.

2016-01-06  Kyrylo Tkachov  

PR rtl-optimization/68841
* gcc.dg/pr68841.c: New test.
* gcc.c-torture/execute/pr68841.c: New test.


Thanks,
Kyrill


Kyrill


Thanks for the help,
Kyrill



Bernd








diff --git a/gcc/ifcvt.c b/gcc/ifcvt.c
index 5812ce30151ed7425780890c66e7763f5758df7e..96957aac5481acbc7ac5f186a653fe63ad3e5f51 100644
--- a/gcc/ifcvt.c
+++ b/gcc/ifcvt.c
@@ -1896,11 +1896,13 @@ insn_valid_noce_process_p (rtx_insn *insn, rtx cc)
 }
 
 
-/* Return true iff the registers that the insns in BB_A set do not
-   get used in BB_B.  */
+/* Return true iff the registers that the insns in BB_A set do not get
+   used in BB_B.  If TO_RENAME is non NULL then it is a REG that will be
+   renamed later by the caller and so conflicts on it should be ignored
+   in this function.  */
 
 static bool
-bbs_ok_for_cmove_arith (basic_block bb_a, basic_block bb_b)
+bbs_ok_for_cmove_arith (basic_block bb_a, basic_block bb_b, rtx to_rename)
 {
   rtx_insn *a_insn;
   bitmap bba_sets = BITMAP_ALLOC (_obstack);
@@ -1920,10 +1922,10 @@ bbs_ok_for_cmove_arith (basic_block bb_a, basic_block bb_b)
 	  BITMAP_FREE (bba_sets);
 	  return false;
 	}
-
   /* Record all registers that BB_A sets.  */
   FOR_EACH_INSN_DEF (def, a_insn)
-	bitmap_set_bit (bba_sets, DF_REF_REGNO (def));
+	if (!(to_rename && DF_REF_REG (def) == to_rename))
+	  bitmap_set_bit (bba_sets, DF_REF_REGNO (def));
 }
 
   rtx_insn *b_insn;
@@ -1942,8 +1944,12 @@ bbs_ok_for_cmove_arith (basic_block bb_a, basic_block bb_b)
 	}
 
   /* Make sure this is a REG and not some instance
-	 of ZERO_EXTRACT or SUBREG or other dangerous stuff.  */
-  if (!REG_P (SET_DEST (sset_b)))
+	 of ZERO_EXTRACT or SUBREG or other 

Re: RFA: PR 66655: Use COFF/PE weak symbols

[Nick Clifton]

Hi Jeff,



The attached patch adds the test derived from the BZ.  There is one
small problem - I could not find a way to stop the additional source
file from being compiled as a test on its own.



I think for C++ code it's usually worked around by naming the
additional-source file with ".cc" rather than .C.  Can you give that a
quick whirl and see if that avoids having the additional file used as a
a test on its own?


Thanks - that worked. :-)

Revised test attached.  OK to apply ?

Cheers
  Nick

--- /dev/null	2016-01-07 09:30:14.144966933 +
+++ gcc/testsuite/g++.dg/pr66655.C	2016-01-07 12:13:15.757187619 +
@@ -0,0 +1,25 @@
+/* { dg-do run } */
+/* { dg-additional-sources "pr66655_1.cc" } */
+
+#include "pr66655.h"
+
+extern "C" void abort (void);
+
+#define COOKIE 0xabcd0123
+
+int
+g (void)
+{
+  return COOKIE;
+}
+
+extern int f (void);
+
+int
+main (void)
+{
+  S::set(0);
+  if (f () != COOKIE)
+abort ();
+  return 0;
+}
--- /dev/null	2016-01-07 09:30:14.144966933 +
+++ gcc/testsuite/g++.dg/pr66655_1.cc	2016-01-07 12:04:30.586623022 +
@@ -0,0 +1,14 @@
+#include "pr66655.h"
+
+extern int g (void);
+
+int S::i;
+
+int
+f (void)
+{
+  int ret = g ();
+
+  S::set (ret);
+  return ret;
+}
--- /dev/null	2016-01-07 09:30:14.144966933 +
+++ gcc/testsuite/g++.dg/pr66655.h	2016-01-05 10:41:45.629561622 +
@@ -0,0 +1,5 @@
+struct S
+{
+  static int i;
+  static void set (int ii) { i = -ii; }
+};

Re: [PATCH : RL78] Disable interrupts during hardware multiplication routines

[Nick Clifton]

Hi Kaushik,

  Just a few comments on the patch itself:

+/* Check if the block uses mul/div insns.  */
+int
+check_mduc_usage ()

I would suggest:

  static bool
  check_mduc_usage (void)

instead, since this is a boolean function, only used in the rl78.c file, 
and it takes no arguments.



+  if (recog_memoized (insn) == CODE_FOR_udivmodsi4_g13
+  || recog_memoized (insn) == CODE_FOR_mulhi3_g13
+  || recog_memoized (insn) == CODE_FOR_mulsi3_g13)

Testing for specific insn codes is a bit unsafe as it would lead to 
problems if new multiply insns are ever added to the target.  A slightly 
better approach would be to have an attribute on these insns, and then 
test for that here.



+  return 1;

If you change the function to "bool" then return "true" here.

+  return 0;

And "false" here.


   if (rl78_is_naked_func ())
 return;
-
+

Why are you adding a extraneous space here ?


+  /* Save MDUC register inside interrupt routine.  */
+  if (MUST_SAVE_MDUC_REGISTER && (!crtl->is_leaf || check_mduc_usage ()))

It would be nice to update the stack size computation performed earlier 
in this function, if these registers are going to be saved.



+{
+  rtx mem_mduc;
+
+  mem_mduc = gen_rtx_MEM (QImode, GEN_INT (0xf00e8));
+  MEM_VOLATILE_P (mem_mduc) = 1;
+  emit_insn (gen_movqi (gen_rtx_REG (QImode, A_REG), mem_mduc));
+  emit_insn (gen_push (gen_rtx_REG (HImode, AX_REG)));
+
+  mem_mduc = gen_rtx_MEM (HImode, GEN_INT (0x0));
+  MEM_VOLATILE_P (mem_mduc) = 1;
+  emit_insn (gen_movhi (gen_rtx_REG (HImode, AX_REG), mem_mduc));
+  emit_insn (gen_push (gen_rtx_REG (HImode, AX_REG)));

Since this is a lot of repeated code, it would be cleaner to use a for 
loop and a small structure containing the address, mode and volatility 
to be saved.  Even better this structure could then be shared with the 
epilogue code so that the two functions always remain in sync.



   if (cfun->machine->uses_es)
 fprintf (file, "\t; uses ES register\n");
+
+  if (MUST_SAVE_MDUC_REGISTER)
+fprintf (file, "\t; uses MDUC register\n");
 }

It is not just that the function uses the MDUC registers.  It is also 
that there registers are saved on the stack - and hence the function 
uses more stack space than the reader might expect.  Hence I would suggest:


  fprintf (file, "\t; preserves MDUC registers\n");


+msave-mduc-in-interrupts
+Target Mask(SAVE_MDUC_REGISTER)
+Stores the MDUC registers for interrupt handlers for G13 target.
+This is the default.

It is *not* the default!


+@item -msave-mduc-in-interrupts
+@item -mno-save-mduc-in-interrupts
+@opindex msave-mduc-in-interrupts
+@opindex mno-save-mduc-in-interrupts
+Specifies that interrupt handler functions should preserve the
+MDUC registers.  This is only necessary if normal code might use
+the MDUC registers, for example because it performs multiplication
+and division operations. The default is to ignore the MDUC registers
+as this makes the interrupt handlers faster. The target option -mg13
+needs to be passed for this to work as this feature is only available
+on the G13 target (S2 core).

You should also mention that even if this option is enabled the MDUC 
registers will not be saved if the interrupt function does not use the 
multiply hardware and does not call any other function.




Cheers
  Nick

Re: [PATCH] testsuite/lib/multline.exp: show test name and line numbers

[Bernd Schmidt]

On 12/29/2015 10:17 AM, Uros Bizjak wrote:

It looks that this new functionality doesn't handle conditional
compilation, when

/* { dg-do compile { target { ! ia32 } } } */

is added to the testcase, such as in recently changed
gcc.target/i386/pr68473-1.c.

The directive is passed to the next testcase, leading to spurious
testsuite failures [1] in unrelated testcases.


Please open a PR if you haven't already. David, could you investigate?


Bernd

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

[Jakub Jelinek]

On Wed, Jan 06, 2016 at 03:02:05PM -0500, David Malcolm wrote:
> 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.

My preference would be inform ().  That is e.g. what var-tracking
uses in a similar case:
  if (MAY_HAVE_DEBUG_INSNS)
inform (DECL_SOURCE_LOCATION (cfun->decl),
"variable tracking size limit exceeded with "
"-fvar-tracking-assignments, retrying without");
  else
inform (DECL_SOURCE_LOCATION (cfun->decl),
"variable tracking size limit exceeded");
when the tables are too large and computing good quality debug info would be
too expensive.

Jakub

[PATCH] Fix #pragma implementation diagnostics (PR c++/69145, take 2)

[Jakub Jelinek]

Hi!

On Tue, Jan 05, 2016 at 03:19:04PM -0500, David Malcolm wrote:
> Isn't the line_table available from the cpp_reader as a field, though?
> cpp_included_before could in theory access pfile->line_table.

You are right, that works too.
So I'm offering an alternate patch too:

2016-01-07  Jakub Jelinek  

PR c++/69145
* files.c (cpp_included_before): If IS_ADHOC_LOC (location), lookup
real location from the line_table.

* g++.dg/ext/pr69145-1.C: New test.
* g++.dg/ext/pr69145-2-very-long-filename.cc: New file.
* g++.dg/ext/pr69145-2.h: New file.

--- libcpp/files.c.jj   2016-01-05 12:26:58.0 +0100
+++ libcpp/files.c  2016-01-07 10:01:35.958676922 +0100
@@ -1224,10 +1224,16 @@ bool
 cpp_included_before (cpp_reader *pfile, const char *fname,
 source_location location)
 {
-  struct cpp_file_hash_entry *entry;
+  struct cpp_file_hash_entry *entry
+= (struct cpp_file_hash_entry *)
+  htab_find_with_hash (pfile->file_hash, fname, htab_hash_string (fname));
 
-  entry = (struct cpp_file_hash_entry *)
- htab_find_with_hash (pfile->file_hash, fname, htab_hash_string (fname));
+  if (IS_ADHOC_LOC (location))
+{
+  location &= MAX_SOURCE_LOCATION;
+  location
+   = pfile->line_table->location_adhoc_data_map.data[location].locus;
+}
 
   while (entry && (entry->start_dir == NULL || entry->u.file->err_no
   || entry->location > location))
--- gcc/testsuite/g++.dg/ext/pr69145-1.C.jj 2016-01-05 12:22:58.206729760 
+0100
+++ gcc/testsuite/g++.dg/ext/pr69145-1.C2016-01-05 12:22:52.017818392 
+0100
@@ -0,0 +1,4 @@
+// PR c++/69145
+// { dg-do compile }
+#pragma implementation "pr69145-2-very-long-filename.cc" // { dg-bogus 
"appears after file is included" }
+#include "pr69145-2-very-long-filename.cc"
--- gcc/testsuite/g++.dg/ext/pr69145-2-very-long-filename.cc.jj 2016-01-05 
12:23:47.151028824 +0100
+++ gcc/testsuite/g++.dg/ext/pr69145-2-very-long-filename.cc2016-01-05 
12:23:42.629093583 +0100
@@ -0,0 +1,3 @@
+// PR c++/69145
+// { dg-do compile } */
+#include "pr69145-2.h"
--- gcc/testsuite/g++.dg/ext/pr69145-2.h.jj 2016-01-05 12:23:49.963988539 
+0100
+++ gcc/testsuite/g++.dg/ext/pr69145-2.h2016-01-05 12:06:42.0 
+0100
@@ -0,0 +1,3 @@
+#ifndef PR69145_2_H
+# define PR69145_2_H
+#endif

Jakub

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

[Jakub Jelinek]

On Thu, Jan 07, 2016 at 06:48:25AM +, Saraswati, Sujoy (OSTL) wrote:
> 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 -

If you have access to x86_64-linux, you can easily test it yourself with:
make -C gcc check-gcc 
RUNTESTFLAGS='--target_board=unix\{-m64,-m32/-march=i386\} dg.exp=pr61441.c'

Your patch does help.

issignalling is a GNU extension of glibc, so supposedly you should limit the
test to the targets that use glibc, so either
/* { dg-do run { target { *-*-linux* *-*-gnu* } } } */
or perhaps specific target-supports.exp test for this (I wonder if android
and/or uclibc support it).

> 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 ?

Perhaps H.J. uses differently configured i686-linux build?  If it is
configured with --with-fpmath=sse or =avx, then i387 is only used
for long double and therefore the target is not excess precision target any 
longer.

Jakub

Re: Fix PR66208

[Bernd Schmidt]

On 12/16/2015 11:14 PM, Jeff Law wrote:

On 12/16/2015 10:13 AM, Bernd Schmidt wrote:

This is a relatively straightforward PR where we should mention a macro
expansion in a warning message. The patch below implements the
suggestion by Marek to pass a location down from
build_function_call_vec. Ok if tests pass on x86_64-linux?


Ping.


One question I have is about -Wformat, which is dealt with in the same
area. We do get a mention of the macro expansion, but in a different
style:

[...]

Is this what we're looking for in terms of output?



Are you referring to the "in definition" vs "in expansion" difference?
That appears to be a difference in the locus of the first displayed
diagnostic before the unwinding of the macros.


Yeah. I just wanted to point it out in case anyone sees something wrong 
with this.



Bernd

Re: PATCH: PR target/69171: [6 Regression] error: unrecognizable insn: on x86_64 with -O2

[Uros Bizjak]

On Thu, Jan 7, 2016 at 12:52 PM, H.J. Lu  wrote:
> Add round_nimm_scalar_predicate for scalar SSE integer to floating point
> conversions since round_nimm_predicate is for vector operand.
>
> round_constraint can't be used on vector SSE patterns since it is mapped
> to "vm".  The "xBm" constraint must be used in this case.
>
> Tested on x86-64.  OK for trunk?

OK.

Thanks,
Uros.

> H.J.
> ---
> gcc/
>
> PR target/69171
> * config/i386/sse.md (_sqrt2):
> Use the "xBm" constraint.
> (float2 Likewise.
> (sse_cvtsi2ss): Use round_nimm_scalar_predicate.
> (sse_cvtsi2ssq): Likewise.
> (sse_cvtss2si): Likewise.
> (sse_cvtss2siq): Likewise.
> (sse2_cvtsi2sdq): Likewise.
> (sse2_cvtsd2si): Likewise.
> (sse2_cvtsd2siq): Likewise.
> * config/i386/subst.md (round_nimm_scalar_predicate): New
> predicate.
>
> gcc/testsuite/
>
> PR target/69171
> * gcc.target/i386/pr69171-1.c: New test.
> * gcc.target/i386/pr69171-2.c: Likewise.
> * gcc.target/i386/pr69171-3.c: Likewise.
> * gcc.target/i386/pr69171-4.c: Likewise.
> * gcc.target/i386/pr69171-5.c: Likewise.
> * gcc.target/i386/pr69171-6.c: Likewise.
> ---
>  gcc/config/i386/sse.md| 36 
> ++-
>  gcc/config/i386/subst.md  |  1 +
>  gcc/testsuite/gcc.target/i386/pr69171-1.c | 13 +++
>  gcc/testsuite/gcc.target/i386/pr69171-2.c | 13 +++
>  gcc/testsuite/gcc.target/i386/pr69171-3.c | 12 +++
>  gcc/testsuite/gcc.target/i386/pr69171-4.c | 12 +++
>  gcc/testsuite/gcc.target/i386/pr69171-5.c | 12 +++
>  gcc/testsuite/gcc.target/i386/pr69171-6.c | 12 +++
>  8 files changed, 96 insertions(+), 15 deletions(-)
>  create mode 100644 gcc/testsuite/gcc.target/i386/pr69171-1.c
>  create mode 100644 gcc/testsuite/gcc.target/i386/pr69171-2.c
>  create mode 100644 gcc/testsuite/gcc.target/i386/pr69171-3.c
>  create mode 100644 gcc/testsuite/gcc.target/i386/pr69171-4.c
>  create mode 100644 gcc/testsuite/gcc.target/i386/pr69171-5.c
>  create mode 100644 gcc/testsuite/gcc.target/i386/pr69171-6.c
>
> diff --git a/gcc/config/i386/sse.md b/gcc/config/i386/sse.md
> index c21cc0e..278dd38 100644
> --- a/gcc/config/i386/sse.md
> +++ b/gcc/config/i386/sse.md
> @@ -1862,11 +1862,14 @@
>  })
>
>  (define_insn "_sqrt2"
> -  [(set (match_operand:VF 0 "register_operand" "=v")
> -   (sqrt:VF (match_operand:VF 1 "" 
> "")))]
> +  [(set (match_operand:VF 0 "register_operand" "=x,v")
> +   (sqrt:VF (match_operand:VF 1 "" 
> "xBm,")))]
>"TARGET_SSE &&  && "
> -  "%vsqrt\t{%1, 
> %0|%0, %1}"
> -  [(set_attr "type" "sse")
> +  "@
> +   sqrt\t{%1, %0|%0, %1}
> +   vsqrt\t{%1, 
> %0|%0, %1}"
> +  [(set_attr "isa" "noavx,avx")
> +   (set_attr "type" "sse")
> (set_attr "atom_sse_attr" "sqrt")
> (set_attr "btver2_sse_attr" "sqrt")
> (set_attr "prefix" "maybe_vex")
> @@ -4269,7 +4272,7 @@
>[(set (match_operand:V4SF 0 "register_operand" "=x,x,v")
> (vec_merge:V4SF
>   (vec_duplicate:V4SF
> -   (float:SF (match_operand:SI 2 "" 
> "r,m,")))
> +   (float:SF (match_operand:SI 2 "" 
> "r,m,")))
>   (match_operand:V4SF 1 "register_operand" "0,0,v")
>   (const_int 1)))]
>"TARGET_SSE"
> @@ -4291,7 +4294,7 @@
>[(set (match_operand:V4SF 0 "register_operand" "=x,x,v")
> (vec_merge:V4SF
>   (vec_duplicate:V4SF
> -   (float:SF (match_operand:DI 2 "" 
> "r,m,")))
> +   (float:SF (match_operand:DI 2 "" 
> "r,m,")))
>   (match_operand:V4SF 1 "register_operand" "0,0,v")
>   (const_int 1)))]
>"TARGET_SSE && TARGET_64BIT"
> @@ -4314,7 +4317,7 @@
>[(set (match_operand:SI 0 "register_operand" "=r,r")
> (unspec:SI
>   [(vec_select:SF
> -(match_operand:V4SF 1 "" 
> "v,")
> +(match_operand:V4SF 1 "" 
> "v,")
>  (parallel [(const_int 0)]))]
>   UNSPEC_FIX_NOTRUNC))]
>"TARGET_SSE"
> @@ -4344,7 +4347,7 @@
>[(set (match_operand:DI 0 "register_operand" "=r,r")
> (unspec:DI
>   [(vec_select:SF
> -(match_operand:V4SF 1 "" 
> "v,")
> +(match_operand:V4SF 1 "" 
> "v,")
>  (parallel [(const_int 0)]))]
>   UNSPEC_FIX_NOTRUNC))]
>"TARGET_SSE && TARGET_64BIT"
> @@ -4431,12 +4434,15 @@
> (set_attr "mode" "")])
>
>  (define_insn "float2"
> -  [(set (match_operand:VF1 0 "register_operand" "=v")
> +  [(set (match_operand:VF1 0 "register_operand" "=x,v")
> (float:VF1
> - (match_operand: 1 "" 
> "")))]
> + (match_operand: 1 "" 
> "xBm,")))]
>"TARGET_SSE2 &&  && 
> "
> -  "%vcvtdq2ps\t{%1, %0|%0, 
> %1}"
> -  [(set_attr "type" "ssecvt")
> +  "@
> +   cvtdq2ps\t{%1, %0|%0, %1}
> +   vcvtdq2ps\t{%1, %0|%0, 
> %1}"
> +  [(set_attr "isa" "noavx,avx")
> +   

Re: RFA: PR 68913: Provide weak version of __fread_chk for PR61886 test

[Dominique d'Humières]

> +/* { dg-lto-options { { -flto -O2 -Werror -Wl,--defsym,__fread_chk=0x1234 } 
> } } */

This won’t work on darwin:

ld: unknown option: --defsym
collect2: error: ld returned 1 exit status

TIA

Dominique

[PATCH][simplify-rtx] PR rtl-optimization/69161: Fix ICE when trying to simplify vec_duplicate of CC mode

[Kyrill Tkachov]

Hi all,

In this ICE on aarch64 combine ends up creating a V4SI vec_duplicate of a 
comparison:
(eq:CC_NZ (reg:CC_NZ 66 cc)
(const_int 0 [0]))

This triggers and assertion in simplify_const_unary_operation about the
inner mode of the duplicate (SImode in this case) not being the same as
the CC_NZ mode of the comparison.

I suspect ICE'ing here is too harsh as this particular function supports
returing 0 to indicate that no simplification is possible, which is
what this patch does.

With this patch the testcase compiles successfully and bootstrap and
tests look ok on arm, aarch64, x86_64.

Is this the right way of going around fixing this?
I'm not sure if there's a clean way of teaching combine to not try creating
these RTXes in the first place...

Thanks,
Kyrill

2016-01-07  Kyrylo Tkachov  

PR rtl-optimization/69161
* simplify-rtx.c (simplify_const_unary_operation): Return zero
rather than ICEing when vector inner mode and op mode don't
match in a vec_duplicate.

2016-01-07  Kyrylo Tkachov  

PR rtl-optimization/69161
* gcc.c-torture/compile/pr69161.c: New test.
diff --git a/gcc/simplify-rtx.c b/gcc/simplify-rtx.c
index f918d2da4ff2b72ee30622a3f78212fa1f88982c..966d9472349a02ab72946e9784fbf8de31a45b2b 100644
--- a/gcc/simplify-rtx.c
+++ b/gcc/simplify-rtx.c
@@ -1628,13 +1628,15 @@ simplify_const_unary_operation (enum rtx_code code, machine_mode mode,
 {
   gcc_assert (VECTOR_MODE_P (mode));
   if (GET_MODE (op) != VOIDmode)
-  {
-	if (!VECTOR_MODE_P (GET_MODE (op)))
-	  gcc_assert (GET_MODE_INNER (mode) == GET_MODE (op));
-	else
-	  gcc_assert (GET_MODE_INNER (mode) == GET_MODE_INNER
-		(GET_MODE (op)));
-  }
+	{
+	  /* Make sure we've got an appropriate inner mode.  */
+	  if (!VECTOR_MODE_P (GET_MODE (op))
+	  && GET_MODE_INNER (mode) != GET_MODE (op))
+	return 0;
+	  else if (VECTOR_MODE_P (GET_MODE (op))
+		   && GET_MODE_INNER (mode) != GET_MODE_INNER (GET_MODE (op)))
+	return 0;
+	}
   if (CONST_SCALAR_INT_P (op) || CONST_DOUBLE_AS_FLOAT_P (op)
 	  || GET_CODE (op) == CONST_VECTOR)
 	{
diff --git a/gcc/testsuite/gcc.c-torture/compile/pr69161.c b/gcc/testsuite/gcc.c-torture/compile/pr69161.c
new file mode 100644
index ..b64197550ce8c6c7e6c1c17fcb4b39fd2ce9d61a
--- /dev/null
+++ b/gcc/testsuite/gcc.c-torture/compile/pr69161.c
@@ -0,0 +1,1199 @@
+/* { dg-options "-w" } */
+
+typedef signed char int8_t;
+typedef short int int16_t;
+typedef int int32_t;
+typedef long int int64_t;
+typedef unsigned char uint8_t;
+typedef unsigned short int uint16_t;
+typedef unsigned int uint32_t;
+typedef unsigned long int uint64_t;
+static int8_t (safe_sub_func_int8_t_s_s) (int8_t si1, int8_t si2) {}
+static uint8_t (safe_mul_func_uint8_t_u_u) (uint8_t ui1, uint8_t ui2) {}
+static uint8_t (safe_rshift_func_uint8_t_u_u) (uint8_t left,
+   unsigned int right)
+{
+  return (((unsigned int)right) >= 32) ? ((left))
+   : (left >> ((unsigned int)right));
+}
+static uint16_t (safe_lshift_func_uint16_t_u_u) (uint16_t left,
+ unsigned int right)
+{
+  return unsigned int)right) >= 32)
+  || (left > ((65535) >> ((unsigned int)right
+ ? ((left))
+ : (left << ((unsigned int)right));
+}
+static uint32_t (safe_add_func_uint32_t_u_u) (uint32_t ui1, uint32_t ui2) {}
+static int32_t g_10 = 0xCB61D225L;
+static uint32_t g_49[5]
+= { 0xC4438182L, 0xC4438182L, 0xC4438182L, 0xC4438182L, 0xC4438182L };
+static uint8_t g_53 = 0xEEL;
+static int32_t g_61 = 0x8CA40452L;
+static uint32_t g_79[1][1] = { { 0x464CD027L } };
+static int64_t g_126 = 0xFCBDC27B9F097201LL;
+static int32_t *g_129 = _61;
+static int32_t **g_128 = _129;
+static int8_t g_195 = 0x61L;
+static uint16_t g_223 = 3UL;
+static uint32_t g_234 = 0UL;
+static int8_t **g_242[8][7] = {};
+static uint16_t g_251 = 0x2CE0L;
+static uint64_t g_254 = 0x02AD15776B272A17LL;
+static int32_t g_276[3] = { 1L, 1L, 1L };
+static int16_t g_391[7]
+= { (-9L), 0x61C0L, 0x61C0L, (-9L), 0x61C0L, 0x61C0L, (-9L) };
+static int16_t *volatile g_454 = _391[0];
+static uint8_t g_493 = 0x2BL;
+static uint64_t *g_608[4] = { (void *)0, (void *)0, (void *)0, (void *)0 };
+static uint32_t *g_619 = _79[0][0];
+static uint8_t g_674 = 1UL;
+static int16_t ***g_781 = (void *)0;
+static int8_t g_817 = 9L;
+static uint64_t g_1066[1] = { 0x29C9DEA68F9DE84CLL };
+static uint32_t **g_1088 = _619;
+static uint32_t ***g_1087 = _1088;
+static int32_t g_1148[3] = { 0x656211FCL, 0x656211FCL, 0x656211FCL };
+static int64_t **g_1224 = (void *)0;
+static int8_t ***g_1240 = _242[6][5];
+static int8_t g_1239[2] = { _1240, _1240 };
+static int8_t *g_1238 = _1239[1];
+static uint32_t g_1263[10]
+= { 7UL, 4294967295UL, 7UL, 4294967295UL, 7UL,
+4294967295UL, 7UL, 4294967295UL, 7UL, 

[PATCH][RS6000] Migrate reduction optabs in paired.md

[Alan Lawrence]

There are only a couple of uses of the old reduction optabs remaining
(the optabs producing a vector with only one element set). This migrates the
uses in gcc.target/rs6000/paired.md.

In the absence of a vec_extract pattern, I generate two subreg moves, the same
as usually produced by the midend when using the old pattern.

I don't have hardware to properly test this, but using a stage 1 compiler, I
have compiled all the tests in gcc.dg/vect, at -O2 -ftree-vectorize -mpaired -S
-mno-altivec -ffast-math -ffinite-math-only, on both
powerpc-none-linux-gnupaired and ppcel-none-linux-gnupaired.

The patterns were triggered on
fast-math-vect-reduc-5.c, fast-math-vect-reduc-8.c, no-fast-math-vect16.c,
vect-reduc-6.c.

no-fast-math-vect16.c exhibited some regalloc differences (regs 0 and 12 are
swapped):

addi 9,1,136
+   lfs 12,136(29)
psq_stx 0,0,9,0,0
-   lfs 0,136(29)
-   lfs 12,140(1)
-   fcmpu 7,12,0
+   lfs 0,140(1)
+   fcmpu 7,0,12

no other assembly was changed.

Is this OK for trunk? (stage 3?)

Cheers, Alan

gcc/ChangeLog:

* gcc.target/rs6000/paired.md (reduc_smax_v2sf): Rename to...
(reduc_smax_scal_v2sf): ...here, make result SFmode, extract element.
(reduc_smin_v2sf): Rename to...
(reduc_smin_scal_v2sf): ...here, make result SFmode, extract element.
(reduc_splus_v2sf): Rename to...
(reduc_plus_scal_v2sf): ...here, make result SFmode, extract element.
---
 gcc/config/rs6000/paired.md | 39 ---
 1 file changed, 28 insertions(+), 11 deletions(-)

diff --git a/gcc/config/rs6000/paired.md b/gcc/config/rs6000/paired.md
index 5d094fb..c3f4d66 100644
--- a/gcc/config/rs6000/paired.md
+++ b/gcc/config/rs6000/paired.md
@@ -421,45 +421,62 @@
   DONE;
 })
 
-(define_expand "reduc_smax_v2sf"
-  [(match_operand:V2SF 0 "gpc_reg_operand" "=f")
+(define_expand "reduc_smax_scal_v2sf"
+  [(match_operand:SF 0 "gpc_reg_operand" "=f")
(match_operand:V2SF 1 "gpc_reg_operand" "f")]
   "TARGET_PAIRED_FLOAT"
 {
   rtx tmp_swap = gen_reg_rtx (V2SFmode);
   rtx tmp = gen_reg_rtx (V2SFmode);
+  rtx vec_res = gen_reg_rtx (V2SFmode);
+  rtx di_res = gen_reg_rtx (DImode);
 
   emit_insn (gen_paired_merge10 (tmp_swap, operands[1], operands[1]));
   emit_insn (gen_subv2sf3 (tmp, operands[1], tmp_swap));
-  emit_insn (gen_selv2sf4 (operands[0], tmp, operands[1], tmp_swap, CONST0_RTX 
(SFmode)));
+  emit_insn (gen_selv2sf4 (vec_res, tmp, operands[1], tmp_swap,
+  CONST0_RTX (SFmode)));
+  emit_move_insn (di_res, simplify_gen_subreg (DImode, vec_res, V2SFmode, 0));
+  emit_move_insn (operands[0], simplify_gen_subreg (SFmode, di_res, DImode,
+   BYTES_BIG_ENDIAN ? 4 : 0));
 
   DONE;
 })
 
-(define_expand "reduc_smin_v2sf"
-  [(match_operand:V2SF 0 "gpc_reg_operand" "=f")
+(define_expand "reduc_smin_scal_v2sf"
+  [(match_operand:SF 0 "gpc_reg_operand" "=f")
(match_operand:V2SF 1 "gpc_reg_operand" "f")]
   "TARGET_PAIRED_FLOAT"
 {
   rtx tmp_swap = gen_reg_rtx (V2SFmode);
   rtx tmp = gen_reg_rtx (V2SFmode);
+  rtx vec_res = gen_reg_rtx (V2SFmode);
+  rtx di_res = gen_reg_rtx (DImode);
 
   emit_insn (gen_paired_merge10 (tmp_swap, operands[1], operands[1]));
   emit_insn (gen_subv2sf3 (tmp, operands[1], tmp_swap));
-  emit_insn (gen_selv2sf4 (operands[0], tmp, tmp_swap, operands[1], CONST0_RTX 
(SFmode)));
+  emit_insn (gen_selv2sf4 (vec_res, tmp, tmp_swap, operands[1],
+  CONST0_RTX (SFmode)));
+  emit_move_insn (di_res, simplify_gen_subreg (DImode, vec_res, V2SFmode, 0));
+  emit_move_insn (operands[0], simplify_gen_subreg (SFmode, di_res, DImode,
+   BYTES_BIG_ENDIAN ? 4 : 0));
 
   DONE;
 })
 
-(define_expand "reduc_splus_v2sf"
-  [(set (match_operand:V2SF 0 "gpc_reg_operand" "=f")
+(define_expand "reduc_plus_scal_v2sf"
+  [(set (match_operand:SF 0 "gpc_reg_operand" "=f")
 (match_operand:V2SF 1 "gpc_reg_operand" "f"))]
   "TARGET_PAIRED_FLOAT"
-  "
 {
-  emit_insn (gen_paired_sum1 (operands[0], operands[1], operands[1], 
operands[1]));
+  rtx vec_res = gen_reg_rtx (V2SFmode);
+  rtx di_res = gen_reg_rtx (DImode);
+
+  emit_insn (gen_paired_sum1 (vec_res, operands[1], operands[1], operands[1]));
+  emit_move_insn (di_res, simplify_gen_subreg (DImode, vec_res, V2SFmode, 0));
+  emit_move_insn (operands[0], simplify_gen_subreg (SFmode, di_res, DImode,
+   BYTES_BIG_ENDIAN ? 4 : 0));
   DONE;
-}")
+})
 
 (define_expand "movmisalignv2sf"
   [(set (match_operand:V2SF 0 "nonimmediate_operand" "")
-- 
1.9.1

Re: [gomp4] kernels offload fns

[Nathan Sidwell]

On 01/06/16 19:11, Cesar Philippidis wrote:

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.


thanks

Re: RFA: PR 68913: Provide weak version of __fread_chk for PR61886 test

[Nick Clifton]

Hi Rainer.


+/* { dg-lto-options { { -flto -O2 -Werror -Wl,--defsym,__fread_chk=0x1234



this assumes GNU ld and will break on all targets that use different
linkers.


OK, how about this version instead ?

Cheers
  Nick

Index: gcc/testsuite/gcc.dg/lto/pr61886_0.c
===
--- gcc/testsuite/gcc.dg/lto/pr61886_0.c(revision 232123)
+++ gcc/testsuite/gcc.dg/lto/pr61886_0.c(working copy)
@@ -1,5 +1,6 @@
 /* { dg-lto-do link } */
 /* { dg-lto-options { { -flto -O2 -Werror } } } */
+/* { dg-extra-ld-options "-Wl,--defsym,__fread_chk=0x1234" { target { 
gld } } } */


 typedef __SIZE_TYPE__ size_t;
 typedef struct _IO_FILE FILE;

[PATCH][MIPS] Migrate reduction optabs in mips-ps-3d.md

[Alan Lawrence]

Here's an updated version, also covering the min/max patterns I missed before.
I've now managed to do some testing with a stage 1 compiler, by compiling all
tests in gcc.dg/vect at -O2 -ftree-vectorize -mips3d -march=mips64r2 -mabi=n32
$x -ffast-math -ffinite-math-only.

There were no changes in which files compiled (871 did, some did not due to
libraries etc. missing in my stage 1 compiler), and no changes in any assembly
output. The patterns were triggered on:

fast-math-vect-reduc-5.c, fast-math-vect-reduc-8.c, fast-math-vect-reduc-9.c,
no-fast-math-vect16.c, pr66142.c, vect-outer-fir-big-array.c, vect-outer-fir.c,
vect-outer-fir-lb-big-array.c, vect-outer-fir-lb.c, vect-reduc-10.c,
vect-reduc-6.c

I realize this is not completely representative of a 'proper' test run, in
which different files are compiled with different options, but it provides
reasonable confidence that I'm not changing any code generation.

OK for trunk? (stage 3?)

Cheers, Alan

gcc/ChangeLog:

* config/mips/mips-ps-3d.md (reduc_splus_v2sf): Remove.
(reduc_plus_scal_v2sf): New.
(reduc_smax_v2sf): Rename to...
(reduc_smax_scal_v2sf): ...here, make result SFmode, add vec_extract.
(reduc_smin_v2sf): Rename to...
(reduc_smin_scal_v2sf): ...here, make result SFmode, add vec_extract.
---
 gcc/config/mips/mips-ps-3d.md | 34 ++
 1 file changed, 22 insertions(+), 12 deletions(-)

diff --git a/gcc/config/mips/mips-ps-3d.md b/gcc/config/mips/mips-ps-3d.md
index 8bc7608..a93a2b9 100644
--- a/gcc/config/mips/mips-ps-3d.md
+++ b/gcc/config/mips/mips-ps-3d.md
@@ -371,13 +371,17 @@
   [(set_attr "type" "fadd")
(set_attr "mode" "SF")])
 
-(define_insn "reduc_splus_v2sf"
-  [(set (match_operand:V2SF 0 "register_operand" "=f")
-   (unspec:V2SF [(match_operand:V2SF 1 "register_operand" "f")
- (match_dup 1)]
-UNSPEC_ADDR_PS))]
+(define_expand "reduc_plus_scal_v2sf"
+  [(match_operand:SF 0 "register_operand" "=f")
+   (match_operand:V2SF 1 "register_operand" "f")]
   "TARGET_HARD_FLOAT && TARGET_MIPS3D"
-  "")
+  {
+rtx temp = gen_reg_rtx (V2SFmode);
+emit_insn (gen_mips_addr_ps (temp, operands[1], operands[1]));
+rtx lane = BYTES_BIG_ENDIAN ? const1_rtx : const0_rtx;
+emit_insn (gen_vec_extractv2sf (operands[0], temp, lane));
+DONE;
+  })
 
 ; cvt.pw.ps - Floating Point Convert Paired Single to Paired Word
 (define_insn "mips_cvt_pw_ps"
@@ -745,20 +749,26 @@
   DONE;
 })
 
-(define_expand "reduc_smin_v2sf"
-  [(match_operand:V2SF 0 "register_operand")
+(define_expand "reduc_smin_scal_v2sf"
+  [(match_operand:SF 0 "register_operand")
(match_operand:V2SF 1 "register_operand")]
   "TARGET_HARD_FLOAT && TARGET_PAIRED_SINGLE_FLOAT"
 {
-  mips_expand_vec_reduc (operands[0], operands[1], gen_sminv2sf3);
+  rtx temp = gen_reg_rtx (V2SFmode);
+  mips_expand_vec_reduc (temp, operands[1], gen_sminv2sf3);
+  rtx lane = BYTES_BIG_ENDIAN ? const1_rtx : const0_rtx;
+  emit_insn (gen_vec_extractv2sf (operands[0], temp, lane));
   DONE;
 })
 
-(define_expand "reduc_smax_v2sf"
-  [(match_operand:V2SF 0 "register_operand")
+(define_expand "reduc_smax_scal_v2sf"
+  [(match_operand:SF 0 "register_operand")
(match_operand:V2SF 1 "register_operand")]
   "TARGET_HARD_FLOAT && TARGET_PAIRED_SINGLE_FLOAT"
 {
-  mips_expand_vec_reduc (operands[0], operands[1], gen_smaxv2sf3);
+  rtx temp = gen_reg_rtx (V2SFmode);
+  mips_expand_vec_reduc (temp, operands[1], gen_smaxv2sf3);
+  rtx lane = BYTES_BIG_ENDIAN ? const1_rtx : const0_rtx;
+  emit_insn (gen_vec_extractv2sf (operands[0], temp, lane));
   DONE;
 })
-- 
1.9.1

Re: [PATCH] Fix #pragma implementation diagnostics (PR c++/69145, take 2)

[Bernd Schmidt]

On 01/07/2016 10:05 AM, Jakub Jelinek wrote:

+  if (IS_ADHOC_LOC (location))
+{
+  location &= MAX_SOURCE_LOCATION;
+  location
+   = pfile->line_table->location_adhoc_data_map.data[location].locus;
+}


This looks like it is get_location_from_adhoc_loc.


Bernd

Re: [patch, nvptx] document "kernel" function attribute

[Nathan Sidwell]

On 01/06/16 23:43, Sandra Loosemore wrote:

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?


thanks.


+as a kernel function, which is callable by host code.

It's not directly callable.  Perhaps ', which is invokable by the host via the 
CUDA RT library'?


+By default, functions are compiled as device functions instead,
+which are callable only by other device code.

what are 'device functions'?  Perhaps something like
'By default functions are only callable from other PTX functions'.

nathan

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

[Bernd Schmidt]

On 01/07/2016 02:45 PM, Kyrill Tkachov wrote:


On 07/01/16 11:52, Bernd Schmidt wrote:

I looked and this is indeed the case. Still slightly scary. Should the
MEM be rtx_equal_p to TO_RENAME? It would be good to test or at least
assert this.



I tried asserting that and it caused trouble because a bit further up in
noce_process_if_block it does:
   /* Only operate on register destinations, and even then avoid extending
  the lifetime of hard registers on small register class machines.  */
   orig_x = x;
   if (!REG_P (x)
   || (HARD_REGISTER_P (x)
   && targetm.small_register_classes_for_mode_p (GET_MODE (x
 {
   if (GET_MODE (x) == BLKmode)
 return FALSE;

   if (GET_CODE (x) == ZERO_EXTRACT
   && (!CONST_INT_P (XEXP (x, 1))
   || !CONST_INT_P (XEXP (x, 2
 return FALSE;

   x = gen_reg_rtx (GET_MODE (GET_CODE (x) == STRICT_LOW_PART
  ? XEXP (x, 0) : x));
 }

It changes X to a register and after noce_try_cmove_arith it emits the
store.


This suggests that orig_x needs to be passed to bbs_ok_for_cmove_arith, 
even disregarding the question of using it to assert that only expected 
MEMs are being modified.



Bernd

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

[Kyrill Tkachov]

On 07/01/16 13:47, Bernd Schmidt wrote:

On 01/07/2016 02:45 PM, Kyrill Tkachov wrote:


On 07/01/16 11:52, Bernd Schmidt wrote:

I looked and this is indeed the case. Still slightly scary. Should the
MEM be rtx_equal_p to TO_RENAME? It would be good to test or at least
assert this.



I tried asserting that and it caused trouble because a bit further up in
noce_process_if_block it does:
   /* Only operate on register destinations, and even then avoid extending
  the lifetime of hard registers on small register class machines.  */
   orig_x = x;
   if (!REG_P (x)
   || (HARD_REGISTER_P (x)
   && targetm.small_register_classes_for_mode_p (GET_MODE (x
 {
   if (GET_MODE (x) == BLKmode)
 return FALSE;

   if (GET_CODE (x) == ZERO_EXTRACT
   && (!CONST_INT_P (XEXP (x, 1))
   || !CONST_INT_P (XEXP (x, 2
 return FALSE;

   x = gen_reg_rtx (GET_MODE (GET_CODE (x) == STRICT_LOW_PART
  ? XEXP (x, 0) : x));
 }

It changes X to a register and after noce_try_cmove_arith it emits the
store.


This suggests that orig_x needs to be passed to bbs_ok_for_cmove_arith, even 
disregarding the question of using it to assert that only expected MEMs are 
being modified.



Yes, which should be the original destinations of insn_a and insn_b of if_info.
I'll work on that. Though if we execute the above path then x will be a fresh 
new pseudo and so
will not cause any conflicts anyway.

Kyrill



Bernd

Re: RFA: PR 68913: Provide weak version of __fread_chk for PR61886 test

[Rainer Orth]

Hi Nick,

>>> +/* { dg-lto-options { { -flto -O2 -Werror -Wl,--defsym,__fread_chk=0x1234
>
>> this assumes GNU ld and will break on all targets that use different
>> linkers.
>
> OK, how about this version instead ?
>
> Cheers
>   Nick
>
> Index: gcc/testsuite/gcc.dg/lto/pr61886_0.c
> ===
> --- gcc/testsuite/gcc.dg/lto/pr61886_0.c(revision 232123)
> +++ gcc/testsuite/gcc.dg/lto/pr61886_0.c(working copy)
> @@ -1,5 +1,6 @@
>  /* { dg-lto-do link } */
>  /* { dg-lto-options { { -flto -O2 -Werror } } } */
> +/* { dg-extra-ld-options "-Wl,--defsym,__fread_chk=0x1234" { target { gld
> } } } */
>
>  typedef __SIZE_TYPE__ size_t;
>  typedef struct _IO_FILE FILE;

No, we're back at square one then, i.e. the failure reported in PR
testsuite/68913:

output is:
Undefined   first referenced
 symbol in file
__fread_chk c_lto_pr61886_0.o
ld: fatal: symbol referencing errors
collect2: error: ld returned 1 exit status

Rainer

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

Re: [PATCH] Fix #pragma implementation diagnostics (PR c++/69145, take 2)

[Bernd Schmidt]

On 01/07/2016 10:36 PM, Jakub Jelinek wrote:


I've also bootstrapped/regtested on x86_64-linux and i686-linux
following version:

2016-01-07  Jakub Jelinek  

PR c++/69145
* files.c (cpp_included_before): If IS_ADHOC_LOC (location), lookup
real location from the line_table.

* g++.dg/ext/pr69145-1.C: New test.
* g++.dg/ext/pr69145-2-very-long-filename.cc: New file.
* g++.dg/ext/pr69145-2.h: New file.


I think this is OK.


Bernd

Re: RFA: PR 68913: Provide weak version of __fread_chk for PR61886 test

[Jeff Law]

On 01/07/2016 06:37 AM, Nick Clifton wrote:

Hi Jeff,


But does the existence of the weak fread_chk change the interactions
inside IPA & LTO in such a way as to compromise the test?

One way to find out would be to check out a compiler before Honza's
change which fixed 61886, verify the test as written fails, verify the
test with your new weak symbol also fails.  Honza didn't fix this until
early December, so you don't have to go terribly far back.


Darn you and your clever brain...  You were right.  My patch prevents
the test from triggering the bug that was fixed by Honza's patch.

I wouldn't say clever, just paranoid around this particular issue.


So I have come up with an alternative, simpler patch - define the
__fread_chk symbol on the linker command line (overriding any definition
that may or may not be present in the target's C library). Since this is
a (final) link time redefinition rather than a compile time one, it does
not interfere with the IPA/LTO code.

This patch works.  I tested it both with an x86_64-pc-linux-gnu
toolchain and an arm-eabi toolchain both before Honza's patch was
committed (both targets fail the test) and with today's gcc sources
(both targets pass the test).

OK to apply ?
As folks noted, I think this is still specific to the linker in use. 
Does it make sense to just limit this test to specific platforms, 
perhaps just x86/i686 linux for now.  68913 mentions ppc64-linux fails, 
it'd be nice to know why since I'd expect that has the _chk symbols.




jeff

Re: RFA: PR 66655: Use COFF/PE weak symbols

[Jeff Law]

On 01/07/2016 05:15 AM, Nick Clifton wrote:

Hi Jeff,



The attached patch adds the test derived from the BZ.  There is one
small problem - I could not find a way to stop the additional source
file from being compiled as a test on its own.



I think for C++ code it's usually worked around by naming the
additional-source file with ".cc" rather than .C.  Can you give that a
quick whirl and see if that avoids having the additional file used as a
a test on its own?


Thanks - that worked. :-)

Revised test attached.  OK to apply ?

Yes.

jeff

[PATCH v2] libstdc++: Make certain exceptions transaction_safe.

[Torvald Riegel]

The attached patch makes some exceptions transaction-safe, as require by
the Transactional Memory TS.  I believe I addressed all feedback for the
previous version of this patch (in particular, there are now more safety
checks for preconditions for this implementation (eg, that the new
allocator is used), all exceptions declared by the TM TS are now
supported (with the exception of tx_exception -- should I add that in a
follow-up patch?), and there is a test for the new functionality (as
part of libitm's testsuite)).

There are two things that complicate such support.  First, it seems
better to not rely on -fgnu-tm of libstdc++ code for now (or at least we
tried to avoid this so far).  Therefore, the transactional clones in
this patch are all manually instrumented (ie, the functions are C
functions with names matching the mangled names of the respective C++
functions, and the _ZGTt prefix signaling that they are txnal clones).

Second, exceptions still use a COW string internally, which cannot be
made transaction-safe with just compiler support because of the
reference counting implementation inside of COW strings, which uses
atomics.  One would need something custom for that nonetheless.

Thus, the patch adds txnal clones as required.  They are new exported
symbols, but not visible to nontransactional code.  The only changes to
headers is transaction_safe[_dynamic] annotations where required by the
TS, and a few friend declarations.  The annotations are only enabled if
a user compiles with -fgnu-tm.  IOW, the changes are pretty much
invisible when not using the TM TS.

There are also commented-out calls to _ITM_setAssociatedException in the
code, which exist to show how we plan to support transaction
cancellation through exceptions (which needs some more libitm support
and bugfixes on the compiler side).

Tested on x86_64-linux and x86-linux.

OK?

2016-01-07  Torvald Riegel  

* include/bits/basic_string.h (basic_string): Declare friends.
* include/bits/c++config (_GLIBCXX_TXN_SAFE,
_GLIBCXX_TXN_SAFE_DYN, _GLIBCXX_USE_ALLOCATOR_NEW): New.
* include/std/stdexcept (logic_error, domain_error, invalid_argument,
length_error, out_of_range, runtime_error, range_error,
underflow_error, overflow_error): Declare members as transaction-safe.
(logic_error, runtime_error): Declare friend functions.
* libsupc++/exception (exception, bad_exception): Declare members as
transaction-safe.
* src/c++11/cow-stdexcept.cc: Define transactional clones for the
transaction-safe members of exceptions and helper functions.
* libsupc++/eh_exception.cc: Adjust and define transactional clones.
* config/abi/pre/gnu.ver (GLIBCXX_3.4.22) Add transactional clones.
(CXXABI_1.3.10): New.
* acinclude.m4 (GLIBCXX_CHECK_SIZE_T_MANGLING): New.
(GLIBCXX_ENABLE_ALLOCATOR): Set ENABLE_ALLOCATOR_NEW.
* configure.ac: Call GLIBCXX_CHECK_SIZE_T_MANGLING.
* include/Makefile.am: Write ENABLE_ALLOCATOR_NEW to c++config.h.
* include/Makefile.in: Regenerate.
* config.h.in: Regenerate.
* configure: Regenerate.

commit d4eda24eca5bf5d8d94f1d56762a9efd50294750
Author: Torvald Riegel 
Date:   Fri Nov 13 01:00:52 2015 +0100

libstdc++: Make certain exceptions transaction_safe.

diff --git a/libitm/testsuite/libitm.c++/libstdc++-safeexc.C b/libitm/testsuite/libitm.c++/libstdc++-safeexc.C
new file mode 100644
index 000..3e1655e
--- /dev/null
+++ b/libitm/testsuite/libitm.c++/libstdc++-safeexc.C
@@ -0,0 +1,89 @@
+// Tests that the exceptions declared by the TM TS (N4514) as transaction_safe
+// are indeed that.  Thus, this also tests the transactional clones in
+// libstdc++ and libsupc++.
+
+// { dg-do run }
+
+#include 
+#include 
+#include 
+#include 
+
+using namespace std;
+
+template void thrower(const T& t)
+{
+  try
+{
+  atomic_commit
+  {
+	throw t;
+  }
+}
+  catch (T ex)
+{
+  if (ex != t) abort ();
+}
+}
+
+template void thrower1(const string& what)
+{
+  try
+{
+  atomic_commit
+  {
+	throw T ();
+  }
+}
+  catch (T ex)
+{
+  if (what != ex.what()) abort ();
+}
+}
+
+template void thrower2(const string& what)
+{
+  try
+{
+  atomic_commit
+  {
+	throw T (what);
+  }
+}
+  catch (T ex)
+{
+  if (what != ex.what()) abort ();
+}
+}
+
+
+int main ()
+{
+  thrower (23);
+  thrower (23);
+  thrower (23);
+  thrower (23);
+  thrower (23);
+  thrower (23);
+  thrower (42);
+  thrower (42);
+  thrower (42);
+  thrower (42);
+  thrower (23.42);
+  thrower (23.42);
+  thrower (23.42);
+  thrower (0);
+  thrower (0);
+  thrower1 ("std::exception");
+  thrower1 ("std::bad_exception");
+  thrower2 ("test");
+  thrower2 ("test");
+  thrower2 ("test");
+  thrower2 ("test");
+  thrower2 ("test");
+  thrower2 ("test");
+  thrower2 ("test");
+  

Re: RFA: PR 68913: Provide weak version of __fread_chk for PR61886 test

[Nick Clifton]

Hi Jeff,


As folks noted, I think this is still specific to the linker in use.


True. :-(

I cannot think of any linker neutral way to add a link time symbol 
definition.  Any attempts to define the __fread_chk function via an 
object file will affects the ipa/lto code and prevent the test from working.


I did have one idea though - we could change the name of the function 
being tested from one that might not exist (__fread_chk) to one that 
definitely should exist (eg malloc).




Does it make sense to just limit this test to specific platforms,
perhaps just x86/i686 linux for now.



68913 mentions ppc64-linux fails,
it'd be nice to know why since I'd expect that has the _chk symbols.


Actually 68913 references any Solaris target, not ppc64-linux.

We could restrict the test to any target that has the GNU linker.  That 
would probably cover most targets, and since the actual bug being 
checked by the testcase is a generic one, not a target specific one, we 
can be reasonably confident that if the problem resurfaces it will be 
detected.


So, two possible alternative versions of the patch are proposed below. 
Do either take your fancy ?


Cheers
  Nick

Index: gcc/testsuite/gcc.dg/lto/pr61886_0.c
===
--- gcc/testsuite/gcc.dg/lto/pr61886_0.c(revision 232132)
+++ gcc/testsuite/gcc.dg/lto/pr61886_0.c(working copy)
@@ -1,6 +1,11 @@
-/* { dg-lto-do link } */
+/* { dg-lto-do link { target gld } } */
 /* { dg-lto-options { { -flto -O2 -Werror } } } */
+/* { dg-extra-ld-options "-Wl,--defsym,__fread_chk=0x1234" { target { 
gld } } } */


+/* This test is currently restricted to targets that use the GNU linker.
+   For the reason why see PR68913 and the gcc-patches thread starting here:
+ https://gcc.gnu.org/ml/gcc-patches/2016-01/msg00212.html  */
+
 typedef __SIZE_TYPE__ size_t;
 typedef struct _IO_FILE FILE;


Or

Index: gcc/testsuite/gcc.dg/lto/pr61886_0.c
===
--- gcc/testsuite/gcc.dg/lto/pr61886_0.c(revision 232132)
+++ gcc/testsuite/gcc.dg/lto/pr61886_0.c(working copy)
@@ -1,11 +1,10 @@
-/* { dg-lto-do link } */
+/* { dg-lto-do link { target gld } } */
 /* { dg-lto-options { { -flto -O2 -Werror } } } */
-
 typedef __SIZE_TYPE__ size_t;
 typedef struct _IO_FILE FILE;

-extern size_t __fread_chk (void *__restrict __ptr, size_t __ptrlen, 
size_t __size, size_t __n, FILE *__restrict __stream) __asm__ ("" 
"__fread_chk")  __attribute__ ((__warn_unused_result__));
-extern size_t __fread_chk_warn (void *__restrict __ptr, size_t 
__ptrlen, size_t __size, size_t __n, FILE *__restrict __stream) __asm__ 
("" "__fread_chk")  __attribute__ ((__warn_unused_result__)) 
__attribute__((__warning__ ("fread called with bigger size * nmemb than 
length " "of destination buffer")));
+extern size_t __malloc (void *__restrict __ptr, size_t __ptrlen, size_t 
__size, size_t __n, FILE *__restrict __stream) __asm__ ("") 
__attribute__ ((__warn_unused_result__));
+extern size_t __malloc_warn (void *__restrict __ptr, size_t __ptrlen, 
size_t __size, size_t __n, FILE *__restrict __stream) __asm__ ("") 
__attribute__ ((__warn_unused_result__)) __attribute__((__warning__ 
("fread called with bigger size * nmemb than length " "of destination 
buffer")));


 extern __inline __attribute__ ((__always_inline__)) __attribute__ 
((__gnu_inline__)) __attribute__ ((__artificial__)) __attribute__ 
((__warn_unused_result__))

 size_t
@@ -17,9 +16,9 @@
   if (!__builtin_constant_p (__size)
   || !__builtin_constant_p (__n)
   || (__size | __n) >= (((size_t) 1) << (8 * sizeof (size_t) / 
2)))
-return __fread_chk (__ptr, __builtin_object_size (__ptr, 0), 
__size, __n, __stream);
+return __malloc (__ptr, __builtin_object_size (__ptr, 0), 
__size, __n, __stream);

   if (__size * __n > __builtin_object_size (__ptr, 0))
-return __fread_chk_warn (__ptr, __builtin_object_size (__ptr, 
0), __size, __n, __stream);
+return __malloc_warn (__ptr, __builtin_object_size (__ptr, 0), 
__size, __n, __stream);

 }
 }

@@ -28,6 +27,6 @@
 int main ()
 {
   char file_contents[4096];

   char file_contents[4096];
-  /* We shouldn't get this resolved to a call to __fread_chk_warn.  */
+  /* We shouldn't get this resolved to a call to __malloc_warn.  */
   return fread (file_contents, 1, nmemb, fp);
 }

Re: RFA: PR 68913: Provide weak version of __fread_chk for PR61886 test

[Andreas Schwab]

Jeff Law  writes:

> 68913 mentions ppc64-linux fails, it'd be nice to know why since I'd
> expect that has the _chk symbols.

It doesn't fail for me (and gcc-testresults has no hits).

Andreas.

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

C PATCH to rectify warning for character types (PR c/23087)

[Marek Polacek]

This PR points out that we issue a wrong warning message when assigning
two pointers when one of them is plain char.  In that case, the compiler
currently says that pointer targets differ in signedness.  But that is
not correct; char is a separate type from (un)signed char and is not
compatible with either.  So we should instead say that the pointer types
are not compatible.

This effectively means that I'm turning a -Wpointer-sign warning into
a -Wincompatible-pointer-types warning.  But -Wincompatible-pointer-types
is a warning that is enabled by default and -Wpointer-sign is enabled by
-Wpedantic || -Wall.  So with this, we'd be more verbose and would warn
by default on e.g. "unsigned char *p = "foo";."  Not sure if that is
desirable at this stage, so I'm leaning towards pushing this patch for
GCC7.

I've fixed various fallout, but on x86_64 only so far; the ppc64le machine
on the compile farm is currently unusable.

Bootstrapped/regtested on x86_64-linux.

2016-01-07  Marek Polacek  

PR c/23087
* c-typeck.c (convert_for_assignment): Don't consider char and
(un)signed char as compatible types.

* gcc.dg/Wno-pointer-sign.c: Change dg-bogus to dg-warning and adjust
the message.
* gcc.dg/assign-warn-1.c: Adjust dg-warnings.
* gcc.dg/assign-warn-2.c: Adjust dg-errors.
* gcc.dg/conv-2.c: Adjust dg-warnings.
* gcc.dg/pr23087.c: New test.
* gcc.dg/pr28726.c: Add dg-warning.
* gcc.dg/torture/pr64853.c: Likewise.
* gcc.dg/torture/pr49603.c: Use unsigned char instead of char.
* gcc.target/i386/avx2-mpsadbw-2.c: Likewise.
* gcc.target/i386/avx2-vpaddusb-2.c: Add cast to avoid warning.
* gcc.target/i386/avx2-vpavgb-2.c: Likewise.
* gcc.target/i386/avx2-vpmaxub-2.c: Likewise.
* gcc.target/i386/avx2-vpminub-2.c: Likewise.
* gcc.target/i386/avx2-vpmovzxbd-2.c: Likewise.
* gcc.target/i386/avx2-vpmovzxbq-2.c: Likewise.
* gcc.target/i386/avx2-vpmovzxbw-2.c: Likewise.
* gcc.target/i386/avx2-vpsadbw-2.c: Likewise.
* gcc.target/i386/avx2-vpsubusb-2.c: Likewise.
* gcc.target/i386/avx512f-vpmovusdb-2.c: Likewise.

diff --git gcc/c/c-typeck.c gcc/c/c-typeck.c
index 952041b..36001d2 100644
--- gcc/c/c-typeck.c
+++ gcc/c/c-typeck.c
@@ -6434,7 +6434,11 @@ convert_for_assignment (location_t location, location_t 
expr_loc, tree type,
   == c_common_unsigned_type (mvr))
  && (c_common_signed_type (mvl)
  == c_common_signed_type (mvr))
- && TYPE_ATOMIC (mvl) == TYPE_ATOMIC (mvr)))
+ && TYPE_ATOMIC (mvl) == TYPE_ATOMIC (mvr)
+ /* char is a separate type and not compatible with signed char
+or unsigned char.  */
+ && mvl != char_type_node
+ && mvr != char_type_node))
{
  /* Warn about loss of qualifers from pointers to arrays with
 qualifiers on the element type. */
diff --git gcc/testsuite/gcc.dg/Wno-pointer-sign.c 
gcc/testsuite/gcc.dg/Wno-pointer-sign.c
index 780c9d4..c9f02a4 100644
--- gcc/testsuite/gcc.dg/Wno-pointer-sign.c
+++ gcc/testsuite/gcc.dg/Wno-pointer-sign.c
@@ -17,10 +17,10 @@ int main()
   f1(ulp); /* { dg-bogus " differ in signedness" } */
   f2(lp);  /* { dg-bogus " differ in signedness" } */
 
-  cp = ucp;/* { dg-bogus " pointer targets in assignment differ in 
signedness" } */
-  cp = scp;/* { dg-bogus " pointer targets in assignment differ in 
signedness" } */
+  cp = ucp;/* { dg-warning "assignment from incompatible pointer type" } */
+  cp = scp;/* { dg-warning "assignment from incompatible pointer type" } */
   ucp = scp;   /* { dg-bogus " pointer targets in assignment differ in 
signedness" } */
-  ucp = cp;/* { dg-bogus " pointer targets in assignment differ in 
signedness" } */
+  ucp = cp;/* { dg-warning "assignment from incompatible pointer type" } */
   scp = ucp;   /* { dg-bogus " pointer targets in assignment differ in 
signedness" } */
-  scp = cp;/* { dg-bogus " pointer targets in assignment differ in 
signedness" } */
+  scp = cp;/* { dg-warning "assignment from incompatible pointer type" } */
 }
diff --git gcc/testsuite/gcc.dg/assign-warn-1.c 
gcc/testsuite/gcc.dg/assign-warn-1.c
index f26a544..ce540cb 100644
--- gcc/testsuite/gcc.dg/assign-warn-1.c
+++ gcc/testsuite/gcc.dg/assign-warn-1.c
@@ -60,29 +60,29 @@ TESTASS(usc, unsigned int *, int *); /* { dg-warning 
"pointer targets in assignm
 TESTINI(usd, unsigned int *, int *); /* { dg-warning "pointer targets in 
initialization differ in signedness" } */
 TESTRET(use, unsigned int *, int *); /* { dg-warning "pointer targets in 
return differ in signedness" } */
 
-TESTARG(cua, char *, unsigned char *); /* { dg-warning "pointer targets in 
passing argument 1 of 'cuaF' differ in signedness" } */
-TESTARP(cub, char *, unsigned char *); /* { dg-warning "pointer targets in 

Re: RFA (tree-cfg): PATCH for 68983 (ICE in copy constructor)

[Eric Botcazou]

> But it occurs to me that since the real problem I was trying to catch is
> creation of temporaries of TREE_ADDRESSABLE type in the back end, we
> should guard that instead.  So this patch moves the assert into assign_temp.

FWIW create_tmp_var has a slightly stronger version:

  gcc_assert (!TREE_ADDRESSABLE (type) && COMPLETE_TYPE_P (type));

-- 
Eric Botcazou

RFA (tree-cfg): PATCH for 68983 (ICE in copy constructor)

[Jason Merrill]

This testcase was broken by my earlier fix for 67557, which added an 
assert to store_field to catch inappropriate use of bitwise copying of 
TREE_ADDRESSABLE types.  In this testcase, the copying is actually fine, 
since no temporary object is created.  So one solution would be to 
recognize that situation better.


But it occurs to me that since the real problem I was trying to catch is 
creation of temporaries of TREE_ADDRESSABLE type in the back end, we 
should guard that instead.  So this patch moves the assert into assign_temp.


That change revealed a couple of places that needed to be adjusted: 
convert_to_void in the front end and fixup_noreturn_call in the back end 
were removing the information about what object is being initialized by 
a function that returns by invisible reference.  If we are insisting 
that objects of TREE_ADDRESSABLE type need to be created in the front 
end, these places need to not strip that information.


Tested x86_64-pc-linux-gnu.  OK for trunk?
commit 1e437dea62b2c4abb2122c276e58b59e3769eb97
Author: Jason Merrill 
Date:   Thu Jan 7 09:46:59 2016 -0500

	PR c++/68983
	PR c++/67557
gcc/
	* function.c (assign_temp): Guard against TREE_ADDRESSABLE types here.
	* expr.c (store_field): Not here.
	* tree-cfgcleanup.c (fixup_noreturn_call): Don't clear LHS of a
	call with TREE_ADDRESSABLE type.
	* tree-cfg.c (verify_gimple_call): Adjust.
gcc/cp/
	* cvt.c (convert_to_void): Don't strip a TARGET_EXPR of
	TREE_ADDRESSABLE type.

diff --git a/gcc/cp/cvt.c b/gcc/cp/cvt.c
index d79f13b..f381f9b 100644
--- a/gcc/cp/cvt.c
+++ b/gcc/cp/cvt.c
@@ -1229,11 +1229,12 @@ convert_to_void (tree expr, impl_conv_void implicit, tsubst_flags_t complain)
 
 case TARGET_EXPR:
   /* Don't bother with the temporary object returned from a function if
-	 we don't use it and don't need to destroy it.  We'll still
+	 we don't use it, don't need to destroy it, and won't abort in
+	 assign_temp.  We'll still
 	 allocate space for it in expand_call or declare_return_variable,
 	 but we don't need to track it through all the tree phases.  */
   if (TARGET_EXPR_IMPLICIT_P (expr)
-	  && TYPE_HAS_TRIVIAL_DESTRUCTOR (TREE_TYPE (expr)))
+	  && !TREE_ADDRESSABLE (TREE_TYPE (expr)))
 	{
 	  tree init = TARGET_EXPR_INITIAL (expr);
 	  if (TREE_CODE (init) == AGGR_INIT_EXPR
diff --git a/gcc/expr.c b/gcc/expr.c
index 8973893..0c5dff8 100644
--- a/gcc/expr.c
+++ b/gcc/expr.c
@@ -6655,9 +6655,6 @@ store_field (rtx target, HOST_WIDE_INT bitsize, HOST_WIDE_INT bitpos,
   rtx temp;
   gimple *nop_def;
 
-  /* Using bitwise copy is not safe for TREE_ADDRESSABLE types.  */
-  gcc_assert (!TREE_ADDRESSABLE (TREE_TYPE (exp)));
-
   /* If EXP is a NOP_EXPR of precision less than its mode, then that
 	 implies a mask operation.  If the precision is the same size as
 	 the field we're storing into, that mask is redundant.  This is
diff --git a/gcc/function.c b/gcc/function.c
index 603ea80..bffd617 100644
--- a/gcc/function.c
+++ b/gcc/function.c
@@ -956,6 +956,10 @@ assign_temp (tree type_or_decl, int memory_required,
   unsignedp = TYPE_UNSIGNED (type);
 #endif
 
+  /* Allocating temporaries of TREE_ADDRESSABLE type must be done
+ in the front end.  */
+  gcc_assert (!TREE_ADDRESSABLE (type));
+
   if (mode == BLKmode || memory_required)
 {
   HOST_WIDE_INT size = int_size_in_bytes (type);
diff --git a/gcc/testsuite/g++.dg/init/base1.C b/gcc/testsuite/g++.dg/init/base1.C
new file mode 100644
index 000..bce2f17
--- /dev/null
+++ b/gcc/testsuite/g++.dg/init/base1.C
@@ -0,0 +1,14 @@
+// PR c++/68983
+
+class SvxOptionsGrid {
+  int nFldDrawX;
+  bool bEqualGrid;
+public:
+  ~SvxOptionsGrid();
+};
+class A : SvxOptionsGrid {
+public:
+  A(SvxOptionsGrid p1) : SvxOptionsGrid(p1) {}
+};
+SvxOptionsGrid a;
+void fn1() { A b(a); }
diff --git a/gcc/tree-cfg.c b/gcc/tree-cfg.c
index e75774e..dbfa506 100644
--- a/gcc/tree-cfg.c
+++ b/gcc/tree-cfg.c
@@ -3371,7 +3371,8 @@ verify_gimple_call (gcall *stmt)
   if (lhs
   && gimple_call_ctrl_altering_p (stmt)
   && gimple_call_noreturn_p (stmt)
-  && TREE_CODE (TYPE_SIZE_UNIT (TREE_TYPE (lhs))) == INTEGER_CST)
+  && TREE_CODE (TYPE_SIZE_UNIT (TREE_TYPE (lhs))) == INTEGER_CST
+  && !TREE_ADDRESSABLE (TREE_TYPE (lhs)))
 {
   error ("LHS in noreturn call");
   return true;
diff --git a/gcc/tree-cfgcleanup.c b/gcc/tree-cfgcleanup.c
index bd7c3c9..46d0fa3 100644
--- a/gcc/tree-cfgcleanup.c
+++ b/gcc/tree-cfgcleanup.c
@@ -601,9 +601,11 @@ fixup_noreturn_call (gimple *stmt)
 
   /* If there is an LHS, remove it, but only if its type has fixed size.
  The LHS will need to be recreated during RTL expansion and creating
- temporaries of variable-sized types is not supported.  */
+ temporaries of variable-sized types is not supported.  Also don't
+ do this with TREE_ADDRESSABLE types, as assign_temp will abort.  */
   tree lhs = gimple_call_lhs 

[gomp4] reductions on explicitly private variables

[Cesar Philippidis]

I noticed that libgomp is lacking test coverage reductions involving
explicitly private variables. E.g.

#pragma acc parallel copyout(red)
  {
#pragma acc loop gang private(v)
for (j = 0; j < 10; j++)
  {
v = j;

#pragma acc loop vector reduction (+:v)
for (i = 0; i < 100; i++)
  v++;

red[j] = v;
  }
  }

This used to case a problem in lower_oacc_reductions because the
reduction finalizer wasn't updating the correct variable. The attached
patch fixes it.

I've applied this patch to gomp-4_0-branch.

Cesar
2016-01-07  Cesar Philippidis  

	gcc/
	* omp-low.c (lower_oacc_reductions): Handle explicitly private
	reduction varaibles.

	libgomp/
	* testsuite/libgomp.oacc-c-c++-common/reduction-6.c: New test.
	* testsuite/libgomp.oacc-fortran/reduction-7.f90: Add a test with
	an explicitly private reduction variable.

diff --git a/gcc/omp-low.c b/gcc/omp-low.c
index bbfd642..0be25b8 100644
--- a/gcc/omp-low.c
+++ b/gcc/omp-low.c
@@ -5616,9 +5616,15 @@ lower_oacc_reductions (location_t loc, tree clauses, tree level, bool inner,
 		
 		outer = probe;
 		for (; cls;  cls = OMP_CLAUSE_CHAIN (cls))
-		  if (OMP_CLAUSE_CODE (cls) == OMP_CLAUSE_REDUCTION
-		  && orig == OMP_CLAUSE_DECL (cls))
-		goto has_outer_reduction;
+		  {
+		if (OMP_CLAUSE_CODE (cls) == OMP_CLAUSE_REDUCTION
+			&& orig == OMP_CLAUSE_DECL (cls))
+		  goto has_outer_reduction;
+		else if (OMP_CLAUSE_CODE (cls) == OMP_CLAUSE_PRIVATE
+			&& orig == OMP_CLAUSE_DECL (cls)
+			&& gimple_code (outer->stmt) != GIMPLE_OMP_TARGET)
+		  goto has_outer_reduction;
+		  }
 	  }
 
 	  do_lookup:
diff --git a/libgomp/testsuite/libgomp.oacc-c-c++-common/reduction-6.c b/libgomp/testsuite/libgomp.oacc-c-c++-common/reduction-6.c
new file mode 100644
index 000..af30b31
--- /dev/null
+++ b/libgomp/testsuite/libgomp.oacc-c-c++-common/reduction-6.c
@@ -0,0 +1,36 @@
+/* { dg-do run } */
+/* { dg-additional-options "-w" } */
+
+/* Test reductions on explicitly private variables.  */
+
+#include 
+
+int
+main ()
+{
+  int i, j, red[10];
+  int v;
+
+  for (i = 0; i < 10; i++)
+red[i] = -1;
+
+#pragma acc parallel copyout(red)
+  {
+#pragma acc loop gang private(v)
+for (j = 0; j < 10; j++)
+  {
+	v = j;
+
+#pragma acc loop vector reduction (+:v)
+	for (i = 0; i < 100; i++)
+	  v++;
+
+	red[j] = v;
+  }
+  }
+
+  for (i = 0; i < 10; i++)
+assert (red[i] == i + 100);
+
+  return 0;
+}
diff --git a/libgomp/testsuite/libgomp.oacc-fortran/reduction-7.f90 b/libgomp/testsuite/libgomp.oacc-fortran/reduction-7.f90
index e80004d..8ec36ad 100644
--- a/libgomp/testsuite/libgomp.oacc-fortran/reduction-7.f90
+++ b/libgomp/testsuite/libgomp.oacc-fortran/reduction-7.f90
@@ -1,12 +1,13 @@
 ! { dg-do run }
 ! { dg-additional-options "-w" }
 
-! subroutine reduction with firstprivate variables
+! subroutine reduction with private and firstprivate variables
 
 program reduction
   integer, parameter:: n = 100
   integer   :: i, j, vsum, cs, arr(n)
 
+  call redsub_private (cs, n, arr)
   call redsub_bogus (cs, n)
   call redsub_combined (cs, n, arr)
 
@@ -22,6 +23,33 @@ program reduction
   end do
 end program reduction
 
+! This subroutine tests a reduction with an explicit private variable.
+
+subroutine redsub_private(sum, n, arr)
+  integer :: sum, n, arr(n)
+  integer :: i, j, v
+
+  !$acc parallel copyout (arr)
+  !$acc loop gang private (v)
+  do j = 1, n
+ v = j
+
+ !$acc loop vector reduction (+:v)
+ do i = 1, 100
+v = v + 1
+ end do
+
+ arr(j) = v
+  end do
+  !$acc end parallel
+
+  ! verify the results
+  do i = 1, 10
+ if (arr(i) .ne. 100+i) call abort ()
+  end do
+end subroutine redsub_private
+
+
 ! Bogus reduction on an impliclitly firstprivate variable.  The results do
 ! survive the parallel region.  The goal here is to ensure that gfortran
 ! doesn't ICE.

Re: [patch] ARM FreeBSD fix bootstrap

[Andreas Tobler]

On 06.01.16 11:39, Richard Earnshaw (lists) wrote:

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.


Done:
https://gcc.gnu.org/viewcvs/gcc?view=revision=232141

Thank you,
Andreas

Re: [patch, nvptx] document "kernel" function attribute

[Nathan Sidwell]

On 01/07/16 12:54, Sandra Loosemore wrote:

On 01/07/2016 06:48 AM, Nathan Sidwell wrote:

On 01/06/16 23:43, Sandra Loosemore wrote:

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?


thanks.


+as a kernel function, which is callable by host code.

It's not directly callable.  Perhaps ', which is invokable by the host
via the CUDA RT library'?

+By default, functions are compiled as device functions instead,
+which are callable only by other device code.

what are 'device functions'?  Perhaps something like
'By default functions are only callable from other PTX functions'.


How about this version?


works for me, thanks

Re: [PATCH committed] Bug 66680 - [5 Regression] ICE with openmp, a loop and a type bound procedure

[Dominique d'Humières]

> Le 7 janv. 2016 à 19:02, H.J. Lu  a écrit :
> 
> On Thu, Jan 7, 2016 at 9:59 AM, H.J. Lu  wrote:
>> On Thu, Jan 7, 2016 at 5:30 AM, Dominique d'Humières  
>> wrote:
>>> I have committed the following patch to trunk. I am planning to commit it 
>>> to the gcc5 branch and close the PR as FIXED next sunday if there is no 
>>> objection.
>>> 
>>> Cheers,
>>> 
>>> Dominique
>>> 
>>> Index: gcc/testsuite/ChangeLog
>>> ===
>>> --- gcc/testsuite/ChangeLog (revision 232126)
>>> +++ gcc/testsuite/ChangeLog (working copy)
>>> @@ -1,3 +1,8 @@
>>> +2016-01-07  Dominique d'Humieres 
>>> +
>>> +   PR fortran/66680
>>> +   gfortran.dg/gomp/pr66680.f90: New test.
>>> +
>>> 2016-01-07  H.J. Lu  
>>> 
>>>PR target/69171
>> 
>> I got
>> 
>> gfortran: error: libgomp.spec: No such file or directory^M
>> 
>> FAIL: gfortran.dg/gomp/pr66680.f90   -O0  (test for excess errors)
>> 
> 
> Shouldn't gomp run-time test be in libgomp/testsuite/libgomp.fortran?

May be. The test succeeds for me in gfortran.dg/gomp/, but I don’t know why.

Nevertheless I’ll move it to libgomp/testsuite/libgomp.fortran after testing.

Dominique

> 
> -- 
> H.J.

Re: [patch, nvptx] document "kernel" function attribute

[Sandra Loosemore]

On 01/07/2016 06:48 AM, Nathan Sidwell wrote:

On 01/06/16 23:43, Sandra Loosemore wrote:

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?


thanks.


+as a kernel function, which is callable by host code.

It's not directly callable.  Perhaps ', which is invokable by the host
via the CUDA RT library'?

+By default, functions are compiled as device functions instead,
+which are callable only by other device code.

what are 'device functions'?  Perhaps something like
'By default functions are only callable from other PTX functions'.


How about this version?

-Sandra

2016-01-07  Sandra Loosemore 

	PR 1078
	gcc/
	* doc/extend.texi (Nvidia PDX Function Attributes): New section.
Index: gcc/doc/extend.texi
===
--- gcc/doc/extend.texi	(revision 232134)
+++ 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,22 @@ 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 can be invoked from the host via the CUDA RT 
+library.
+By default functions are only callable only from other PTX functions.
+
+Kernel functions must have @code{void} return type.
+@end table
+
 @node PowerPC Function Attributes
 @subsection PowerPC Function Attributes
 

Re: [PATCH committed] Bug 66680 - [5 Regression] ICE with openmp, a loop and a type bound procedure

[H.J. Lu]

On Thu, Jan 7, 2016 at 10:07 AM, Jakub Jelinek  wrote:
> On Thu, Jan 07, 2016 at 10:02:23AM -0800, H.J. Lu wrote:
>> On Thu, Jan 7, 2016 at 9:59 AM, H.J. Lu  wrote:
>> > On Thu, Jan 7, 2016 at 5:30 AM, Dominique d'Humières  
>> > wrote:
>> >> I have committed the following patch to trunk. I am planning to commit it 
>> >> to the gcc5 branch and close the PR as FIXED next sunday if there is no 
>> >> objection.
>> >>
>> >> Cheers,
>> >>
>> >> Dominique
>> >>
>> >> Index: gcc/testsuite/ChangeLog
>> >> ===
>> >> --- gcc/testsuite/ChangeLog (revision 232126)
>> >> +++ gcc/testsuite/ChangeLog (working copy)
>> >> @@ -1,3 +1,8 @@
>> >> +2016-01-07  Dominique d'Humieres 
>> >> +
>> >> +   PR fortran/66680
>> >> +   gfortran.dg/gomp/pr66680.f90: New test.
>> >> +
>> >>  2016-01-07  H.J. Lu  
>> >>
>> >> PR target/69171
>> >
>> > I got
>> >
>> > gfortran: error: libgomp.spec: No such file or directory^M
>> >
>> > FAIL: gfortran.dg/gomp/pr66680.f90   -O0  (test for excess errors)
>> >
>>
>> Shouldn't gomp run-time test be in libgomp/testsuite/libgomp.fortran?
>
> Of course.  Patch to move it there preapproved.
>
> Jakub

Done.

-- 
H.J.

[gomp4] Fix use of declare'd vars by routine procedures.

[James Norris]

Hi!

The checking of variables declared by OpenACC declare directives
used within an OpenACC routine procedure was not being done correctly.
This fix adds the checking required and also adds to the testing.

This fix resolves the issue pointed out by Cesar with declare-4.c
(https://gcc.gnu.org/ml/gcc-patches/2016-01/msg00339.html).

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

Thanks,
Jim

Index: gcc/c/ChangeLog.gomp
===
--- gcc/c/ChangeLog.gomp	(revision 232138)
+++ gcc/c/ChangeLog.gomp	(working copy)
@@ -1,3 +1,8 @@
+2016-01-07  James Norris  
+
+	* c-parser.c (c_finish_oacc_routine): Add new attribute.
+	* c-typeck.c (build_external_ref): Add usage check.
+
 2015-12-08  Thomas Schwinge  
 
 	* c-parser.c (c_parser_oacc_clause_bind, c_parser_oacc_routine)
Index: gcc/c/c-parser.c
===
--- gcc/c/c-parser.c	(revision 232138)
+++ gcc/c/c-parser.c	(working copy)
@@ -14115,6 +14115,10 @@
   /* Also add an "omp declare target" attribute, with clauses.  */
   DECL_ATTRIBUTES (fndecl) = tree_cons (get_identifier ("omp declare target"),
 	clauses, DECL_ATTRIBUTES (fndecl));
+
+  DECL_ATTRIBUTES (fndecl)
+= tree_cons (get_identifier ("oacc routine"),
+		 clauses, DECL_ATTRIBUTES (fndecl));
 }
 
 /* OpenACC 2.0:
Index: gcc/c/c-typeck.c
===
--- gcc/c/c-typeck.c	(revision 232138)
+++ gcc/c/c-typeck.c	(working copy)
@@ -2664,6 +2664,26 @@
   tree ref;
   tree decl = lookup_name (id);
 
+  if (decl
+  && decl != error_mark_node
+  && current_function_decl
+  && TREE_CODE (decl) == VAR_DECL
+  && is_global_var (decl)
+  && lookup_attribute ("oacc routine",
+			   DECL_ATTRIBUTES (current_function_decl)))
+{
+  if (lookup_attribute ("omp declare target link",
+			DECL_ATTRIBUTES (decl))
+	  || ((!lookup_attribute ("omp declare target",
+  DECL_ATTRIBUTES (decl))
+	   && ((TREE_STATIC (decl) && !DECL_EXTERNAL (decl))
+		   || (!TREE_STATIC (decl) && DECL_EXTERNAL (decl))
+	{
+	  error_at (loc, "invalid use in % function");
+	  return error_mark_node;
+	}
+}
+
   /* In Objective-C, an instance variable (ivar) may be preferred to
  whatever lookup_name() found.  */
   decl = objc_lookup_ivar (decl, id);
Index: gcc/cp/ChangeLog.gomp
===
--- gcc/cp/ChangeLog.gomp	(revision 232138)
+++ gcc/cp/ChangeLog.gomp	(working copy)
@@ -1,3 +1,8 @@
+2016-01-07  James Norris  
+
+	* parser.c (cp_finalize_oacc_routine): Add new attribute.
+	* semantics.c (finish_id_expression): Add usage check.
+
 2016-01-07  Cesar Philippidis  
 
 	* cp-tree.h (bind_decls_match): Declare.
Index: gcc/cp/parser.c
===
--- gcc/cp/parser.c	(revision 232138)
+++ gcc/cp/parser.c	(working copy)
@@ -36732,6 +36732,10 @@
   DECL_ATTRIBUTES (fndecl)
 	= tree_cons (get_identifier ("omp declare target"),
 		 clauses, DECL_ATTRIBUTES (fndecl));
+
+  DECL_ATTRIBUTES (fndecl)
+	= tree_cons (get_identifier ("oacc routine"),
+		 NULL_TREE, DECL_ATTRIBUTES (fndecl));
 }
 }
 
Index: gcc/cp/semantics.c
===
--- gcc/cp/semantics.c	(revision 232138)
+++ gcc/cp/semantics.c	(working copy)
@@ -3700,6 +3700,25 @@
 
 	  decl = convert_from_reference (decl);
 	}
+
+  if (decl != error_mark_node
+	  && current_function_decl
+	  && TREE_CODE (decl) == VAR_DECL
+	  && is_global_var (decl)
+	  && lookup_attribute ("oacc routine",
+			   DECL_ATTRIBUTES (current_function_decl)))
+	{
+	  if (lookup_attribute ("omp declare target link",
+DECL_ATTRIBUTES (decl))
+	  || ((!lookup_attribute ("omp declare target",
+  DECL_ATTRIBUTES (decl))
+		   && ((TREE_STATIC (decl) && !DECL_EXTERNAL (decl))
+			|| (!TREE_STATIC (decl) && DECL_EXTERNAL (decl))
+	{
+	  *error_msg = "invalid use in % function";
+	  return error_mark_node;
+	}
+	}
 }
 
   return cp_expr (decl, location);
Index: gcc/testsuite/ChangeLog.gomp
===
--- gcc/testsuite/ChangeLog.gomp	(revision 232138)
+++ gcc/testsuite/ChangeLog.gomp	(working copy)
@@ -1,3 +1,7 @@
+2016-01-07  James Norris  
+
+	* c-c++-common/goacc/routine-5.c: Additional tests.
+
 2016-01-07  Cesar Philippidis  
 
 	* g++.dg/goacc/routine-2.C: Add more coverage.
Index: gcc/testsuite/c-c++-common/goacc/routine-5.c
===
--- gcc/testsuite/c-c++-common/goacc/routine-5.c	(revision 232138)
+++ gcc/testsuite/c-c++-common/goacc/routine-5.c	(working copy)
@@ -59,3 +59,49 @@
 

Re: [PATCH committed] Bug 66680 - [5 Regression] ICE with openmp, a loop and a type bound procedure

[H.J. Lu]

On Thu, Jan 7, 2016 at 5:30 AM, Dominique d'Humières  wrote:
> I have committed the following patch to trunk. I am planning to commit it to 
> the gcc5 branch and close the PR as FIXED next sunday if there is no 
> objection.
>
> Cheers,
>
> Dominique
>
> Index: gcc/testsuite/ChangeLog
> ===
> --- gcc/testsuite/ChangeLog (revision 232126)
> +++ gcc/testsuite/ChangeLog (working copy)
> @@ -1,3 +1,8 @@
> +2016-01-07  Dominique d'Humieres 
> +
> +   PR fortran/66680
> +   gfortran.dg/gomp/pr66680.f90: New test.
> +
>  2016-01-07  H.J. Lu  
>
> PR target/69171

I got

gfortran: error: libgomp.spec: No such file or directory^M

FAIL: gfortran.dg/gomp/pr66680.f90   -O0  (test for excess errors)

-- 
H.J.

[C++ PATCH] Fix ICE with bitfields (PR c++/69164)

[Jakub Jelinek]

Hi!

We ICE on the following testcase during SRA, because it sees a field
with DECL_SIZE of 1 which is not DECL_BIT_FIELD.  The problem is that
layout_class_type in some cases copies fields, including DECL_SIZE, but does
not copy over DECL_BIT_FIELD flag.  The following patch copies even that
and also DECL_SIZE_UNIT and DEC_BIT_FIELD_TYPE that weren't copied either.

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

2016-01-07  Jakub Jelinek  

PR c++/69164
* class.c (layout_class_type): Also copy DEC_SIZE_UNIT, DECL_BIT_FIELD
and DEC_BIT_FIELD_TYPE.

* g++.dg/opt/pr69164.C: New test.

--- gcc/cp/class.c.jj   2016-01-04 14:55:57.0 +0100
+++ gcc/cp/class.c  2016-01-07 13:59:13.895677297 +0100
@@ -6493,7 +6493,10 @@ layout_class_type (tree t, tree *virtual
DECL_FIELD_BIT_OFFSET (*next_field)
  = DECL_FIELD_BIT_OFFSET (field);
DECL_SIZE (*next_field) = DECL_SIZE (field);
+   DECL_SIZE_UNIT (*next_field) = DECL_SIZE_UNIT (field);
DECL_MODE (*next_field) = DECL_MODE (field);
+   DECL_BIT_FIELD (*next_field) = DECL_BIT_FIELD (field);
+   DECL_BIT_FIELD_TYPE (*next_field) = DECL_BIT_FIELD_TYPE (field);
next_field = _CHAIN (*next_field);
  }
 
--- gcc/testsuite/g++.dg/opt/pr69164.C.jj   2016-01-07 13:56:33.013915214 
+0100
+++ gcc/testsuite/g++.dg/opt/pr69164.C  2016-01-07 13:55:57.0 +0100
@@ -0,0 +1,30 @@
+// PR c++/69164
+// { dg-do compile { target c++11 } }
+// { dg-options "-O2" }
+
+struct A {
+  struct B {
+B () {}
+bool : 1;
+  };
+  B foo () { B r; return r; }
+};
+
+struct C {
+  struct D {
+D (C *x) : d (x->c.foo ()) {}
+A::B d;
+  };
+  A c;
+};
+
+struct F : C {
+  D f = this;
+  F (int, int) {}
+};
+
+void
+bar (int a, int b)
+{
+  F (b, a);
+}

Jakub

[PATCH] Fix ICE with va_arg (PR tree-optimization/69162)

[Jakub Jelinek]

Hi!

The addition of IFN_VA_ARG which is only during stdarg pass lowered
introduced ICE on the following testcase.  The problem is that
we expected that the type the first argument of the internal call points
to will remain the one that used to be there during gimplification, but
as pointer conversions are useless, that is not guaranteed, it can become
void * or any other pointer type.

Fixed by remembering the type on another argument.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

2016-01-07  Jakub Jelinek  

PR tree-optimization/69162
* gimplify.c (gimplify_va_arg_expr): Encode original type of
valist argument in another argument.
(gimplify_modify_expr): Adjust for the above change.  Cleanup.
* tree-stdarg.c (expand_ifn_va_arg_1): Use new 3rd argument
to determine the va_list type, build a MEM_REF instead of
build_fold_indirect_ref.

* gcc.dg/pr69162.c: New test.

--- gcc/gimplify.c.jj   2016-01-04 14:55:53.0 +0100
+++ gcc/gimplify.c  2016-01-07 15:19:17.283215609 +0100
@@ -4724,12 +4724,12 @@ gimplify_modify_expr (tree *expr_p, gimp
  tree type = TREE_TYPE (call);
  tree ap = CALL_EXPR_ARG (call, 0);
  tree tag = CALL_EXPR_ARG (call, 1);
+ tree aptag = CALL_EXPR_ARG (call, 2);
  tree newcall = build_call_expr_internal_loc (EXPR_LOCATION (call),
   IFN_VA_ARG, type,
   nargs + 1, ap, tag,
-  vlasize);
- tree *call_p = &(TREE_OPERAND (*from_p, 0));
- *call_p = newcall;
+  aptag, vlasize);
+ TREE_OPERAND (*from_p, 0) = newcall;
}
 }
 
@@ -11501,7 +11501,7 @@ gimplify_va_arg_expr (tree *expr_p, gimp
   tree promoted_type, have_va_type;
   tree valist = TREE_OPERAND (*expr_p, 0);
   tree type = TREE_TYPE (*expr_p);
-  tree t, tag;
+  tree t, tag, aptag;
   location_t loc = EXPR_LOCATION (*expr_p);
 
   /* Verify that valist is of the proper type.  */
@@ -11555,7 +11555,10 @@ gimplify_va_arg_expr (tree *expr_p, gimp
 }
 
   tag = build_int_cst (build_pointer_type (type), 0);
-  *expr_p = build_call_expr_internal_loc (loc, IFN_VA_ARG, type, 2, valist, 
tag);
+  aptag = build_int_cst (TREE_TYPE (valist), 0);
+
+  *expr_p = build_call_expr_internal_loc (loc, IFN_VA_ARG, type, 3,
+ valist, tag, aptag);
 
   /* Clear the tentatively set PROP_gimple_lva, to indicate that IFN_VA_ARG
  needs to be expanded.  */
--- gcc/tree-stdarg.c.jj2016-01-04 14:55:52.0 +0100
+++ gcc/tree-stdarg.c   2016-01-07 15:20:14.340424740 +0100
@@ -1018,7 +1018,7 @@ expand_ifn_va_arg_1 (function *fun)
 for (i = gsi_start_bb (bb); !gsi_end_p (i); gsi_next ())
   {
gimple *stmt = gsi_stmt (i);
-   tree ap, expr, lhs, type;
+   tree ap, aptype, expr, lhs, type;
gimple_seq pre = NULL, post = NULL;
 
if (!gimple_call_ifn_va_arg_p (stmt))
@@ -1028,9 +1028,12 @@ expand_ifn_va_arg_1 (function *fun)
 
type = TREE_TYPE (TREE_TYPE (gimple_call_arg (stmt, 1)));
ap = gimple_call_arg (stmt, 0);
+   aptype = TREE_TYPE (gimple_call_arg (stmt, 2));
+   gcc_assert (POINTER_TYPE_P (aptype));
 
/* Balanced out the , usually added by build_va_arg.  */
-   ap = build_fold_indirect_ref (ap);
+   ap = build2 (MEM_REF, TREE_TYPE (aptype), ap,
+build_int_cst (aptype, 0));
 
push_gimplify_context (false);
saved_location = input_location;
@@ -1053,7 +1056,7 @@ expand_ifn_va_arg_1 (function *fun)
if (chkp_function_instrumented_p (fun->decl))
  chkp_fixup_inlined_call (lhs, expr);
 
-   if (nargs == 3)
+   if (nargs == 4)
  {
/* We've transported the size of with WITH_SIZE_EXPR here as
   the last argument of the internal fn call.  Now reinstate
--- gcc/testsuite/gcc.dg/pr69162.c.jj   2016-01-07 15:27:10.215660347 +0100
+++ gcc/testsuite/gcc.dg/pr69162.c  2016-01-07 15:27:47.127148736 +0100
@@ -0,0 +1,12 @@
+/* PR tree-optimization/69162 */
+/* { dg-do compile } */
+/* { dg-options "-O2" } */
+
+#include 
+
+int
+foo (void *a)
+{
+  va_list *b = a;
+  return va_arg (*b, int);
+}

Jakub

[PATCH] Fix (ab) SSA_NAME issue in gimple folding (PR tree-optimization/69167)

[Jakub Jelinek]

Hi!

Various places check that (ab) SSA_NAMEs that weren't referenced on a stmt
before don't appear on it, but all the checking is done on the gimple tuple
operands, while in this case it is added to operands of a comparison of
COND_EXPR/VEC_COND_EXPR.  The following patch fixes it,
bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

2016-01-07  Jakub Jelinek  

PR tree-optimization/69167
* gimple-match-head.c (gimple_simplify) :
Don't simplify condition if the condition simplification would
introduce use of SSA_NAME_OCCURS_IN_ABNORMAL_PHI SSA_NAME not
previously mentioned on the insn.
* gimple-fold.h (has_use_on_stmt): New prototype.
* gimple-fold.c (has_use_on_stmt): No longer static.

* gcc.dg/pr69167.c: New test.

--- gcc/gimple-match-head.c.jj  2016-01-04 14:55:53.0 +0100
+++ gcc/gimple-match-head.c 2016-01-07 12:54:42.237334530 +0100
@@ -655,9 +655,23 @@ gimple_simplify (gimple *stmt,
  valueized = true;
  if (TREE_CODE_CLASS ((enum tree_code)rcode2)
  == tcc_comparison)
-   rhs1 = build2 (rcode2, TREE_TYPE (rhs1),
-  ops2[0], ops2[1]);
- else if (rcode2 == SSA_NAME
+   {
+ if (TREE_CODE (ops2[0]) == SSA_NAME
+ && SSA_NAME_OCCURS_IN_ABNORMAL_PHI (ops2[0])
+ && !has_use_on_stmt (ops2[0], stmt))
+   valueized = false;
+ if (TREE_CODE (ops2[1]) == SSA_NAME
+ && SSA_NAME_OCCURS_IN_ABNORMAL_PHI (ops2[1])
+ && !has_use_on_stmt (ops2[1], stmt))
+   valueized = false;
+ if (valueized)
+   rhs1 = build2 (rcode2, TREE_TYPE (rhs1),
+  ops2[0], ops2[1]);
+   }
+ else if ((rcode2 == SSA_NAME
+   && (!SSA_NAME_OCCURS_IN_ABNORMAL_PHI
+ (ops2[0])
+   || has_use_on_stmt (ops2[0], stmt)))
   || rcode2 == INTEGER_CST
   || rcode2 == VECTOR_CST)
rhs1 = ops2[0];
--- gcc/gimple-fold.h.jj2016-01-04 14:55:53.0 +0100
+++ gcc/gimple-fold.h   2016-01-07 13:01:52.938315972 +0100
@@ -34,6 +34,7 @@ extern tree maybe_fold_or_comparisons (e
   enum tree_code, tree, tree);
 extern bool arith_overflowed_p (enum tree_code, const_tree, const_tree,
const_tree);
+extern bool has_use_on_stmt (tree, gimple *);
 extern tree no_follow_ssa_edges (tree);
 extern tree follow_single_use_edges (tree);
 extern tree gimple_fold_stmt_to_constant_1 (gimple *, tree (*) (tree),
--- gcc/gimple-fold.c.jj2016-01-07 11:37:36.0 +0100
+++ gcc/gimple-fold.c   2016-01-07 13:01:25.793695288 +0100
@@ -3270,7 +3270,7 @@ gimple_fold_call (gimple_stmt_iterator *
 
 /* Return true whether NAME has a use on STMT.  */
 
-static bool
+bool
 has_use_on_stmt (tree name, gimple *stmt)
 {
   imm_use_iterator iter;
--- gcc/testsuite/gcc.dg/pr69167.c.jj   2016-01-07 12:58:40.706002201 +0100
+++ gcc/testsuite/gcc.dg/pr69167.c  2016-01-07 12:58:22.0 +0100
@@ -0,0 +1,21 @@
+/* PR tree-optimization/69167 */
+/* { dg-do compile } */
+/* { dg-options "-O2" } */
+
+int sigsetjmp (char *);
+void foo ();
+void bar (void (*) (int *));
+extern char t[];
+
+void
+baz (int *x)
+{
+  int *a = x;
+  foo ();
+  x = 0;
+  if (sigsetjmp (t))
+while (1)
+  bar (a ? baz : 0);
+  if (x)
+foo ();
+}

Jakub

[PATCH] Fix !$omp workshare (PR fortran/69128)

[Jakub Jelinek]

Hi!

As the testcase shows, gfc_trans_scalarized_loop_end can be called
multiple times (and not just for different dimensions of the same loop)
on a single assignment, and we could in that case when inside of
!$omp workshare generate nested !$omp do, which is obviously incorrect.

Fixed by making sure we do it only in the toplevel loop nest generated from
the statement.  Bootstrapped/regtested on x86_64-linux and i686-linux, will
commit tomorrow.

2016-01-07  Jakub Jelinek  

PR fortran/69128
* trans.h (OMPWS_SCALARIZER_BODY): Define.
(OMPWS_NOWAIT): Renumber.
* trans-stmt.c (gfc_trans_where_3): Only set OMPWS_SCALARIZER_WS
if OMPWS_SCALARIZER_BODY is not set already, and set also
OMPWS_SCALARIZER_BODY until the final loop creation.
* trans-expr.c (gfc_trans_assignment_1): Likewise.
* trans-openmp.c (gfc_trans_omp_workshare): Also clear
OMPWS_SCALARIZER_BODY.
* trans-array.c (gfc_trans_scalarized_loop_end): Don't create
OMP_FOR if OMPWS_SCALARIZER_BODY is set.

* gfortran.dg/gomp/pr69128.f90: New test.

--- gcc/fortran/trans.h.jj  2016-01-07 18:38:20.274008188 +0100
+++ gcc/fortran/trans.h 2016-01-07 18:42:25.187630832 +0100
@@ -1039,7 +1039,9 @@ extern const char gfc_msg_wrong_return[]
   construct is not workshared.  */
 #define OMPWS_SCALARIZER_WS4   /* Set if scalarizer should attempt
   to create parallel loops.  */
-#define OMPWS_NOWAIT   8   /* Use NOWAIT on OMP_FOR.  */
+#define OMPWS_SCALARIZER_BODY  8   /* Set if handling body of potential
+  parallel loop.  */
+#define OMPWS_NOWAIT   16  /* Use NOWAIT on OMP_FOR.  */
 extern int ompws_flags;
 
 #endif /* GFC_TRANS_H */
--- gcc/fortran/trans-stmt.c.jj 2016-01-07 18:38:20.269008257 +0100
+++ gcc/fortran/trans-stmt.c2016-01-07 18:42:25.186630846 +0100
@@ -5057,10 +5057,15 @@ gfc_trans_where_3 (gfc_code * cblock, gf
   gfc_loopinfo loop;
   gfc_ss *edss = 0;
   gfc_ss *esss = 0;
+  bool maybe_workshare = false;
 
   /* Allow the scalarizer to workshare simple where loops.  */
-  if (ompws_flags & OMPWS_WORKSHARE_FLAG)
-ompws_flags |= OMPWS_SCALARIZER_WS;
+  if ((ompws_flags & (OMPWS_WORKSHARE_FLAG | OMPWS_SCALARIZER_BODY))
+  == OMPWS_WORKSHARE_FLAG)
+{
+  maybe_workshare = true;
+  ompws_flags |= OMPWS_SCALARIZER_WS | OMPWS_SCALARIZER_BODY;
+}
 
   cond = cblock->expr1;
   tdst = cblock->next->expr1;
@@ -5160,6 +5165,8 @@ gfc_trans_where_3 (gfc_code * cblock, gf
   gfc_add_expr_to_block (, tmp);
   gfc_add_block_to_block (, );
 
+  if (maybe_workshare)
+ompws_flags &= ~OMPWS_SCALARIZER_BODY;
   gfc_trans_scalarizing_loops (, );
   gfc_add_block_to_block (, );
   gfc_add_block_to_block (, );
--- gcc/fortran/trans-openmp.c.jj   2016-01-07 18:38:20.279008119 +0100
+++ gcc/fortran/trans-openmp.c  2016-01-07 18:42:25.188630818 +0100
@@ -4297,7 +4297,7 @@ gfc_trans_omp_workshare (gfc_code *code,
 
   /* By default, every gfc_code is a single unit of work.  */
   ompws_flags |= OMPWS_CURR_SINGLEUNIT;
-  ompws_flags &= ~OMPWS_SCALARIZER_WS;
+  ompws_flags &= ~(OMPWS_SCALARIZER_WS | OMPWS_SCALARIZER_BODY);
 
   switch (code->op)
{
--- gcc/fortran/trans-array.c.jj2016-01-07 18:38:20.284008050 +0100
+++ gcc/fortran/trans-array.c   2016-01-07 18:42:25.191630777 +0100
@@ -3601,7 +3601,8 @@ gfc_trans_scalarized_loop_end (gfc_loopi
   tree init;
   tree incr;
 
-  if ((ompws_flags & (OMPWS_WORKSHARE_FLAG | OMPWS_SCALARIZER_WS))
+  if ((ompws_flags & (OMPWS_WORKSHARE_FLAG | OMPWS_SCALARIZER_WS
+ | OMPWS_SCALARIZER_BODY))
   == (OMPWS_WORKSHARE_FLAG | OMPWS_SCALARIZER_WS)
   && n == loop->dimen - 1)
 {
--- gcc/fortran/trans-expr.c.jj 2016-01-07 18:38:20.289007981 +0100
+++ gcc/fortran/trans-expr.c2016-01-07 18:42:25.193630749 +0100
@@ -9160,6 +9160,7 @@ gfc_trans_assignment_1 (gfc_expr * expr1
   bool scalar_to_array;
   tree string_length;
   int n;
+  bool maybe_workshare = false;
 
   /* Assignment of the form lhs = rhs.  */
   gfc_start_block ();
@@ -9234,8 +9235,13 @@ gfc_trans_assignment_1 (gfc_expr * expr1
}
 
   /* Allow the scalarizer to workshare array assignments.  */
-  if ((ompws_flags & OMPWS_WORKSHARE_FLAG) && loop.temp_ss == NULL)
-   ompws_flags |= OMPWS_SCALARIZER_WS;
+  if ((ompws_flags & (OMPWS_WORKSHARE_FLAG | OMPWS_SCALARIZER_BODY))
+ == OMPWS_WORKSHARE_FLAG
+ && loop.temp_ss == NULL)
+   {
+ maybe_workshare = true;
+ ompws_flags |= OMPWS_SCALARIZER_WS | OMPWS_SCALARIZER_BODY;
+   }
 
   /* Start the scalarized loop body.  */
   gfc_start_scalarized_body (, );
@@ -9384,6 +9390,9 @@ gfc_trans_assignment_1 (gfc_expr * expr1
gfc_add_expr_to_block ([expr1->rank - 1], tmp);
}
 
+

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

[Jonathan Wakely]

On 07/01/16 13:37 -0800, Steve Ellcey wrote:

On Thu, 2016-01-07 at 20:56 +0100, Bernhard Reutner-Fischer wrote:

On January 7, 2016 12:23:49 PM GMT+01:00, Jonathan Wakely  
wrote:
>On 07/01/16 07:28 +0100, Marc Glisse wrote:
>>On Wed, 6 Jan 2016, Jonathan Wakely wrote:
>>
>>>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

uClibc provides an infinite macro. Make sure to enable C99 math though.


(You mean isfinite, not infinite, right? C99 doesn't define an "infinite"
macro.)


OK?

TIA,


But is there any reason to use the infinite macro instead of the
__builtin_isfinite function?  I think that if I used the infinite macro


The isfinite macro doesn't exist in C++, if the C library defines it
we #undef it in , because the C++ standard requires those C99
math functions to be real functions, not macros. So that's a good
reason to use the builtin :-)

(Currently if you #include  instead of  then you get
the macro, because  comes from the C library, but I'm in the
process of fixing that so the C++ library will provide its own
 wrapper that does the #undef.)


I would also have to check for NAN since NAN is neither finite nor
infinite.  Here is what I tested last night with no failures.  Is this
version OK to checkin?


Yes, this is OK, thanks.

Re: [PATCH] longlong: fix sh -Wundef builds

[Oleg Endo]

On Jan 8, 2016, at 4:39 AM, Mike Frysinger  wrote:

> This file fails when building for SuperH as it assumes __SHMEDIA__ is
> always defined.  Update the code to check if it's defined.

This is OK for trunk.  Thanks for spotting it.

Cheers,
Oleg

> ---
> include/longlong.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/include/longlong.h b/include/longlong.h
> index d7ef671..78042d7 100644
> --- a/include/longlong.h
> +++ b/include/longlong.h
> @@ -1086,7 +1086,7 @@ extern UDItype __umulsidi3 (USItype, USItype);
>   } while (0)
> #endif
> 
> -#if defined(__sh__) && !__SHMEDIA__ && W_TYPE_SIZE == 32
> +#if defined(__sh__) && (!defined (__SHMEDIA__) || !__SHMEDIA__) && 
> W_TYPE_SIZE == 32
> #ifndef __sh1__
> #define umul_ppmm(w1, w0, u, v) \
>   __asm__ (\
> @@ -1159,7 +1159,7 @@ extern UDItype __umulsidi3 (USItype, USItype);
> 
> #endif /* __sh__ */
> 
> -#if defined (__SH5__) && __SHMEDIA__ && W_TYPE_SIZE == 32
> +#if defined (__SH5__) && (!defined (__SHMEDIA__) || !__SHMEDIA__) && 
> W_TYPE_SIZE == 32
> #define __umulsidi3(u,v) ((UDItype)(USItype)u*(USItype)v)
> #define count_leading_zeros(count, x) \
>   do\
> -- 
> 2.6.2
> 

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

[Joseph Myers]

On Wed, 6 Jan 2016, Michael Meissner wrote:

> 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).

I think this needs to be __NO_FPRS__ instead of _SOFT_FLOAT (since soft-fp 
is also built for e500).

Other than that my only comments on this version are some formatting / 
coding style comments:

> Index: libgcc/config/rs6000/sfp-exceptions.c
> ===
> --- libgcc/config/rs6000/sfp-exceptions.c 
> (.../svn+ssh://meiss...@gcc.gnu.org/svn/gcc/trunk/libgcc)   (revision 0)
> +++ libgcc/config/rs6000/sfp-exceptions.c (.../libgcc)(revision 
> 232096)
> @@ -0,0 +1,74 @@
> +/*
> + * Copyright (C) 2016 Free Software Foundation, Inc.
> + *

Normally we don't use the '*' at the start of each comment line.

> +TFtype
> +__floatsikf_hw (SItype_ppc a)
> +{
> +  return (TFtype)a;

Casts should have a space, "(TFtype) a".  Many more cases in this file.

> +/* __unordkf2 returns 1 if Nan or 0 otherwise.  */

NaN.

> +  __low = (double) (__value - (__float128)__high);   
> \

Again, space in cast.

> +  /* now renormalized move the high/low into canonical IBM long  \
> +  double form.  */   \

Comments start with a capital letter.

> +  /* Handle the special cases of NAN and inifinity.  */  
> \

"infinity".

> +RESULT = ((__float128)__high) + ((__float128)__low); \

Spaces in casts.

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

Re: [PATCH] Fix !$omp workshare (PR fortran/69128)

[Paul Richard Thomas]

Hi Jakub,

Thanks for responding so quickly - it looks good to me.

The PR is marked as a 4.9/5/6 regression. Do you intend to backport to
5, at least?

Cheers

Paul

On 7 January 2016 at 22:49, Jakub Jelinek  wrote:
> Hi!
>
> As the testcase shows, gfc_trans_scalarized_loop_end can be called
> multiple times (and not just for different dimensions of the same loop)
> on a single assignment, and we could in that case when inside of
> !$omp workshare generate nested !$omp do, which is obviously incorrect.
>
> Fixed by making sure we do it only in the toplevel loop nest generated from
> the statement.  Bootstrapped/regtested on x86_64-linux and i686-linux, will
> commit tomorrow.
>
> 2016-01-07  Jakub Jelinek  
>
> PR fortran/69128
> * trans.h (OMPWS_SCALARIZER_BODY): Define.
> (OMPWS_NOWAIT): Renumber.
> * trans-stmt.c (gfc_trans_where_3): Only set OMPWS_SCALARIZER_WS
> if OMPWS_SCALARIZER_BODY is not set already, and set also
> OMPWS_SCALARIZER_BODY until the final loop creation.
> * trans-expr.c (gfc_trans_assignment_1): Likewise.
> * trans-openmp.c (gfc_trans_omp_workshare): Also clear
> OMPWS_SCALARIZER_BODY.
> * trans-array.c (gfc_trans_scalarized_loop_end): Don't create
> OMP_FOR if OMPWS_SCALARIZER_BODY is set.
>
> * gfortran.dg/gomp/pr69128.f90: New test.
>
> --- gcc/fortran/trans.h.jj  2016-01-07 18:38:20.274008188 +0100
> +++ gcc/fortran/trans.h 2016-01-07 18:42:25.187630832 +0100
> @@ -1039,7 +1039,9 @@ extern const char gfc_msg_wrong_return[]
>construct is not workshared.  */
>  #define OMPWS_SCALARIZER_WS4   /* Set if scalarizer should attempt
>to create parallel loops.  */
> -#define OMPWS_NOWAIT   8   /* Use NOWAIT on OMP_FOR.  */
> +#define OMPWS_SCALARIZER_BODY  8   /* Set if handling body of potential
> +  parallel loop.  */
> +#define OMPWS_NOWAIT   16  /* Use NOWAIT on OMP_FOR.  */
>  extern int ompws_flags;
>
>  #endif /* GFC_TRANS_H */
> --- gcc/fortran/trans-stmt.c.jj 2016-01-07 18:38:20.269008257 +0100
> +++ gcc/fortran/trans-stmt.c2016-01-07 18:42:25.186630846 +0100
> @@ -5057,10 +5057,15 @@ gfc_trans_where_3 (gfc_code * cblock, gf
>gfc_loopinfo loop;
>gfc_ss *edss = 0;
>gfc_ss *esss = 0;
> +  bool maybe_workshare = false;
>
>/* Allow the scalarizer to workshare simple where loops.  */
> -  if (ompws_flags & OMPWS_WORKSHARE_FLAG)
> -ompws_flags |= OMPWS_SCALARIZER_WS;
> +  if ((ompws_flags & (OMPWS_WORKSHARE_FLAG | OMPWS_SCALARIZER_BODY))
> +  == OMPWS_WORKSHARE_FLAG)
> +{
> +  maybe_workshare = true;
> +  ompws_flags |= OMPWS_SCALARIZER_WS | OMPWS_SCALARIZER_BODY;
> +}
>
>cond = cblock->expr1;
>tdst = cblock->next->expr1;
> @@ -5160,6 +5165,8 @@ gfc_trans_where_3 (gfc_code * cblock, gf
>gfc_add_expr_to_block (, tmp);
>gfc_add_block_to_block (, );
>
> +  if (maybe_workshare)
> +ompws_flags &= ~OMPWS_SCALARIZER_BODY;
>gfc_trans_scalarizing_loops (, );
>gfc_add_block_to_block (, );
>gfc_add_block_to_block (, );
> --- gcc/fortran/trans-openmp.c.jj   2016-01-07 18:38:20.279008119 +0100
> +++ gcc/fortran/trans-openmp.c  2016-01-07 18:42:25.188630818 +0100
> @@ -4297,7 +4297,7 @@ gfc_trans_omp_workshare (gfc_code *code,
>
>/* By default, every gfc_code is a single unit of work.  */
>ompws_flags |= OMPWS_CURR_SINGLEUNIT;
> -  ompws_flags &= ~OMPWS_SCALARIZER_WS;
> +  ompws_flags &= ~(OMPWS_SCALARIZER_WS | OMPWS_SCALARIZER_BODY);
>
>switch (code->op)
> {
> --- gcc/fortran/trans-array.c.jj2016-01-07 18:38:20.284008050 +0100
> +++ gcc/fortran/trans-array.c   2016-01-07 18:42:25.191630777 +0100
> @@ -3601,7 +3601,8 @@ gfc_trans_scalarized_loop_end (gfc_loopi
>tree init;
>tree incr;
>
> -  if ((ompws_flags & (OMPWS_WORKSHARE_FLAG | OMPWS_SCALARIZER_WS))
> +  if ((ompws_flags & (OMPWS_WORKSHARE_FLAG | OMPWS_SCALARIZER_WS
> + | OMPWS_SCALARIZER_BODY))
>== (OMPWS_WORKSHARE_FLAG | OMPWS_SCALARIZER_WS)
>&& n == loop->dimen - 1)
>  {
> --- gcc/fortran/trans-expr.c.jj 2016-01-07 18:38:20.289007981 +0100
> +++ gcc/fortran/trans-expr.c2016-01-07 18:42:25.193630749 +0100
> @@ -9160,6 +9160,7 @@ gfc_trans_assignment_1 (gfc_expr * expr1
>bool scalar_to_array;
>tree string_length;
>int n;
> +  bool maybe_workshare = false;
>
>/* Assignment of the form lhs = rhs.  */
>gfc_start_block ();
> @@ -9234,8 +9235,13 @@ gfc_trans_assignment_1 (gfc_expr * expr1
> }
>
>/* Allow the scalarizer to workshare array assignments.  */
> -  if ((ompws_flags & OMPWS_WORKSHARE_FLAG) && loop.temp_ss == NULL)
> -   ompws_flags |= OMPWS_SCALARIZER_WS;
> +  if ((ompws_flags & (OMPWS_WORKSHARE_FLAG | 

[gomp4] Remove PTX link option

[James Norris]

Hi,

This patch removes the constraint whereby the PTX
emitted was only for sm_30 GPU's. With this removal,
the PTX emitted will be targeted for the current
context (attached GPU).

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

Thanks,
Jim
Index: libgomp/ChangeLog.gomp
===
--- libgomp/ChangeLog.gomp	(revision 232139)
+++ libgomp/ChangeLog.gomp	(revision 232142)
@@ -1,5 +1,10 @@
 2016-01-07  James Norris  
+	Alexander Monakov 
 
+	* plugin/plugin-nvptx.c (link_ptx): Remove link option.
+
+2016-01-07  James Norris  
+
 	* testsuite/libgomp.oacc-c-c++-common/declare-4.c: Fix test.
 
 2016-01-06  Cesar Philippidis  
Index: libgomp/plugin/plugin-nvptx.c
===
--- libgomp/plugin/plugin-nvptx.c	(revision 232139)
+++ libgomp/plugin/plugin-nvptx.c	(revision 232142)
@@ -693,8 +693,8 @@
 link_ptx (CUmodule *module, const struct targ_ptx_obj *ptx_objs,
 	  unsigned num_objs)
 {
-  CUjit_option opts[7];
-  void *optvals[7];
+  CUjit_option opts[6];
+  void *optvals[6];
   float elapsed = 0.0;
 #define LOGSIZE 8192
   char elog[LOGSIZE];
@@ -723,10 +723,7 @@
   opts[5] = CU_JIT_LOG_VERBOSE;
   optvals[5] = (void *) 1;
 
-  opts[6] = CU_JIT_TARGET;
-  optvals[6] = (void *) CU_TARGET_COMPUTE_30;
-
-  r = cuLinkCreate (7, opts, optvals, );
+  r = cuLinkCreate (6, opts, optvals, );
   if (r != CUDA_SUCCESS)
 GOMP_PLUGIN_fatal ("cuLinkCreate error: %s", cuda_error (r));
 

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

[Steve Ellcey]

On Thu, 2016-01-07 at 20:56 +0100, Bernhard Reutner-Fischer wrote:
> On January 7, 2016 12:23:49 PM GMT+01:00, Jonathan Wakely 
>  wrote:
> >On 07/01/16 07:28 +0100, Marc Glisse wrote:
> >>On Wed, 6 Jan 2016, Jonathan Wakely wrote:
> >>
> >>>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
> 
> uClibc provides an infinite macro. Make sure to enable C99 math though.
> 
> OK?
> 
> TIA,

But is there any reason to use the infinite macro instead of the
__builtin_isfinite function?  I think that if I used the infinite macro
I would also have to check for NAN since NAN is neither finite nor
infinite.  Here is what I tested last night with no failures.  Is this
version OK to checkin?

Steve Ellcey
sell...@imgtec.com



2016-01-07  Steve Ellcey  

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


diff --git a/libstdc++-v3/include/ext/random.tcc 
b/libstdc++-v3/include/ext/random.tcc
index a9c5a2b..52350e8 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_isfinite(__norm));
 
  std::transform(__ret.begin(), __ret.end(), __ret.begin(),
 [__norm](_RealType __val){ return __val / __norm; });

Re: RFA: PR 68913: Provide weak version of __fread_chk for PR61886 test

[Nick Clifton]

Hi Jakub,



-extern size_t __fread_chk (void *__restrict __ptr, size_t __ptrlen, size_t
__size, size_t __n, FILE *__restrict __stream) __asm__ ("" "__fread_chk")
__attribute__ ((__warn_unused_result__));



+extern size_t __malloc (void *__restrict __ptr, size_t __ptrlen, size_t
__size, size_t __n, FILE *__restrict __stream) __asm__ ("") __attribute__
((__warn_unused_result__));



The __asm__ ("") on both decls is very weird.  The original had
"" "__fread_chk" aka "__fread_chk" instead.


What does that do ?  I could not find a reference to it in the 
documentation.



But malloc really has also different arguments...


True - thinking about it afterwards it occurred to me that renaming the 
function to just "fread" would be a lot better ...


Cheers
  Nick

Re: C PATCH to rectify warning for character types (PR c/23087)

[Joseph Myers]

On Thu, 7 Jan 2016, Marek Polacek wrote:

> This PR points out that we issue a wrong warning message when assigning
> two pointers when one of them is plain char.  In that case, the compiler
> currently says that pointer targets differ in signedness.  But that is
> not correct; char is a separate type from (un)signed char and is not
> compatible with either.  So we should instead say that the pointer types
> are not compatible.
> 
> This effectively means that I'm turning a -Wpointer-sign warning into
> a -Wincompatible-pointer-types warning.  But -Wincompatible-pointer-types
> is a warning that is enabled by default and -Wpointer-sign is enabled by
> -Wpedantic || -Wall.  So with this, we'd be more verbose and would warn
> by default on e.g. "unsigned char *p = "foo";."  Not sure if that is
> desirable at this stage, so I'm leaning towards pushing this patch for
> GCC7.

I don't think it's desirable to raise the warning for this case under 
different conditions from the warning for other signedness cases.  The 
targets do differ in signedness - it's just that the difference is between 
"plain" and "signed" or "plain" and "unsigned", not between signed and 
unsigned.  Maybe the warning message should be more specific in this case, 
but not a less-specific "incompatible" which is what this patch would 
achieve.

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

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

[Jeff Law]

On 01/06/2016 01:11 PM, Ryan Burn wrote:





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?
I think the checks, or at least part of them is going to have to move 
out of c-family common code and into the language specific front-ends.


As you note, that likely means a more intrusive change and possibly some 
code duplication.  But looking at the language specific flags like that 
in code shared across front-ends is a recipe for disaster.


Jeff

Re: [PATCH] Fix #pragma implementation diagnostics (PR c++/69145, take 2)

[Jakub Jelinek]

On Thu, Jan 07, 2016 at 01:49:12PM +0100, Bernd Schmidt wrote:
> On 01/07/2016 10:05 AM, Jakub Jelinek wrote:
> >+  if (IS_ADHOC_LOC (location))
> >+{
> >+  location &= MAX_SOURCE_LOCATION;
> >+  location
> >+= pfile->line_table->location_adhoc_data_map.data[location].locus;
> >+}
> 
> This looks like it is get_location_from_adhoc_loc.

I've also bootstrapped/regtested on x86_64-linux and i686-linux
following version:

2016-01-07  Jakub Jelinek  

PR c++/69145
* files.c (cpp_included_before): If IS_ADHOC_LOC (location), lookup
real location from the line_table.

* g++.dg/ext/pr69145-1.C: New test.
* g++.dg/ext/pr69145-2-very-long-filename.cc: New file.
* g++.dg/ext/pr69145-2.h: New file.

--- libcpp/files.c.jj   2016-01-05 12:26:58.0 +0100
+++ libcpp/files.c  2016-01-07 19:41:11.841870958 +0100
@@ -1224,10 +1224,12 @@ bool
 cpp_included_before (cpp_reader *pfile, const char *fname,
 source_location location)
 {
-  struct cpp_file_hash_entry *entry;
+  struct cpp_file_hash_entry *entry
+= (struct cpp_file_hash_entry *)
+  htab_find_with_hash (pfile->file_hash, fname, htab_hash_string (fname));
 
-  entry = (struct cpp_file_hash_entry *)
- htab_find_with_hash (pfile->file_hash, fname, htab_hash_string (fname));
+  if (IS_ADHOC_LOC (location))
+location = get_location_from_adhoc_loc (pfile->line_table, location);
 
   while (entry && (entry->start_dir == NULL || entry->u.file->err_no
   || entry->location > location))
--- gcc/testsuite/g++.dg/ext/pr69145-1.C.jj 2016-01-05 12:22:58.206729760 
+0100
+++ gcc/testsuite/g++.dg/ext/pr69145-1.C2016-01-05 12:22:52.017818392 
+0100
@@ -0,0 +1,4 @@
+// PR c++/69145
+// { dg-do compile }
+#pragma implementation "pr69145-2-very-long-filename.cc" // { dg-bogus 
"appears after file is included" }
+#include "pr69145-2-very-long-filename.cc"
--- gcc/testsuite/g++.dg/ext/pr69145-2-very-long-filename.cc.jj 2016-01-05 
12:23:47.151028824 +0100
+++ gcc/testsuite/g++.dg/ext/pr69145-2-very-long-filename.cc2016-01-05 
12:23:42.629093583 +0100
@@ -0,0 +1,3 @@
+// PR c++/69145
+// { dg-do compile } */
+#include "pr69145-2.h"
--- gcc/testsuite/g++.dg/ext/pr69145-2.h.jj 2016-01-05 12:23:49.963988539 
+0100
+++ gcc/testsuite/g++.dg/ext/pr69145-2.h2016-01-05 12:06:42.0 
+0100
@@ -0,0 +1,3 @@
+#ifndef PR69145_2_H
+# define PR69145_2_H
+#endif


Jakub

[PATCH] Fix incorrect gimple_build arguments in gimple-fold.c (PR tree-optimization/69172)

[Jakub Jelinek]

Hi!

gimple_build wants the type after POINTER_PLUS_EXPR, but
gimple_fold_builtin_memory_chk wasn't passing it.

Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trunk?

2016-01-07  Jakub Jelinek  

PR tree-optimization/69172
* gimple-fold.c (gimple_fold_builtin_memory_chk): Pass type to
gimple_build.

* gcc.dg/pr69172.c: New test.

--- gcc/gimple-fold.c.jj2016-01-04 14:55:53.0 +0100
+++ gcc/gimple-fold.c   2016-01-07 11:37:36.697047480 +0100
@@ -1710,7 +1710,8 @@ gimple_fold_builtin_memory_chk (gimple_s
{
  gimple_seq stmts = NULL;
  len = gimple_convert_to_ptrofftype (, loc, len);
- tree temp = gimple_build (, loc, POINTER_PLUS_EXPR, dest, len);
+ tree temp = gimple_build (, loc, POINTER_PLUS_EXPR,
+   TREE_TYPE (dest), dest, len);
  gsi_insert_seq_before (gsi, stmts, GSI_SAME_STMT);
  replace_call_with_value (gsi, temp);
  return true;
--- gcc/testsuite/gcc.dg/pr69172.c.jj   2016-01-07 11:59:13.433897448 +0100
+++ gcc/testsuite/gcc.dg/pr69172.c  2016-01-07 11:59:02.0 +0100
@@ -0,0 +1,45 @@
+/* PR tree-optimization/69172 */
+/* { dg-do compile } */
+/* { dg-options "-O2" } */
+
+int a;
+
+void *
+f1 (void)
+{
+  int *b = , *c = 
+  return __builtin___mempcpy_chk (b, c, sizeof (int), 0);
+}
+
+void *
+f2 (void)
+{
+  int *b = 
+  return __builtin___mempcpy_chk (b, b, sizeof (int), 0);
+}
+
+void *
+f3 (void)
+{
+  return __builtin___mempcpy_chk (, , sizeof (int), 0);
+}
+
+void *
+f4 (int x)
+{
+  int *b = , *c = 
+  return __builtin___mempcpy_chk (b, c, x, 0);
+}
+
+void *
+f5 (int x)
+{
+  int *b = 
+  return __builtin___mempcpy_chk (b, b, x, 0);
+}
+
+void *
+f6 (int x)
+{
+  return __builtin___mempcpy_chk (, , x, 0);
+}

Jakub

Re: [PATCH] longlong: fix sh -Wundef builds

[Mike Frysinger]

On 08 Jan 2016 06:54, Oleg Endo wrote:
> On Jan 8, 2016, at 4:39 AM, Mike Frysinger  wrote:
> > This file fails when building for SuperH as it assumes __SHMEDIA__ is
> > always defined.  Update the code to check if it's defined.
> 
> This is OK for trunk.  Thanks for spotting it.

i had checked only the first case previously (as i don't have sh5
systems), but there's a logic error in the second i fixed before
committing.  this is what i merged:
--- include/longlong.h  (revision 232142)
+++ include/longlong.h  (working copy)
@@ -1086,7 +1086,7 @@ extern UDItype __umulsidi3 (USItype, USI
   } while (0)
 #endif
 
-#if defined(__sh__) && !__SHMEDIA__ && W_TYPE_SIZE == 32
+#if defined(__sh__) && (!defined (__SHMEDIA__) || !__SHMEDIA__) && W_TYPE_SIZE 
== 32
 #ifndef __sh1__
 #define umul_ppmm(w1, w0, u, v) \
   __asm__ (\
@@ -1159,7 +1159,7 @@ extern UDItype __umulsidi3 (USItype, USI
 
 #endif /* __sh__ */
 
-#if defined (__SH5__) && __SHMEDIA__ && W_TYPE_SIZE == 32
+#if defined (__SH5__) && defined (__SHMEDIA__) && __SHMEDIA__ && W_TYPE_SIZE 
== 32
 #define __umulsidi3(u,v) ((UDItype)(USItype)u*(USItype)v)
 #define count_leading_zeros(count, x) \
   do   \
-mike


signature.asc
Description: Digital signature