Re: [Patch] Implementation of n3793

[Andreas Schwab]

Jonathan Wakely  writes:

> +  {
> +std::experimental::optional o { std::experimental::in_place, 
> 0x1234ABCDF1E2D3C4 };
> +auto copy = o;
> +VERIFY( copy );
> +VERIFY( *copy == 0x1234ABCDF1E2D3C4 );
> +VERIFY( o && o == 0x1234ABCDF1E2D3C4 );
> +  }

experimental/optional/cons/copy.cc:70:20: error: no match for 'operator==' 
(operand types are 'std::experimental::optional' and 'long long int')
 VERIFY( o && o == 0x1234ABCDF1E2D3C4 );
^

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

RE: Honnor ix86_accumulate_outgoing_args again

[Zamyatin, Igor]

So, Jan, what do you think will be best solution for stage 1?

Thanks,
Igor

> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Vladimir Makarov
> Sent: Monday, October 21, 2013 6:52 AM
> To: Jan Hubicka; Zamyatin, Igor; gcc-patches@gcc.gnu.org
> Subject: Re: Honnor ix86_accumulate_outgoing_args again
> 
> On 13-10-19 4:30 PM, Jan Hubicka wrote:
> >> Jan,
> >>
> >> Does this seem reasonable to you?
> > Oops, sorry, I missed your email. (I was travelling and I am finishing
> > a paper now).
> >> Thanks,
> >> Igor
> >>
> >>> -Original Message-
> >>> From: Zamyatin, Igor
> >>> Sent: Tuesday, October 15, 2013 3:48 PM
> >>> To: Jan Hubicka
> >>> Subject: RE: Honnor ix86_accumulate_outgoing_args again
> >>>
> >>> Jan,
> >>>
> >>> Now we have following prologue in, say, phi0 routine in equake
> >>>
> >>> 0x804aa90 1  push   %ebp
> >>> 0x804aa91 2  mov%esp,%ebp
> >>> 0x804aa93 3  sub$0x18,%esp
> >>> 0x804aa96 4  vmovsd 0x80ef7a8,%xmm0
> >>> 0x804aa9e 5  vmovsd 0x8(%ebp),%xmm1
> >>> 0x804aaa3 6  vcomisd %xmm1,%xmm0   <-- we see big stall somewhere
> here
> >>> or 1-2 instructions above
> >>>
> >>> While earlier it was
> >>>
> >>> 0x804abd0 1 sub$0x2c,%esp
> >>> 0x804abd3 2 vmovsd 0x30(%esp),%xmm1
> >>> 0x804abd9 3 vmovsd 0x80efcc8,%xmm0
> >>> 0x804abe1 4 vcomisd %xmm1,%xmm0
> > Thanks for analysis! It is a different benchmark than for bulldozer,
> > but apparently same case.  Again we used to eliminate frame pointer
> > here but IRS now doesn't Do you see the same regression with
> > -fno-omit-frame-pointer -maccumulate-outgoing-args?
> >
> > I suppose this is a conflict in between the push instruction hanled by
> > stack engine and initialization of EBP that isn't.  That would explain
> > why bulldozer don't seem to care about this particular benchmark (its
> > stack engine seems to have quite different design).
> >
> > This is a bit sad situation - accumulate-outgoing-args is expensive
> > code size wise and it seems we don't really need esp with -mno-
> accumulate-outgoing-args.
> > The non-accumulation code path was mistakely disabled for too long ;(
> >
> > Vladimir, how much effort do you think it will be to fix the frame
> > pointer elimination here?
> My guess is a week.  The problem I am busy and having some problems with
> two small projects right now which I'd like to include into gcc-4.9.
> 
> But I think, this still can be fixed on stage2 as it is a PR.
> 
> > I can imagine it is a quite tricky case. If so I would suggest adding
> > m_CORE_ALL to X86_TUNE_ACCUMULATE_OUTGOING_ARGS with a
> comment
> > explaining the problem and mentioning the regression on equake on core
> > and mgrid on Bulldizer and opening an enhancement request for this...
> >
> > I also wonder if direct ESP use and push/pop instructions are causing
> > so noticeable issues, I wonder if we can't "shrink wrap" this into
> > red-zone in the 64bit compilation.  It seems that even with
> > -maccumulate-outgoing-args pushing the frame allocation as late as
> > possible in the function would be a good idea so it is not close to the
> push/pop/call/ret.
> >
> >

[PATCH, i386]: Do not compile crtfastmath.c and crtprec.c for soft-float targets

[Uros Bizjak]

Hello!

There is no point to access FP hardware for soft-float targets.

2013-11-03  Uros Bizjak  

* config/i386/crtfastmath.c: Compile only for !_SOFT_FLOAT.
* config/i386/crtprec.c: Ditto.

Tested on x86_64-pc-linux-gnu, committed to mainline SVN.

Uros.
Index: config/i386/crtfastmath.c
===
--- config/i386/crtfastmath.c   (revision 204324)
+++ config/i386/crtfastmath.c   (working copy)
@@ -21,6 +21,7 @@
  * .
  */
 
+#ifndef _SOFT_FLOAT
 #define MXCSR_DAZ (1 << 6) /* Enable denormals are zero mode */
 #define MXCSR_FTZ (1 << 15)/* Enable flush to zero mode */
 
@@ -134,3 +135,4 @@
   __builtin_ia32_ldmxcsr (mxcsr);
 #endif
 }
+#endif
Index: config/i386/crtprec.c
===
--- config/i386/crtprec.c   (revision 204324)
+++ config/i386/crtprec.c   (working copy)
@@ -21,6 +21,7 @@
  * .
  */
 
+#ifndef _SOFT_FLOAT
 #if __PREC == 32
  #define X87CW (0 << 8)/* Single precision (24 bits) */
 #elif __PREC == 64
@@ -45,3 +46,4 @@
 
   asm volatile ("fldcw\t%0" : : "m" (cwd));
 }
+#endif

[wide-int] Restore msp430 build

[Richard Sandiford]

Installed as obvious.

Richard


