Re: [PATCH] Fix PR56344

[Richard Biener]

On Wed, Feb 27, 2013 at 6:38 PM, Joseph S. Myers
 wrote:
> On Wed, 27 Feb 2013, Richard Biener wrote:
>
>> Wouldn't it be better to simply pass this using the variable size handling
>> code?  Thus, initialize args_size.var for too large constant size instead?
>
> Would that be compatible with the ABI definition of how a large (constant
> size) argument should be passed?

I'm not sure.  Another alternative is to expand to __builtin_trap (), but that's
probably not easy at this very point.

Or simply fix the size calculation to not overflow (either don't count bits
or use a double-int).

Richard.

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

Re: [PATCH] C++ math constants

[Florian Weimer]

On 03/01/2013 05:15 AM, Ulrich Drepper wrote:

On Thu, Feb 21, 2013 at 12:38 PM, Benjamin De Kosnik  wrote:

Not seeing it.

Say for:

#include 

   // A class for math constants.
   template
 struct __math_constants
 {
   // Constant @f$ \pi @f$.
   static constexpr _RealType __pie =
   3.1415926535897932384626433832795029L; };

template
void print(const T& t) { std::cout << t; }

int main()
{
   print(__math_constants::__pie);
   return 0;
}

I'm not getting any definition, even at -O0.


Even more so: how would an explicit instantiation even work?


You don't need an explicit instantiation, just a regular templated 
definition.  This example shows that a definition is needed, and how one 
is provided.


template 
struct a {
  static constexpr T m = T(1);
};

template 
constexpr T a::m;

const int *
f()
{
  return &a::m;
}

int
main()
{
  return f() == 0;
}

--
Florian Weimer / Red Hat Product Security Team

Re: [PATCH, ARM, RFC] Fix vect.exp failures for NEON in big-endian mode

[Richard Biener]

On Wed, Feb 27, 2013 at 6:29 PM, Julian Brown  wrote:
> Hi,
>
> Several new (ish?) autovectorizer features have apparently caused NEON
> support for same to regress quite heavily in big-endian mode. This
> patch is an attempt to fix things up, but is not without problems --
> maybe someone will have a suggestion as to how we should proceed.
>
> The problem (as ever) is that the ARM backend must lie to the
> middle-end about the layout of NEON vectors in big-endian mode (due to
> ABI requirements, VFP compatibility, and the middle-end semantics of
> vector indices being equivalent to those of an array with the same type
> of elements when stored in memory).

Why not simply give up?  Thus, make autovectorization unsupported for
ARM big-endian targets?

Do I understand correctly that the "only" issue is memory vs. register
element ordering?  Thus a fixup could be as simple as extra shuffles
inserted after vector memory loads and before vector memory stores?
(with the hope of RTL optimizers optimizing those)?

Any "lies" are of course bad and you'll pay for them later.

Richard.