Index: gcc/config/msp430/msp430.c
===
--- gcc/config/msp430/msp430.c  2013-11-03 10:04:56.004019113 +
+++ gcc/config/msp430/msp430.c  2013-11-03 10:19:04.928118621 +
@@ -1058,7 +1058,7 @@ msp430_attr (tree * node,
  break;
 
case INTEGER_CST:
- if (TREE_INT_CST_LOW (value) > 31)
+ if (wi::gtu_p (value, 31))
/* Allow the attribute to be added - the linker script
   being used may still recognise this value.  */
warning (OPT_Wattributes,
@@ -1132,7 +1132,7 @@ msp430_start_function (FILE *file, const
 TREE_STRING_POINTER (intr_vector));
  else /* TREE_CODE (intr_vector) == INTEGER_CST */
sprintf (buf, "__interrupt_vector_%u",
-(unsigned int) TREE_INT_CST_LOW (intr_vector));
+(unsigned int) tree_to_hwi (intr_vector));
 
  switch_to_section (get_section (buf, SECTION_CODE, decl));
  fputs ("\t.word\t", file);

[wide-int] Restore SPARC build

[Richard Sandiford]

...since I'd forgotten to update it when doing the wi:: stuff.

Installed as obvious.

Richard


Index: gcc/config/sparc/sparc.c
===
--- gcc/config/sparc/sparc.c2013-11-03 10:04:56.004019113 +
+++ gcc/config/sparc/sparc.c2013-11-03 10:21:25.557126367 +
@@ -10621,26 +10621,26 @@ sparc_fold_builtin (tree fndecl, int n_a
  && TREE_CODE (arg2) == INTEGER_CST)
{
  bool overflow, overall_overflow = false;
- wide_int result = wide_int::from_tree (arg2);
+ wide_int result = arg2;
  wide_int tmp;
  unsigned i;
 
  for (i = 0; i < VECTOR_CST_NELTS (arg0); ++i)
{
- wide_int e0 = wide_int::from_tree (VECTOR_CST_ELT (arg0, i));
- wide_int e1 = wide_int::from_tree (VECTOR_CST_ELT (arg1, i));
+ tree e0 = VECTOR_CST_ELT (arg0, i);
+ tree e1 = VECTOR_CST_ELT (arg1, i);
 
- tmp = e1.neg (&overflow);
+ tmp = wi::neg (e1, &overflow);
  overall_overflow |= overall_overflow;
- tmp = e0.add (tmp, SIGNED, &overflow);
+ tmp = wi::add (e0, tmp, SIGNED, &overflow);
  overall_overflow |= overall_overflow;
- if (tmp.neg_p ())
+ if (wi::neg_p (tmp))
{
- tmp = tmp.neg (&overflow);
+ tmp = wi::neg (tmp, &overflow);
  overall_overflow |= overall_overflow;
}
 
- result = result.add (tmp, SIGNED, &overflow);
+ result = wi::add (result, tmp, SIGNED, &overflow);
  overall_overflow |= overall_overflow;
}
 

[wide-int] Restore VAX build

[Richard Sandiford]

Installed as obvious.

Richard


Index: gcc/config/vax/vax.c
===
--- gcc/config/vax/vax.c2013-11-03 10:24:01.013238719 +
+++ gcc/config/vax/vax.c2013-11-03 10:24:02.308247979 +
@@ -643,7 +643,7 @@ vax_float_literal (rtx c)
 {
   int x = 1 << i;
   bool ok;
-  REAL_VALUE_FROM_INT (s, x, 0, mode);
+  REAL_VALUE_FROM_INT (s, x, mode);
 
   if (REAL_VALUES_EQUAL (r, s))
return true;

[PATCH] Fix PR58115

[Bernd Edlinger]

Hello,

on i686-pc-linux-gnu the test case gcc.target/i386/intrinsics_4.c fails because 
of
an internal compiler error, see PR58155.

The reason for this is that the optab CODE_FOR_movv8sf is disabled when it
should be enabled.

This happens because invoke_set_current_function_hook changes the pointer
"this_fn_optabs" after targetm.set_current_function has already modified the
optab to enable/disable CODE_FOR_movv8sf, leaving that optab entry
in an undefined state.

Boot-strapped and regression-tested on i686-pc-linux-gnu.

Ok for trunk?

Regards
Bernd.2013-11-03  Bernd Edlinger  

PR target/58115
* function.c (invoke_set_current_function_hook): Call
targetm.set_current_function after setting this_fn_optabs.



patch-pr58115.diff
Description: Binary data

[wide-int] Simplify some force_fit_type calls

[Richard Sandiford]

When going through force_fit_type calls to see whether they were
extending correctly, I noticed some of the calls in VRP could be simplified.

There's no change in behaviour, it's just shorter and more efficient.

Tested on powerpc64-linux-gnu and x86_64-linux-gnu.  OK to install?

Thanks,
Richard


Index: gcc/tree-vrp.c
===
--- gcc/tree-vrp.c  2013-11-03 10:04:56.004019113 +
+++ gcc/tree-vrp.c  2013-11-03 10:25:45.398984735 +
@@ -1617,16 +1617,8 @@ extract_range_from_assert (value_range_t
   /* Make sure to not set TREE_OVERFLOW on the final type
 conversion.  We are willingly interpreting large positive
 unsigned values as negative singed values here.  */
-  min = force_fit_type (TREE_TYPE (var),
-   wide_int::from (min,
-   TYPE_PRECISION (TREE_TYPE (var)),
-   TYPE_SIGN (TREE_TYPE (min))),
-   0, false);
-  max = force_fit_type (TREE_TYPE (var),
-   wide_int::from (max,
-   TYPE_PRECISION (TREE_TYPE (var)),
-   TYPE_SIGN (TREE_TYPE (max))),
-   0, false);
+  min = force_fit_type (TREE_TYPE (var), wi::to_widest (min), 0, false);
+  max = force_fit_type (TREE_TYPE (var), wi::to_widest (max), 0, false);
 
   /* We can transform a max, min range to an anti-range or
  vice-versa.  Use set_and_canonicalize_value_range which does
@@ -3235,20 +3227,12 @@ extract_range_from_unary_expr_1 (value_r
  if (is_overflow_infinity (vr0.min))
new_min = negative_overflow_infinity (outer_type);
  else
-   new_min = force_fit_type (outer_type,
- wide_int::from
-   (vr0.min,
-TYPE_PRECISION (outer_type),
-TYPE_SIGN (TREE_TYPE (vr0.min))),
+   new_min = force_fit_type (outer_type, wi::to_widest (vr0.min),
  0, false);
  if (is_overflow_infinity (vr0.max))
new_max = positive_overflow_infinity (outer_type);
  else
-   new_max = force_fit_type (outer_type,
- wide_int::from
-   (vr0.max,
-TYPE_PRECISION (outer_type),
-TYPE_SIGN (TREE_TYPE (vr0.max))),
+   new_max = force_fit_type (outer_type, wi::to_widest (vr0.max),
  0, false);
  set_and_canonicalize_value_range (vr, vr0.type,
new_min, new_max, NULL);

Re: [Patch] Implementation of n3793

[Jonathan Wakely]

On 3 November 2013 09:49, Andreas Schwab wrote:
> Jonathan Wakely  writes:
>
>> +  {
>> +std::experimental::optional o { std::experimental::in_place, 
>> 0x1234ABCDF1E2D3C4 };
>> +auto copy = o;
>> +VERIFY( copy );
>> +VERIFY( *copy == 0x1234ABCDF1E2D3C4 );
>> +VERIFY( o && o == 0x1234ABCDF1E2D3C4 );
>> +  }
>
> experimental/optional/cons/copy.cc:70:20: error: no match for 'operator==' 
> (operand types are 'std::experimental::optional' and 'long long 
> int')
>  VERIFY( o && o == 0x1234ABCDF1E2D3C4 );
> ^

Yes, Paolo pointed out these are failing on 32-bit targets, I've got a
patch coming.  Luc is there any reason not to just replace all those
large constants with 0x1234ABCD, which fits in a long on 32-bit
targets?

Re: [Patch] Implementation of n3793

[Paolo Carlini]

On 11/03/2013 12:19 PM, Jonathan Wakely wrote:
Yes, Paolo pointed out these are failing on 32-bit targets, I've got a 
patch coming. Luc is there any reason not to just replace all those 
large constants with 0x1234ABCD, which fits in a long on 32-bit targets? 

By the way, that's what I did/hacked in my local tree ;)

Jon, I have got a bunch of other minor tweaks, from proper formatting of 
conditional operator and some curly braces, to using __and_ and __not_ 
when possible, and other thingies, like no full stops at the end of 
asserts and throws. Passes testing. You may want to integrate it with 
your other changes in testing... Or I can wait and apply it myself.


Paolo.

/

Index: include/experimental/optional
===
--- include/experimental/optional   (revision 204311)
+++ include/experimental/optional   (working copy)
@@ -129,7 +129,7 @@
   template
 struct _Has_addressof_impl<_Tp,
   decltype( std::declval().operator&(), void() )>
-: std::true_type { };
+  : std::true_type { };
 
   /**
 * @brief Trait that detects the presence of an overloaded unary operator&.
@@ -157,7 +157,7 @@
 */
   template::value,
 int>::type...>
-_Tp* __constexpr_addressof(_Tp& __t)
+inline _Tp* __constexpr_addressof(_Tp& __t)
 { return std::__addressof(__t); }
 
   /**
@@ -235,30 +235,30 @@
 if (this->_M_engaged && __other._M_engaged)
   this->_M_get() = __other._M_get();
 else
-{
-  if (__other._M_engaged)
-this->_M_construct(__other._M_get());
-  else
-this->_M_reset();
-}
+ {
+   if (__other._M_engaged)
+ this->_M_construct(__other._M_get());
+   else
+ this->_M_reset();
+ }
 
 return *this;
   }
 
   _Optional_base&
   operator=(_Optional_base&& __other)
-  noexcept(is_nothrow_move_constructible<_Tp>()
-   && is_nothrow_move_assignable<_Tp>())
+  noexcept(__and_,
+ is_nothrow_move_assignable<_Tp>>())
   {
 if (this->_M_engaged && __other._M_engaged)
   this->_M_get() = std::move(__other._M_get());
 else
-{
-  if (__other._M_engaged)
-this->_M_construct(std::move(__other._M_get()));
-  else
-this->_M_reset();
-}
+ {
+   if (__other._M_engaged)
+ this->_M_construct(std::move(__other._M_get()));
+   else
+ this->_M_reset();
+ }
 
 return *this;
   }
@@ -376,30 +376,30 @@
 if (this->_M_engaged && __other._M_engaged)
   this->_M_get() = __other._M_get();
 else
-{
-  if (__other._M_engaged)
-this->_M_construct(__other._M_get());
-  else
-this->_M_reset();
-}
+ {
+   if (__other._M_engaged)
+ this->_M_construct(__other._M_get());
+   else
+ this->_M_reset();
+ }
 
 return *this;
   }
 
   _Optional_base&
   operator=(_Optional_base&& __other)
-  noexcept(is_nothrow_move_constructible<_Tp>()
-   && is_nothrow_move_assignable<_Tp>())
+  noexcept(__and_,
+ is_nothrow_move_assignable<_Tp>>())
   {
 if (this->_M_engaged && __other._M_engaged)
   this->_M_get() = std::move(__other._M_get());
 else
-{
-  if (__other._M_engaged)
-this->_M_construct(std::move(__other._M_get()));
-  else
-this->_M_reset();
-}
+ {
+   if (__other._M_engaged)
+ this->_M_construct(std::move(__other._M_get()));
+   else
+ this->_M_reset();
+ }
 
 return *this;
   }
@@ -445,9 +445,10 @@
 
 private:
   struct _Empty_byte { };
-  union {
-  _Empty_byte _M_empty;
-  _Stored_type _M_payload;
+  union
+  {
+   _Empty_byte _M_empty;
+   _Stored_type _M_payload;
   };
   bool _M_engaged = false;
 };
@@ -462,22 +463,22 @@
 // Copy constructor.
 is_copy_constructible<_Tp>::value,
 // Copy assignment.
-is_copy_constructible<_Tp>::value
-&& is_copy_assignable<_Tp>::value,
+__and_,
+  is_copy_assignable<_Tp>>::value,
 // Move constructor.
 is_move_constructible<_Tp>::value,
 // Move assignment.
-is_move_constructible<_Tp>::value
-&& is_move_assignable<_Tp>::value,
+__and_,
+  is_move_assignable<_Tp>>::value,
 // Unique tag type.
 optional<_Tp>>
 {
-  static_assert(!is_same::type,
- nullopt_t>()
-&& !is_same::type,
- in_place_t>()
-&&

[avr] Use unsigned int rather than double_int for insert_bits

[Richard Sandiford]

The __builtin_avr_insert_bits code uses a double_int to handle the mask,
but AIUI the mask has exactly 32 bits.  Is that right?  If so, would it be
OK to use "unsigned int" instead?  I realise this might seem like pointless
churn, but it would help out with the wide_int conversion.

Doing this also gets rid of the last use of the %X avr_[fe]dump format.
It looks like %D is already unused.  So would it be OK to get rid of them
at the same time?  The hope is that wide_int will remove all remaining
uses of double_int, so new uses are unlikely to pop up.

I tested this by compiling builtin_insert_bits-{1,2}.c before and after
the patch at various optimisation levels and checking that they produce
the same code.  OK to install?

Thanks,
Richard


gcc/
* config/avr/avr-log.c (avr_double_int_pop_digit): Delete.
(avr_dump_double_int_hex): Likewise.
(avr_log_vadump): Remove %D and %X handling.
* config/avr/avr.c (avr_double_int_push_digit): Delete.
(avr_map_op_t): Change map from double_int to unsigned int.
(avr_map_op): Update accordingly.
(avr_map, avr_map_metric, avr_has_nibble_0xf, avr_map_decompose)
(avr_move_bits, avr_out_insert_bits, avr_fold_builtin): Operate on
unsigned ints rather than double_ints.

Index: gcc/config/avr/avr-log.c
===
--- gcc/config/avr/avr-log.c2013-11-02 22:04:29.294186290 +
+++ gcc/config/avr/avr-log.c2013-11-03 11:43:19.689884434 +
@@ -49,8 +49,6 @@
   C: enum rtx_code
   m: enum machine_mode
   R: enum reg_class
-  D: double_int (signed decimal)
-  X: double_int (unsigned hex)
   L: insn list
   H: location_t
 
@@ -138,45 +136,6 @@ avr_log_set_caller_f (const char *caller
 }
 
 
-/* Copy-paste from double-int.c:double_int_split_digit (it's static there).
-   Splits last digit of *CST (taken as unsigned) in BASE and returns it.  */
-
-static unsigned
-avr_double_int_pop_digit (double_int *cst, unsigned base)
-{
-  double_int drem;
-
-  *cst = cst->udivmod (double_int::from_uhwi (base), (int) FLOOR_DIV_EXPR,
-   &drem);
-
-  return (unsigned) drem.to_uhwi();
-}
-
-
-/* Dump VAL as hex value to FILE.  */
-
-static void
-avr_dump_double_int_hex (FILE *file, double_int val)
-{
-  unsigned digit[4];
-
-  digit[0] = avr_double_int_pop_digit (&val, 1 << 16);
-  digit[1] = avr_double_int_pop_digit (&val, 1 << 16);
-  digit[2] = avr_double_int_pop_digit (&val, 1 << 16);
-  digit[3] = avr_double_int_pop_digit (&val, 1 << 16);
-
-  fprintf (file, "0x");
-
-  if (digit[3] | digit[2])
-fprintf (file, "%04x%04x", digit[3], digit[2]);
-
-  if (digit[3] | digit[2] | digit[1] | digit[0])
-fprintf (file, "%04x%04x", digit[1], digit[0]);
-  else
-fprintf (file, "0");
-}
-
-
 /* Worker function implementing the %-codes and forwarding to
respective print/dump function.  */
 
@@ -231,14 +190,6 @@ avr_log_vadump (FILE *file, const char *
   fprintf (file, "%d", va_arg (ap, int));
   break;
 
-case 'D':
-  dump_double_int (file, va_arg (ap, double_int), false);
-  break;
-
-case 'X':
-  avr_dump_double_int_hex (file, va_arg (ap, double_int));
-  break;
-
 case 'x':
   fprintf (file, "%x", va_arg (ap, int));
   break;
Index: gcc/config/avr/avr.c
===
--- gcc/config/avr/avr.c2013-11-02 22:04:29.297186315 +
+++ gcc/config/avr/avr.c2013-11-03 11:47:27.100686844 +
@@ -11365,26 +11365,12 @@ avr_expand_delay_cycles (rtx operands0)
 }
 
 
-/* Return VAL * BASE + DIGIT.  BASE = 0 is shortcut for BASE = 2^{32}   */
-
-static double_int
-avr_double_int_push_digit (double_int val, int base,
-   unsigned HOST_WIDE_INT digit)
-{
-  val = 0 == base
-? val.llshift (32, 64)
-: val * double_int::from_uhwi (base);
-
-  return val + double_int::from_uhwi (digit);
-}
-
-
 /* Compute the image of x under f, i.e. perform   x --> f(x)*/
 
 static int
-avr_map (double_int f, int x)
+avr_map (unsigned int f, int x)
 {
-  return 0xf & f.lrshift (4*x, 64).to_uhwi ();
+  return x < 8 ? (f >> (4 * x)) & 0xf : 0;
 }
 
 
@@ -11409,7 +11395,7 @@ enum
   };
 
 static unsigned
-avr_map_metric (double_int a, int mode)
+avr_map_metric (unsigned int a, int mode)
 {
   unsigned i, metric = 0;
 
@@ -11442,7 +11428,8 @@ avr_map_metric (double_int a, int mode)
 bool
 avr_has_nibble_0xf (rtx ival)
 {
-  return 0 != avr_map_metric (rtx_to_double_int (ival), MAP_MASK_PREIMAGE_F);
+  unsigned int map = UINTVAL (ival) & GET_MODE_MASK (SImode);
+  return 0 != avr_map_metric (map, MAP_MASK_PREIMAGE_F);
 }
 
 
@@ -11476,7 +11463,7 @@ typedef struct
   int cost;
 
   /* The composition F o G^-1 (*, arg) for some function F */
-  double_int map;
+  unsigned int map;
 
   /* For debug purpose only */
   const char *str;
@@ -1

Re: [avr] Use unsigned int rather than double_int for insert_bits

[Denis Chertykov]

2013/11/3 Richard Sandiford :
> The __builtin_avr_insert_bits code uses a double_int to handle the mask,
> but AIUI the mask has exactly 32 bits.  Is that right?  If so, would it be
> OK to use "unsigned int" instead?  I realise this might seem like pointless
> churn, but it would help out with the wide_int conversion.
>
> Doing this also gets rid of the last use of the %X avr_[fe]dump format.
> It looks like %D is already unused.  So would it be OK to get rid of them
> at the same time?  The hope is that wide_int will remove all remaining
> uses of double_int, so new uses are unlikely to pop up.
>
> I tested this by compiling builtin_insert_bits-{1,2}.c before and after
> the patch at various optimisation levels and checking that they produce
> the same code.  OK to install?
>
> Thanks,
> Richard
>
>
> gcc/
> * config/avr/avr-log.c (avr_double_int_pop_digit): Delete.
> (avr_dump_double_int_hex): Likewise.
> (avr_log_vadump): Remove %D and %X handling.
> * config/avr/avr.c (avr_double_int_push_digit): Delete.
> (avr_map_op_t): Change map from double_int to unsigned int.
> (avr_map_op): Update accordingly.
> (avr_map, avr_map_metric, avr_has_nibble_0xf, avr_map_decompose)
> (avr_move_bits, avr_out_insert_bits, avr_fold_builtin): Operate on
> unsigned ints rather than double_ints.
>


Please apply.

Denis.

Re: [wide-int] Restore VAX build

[Kenneth Zadeck]

Vax, seriously???  Are there any left?


On Nov 3, 2013, at 5:24 AM, Richard Sandiford  
wrote:

> Installed as obvious.
> 
> Richard
> 
> 
> Index: gcc/config/vax/vax.c
> ===
> --- gcc/config/vax/vax.c2013-11-03 10:24:01.013238719 +
> +++ gcc/config/vax/vax.c2013-11-03 10:24:02.308247979 +
> @@ -643,7 +643,7 @@ vax_float_literal (rtx c)
> {
>   int x = 1 << i;
>   bool ok;
> -  REAL_VALUE_FROM_INT (s, x, 0, mode);
> +  REAL_VALUE_FROM_INT (s, x, mode);
> 
>   if (REAL_VALUES_EQUAL (r, s))
>return true;

[RFC PATCH, i386]: Define _SOFT_FLOAT for !TARGET_80387

[Uros Bizjak]

Hello!

Attached patch defines _SOFT_FLOAT internal define for !TARGET_80387
for all x86 targets, similar to what RTEMS has been doing. This define
can be used to disable various parts af hardware FPU support in
libgcc, when -mno-80387 a.k.a. -soft-float is in effect. Please also
see the thread, starting at [1].

2013-11-03  Uros Bizjak  

* config/i386/i386-c.c (ix86_target_macros): Define _SOFT_FLOAT
for !TARGET_80387.
* config/i386/rtemself.h (TARGET_OS_CPP_BUILTINS): Do not define
_SOFT_FLOAT here.

Patch was bootstrapped and regression tested on x96_64-pc-linux-gnu {,-m32}.

I will wait a couple of days for possible comments.

[1] http://gcc.gnu.org/ml/gcc-help/2013-10/msg2.html

Uros.
Index: config/i386/i386-c.c
===
--- config/i386/i386-c.c(revision 204324)
+++ config/i386/i386-c.c(working copy)
@@ -467,6 +467,9 @@ ix86_target_macros (void)
   builtin_define_std ("i386");
 }
 
+  if (!TARGET_80387)
+cpp_define (parse_in, "_SOFT_FLOAT");
+
   if (TARGET_LONG_DOUBLE_64)
 cpp_define (parse_in, "__LONG_DOUBLE_64__");
 
Index: config/i386/rtemself.h
===
--- config/i386/rtemself.h  (revision 204324)
+++ config/i386/rtemself.h  (working copy)
@@ -26,7 +26,5 @@ along with GCC; see the file COPYING3.  If not see
builtin_define ("__rtems__");   \
builtin_define ("__USE_INIT_FINI__");   \
builtin_assert ("system=rtems");\
-   if (!TARGET_80387)  \
- builtin_define ("_SOFT_FLOAT");   \
 }  \
   while (0)

[wwwdocs] Buildstat update for 4.8

[Tom G. Christensen]

Latest results for gcc 4.8.x.

-tgc

Testresults for 4.8.2
  arm-unknown-linux-gnueabi
  i386-pc-solaris2.9
  i686-pc-linux-gnu (2)
  i686-unknown-linux-gnu
  mips-unknown-linux-gnu
  mipsel-unknown-linux-gnu
  powerpc-apple-darwin8.11.0
  powerpc-unknown-linux-gnu
  sparc-sun-solaris2.9
  sparc64-sun-solaris2.10 (2)
  sparc-unknown-linux-gnu
  x86_64-apple-darwin13
  x86_64-unknown-linux-gnu (2)

Index: buildstat.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.8/buildstat.html,v
retrieving revision 1.5
diff -u -r1.5 buildstat.html
--- buildstat.html  2 Oct 2013 08:58:33 -   1.5
+++ buildstat.html  3 Nov 2013 15:04:43 -
@@ -26,6 +26,7 @@
 arm-unknown-linux-gnueabi
  
 Test results:
+http://gcc.gnu.org/ml/gcc-testresults/2013-10/msg01757.html";>4.8.2,
 http://gcc.gnu.org/ml/gcc-testresults/2013-06/msg01612.html";>4.8.1,
 http://gcc.gnu.org/ml/gcc-testresults/2013-03/msg02658.html";>4.8.0
 
@@ -85,6 +86,7 @@
 i386-pc-solaris2.9
  
 Test results:
+http://gcc.gnu.org/ml/gcc-testresults/2013-10/msg02068.html";>4.8.2,
 http://gcc.gnu.org/ml/gcc-testresults/2013-08/msg00230.html";>4.8.1,
 http://gcc.gnu.org/ml/gcc-testresults/2013-06/msg00416.html";>4.8.1,
 http://gcc.gnu.org/ml/gcc-testresults/2013-06/msg00415.html";>4.8.0,
@@ -112,15 +114,26 @@
 i686-pc-linux-gnu
  
 Test results:
+http://gcc.gnu.org/ml/gcc-testresults/2013-10/msg01348.html";>4.8.2,
+http://gcc.gnu.org/ml/gcc-testresults/2013-10/msg01313.html";>4.8.2,
 http://gcc.gnu.org/ml/gcc-testresults/2013-07/msg02349.html";>4.8.1,
 http://gcc.gnu.org/ml/gcc-testresults/2013-04/msg03091.html";>4.8.0
 
 
 
 
+i686-unknown-linux-gnu
+ 
+Test results:
+http://gcc.gnu.org/ml/gcc-testresults/2013-10/msg01351.html";>4.8.2
+
+
+
+
 mips-unknown-linux-gnu
  
 Test results:
+http://gcc.gnu.org/ml/gcc-testresults/2013-10/msg01758.html";>4.8.2,
 http://gcc.gnu.org/ml/gcc-testresults/2013-06/msg02891.html";>4.8.1
 
 
@@ -129,6 +142,7 @@
 mipsel-unknown-linux-gnu
  
 Test results:
+http://gcc.gnu.org/ml/gcc-testresults/2013-10/msg01759.html";>4.8.2,
 http://gcc.gnu.org/ml/gcc-testresults/2013-06/msg01568.html";>4.8.1,
 http://gcc.gnu.org/ml/gcc-testresults/2013-03/msg02562.html";>4.8.0
 
@@ -138,6 +152,7 @@
 powerpc-apple-darwin8.11.0
  
 Test results:
+http://gcc.gnu.org/ml/gcc-testresults/2013-10/msg01405.html";>4.8.2,
 http://gcc.gnu.org/ml/gcc-testresults/2013-06/msg00237.html";>4.8.1,
 http://gcc.gnu.org/ml/gcc-testresults/2013-04/msg01012.html";>4.8.0
 
@@ -163,6 +178,7 @@
 powerpc-unknown-linux-gnu
  
 Test results:
+http://gcc.gnu.org/ml/gcc-testresults/2013-11/msg00014.html";>4.8.2,
 http://gcc.gnu.org/ml/gcc-testresults/2013-06/msg01486.html";>4.8.1,
 http://gcc.gnu.org/ml/gcc-testresults/2013-03/msg02452.html";>4.8.0
 
@@ -180,6 +196,7 @@
 sparc-sun-solaris2.9
  
 Test results:
+http://gcc.gnu.org/ml/gcc-testresults/2013-10/msg02067.html";>4.8.2,
 http://gcc.gnu.org/ml/gcc-testresults/2013-08/msg00243.html";>4.8.1,
 http://gcc.gnu.org/ml/gcc-testresults/2013-03/msg02774.html";>4.8.0,
 http://gcc.gnu.org/ml/gcc-testresults/2013-03/msg02717.html";>4.8.0
@@ -206,6 +223,8 @@
 sparc64-sun-solaris2.10
  
 Test results:
+http://gcc.gnu.org/ml/gcc-testresults/2013-10/msg01666.html";>4.8.2,
+http://gcc.gnu.org/ml/gcc-testresults/2013-10/msg01379.html";>4.8.2,
 http://gcc.gnu.org/ml/gcc-testresults/2013-03/msg02413.html";>4.8.0
 
 
@@ -214,6 +233,7 @@
 sparc-unknown-linux-gnu
  
 Test results:
+http://gcc.gnu.org/ml/gcc-testresults/2013-10/msg01785.html";>4.8.2,
 http://gcc.gnu.org/ml/gcc-testresults/2013-06/msg02503.html";>4.8.1,
 http://gcc.gnu.org/ml/gcc-testresults/2013-03/msg02660.html";>4.8.0
 
@@ -244,6 +264,14 @@
 
 
 
+x86_64-apple-darwin13
+ 
+Test results:
+http://gcc.gnu.org/ml/gcc-testresults/2013-10/msg01562.html";>4.8.2
+
+
+
+
 x86_64-apple-darwin13.0.0
  
 Test results:
@@ -255,6 +283,8 @@
 x86_64-unknown-linux-gnu
  
 Test results:
+http://gcc.gnu.org/ml/gcc-testresults/2013-10/msg01854.html";>4.8.2,
+http://gcc.gnu.org/ml/gcc-testresults/2013-10/msg01777.html";>4.8.2,
 http://gcc.gnu.org/ml/gcc-testresults/2013-03/msg02881.html";>4.8.0,
 http://gcc.gnu.org/ml/gcc-testresults/2013-03/msg02623.html";>4.8.0
 

Re: Testsuite / Cilk Plus: Include library path in compile flags in gcc.dg/cilk-plus/cilk-plus.exp

[Iain Sandoe]

Hi!
On 30 Oct 2013, at 20:55, Joseph S. Myers wrote:

> On Wed, 30 Oct 2013, Tobias Burnus wrote:
> 
>> On the other hand, one could use the existence of libcilkrts* as detected by
>> the patch to decide whether to link or not: If the library is there, one can
>> link – if not found, it is unlikely to work (unless it is, e.g. found in
>> /usr/lib).
> 
> The way to detect it is to try to link with it, rather than just looking 
> for it in the build tree.  If you just look for it in the build tree and 
> assume it's missing if not found there, you break installed testing.  See 
> Andrew's recent patch fixing this for asan/ubsan testing (or what I did 
> for tests linking with libatomic on the C11-atomic branch).

In addition to other posters, a few other observations.

1). the c execute tests all fail on Darwin (because nothing is calling 
set_ld_library_path_env_vars).
  Note that this could cause particularly subtle issues, if one builds 
consecutive versions of the compiler with the same install path (and install 
the compiler after testing).  Since the new compiler could end up testing the 
previously installed shlib [at least on Darwin].

A minimal fix for the execute tests (in-tree testing) is to add 
set_ld_library_path_env_vars after the ld_library_path is decided (although 
this does not fix installed testing, of course).

2). The C tests are extremely time-consuming (m32/m64) with NO -jxx on the c/l:

  x86_64-linux (32 cores 2.8G Xeon) : 36m/421m/6m
  x86_64-darwin12 (8 cores 2.8G Xeon) : 45m/309m/2m.

c.f. the g++ tests which take ~2m wall clock.

this might be nothing to do with cilk, but it certainly warrants investigation.

3). The "torture" mixes you have are not obvious (at least to me):

 * there are a lot of tests where you do "-O0" and "" 
 * also you test "-O2 -ftree-vectorize" (but not -O2) 
 * but -O3 with / without -ftree-vectorize.
 * you test a few LTO combinations for C but none for C++
 * you test C with/without -std=c99. 
 * but don't test C++ with -std=c++98 and -std=c++11.

There might be perfectly good reasons for these; but, as I say, they are not 
obvious ( at least to me ;) ) and probably warrant a comment in the .exp as to 
the rationale for the choices.



I'm attaching three .exp files which might form the basis of an alternate 
implementation of the testing - they fix the execute tests on darwin and work 
for installed testing too.

However, given that Q2 and Q3 above might involve some changes, there are 
probably additional modifications needed.

in the new .exps, the c++ tests do -std=c++98 and -std=c++11, 
but otherwise do the same torture mix as you have, so would also need 
adjustment once the questions are resolved.

cilk-dg.exp => gcc/testsuite/lib/cilk-dg.exp
cilk-plus.exp => gcc/testsuite/gcc.dg/cilk-plus/cilk-plus.exp
cxx-cilk-plus.exp => gcc/testsuite/g++.dg/cilk-plus/cilk-plus.exp