> A few years ago when the vectorizer
> was relatively less sophisticated, the ordering of vector elements
> could be ignored to some extent by disabling certain instruction
> patterns used by the vectorizer in big-endian mode which were sensitive
> to the ordering of elements: in fact this is still the strategy we're
> using, but it is clearly becoming less and less tenable as time
> progresses. Quad-word registers (being composed of two double-word
> registers, loaded/stored the "wrong way round" in big-endian mode)
> arguably cause more problems than double-word registers.
>
> So, the idea behind the attached patch was supposed to be to limit the
> autovectorizer to using double-word registers only, and to disable a
> few additional (or newly-used by the vectorizer) patterns in big-endian
> mode. That, plus several testsuite tweaks, gets us down to zero
> failures for vect.exp, which is good.
>
> The problem is that at the same time quite a large set of neon.exp tests
> regress (vzip/vuzp/vtrn): one of the new patterns which is
> disabled because it causes trouble (i.e. execution failures) for the
> vectorizer is vec_perm_const. However __builtin_shuffle (which
> uses that pattern) is used for arm_neon.h now -- so disabling it means
> that the proper instructions aren't generated for intrinsics any more in
> big-endian mode.
>
> I think we have a problem here. The vectorizer also tries to use
> __builtin_shuffle (for scatter/gather operations, when lane
> loading/storing ops aren't available), but does not understand the
> "special tweaks" that arm_evpc_neon_{vuzp,vzip,vtrn} does to try to
> hide the true element ordering of vectors from the middle-end. So, I'm
> left wondering:
>
>  * Given our funky element ordering in BE mode, are the
>__builtin_shuffle lists in arm_neon.h actually an accurate
>representation of what the given intrinsic should do? (The fallback
>code might or might not do the same thing, I'm not sure.)
>
>  * The vectorizer tries to use VEC_PERM_EXPR (equivalent to
>__builtin_shuffle) with e.g. pairs of doubleword registers loaded
>from adjacent memory locations. Are the semantics required for this
>(again, with our funky element ordering) even the same as those
>required for the intrinsics? Including quad-word registers for the
>latter? (My suspicion is "no", in which case there's a fundamental
>incompatibility here that needs to be resolved somehow.)
>
> Anyway: the tl;dr is "fixing NEON vect tests breaks intrinsics". Any
> ideas for what to do about that? (FAOD, I don't think I'm in a position
> to do the kind of middle-end surgery required to fix the problem
> "properly" at this point :-p).
>
> (It's arguably more important for the vectorizer to not generate bad
> code than it is for intrinsics to work properly, in which case: OK to
> apply? Tested cross to ARM EABI with configury modifications to build
> LE/BE multilibs.)
>
> Thanks,
>
> Julian
>
> ChangeLog
>
> gcc/
> * config/arm/arm.c (arm_array_mode_supported_p): No array modes for
> big-endian NEON.
> (arm_preferred_simd_mode): Always prefer 64-bit modes for
> big-endian NEON.
> (arm_autovectorize_vector_sizes): Use 8-byte vectors only for NEON.
> (arm_vectorize_vec_perm_const_ok): No permutations are OK in
> big-endian mode.
> * config/arm/neon.md (vec_load_lanes): Disable in
> big-endian mode.
> (vec_store_lanes, vec_load_lanesti)
> (vec_load_lanesoi, vec_store_lanesti)
> (vec_store_lanesoi, vec_load_lanesei)
> (vec_load_lanesci, vec_store_lanesei)
> (vec_store_lanesci, vec_load_lanesxi)
> (vec_store_lanesxi): Likewise.
> (vec_widen_shiftl_lo_, vec_widen_shiftl_hi_)
> (vec_widen_mult_hi_, vec_widen_mult_lo_):
> Likewise.
>
> gcc/testsuite/
> * gcc.dg/vect/slp-cond-3.c: XFAIL for !vect_unpack.
> * gcc.dg/vect/slp-cond-4.c: Likewi

*ping* - Re: Fix some texinfo 5.0 warnings in gcc/doc + libiberty

[Tobias Burnus]

* PING * – The patch is rather simple and on the verge to be obvious.
http://gcc.gnu.org/ml/gcc-patches/2013-02/msg01106.html


Tobias

Tobias Burnus wrote:
(The attachment contains my original patch (simple rediff) and 
Andreas' follow-up patch for libiberty.)


Tobias

Tobias Burnus wrote:

This is a follow up to Jakub's patch.

With texinfo 5.0 one gets a bunch of warnings. This patch reduces the 
number of warnings – but there are still warnings to be fixed.


This patch solves most of the issues related to mismatches between 
the item order in the @menu and the actual @nodes. As always, there 
is the question whether the @node or the item in @menu should be 
changed. In one case, I had the choice to either add a new item under 
@menu or to change a @section into @subsection. I did the latter.


Tested with "make info" and no new warnings in texinfo 5.0. 
Additionally, I used texinfo 4.13a with showed no warnings.

OK for the trunk?

Tobias


PS: I tried the following libiberty patch; it fixes a warning with 
texinfo 5.0. But I do not include it as it fails for some reason with 
an error with texinfo 4.13:
../../libiberty/libiberty.texi:250: Prev field of node `Functions' 
not pointed to.

../../libiberty//obstacks.texi:1: This node (Obstacks) has the bad Next.

Re: [PATCH] Fix PR56478

[Richard Biener]

On Thu, Feb 28, 2013 at 7:43 PM, Jakub Jelinek  wrote:
> On Thu, Feb 28, 2013 at 07:27:48PM +0100, Marek Polacek wrote:
>> The hunk
>> probability = (double) REG_BR_PROB_BASE * compare_count / loop_count;
>> in there should be probably handled in the same way.  But I'll handle
>> that separately.
>>
>> In the first hunk, I did s/int/HOST_WIDE_INT/, because HWI is what
>> tree_low_cst returns.  For why that could be a problem, see the
>> Jakub's comment in the PR.
>
> That doesn't help, because it is assigned into
> int *loop_step;
> *loop_step = step;
>
> IMHO the argument should be tree *loop_step, then you don't need to
> convert it back from int to tree.
>
>> --- gcc/predict.c.mp  2013-02-28 17:26:47.950247877 +0100
>> +++ gcc/predict.c 2013-02-28 17:26:56.855275792 +0100
>
>> +  /* We want to do the arithmetics on trees (and punt in
>> + case of an overflow).  */
>> +  step_var = build_int_cst (NULL_TREE, compare_step);

Don't use NULL_TREE built_int_cst - doing so hints at that you want to
use double_ints.  Generally doing computation with trees is expensive.
You want to avoid that at all cost.  Use double-ints (yeah, you have to
use the clunky divmod_with_overflow interface).

Richard.

>> +  gcc_assert (TREE_CODE (step_var) == INTEGER_CST);
>
> See above, this would be unnecessary.
>> +
>> +  /* Compute (loop_bound - base) / compare_step.  */
>> +  loop_count_var
>> += int_const_binop (TRUNC_DIV_EXPR,
>> +int_const_binop (MINUS_EXPR,
>> + loop_bound_var,
>> + compare_base),
>> +step_var);
>> +
>> +  if (TREE_OVERFLOW_P (loop_count_var))
>> +   return;
>> +
>> +  HOST_WIDE_INT loop_count = tree_low_cst (loop_count_var, 0);
>
> I thought you'd do the rest of the computations on trees too,
> there are the risks of overflows or undefined behavior.
>
> So if ((tree_int_cst_sgn (compare_step) == 1)
> etc., integer_zerop (loop_count), and the only conversion from tree
> to HWI would be after you convert the floating point tree to integer
> when you assign it to probability.
>
> Jakub

[Patch, Fortran, committed] Fix two memory leaks

[Tobias Burnus]

I committed (Rev. 196372) after regtesting on x86-64-gnu-linux the 
attached patch.


There are still plenty of leaks in the FE, including surprising ones: 
The program "end" leaks memory while some more complicated programs 
don't. (Tested with valgrind --leak-check=full and compiling with 
-fsyntax-only.)


Tobias
Index: gcc/fortran/ChangeLog
===
--- gcc/fortran/ChangeLog	(Revision 196370)
+++ gcc/fortran/ChangeLog	(Arbeitskopie)
@@ -1,3 +1,8 @@
+2013-03-01  Tobias Burnus  
+
+	* trans-decl.c (gfc_trans_deferred_vars): Free expr after use.
+	* trans-io.c (build_dt): Ditto.
+
 2013-02-24  Joseph Myers  
 
 	* resolve.c (generate_component_assignments): Don't use UTF-8
Index: gcc/fortran/trans-decl.c
===
--- gcc/fortran/trans-decl.c	(Revision 196370)
+++ gcc/fortran/trans-decl.c	(Arbeitskopie)
@@ -3818,10 +3818,12 @@ gfc_trans_deferred_vars (gfc_symbol * proc_sym, gf
 		  NULL_TREE, true, NULL,
 		  true);
 		  else
-		tmp = gfc_deallocate_scalar_with_status (se.expr, NULL_TREE,
-		   true,
-		   gfc_lval_expr_from_sym (sym),
-		   sym->ts);
+		{
+		  gfc_expr *expr = gfc_lval_expr_from_sym (sym);
+		  tmp = gfc_deallocate_scalar_with_status (se.expr, NULL_TREE,
+		   true, expr, sym->ts);
+		  gfc_free_expr (expr);
+		}
 		}
 	  if (sym->ts.type == BT_CLASS)
 		{
Index: gcc/fortran/trans-io.c
===
--- gcc/fortran/trans-io.c	(Revision 196370)
+++ gcc/fortran/trans-io.c	(Arbeitskopie)
@@ -1782,6 +1782,8 @@ build_dt (tree function, gfc_code * code)
 	  mask |= set_string (&block, &post_block, var, IOPARM_dt_namelist_name,
 			  nmlname);
 
+	  gfc_free_expr (nmlname);
+
 	  if (last_dt == READ)
 	mask |= IOPARM_dt_namelist_read_mode;
 

[AArch64-4.7] Fix warning: TARGET_FIXED_CONDITION_CODE_REGS redefined.

[James Greenhalgh]

Hi,

config/aarch64/aarch64.c attempts to do this:

> #undef TARGET_FIXED_CONDITION_CODE_REG
> #define TARGET_FIXED_CONDITION_CODE_REGS aarch64_fixed_condition_code_regs

This patch adds the S to the end of TARGET_FIXED_CONDITION_CODE_REG
clearing a warning for redefining TARGET_FIXED_CONDITION_REGS

Regression tested on aarch64-none-elf with no issues and checked
to ensure that the warning is cleared.

OK for aarch64-4.7-branch?

Thanks,
James

---
gcc/

2013-03-01  James Greenhalgh  

* config/aarch64/aarch64.c:
Fix typo in `#undef TARGET_FIXED_CONDITION_CODE_REGS'diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index b554a0e..5bc6f84 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -7819,7 +7819,7 @@ aarch64_vectorize_vec_perm_const_ok (enum machine_mode vmode,
 #undef TARGET_EXPAND_BUILTIN_VA_START
 #define TARGET_EXPAND_BUILTIN_VA_START aarch64_expand_builtin_va_start
 
-#undef TARGET_FIXED_CONDITION_CODE_REG
+#undef TARGET_FIXED_CONDITION_CODE_REGS
 #define TARGET_FIXED_CONDITION_CODE_REGS aarch64_fixed_condition_code_regs
 
 #undef TARGET_FUNCTION_ARG

[patch] Fix PR tree-optimization/56424

[Eric Botcazou]

Hi,

this is the ICE during the build of the Ada runtime on x86-64/Windows: the
compiler stops on the assertion in declare_return_variable:

  var = return_slot;
  gcc_assert (TREE_CODE (var) != SSA_NAME);

The problem stems for the fnsplit pass: it turns

P.Sin (const long_long_float x)
{
  long_long_float _3;
  boolean _4;
  q__double _9;

  :
  _3 = ABS_EXPR ;
  _4 = _3 < 1.0e+0;
  if (_4 != 0)
goto ;
  else
goto ;

  :
   = x_2(D);
  goto ;

  :
  _9 = q.sin (x_2(D));
   = _9;

  :
  return ;

}

into

P.Sin (const long_long_float x)
{
  long_long_float _3;
  boolean _4;

  :
  _3 = ABS_EXPR ;
  _4 = _3 < 1.0e+0;
  if (_4 != 0)
goto ;
  else
goto ;

  :
   = x_2(D);
  goto ;

  :
   = p.sin.part (x_2(D)); [return slot optimization]

  :
  return ;

}

Note the RSO flag on the call to the split part: it's bogus since the return
type is scalar:

  

Fixed by checking that either the type of the result is not is_gimple_reg_type
or the result is passed by reference before setting the RSO flag.

Tested on x86_64-suse-linux, OK for the mainline?


2013-01-01  Eric Botcazou  

PR tree-optimization/56424
* ipa-split.c (split_function): Do not set the RSO flag if result is
not by reference and its type is not a register type.


2013-01-01  Eric Botcazou  

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


-- 
Eric Botcazou
Index: ipa-split.c
===
--- ipa-split.c	(revision 196253)
+++ ipa-split.c	(working copy)
@@ -1309,7 +1309,9 @@ split_function (struct split_point *spli
  so return slot optimization is always possible.  Moreover this is
  required to make DECL_BY_REFERENCE work.  */
   if (aggregate_value_p (DECL_RESULT (current_function_decl),
-			 TREE_TYPE (current_function_decl)))
+			 TREE_TYPE (current_function_decl))
+  && (!is_gimple_reg_type (TREE_TYPE (DECL_RESULT (current_function_decl)))
+	  || DECL_BY_REFERENCE (DECL_RESULT (current_function_decl
 gimple_call_set_return_slot_opt (call, true);
 
   /* Update return value.  This is bit tricky.  When we do not return,
/* PR tree-optimization/56424 */

/* { dg-do compile } */
/* { dg-options "-O2 -fexceptions -fnon-call-exceptions" } */

extern long double cosl (long double);
extern long double sinl (long double);
extern long double reml (long double, long double);

long double my_cos (long double arg)
{
  return cosl (arg);
}

long double my_sin (long double arg)
{
  if (__builtin_fabs (arg) < 1.0)
return arg;

  return sinl (arg);
}

long double my_cot (long double arg, long double cycle)
{
  long double t = reml (arg, cycle);
  return my_cos (t) / my_sin (t);
}

long double my_tan (long double arg, long double cycle)
{
  long double t = reml (arg, cycle);
  return my_sin (t) / my_cos (t);
}

[AArch64/AArch64-4.7][libgcc] Silence warnings in sync-cache.c

[James Greenhalgh]

Hi,

On trunk and 4.7 __aarch64_sync_cache_range gives a missing prototype
warning and two "statement with no effect" warnings as so:

---
.../libgcc/config/aarch64/sync-cache.c:22:1: warning: no previous prototype for 
'__aarch64_sync_cache_range' [-Wmissing-prototypes]
 __aarch64_sync_cache_range (const void *base, const void *end)
 ^
.../libgcc/config/aarch64/sync-cache.c: In function 
'__aarch64_sync_cache_range':
/work/oban-clean/src/gcc/libgcc/config/aarch64/sync-cache.c:46:3: warning: 
statement with no effect [-Wunused-value]
   for (address; address < (const char *) end; address += dcache_lsize)
   ^
.../libgcc/config/aarch64/sync-cache.c:58:3: warning: statement with no effect 
[-Wunused-value]
   for (address; address < (const char *) end; address += icache_lsize)
---

This patch silences these warnings by declaring a prototype for
aarch64_sync_cache_range and removing the no-op for loop initialisation

Regression tested on aarch64-none-linux-gnu with no issues.

OK for trunk/aarch64-4.7-branch?

Thanks,
James Greenhalgh

---
libgcc/

2013-03-01  James Greenhalgh  

* config/aarch64/sync-cache.c
(__aarch64_sync_cache_range): Silence warnings.
diff --git a/libgcc/config/aarch64/sync-cache.c b/libgcc/config/aarch64/sync-cache.c
index 7091c48..3397e9d 100644
--- a/libgcc/config/aarch64/sync-cache.c
+++ b/libgcc/config/aarch64/sync-cache.c
@@ -18,6 +18,8 @@
along with GCC; see the file COPYING3.  If not see
.  */
 
+void __aarch64_sync_cache_range (const void *, const void *);
+
 void
 __aarch64_sync_cache_range (const void *base, const void *end)
 {
@@ -43,7 +45,7 @@ __aarch64_sync_cache_range (const void *base, const void *end)
   address = (const char*) ((__UINTPTR_TYPE__) base
 			   & ~ (__UINTPTR_TYPE__) (dcache_lsize - 1));
 
-  for (address; address < (const char *) end; address += dcache_lsize)
+  for (; address < (const char *) end; address += dcache_lsize)
 asm volatile ("dc\tcvau, %0"
 		  :
 		  : "r" (address)
@@ -55,7 +57,7 @@ __aarch64_sync_cache_range (const void *base, const void *end)
   address = (const char*) ((__UINTPTR_TYPE__) base
 			   & ~ (__UINTPTR_TYPE__) (icache_lsize - 1));
 
-  for (address; address < (const char *) end; address += icache_lsize)
+  for (; address < (const char *) end; address += icache_lsize)
 asm volatile ("ic\tivau, %0"
 		  :
 		  : "r" (address)

Re: [patch] Fix PR tree-optimization/56424

[Richard Biener]

On Fri, Mar 1, 2013 at 12:38 PM, Eric Botcazou  wrote:
> Hi,
>
> this is the ICE during the build of the Ada runtime on x86-64/Windows: the
> compiler stops on the assertion in declare_return_variable:
>
>   var = return_slot;
>   gcc_assert (TREE_CODE (var) != SSA_NAME);
>
> The problem stems for the fnsplit pass: it turns
>
> P.Sin (const long_long_float x)
> {
>   long_long_float _3;
>   boolean _4;
>   q__double _9;
>
>   :
>   _3 = ABS_EXPR ;
>   _4 = _3 < 1.0e+0;
>   if (_4 != 0)
> goto ;
>   else
> goto ;
>
>   :
>= x_2(D);
>   goto ;
>
>   :
>   _9 = q.sin (x_2(D));
>= _9;
>
>   :
>   return ;
>
> }
>
> into
>
> P.Sin (const long_long_float x)
> {
>   long_long_float _3;
>   boolean _4;
>
>   :
>   _3 = ABS_EXPR ;
>   _4 = _3 < 1.0e+0;
>   if (_4 != 0)
> goto ;
>   else
> goto ;
>
>   :
>= x_2(D);
>   goto ;
>
>   :
>= p.sin.part (x_2(D)); [return slot optimization]
>
>   :
>   return ;
>
> }
>
> Note the RSO flag on the call to the split part: it's bogus since the return
> type is scalar:
>
>   
>
> Fixed by checking that either the type of the result is not is_gimple_reg_type
> or the result is passed by reference before setting the RSO flag.
>
> Tested on x86_64-suse-linux, OK for the mainline?

But in theory this pessimizes code as aggregate_value_p returned true
for this?  That is, isn't the bug that we rewrite a possible return-slot-decl
into SSA?  (do we do that here?)

Thanks,
Richard.

>
> 2013-01-01  Eric Botcazou  
>
> PR tree-optimization/56424
> * ipa-split.c (split_function): Do not set the RSO flag if result is
> not by reference and its type is not a register type.
>
>
> 2013-01-01  Eric Botcazou  
>
> * gcc.dg/pr56424.c: New test.
>
>
> --
> Eric Botcazou

Re: [PATCH, ARM, RFC] Fix vect.exp failures for NEON in big-endian mode

[Julian Brown]

On Fri, 1 Mar 2013 11:07:17 +0100
Richard Biener  wrote:

> On Wed, Feb 27, 2013 at 6:29 PM, Julian Brown
>  wrote:
> > Hi,
> >
> > Several new (ish?) autovectorizer features have apparently caused
> > NEON support for same to regress quite heavily in big-endian mode.
> > This patch is an attempt to fix things up, but is not without
> > problems -- maybe someone will have a suggestion as to how we
> > should proceed.
> >
> > The problem (as ever) is that the ARM backend must lie to the
> > middle-end about the layout of NEON vectors in big-endian mode (due
> > to ABI requirements, VFP compatibility, and the middle-end
> > semantics of vector indices being equivalent to those of an array
> > with the same type of elements when stored in memory).
> 
> Why not simply give up?  Thus, make autovectorization unsupported for
> ARM big-endian targets?

That's certainly a tempting option...

> Do I understand correctly that the "only" issue is memory vs. register
> element ordering?  Thus a fixup could be as simple as extra shuffles
> inserted after vector memory loads and before vector memory stores?
> (with the hope of RTL optimizers optimizing those)?

It's not even necessary to use explicit shuffles -- NEON has perfectly
good instructions for loading/storing vectors in the "right" order, in
the form of vld1 & vst1. I'm afraid the solution to this problem might
have been staring us in the face for years, which is simply to forbid
vldr/vstr/vldm/vstm (the instructions which lead to weird element
permutations in BE mode) for loading/storing NEON vectors altogether.
That way the vectorizer gets what it wants, the intrinsics can continue
to use __builtin_shuffle exactly as they are doing, and we get to
remove all the bits which fiddle vector element numbering in BE mode in
the ARM backend.

I can't exactly remember why we didn't do that to start with. I think
the problem was ABI-related, or to do with transferring NEON vectors
to/from ARM registers when it was necessary to do that... I'm planning
to do some archaeology to try to see if I can figure out a definitive
answer.

(Previous discussions include, e.g.:

http://gcc.gnu.org/ml/gcc-patches/2009-11/msg00876.html

http://gcc.gnu.org/ml/gcc-patches/2010-06/msg00409.html

http://lists.linaro.org/pipermail/linaro-toolchain/2010-November/000437.html

it looks like ABI boundaries require vldr/vstr/vldm/vstm ordering:
maybe those can be treated as "opaque" transfers and continue to use
the same instructions & ordering, but vld1/vst1 can be used everywhere
else?)

> Any "lies" are of course bad and you'll pay for them later.

Indeed :-).

Cheers,

Julian

Re: [AArch64/AArch64-4.7][libgcc] Silence warnings in sync-cache.c

[Marcus Shawcroft]

On 01/03/13 11:41, James Greenhalgh wrote:


Hi,

On trunk and 4.7 __aarch64_sync_cache_range gives a missing prototype
warning and two "statement with no effect" warnings as so:


OK
/Marcus

Re: [AArch64-4.7] Fix warning: TARGET_FIXED_CONDITION_CODE_REGS redefined.

[Marcus Shawcroft]

OK

On 1 March 2013 10:49, James Greenhalgh  wrote:
>
> Hi,
>
> config/aarch64/aarch64.c attempts to do this:
>
>> #undef TARGET_FIXED_CONDITION_CODE_REG
>> #define TARGET_FIXED_CONDITION_CODE_REGS aarch64_fixed_condition_code_regs
>
> This patch adds the S to the end of TARGET_FIXED_CONDITION_CODE_REG
> clearing a warning for redefining TARGET_FIXED_CONDITION_REGS
>
> Regression tested on aarch64-none-elf with no issues and checked
> to ensure that the warning is cleared.
>
> OK for aarch64-4.7-branch?
>
> Thanks,
> James
>
> ---
> gcc/
>
> 2013-03-01  James Greenhalgh  
>
> * config/aarch64/aarch64.c:
> Fix typo in `#undef TARGET_FIXED_CONDITION_CODE_REGS'

[PATCH, go] Passing Complex64 and Complex128 values via reflect.Call (using libffi) introduces ABI mismatch

[Uros Bizjak]

Hello!

Due to the fact that libFFI does not handle C99 _Complex arguments
correctly [1], libgo passes Complex64 and Complex128 arguments via a
temporary structure. However, passing parts of complex number in a
structure is not the same as passing true C99 _Complex value, so this
workaround introduces ABI mismatch between caller and callee. This
mismatch results in wrong passed values of complex types.

Fortunately all x86 ABIs tolerate this mismatch, but other targets
(i.e. alpha) don't have this privilege.

Attached patch disables passing of C99 _Complex arguments via FFI on
all targets, other than x86 (to be on the safe side w.r.t. other
targets). Hopefully, someday libffi will be extended to handle
_Complex arguments in correct way.

Patch was tested on x86_64-pc-linux-gnu {,-m32} and alphaev68-pc-linux-gnu.

[1] http://sourceware.org/ml/libffi-discuss/2007/msg00010.html

Uros.
Index: runtime/go-reflect-call.c
===
--- runtime/go-reflect-call.c   (revision 196368)
+++ runtime/go-reflect-call.c   (working copy)
@@ -30,7 +30,7 @@
 static ffi_type *go_string_to_ffi (void) __attribute__ ((no_split_stack));
 static ffi_type *go_interface_to_ffi (void) __attribute__ ((no_split_stack));
 static ffi_type *go_complex_to_ffi (ffi_type *)
-  __attribute__ ((no_split_stack));
+  __attribute__ ((no_split_stack,unused));
 static ffi_type *go_type_to_ffi (const struct __go_type_descriptor *)
   __attribute__ ((no_split_stack));
 static ffi_type *go_func_return_ffi (const struct __go_func_type *)
@@ -185,13 +185,23 @@
return &ffi_type_double;
   abort ();
 case GO_COMPLEX64:
+#if defined (__i386__) || defined (__x86_64__)
   if (sizeof (float) == 4)
return go_complex_to_ffi (&ffi_type_float);
   abort ();
+#else
+  runtime_throw("the ABI does not support Complex64 type with "
+   "reflect.Call or runtime.SetFinalizer");
+#endif
 case GO_COMPLEX128:
+#if defined (__i386__) || defined (__x86_64__)
   if (sizeof (double) == 8)
return go_complex_to_ffi (&ffi_type_double);
   abort ();
+#else
+  runtime_throw("the ABI does not support Complex128 type with "
+   "reflect.Call or runtime.SetFinalizer");
+#endif
 case GO_INT16:
   return &ffi_type_sint16;
 case GO_INT32:
Index: go/testing/quick/quick_test.go
===
--- go/testing/quick/quick_test.go  (revision 196368)
+++ go/testing/quick/quick_test.go  (working copy)
@@ -7,6 +7,7 @@
 import (
"math/rand"
"reflect"
+   "runtime"
"testing"
 )
 
@@ -72,8 +73,10 @@
reportError("fBool", CheckEqual(fBool, fBool, nil), t)
reportError("fFloat32", CheckEqual(fFloat32, fFloat32, nil), t)
reportError("fFloat64", CheckEqual(fFloat64, fFloat64, nil), t)
-   reportError("fComplex64", CheckEqual(fComplex64, fComplex64, nil), t)
-   reportError("fComplex128", CheckEqual(fComplex128, fComplex128, nil), t)
+   if runtime.GOARCH == "386" || runtime.GOARCH == "amd64" {
+   reportError("fComplex64", CheckEqual(fComplex64, fComplex64, 
nil), t)
+   reportError("fComplex128", CheckEqual(fComplex128, fComplex128, 
nil), t)
+   }
reportError("fInt16", CheckEqual(fInt16, fInt16, nil), t)
reportError("fInt32", CheckEqual(fInt32, fInt32, nil), t)
reportError("fInt64", CheckEqual(fInt64, fInt64, nil), t)

RE: [Patch, AArch64] Implement SIMD Absolute Difference Instructions

[James Greenhalgh]

> >> The use of TAB there is fine.  The issue is that you have trail
> white
> >> space at the end of the line, which is still present in the latest
> patch.
> 
> Sorry. I confused it with spaces at the start of pattern instead of
> trailing space. I have modified it as per your suggestion.
> Please review the modified patch.

Hi Naveen,

It looks like you didn't quite catch all of them:

> +#define DEF3a(fname, type, op) \
> +  void  fname##_##type (pR##type a,   \
> +pR##type b,   \
> +pR##type c)   \
> +  {   \
> +int i;\
> +for (i = 0; i < 16; i++)  \
> +  a[i] = op (b[i] - c[i]);\
> +  }

This one introduces a problem for the testsuite as whitespace between
a \ and the newline is an error on some compilers and a warning on GCC.

There is a script at contrib/check_GNU_style.sh which is helpful
for catching bugs like this.

Thanks,
James Greenhalgh

Re: [PATCH, ARM, RFC] Fix vect.exp failures for NEON in big-endian mode

[Paul Brook]

> > Do I understand correctly that the "only" issue is memory vs. register
> > element ordering?  Thus a fixup could be as simple as extra shuffles
> > inserted after vector memory loads and before vector memory stores?
> > (with the hope of RTL optimizers optimizing those)?
> 
> It's not even necessary to use explicit shuffles -- NEON has perfectly
> good instructions for loading/storing vectors in the "right" order, in
> the form of vld1 & vst1. I'm afraid the solution to this problem might
> have been staring us in the face for years, which is simply to forbid
> vldr/vstr/vldm/vstm (the instructions which lead to weird element
> permutations in BE mode) for loading/storing NEON vectors altogether.
> That way the vectorizer gets what it wants, the intrinsics can continue
> to use __builtin_shuffle exactly as they are doing, and we get to
> remove all the bits which fiddle vector element numbering in BE mode in
> the ARM backend.
> 
> I can't exactly remember why we didn't do that to start with. I think
> the problem was ABI-related, or to do with transferring NEON vectors
> to/from ARM registers when it was necessary to do that... I'm planning
> to do some archaeology to try to see if I can figure out a definitive
> answer.

The ABI defined vector types (uint32x4_t etc) are defined to be in vldm/vstm 
order.

Paul

Re: [PATCH, go] Passing Complex64 and Complex128 values via reflect.Call (using libffi) introduces ABI mismatch

[Ian Lance Taylor]

On Fri, Mar 1, 2013 at 4:57 AM, Uros Bizjak  wrote:
>
> Due to the fact that libFFI does not handle C99 _Complex arguments
> correctly [1], libgo passes Complex64 and Complex128 arguments via a
> temporary structure. However, passing parts of complex number in a
> structure is not the same as passing true C99 _Complex value, so this
> workaround introduces ABI mismatch between caller and callee. This
> mismatch results in wrong passed values of complex types.
>
> Fortunately all x86 ABIs tolerate this mismatch, but other targets
> (i.e. alpha) don't have this privilege.

Is there a PR open against libffi?

Do we have any idea which targets pass complex in a manner different
than a struct of two float/doubles?  Your patch assumes that only x86
targets work, but I would expect that many targets work that way.

Ian

Re: [PATCH, go] Passing Complex64 and Complex128 values via reflect.Call (using libffi) introduces ABI mismatch

[Uros Bizjak]

On Fri, Mar 1, 2013 at 3:43 PM, Ian Lance Taylor  wrote:
> On Fri, Mar 1, 2013 at 4:57 AM, Uros Bizjak  wrote:
>>
>> Due to the fact that libFFI does not handle C99 _Complex arguments
>> correctly [1], libgo passes Complex64 and Complex128 arguments via a
>> temporary structure. However, passing parts of complex number in a
>> structure is not the same as passing true C99 _Complex value, so this
>> workaround introduces ABI mismatch between caller and callee. This
>> mismatch results in wrong passed values of complex types.
>>
>> Fortunately all x86 ABIs tolerate this mismatch, but other targets
>> (i.e. alpha) don't have this privilege.
>
> Is there a PR open against libffi?

Not that I know of, but I can open one if requested.

> Do we have any idea which targets pass complex in a manner different
> than a struct of two float/doubles?  Your patch assumes that only x86
> targets work, but I would expect that many targets work that way.

Maybe a test could be added to reflect package that calls foreign
function with _Complex arguments/return value? The function should do
some basic arithmetic on complex values and the test could check if it
returns expected values. This test would reliably catch affected
targets.

Uros.

[c++-concepts] Enable C++11 and concepts by default

[Gabriel Dos Reis]

This patch enables C++11 and concepts support by default on the
c++-concepts branch.

-- Gaby

2013-03-01  Gabriel Dos Reis  

* gcc/c-family/c-common.c (cxx_dialect): Set C++11 as default.
* gcc/c-family/c.opt(flag_concepts): Add.
* gcc/cp/lex.c (flag_concepts): New.  Enabled concept support by
default. 

Index: gcc/c-family/c-common.c
===
--- gcc/c-family/c-common.c (revision 196383)
+++ gcc/c-family/c-common.c (working copy)
@@ -238,9 +238,9 @@
 
 int flag_use_repository;
 
-/* The C++ dialect being used. C++98 is the default.  */
+/* The C++ dialect being used. C++11 is the default.  */
 
-enum cxx_dialect cxx_dialect = cxx98;
+enum cxx_dialect cxx_dialect = cxx11;
 
 /* Maximum template instantiation depth.  This limit exists to limit the
time it takes to notice excessively recursive template instantiations.
Index: gcc/c-family/c.opt
===
--- gcc/c-family/c.opt  (revision 196383)
+++ gcc/c-family/c.opt  (working copy)
@@ -21,6 +21,10 @@
 
 ; Please try to keep this file in ASCII collating order.
 
+; Activate C++ concepts support.
+Variable
+bool flag_concepts
+
 Language
 C
 
@@ -843,6 +847,10 @@
 C ObjC C++ ObjC++
 Where shorter, use canonicalized paths to systems headers.
 
+fconcepts
+C++ ObjC++ Var(flag_concepts, true)
+Activate support for C++ concepts
+
 fcheck-new
 C++ ObjC++ Var(flag_check_new)
 Check the return value of new
Index: gcc/cp/lex.c
===
--- gcc/cp/lex.c(revision 196383)
+++ gcc/cp/lex.c(working copy)
@@ -51,6 +51,9 @@
 /* A constraint that can be tested at compile time.  */
 #define CONSTRAINT(name, expr) extern int constraint_##name [(expr) ? 1 : -1]
 
+/* True if C++ concepts are enabled. */
+bool flag_concepts = true;
+
 /* Functions and data structures for #pragma interface.
 
`#pragma implementation' means that the main file being compiled

Re: [PATCH, go] Passing Complex64 and Complex128 values via reflect.Call (using libffi) introduces ABI mismatch

[Uros Bizjak]

On Fri, Mar 1, 2013 at 3:50 PM, Uros Bizjak  wrote:

>>> Due to the fact that libFFI does not handle C99 _Complex arguments
>>> correctly [1], libgo passes Complex64 and Complex128 arguments via a
>>> temporary structure. However, passing parts of complex number in a
>>> structure is not the same as passing true C99 _Complex value, so this
>>> workaround introduces ABI mismatch between caller and callee. This
>>> mismatch results in wrong passed values of complex types.
>>>
>>> Fortunately all x86 ABIs tolerate this mismatch, but other targets
>>> (i.e. alpha) don't have this privilege.
>>
>> Is there a PR open against libffi?
>
> Not that I know of, but I can open one if requested.

FYI, python is also interested [1] in this enhancement.

[1] http://bugs.python.org/issue16899

Uros.

Re: [PATCH] C++ math constants

[Ulrich Drepper]

How about this patch then?  As I said, I have code in need of
constants lined up and Edward likely also wants to take advantage of
them in some of his code.


Index: include/Makefile.am
===
--- include/Makefile.am (revision 196362)
+++ include/Makefile.am (working copy)
@@ -499,6 +499,7 @@
  ${ext_srcdir}/array_allocator.h \
  ${ext_srcdir}/bitmap_allocator.h \
  ${ext_srcdir}/cast.h \
+ ${ext_srcdir}/cmath \
  ${ext_srcdir}/codecvt_specializations.h \
  ${ext_srcdir}/concurrence.h \
  ${ext_srcdir}/debug_allocator.h \
--- /dev/null 2013-02-06 19:11:05.441448320 -0500
+++ include/ext/cmath 2013-03-01 09:28:36.448535383 -0500
@@ -0,0 +1,152 @@
+// Math extensions -*- C++ -*-
+
+// Copyright (C) 2013 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library.  This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+// GNU General Public License for more details.
+
+// Under Section 7 of GPL version 3, you are granted additional
+// permissions described in the GCC Runtime Library Exception, version
+// 3.1, as published by the Free Software Foundation.
+
+// You should have received a copy of the GNU General Public License and
+// a copy of the GCC Runtime Library Exception along with this program;
+// see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
+// .
+
+/** @file ext/cmath
+ *  This file is a GNU extension to the Standard C++ Library.
+ */
+
+#ifndef _EXT_CMATH
+#define _EXT_CMATH 1
+
+#pragma GCC system_header
+
+#if __cplusplus < 201103L
+# include 
+#else
+
+#include 
+#include 
+
+namespace __gnu_cxx _GLIBCXX_VISIBILITY(default)
+{
+_GLIBCXX_BEGIN_NAMESPACE_VERSION
+
+  // A class for math constants.
+  template
+struct __math_constants
+{
+  static_assert(std::is_floating_point<_RealType>::value,
+"template argument not a floating point type");
+
+  // Constant @f$ \pi @f$.
+  static constexpr _RealType __pi = 3.1415926535897932384626433832795029L;
+  // Constant @f$ \pi / 2 @f$.
+  static constexpr _RealType __pi_half =
1.5707963267948966192313216916397514L;
+  // Constant @f$ \pi / 3 @f$.
+  static constexpr _RealType __pi_third =
1.0471975511965977461542144610931676L;
+  // Constant @f$ \pi / 4 @f$.
+  static constexpr _RealType __pi_quarter =
0.7853981633974483096156608458198757L;
+  // Constant @f$ \sqrt(\pi / 2) @f$.
+  static constexpr _RealType __root_pi_div_2 =
1.2533141373155002512078826424055226L;
+  // Constant @f$ 1 / \pi @f$.
+  static constexpr _RealType __one_div_pi =
0.3183098861837906715377675267450287L;
+  // Constant @f$ 2 / \pi @f$.
+  static constexpr _RealType __two_div_pi =
0.6366197723675813430755350534900574L;
+  // Constant @f$ 2 / \sqrt(\pi) @f$.
+  static constexpr _RealType __two_div_root_pi =
1.1283791670955125738961589031215452L;
+
+  // Constant Euler's number @f$ e @f$.
+  static constexpr _RealType __e = 2.7182818284590452353602874713526625L;
+  // Constant @f$ 1 / e @f$.
+  static constexpr _RealType __one_div_e =
0.36787944117144232159552377016146087L;
+  // Constant @f$ \log_2(e) @f$.
+  static constexpr _RealType __log2_e =
1.4426950408889634073599246810018921L;
+  // Constant @f$ \log_10(e) @f$.
+  static constexpr _RealType __log10_e =
0.4342944819032518276511289189166051L;
+  // Constant @f$ \ln(2) @f$.
+  static constexpr _RealType __ln_2 =
0.6931471805599453094172321214581766L;
+  // Constant @f$ \ln(3) @f$.
+  static constexpr _RealType __ln_3 =
1.0986122886681096913952452369225257L;
+  // Constant @f$ \ln(10) @f$.
+  static constexpr _RealType __ln_10 =
2.3025850929940456840179914546843642L;
+
+  // Constant Euler-Mascheroni @f$ \gamma_E @f$.
+  static constexpr _RealType __gamma_e =
0.5772156649015328606065120900824024L;
+  // Constant Golden Ratio @f$ \phi @f$.
+  static constexpr _RealType __phi = 1.6180339887498948482045868343656381L;
+
+  // Constant @f$ \sqrt(2) @f$.
+  static constexpr _RealType __root_2 =
1.4142135623730950488016887242096981L;
+  // Constant @f$ \sqrt(3) @f$.
+  static constexpr _RealType __root_3 =
1.7320508075688772935274463415058724L;
+  // Constant @f$ \sqrt(5) @f$.
+  static constexpr _RealType __root_5 =
2.2360679774997896964091736687312762L;
+  // Constant @f$ \sqrt(7) @f$.
+  static constexpr _RealType __root_7 =
2.6457513110645905905016157536392604L;
+  // Constant @f$ 1 / \sqrt(2) @f$.
+  static constexpr _Real

Re: [patch] Fix PR tree-optimization/56424

[Eric Botcazou]

> But in theory this pessimizes code as aggregate_value_p returned true
> for this?  That is, isn't the bug that we rewrite a possible
> return-slot-decl into SSA?  (do we do that here?)

Yes, aggregate_value_p returns true for this because the ABI says that this 
type is returned in memory.  And, no, I don't think that this will further 
pessimize, given that it's already "pessimized" in gimplify_modify_expr_rhs:

case CALL_EXPR:
  /* For calls that return in memory, give *to_p as the CALL_EXPR's
 return slot so that we don't generate a temporary.  */
  if (!CALL_EXPR_RETURN_SLOT_OPT (*from_p)
  && aggregate_value_p (*from_p, *from_p))
{
  bool use_target;

  if (!(rhs_predicate_for (*to_p))(*from_p))
/* If we need a temporary, *to_p isn't accurate.  */
use_target = false;
  /* It's OK to use the return slot directly unless it's an NRV. */
  else if (TREE_CODE (*to_p) == RESULT_DECL
   && DECL_NAME (*to_p) == NULL_TREE
   && needs_to_live_in_memory (*to_p))
use_target = true;
  else if (is_gimple_reg_type (TREE_TYPE (*to_p))
   || (DECL_P (*to_p) && DECL_REGISTER (*to_p)))
/* Don't force regs into memory.  */
use_target = false;

-- 
Eric Botcazou

[c++-concepts] flag_concepts declaration

[Gabriel Dos Reis]

The previous patch left a declaration for flag_concepts, which is bogus.

Applied to branch.


-- Gaby

2013-03-01  Gabriel Dos Reis  
 
* lex.c (flag_concepts): Revert left over declaration.
 
Index: gcc/cp/lex.c
===
--- gcc/cp/lex.c(revision 196384)
+++ gcc/cp/lex.c(working copy)
@@ -51,9 +51,6 @@
 /* A constraint that can be tested at compile time.  */
 #define CONSTRAINT(name, expr) extern int constraint_##name [(expr) ? 1 : -1]
 
-/* True if C++ concepts are enabled. */
-bool flag_concepts = true;
-
 /* Functions and data structures for #pragma interface.
 
`#pragma implementation' means that the main file being compiled

[patch, testsuite] Obvious patch for gcc.dg/pr56396.c

[Steve Ellcey]

I am going to check in this testsuite patch as an obvious fix.  We should make
sure a platform supports PIC before compiling with the -fpic flag.

Steve Ellcey
sell...@imgtec.com


2013-03-01  Steve Ellcey  

* gcc.dg/pr56396.c: Require pic support.


diff --git a/gcc/testsuite/gcc.dg/pr56396.c b/gcc/testsuite/gcc.dg/pr56396.c
index d2ec8fa..160545b 100644
--- a/gcc/testsuite/gcc.dg/pr56396.c
+++ b/gcc/testsuite/gcc.dg/pr56396.c
@@ -1,5 +1,6 @@
 /* PR tree-optimization/56396 */
 /* { dg-do compile } */
+/* { dg-require-effective-target fpic } */
 /* { dg-options "-O2 -fpic -g" } */
 
 struct S { char *s; int z; };

Re: [patch, testsuite] Obvious patch for gcc.dg/pr56396.c

[Jakub Jelinek]

On Fri, Mar 01, 2013 at 07:57:12AM -0800, Steve Ellcey  wrote:
> I am going to check in this testsuite patch as an obvious fix.  We should make
> sure a platform supports PIC before compiling with the -fpic flag.
> 
> 2013-03-01  Steve Ellcey  
> 
>   * gcc.dg/pr56396.c: Require pic support.

Ok, thanks.

> --- a/gcc/testsuite/gcc.dg/pr56396.c
> +++ b/gcc/testsuite/gcc.dg/pr56396.c
> @@ -1,5 +1,6 @@
>  /* PR tree-optimization/56396 */
>  /* { dg-do compile } */
> +/* { dg-require-effective-target fpic } */
>  /* { dg-options "-O2 -fpic -g" } */
>  
>  struct S { char *s; int z; };

Jakub

[c++-concepts] Parsing for template requirements

[Andrew Sutton]

Two patches attached.

The reqs-parsing patch adds parsing support for template requirements
(i.e., requires clauses). This is supported for all template
declarations and non-template member functions of class templates.
Grammar changes are documented in comments. Semantic processing of
constraints is stubbed out for the time being.

The flags patch just enables -fconcepts by default.

The combined change log is:

2013-03-01  Andrew Sutton  

* cp-tree.h (saved_scope): Add template requirements.
(finish_template_requirements): Declare
* parser.c (cp_parser_template_requirement_opt): Declare.
(cp_parser_template_declaration): Document grammar extensions.
(cp_parser_type_parameter): Parse requirements for template
template parameters.
(cp_parser_member_declaration): Parse requirements for
members of class templates.
(cp_parser_template_requirement_opt): Define.
(cp_parser_template_declaration_after_exp): Parse requirements
for template declarations.
* semantics.c (finish_template_requirements): Define.
* lex.c (cxx_init): Enable concepts by default.


flags.patch
Description: Binary data


reqs-parsing.patch
Description: Binary data

[Patch, Fortran, committed] Fix another two memory leaks

[Tobias Burnus]

Committed after regtesting as Rev. 196387. (I forgot to mention that it 
fixes PR56491)

http://gcc.gnu.org/ml/gcc-cvs/2013-03/msg00024.html

Tobias
Index: gcc/fortran/ChangeLog
===
--- gcc/fortran/ChangeLog	(Revision 196386)
+++ gcc/fortran/ChangeLog	(Arbeitskopie)
@@ -1,5 +1,10 @@
 2013-03-01  Tobias Burnus  
 
+	* iresolve.c (resolve_bound): Use gfc_get_string instead of xstrdup.
+	* symbol.c (free_components): Free proc-pointer components.
+
+2013-03-01  Tobias Burnus  
+
 	* trans-decl.c (gfc_trans_deferred_vars): Free expr after use.
 	* trans-io.c (build_dt): Ditto.
 
Index: gcc/fortran/iresolve.c
===
--- gcc/fortran/iresolve.c	(Revision 196386)
+++ gcc/fortran/iresolve.c	(Arbeitskopie)
@@ -140,7 +140,7 @@ resolve_bound (gfc_expr *f, gfc_expr *array, gfc_e
 	}
 }
 
-  f->value.function.name = xstrdup (name);
+  f->value.function.name = gfc_get_string (name);
 }
 
 
Index: gcc/fortran/symbol.c
===
--- gcc/fortran/symbol.c	(Revision 196386)
+++ gcc/fortran/symbol.c	(Arbeitskopie)
@@ -2076,6 +2076,7 @@ free_components (gfc_component *p)
 
   gfc_free_array_spec (p->as);
   gfc_free_expr (p->initializer);
+  free (p->tb);
 
   free (p);
 }

Re: *ping* - Re: Fix some texinfo 5.0 warnings in gcc/doc + libiberty

[Joseph S. Myers]

On Fri, 1 Mar 2013, Tobias Burnus wrote:

> http://gcc.gnu.org/ml/gcc-patches/2013-02/msg01106.html

OK, though for the libiberty patch it would be good if someone can find 
the make-obstacks-texi.sh script referred to in libiberty.texi, check it 
in and get obstacks.texi exactly in sync with the output of that script 
run on current glibc sources.

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

Re: [c++-concepts] Parsing for template requirements

[Gabriel Dos Reis]

On Fri, Mar 1, 2013 at 10:12 AM, Andrew Sutton
 wrote:
> Two patches attached.
>
> The reqs-parsing patch adds parsing support for template requirements
> (i.e., requires clauses). This is supported for all template
> declarations and non-template member functions of class templates.
> Grammar changes are documented in comments. Semantic processing of
> constraints is stubbed out for the time being.
>
> The flags patch just enables -fconcepts by default.
>
> The combined change log is:
>
> 2013-03-01  Andrew Sutton  

Patch OK, thanks.  Please adjust the paths in the log to include
the directories -- since everything is going in the toplevel ChangeLog.concepts.

-- Gaby

>
> * cp-tree.h (saved_scope): Add template requirements.
> (finish_template_requirements): Declare
> * parser.c (cp_parser_template_requirement_opt): Declare.
> (cp_parser_template_declaration): Document grammar extensions.
> (cp_parser_type_parameter): Parse requirements for template
> template parameters.
> (cp_parser_member_declaration): Parse requirements for
> members of class templates.
> (cp_parser_template_requirement_opt): Define.
> (cp_parser_template_declaration_after_exp): Parse requirements
> for template declarations.
> * semantics.c (finish_template_requirements): Define.
> * lex.c (cxx_init): Enable concepts by default.

Re: [PATCH, go] Passing Complex64 and Complex128 values via reflect.Call (using libffi) introduces ABI mismatch

[Uros Bizjak]

On Fri, Mar 1, 2013 at 3:43 PM, Ian Lance Taylor  wrote:
> On Fri, Mar 1, 2013 at 4:57 AM, Uros Bizjak  wrote:
>>
>> Due to the fact that libFFI does not handle C99 _Complex arguments
>> correctly [1], libgo passes Complex64 and Complex128 arguments via a
>> temporary structure. However, passing parts of complex number in a
>> structure is not the same as passing true C99 _Complex value, so this
>> workaround introduces ABI mismatch between caller and callee. This
>> mismatch results in wrong passed values of complex types.
>>
>> Fortunately all x86 ABIs tolerate this mismatch, but other targets
>> (i.e. alpha) don't have this privilege.
>
> Is there a PR open against libffi?
>
> Do we have any idea which targets pass complex in a manner different
> than a struct of two float/doubles?  Your patch assumes that only x86
> targets work, but I would expect that many targets work that way.

$ grep -R "define TARGET_SPLIT_COMPLEX_ARG" config
config/rs6000/rs6000.c:#define TARGET_SPLIT_COMPLEX_ARG
hook_bool_const_tree_true
config/xtensa/xtensa.c:#define TARGET_SPLIT_COMPLEX_ARG
hook_bool_const_tree_true
config/alpha/alpha.c:#define TARGET_SPLIT_COMPLEX_ARG alpha_split_complex_arg

We can probably define Complex64 type as "struct { float re, im; }"
and Complex128 as "struct { double re, im; }" for these targets. What
do you think about this approach?

Uros.

Re: [PATCH, go] Passing Complex64 and Complex128 values via reflect.Call (using libffi) introduces ABI mismatch

[Ian Lance Taylor]

On Fri, Mar 1, 2013 at 9:34 AM, Uros Bizjak  wrote:
> On Fri, Mar 1, 2013 at 3:43 PM, Ian Lance Taylor  wrote:
>> On Fri, Mar 1, 2013 at 4:57 AM, Uros Bizjak  wrote:
>>>
>>> Due to the fact that libFFI does not handle C99 _Complex arguments
>>> correctly [1], libgo passes Complex64 and Complex128 arguments via a
>>> temporary structure. However, passing parts of complex number in a
>>> structure is not the same as passing true C99 _Complex value, so this
>>> workaround introduces ABI mismatch between caller and callee. This
>>> mismatch results in wrong passed values of complex types.
>>>
>>> Fortunately all x86 ABIs tolerate this mismatch, but other targets
>>> (i.e. alpha) don't have this privilege.
>>
>> Is there a PR open against libffi?
>>
>> Do we have any idea which targets pass complex in a manner different
>> than a struct of two float/doubles?  Your patch assumes that only x86
>> targets work, but I would expect that many targets work that way.
>
> $ grep -R "define TARGET_SPLIT_COMPLEX_ARG" config
> config/rs6000/rs6000.c:#define TARGET_SPLIT_COMPLEX_ARG
> hook_bool_const_tree_true
> config/xtensa/xtensa.c:#define TARGET_SPLIT_COMPLEX_ARG
> hook_bool_const_tree_true
> config/alpha/alpha.c:#define TARGET_SPLIT_COMPLEX_ARG alpha_split_complex_arg
>
> We can probably define Complex64 type as "struct { float re, im; }"
> and Complex128 as "struct { double re, im; }" for these targets. What
> do you think about this approach?

The odd thing is that those are exactly the targets I would expect to
work with the current code.  I don't see why those should be the
targets that fail.

Right now the reflect.Call implementation is passing Go complex64 and
complex128 types as though they were implemented as struct { float32;
float32 } and struct { float64; float64 } respectively.  The code
assumes that a function that takes a complex64 argument can be called
as though it took a struct argument instead.  Apparently that does not
work on Alpha.  So the case that fails is when the calling convention
for a complex number differs from the calling convention for passing a
struct.

In the Alpha calling convention, how is a complex number passed?  How
is a struct of two floats/doubles passed?

I think your suggestion of implementing complex as a struct would be
somewhat painful to implement, because it would require generating
complicated code for all complex arithmetic.

I'm not strongly opposed to your original patch, I just think it
overreaches in assuming that only x86 works.  What if we flip it
around and assume that only Alpha falis?

Ian

Re: [PATCH, go] Passing Complex64 and Complex128 values via reflect.Call (using libffi) introduces ABI mismatch

[Uros Bizjak]

On Fri, Mar 1, 2013 at 7:26 PM, Ian Lance Taylor  wrote:

> Right now the reflect.Call implementation is passing Go complex64 and
> complex128 types as though they were implemented as struct { float32;
> float32 } and struct { float64; float64 } respectively.  The code
> assumes that a function that takes a complex64 argument can be called
> as though it took a struct argument instead.  Apparently that does not
> work on Alpha.  So the case that fails is when the calling convention
> for a complex number differs from the calling convention for passing a
> struct.
>
> In the Alpha calling convention, how is a complex number passed?  How
> is a struct of two floats/doubles passed?

Looking at the following testcase, they are passed in integer
registers, and returned in memory.

--cut here--
typedef struct
{
  float re, im;
} cfloat_t;

cfloat_t testf (cfloat_t a, cfloat_t b)
{
  cfloat_t r;

  r.re = a.re + b.re;
  r.im = a.im + b.im;
  return r;
}

_Complex float _testf (_Complex float a, _Complex float b)
{
  return a + b;
}
--cut here--

testf:
.frame $30,16,$26,0
lda $30,-16($30)
.prologue 0
mov $16,$0
stq $17,0($30)
stq $18,8($30)
lds $f10,12($30)
lds $f11,4($30)
lds $f12,0($30)
bis $31,$31,$31
adds $f11,$f10,$f11
lds $f10,8($30)
adds $f12,$f10,$f10
sts $f11,4($16)
sts $f10,0($16)
bis $31,$31,$31
lda $30,16($30)
ret $31,($26),1

_testf:
.frame $30,0,$26,0
.prologue 0
adds $f17,$f19,$f1
adds $f16,$f18,$f0
ret $31,($26),1

[the double assembly is practically the same]

> I think your suggestion of implementing complex as a struct would be
> somewhat painful to implement, because it would require generating
> complicated code for all complex arithmetic.
>
> I'm not strongly opposed to your original patch, I just think it
> overreaches in assuming that only x86 works.  What if we flip it
> around and assume that only Alpha falis?

No problem for me, the attached patch was re-tested with libgo tests
on alphaev68-pc-linux-gnu and x86_64-pc-linux-gnu {,-m32} without
errors.

Uros.
Index: go/testing/quick/quick_test.go
===
--- go/testing/quick/quick_test.go  (revision 196386)
+++ go/testing/quick/quick_test.go  (working copy)
@@ -7,6 +7,7 @@ package quick
 import (
"math/rand"
"reflect"
+   "runtime"
"testing"
 )
 
@@ -72,8 +73,10 @@ func TestCheckEqual(t *testing.T) {
reportError("fBool", CheckEqual(fBool, fBool, nil), t)
reportError("fFloat32", CheckEqual(fFloat32, fFloat32, nil), t)
reportError("fFloat64", CheckEqual(fFloat64, fFloat64, nil), t)
-   reportError("fComplex64", CheckEqual(fComplex64, fComplex64, nil), t)
-   reportError("fComplex128", CheckEqual(fComplex128, fComplex128, nil), t)
+   if runtime.GOARCH != "alpha" {
+   reportError("fComplex64", CheckEqual(fComplex64, fComplex64, 
nil), t)
+   reportError("fComplex128", CheckEqual(fComplex128, fComplex128, 
nil), t)
+   }
reportError("fInt16", CheckEqual(fInt16, fInt16, nil), t)
reportError("fInt32", CheckEqual(fInt32, fInt32, nil), t)
reportError("fInt64", CheckEqual(fInt64, fInt64, nil), t)
Index: runtime/go-reflect-call.c
===
--- runtime/go-reflect-call.c   (revision 196386)
+++ runtime/go-reflect-call.c   (working copy)
@@ -30,7 +30,7 @@ static ffi_type *go_struct_to_ffi (const struct __
 static ffi_type *go_string_to_ffi (void) __attribute__ ((no_split_stack));
 static ffi_type *go_interface_to_ffi (void) __attribute__ ((no_split_stack));
 static ffi_type *go_complex_to_ffi (ffi_type *)
-  __attribute__ ((no_split_stack));
+  __attribute__ ((no_split_stack,unused));
 static ffi_type *go_type_to_ffi (const struct __go_type_descriptor *)
   __attribute__ ((no_split_stack));
 static ffi_type *go_func_return_ffi (const struct __go_func_type *)
@@ -185,13 +185,23 @@ go_type_to_ffi (const struct __go_type_descriptor
return &ffi_type_double;
   abort ();
 case GO_COMPLEX64:
+#ifdef __alpha__
+  runtime_throw("the ABI does not support Complex64 type with "
+   "reflect.Call or runtime.SetFinalizer");
+#else
   if (sizeof (float) == 4)
return go_complex_to_ffi (&ffi_type_float);
   abort ();
+#endif
 case GO_COMPLEX128:
+#ifdef __alpha__
+  runtime_throw("the ABI does not support Complex128 type with "
+   "reflect.Call or runtime.SetFinalizer");
+#else
   if (sizeof (double) == 8)
return go_complex_to_ffi (&ffi_type_double);
   abort ();
+#endif
 case GO_INT16:
   return &ffi_type_sint16;
 case GO_INT32:

more distributions

[Ulrich Drepper]

I have a few more distributions to be added.  The triangle
distribution is the result of combining to uniform distributions and
therefore quite frequently used.  The von Mises distribution (the
simple, 2D version) would be the first circular distribution.

The patch depends on the __math_constants patch.


d-gcc-tri-mises
Description: Binary data

Re: *ping* - Re: Fix some texinfo 5.0 warnings in gcc/doc + libiberty

[Tobias Burnus]

Joseph S. Myers wrote:

OK, though for the libiberty patch it would be good if someone can find
the make-obstacks-texi.sh script referred to in libiberty.texi, check it
in and get obstacks.texi exactly in sync with the output of that script
run on current glibc sources.


I couldn't find it, but I created a Perl version of the unknown script.

Is the attached patch OK? (I tested it with "make info html pdf" using 
(only) texinfo-4.13a.)


Tobias
contrib/
2012-03-01  Tobias Burnus  

	* make-obstacks-texi.pl: New.

libiberty/
2012-03-01  Tobias Burnus  

	* libiberty.texi: Update comment, remove lowersections.
	* obstacks.texi: Regenerate.

diff --git a/contrib/make-obstacks-texi.pl b/contrib/make-obstacks-texi.pl
new file mode 100755
index 000..8128dd6
--- /dev/null
+++ b/contrib/make-obstacks-texi.pl
@@ -0,0 +1,46 @@
+#!/usr/bin/perl -w
+
+# (C) 2012 Free Software Foundation
+# Contributed by Tobias Burnus
+#
+# This script is Free Software, and it can be copied, distributed and
+# modified as defined in the GNU General Public License.  A copy of
+# its license can be downloaded from http://www.gnu.org/copyleft/gpl.html
+
+use strict;
+use File::Basename;
+
+
+if ($#ARGV != 0 or $ARGV[0] eq "")  {
+   my $name = basename($0);
+
+   print "\nUSAGE: `$name` memory.texi\n\n";
+   print "Reads GLIBC's manual/memory.texi and extracts the obstacks section\n"
+."Redirect the output to update GCC's libiberty/obstacks.texi\n\n";
+   exit 1;
+}
+
+open (IN, "<$ARGV[0]") || die "Cannot open '$ARGV[0]': $!";
+my $data = join ("", );
+close (IN);
+
+$data =~ s/.*\@node Obstacks\n/\@node Obstacks\n/s;
+$data =~ s/\n\@node [^\n]+\n\@subsection.*/\n/s;
+
+# Add refs to GLIBC
+$data =~ s/(\@p?xref{[^}]*)}/$1, , , libc, The GNU C Library Reference Manual}/gs;
+
+
+# And undo the refs which are in this file
+my @nodes = grep /^\@node /, (split /\n/, $data);
+
+foreach my $node (@nodes) {
+  $node =~ s/\@node //;
+  $node =~ s/,.*//;
+  $node =~ s/ / *\n?/g;
+  chomp ($node);
+
+  $data =~ s/(\@p?xref{$node), , , libc, The GNU C Library Reference Manual}/$1}/gsi;
+}
+
+print $data;
diff --git a/libiberty/.obstacks.texi.swp b/libiberty/.obstacks.texi.swp
new file mode 100644
index 000..545bf97
Binary files /dev/null and b/libiberty/.obstacks.texi.swp differ
diff --git a/libiberty/libiberty.texi b/libiberty/libiberty.texi
index f1e4bdd..f4af66d 100644
--- a/libiberty/libiberty.texi
+++ b/libiberty/libiberty.texi
@@ -241,13 +241,8 @@ central location from which to use, maintain, and distribute them.
 * Obstacks:: Stacks of arbitrary objects.
 @end menu
 
-@c This is generated from the glibc manual using a make-obstacks-texi.sh
-@c script of Phil's.  Hope it's accurate.
-@lowersections
-@lowersections
+@c This is generated from the glibc manual using contrib/make-obstacks-texi.pl
 @include obstacks.texi
-@raisesections
-@raisesections
 
 @node Functions
 @chapter Function, Variable, and Macro Listing.
diff --git a/libiberty/obstacks.texi b/libiberty/obstacks.texi
index 67780aa..adcd810 100644
--- a/libiberty/obstacks.texi
+++ b/libiberty/obstacks.texi
@@ -1,5 +1,5 @@
 @node Obstacks
-@chapter Obstacks
+@subsection Obstacks
 @cindex obstacks
 
 An @dfn{obstack} is a pool of memory containing a stack of objects.  You
@@ -15,25 +15,25 @@ the objects are usually small.  And the only space overhead per object is
 the padding needed to start each object on a suitable boundary.
 
 @menu
-* Creating Obstacks::   How to declare an obstack in your program.
-* Preparing for Obstacks::  Preparations needed before you can
-use obstacks.
+* Creating Obstacks::		How to declare an obstack in your program.
+* Preparing for Obstacks::	Preparations needed before you can
+ use obstacks.
 * Allocation in an Obstack::Allocating objects in an obstack.
 * Freeing Obstack Objects:: Freeing objects in an obstack.
-* Obstack Functions::   The obstack functions are both
-functions and macros.
+* Obstack Functions::		The obstack functions are both
+ functions and macros.
 * Growing Objects:: Making an object bigger by stages.
-* Extra Fast Growing::  Extra-high-efficiency (though more
-complicated) growing objects.
+* Extra Fast Growing::		Extra-high-efficiency (though more
+ complicated) growing objects.
 * Status of an Obstack::Inquiries about the status of an obstack.
 * Obstacks Data Alignment:: Controlling alignment of objects in obstacks.
 * Obstack Chunks::  How obstacks obtain and release chunks;
-efficiency considerations.
+ efficiency considerations.
 * Summary of Obstacks::
 @end menu
 
 @node Creating Obstacks
-@section Creating Obstacks
+@subsubsection Creating Obstacks
 
 The utilities for manipulating obstacks are declared in the header
 file @file{obstack.h}.
@@ -74,7 +74,7 @@ directly or indi

Re: [PATCH, go] Passing Complex64 and Complex128 values via reflect.Call (using libffi) introduces ABI mismatch

[Ian Lance Taylor]

On Fri, Mar 1, 2013 at 10:50 AM, Uros Bizjak  wrote:
>
> No problem for me, the attached patch was re-tested with libgo tests
> on alphaev68-pc-linux-gnu and x86_64-pc-linux-gnu {,-m32} without
> errors.

Committed with slightly different error messages, like so.

Thanks.

Ian


foo.patch
Description: Binary data

[PATCH] Fix memory leak due to destroy_loop_vec_info (PR middle-end/56461)

[Jakub Jelinek]

Hi!

This fixes leaks like
==31176== 176 bytes in 2 blocks are definitely lost in loss record 432 of 541
==31176==at 0x4A0881C: malloc (vg_replace_malloc.c:270)
==31176==by 0x114DF6F: xrealloc (xmalloc.c:177)
==31176==by 0x85E0AA: void 
va_heap::reserve(vec*&, unsigned int, bool) (vec.h:300)
==31176==by 0x85DE23: vec::reserve(unsigned int, bool) (vec.h:1468)
==31176==by 0xA7961C: vec::reserve_exact(unsigned int) (vec.h:1482)
==31176==by 0xA79402: vec::create(unsigned int) (vec.h:1497)
==31176==by 0xC7189C: new_loop_vec_info(loop*) (tree-vect-loop.c:871)
==31176==by 0xC725EB: vect_analyze_loop_form(loop*) (tree-vect-loop.c:1251)
==31176==by 0xC71DEE: vect_analyze_loop_1(loop*) (tree-vect-loop.c:1000)
==31176==by 0xC71F6D: vect_analyze_loop_form(loop*) (tree-vect-loop.c:1098)
==31176==by 0xC73815: vect_analyze_loop(loop*) (tree-vect-loop.c:1764)
==31176==by 0xC8F9EA: vectorize_loops() (tree-vectorizer.c:113)
and various others, when vect_analyze_loop_form calls destroy_loop_vec_info
with false as second argument, we leak various fields.  My understanding
is that back when clean_stmts argument has been added, the if (!clean_stmts)
switch got a copy of all the cleanups the other code path did, except for the 
loop
actually freeing stmt_vec_info, but already shortly after it new fields
have been added and cleanup for those has been added to just one spot instead
of two.

The patch fixes it by doing all the cleanups for !clean_stmts too in the
same code path, except for the stmt_vec_info freeing.  With -O3 -mavx
I didn't see any code differences on all of gcc.dg/vect/*.c.

Also, passing false to the second to last call to destroy_loop_vec_info
where we return NULL looks like a typo to my eyes, so I've changed that too.

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

2013-03-01  Jakub Jelinek  

PR middle-end/56461
* tree-vect-loop.c (destroy_loop_vec_info): For !clean_stmts, just
set nbbs to 0 instead of having separate code path.
(vect_analyze_loop_form): Call destroy_loop_vec_info with true
instead of false as last argument if returning NULL.

--- gcc/tree-vect-loop.c.jj 2013-02-27 22:40:24.0 +0100
+++ gcc/tree-vect-loop.c2013-03-01 11:27:53.205162019 +0100
@@ -905,23 +905,9 @@ destroy_loop_vec_info (loop_vec_info loo
   loop = LOOP_VINFO_LOOP (loop_vinfo);
 
   bbs = LOOP_VINFO_BBS (loop_vinfo);
-  nbbs = loop->num_nodes;
+  nbbs = clean_stmts ? loop->num_nodes : 0;
   swapped = LOOP_VINFO_OPERANDS_SWAPPED (loop_vinfo);
 
-  if (!clean_stmts)
-{
-  free (LOOP_VINFO_BBS (loop_vinfo));
-  free_data_refs (LOOP_VINFO_DATAREFS (loop_vinfo));
-  free_dependence_relations (LOOP_VINFO_DDRS (loop_vinfo));
-  LOOP_VINFO_LOOP_NEST (loop_vinfo).release ();
-  LOOP_VINFO_MAY_MISALIGN_STMTS (loop_vinfo).release ();
-  LOOP_VINFO_MAY_ALIAS_DDRS (loop_vinfo).release ();
-
-  free (loop_vinfo);
-  loop->aux = NULL;
-  return;
-}
-
   for (j = 0; j < nbbs; j++)
 {
   basic_block bb = bbs[j];
@@ -1244,7 +1230,7 @@ vect_analyze_loop_form (struct loop *loo
dump_printf_loc (MSG_MISSED_OPTIMIZATION, vect_location,
 "not vectorized: number of iterations = 0.");
   if (inner_loop_vinfo)
-destroy_loop_vec_info (inner_loop_vinfo, false);
+destroy_loop_vec_info (inner_loop_vinfo, true);
   return NULL;
 }
 

Jakub

[lra] merged with trunk

[Vladimir Makarov]

LRA branch was merged with trunk @ r196386.

The branch was successfully bootstrapped on x86 and x86-64.

Committed as rev. 196390.

[PATCH] Fix leaks in vectorizable_shift (PR middle-end/56461)

[Jakub Jelinek]

Hi!

Except for the case when we set vec_oprnd1 to non-NULL, with j == 0
we always initialize vec_oprnds[01] with vect_get_vec_defs, which overwrites
the vectors rather than just filling them.  So we shouldn't allocate the
vectors first.

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

2013-03-01  Jakub Jelinek  

PR middle-end/56461
* tree-vect-stmts.c (vectorizable_shift): Don't call create methods
on vec_oprnds0 or vec_oprnds1 before loop, only call it on
vec_oprnds1 right before pushing anything to it for
scalar_shift_arg.

--- gcc/tree-vect-stmts.c.jj2013-02-28 22:19:57.0 +0100
+++ gcc/tree-vect-stmts.c   2013-03-01 11:59:03.973792955 +0100
@@ -3335,21 +3335,6 @@ vectorizable_shift (gimple stmt, gimple_
   /* Handle def.  */
   vec_dest = vect_create_destination_var (scalar_dest, vectype);
 
-  /* Allocate VECs for vector operands.  In case of SLP, vector operands are
- created in the previous stages of the recursion, so no allocation is
- needed, except for the case of shift with scalar shift argument.  In that
- case we store the scalar operand in VEC_OPRNDS1 for every vector stmt to
- be created to vectorize the SLP group, i.e., SLP_NODE->VEC_STMTS_SIZE.
- In case of loop-based vectorization we allocate VECs of size 1.  We
- allocate VEC_OPRNDS1 only in case of binary operation.  */
-  if (!slp_node)
-{
-  vec_oprnds0.create (1);
-  vec_oprnds1.create (1);
-}
-  else if (scalar_shift_arg)
-vec_oprnds1.create (slp_node->vec_stmts_size);
-
   prev_stmt_info = NULL;
   for (j = 0; j < ncopies; j++)
 {
@@ -3369,6 +3354,7 @@ vectorizable_shift (gimple stmt, gimple_
 dump_printf_loc (MSG_NOTE, vect_location,
  "operand 1 using scalar mode.");
   vec_oprnd1 = op1;
+  vec_oprnds1.create (slp_node ? slp_node->vec_stmts_size : 1);
   vec_oprnds1.quick_push (vec_oprnd1);
   if (slp_node)
 {

Jakub

[PATCH] Fix memory leak in vectorizable_conversion (PR middle-end/56461)

[Jakub Jelinek]

Hi!

For the modifier == NONE && !slp_node case we call vect_get_vec_defs, so
we overwrite vec_oprnds0, thus we shouldn't allocate it.

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

2013-03-01  Jakub Jelinek  

PR middle-end/56461
* tree-vect-stmts.c (vectorizable_conversion): Don't call
vec_oprnds0.create (1) for modifier == NONE.

--- gcc/tree-vect-stmts.c.jj2013-03-01 11:59:03.0 +0100
+++ gcc/tree-vect-stmts.c   2013-03-01 12:39:08.521188115 +0100
@@ -2616,15 +2616,13 @@ vectorizable_conversion (gimple stmt, gi
 
   if (!slp_node)
 {
-  if (modifier == NONE)
-   vec_oprnds0.create (1);
-  else if (modifier == WIDEN)
+  if (modifier == WIDEN)
{
  vec_oprnds0.create (multi_step_cvt ? vect_pow2(multi_step_cvt) : 1);
  if (op_type == binary_op)
vec_oprnds1.create (1);
}
-  else
+  else if (modifier == NARROW)
vec_oprnds0.create (
   2 * (multi_step_cvt ? vect_pow2 (multi_step_cvt) : 1));
 }

Jakub

[PATCH] Fix memory leaks in ldist_gen (PR middle-end/56461)

[Jakub Jelinek]

Hi!

When merging partitions together, we remove them from partitions vector,
thus don't free them at all.  Fixed thusly, bootstrapped/regtested on
x86_64-linux and i686-linux, ok for trunk?

2013-03-01  Jakub Jelinek  

PR middle-end/56461
* tree-loop-distribution.c (ldist_gen): Call partition_free after each
partitions.ordered_remove.

--- gcc/tree-loop-distribution.c.jj 2013-01-28 17:06:51.0 +0100
+++ gcc/tree-loop-distribution.c2013-03-01 13:17:11.851331653 +0100
@@ -1306,6 +1306,7 @@ ldist_gen (struct loop *loop, struct gra
if (partition->kind == PKIND_REDUCTION)
  into->kind = PKIND_REDUCTION;
partitions.ordered_remove (i);
+   partition_free (partition);
i--;
  }
else
@@ -1342,6 +1343,7 @@ ldist_gen (struct loop *loop, struct gra
  if (partition->kind == PKIND_REDUCTION)
into->kind = PKIND_REDUCTION;
  partitions.ordered_remove (j);
+ partition_free (partition);
  j--;
}
}
@@ -1367,6 +1369,7 @@ ldist_gen (struct loop *loop, struct gra
  bitmap_ior_into (into->stmts, what->stmts);
  into->kind = PKIND_REDUCTION;
  partitions.ordered_remove (i);
+ partition_free (what);
}
}
 }

Jakub

[PATCH] Fix valgrind checking bootstrap with PCH (PR middle-end/56461)

[Jakub Jelinek]

Hi!

When I've tried --enable-checking=valgrind bootstrap recently, it failed
as soon as compiling first PCH header.  The problem is that in
ggc_internal_alloc_stat we often increase the requested size through
ggc_round_alloc_size_1 (size, &order, &object_size);
and there is no way to query the actual size, so for PCH saving all we
know is the larger object_size.  From size to object_size the memory
is marked as unaccessible for valgrind though:
  /* Make the bytes after the end of the object unaccessible.  Discard the
 handle to avoid handle leak.  */
  VALGRIND_DISCARD (VALGRIND_MAKE_MEM_NOACCESS ((char *) result + size,
object_size - size));
thus when we're trying to save it into the PCH file (sure, we'll store
there usually the 0xaf bytes), we hit tons of valgrind errors.

Fixed by making the memory accessible again (and fully defined) for the
actual writing to PCH, and then restoring the previous state.

Also, I've plugged two memory leaks in PCH writing.

Bootstrapped/regtested on x86_64-linux and i686-linux, tested also with
valgrind checking on various testcases (full --enable-checking=yes,valgrind
bootstrap queued for the weekend).

Ok for trunk?

2013-03-01  Jakub Jelinek  

PR middle-end/56461
* ggc-common.c (gt_pch_save): For ENABLE_VALGRIND_CHECKING,
if VALGRIND_GET_VBITS is defined, temporarily make object
memory all defined, and restore previous valgrind addressability
and definability afterwards.  Free this_object at the end.

* c-pch.c (pch_init): Free target_validity at the end.

--- gcc/ggc-common.c.jj 2013-01-24 17:04:30.0 +0100
+++ gcc/ggc-common.c2013-03-01 16:32:24.547261238 +0100
@@ -561,6 +561,10 @@ gt_pch_save (FILE *f)
 
   ggc_pch_prepare_write (state.d, state.f);
 
+#if defined ENABLE_VALGRIND_CHECKING && defined VALGRIND_GET_VBITS
+  vec vbits = vNULL;
+#endif
+
   /* Actually write out the objects.  */
   for (i = 0; i < state.count; i++)
 {
@@ -569,6 +573,50 @@ gt_pch_save (FILE *f)
  this_object_size = state.ptrs[i]->size;
  this_object = XRESIZEVAR (char, this_object, this_object_size);
}
+#if defined ENABLE_VALGRIND_CHECKING && defined VALGRIND_GET_VBITS
+  /* obj might contain uninitialized bytes, e.g. in the trailing
+padding of the object.  Avoid warnings by making the memory
+temporarily defined and then restoring previous state.  */
+  int get_vbits = 0;
+  size_t valid_size = state.ptrs[i]->size;
+  if (__builtin_expect (RUNNING_ON_VALGRIND, 0))
+   {
+ if (vbits.length () < valid_size)
+   vbits.safe_grow (valid_size);
+ get_vbits = VALGRIND_GET_VBITS (state.ptrs[i]->obj,
+ vbits.address (), valid_size);
+ if (get_vbits == 3)
+   {
+ /* We assume that first part of obj is addressable, and
+the rest is unaddressable.  Find out where the boundary is
+using binary search.  */
+ size_t lo = 0, hi = valid_size;
+ while (hi > lo)
+   {
+ size_t mid = (lo + hi) / 2;
+ get_vbits = VALGRIND_GET_VBITS ((char *) state.ptrs[i]->obj
+ + mid, vbits.address (),
+ 1);
+ if (get_vbits == 3)
+   hi = mid;
+ else if (get_vbits == 1)
+   lo = mid + 1;
+ else
+   break;
+   }
+ if (get_vbits == 1 || get_vbits == 3)
+   {
+ valid_size = lo;
+ get_vbits = VALGRIND_GET_VBITS (state.ptrs[i]->obj,
+ vbits.address (),
+ valid_size);
+   }
+   }
+ if (get_vbits == 1)
+   VALGRIND_DISCARD (VALGRIND_MAKE_MEM_DEFINED (state.ptrs[i]->obj,
+state.ptrs[i]->size));
+   }
+#endif
   memcpy (this_object, state.ptrs[i]->obj, state.ptrs[i]->size);
   if (state.ptrs[i]->reorder_fn != NULL)
state.ptrs[i]->reorder_fn (state.ptrs[i]->obj,
@@ -582,11 +630,29 @@ gt_pch_save (FILE *f)
state.ptrs[i]->note_ptr_fn == gt_pch_p_S);
   if (state.ptrs[i]->note_ptr_fn != gt_pch_p_S)
memcpy (state.ptrs[i]->obj, this_object, state.ptrs[i]->size);
+#if defined ENABLE_VALGRIND_CHECKING && defined VALGRIND_GET_VBITS
+  if (__builtin_expect (get_vbits == 1, 0))
+   {
+ (void) VALGRIND_SET_VBITS (state.ptrs[i]->obj, vbits.address (),
+valid_size);
+ if (valid_size != state.ptrs[i]->size)
+   VALGRIND_DISCARD (VALGRIND_MAKE_MEM_NOACCESS ((char *)
+ 

[PATCH] Fix libcpp PCH related memory leaks (PR middle-end/56461)

[Jakub Jelinek]

Hi!

This patch fixes various memory leaks in libcpp during PCH writing.

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

2013-03-01  Jakub Jelinek  

PR middle-end/56461
* files.c (_cpp_save_file_entries): Free result at the end.
* pch.c (cpp_string_free): New function.
(cpp_save_state): Use it in htab_create call.
(cpp_write_pch_deps): Free ss->defs.  Destroy ss->definedhash.

--- libcpp/files.c.jj   2013-02-28 23:53:11.0 +0100
+++ libcpp/files.c  2013-03-01 16:36:09.849026241 +0100
@@ -1776,6 +1776,7 @@ _cpp_save_file_entries (cpp_reader *pfil
   struct pchf_data *result;
   size_t result_size;
   _cpp_file *f;
+  bool ret;
 
   for (f = pfile->all_files; f; f = f->next_file)
 ++count;
@@ -1832,7 +1833,9 @@ _cpp_save_file_entries (cpp_reader *pfil
   qsort (result->entries, result->count, sizeof (struct pchf_entry),
 pchf_save_compare);
 
-  return fwrite (result, result_size, 1, fp) == 1;
+  ret = fwrite (result, result_size, 1, fp) == 1;
+  free (result);
+  return ret;
 }
 
 /* Read the pchf_data structure from F.  */
--- libcpp/pch.c.jj 2013-01-15 09:04:55.0 +0100
+++ libcpp/pch.c2013-03-01 17:05:59.048498975 +0100
@@ -187,6 +187,16 @@ cpp_string_eq (const void *a_p, const vo
  && memcmp (a->text, b->text, a->len) == 0);
 }
 
+/* Free memory associated with cpp_string.  */
+
+static void
+cpp_string_free (void *a_p)
+{
+  struct cpp_string *a = (struct cpp_string *) a_p;
+  free ((void *) a->text);
+  free (a);
+}
+
 /* Save the current definitions of the cpp_reader for dependency
checking purposes.  When writing a precompiled header, this should
be called at the same point in the compilation as cpp_valid_state
@@ -198,7 +208,7 @@ cpp_save_state (cpp_reader *r, FILE *f)
   /* Save the list of non-void identifiers for the dependency checking.  */
   r->savedstate = XNEW (struct cpp_savedstate);
   r->savedstate->definedhash = htab_create (100, cpp_string_hash,
-   cpp_string_eq, NULL);
+   cpp_string_eq, cpp_string_free);
   cpp_forall_identifiers (r, save_idents, r->savedstate);
 
   /* Write out the list of defined identifiers.  */
@@ -336,6 +346,8 @@ cpp_write_pch_deps (cpp_reader *r, FILE
   return -1;
 }
   free (ss->definedstrs);
+  free (ss->defs);
+  htab_delete (ss->definedhash);
 
   /* Free the saved state.  */
   free (ss);

Jakub

[PATCH] Fix memory leak in tree_estimate_loop_size (PR middle-end/56461)

[Jakub Jelinek]

Hi!

path vector has been only released when return false; later in the function,
but not in this case.  Bootstrapped/regtested on x86_64-linux and
i686-linux, ok for trunk?

2013-03-01  Jakub Jelinek  

PR middle-end/56461
* tree-ssa-loop-ivcanon.c (tree_estimate_loop_size): Release path
vector even when returning true.  Fix up function comment formatting.

--- gcc/tree-ssa-loop-ivcanon.c.jj  2013-01-11 09:02:48.0 +0100
+++ gcc/tree-ssa-loop-ivcanon.c 2013-03-01 17:16:51.955088637 +0100
@@ -207,7 +207,7 @@ constant_after_peeling (tree op, gimple
EDGE_TO_CANCEL (if non-NULL) is an non-exit edge eliminated in the last 
iteration
of loop.
Return results in SIZE, estimate benefits for complete unrolling exiting by 
EXIT. 
-   Stop estimating after UPPER_BOUND is met. Return true in this case */
+   Stop estimating after UPPER_BOUND is met.  Return true in this case.  */
 
 static bool
 tree_estimate_loop_size (struct loop *loop, edge exit, edge edge_to_cancel, 
struct loop_size *size,
@@ -321,6 +321,7 @@ tree_estimate_loop_size (struct loop *lo
  - size->last_iteration_eliminated_by_peeling) > upper_bound)
{
   free (body);
+ path.release ();
  return true;
}
}

Jakub

[PATCH] Fix IRA memory leak (PR middle-end/56461)

[Jakub Jelinek]

Hi!

When ira_destroy is called, often (always?) this is after
loop_optimize_finalize call and thus current_loops is NULL, which results in
only freeing ira_loop_nodes[0] and not ira_loop_nodes[1] and above (if any).

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

2013-03-01  Jakub Jelinek  

PR middle-end/56461
* ira-build.c (ira_loop_nodes_count): New variable.
(create_loop_tree_nodes): Initialize it.
(finish_loop_tree_nodes): Use it instead of looking at current_loops.

--- gcc/ira-build.c.jj  2013-02-08 13:16:55.0 +0100
+++ gcc/ira-build.c 2013-03-01 17:30:30.279549566 +0100
@@ -57,6 +57,9 @@ ira_loop_tree_node_t ira_bb_nodes;
array.  */
 ira_loop_tree_node_t ira_loop_nodes;
 
+/* And size of the ira_loop_nodes array.  */
+unsigned int ira_loop_nodes_count;
+
 /* Map regno -> allocnos with given regno (see comments for
allocno member `next_regno_allocno').  */
 ira_allocno_t *ira_regno_allocno_map;
@@ -142,14 +145,16 @@ create_loop_tree_nodes (void)
 }
   if (current_loops == NULL)
 {
+  ira_loop_nodes_count = 1;
   ira_loop_nodes = ((struct ira_loop_tree_node *)
ira_allocate (sizeof (struct ira_loop_tree_node)));
   init_loop_tree_node (ira_loop_nodes, 0);
   return;
 }
+  ira_loop_nodes_count = number_of_loops ();
   ira_loop_nodes = ((struct ira_loop_tree_node *)
ira_allocate (sizeof (struct ira_loop_tree_node)
- * number_of_loops ()));
+ * ira_loop_nodes_count));
   FOR_EACH_VEC_SAFE_ELT (get_loops (), i, loop)
 {
   if (loop_outer (loop) != NULL)
@@ -217,13 +222,9 @@ static void
 finish_loop_tree_nodes (void)
 {
   unsigned int i;
-  loop_p loop;
 
-  if (current_loops == NULL)
-finish_loop_tree_node (&ira_loop_nodes[0]);
-  else
-FOR_EACH_VEC_SAFE_ELT (get_loops (), i, loop)
-  finish_loop_tree_node (&ira_loop_nodes[i]);
+  for (i = 0; i < ira_loop_nodes_count; i++)
+finish_loop_tree_node (&ira_loop_nodes[i]);
   ira_free (ira_loop_nodes);
   for (i = 0; i < (unsigned int) last_basic_block_before_change; i++)
 {

Jakub

[PATCH] Fix vectorizable_store memory leaks (PR middle-end/56461)

[Jakub Jelinek]

Hi!

The first two hunks are similar issue to what I've posted for
vect_permute_load_chain two days ago, the remaining issue is that
if ncopies > 1, we'd leak the result_chain vector too.

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

2013-03-01  Jakub Jelinek  

PR middle-end/56461
* tree-vect-data-refs.c (vect_permute_store_chain): Avoid using copy
method on dr_chain and result_chain.
* tree-vect-stmts.c (vectorizable_store): Only call
result_chain.create if j == 0.

--- gcc/tree-vect-data-refs.c.jj2013-02-27 23:05:57.0 +0100
+++ gcc/tree-vect-data-refs.c   2013-03-01 17:41:12.296992793 +0100
@@ -4218,7 +4218,9 @@ vect_permute_store_chain (vec dr_c
   unsigned int j, nelt = TYPE_VECTOR_SUBPARTS (vectype);
   unsigned char *sel = XALLOCAVEC (unsigned char, nelt);
 
-  *result_chain = dr_chain.copy ();
+  result_chain->quick_grow (length);
+  memcpy (result_chain->address (), dr_chain.address (),
+ length * sizeof (tree));
 
   for (i = 0, n = nelt / 2; i < n; i++)
 {
@@ -4259,7 +4261,8 @@ vect_permute_store_chain (vec dr_c
  vect_finish_stmt_generation (stmt, perm_stmt, gsi);
  (*result_chain)[2*j+1] = low;
}
-  dr_chain = result_chain->copy ();
+  memcpy (dr_chain.address (), result_chain->address (),
+ length * sizeof (tree));
 }
 }
 
--- gcc/tree-vect-stmts.c.jj2013-03-01 13:33:37.0 +0100
+++ gcc/tree-vect-stmts.c   2013-03-01 17:35:17.146958118 +0100
@@ -4135,7 +4135,8 @@ vectorizable_store (gimple stmt, gimple_
  new_stmt = NULL;
  if (grouped_store)
{
- result_chain.create (group_size);
+ if (j == 0)
+   result_chain.create (group_size);
  /* Permute.  */
  vect_permute_store_chain (dr_chain, group_size, stmt, gsi,
&result_chain);

Jakub

[PATCH] Fix memory leak in vect_create_vectorized_promotion_stmts (PR middle-end/56461)

[Jakub Jelinek]

Hi!

4.7 did here:
  VEC_free (tree, heap, *vec_oprnds0);
  *vec_oprnds0 = vec_tmp;
so vec_oprnds0->truncate (0) doesn't match that, and leaks memory.

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

2013-03-01  Jakub Jelinek  

PR middle-end/56461
* tree-vect-stmts.c (vect_create_vectorized_promotion_stmts): Call
vec_oprnds0->release (); rather than vec_oprnds0->truncate (0)
before overwriting it.

--- gcc/tree-vect-stmts.c.jj2013-03-01 12:39:08.0 +0100
+++ gcc/tree-vect-stmts.c   2013-03-01 13:33:37.796121184 +0100
@@ -2269,7 +2269,7 @@ vect_create_vectorized_promotion_stmts (
   vec_tmp.quick_push (new_tmp2);
 }
 
-  vec_oprnds0->truncate (0);
+  vec_oprnds0->release ();
   *vec_oprnds0 = vec_tmp;
 }
 

Jakub

Re: [PATCH] Fix memory leak in vect_create_vectorized_promotion_stmts (PR middle-end/56461)

[Diego Novillo]

On Fri, Mar 1, 2013 at 3:10 PM, Jakub Jelinek  wrote:
> Hi!
>
> 4.7 did here:
>   VEC_free (tree, heap, *vec_oprnds0);
>   *vec_oprnds0 = vec_tmp;
> so vec_oprnds0->truncate (0) doesn't match that, and leaks memory.
>
> Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
> trunk?
>
> 2013-03-01  Jakub Jelinek  
>
> PR middle-end/56461
> * tree-vect-stmts.c (vect_create_vectorized_promotion_stmts): Call
> vec_oprnds0->release (); rather than vec_oprnds0->truncate (0)
> before overwriting it.

OK.


Diego.

Re: [PATCH] Fix libcpp PCH related memory leaks (PR middle-end/56461)

[Tom Tromey]

> "Jakub" == Jakub Jelinek  writes:

Jakub> 2013-03-01  Jakub Jelinek  
Jakub>  PR middle-end/56461
Jakub>  * files.c (_cpp_save_file_entries): Free result at the end.
Jakub>  * pch.c (cpp_string_free): New function.
Jakub>  (cpp_save_state): Use it in htab_create call.
Jakub>  (cpp_write_pch_deps): Free ss->defs.  Destroy ss->definedhash.

Looks good to me.  This is ok, thanks.

Tom

[ira-improv] merged with trunk.

[Vladimir Makarov]

The branch was merged with trunk @ r196387.

The branch was successfully bootstrapped on x86 and x86-64.

Committed as rev. 196391.

Re: [PATCH] Fix vectorizable_store memory leaks (PR middle-end/56461)

[Jeff Law]

On 03/01/2013 01:23 PM, Jakub Jelinek wrote:

Hi!

The first two hunks are similar issue to what I've posted for
vect_permute_load_chain two days ago, the remaining issue is that
if ncopies > 1, we'd leak the result_chain vector too.

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

2013-03-01  Jakub Jelinek  

PR middle-end/56461
* tree-vect-data-refs.c (vect_permute_store_chain): Avoid using copy
method on dr_chain and result_chain.
* tree-vect-stmts.c (vectorizable_store): Only call
result_chain.create if j == 0.

This is fine.  Please install.  Thanks.

Jeff

Re: [PATCH] Fix IRA memory leak (PR middle-end/56461)

[Jeff Law]

On 03/01/2013 01:21 PM, Jakub Jelinek wrote:

Hi!

When ira_destroy is called, often (always?) this is after
loop_optimize_finalize call and thus current_loops is NULL, which results in
only freeing ira_loop_nodes[0] and not ira_loop_nodes[1] and above (if any).

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

2013-03-01  Jakub Jelinek  

PR middle-end/56461
* ira-build.c (ira_loop_nodes_count): New variable.
(create_loop_tree_nodes): Initialize it.
(finish_loop_tree_nodes): Use it instead of looking at current_loops.

OK.

Jeff

Re: more distributions

[3dw4rd]

On 03/01/13, Ulrich Drepper wrote:
 
I have a few more distributions to be added. The triangle
distribution is the result of combining to uniform distributions and
therefore quite frequently used. The von Mises distribution (the
simple, 2D version) would be the first circular distribution.

The patch depends on the __math_constants patch.

Excellent!

I was looking at a paper: Modeling Data using Directional Distributions by 
Inderjit S. Dhillon and Suvrit Sra that looks like it would be very similar to 
your multi-variate normal distribution. These generalize von Mises to higher 
dimension. Is this your next target?

Thanks for the math constants too.

Ed
 

Fix PR/56490

[Xinliang David Li]

The following patch limit the depth for post-dom walk in the analysis
-- in the presence of complicated control flow, the analysis should
bail out sooner.

Bootstrapped on x86-64/linux. No regressions found.  OK for trunk?

thanks,

David



2013-03-01  Xinliang David Li  

* tree-ssa-uninit.c (compute_control_dep_chain): Limit post-dom
walk length.


 #define MAX_NUM_CHAINS 8
 #define MAX_CHAIN_LEN 5
+#define MAX_POSTDOM_CHECK 8

 /* Computes the control dependence chains (paths of edges)
for DEP_BB up to the dominating basic block BB (the head node of a
@@ -269,6 +270,7 @@ compute_control_dep_chain (basic_block b
   FOR_EACH_EDGE (e, ei, bb->succs)
 {
   basic_block cd_bb;
+  int post_dom_check = 0;
   if (e->flags & (EDGE_FAKE | EDGE_ABNORMAL))
 continue;

@@ -298,7 +300,8 @@ compute_control_dep_chain (basic_block b
 }

   cd_bb = find_pdom (cd_bb);
-  if (cd_bb == EXIT_BLOCK_PTR)
+  post_dom_check++;
+  if (cd_bb == EXIT_BLOCK_PTR || post_dom_check > MAX_POSTDOM_CHECK)
 break;
 }
   cur_cd_chain->pop ();

Re: [PATCH] Fix memory leak in tree_estimate_loop_size (PR middle-end/56461)

[Jeff Law]

On 03/01/2013 01:18 PM, Jakub Jelinek wrote:

Hi!

path vector has been only released when return false; later in the function,
but not in this case.  Bootstrapped/regtested on x86_64-linux and
i686-linux, ok for trunk?

2013-03-01  Jakub Jelinek  

PR middle-end/56461
* tree-ssa-loop-ivcanon.c (tree_estimate_loop_size): Release path
vector even when returning true.  Fix up function comment formatting.

OK.

Jeff

[patch] Add new enum to include/dwarf2.h

[Cary Coutant]

I'm checking in this patch to include/dwarf2.h, which was approved on binutils.

-cary


include/
* dwarf2.h (enum dwarf_sect): New enum type.


RCS file: /cvs/src/src/include/dwarf2.h,v
retrieving revision 1.31
retrieving revision 1.32
diff -u -r1.31 -r1.32
--- src/include/dwarf2.h 2012/11/11 22:37:19 1.31
+++ src/include/dwarf2.h 2013/03/01 19:23:33 1.32
@@ -376,6 +376,20 @@

 #define DW_EH_PE_indirect 0x80

+/* Codes for the debug sections in a dwarf package (.dwp) file.
+   Extensions for Fission.  See http://gcc.gnu.org/wiki/DebugFissionDWP.  */
+enum dwarf_sect
+  {
+DW_SECT_INFO = 1,
+DW_SECT_TYPES = 2,
+DW_SECT_ABBREV = 3,
+DW_SECT_LINE = 4,
+DW_SECT_LOC = 5,
+DW_SECT_STR_OFFSETS = 6,
+DW_SECT_MACINFO = 7,
+DW_SECT_MACRO = 8,
+DW_SECT_MAX = 8
+  };

 #ifdef __cplusplus
 extern "C" {

RE: PR target/52555: attribute optimize is overriding command line options

[Steve Ellcey]

Jakub and Aldy,

It looks like I am having another problem with this patch.  Jakubs earlier 
patch fixed things
for me when building my mips-mti-elf target but I just started building glibc 
in mips16 mode
with the latest compiler and I am running into this assert:

mktime.c:147:1: internal compiler error: in save_optabs_if_changed, at 
optabs.c:6221
 {
 ^
0x8198e5 save_optabs_if_changed(tree_node*)
/local/home/sellcey/gcc/linux_mips16/src/gcc/gcc/optabs.c:6221
0x4b090b decl_attributes(tree_node**, tree_node*, int)
/local/home/sellcey/gcc/linux_mips16/src/gcc/gcc/attribs.c:545
0x4cf728 start_function(c_declspecs*, c_declarator*, tree_node*)
/local/home/sellcey/gcc/linux_mips16/src/gcc/gcc/c/c-decl.c:7727
0x557114 c_common_parse_file()
/local/home/sellcey/gcc/linux_mips16/src/gcc/gcc/c-family/c-opts.c:1046

I looked at this_target_optabs and it appears to be a valid pointer but it is 
not pointing at
default_target_optabs addr and so I get the assert.  I am still trying to dig 
out more 
information and create a good test case.

Steve Ellcey
sell...@imgtec.com

Re: Fix PR/56490

[Jeff Law]

On 03/01/2013 04:12 PM, Xinliang David Li wrote:

The following patch limit the depth for post-dom walk in the analysis
-- in the presence of complicated control flow, the analysis should
bail out sooner.

Bootstrapped on x86-64/linux. No regressions found.  OK for trunk?

thanks,

David



2013-03-01  Xinliang David Li  

* tree-ssa-uninit.c (compute_control_dep_chain): Limit post-dom
walk length.


  #define MAX_NUM_CHAINS 8
  #define MAX_CHAIN_LEN 5
+#define MAX_POSTDOM_CHECK 8
I don't like the magic constants, but I dislike knobs that users won't 
understand even more.


OK.
Jeff

Re: [PATCH] Fix remainder of PR bootstrap/56258 on gcc-4_6-branch

[Gerald Pfeifer]

On Wed, 27 Feb 2013, Jack Howarth wrote:
>No, these are additional instances of the @item instead of @itemx change
> which exist in gcc-4_6-branch and gcc-4_7-branch but not gcc trunk. There
> is one extra instance in gcc-4_7-branch compared to gcc-4_6-branch...

Ahh, sorry for missing that.  And thanks for fixing those!

Gerald

Re: [PATCH][www] Add loop case to non-bugs in bugs.html

[Gerald Pfeifer]

On Mon, 18 Feb 2013, Richard Biener wrote:
>>   Before reporting that GCC compiles your code incorrectly, compile it
>>   with gcc -Wall -Wextra and see whether this shows anything
>>   wrong with your code.  Similarly, if compiling with
>>   -fno-strict-aliasing -fwrapv makes a difference, your code
>>   probably is not correct.
>> 
>> Should I add  -fno-aggressive-loop-optimizations  to the list in the
>> second sentence?
> Yes please.

Done thusly.

Gerald

Index: index.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/bugs/index.html,v
retrieving revision 1.110
diff -u -3 -p -r1.110 index.html
--- index.html  8 Feb 2013 15:55:03 -   1.110
+++ index.html  2 Mar 2013 01:22:47 -
@@ -54,8 +54,8 @@ try a current release or develo
 Before reporting that GCC compiles your code incorrectly, compile it
 with gcc -Wall -Wextra and see whether this shows anything
 wrong with your code.  Similarly, if compiling with
--fno-strict-aliasing -fwrapv makes a difference, your code
-probably is not correct.
+-fno-strict-aliasing -fwrapv -fno-aggressive-loop-optimizations
+makes a difference, your code probably is not correct.
 
 Summarized bug reporting instructions
 

Re: more distributions

[Ulrich Drepper]

On Fri, Mar 1, 2013 at 5:55 PM,  <3dw...@verizon.net> wrote:
> I was looking at a paper: Modeling Data using Directional Distributions by 
> Inderjit S. Dhillon and Suvrit Sra that looks
> like it would be very similar to your multi-variate normal distribution. 
> These generalize von Mises to higher dimension.
> Is this your next target?

von Mises-Fisher?  I might indeed look at it.  The relationship to the
MV Normal distribution is only marginal, though.  MV Normal is not a
circular distribution.

I have a whole bunch of optimization patches which aren't quite done
yet.  I might pick those up first again.