rename / use / ignore - as appropriate ;)

cheers,
Iain



cilk-plus.exp
Description: Binary data



cxx-cilk-plus.exp
Description: Binary data



cilk-dg.exp
Description: Binary data

[C++ Patch] PR 38313

[Paolo Carlini]

Hi,

I had a look to this very old parsing issue and having studied it a bit, 
I decided that it could make sense to attack it directly, thus basing 
directly on the note in Bugzilla left by Jason: enforce that the 
declaration of a constructor of T actually names T! Testsuite passes 
smoothly on x86_64-linux.


Thanks,
Paolo.

/
/cp
2013-11-03  Paolo Carlini  

PR c++/38313
* parser.c (cp_parser_constructor_declarator_p): Check that the
class-name matches current_class_type.

/testsuite
2013-11-03  Paolo Carlini  

PR c++/38313
* g++.dg/lookup/name-clash10.C: New.
Index: cp/parser.c
===
--- cp/parser.c (revision 204333)
+++ cp/parser.c (working copy)
@@ -22211,6 +22211,7 @@ static bool
 cp_parser_constructor_declarator_p (cp_parser *parser, bool friend_p)
 {
   bool constructor_p;
+  bool outside_class_specifier_p;
   tree nested_name_specifier;
   cp_token *next_token;
 
@@ -22243,11 +22244,14 @@ cp_parser_constructor_declarator_p (cp_parser *par
/*check_dependency_p=*/false,
/*type_p=*/false,
/*is_declaration=*/false));
+
+  outside_class_specifier_p = (!at_class_scope_p ()
+  || !TYPE_BEING_DEFINED (current_class_type)
+  || friend_p);
+
   /* Outside of a class-specifier, there must be a
  nested-name-specifier.  */
-  if (!nested_name_specifier &&
-  (!at_class_scope_p () || !TYPE_BEING_DEFINED (current_class_type)
-   || friend_p))
+  if (!nested_name_specifier && outside_class_specifier_p)
 constructor_p = false;
   else if (nested_name_specifier == error_mark_node)
 constructor_p = false;
@@ -22286,8 +22290,16 @@ cp_parser_constructor_declarator_p (cp_parser *par
/*check_dependency_p=*/false,
/*class_head_p=*/false,
/*is_declaration=*/false);
-  /* If there was no class-name, then this is not a constructor.  */
-  constructor_p = !cp_parser_error_occurred (parser);
+  /* If there was no class-name, then this is not a constructor.
+Otherwise, if we are in a class-specifier and we aren't
+handling a friend declaration, check that its type matches
+current_class_type (c++/38313).  Note: error_mark_node
+is left alone for error recovery purposes.  */
+  constructor_p = (!cp_parser_error_occurred (parser)
+  && (outside_class_specifier_p
+  || type_decl == error_mark_node
+  || same_type_p (current_class_type,
+  TREE_TYPE (type_decl;
 
   /* If we're still considering a constructor, we have to see a `(',
 to begin the parameter-declaration-clause, followed by either a
Index: testsuite/g++.dg/lookup/name-clash10.C
===
--- testsuite/g++.dg/lookup/name-clash10.C  (revision 0)
+++ testsuite/g++.dg/lookup/name-clash10.C  (working copy)
@@ -0,0 +1,8 @@
+// PR c++/38313
+
+struct foo { };
+struct bar { };
+
+struct baz {
+  static foo (bar)();
+};

Re: [wide-int] Restore VAX build

[Steven Bosscher]

On Sun, Nov 3, 2013 at 2:29 PM, Kenneth Zadeck wrote:
> Vax, seriously???  Are there any left?

Maybe. Maybe not. But there are decent VAX simulators, and Linux,
NetBSD, and OpenBSD have been ported to VAX.

Remember they were still building VAX machines in 2005, when e.g.
Alpha and HP-PA were already effectively dead... :-)

Ciao!
Steven

[Patch, ObjC, ObjC++, Darwin] Remove "-fobjc-sjlj-exceptions"

[Iain Sandoe]

The Objective C/C++ exceptions model is, currently, completely determined by 
the combination of runtime {gnu, next} and ABI {m32/V1, m64/V2}.

Thus, the "-fobjc-sjlj-exceptions" command line option is redundant and may be 
removed.
(note that trunk clang doesn't even accept the option, although xcode 4.6.3 
still does).

The patch below removes the action of the flag, and produces a warning if the 
User puts it on a c/l.

This has been in use for some time on my *-darwin* systems and has been tested 
also on x86_64-linux. 
 
The option is apparently undocumented in the current User's manual, hence, 
there are no adjustments to documentation.

OK for trunk?
Iain

gcc/c-family:

* c-opts.c (c_common_post_options): Remove handling of
flag_objc_sjlj_exceptions.
* c.opt (fobjc-sjlj-exceptions): Issue a warning if this
option is given.

gcc:
* config/darwin.c (darwin_override_options): Remove handling
of flag_objc_sjlj_exceptions.

gcc/objc:

* objc-act.c (objc_begin_try_stmt): Find the exceptions model
in force from the runtime structure rather than a command line
flag.
* objc-gnu-runtime-abi-01.c (objc_gnu_runtime_abi_01_init): Set
up the exceptions model and handle conflicting User selections.
* objc-next-runtime-abi-02.c (objc_next_runtime_abi_02_init): 
Likewise.
* objc-next-runtime-abi-01.c (OBJC_SJLJ_EXCEPTIONS): Define true.
(objc_next_runtime_abi_01_init): Set up the exceptions model and
 handle conflicting User selections.
(next_runtime_01_initialize, objc_build_exc_ptr, finish_try_stmt): 
Use OBJC_SJLJ_EXCEPTIONS rather than a flag.
* objc-runtime-hooks.h (objc_exceptions_model_t): New enum.
(objc_runtime_hooks): Add exceptions model.

 gcc/c-family/c-opts.c   |  6 --
 gcc/c-family/c.opt  |  4 ++--
 gcc/config/darwin.c | 12 
 gcc/objc/objc-act.c |  2 +-
 gcc/objc/objc-gnu-runtime-abi-01.c  | 18 +-
 gcc/objc/objc-next-runtime-abi-01.c | 20 ++--
 gcc/objc/objc-next-runtime-abi-02.c | 20 +++-
 gcc/objc/objc-runtime-hooks.h   | 12 
 8 files changed, 53 insertions(+), 41 deletions(-)

diff --git a/gcc/c-family/c-opts.c b/gcc/c-family/c-opts.c
index 702fe1a..9d0b972 100644
--- a/gcc/c-family/c-opts.c
+++ b/gcc/c-family/c-opts.c
@@ -834,12 +834,6 @@ c_common_post_options (const char **pfilename)
   else if (!flag_gnu89_inline && !flag_isoc99)
 error ("-fno-gnu89-inline is only supported in GNU99 or C99 mode");
 
-  /* Default to ObjC sjlj exception handling if NeXT runtime.  */
-  if (flag_objc_sjlj_exceptions < 0)
-flag_objc_sjlj_exceptions = flag_next_runtime;
-  if (flag_objc_exceptions && !flag_objc_sjlj_exceptions)
-flag_exceptions = 1;
-
   /* -Woverlength-strings is off by default, but is enabled by -Wpedantic.
  It is never enabled in C++, as the minimum limit is not normative
  in that standard.  */
diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt
index b862eb9..23646f3 100644
--- a/gcc/c-family/c.opt
+++ b/gcc/c-family/c.opt
@@ -1058,8 +1058,8 @@ Enable inline checks for nil receivers with the NeXT 
runtime and ABI version 2.
 
 ; Nonzero means that we generate NeXT setjmp based exceptions.
 fobjc-sjlj-exceptions
-ObjC ObjC++ Var(flag_objc_sjlj_exceptions) Init(-1)
-Enable Objective-C setjmp exception handling runtime
+ObjC ObjC++ Ignore Warn(switch %qs has been removed and is set automatically 
where required)
+Option removed
 
 fobjc-std=objc1
 ObjC ObjC++ Var(flag_objc1_only)
diff --git a/gcc/config/darwin.c b/gcc/config/darwin.c
index fc7a9a8..3bf30db 100644
--- a/gcc/config/darwin.c
+++ b/gcc/config/darwin.c
@@ -3126,18 +3126,6 @@ darwin_override_options (void)
   flag_reorder_blocks = 1;
 }
 
-/* FIXME: flag_objc_sjlj_exceptions is no longer needed since there is only
-   one valid choice of exception scheme for each runtime.  */
-if (!global_options_set.x_flag_objc_sjlj_exceptions)
-  global_options.x_flag_objc_sjlj_exceptions = 
-   flag_next_runtime && !TARGET_64BIT;
-
-/* FIXME: and this could be eliminated then too.  */
-if (!global_options_set.x_flag_exceptions
-   && flag_objc_exceptions
-   && TARGET_64BIT)
-  flag_exceptions = 1;
-
   if (flag_mkernel || flag_apple_kext)
 {
   /* -mkernel implies -fapple-kext for C++ */
diff --git a/gcc/objc/objc-act.c b/gcc/objc/objc-act.c
index 95ec4ec..6103b3b 100644
--- a/gcc/objc/objc-act.c
+++ b/gcc/objc/objc-act.c
@@ -4126,7 +4126,7 @@ objc_begin_try_stmt (location_t try_locus, tree body)
   /* Collect the list of local variables.  We'll mark them as volatile
  at the end of compilation of this function to prevent them being
  clobbered by setjmp/longjmp.  */
-  if (flag_objc_sjlj_exceptions)
+  if (runtime.exceptions_model == objc_except

[Patch Ada/build] deal with some cross/native cross issues

[Iain Sandoe]

Hi,

I've been trying to improve the building and testing of Darwin for crosses and 
native crosses.

This has thrown up a few small glitches in the Ada build stuff (that would seem 
to apply to any build-host-nativeX scenario, not just darwin).  I would imagine 
it would be beneficial to resolve these, since Ada requires Ada - a native 
cross seems like the only realistic way onto a new target.

Having said that, I am not fully conversant with the build permutations you 
need to achieve - so the fixes proposed here might not be the best solutions;  
comments and suggestions welcome.

===

1. xgnatugn needs to be run on the build system, so needs to be built with the 
build system's gnatmake. 
I haven't put a canonical prefix on this since this doesn't appear to be done 
elsewhere.  
Defined as GNATMAKE_FOR_BUILD and passed to sub-processes.

2. Some builds might need to pass LDFLAGS to the gnat* builds.  Appended 
LDFLAGS to GCC_LINK.  Passed on in gnattools/Make.

3. In gnattools, the RTS dir must be for the host and not for the build;  This 
actually only showed up when I tried a cross from a 64bit pointer machine to a 
32bit pointer one (i.e it is easy for it to go unnoticed).  

With these changes I can build working crosses and native crosses at least on 
Darwin between machines of different pointer size and endianess.

OK for trunk?
Iain

gcc/ada:

* gcc-interface/Make-lang.in (GNATMAKE_FOR_BUILD): New, pass
to subordinate builds.
(xgnatugn): Build with GNATMAKE_FOR_BUILD.
* gcc-interface/Makefile.in (GCC_LINK): Append LDFLAGS.

gnattools:

* Makefile.in (TOOLS_FLAGS_TO_PASS_RE): Pass LDFLAGS.
(RTS_DIR): Use $(host)-gnatls when the host differs from build.

 gcc/ada/gcc-interface/Make-lang.in | 10 --
 gcc/ada/gcc-interface/Makefile.in  |  2 +-
 gnattools/Makefile.in  |  6 ++
 3 files changed, 15 insertions(+), 3 deletions(-)

diff --git a/gcc/ada/gcc-interface/Make-lang.in 
b/gcc/ada/gcc-interface/Make-lang.in
index cd3676f..dd5392f 100644
--- a/gcc/ada/gcc-interface/Make-lang.in
+++ b/gcc/ada/gcc-interface/Make-lang.in
@@ -53,6 +53,8 @@ CHECKING_ADAFLAGS= -gnata
 endif
 WARN_ADAFLAGS= -W -Wall
 
+GNATMAKE_FOR_BUILD=gnatmake
+
 # For native builds, the base compiler might be old and we need to arrange for
 # style warnings not to be flagged as errors during stage1.  Cross compilers
 # need to be built by a recent/matching native so we might as well leave the
@@ -147,7 +149,8 @@ ifeq ($(build), $(host))
 ADA_INCLUDES="-I- -I../rts" \
 GNATMAKE="../../gnatmake" \
 GNATLINK="../../gnatlink" \
-GNATBIND="../../gnatbind"
+GNATBIND="../../gnatbind" \
+GNATMAKE_FOR_BUILD="$(GNATMAKE_FOR_BUILD)"
   else
 # This is a regular cross compiler. Use the native compiler to compile
 # the tools.
@@ -166,6 +169,7 @@ ifeq ($(build), $(host))
 GNATMAKE="gnatmake" \
 GNATBIND="gnatbind" \
 GNATLINK="gnatlink" \
+GNATMAKE_FOR_BUILD="$(GNATMAKE_FOR_BUILD)" \
 LIBGNAT=""
   endif
 else
@@ -189,6 +193,7 @@ else
 GNATMAKE="$(GNATMAKE_FOR_HOST)"  \
 GNATBIND="$(GNATBIND_FOR_HOST)"  \
 GNATLINK="$(GNATLINK_FOR_HOST)"  \
+GNATMAKE_FOR_BUILD="$(GNATMAKE_FOR_BUILD)" \
 LIBGNAT=""
   else
 # This is a canadian cross. We should use a toolchain running on the
@@ -204,6 +209,7 @@ else
 GNATMAKE="$(GNATMAKE_FOR_HOST)"  \
 GNATBIND="$(GNATBIND_FOR_HOST)"  \
 GNATLINK="$(GNATLINK_FOR_HOST)"  \
+GNATMAKE_FOR_BUILD="$(GNATMAKE_FOR_BUILD)" \
 LIBGNAT=""
   endif
 endif
@@ -658,7 +664,7 @@ ada.tags: force
 ada/doctools/xgnatugn$(build_exeext): ada/xgnatugn.adb
-$(MKDIR) ada/doctools
$(CP) $^ ada/doctools
-   cd ada/doctools && $(GNATMAKE) -q xgnatugn
+   cd ada/doctools && $(GNATMAKE_FOR_BUILD) -q xgnatugn
 
 # Note that doc/gnat_ugn.texi and doc/projects.texi do not depend on
 # xgnatugn being built so we can distribute a pregenerated doc/gnat_ugn.info
diff --git a/gcc/ada/gcc-interface/Makefile.in 
b/gcc/ada/gcc-interface/Makefile.in
index 91778c5..d1a4981 100644
--- a/gcc/ada/gcc-interface/Makefile.in
+++ b/gcc/ada/gcc-interface/Makefile.in
@@ -2415,7 +2415,7 @@ TOOLS_FLAGS_TO_PASS=  \
"GNATLINK=$(GNATLINK)"  \
"GNATBIND=$(GNATBIND)"
 
-GCC_LINK=$(CXX) $(GCC_LINK_FLAGS) $(ADA_INCLUDES)
+GCC_LINK=$(CXX) $(GCC_LINK_FLAGS) $(ADA_INCLUDES) $(LDFLAGS)
 
 # Build directory for the tools. Let's copy the target-dependent
 # sources using the same mechanism as for gnatlib. The other sources are
diff --git a/gnattools/Makefile.in b/gnattools/Makefile.in
index fdd6491..118847c 100644
--- a/gnattools/Makefile.in
+++ b/gnattools/Makefile.in
@@ -24,6 +24,7 @@ srcdir = @srcdir@
 libdir = @libdir@
 build = @build@
 target = @target@
+host = @host@
 prefix = @prefix@
 INSTALL = @INSTALL@
 INSTALL_DATA = @INSTALL_DATA@
@@ -92,6 +93,

Re: [C++ Patch] PR 38313

[Jason Merrill]

OK.

Jason

Re: [ARM][PATCH] Fix testsuite testcase neon-vcond-[ltgt,unordered].c

[Christophe Lyon]

On 29 October 2013 10:38, Ramana Radhakrishnan  wrote:
> On 10/24/13 00:04, Kugan wrote:
>>
>> Hi,
>>
>> arm testcases neon-vcond-ltgt.c and neon-vcond-unordered.c fails in
>> Linaro 4.8 branch. It is not reproducable with trunk but it can happen.
>> Both neon-vcond-ltgt.c and neon-vcond-unordered.c scans for vbsl
>> instruction, with other vector instructions. However, as per the comment
>>   for "neon_vbsl_internal" md pattern defined in neon.md, gcc can
>> generate vbsl or vbit or vbif depending on the register allocation.
>> Therfore, these testcases should scan for one of these three
>> instructions instead of just vbsl. I have updated the testcases to scan
>> vbsl or vbit or vbif now.
>>
>> Is this OK?
>>
>> Thanks,
>> Kugan
>
>
>
> Hit send too soon on my earlier email. Minor nit in the Changelog as below.
> Need a newline between the DATE line and the file names .
>
>
Committed on Kugan's behalf as rev 204336.

Christophe.

Re: [Patch, ObjC, ObjC++, Darwin] Remove "-fobjc-sjlj-exceptions"

[Gerald Pfeifer]

Hi Ian,

On Sun, 3 Nov 2013, Iain Sandoe wrote:
> The option is apparently undocumented in the current User's manual, 
> hence, there are no adjustments to documentation.

I cannot approve the patch, but if it goes in that way or a similar 
one I recommend to add a short note to htdocs/gcc-4.9/changes.html,
just for those who may be using it.

Gerald

PATCH: PR target/58981: [4.9 Regression] FAIL: gcc.target/i386/memset-1.c execution test

[H.J. Lu]

Hi,

expand_set_or_movmem_prologue_epilogue_by_misaligned has

 rtx saveddest = *destptr;

  gcc_assert (desired_align <= size);
  /* Align destptr up, place it to new register.  */
  *destptr = expand_simple_binop (GET_MODE (*destptr), PLUS,
*destptr,
  GEN_INT (prolog_size),
  NULL_RTX, 1, OPTAB_DIRECT);
  *destptr = expand_simple_binop (GET_MODE (*destptr), AND,
*destptr,
  GEN_INT (-desired_align),
  *destptr, 1, OPTAB_DIRECT);
  /* See how many bytes we skipped.  */
  saveddest = expand_simple_binop (GET_MODE (*destptr), MINUS,
saveddest,
   *destptr,
   saveddest, 1, OPTAB_DIRECT);
  /* Adjust srcptr and count.  */
  if (!issetmem)
*srcptr = expand_simple_binop (GET_MODE (*srcptr), MINUS,
*srcptr, saveddest,
*srcptr, 1, OPTAB_DIRECT);
  *count = expand_simple_binop (GET_MODE (saveddest), PLUS, *count,
saveddest, *count, 1, OPTAB_DIRECT);

For x32, adddress may be in SImode and count may be in DImode:

(gdb) call debug_rtx (saveddest)
(reg:SI 101)
(gdb) call debug_rtx (*count)
(reg:DI 100)
(gdb) 

saveddest is a negative number and saveddest + count leads to overflow.
Instead, we should use mode of saveddest. It is OK since count must be
less than the size of address.  Tested on x32.  OK to install?

Thanks x32.  OK to install?

Thanks.


H.J.
2013-11-03  H.J. Lu  

PR target/58981
* config/i386/i386.c 
(expand_set_or_movmem_prologue_epilogue_by_misaligned):
Update count with mode of address.

diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 902e169..b27bfb6 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -23139,7 +23139,7 @@ 
expand_set_or_movmem_prologue_epilogue_by_misaligned_moves (rtx destmem, rtx src
   if (!issetmem)
*srcptr = expand_simple_binop (GET_MODE (*srcptr), MINUS, *srcptr, 
saveddest,
*srcptr, 1, OPTAB_DIRECT);
-  *count = expand_simple_binop (GET_MODE (*count), PLUS, *count,
+  *count = expand_simple_binop (GET_MODE (saveddest), PLUS, *count,
saveddest, *count, 1, OPTAB_DIRECT);
   /* We copied at most size + prolog_size.  */
   if (*min_size > (unsigned HOST_WIDE_INT)(size + prolog_size))

[C++ testcase, commiitted] PR 52071

[Paolo Carlini]

Hi,

my recent fix for c++/29234 fixed this one too, I'm adding the testcase 
and closing the bug.


Thanks,
Paolo.

/
2013-11-03  Paolo Carlini  

PR c++/52071
* g++.dg/parse/pr52071.C: New.
Index: g++.dg/parse/pr52071.C
===
--- g++.dg/parse/pr52071.C  (revision 0)
+++ g++.dg/parse/pr52071.C  (working copy)
@@ -0,0 +1,23 @@
+// PR c++/52071
+
+struct C1 {
+C1(int);
+};
+
+struct C2 {
+C2();
+C2(C1);
+};
+
+void f()
+{
+  int x;
+  int y = 1;
+  C2  vc;
+
+  vc = C2(C1(x = y));
+
+  vc = (C2(C1(x = y)));
+
+  vc = (C2(C1((0, x = y;
+}

Re: [PATCH] Handle __builtin_unreachable () using assertions in VRP

[Tom de Vries]

On 29/10/13 14:54, Jakub Jelinek wrote:
> +/* Return true if all imm uses of VAR are either in STMT, or
> +   feed (optionally through a chain of single imm uses) GIMPLE_COND
> +   in basic block COND_BB.  */
> +
> +static bool
> +all_imm_uses_in_stmt_or_feed_cond (tree var, gimple stmt, basic_block 
> cond_bb)
> +{
> +  use_operand_p use_p, use2_p;
> +  imm_use_iterator iter;
> +
> +  FOR_EACH_IMM_USE_FAST (use_p, iter, var)
> +if (USE_STMT (use_p) != stmt)
> +  {
> + gimple use_stmt = USE_STMT (use_p);
> + if (is_gimple_debug (use_stmt))
> +   continue;
> + while (is_gimple_assign (use_stmt)
> +&& single_imm_use (gimple_assign_lhs (use_stmt),
> +   &use2_p, &use_stmt))
> +   ;
> + if (gimple_code (use_stmt) != GIMPLE_COND
> + || gimple_bb (use_stmt) != cond_bb)
> +   return false;
> +  }
> +  return true;
> +}
> +

Jakub,

with g++.dg/torture/pr54684.C and -fno-tree-tail-merge, I run into a sigsegv
because of gimple_code (use_stmt) being called with use_stmt == NULL.

Thanks,
- Tom

Re: Fwd: [PATCH] Scheduling result adjustment to enable macro-fusion

[Jan Hubicka]

> Ping.  Is it ok for x86 maintainer?

I tought I already approved the x86 bits.
> 
> Thanks,
> Wei Mi.
> 
> On Wed, Oct 16, 2013 at 4:25 PM, Wei Mi  wrote:
> >> Go ahead and consider that pre-approved.  Just send it to the list with a
> >> note that I approved it in this thread.
> >>
> >> Jeff
> >
> > Thanks! The new patch addressed Jeff's comments.
> >
> > Is it ok for x86 maintainer?
> >
> > Thanks,
> > Wei Mi.
> >
> > 2013-10-16  Wei Mi  
> >
> > * gcc/config/i386/i386.c (memory_address_length): Extract a part
> > of code to rip_relative_addr_p.
> > (rip_relative_addr_p): New Function.
> > (ix86_macro_fusion_p): Ditto.
> > (ix86_macro_fusion_pair_p): Ditto.
> > * gcc/config/i386/i386.h: Add new tune features about macro-fusion.
> > * gcc/config/i386/x86-tune.def (DEF_TUNE): Ditto.
> > * gcc/doc/tm.texi: Generated.
> > * gcc/doc/tm.texi.in: Ditto.
> > * gcc/haifa-sched.c (try_group_insn): New Function.
> > (group_insns_for_macro_fusion): Ditto.
> > (sched_init): Call group_insns_for_macro_fusion.
> > * gcc/target.def: Add two hooks: macro_fusion_p and
> > macro_fusion_pair_p.
> >
The i386 bits are OK.

Honza

[driver] Force options Wa, Wl, Wp, to take a mandatory argument

[Mingjie Xing]

Hello,

This patch forces options Wa, Wl, Wp, to take a mandatory argument,
which can fix the bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55651.

Tested on i686-pc-linux-gnu.

2013-11-04  Mingjie Xing  

* common.opt (Wa, Wl, Wp,): Change JoinedOrMissing to Joined.

Is it OK?

Mingjie
Index: gcc/common.opt
===
--- gcc/common.opt	(revision 204285)
+++ gcc/common.opt	(working copy)
@@ -497,13 +497,13 @@ Common RejectNegative Warning Alias(Wext
 This switch is deprecated; use -Wextra instead
 
 Wa,
-Driver JoinedOrMissing
+Driver Joined
 
 Wl,
-Driver JoinedOrMissing
+Driver Joined
 
 Wp,
-Driver JoinedOrMissing
+Driver Joined
 
 Waggregate-return
 Common Var(warn_aggregate_return) Warning

Re: [Patch] Implementation of n3793

[Luc Danton]

On 2013-11-03 12:19, Jonathan Wakely wrote:

On 3 November 2013 09:49, Andreas Schwab wrote:

Jonathan Wakely  writes:


+  {
+std::experimental::optional o { std::experimental::in_place, 
0x1234ABCDF1E2D3C4 };
+auto copy = o;
+VERIFY( copy );
+VERIFY( *copy == 0x1234ABCDF1E2D3C4 );
+VERIFY( o && o == 0x1234ABCDF1E2D3C4 );
+  }

experimental/optional/cons/copy.cc:70:20: error: no match for 'operator==' (operand 
types are 'std::experimental::optional' and 'long long int')
  VERIFY( o && o == 0x1234ABCDF1E2D3C4 );
 ^

Yes, Paolo pointed out these are failing on 32-bit targets, I've got a
patch coming.  Luc is there any reason not to just replace all those
large constants with 0x1234ABCD, which fits in a long on 32-bit
targets?


The value is arbitrary, it's fine to proceed.

[PATCH GCC]Compute, cache and use cost of auto-increment rtx patterns in IVOPT

[bin.cheng]

Hi,

The IVOPT in GCC has a problem that it does not use cost of auto-increment
address expression in accounting, while it retreats to cost of address
expression if auto-increment addressing mode is unavailable.
For example, on ARM target:
1) the cost of "[reg]" (which is 6) is used for address expression "[reg],
#off";
2) the cost of "[reg+off]" (which is 2) is used for address expression
"[reg, #off]!"; 

This causes:
1) cost of non-auto increment address expression is used for auto-increment
address expression;
2) different address costs are used for pre/post increment address
expressions.
This patch fixes the problem by computing, caching and using the cost of
auto-increment address expressions.

Bootstrap and test on x86/arm.  Is it OK?

2013-11-01  Bin Cheng  

* tree-ssa-loop-ivopts.c (enum ainc_type): New.
(address_cost_data): New field.
(get_address_cost): Compute auto-increment rtx cost in ainc_costs.
Use ainc_costs for auto-increment rtx patterns.
Cleanup TWS.
Index: gcc/tree-ssa-loop-ivopts.c
===
--- gcc/tree-ssa-loop-ivopts.c  (revision 204117)
+++ gcc/tree-ssa-loop-ivopts.c  (working copy)
@@ -3185,10 +3185,21 @@ multiplier_allowed_in_address_p (HOST_WIDE_INT rat
 
TODO -- there must be some better way.  This all is quite crude.  */
 
+enum ainc_type
+{
+  AINC_PRE_INC,/* Pre increment.  */
+  AINC_PRE_DEC,/* Pre decrement.  */
+  AINC_POST_INC,   /* Post increment.  */
+  AINC_POST_DEC,   /* Post decrement.  */
+  AINC_NUM,/* Number of auto increment types.  */
+  AINC_NONE
+};
+
 typedef struct address_cost_data_s
 {
   HOST_WIDE_INT min_offset, max_offset;
   unsigned costs[2][2][2][2];
+  unsigned ainc_costs[AINC_NUM];
 } *address_cost_data;
 
 
@@ -3206,6 +3217,7 @@ get_address_cost (bool symbol_present, bool var_pr
   static bool has_preinc[MAX_MACHINE_MODE], has_postinc[MAX_MACHINE_MODE];
   static bool has_predec[MAX_MACHINE_MODE], has_postdec[MAX_MACHINE_MODE];
   unsigned cost, acost, complexity;
+  enum ainc_type autoinc_type;
   bool offset_p, ratio_p, autoinc;
   HOST_WIDE_INT s_offset, autoinc_offset, msize;
   unsigned HOST_WIDE_INT mask;
@@ -3277,33 +3289,49 @@ get_address_cost (bool symbol_present, bool var_pr
   reg0 = gen_raw_REG (address_mode, LAST_VIRTUAL_REGISTER + 1);
   reg1 = gen_raw_REG (address_mode, LAST_VIRTUAL_REGISTER + 2);
 
-  if (USE_LOAD_PRE_DECREMENT (mem_mode) 
+  if (USE_LOAD_PRE_DECREMENT (mem_mode)
  || USE_STORE_PRE_DECREMENT (mem_mode))
{
  addr = gen_rtx_PRE_DEC (address_mode, reg0);
  has_predec[mem_mode]
= memory_address_addr_space_p (mem_mode, addr, as);
+
+ if (has_predec[mem_mode])
+   data->ainc_costs[AINC_PRE_DEC]
+ = address_cost (addr, mem_mode, as, speed);
}
-  if (USE_LOAD_POST_DECREMENT (mem_mode) 
+  if (USE_LOAD_POST_DECREMENT (mem_mode)
  || USE_STORE_POST_DECREMENT (mem_mode))
{
  addr = gen_rtx_POST_DEC (address_mode, reg0);
  has_postdec[mem_mode]
= memory_address_addr_space_p (mem_mode, addr, as);
+
+ if (has_postdec[mem_mode])
+   data->ainc_costs[AINC_POST_DEC]
+ = address_cost (addr, mem_mode, as, speed);
}
-  if (USE_LOAD_PRE_INCREMENT (mem_mode) 
+  if (USE_LOAD_PRE_INCREMENT (mem_mode)
  || USE_STORE_PRE_DECREMENT (mem_mode))
{
  addr = gen_rtx_PRE_INC (address_mode, reg0);
  has_preinc[mem_mode]
= memory_address_addr_space_p (mem_mode, addr, as);
+
+ if (has_preinc[mem_mode])
+   data->ainc_costs[AINC_PRE_INC]
+ = address_cost (addr, mem_mode, as, speed);
}
-  if (USE_LOAD_POST_INCREMENT (mem_mode) 
+  if (USE_LOAD_POST_INCREMENT (mem_mode)
  || USE_STORE_POST_INCREMENT (mem_mode))
{
  addr = gen_rtx_POST_INC (address_mode, reg0);
  has_postinc[mem_mode]
= memory_address_addr_space_p (mem_mode, addr, as);
+
+ if (has_postinc[mem_mode])
+   data->ainc_costs[AINC_POST_INC]
+ = address_cost (addr, mem_mode, as, speed);
}
   for (i = 0; i < 16; i++)
{
@@ -3429,22 +3457,32 @@ get_address_cost (bool symbol_present, bool var_pr
   s_offset = offset;
 
   autoinc = false;
+  autoinc_type = AINC_NONE;
   msize = GET_MODE_SIZE (mem_mode);
   autoinc_offset = offset;
   if (stmt_after_inc)
 autoinc_offset += ratio * cstep;
   if (symbol_present || var_present || ratio != 1)
 autoinc = false;
-  else if ((has_postinc[mem_mode] && autoinc_offset == 0
+  else
+{
+  if (has_postinc[mem_mode] && autoinc_offset == 0
+ && msize == cstep)
+   autoinc_type = AINC_POST_INC;
+  else if (has_postdec[mem_mode] && autoinc_offset == 0
+  && msize == -cstep)
+   autoinc_type = AINC_

Re: [Patch, ObjC, ObjC++, Darwin] Remove "-fobjc-sjlj-exceptions"

[Mike Stump]

On Nov 3, 2013, at 12:58 PM, Iain Sandoe  wrote:
> The Objective C/C++ exceptions model is, currently, completely determined by 
> the combination of runtime {gnu, next} and ABI {m32/V1, m64/V2}.

> OK for trunk?

Ok.

[PATCH, rs6000] (0/3) Patch set to fix multiply even/odd problem and associated fallout for little endian

[Bill Schmidt]

Hi,

This set of patches addresses the problem with vector multiply even/odd
instructions in little endian mode that I incorrectly attempted to
address as part of expand_mult_highpart.  (Thanks to Richard Sandiford
for setting me on the right path.)

The first patch fixes the root problem wherein the "even" multiply
instructions actually process odd elements in little endian mode, and
vice versa.  However, fixing this problem exposed several other issues,
necessitating the other two patches.

The second patch addresses the vector widening multiply high/low
operations by swapping the input operands of the merge high and merge
low instructions.  Those operands are multiply-even and multiply-odd
instructions, which now have reversed meanings, so swapping the operands
gets us back to correct behavior.

The third patch addresses two other multiplication expansions:  mulv4si3
and mulv8hi3.  The first needs an exception to the rule of swapping the
even and odd multiply instructions, and the second again needs to swap
inputs to the merge high and merge low instructions.

The net effect of these three patches is to fix one failing test case,
without any regressions for either endianness.

Thanks,
Bill

[PATCH, rs6000] (1/3) Reverse meanings of multiply even/odd for little endian

[Bill Schmidt]

Hi,

This patch reverses the meanings of multiply even/odd instructions for
little endian.  Since these instructions use a big-endian idea of
evenness/oddness, the nominal meanings of the instructions is wrong for
little endian.

Bootstrapped and tested with the rest of the patch set on
powerpc64{,le}-unknown-linux-gnu with no regressions.  Ok for trunk?

Thanks,
Bill


2013-11-03  Bill Schmidt  

* config/rs6000/altivec.md (vec_widen_umult_even_v16qi): Swap
meanings of even and odd multiplies for little endian.
(vec_widen_smult_even_v16qi): Likewise.
(vec_widen_umult_even_v8hi): Likewise.
(vec_widen_smult_even_v8hi): Likewise.
(vec_widen_umult_odd_v16qi): Likewise.
(vec_widen_smult_odd_v16qi): Likewise.
(vec_widen_umult_odd_v8hi): Likewise.
(vec_widen_smult_odd_v8hi): Likewise.


 Index: gcc/config/rs6000/altivec.md
===
--- gcc/config/rs6000/altivec.md(revision 204192)
+++ gcc/config/rs6000/altivec.md(working copy)
@@ -978,7 +988,12 @@
   (match_operand:V16QI 2 "register_operand" "v")]
 UNSPEC_VMULEUB))]
   "TARGET_ALTIVEC"
-  "vmuleub %0,%1,%2"
+{
+  if (BYTES_BIG_ENDIAN)
+return "vmuleub %0,%1,%2";
+  else
+return "vmuloub %0,%1,%2";
+}
   [(set_attr "type" "veccomplex")])
 
 (define_insn "vec_widen_smult_even_v16qi"
@@ -987,7 +1002,12 @@
   (match_operand:V16QI 2 "register_operand" "v")]
 UNSPEC_VMULESB))]
   "TARGET_ALTIVEC"
-  "vmulesb %0,%1,%2"
+{
+  if (BYTES_BIG_ENDIAN)
+return "vmulesb %0,%1,%2";
+  else
+return "vmulosb %0,%1,%2";
+}
   [(set_attr "type" "veccomplex")])
 
 (define_insn "vec_widen_umult_even_v8hi"
@@ -996,7 +1016,12 @@
   (match_operand:V8HI 2 "register_operand" "v")]
 UNSPEC_VMULEUH))]
   "TARGET_ALTIVEC"
-  "vmuleuh %0,%1,%2"
+{
+  if (BYTES_BIG_ENDIAN)
+return "vmuleuh %0,%1,%2";
+  else
+return "vmulouh %0,%1,%2";
+}
   [(set_attr "type" "veccomplex")])
 
 (define_insn "vec_widen_smult_even_v8hi"
@@ -1005,7 +1030,12 @@
   (match_operand:V8HI 2 "register_operand" "v")]
 UNSPEC_VMULESH))]
   "TARGET_ALTIVEC"
-  "vmulesh %0,%1,%2"
+{
+  if (BYTES_BIG_ENDIAN)
+return "vmulesh %0,%1,%2";
+  else
+return "vmulosh %0,%1,%2";
+}
   [(set_attr "type" "veccomplex")])
 
 (define_insn "vec_widen_umult_odd_v16qi"
@@ -1014,7 +1044,12 @@
   (match_operand:V16QI 2 "register_operand" "v")]
 UNSPEC_VMULOUB))]
   "TARGET_ALTIVEC"
-  "vmuloub %0,%1,%2"
+{
+  if (BYTES_BIG_ENDIAN)
+return "vmuloub %0,%1,%2";
+  else
+return "vmuleub %0,%1,%2";
+}
   [(set_attr "type" "veccomplex")])
 
 (define_insn "vec_widen_smult_odd_v16qi"
@@ -1023,7 +1058,12 @@
   (match_operand:V16QI 2 "register_operand" "v")]
 UNSPEC_VMULOSB))]
   "TARGET_ALTIVEC"
-  "vmulosb %0,%1,%2"
+{
+  if (BYTES_BIG_ENDIAN)
+return "vmulosb %0,%1,%2";
+  else
+return "vmulesb %0,%1,%2";
+}
   [(set_attr "type" "veccomplex")])
 
 (define_insn "vec_widen_umult_odd_v8hi"
@@ -1032,7 +1072,12 @@
   (match_operand:V8HI 2 "register_operand" "v")]
 UNSPEC_VMULOUH))]
   "TARGET_ALTIVEC"
-  "vmulouh %0,%1,%2"
+{
+  if (BYTES_BIG_ENDIAN)
+return "vmulouh %0,%1,%2";
+  else
+return "vmuleuh %0,%1,%2";
+}
   [(set_attr "type" "veccomplex")])
 
 (define_insn "vec_widen_smult_odd_v8hi"
@@ -1041,7 +1086,12 @@
   (match_operand:V8HI 2 "register_operand" "v")]
 UNSPEC_VMULOSH))]
   "TARGET_ALTIVEC"
-  "vmulosh %0,%1,%2"
+{
+  if (BYTES_BIG_ENDIAN)
+return "vmulosh %0,%1,%2";
+  else
+return "vmulesh %0,%1,%2";
+}
   [(set_attr "type" "veccomplex")])
 
 

[PATCH, rs6000] (2/3) Fix widening multiply high/low operations for little endian

[Bill Schmidt]

Hi,

This patch fixes the widening multiply high/low operations to work
correctly in the presence of the first patch of this series, which
reverses the meanings of multiply even/odd instructions.  Here we
reorder the input operands to the vector merge low/high instructions.

The general rule is that vmrghh(x,y) [BE] = vmrglh(y,x) [LE], and so on;
that is, we need to reverse the usage of merge high and merge low, and
also swap their inputs, to obtain the same semantics.  In this case we
are only swapping the inputs, because the reversed usage of high and low
has already been done for us in the generic handling code for
VEC_WIDEN_MULT_LO_EXPR.

Bootstrapped and tested with the rest of the patch set on
powerpc64{,le}-unknown-linux-gnu, with no regressions.  Is this ok for
trunk?

Thanks,
Bill


2013-11-03  Bill Schmidt  

* config/rs6000/altivec.md (vec_widen_umult_hi_v16qi): Swap
arguments to merge instruction for little endian.
(vec_widen_umult_lo_v16qi): Likewise.
(vec_widen_smult_hi_v16qi): Likewise.
(vec_widen_smult_lo_v16qi): Likewise.
(vec_widen_umult_hi_v8hi): Likewise.
(vec_widen_umult_lo_v8hi): Likewise.
(vec_widen_smult_hi_v8hi): Likewise.
(vec_widen_smult_lo_v8hi): Likewise.


Index: gcc/config/rs6000/altivec.md
===
--- gcc/config/rs6000/altivec.md(revision 204192)
+++ gcc/config/rs6000/altivec.md(working copy)
@@ -2185,7 +2235,10 @@
   
   emit_insn (gen_vec_widen_umult_even_v16qi (ve, operands[1], operands[2]));
   emit_insn (gen_vec_widen_umult_odd_v16qi (vo, operands[1], operands[2]));
-  emit_insn (gen_altivec_vmrghh (operands[0], ve, vo));
+  if (BYTES_BIG_ENDIAN)
+emit_insn (gen_altivec_vmrghh (operands[0], ve, vo));
+  else
+emit_insn (gen_altivec_vmrghh (operands[0], vo, ve));
   DONE;
 }")
 
@@ -2202,7 +2255,10 @@
   
   emit_insn (gen_vec_widen_umult_even_v16qi (ve, operands[1], operands[2]));
   emit_insn (gen_vec_widen_umult_odd_v16qi (vo, operands[1], operands[2]));
-  emit_insn (gen_altivec_vmrglh (operands[0], ve, vo));
+  if (BYTES_BIG_ENDIAN)
+emit_insn (gen_altivec_vmrglh (operands[0], ve, vo));
+  else
+emit_insn (gen_altivec_vmrglh (operands[0], vo, ve));
   DONE;
 }")
 
@@ -2219,7 +2275,10 @@
   
   emit_insn (gen_vec_widen_smult_even_v16qi (ve, operands[1], operands[2]));
   emit_insn (gen_vec_widen_smult_odd_v16qi (vo, operands[1], operands[2]));
-  emit_insn (gen_altivec_vmrghh (operands[0], ve, vo));
+  if (BYTES_BIG_ENDIAN)
+emit_insn (gen_altivec_vmrghh (operands[0], ve, vo));
+  else
+emit_insn (gen_altivec_vmrghh (operands[0], vo, ve));
   DONE;
 }")
 
@@ -2236,7 +2295,10 @@
   
   emit_insn (gen_vec_widen_smult_even_v16qi (ve, operands[1], operands[2]));
   emit_insn (gen_vec_widen_smult_odd_v16qi (vo, operands[1], operands[2]));
-  emit_insn (gen_altivec_vmrglh (operands[0], ve, vo));
+  if (BYTES_BIG_ENDIAN)
+emit_insn (gen_altivec_vmrglh (operands[0], ve, vo));
+  else
+emit_insn (gen_altivec_vmrglh (operands[0], vo, ve));
   DONE;
 }")
 
@@ -2253,7 +2315,10 @@
   
   emit_insn (gen_vec_widen_umult_even_v8hi (ve, operands[1], operands[2]));
   emit_insn (gen_vec_widen_umult_odd_v8hi (vo, operands[1], operands[2]));
-  emit_insn (gen_altivec_vmrghw (operands[0], ve, vo));
+  if (BYTES_BIG_ENDIAN)
+emit_insn (gen_altivec_vmrghw (operands[0], ve, vo));
+  else
+emit_insn (gen_altivec_vmrghw (operands[0], vo, ve));
   DONE;
 }")
 
@@ -2270,7 +2335,10 @@
   
   emit_insn (gen_vec_widen_umult_even_v8hi (ve, operands[1], operands[2]));
   emit_insn (gen_vec_widen_umult_odd_v8hi (vo, operands[1], operands[2]));
-  emit_insn (gen_altivec_vmrglw (operands[0], ve, vo));
+  if (BYTES_BIG_ENDIAN)
+emit_insn (gen_altivec_vmrglw (operands[0], ve, vo));
+  else
+emit_insn (gen_altivec_vmrglw (operands[0], vo, ve));
   DONE;
 }")
 
@@ -2287,7 +2355,10 @@
   
   emit_insn (gen_vec_widen_smult_even_v8hi (ve, operands[1], operands[2]));
   emit_insn (gen_vec_widen_smult_odd_v8hi (vo, operands[1], operands[2]));
-  emit_insn (gen_altivec_vmrghw (operands[0], ve, vo));
+  if (BYTES_BIG_ENDIAN)
+emit_insn (gen_altivec_vmrghw (operands[0], ve, vo));
+  else
+emit_insn (gen_altivec_vmrghw (operands[0], vo, ve));
   DONE;
 }")
 
@@ -2304,7 +2375,10 @@
   
   emit_insn (gen_vec_widen_smult_even_v8hi (ve, operands[1], operands[2]));
   emit_insn (gen_vec_widen_smult_odd_v8hi (vo, operands[1], operands[2]));
-  emit_insn (gen_altivec_vmrglw (operands[0], ve, vo));
+  if (BYTES_BIG_ENDIAN)
+emit_insn (gen_altivec_vmrglw (operands[0], ve, vo));
+  else
+emit_insn (gen_altivec_vmrglw (operands[0], vo, ve));
   DONE;
 }")
 

[PATCH, rs6000] (3/3) Fix mulv4si3 and mulv8hi3 patterns for little endian

[Bill Schmidt]

Hi,

This patch contains two more fixes related to the multiply even/odd
problem.  First, it changes the mulv4si3 pattern so that it always uses
the vmulouh (vector multiply odd halfword) instruction regardless of
endianness.  The reason for this is that we are not really multiplying
halfwords, but are multiplying words that have been truncated to
halfword length; therefore they always sit in the right half of each
word, which is the odd-numbered word in big-endian numbering.

The fix for mulv8hi3 is another case where reversing the meanings of the
multiply even/odd instructions requires us to reverse the order of
inputs on the merge high/low instructions to compensate.

Bootstrapped and tested with the rest of the patch set on
powerpc64{,le}-unknown-linux-gnu with no regressions.  Ok for trunk?

Thanks,
Bill


2013-11-03  Bill Schmidt  

* config/rs6000/altivec.md (mulv4si3): Ensure we generate vmulouh
for both big and little endian.
(mulv8hi3): Swap input operands for merge high and merge low
instructions.



Index: gcc/config/rs6000/altivec.md
===
--- gcc/config/rs6000/altivec.md(revision 204192)
+++ gcc/config/rs6000/altivec.md(working copy)
@@ -651,7 +651,12 @@
convert_move (small_swap, swap, 0);
  
low_product = gen_reg_rtx (V4SImode);
-   emit_insn (gen_vec_widen_umult_odd_v8hi (low_product, one, two));
+   /* We need this to be vmulouh for both big and little endian,
+  but for little endian we would swap this, so avoid that.  */
+   if (BYTES_BIG_ENDIAN)
+ emit_insn (gen_vec_widen_umult_odd_v8hi (low_product, one, two));
+   else
+ emit_insn (gen_vec_widen_umult_even_v8hi (low_product, one, two));
  
high_product = gen_reg_rtx (V4SImode);
emit_insn (gen_altivec_vmsumuhm (high_product, one, small_swap, zero));
@@ -678,13 +683,18 @@
emit_insn (gen_vec_widen_smult_even_v8hi (even, operands[1], operands[2]));
emit_insn (gen_vec_widen_smult_odd_v8hi (odd, operands[1], operands[2]));
 
-   emit_insn (gen_altivec_vmrghw (high, even, odd));
-   emit_insn (gen_altivec_vmrglw (low, even, odd));
-
if (BYTES_BIG_ENDIAN)
- emit_insn (gen_altivec_vpkuwum (operands[0], high, low));
+ {
+   emit_insn (gen_altivec_vmrghw (high, even, odd));
+   emit_insn (gen_altivec_vmrglw (low, even, odd));
+   emit_insn (gen_altivec_vpkuwum (operands[0], high, low));
+ }
else
- emit_insn (gen_altivec_vpkuwum (operands[0], low, high));
+ {
+   emit_insn (gen_altivec_vmrghw (high, odd, even));
+   emit_insn (gen_altivec_vmrglw (low, odd, even));
+   emit_insn (gen_altivec_vpkuwum (operands[0], low, high));
+ } 
 
DONE;
 }")

Patch RFA: With -fnon-call-exceptions sync builtins may throw

[Ian Lance Taylor]

The middle-end currently marks all the sync builtins as nothrow.  That
is incorrect for most of them when using -fnon-call-exceptions.  The
-fnon-call-exceptions option means that instructions that trap may throw
exceptions.  Most of the sync builtins access memory via pointers passed
by user code.  Therefore, they may trap.  (I noticed this because Go
uses -fnon-call-exceptions.)

This patch fixes the problem by introducing a new internal function
attribute "nothrow call".  The new attribute is exactly like "nothrow",
except that it is ignored when using -fnon-call-exceptions.

It is an internal attribute because there is no reason for a user to use
this.  The problem only arises when the middle-end sees a function call
that the backend turns into an instruction sequence that directly
references memory.  That can only happen for functions that are built in
to the compiler.

This requires changes to the C family, LTO, and Ada frontends.  I think
I'm handling the option correctly for LTO, but it would be good if
somebody could check the logic for me.

Bootstrapped and ran tests on x86_64-unknown-linux-gnu.  OK for
mainline?

Ian


gcc/ChangeLog:

2013-11-03  Ian Lance Taylor  

* builtin-attrs.def (ATTR_NOTHROWCALL): Define.
(ATTR_NOTHROWCALL_LIST, ATTR_NOTHROWCALL_LEAF_LIST): Define.
* sync-builtins.def: Use ATTR_NOTHROWCALL_LEAF_LIST for all sync
builtins that take pointers.
* lto-opts.c (lto_write_options): Write -fnon-call-exceptions
if set.
* lto-wrapper.c (merge_and_complain): Collect
OPT_fnon_call_exceptions.
(run_gcc): Pass -fnon-call-exceptions.

gcc/c-family/ChangeLog:

2013-11-03  Ian Lance Taylor  

* c-common.c (c_common_attribute_table): Add "nothrow call".
(handle_nothrowcall_attribute): New static function.

gcc/lto/ChangeLog:

2013-11-03  Ian Lance Taylor  

* lto-lang.c (lto_attribute_table): Add "nothrow call"
(handle_nothrowcall_attribute): New static function.

gcc/ada/ChangeLog:

2013-11-03  Ian Lance Taylor  

* gcc-interface/utils.c (gnat_internal_attribute_table): Add
"nothrow call".
(handle_nothrowcall_attribute): New static function.

gcc/testsuite/ChangeLog:

2013-11-03  Ian Lance Taylor  

* g++.dg/ext/sync-4.C: New test.


Index: lto-wrapper.c
===
--- lto-wrapper.c	(revision 204343)
+++ lto-wrapper.c	(working copy)
@@ -409,6 +409,7 @@ merge_and_complain (struct cl_decoded_op
 	case OPT_fpie:
 	case OPT_fcommon:
 	case OPT_fexceptions:
+	case OPT_fnon_call_exceptions:
 	case OPT_fgnu_tm:
 	  /* Do what the old LTO code did - collect exactly one option
 	 setting per OPT code, we pick the first we encounter.
@@ -573,6 +574,7 @@ run_gcc (unsigned argc, char *argv[])
 	case OPT_fpie:
 	case OPT_fcommon:
 	case OPT_fexceptions:
+	case OPT_fnon_call_exceptions:
 	case OPT_fgnu_tm:
 	case OPT_freg_struct_return:
 	case OPT_fpcc_struct_return:
Index: c-family/c-common.c
===
--- c-family/c-common.c	(revision 204343)
+++ c-family/c-common.c	(working copy)
@@ -358,6 +358,7 @@ static tree handle_vector_size_attribute
 	  bool *);
 static tree handle_nonnull_attribute (tree *, tree, tree, int, bool *);
 static tree handle_nothrow_attribute (tree *, tree, tree, int, bool *);
+static tree handle_nothrowcall_attribute (tree *, tree, tree, int, bool *);
 static tree handle_cleanup_attribute (tree *, tree, tree, int, bool *);
 static tree handle_warn_unused_result_attribute (tree *, tree, tree, int,
 		 bool *);
@@ -708,6 +709,10 @@ const struct attribute_spec c_common_att
 			  handle_nonnull_attribute, false },
   { "nothrow",0, 0, true,  false, false,
 			  handle_nothrow_attribute, false },
+  /* For internal use only.  The name contains a space to prevent its
+ use in source code.  */
+  { "nothrow call",   0, 0, true, false, false,
+			  handle_nothrowcall_attribute, false },
   { "may_alias",	  0, 0, false, true, false, NULL, false },
   { "cleanup",		  1, 1, true, false, false,
 			  handle_cleanup_attribute, false },
@@ -8788,6 +8793,29 @@ handle_nothrow_attribute (tree *node, tr
   return NULL_TREE;
 }
 
+/* Handle a "nothrow call" attribute: arguments as in struct
+   attribute_spec.handler.  This attribute means that the function is
+   to be treated as not throwing, unless -fnon-call-exceptions is
+   being used.
+
+   This attribute is only used for builtin functions defined by the
+   compiler.  If a builtin function indirects through an unknown
+   pointer, and the builtin function is replaced by inline code, we
+   need to know that that inline code might trap.  This attribute can
+   not be specified by user code, because user code can not write a
+   function that is replaced by inline code by the backend.  */
+
+static tree
+handle_nothrowcall_attribute 

Re: [RFC] libgcov.c re-factoring and offline profile-tool

[Xinliang David Li]

Thanks! Can you attach the patch file for the proposed change?

David

On Fri, Nov 1, 2013 at 2:08 PM, Rong Xu  wrote:
> libgcov.c is the main file to generate libgcov.a. This single source generates
> 21 object files and then archives to a library. These objects are of
> very different purposes but they are in the same file guarded by various 
> macros.
> The source file becomes quite large and its readability becomes very
> low. In its current state:
> 1) The code is very hard to understand by new developers;
> 2) It makes regressions more likely when making simple changes;
> More importantly,
> 3) it makes code reuse/sharing very difficult. For instance, Using
> libgcov to implement an offline profile tool (see below); kernel FDO
> support etc.
>
> We came to this issue when working on an offline tool to handle
> profile counters.
> Our plan is to have a profile-tool can merge, diff, collect statistics, and
> better dump raw profile counters. This is one of the most requested features
> from out internal users. This tool can also be very useful for any 
> FDO/coverage
> users. In the first part of tool, we want to have the weight
> merge. Again, to reuse the code, we have to change libgcov.c. But we don't 
> want
> to further diverge libgcov.a in our google branches from the trunk.
>
> Another issue in libgcov.c is function gcov_exit(). It is a huge function
> with about 467 lines of code. This function traverses gcov_list and dumps all
> the gcda files. The code for merging the gcda files also sits in the same
>  function. The structure makes the code-reuse and extension really difficult
> (like in kernel FDO, we have to break this function to reuse some of the 
> code).
>
> We propose to break gcov_exit into smaller functions and split libgcov.c into
> several files. Our plan for profile-tool is listed in (3).
>
> 1. break gcov_exit() into the following structure:
>gcov_exit()
>   --> gcov_exit_compute_summary()
>   --> allocate_filename_struct()
>   for gi_ptr in gcov_list
> --> gcov_exit_dump_gcov()
>--> gcov_exit_open_gcda_file()
>--> gcov_exit_merge_gcda ()
>--> gcov_exit_write_gcda ()
>
> 2. split libgcov.c into the following files:
>  libgcov-profiler.c
>  libgcov-merge.c
>  libgcov-interface.c
>  libgcov-driver.c
>libgcov-driver-system.c (source included into libgcov-driver.c)
>
> The details of the splitting:
> libgcov-interface.c
> /* This file contains API functions to other programs and the supporting
>functions.  */
>   __gcov_dump()
>   __gcov_execl()
>   __gcov_execle()
>   __gcov_execlp()
>   __gcov_execv()
>   __gcov_execve()
>   __gcov_execvp()
>   __gcov_flush()
>   __gcov_fork()
>   __gcov_reset()
>   init_mx()
>   init_mx_once()
>
> libgcov-profiler.c
> /* This file contains runtime profile handlers.  */
>   variables:
> __gcov_indirect_call_callee
> __gcov_indirect_call_counters
>   functions:
> __gcov_average_profiler()
> __gcov_indirect_call_profiler()
> __gcov_indirect_call_profiler_v2()
> __gcov_interval_profiler()
> __gcov_ior_profiler()
> __gcov_one_value_profiler()
> __gcov_one_value_profiler_body()
> __gcov_pow2_profiler()
>
> libgcov-merge.c
> /* This file contains the merge functions for various counters.  */
>   functions:
> __gcov_merge_add()
> __gcov_merge_delta()
> __gcov_merge_ior()
> __gcov_merge_single()
>
> libcov-driver.c
> /* This file contains the gcov dumping functions. We separate the
>system dependent part to libgcov-driver-system.c.  */
>   variables:
> gcov_list
> gcov_max_filename
> gcov_dump_complete
> -- newly added file static variables --
> this_prg
> all_prg
> crc32
> gi_filename
> fn_buffer
> fn_tail
> sum_buffer
> next_sum_buffer
> sum_tail
> - end -
>   functions:
> free_fn_data()
> buffer_fn_data()
> crc32_unsigned()
> gcov_version()
> gcov_histogram_insert()
> gcov_compute_histogram()
> gcov_clear()
> __gcov_init()
> gcov_exit()
> --- newly added static functions --
> gcov_exit_compute_summary ()
> gcov_exit_merge_gcda()
> gcov_exit_write_gcda()
> gcov_exit_dump_gcov()
> - end -
>
> libgcov-driver-system.c
> /* system dependent part of ligcov-driver.c.  */
>   functions:
> create_file_directory()
> --- newly added static functions --
> gcov_error() /* This replaces all fprintf(stderr, ...) */
> allocate_filename_struct()
> gcov_exit_open_gcda_file()
>
> 3. add offline profile-tool support.
>We will change the interface of merge functions to make it
>take in-memory gcov_info list, and a weight as the arguments.
>
>We will add libgcov-tool.c. It has two APIs:
>(1) read_profile_dir(): read a profile directory and reconstruct the
>gcov_info link list in-memory.
>(2) merge_profiles():