RE: [PATCH,i386] FSGSBASE for AMD bdver3

[Gopalasubramanian, Ganesh]

Thanks Uros!

I think you mean the amdfam10 ISA mismatch between march=native and 
march=amdfam10.
The below patch fills the gap.

"make -k check" passes.

Regards
Ganesh

2013-05-07  Ganesh Gopalasubramanian  

* config/i386/i386.c (processor_alias_table): Mismatch in ISAs
Between march=native and march=amdfam10 is fixed.

--- ./wkcpy/gcc-4.9.0/gcc/config/i386/i386.c  2013-02-21 16:27:10.0 
+0530
+++ ./source/gcc-4.9.0/gcc/config/i386/i386.c   2013-10-21 22:20:28.0 
+0530
@@ -2964,7 +2964,8 @@
| PTA_SSE2 | PTA_NO_SAHF},
   {"amdfam10", PROCESSOR_AMDFAM10, CPU_AMDFAM10,
PTA_64BIT | PTA_MMX | PTA_3DNOW | PTA_3DNOW_A | PTA_SSE
-   | PTA_SSE2 | PTA_SSE3 | PTA_SSE4A | PTA_CX16 | PTA_ABM},
+   | PTA_SSE2 | PTA_SSE3 | PTA_SSE4A | PTA_CX16 | PTA_ABM
+   | PTA_FXSR | PTA_PRFCHW},
   {"barcelona", PROCESSOR_AMDFAM10, CPU_AMDFAM10,
PTA_64BIT | PTA_MMX | PTA_3DNOW | PTA_3DNOW_A | PTA_SSE
| PTA_SSE2 | PTA_SSE3 | PTA_SSE4A | PTA_CX16 | PTA_ABM},


-Original Message-
From: Uros Bizjak [mailto:ubiz...@gmail.com] 
Sent: Monday, May 13, 2013 5:50 PM
To: Gopalasubramanian, Ganesh
Cc: gcc-patches@gcc.gnu.org
Subject: Re: [PATCH,i386] FSGSBASE for AMD bdver3

On Mon, May 13, 2013 at 1:54 PM, Gopalasubramanian, Ganesh 
 wrote:

> The patch enables FSGSBASE instruction generation for AMD bdver3 
> architectures.
>
> "make -k check" passes.
>
> Is it OK for upstream?

OK. Please also check for missing PTA_PRFCHW and PTA_FXSR for AMD processors in 
processor_alias_table.

Thanks,
Uros.

Re: [PATCH,i386] FSGSBASE for AMD bdver3

[Uros Bizjak]

On Tue, May 14, 2013 at 9:26 AM, Gopalasubramanian, Ganesh
 wrote:

> I think you mean the amdfam10 ISA mismatch between march=native and 
> march=amdfam10.
> The below patch fills the gap.

Yes, but please also review other AMD processor entries that possibly
miss these two flags.

Uros.

Re: Using GS for TLS on x86-64 for target RDOS

[Uros Bizjak]

Hello!

> I would need a way to use GS segment register instead of FS for x86-64 for 
> target RDOS since
> RDOS cannot use FS for TLS. It seems like the code related to this is 
> concentrated to two
> different places:

> Especially the second reference would become hard-to-read if more 
> conditionals are added to it.

> Perhaps the code could be changed to something like this:

> #ifdef TARGET_RDOS
> #define GET_TLS_SEG_REG  SEG_GS
> #else
> #define GET_TLS_SEG_REG TARGET_64BIT ? SEG_FS : SEG_GS
> #endif

> Thoughts?

I'd propose to introduce:

a) #define DEFAULT_TLS_SEG_REG in i386.h to SEG_GS

b) #undef and #define DEFAULT_TLS_SEG_REG in x86-64.h to SEG_FS

c) #undef and #define DEFAULT_TLS_SEG_REG in rdos.h to SEG_GS

Then use DEFAULT_TLS_SEG_REG everywhere.

This will avoid compile-time and runtime checks. Please note that
sequence of include files gets defined in config.gcc.

Uros.

Re: sparc64*-*-rtems* should not define __svr4__

[Eric Botcazou]

> sparc64*-*-rtems* ends up with __svr4__ defined. The attached
> patch corrects that.

Let's remove the FIXME instead.  Applied to mainline.


2013-05-14  Eric Botcazou  

* config/sparc/sp64-elf.h (CPP_SUBTARGET_SPEC): Delete.
* config/sparc/openbsd64.h (CPP_SUBTARGET_SPEC): Likewise.


-- 
Eric BotcazouIndex: config/sparc/sp64-elf.h
===
--- config/sparc/sp64-elf.h	(revision 198799)
+++ config/sparc/sp64-elf.h	(working copy)
@@ -30,10 +30,6 @@ along with GCC; see the file COPYING3.
 /* Don't assume anything about the header files.  */
 #define NO_IMPLICIT_EXTERN_C
 
-/* __svr4__ is used by the C library (FIXME) */
-#undef CPP_SUBTARGET_SPEC
-#define CPP_SUBTARGET_SPEC "-D__svr4__"
-
 #undef ASM_SPEC
 #define ASM_SPEC "\
 -s %{fpic|fPIC|fpie|fPIE:-K PIC} \
Index: config/sparc/openbsd64.h
===
--- config/sparc/openbsd64.h	(revision 198799)
+++ config/sparc/openbsd64.h	(working copy)
@@ -41,9 +41,6 @@ along with GCC; see the file COPYING3.
 }		\
   while (0)
 
-#undef CPP_SUBTARGET_SPEC
-#define CPP_SUBTARGET_SPEC ""
-
 /* Inherited from sp64-elf.  */
 #undef NO_IMPLICIT_EXTERN_C
 

Re: [PATCH] Improve rotation by mode bitsize - 1 (take 2)

[Richard Biener]

On Mon, 13 May 2013, Jakub Jelinek wrote:

> On Fri, May 10, 2013 at 07:15:38PM +0200, Jan Hubicka wrote:
> > It seems to me that it is not different from normalizing reg-10 into 
> > reg+(-10)
> > we do for years (and for good reason).  It is still target preference when 
> > use
> > add and when sub to perform the arithmetic, but it makes sense to keep 
> > single
> > canonical form of the expression both in RTL and Gimple.
> > 
> > For example we may want to be able to prove that 
> >   (rotate reg 31) == (rotatert reg 1)
> > is true or
> >   (rotate reg 30) == (rotatert reg 2)
> > is also true or cross jump both variants into one instruction.
> 
> Ok, this patch reverts my earlier patch and does the canonicalization, for
> now for RTL only.  Bootstrapped/regtested on x86_64-linux and i686-linux, ok
> for trunk?

Ok.

Thanks,
Richard.

> 2013-05-13  Jakub Jelinek  
> 
>   * expmed.c (expand_shift_1): Canonicalize rotates by
>   constant bitsize / 2 to bitsize - 1.
>   * simplify-rt.x (simplify_binary_operation_1)case ROTATERT>: Likewise.
> 
>   Revert:
>   2013-05-10  Jakub Jelinek  
> 
>   * config/i386/i386.md (rotateinv): New code attr.
>   (*3_1, *si3_1_zext,
>   *qi3_1_slp): Emit rorl %eax instead of
>   roll $31, %eax, etc.
> 
> --- gcc/expmed.c.jj   2013-05-13 13:03:31.0 +0200
> +++ gcc/expmed.c  2013-05-13 15:22:39.456194286 +0200
> @@ -2122,6 +2122,20 @@ expand_shift_1 (enum tree_code code, enu
>   op1 = SUBREG_REG (op1);
>  }
>  
> +  /* Canonicalize rotates by constant amount.  If op1 is bitsize / 2,
> + prefer left rotation, if op1 is from bitsize / 2 + 1 to
> + bitsize - 1, use other direction of rotate with 1 .. bitsize / 2 - 1
> + amount instead.  */
> +  if (rotate
> +  && CONST_INT_P (op1)
> +  && IN_RANGE (INTVAL (op1), GET_MODE_BITSIZE (mode) / 2 + left,
> +GET_MODE_BITSIZE (mode) - 1))
> +{
> +  op1 = GEN_INT (GET_MODE_BITSIZE (mode) - INTVAL (op1));
> +  left = !left;
> +  code = left ? LROTATE_EXPR : RROTATE_EXPR;
> +}
> +
>if (op1 == const0_rtx)
>  return shifted;
>  
> --- gcc/simplify-rtx.c.jj 2013-05-02 12:42:25.0 +0200
> +++ gcc/simplify-rtx.c2013-05-13 15:48:31.171182716 +0200
> @@ -3250,6 +3250,18 @@ simplify_binary_operation_1 (enum rtx_co
>  
>  case ROTATERT:
>  case ROTATE:
> +  /* Canonicalize rotates by constant amount.  If op1 is bitsize / 2,
> +  prefer left rotation, if op1 is from bitsize / 2 + 1 to
> +  bitsize - 1, use other direction of rotate with 1 .. bitsize / 2 - 1
> +  amount instead.  */
> +  if (CONST_INT_P (trueop1)
> +   && IN_RANGE (INTVAL (trueop1),
> +GET_MODE_BITSIZE (mode) / 2 + (code == ROTATE),
> +GET_MODE_BITSIZE (mode) - 1))
> + return simplify_gen_binary (code == ROTATE ? ROTATERT : ROTATE,
> + mode, op0, GEN_INT (GET_MODE_BITSIZE (mode)
> + - INTVAL (trueop1)));
> +  /* FALLTHRU */
>  case ASHIFTRT:
>if (trueop1 == CONST0_RTX (mode))
>   return op0;
> --- gcc/config/i386/i386.md.jj2013-05-13 09:44:51.675494325 +0200
> +++ gcc/config/i386/i386.md   2013-05-13 15:09:37.461637593 +0200
> @@ -762,9 +762,6 @@ (define_code_attr rotate_insn [(rotate "
>  ;; Base name for insn mnemonic.
>  (define_code_attr rotate [(rotate "rol") (rotatert "ror")])
>  
> -;; Base name for insn mnemonic of rotation in the other direction.
> -(define_code_attr rotateinv [(rotate "ror") (rotatert "rol")])
> -
>  ;; Mapping of abs neg operators
>  (define_code_iterator absneg [abs neg])
>  
> @@ -9755,15 +9752,11 @@ (define_insn "*3_1"
>return "#";
>  
>  default:
> -  if (TARGET_SHIFT1 || optimize_function_for_size_p (cfun))
> - {
> -   if (operands[2] == const1_rtx)
> - return "{}\t%0";
> -   if (CONST_INT_P (operands[2])
> -   && INTVAL (operands[2]) == GET_MODE_BITSIZE (mode) - 1)
> - return "{}\t%0";
> - }
> -  return "{}\t{%2, %0|%0, %2}";
> +  if (operands[2] == const1_rtx
> +   && (TARGET_SHIFT1 || optimize_function_for_size_p (cfun)))
> + return "{}\t%0";
> +  else
> + return "{}\t{%2, %0|%0, %2}";
>  }
>  }
>[(set_attr "isa" "*,bmi2")
> @@ -9825,14 +9818,11 @@ (define_insn "*si3_1_zext"
>return "#";
>  
>  default:
> -  if (TARGET_SHIFT1 || optimize_function_for_size_p (cfun))
> - {
> -   if (operands[2] == const1_rtx)
> - return "{l}\t%k0";
> -   if (CONST_INT_P (operands[2]) && INTVAL (operands[2]) == 31)
> - return "{l}\t%k0";
> - }
> -  return "{l}\t{%2, %k0|%k0, %2}";
> +  if (operands[2] == const1_rtx
> +   && (TARGET_SHIFT1 || optimize_function_for_size_p (cfun)))
> + return "{l}\t%k0";
> +  else
> + return "{l}\t{%2, %k0|%k0, %2}";
>  }
>  }
>[(set_attr "isa"

Re: [PATCH] Fix PR57235

[Richard Biener]

On Mon, 13 May 2013, Richard Biener wrote:

> 
> This fixes a virtual SSA updating problem with sinking clobbers.
> Namely when sinking into a block with multiple predecessors and
> no virtual use we lack a convenient PHI node that serves as a
> merge of the virtual operands from the predecessors.  The following
> patch gives up sinking clobbers in this case (alternatively
> we can remove all clobbers).  Any preference here?  I'm wondering
> when sinking a clobber into a block with multiple preds is good.

After discussion on IRC I re-instantiated the virtual operand
renaming case to recover in this case.  We'll sometimes rename
vops without good reason though as the CFG is not cleaned up
during the sinking and thus SSA form is not up-to-date.

Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.

Richard.

2013-05-13  Richard Biener  

PR middle-end/57235
* tree-eh.c (sink_clobbers): Give up for successors with
multiple predecessors and no virtual uses.

* g++.dg/torture/pr57235.C: New testcase.

Index: gcc/tree-eh.c
===
--- gcc/tree-eh.c   (revision 198815)
+++ gcc/tree-eh.c   (working copy)
@@ -3312,6 +3312,7 @@ sink_clobbers (basic_block bb)
   gimple_stmt_iterator gsi, dgsi;
   basic_block succbb;
   bool any_clobbers = false;
+  unsigned todo = 0;
 
   /* Only optimize if BB has a single EH successor and
  all predecessor edges are EH too.  */
@@ -3410,9 +3411,22 @@ sink_clobbers (basic_block bb)
  SET_USE (PHI_ARG_DEF_PTR_FROM_EDGE (vphi, succe), gimple_vuse (stmt));
  SET_USE (gimple_vuse_op (stmt), vuse);
}
+  /* If there isn't a single predecessor but no virtual PHI node
+ arrange for virtual operands to be renamed.  */
+  else if (gimple_vuse_op (stmt) != NULL_USE_OPERAND_P
+  && !single_pred_p (succbb))
+   {
+ /* In this case there will be no use of the VDEF of this stmt.
+???  Unless this is a secondary opportunity and we have not
+removed unreachable blocks yet, so we cannot assert this.
+Which also means we will end up renaming too many times.  */
+ SET_USE (gimple_vuse_op (stmt), gimple_vop (cfun));
+ mark_virtual_operands_for_renaming (cfun);
+ todo |= TODO_update_ssa_only_virtuals;
+   }
 }
 
-  return 0;
+  return todo;
 }
 
 /* At the end of inlining, we can lower EH_DISPATCH.  Return true when 
Index: gcc/testsuite/g++.dg/torture/pr57235.C
===
--- gcc/testsuite/g++.dg/torture/pr57235.C  (revision 0)
+++ gcc/testsuite/g++.dg/torture/pr57235.C  (working copy)
@@ -0,0 +1,156 @@
+// { dg-do compile }
+
+namespace std
+{
+  template < class _Elem > struct char_traits
+  {
+  };
+  struct _Container_base
+  {
+  };
+template < class _Ty > struct _Allocator_base
+  {
+  };
+template < class _Ty > class allocator:public _Allocator_base < _Ty >
+  {
+  };
+  class _String_base:public _Container_base
+  {
+  };
+template < class _Ty, class _Alloc > class _String_val:public _String_base
+  {
+  };
+template < class _Elem, class _Traits, class _Ax > class basic_string:public 
_String_val < _Elem,
+_Ax
+>
+  {
+  public:typedef basic_string < _Elem, _Traits, _Ax > _Myt;
+typedef _String_val < _Elem, _Ax > _Mybase;
+basic_string (const _Elem * _Ptr):_Mybase ()
+{
+}
+  };
+  typedef basic_string < char, char_traits < char >,
+allocator < char > >string;
+}
+
+
+namespace google
+{
+  namespace protobuf
+  {
+namespace internal
+{
+  template < class C > class scoped_ptr
+  {
+  public:typedef C element_type;
+  explicit scoped_ptr (C * p = __null):ptr_ (p)
+   {
+   }
+~scoped_ptr ()
+   {
+ delete ptr_;
+   }
+   C *get () const
+   {
+ return ptr_;
+   }
+  private:  C * ptr_;
+  };
+}
+using internal::scoped_ptr;
+enum LogLevel
+{
+  LOGLEVEL_INFO, LOGLEVEL_WARNING, LOGLEVEL_ERROR, LOGLEVEL_FATAL,
+   LOGLEVEL_DFATAL = LOGLEVEL_ERROR
+};
+namespace internal
+{
+  class LogMessage
+  {
+  public:LogMessage (LogLevel level, const char *filename,
+   int line);
+~LogMessage ();
+ LogMessage & operator<< (const std::string & value);
+  };
+  class LogFinisher
+  {
+  public:void operator= (LogMessage & other);
+  };
+}
+using namespace std;
+class Descriptor
+{
+};
+class FieldDescriptor
+{
+public:
+  const Descriptor *message_type () const;
+  string DebugString () const;
+};
+class MessageLite
+{
+};
+class Message:public MessageLite
+{
+public:inline Message ()
+  {
+  }
+  virtual ~ Message ();
+  virtual Message *New () const = 0;
+};
+class MessageFactory
+{

Re: GCC does not support *mmintrin.h with function specific opts

[Jakub Jelinek]

On Tue, May 14, 2013 at 08:58:55AM +0200, Uros Bizjak wrote:
> I think that the option should be named -mtarget-builtins.

There shouldn't be an option for it at all.  If constructing the builtins is
slow (it is), we should just create them lazily, the
*builtin_decl_{explicit,implicit}* APIs were a first step for that, plus
we should build some gperf table of all the generic and all the target
builtins and record prefixes used to find them (__builtin_, __sync_,
__atomic_, what else?), then just teach FE that if they are looking up
a symbol prefixed with one of these, they should also look it up
in the perfect hash table and if found there, call some function to
construct the builtin.  Of course, this isn't a prerequisite of the
changes you are looking for, but introducing an option that hopefully will
be completely useless in a few months is just a bad idea.

> Since HJ is OK with this user-visible change, the patch is OK for
> mainline (with eventually renamed option). We also have an option to
> switch this new functionality off, and we are early enough in the
> development cycle to find out if anything is fundamentaly broken with
> this approach.
> 
> BTW, does this patch address the request in PR57202?

I'm strongly against the patch in its current form, it is a hack rather
than a solution.  I don't see how it could be properly tested, when say
immintrin.h and x86intrin.h is still full of code like:
#ifdef __AVX__
#include 
#endif
so when you just
#include 
rather than the few headers that were tested, you are out of luck.

The right solution is really IMNSHO something along the lines of:
#ifndef __AVX__
#pragma GCC push_options
#pragma GCC target("avx")
#define __AVXINTRIN_H_POP_OPTIONS__
#endif
...
#ifdef __AVXINTRIN_H_POP_OPTIONS__
#pragma GCC pop_options
#undef __AVXINTRIN_H_POP_OPTIONS__
#endif

around the headers.  As can be seen on say -O2 -mno-avx:
#ifndef __AVX__
#pragma GCC push_options
#pragma GCC target("avx")
#define __DISABLE_AVX__
#endif
typedef float __v8sf __attribute__((vector_size (32)));
extern __v8sf a, b;
extern __inline int __attribute__((__gnu_inline__, __always_inline__, 
__artificial__)) bar (int x) { a = b + 1.0f; return x + 1; }
#ifdef __DISABLE_AVX__
#pragma GCC pop_options
#undef __DISABLE_AVX__
#endif
int __attribute__((target ("avx2"))) avx2 (int x) { return bar (x) + bar (x + 
1); }
int __attribute__((target ("avx"))) avx (int x) { return bar (x) + bar (x + 1); 
}
int __attribute__((target ("xop"))) xop (int x) { return bar (x) + bar (x + 1); 
}
int __attribute__((target ("sse2"))) sse2 (int x) { return bar (x) + bar (x + 
1); }
int nothing (int x) { return bar (x) + bar (x + 1); }
the inliner happily inlines the avx target function into avx/avx2/xop
targetted functions (correct), inlines it even into sse2 (something that
should be fixed not to), and doesn't inline into nothing (IMHO correct, we
want an error in that case, one shouldn't use avx intrinsics in say sse2
only targetted function (unless -mavx is used on command line, i.e. the
check should always be if the caller's target set is equal or superset of
callee's target set).

When trying with -O2 -mno-avx:
#ifndef __AVX__
#pragma GCC push_options
#pragma GCC target("avx")
#define __DISABLE_AVX__
#endif
typedef float __v8sf __attribute__ ((__vector_size__ (32)));
typedef float __m256 __attribute__ ((__vector_size__ (32), __may_alias__));
extern __inline __m256 __attribute__((__gnu_inline__, __always_inline__, 
__artificial__))
_mm256_and_ps (__m256 __A, __m256 __B) { return (__m256) 
__builtin_ia32_andps256 ((__v8sf)__A, (__v8sf)__B); }
#ifdef __DISABLE_AVX__
#pragma GCC pop_options
#undef __DISABLE_AVX__
#endif
__m256 a, b, c;
void __attribute__((target ("avx")))
foo (void)
{
  a = _mm256_and_ps (b, c);
}
we get bogus errors and ICE:
tty2.c: In function '_mm256_and_ps':
tty2.c:9:1: note: The ABI for passing parameters with 32-byte alignment has 
changed in GCC 4.6
tty2.c: In function 'foo':
tty2.c:9:82: error: '__builtin_ia32_andps256' needs isa option -m32
tty2.c:9:82: internal compiler error: in emit_move_insn, at expr.c:3486
0x77a3d2 emit_move_insn(rtx_def*, rtx_def*)
../../gcc/expr.c:3485
(I have added "1 ||" instead of your generate_builtins into i386.c
(def_builtin)), that just shows that target attribute/pragma support still
has very severe issues that need to be fixed, instead of papered around.

Note, we ICE on:
#pragma GCC target ("mavx")
That should be fixed too.

Jakub

Re: cfgexpand.c patch for [was new port: msp430-elf]

[Richard Biener]

On Mon, May 13, 2013 at 7:23 PM, DJ Delorie  wrote:
>
>> Can you add that (partial int modes have fewer bits than int modes)
>> as verification to genmodes.c:make_partial_integer_mode?
>
> I could, but it would be a no-op for PARTIAL_INT_MODE()
>
>> I wonder if this should not use GET_MODE_PRECISION - after all it is
>> the precision that determines whether we have to extend / truncate?
>> Or is precision a so much unused term on RTL that this would cause
>> problems?
>
> The problem is, the precision of PSImode *is* the same as SImode,
> if you just use PARTIAL_INT_MODE() in *-modes.def

How can you then ever "truncate" from SImode to PSImode?  That is,
currently we have

  if (GET_MODE_BITSIZE (GET_MODE (op0)) < GET_MODE_BITSIZE
(GET_MODE (op1)))
op1 = simplify_gen_unary (TRUNCATE, GET_MODE (op0), op1,
  GET_MODE (op1));
  else
/* We always sign-extend, regardless of the signedness of
   the operand, because the operand is always unsigned
   here even if the original C expression is signed.  */
op1 = simplify_gen_unary (SIGN_EXTEND, GET_MODE (op0), op1,
  GET_MODE (op1));

but the case of same precision/bitsize is not handled here.  So, shouldn't it
be then

   if (GET_MODE_BITSIZE (GET_MODE (op0)) == GET_MODE_BITSIZE
(GET_MODE (op1)))
 op1 = convert_move (GET_MODE (op0), op1);
   else if (

?

That said, special casing PARTIAL_INT_MODEs anywhere looks bogus to me.
Which might mean that PARTIAL_INT_MODEs are bogus... what are they
useful for if they do not even have a precision and share the same bitsize
as their base mode?  Do they even have a "precision"?

> grep PARTIAL_INT_MODE config/*/*.def
config/bfin/bfin-modes.def:PARTIAL_INT_MODE (DI);
config/m32c/m32c-modes.def:PARTIAL_INT_MODE (SI);
config/rs6000/rs6000-modes.def:PARTIAL_INT_MODE (TI);
config/sh/sh-modes.def:PARTIAL_INT_MODE (SI);
config/sh/sh-modes.def:PARTIAL_INT_MODE (DI);

so it shouldn't be difficult to fix that precision thing by adjusting genmodes.c
and the few occurences above?  Make it

config/bfin/bfin-modes.def:PARTIAL_INT_MODE (DI, 40);

btw, what's the relation to fractional int modes?

Richard.

Re: section anchors and weak hidden symbols

[Jan Hubicka]

> On 05/13/13 14:09, Jan Hubicka wrote:
> >>Index: varasm.c
> >>===
> 
> >I think DECL_COMDAT is not what you really want to return true for.  So 
> >perhaps
> >you really want (TREE_PUBLIC (decl) && decl_binds_to_current_def_p)?
> 
> Like this?  This too fixes the problem, tested on powerpc-linux target.

Yes, it looks good to me :)

Honza

Re: [patch] struct resources: remove unch_memory member

[Eric Botcazou]

> This unch_memory in struct resources is a left-over from
> RTX_UNCHANGING_P, but it looks like the change-over to MEM_READONLY_P
> was done incorrectly: The resource_conflicts_p code now reports
> conflicts for insns reading readonly memory and insns reading "normal"
> memory or no memory at all.

Does it really?  One would need to have a SET of a MEM_READONLY_P MEM and this 
isn't supposed to happen (unlike with RTX_UNCHANGING_P).  That being said, the 
patch is a good cleanup.

> Spotted by checking why reorg.c failed to fill some slots that my
> sched-deps based delay slot scheduler managed to fill.

I've been in the business lately so I'm interested in all things reorg.c. :-)

> Bootstrapped&tested on sparc64-unknown-linux-gnu. OK for trunk?

Fine with me.

-- 
Eric Botcazou

Re: [PATCH] New switch optimization pass (PR tree-optimization/54742)

[Richard Biener]

On Mon, May 13, 2013 at 10:28 PM, Jeff Law  wrote:
> On 05/13/2013 02:16 PM, Steve Ellcey wrote:
>>
>> Here is the latest version of my SSA optimization pass to do the switch
>> statement optimization described in PR 54742 (core_state_transition from
>> coremark).
>>
>> I have tested this optimization with a x86 bootstrap and GCC test run
>> with no errors and tested the MIPS cross compiler with no errors.
>> Because of that I decided to submit it as a statically linked
>> optimization pass instead of a dynamically loaded one, though I did keep
>> the ifdefs for using it as a dynamic pass in the code.  They could be
>> removed if this patch is approved as a statically linked pass.  Also,
>> while this patch shows the optimization only being turned on with the
>> -ftree-switch-shortcut flag, my bootstrap and testing had it turned on
>> for all -O2 optimizations in order to maximize the testing.
>> We may want to turn this on for -O3 and/or for
>> -fexpensive-optimizations.
>>
>> I had to make one change to dominance.c in order to avoid some compiler
>> aborts where it was dereferencing a null pointer.  I believe this was
>> happening because I am calling gimple_duplicate_sese_region with regions
>> that are not really SESE.  Because I am doing this, I regenerate the cfg
>> and SSA information after each call, but I also had to change
>> iterate_fix_dominators to fix the abort.  Another way we might want to
>> fix this would be to pass a flag to gimple_duplicate_sese_region that
>> tells it whether or not we want it to recalculate the dominance
>> information at all.  If set to false, it would assume the caller will
>> take care of it.
>>
>> Opinions?  OK to checkin?
>>
>> Steve Ellcey
>> sell...@imgtec.com
>>
>>
>> 2013-05-13  Steve Ellcey  
>>
>> PR tree-optimization/54742
>> * Makefile.in (OBJS): Add tree-switch-shortcut.o.
>> * common.opt (ftree-switch-shortcut): New.
>> * dominance.c (iterate_fix_dominators): Add null check.
>> * params.def (PARAM_MAX_SWITCH_INSNS): New.
>> (PARAM_MAX_SWITCH_PATHS): New.
>> * passes.c (init_optimization_passes): Add pass_switch_shortcut.
>> * timevar.def (TV_SWITCH_SHORTCUT): New.
>> * tree-pass.c (pass_switch_shortcut): New.
>> * tree-switch-shortcut.c: New file.
>
> I was looking at this last week (stuck for hours on tarmac at BWI).
>
> I think we should fix this in the threader rather than doing a special
> purpose pass.  This is primarily because we get it for free if we address
> one limitation in the threader (some of the other issues I was concerned
> about don't apply).
>
> Specifically if we look at thread_around_empty_block we have:
>
>   /* This block must have a single predecessor (E->dest).  */
>   if (!single_pred_p (bb))
> return NULL;
>
>   /* This block must have more than one successor.  */
>   if (single_succ_p (bb))
> return NULL;
>
>   /* This block can have no PHI nodes.  This is overly conservative.  */
>   if (!gsi_end_p (gsi_start_phis (bb)))
> return NULL;
>
>
> The test that the block have > 1 successor and no PHI nodes are the keys.
>
> ;;   basic block 17, loop depth 1
> ;;pred:   9
> ;;13
> ;;16
> ;;15
> ;;4
> ;;12
> ;;7
> ;;14
> ;;10
> ;;5
> ;;6
> ;;8
> ;;11
>   # state_1 = PHI <0(9), 2(13), 3(16), 3(15), state_36(4), 1(12), 0(7),
> 2(14), 1(10), 1(5), 0(6), 2(8), 3(11)>
>   # .MEM_4 = PHI <.MEM_29(9), .MEM_20(13), .MEM_24(16), .MEM_29(15),
> .MEM_29(4), .MEM_29(12), .MEM_12(7), .MEM_29(14), .MEM_16(10), .MEM_29(5),
> .MEM_29(6), .MEM_29(8), .MEM_29(11)>
> :
>   str_25 = str_37 + 1;
>   # VUSE <.MEM_4>
>   _8 = MEM[base: str_25, offset: 0B];
>   if (_8 != 0)
> goto ;
>   else
> goto ;
> ;;succ:   18
> ;;19
>
> ;;   basic block 18, loop depth 1
> ;;pred:   17
>   goto ;
> ;;succ:   4
>
>
>
> bb will be block #18.  In theory we just do
> if (single_succ_p (bb))
>   bb = single_succ_edge (bb)->dest;
>
> And allow PHI nodes in this specific instance.
>
> That's enough to allow existing code to identify the potential jump
> threading candidates -- and more importantly, it's much more general.
>
>
>
> The updater needs copy bb17 & bb4.  bb17' will transfer to bb4' which will
> directly transfer to the destination of the switch.
>
> The advantage of doing this in the threader is it'll help more than just the
> switch statement case.  It's probably highly likely that we're missing cases
> to thread through empty blocks with PHIs.
>
> I've started cobbling together some of the updating code.  So far it doesn't
> look too terrible.

I agree - thanks for looking at this!

Richard.

>
> Jeff
>

Fix weakrefs and LTO

[Jan Hubicka]

Hi,
this patch fixes with weakrefs seen on building latest firefox.  The problem is
that currently we handle weakrefs as external variables/functions that makes us
to merge them.  In firefox there are two weakrefs with different aliases used
in different units.  This is correct and well defined even if weird use.

This patch adds special cases for weakrefs into lto-symtab and lto-partition
to make them go through correctly.  I also fixed two fallouts of my previous
change that reproduce on firefox (and the testcase addded).

For lto-partition the weakrefs with defined target are even bit more special
animals, since they needs to be duplicated into every unit that use them.

It is ugly to special case wekarefs all around.  My plan is to cleanup whole
area, but it seems that the correctness issue deserve to be fixed first.

I have bootstrapped/regtested x86_64-linux and tested mozilla build.  Will
commit it tonight if there are no complains.

Honza

PR lto/57038
PR lto/47375
* lto-symtab.c (lto_symtab_symbol_p): Add external symbol; weakrefs are
not external.
(lto_symtab_merge_decls): Fix thinko when dealing with non-lto_symtab 
decls.
(lto_symtab_merge_cgraph_nodes): Use lto_symtab_symbol_p.
(lto_symtab_prevailing_decl): Get int sync with lto_symtab_symbol_p.
* varpool.c (dump_varpool_node): Dump more flags.

* lto-partition.c (get_symbol_class): Fix weakrefs.
(lto_balanced_map): Fix weakrefs.
(privatize_symbol_name): Remove unnecesary label.
(rename_statics): Handle weakrefs as statics.

* gcc.dg/lto/attr-weakref-1_0.c: New testcase.
* gcc.dg/lto/attr-weakref-1_1.c: New testcase.
* gcc.dg/lto/attr-weakref-1_2.c: New testcase.
Index: lto-symtab.c
===
*** lto-symtab.c(revision 198824)
--- lto-symtab.c(working copy)
*** lto_symtab_resolve_replaceable_p (symtab
*** 227,239 
  }
  
  /* Return true, if the symbol E should be resolved by lto-symtab.
!Those are all real symbols that are not static (we handle renaming
!of static later in partitioning).  */
  
  static bool
  lto_symtab_symbol_p (symtab_node e)
  {
!   if (!TREE_PUBLIC (e->symbol.decl))
  return false;
return symtab_real_symbol_p (e);
  }
--- 227,242 
  }
  
  /* Return true, if the symbol E should be resolved by lto-symtab.
!Those are all external symbols and all real symbols that are not static (we
!handle renaming of static later in partitioning).  */
  
  static bool
  lto_symtab_symbol_p (symtab_node e)
  {
!   if (!TREE_PUBLIC (e->symbol.decl) && !DECL_EXTERNAL (e->symbol.decl))
! return false;
!   /* weakrefs are really static variables that are made external by a hack.  
*/
!   if (lookup_attribute ("weakref", DECL_ATTRIBUTES (e->symbol.decl)))
  return false;
return symtab_real_symbol_p (e);
  }
*** lto_symtab_merge_decls (void)
*** 528,537 
symtab_initialize_asm_name_hash ();
  
FOR_EACH_SYMBOL (node)
! if (TREE_PUBLIC (node->symbol.decl)
!   && node->symbol.next_sharing_asm_name
!   && !node->symbol.previous_sharing_asm_name)
! lto_symtab_merge_decls_1 (node);
  }
  
  /* Helper to process the decl chain for the symbol table entry *SLOT.  */
--- 531,549 
symtab_initialize_asm_name_hash ();
  
FOR_EACH_SYMBOL (node)
! if (lto_symtab_symbol_p (node)
!   && node->symbol.next_sharing_asm_name)
!   {
! symtab_node n;
! 
!   /* To avoid duplicated work, see if this is first real symbol in the
!  chain.  */
!   for (n = node->symbol.previous_sharing_asm_name;
!n && !lto_symtab_symbol_p (n); n = 
n->symbol.previous_sharing_asm_name)
! ;
!   if (!n)
!   lto_symtab_merge_decls_1 (node);
!   }
  }
  
  /* Helper to process the decl chain for the symbol table entry *SLOT.  */
*** lto_symtab_merge_cgraph_nodes (void)
*** 574,580 
  
if (!flag_ltrans)
  FOR_EACH_SYMBOL (node)
!   if (TREE_PUBLIC (node->symbol.decl)
  && node->symbol.next_sharing_asm_name
  && !node->symbol.previous_sharing_asm_name)
  lto_symtab_merge_cgraph_nodes_1 (node);
--- 586,592 
  
if (!flag_ltrans)
  FOR_EACH_SYMBOL (node)
!   if (lto_symtab_symbol_p (node)
  && node->symbol.next_sharing_asm_name
  && !node->symbol.previous_sharing_asm_name)
  lto_symtab_merge_cgraph_nodes_1 (node);
*** lto_symtab_prevailing_decl (tree decl)
*** 602,608 
symtab_node ret;
  
/* Builtins and local symbols are their own prevailing decl.  */
!   if (!TREE_PUBLIC (decl) || is_builtin_fn (decl))
  return decl;
  
/* DECL_ABSTRACTs are their own prevailng decl.  */
--- 614,620 
symtab_node ret;
  
/* Builtins and local symbols are their own prevailing decl.  */
!   if ((!TREE_PUBLIC (decl) && 

Re: Using GS for TLS on x86-64 for target RDOS

[Michael Matz]

Hi,

On Tue, 14 May 2013, Uros Bizjak wrote:

> I'd propose to introduce:
> 
> a) #define DEFAULT_TLS_SEG_REG in i386.h to SEG_GS
> 
> b) #undef and #define DEFAULT_TLS_SEG_REG in x86-64.h to SEG_FS

This would break -m32.

> c) #undef and #define DEFAULT_TLS_SEG_REG in rdos.h to SEG_GS
> 
> Then use DEFAULT_TLS_SEG_REG everywhere.
> 
> This will avoid compile-time and runtime checks.

... which you can't avoid in a multilib compiler.


Ciao,
Michael.

Re: [gomp4] Basic vectorization enablement for #pragma omp simd

[Richard Biener]

On Tue, 14 May 2013, Jakub Jelinek wrote:

> Hi!
> 
> This patch adds safelen field to struct loop, teaches expand_omp_simd
> to set it on the simd loops and then uses it in a few places:
> 1) because the loops are explicitly marked for vectorization by the user,
>we'll try to ifconvert them and vectorize even without -O3, -Ofast or
>-ftree-vectorize (but explicit -fno-tree-vectorize will still disable
>that behavior)
> 2) the data dependency analysis uses it to decide about unknown and bad
>data dependencies
> 3) unrolling is disabled for those loops, I think we don't want to unroll
>those loops until vectorization, and after vectorization we just clear
>the safelen, so that it can be unrolled afterwards
> 
> In the end we'll want to do much more on the vectorizer side, handle calls
> to elemental functions, handle conditionalized calls to elemental functions,
> or even vectorize loops where some part of the loop isn't really
> vectorizable and needs to be sequential, but other parts of the loop are
> vectorizable.  for (...) { vectorizable_bb; non-vectorizable_bb; 
> vectorizable_bb; }
> can be turned into for (...) { vectorized_bb; for (temp = 0; temp < vf;
> temp++) non-vectorizable_bb; vectorized_bb; } etc.
> 
> Does this look ok?
> 
> 2013-05-14  Jakub Jelinek  
> 
>   * cfgloop.h (struct loop): Add safelen field.
>   * omp-low.c (expand_omp_simd): If !broken_loop, fix_loop_structure
>   to create loop for the simd region and set safelen field.
>   * tree-vectorizer.c (vectorize_loops): If loop has safelen set,
>   vectorize it even if flag_vectorize isn't set.  Clear loop->safelen
>   after vectorization.
>   * tree-ssa-loop.c (gate_tree_vectorize): Return true even for
>   flag_openmp if -fno-tree-vectorize hasn't been specified.
>   * tree-ssa-loop-ivcanon.c (tree_unroll_loops_completely_1): Don't
>   unroll loops with non-NULL loop->safelen.
>   * tree-vect-data-refs.c (vect_analyze_data_ref_dependence): For unknown
>   or bad data dependency, if loop->safelen is non-NULL, just decrease
>   *max_vf to loop->safelen if needed and return false.
>   * tree-if-conv.c (main_tree_if_conversion): If-convert also loops with
>   non-NULL loop->safelen.
>   (gate_tree_if_conversion): Return true even for
>   flag_openmp if -fno-tree-vectorize hasn't been specified.
> 
> --- gcc/cfgloop.h.jj  2013-05-13 16:49:44.0 +0200
> +++ gcc/cfgloop.h 2013-05-13 17:30:18.630883633 +0200
> @@ -176,6 +176,12 @@ struct GTY ((chain_next ("%h.next"))) lo
>  
>/* Number of iteration analysis data for RTL.  */
>struct niter_desc *simple_loop_desc;
> +
> +  /* If non-NULL, an INTEGER_CST, where the user asserted that for any
> + I in [ 0, nb_iterations ) and for any J in
> + [ I, min ( I + safelen, nb_iterations ) ), the Ith and Jth iterations
> + of the loop can be safely evaluated concurrently.  */
> +  tree safelen;

Can you make this a double_int (or a HOST_WIDE_INT or an int) instead 
please?  It should map to data-dependence analysis distance vectors
which currently is a vector of 'int'.
Is there a magic value to tell safelen is "infinity"?  As I read
above safelen == 0 would mean all iterations are dependent.  Are
negative safelen values well-defined?  The comment doesn't seem
to disallow them.

Also make sure to copy the field in copy_loop_info and stream
it in output/input_cfg in lto-streamer-in/out.c.

>  };
>  
>  /* Flags for state of loop structure.  */
> --- gcc/omp-low.c.jj  2013-05-13 16:37:05.0 +0200
> +++ gcc/omp-low.c 2013-05-13 18:46:18.310405585 +0200
> @@ -4960,6 +4960,8 @@ expand_omp_simd (struct omp_region *regi
>edge e, ne;
>tree *counts = NULL;
>int i;
> +  tree safelen = find_omp_clause (gimple_omp_for_clauses (fd->for_stmt),
> +   OMP_CLAUSE_SAFELEN);
>type = TREE_TYPE (fd->loop.v);
>entry_bb = region->entry;
> @@ -5157,6 +5159,22 @@ expand_omp_simd (struct omp_region *regi
>set_immediate_dominator (CDI_DOMINATORS, l1_bb, entry_bb);
>set_immediate_dominator (CDI_DOMINATORS, l2_bb, l1_bb);
>set_immediate_dominator (CDI_DOMINATORS, l0_bb, l1_bb);
> +
> +  if (!broken_loop)
> +{
> +  struct loop *loop;
> +  calculate_dominance_info (CDI_DOMINATORS);
> +  fix_loop_structure (NULL);

Ick.  Didn't I properly add loops everywhere?

> +  loop = l1_bb->loop_father;
> +  if (safelen == NULL_TREE)
> + {
> +   safelen = build_nonstandard_integer_type (TYPE_PRECISION (type), 1);
> +   safelen = TYPE_MAX_VALUE (safelen);
> + }
> +  else
> + safelen = OMP_CLAUSE_SAFELEN_EXPR (safelen);
> +  loop->safelen = safelen;
> +}
>  }
>  
>  
> --- gcc/tree-vectorizer.c.jj  2013-05-13 16:49:03.0 +0200
> +++ gcc/tree-vectorizer.c 2013-05-13 20:44:58.721863725 +0200
> @@ -101,7 +101,8 @@ vectorize_loops (void)
>   than all previously defined loops.  This fact all

[build] Fix Solaris --as-needed/-z ignore detection (PR target/57261)

[Rainer Orth]

The patch to use -z ignore/-z record for libgcc_s on Solaris caused far
more problems than it initially seemed:

* Before Solaris 11 where dl_iterate_phdr is used, crtbegin.o contains
  references to
  __register_frame_info_bases/__deregister_frame_info_bases which cause
  libgcc_s.so.1 to be dragged into even the most trivial C program,
  which breaks bootstrap.

* On Solaris 11/x86 with gld, crt1.o is delivered with a reference to
  _DYNAMIC (unlike SPARC), which again drags in libgcc_s.so.1.  I don't
  yet know why this doesn't happen with Solaris ld.

Anyway, this patch disables -z ignore/--as-needed use in all those
configurations.

Bootstrapped without regressions on i386-pc-solaris2.{9,10,11} and
sparc-sun-solaris2.{9,10,11} with as/ld, gas/gld, installed on mainline.

Rainer


2013-04-25  Rainer Orth  

PR target/57261
* configure.ac (gcc_cv_ld_as_needed): Disable before Solaris 11
and Solaris 11+/x86 with gld.
* configure: Regenerate.

# HG changeset patch
# Parent a618b2ae5c9b7838e4785a8179e0a67fb55365f7
Fix Solaris --as-needed/-z ignore detection

diff --git a/gcc/configure.ac b/gcc/configure.ac
--- a/gcc/configure.ac
+++ b/gcc/configure.ac
@@ -4560,6 +4560,23 @@ elif test x$gcc_cv_ld != x; then
 	  esac
 	fi
 fi
+# --as-needed/-z ignore can only be used if libgcc_s.so.1 uses
+# dl_iterate_phdr, i.e. since Solaris 11.
+case "$target" in
+  *-*-solaris2.1[[1-9]]*)
+case "$target" in
+i?86-*-* | x86_64-*-*)
+  if echo "$ld_ver" | grep GNU > /dev/null; then
+# Doesn't work with gld on Solaris/x86 due to PR ld/12320.
+gcc_cv_ld_as_needed=no
+  fi
+  ;;
+esac
+;;
+  *-*-solaris2*)
+gcc_cv_ld_as_needed=no
+;;
+esac
 ])
 if test x"$gcc_cv_ld_as_needed" = xyes; then
 	AC_DEFINE(HAVE_LD_AS_NEEDED, 1,

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

Re: Fix weakrefs and LTO

[Richard Biener]

On Tue, May 14, 2013 at 11:12 AM, Jan Hubicka  wrote:
> Hi,
> this patch fixes with weakrefs seen on building latest firefox.  The problem 
> is
> that currently we handle weakrefs as external variables/functions that makes 
> us
> to merge them.  In firefox there are two weakrefs with different aliases used
> in different units.  This is correct and well defined even if weird use.
>
> This patch adds special cases for weakrefs into lto-symtab and lto-partition
> to make them go through correctly.  I also fixed two fallouts of my previous
> change that reproduce on firefox (and the testcase addded).
>
> For lto-partition the weakrefs with defined target are even bit more special
> animals, since they needs to be duplicated into every unit that use them.
>
> It is ugly to special case wekarefs all around.  My plan is to cleanup whole
> area, but it seems that the correctness issue deserve to be fixed first.
>
> I have bootstrapped/regtested x86_64-linux and tested mozilla build.  Will
> commit it tonight if there are no complains.

Does this affect the 4.8 branch, too?

Thanks,
Richard.

> Honza
>
> PR lto/57038
> PR lto/47375
> * lto-symtab.c (lto_symtab_symbol_p): Add external symbol; weakrefs 
> are
> not external.
> (lto_symtab_merge_decls): Fix thinko when dealing with non-lto_symtab 
> decls.
> (lto_symtab_merge_cgraph_nodes): Use lto_symtab_symbol_p.
> (lto_symtab_prevailing_decl): Get int sync with lto_symtab_symbol_p.
> * varpool.c (dump_varpool_node): Dump more flags.
>
> * lto-partition.c (get_symbol_class): Fix weakrefs.
> (lto_balanced_map): Fix weakrefs.
> (privatize_symbol_name): Remove unnecesary label.
> (rename_statics): Handle weakrefs as statics.
>
> * gcc.dg/lto/attr-weakref-1_0.c: New testcase.
> * gcc.dg/lto/attr-weakref-1_1.c: New testcase.
> * gcc.dg/lto/attr-weakref-1_2.c: New testcase.
> Index: lto-symtab.c
> ===
> *** lto-symtab.c(revision 198824)
> --- lto-symtab.c(working copy)
> *** lto_symtab_resolve_replaceable_p (symtab
> *** 227,239 
>   }
>
>   /* Return true, if the symbol E should be resolved by lto-symtab.
> !Those are all real symbols that are not static (we handle renaming
> !of static later in partitioning).  */
>
>   static bool
>   lto_symtab_symbol_p (symtab_node e)
>   {
> !   if (!TREE_PUBLIC (e->symbol.decl))
>   return false;
> return symtab_real_symbol_p (e);
>   }
> --- 227,242 
>   }
>
>   /* Return true, if the symbol E should be resolved by lto-symtab.
> !Those are all external symbols and all real symbols that are not static 
> (we
> !handle renaming of static later in partitioning).  */
>
>   static bool
>   lto_symtab_symbol_p (symtab_node e)
>   {
> !   if (!TREE_PUBLIC (e->symbol.decl) && !DECL_EXTERNAL (e->symbol.decl))
> ! return false;
> !   /* weakrefs are really static variables that are made external by a hack. 
>  */
> !   if (lookup_attribute ("weakref", DECL_ATTRIBUTES (e->symbol.decl)))
>   return false;
> return symtab_real_symbol_p (e);
>   }
> *** lto_symtab_merge_decls (void)
> *** 528,537 
> symtab_initialize_asm_name_hash ();
>
> FOR_EACH_SYMBOL (node)
> ! if (TREE_PUBLIC (node->symbol.decl)
> !   && node->symbol.next_sharing_asm_name
> !   && !node->symbol.previous_sharing_asm_name)
> ! lto_symtab_merge_decls_1 (node);
>   }
>
>   /* Helper to process the decl chain for the symbol table entry *SLOT.  */
> --- 531,549 
> symtab_initialize_asm_name_hash ();
>
> FOR_EACH_SYMBOL (node)
> ! if (lto_symtab_symbol_p (node)
> !   && node->symbol.next_sharing_asm_name)
> !   {
> ! symtab_node n;
> !
> !   /* To avoid duplicated work, see if this is first real symbol in the
> !  chain.  */
> !   for (n = node->symbol.previous_sharing_asm_name;
> !n && !lto_symtab_symbol_p (n); n = 
> n->symbol.previous_sharing_asm_name)
> ! ;
> !   if (!n)
> !   lto_symtab_merge_decls_1 (node);
> !   }
>   }
>
>   /* Helper to process the decl chain for the symbol table entry *SLOT.  */
> *** lto_symtab_merge_cgraph_nodes (void)
> *** 574,580 
>
> if (!flag_ltrans)
>   FOR_EACH_SYMBOL (node)
> !   if (TREE_PUBLIC (node->symbol.decl)
>   && node->symbol.next_sharing_asm_name
>   && !node->symbol.previous_sharing_asm_name)
>   lto_symtab_merge_cgraph_nodes_1 (node);
> --- 586,592 
>
> if (!flag_ltrans)
>   FOR_EACH_SYMBOL (node)
> !   if (lto_symtab_symbol_p (node)
>   && node->symbol.next_sharing_asm_name
>   && !node->symbol.previous_sharing_asm_name)
>   lto_symtab_merge_cgraph_nodes_1 (node);
> *** lto_symtab_prevailing_decl (tree decl)
> *** 602,608 
> symtab_node ret;
>
> 

Re: Using GS for TLS on x86-64 for target RDOS

[Uros Bizjak]

On Tue, May 14, 2013 at 11:13 AM, Michael Matz  wrote:

> On Tue, 14 May 2013, Uros Bizjak wrote:
>
>> I'd propose to introduce:
>>
>> a) #define DEFAULT_TLS_SEG_REG in i386.h to SEG_GS
>>
>> b) #undef and #define DEFAULT_TLS_SEG_REG in x86-64.h to SEG_FS
>
> This would break -m32.

Uh, yes.

So instead of a) and b), there should be:

#define DEFAULT_TLS_SEG_REG TARGET_64BIT ? SEG_FS : SEG_GS in i386.h.

Uros.

Re: [gomp4] Basic vectorization enablement for #pragma omp simd

[Jakub Jelinek]

On Tue, May 14, 2013 at 11:28:43AM +0200, Richard Biener wrote:
> > +  /* If non-NULL, an INTEGER_CST, where the user asserted that for any
> > + I in [ 0, nb_iterations ) and for any J in
> > + [ I, min ( I + safelen, nb_iterations ) ), the Ith and Jth iterations
> > + of the loop can be safely evaluated concurrently.  */
> > +  tree safelen;
> 
> Can you make this a double_int (or a HOST_WIDE_INT or an int) instead 
> please?  It should map to data-dependence analysis distance vectors
> which currently is a vector of 'int'.

If all we care about is int, it can be int.  Infinity is when
#pragma omp simd
doesn't contain any simdlen clause, or when Cilk+
#pragma simd
doesn't contain any vectorlength or vectorlengthfor clauses.
So, shall we assign INT_MAX for infinity?  At least the vectorizer
certainly doesn't care about anything beyond MAX_VECTORIZATION_FACTOR.
And I can just map any explicit safelen in the source larger than INT_MAX
as INT_MAX.

> Is there a magic value to tell safelen is "infinity"?  As I read
> above safelen == 0 would mean all iterations are dependent.  Are
> negative safelen values well-defined?  The comment doesn't seem
> to disallow them.

The FEs disallow safelen <= 0 or non-constant.

> Also make sure to copy the field in copy_loop_info and stream
> it in output/input_cfg in lto-streamer-in/out.c.

Ok.

> > +  if (!broken_loop)
> > +{
> > +  struct loop *loop;
> > +  calculate_dominance_info (CDI_DOMINATORS);
> > +  fix_loop_structure (NULL);
> 
> Ick.  Didn't I properly add loops everywhere?

The loop was previously containing EDGE_ABNORMAL edges (that is something
to prevent any optimizations on those until ompexp had a chance to deal with
those), so there is no loop at all, just the loop->num == 0 for the whole
function if #pragma omp simd appears outside of loops and doesn't contain
any loops inside of its body.

> > --- gcc/tree-vectorizer.c.jj2013-05-13 16:49:03.0 +0200
> > +++ gcc/tree-vectorizer.c   2013-05-13 20:44:58.721863725 +0200
> > @@ -101,7 +101,8 @@ vectorize_loops (void)
> >   than all previously defined loops.  This fact allows us to run
> >   only over initial loops skipping newly generated ones.  */
> >FOR_EACH_LOOP (li, loop, 0)
> > -if (optimize_loop_nest_for_speed_p (loop))
> > +if ((flag_tree_vectorize && optimize_loop_nest_for_speed_p (loop))
> > +   || loop->safelen)
> 
> So you vectorize all loops with a safelen?  I'd say this warrants an
> extra flag in struct loop, force_vect.

Ok.

> > @@ -225,7 +225,8 @@ tree_vectorize (void)
> >  static bool
> >  gate_tree_vectorize (void)
> >  {
> > -  return flag_tree_vectorize;
> > +  return flag_tree_vectorize
> > +|| (flag_openmp && !global_options_set.x_flag_tree_vectorize);
> 
> And a flag in cfun here, whether any loop has force_vect set (or
> a flag in current_loops)

Ok.

> Rather than looking at safelen from data-dependence analysis consumers
> data-dependence analysis itself should use the information.  Which
> is why I'd like the 'safelen' thing to map to the distance vector
> representation of dependence analysis.

Will try.

Jakub

Re: GCC does not support *mmintrin.h with function specific opts

[Uros Bizjak]

On Tue, May 14, 2013 at 10:39 AM, Jakub Jelinek  wrote:
> On Tue, May 14, 2013 at 08:58:55AM +0200, Uros Bizjak wrote:
>> I think that the option should be named -mtarget-builtins.
>
> There shouldn't be an option for it at all.  If constructing the builtins is
> slow (it is), we should just create them lazily, the
> *builtin_decl_{explicit,implicit}* APIs were a first step for that, plus
> we should build some gperf table of all the generic and all the target
> builtins and record prefixes used to find them (__builtin_, __sync_,
> __atomic_, what else?), then just teach FE that if they are looking up
> a symbol prefixed with one of these, they should also look it up
> in the perfect hash table and if found there, call some function to
> construct the builtin.  Of course, this isn't a prerequisite of the
> changes you are looking for, but introducing an option that hopefully will
> be completely useless in a few months is just a bad idea.
>
>> Since HJ is OK with this user-visible change, the patch is OK for
>> mainline (with eventually renamed option). We also have an option to
>> switch this new functionality off, and we are early enough in the
>> development cycle to find out if anything is fundamentaly broken with
>> this approach.
>>
>> BTW, does this patch address the request in PR57202?
>
> I'm strongly against the patch in its current form, it is a hack rather
> than a solution.  I don't see how it could be properly tested, when say
> immintrin.h and x86intrin.h is still full of code like:
> #ifdef __AVX__
> #include 
> #endif
> so when you just
> #include 
> rather than the few headers that were tested, you are out of luck.

Jakub, thanks for your thorough analysis.

It looks that the approach in the patch is fundamentally flawed and
that infrastructure is not developed/fixed enough for alternative
solution.

Based on expressed concerns, I retract my previous approval.

Thanks,
Uros.

Re: [PATCH] Add explicit default constructors where required by the standard

[Evgeniy Stepanov]

This must have fallen through the cracks.
I realized we also need it in the 4_7 branch. Could you backport the
change there, too, if it is not too much trouble?

On Mon, Apr 22, 2013 at 10:53 PM, Jonathan Wakely  wrote:
> On 22 April 2013 12:13, Evgeniy Stepanov wrote:
>> Thanks a lot.
>> Forgot to mention it earlier, can this be backported in the 4_8 branch as 
>> well?
>
> Yes, I don't see why not. I'll do that too.

Re: [ping][patch, ARM] Fix PR42017, LR not used in leaf functions

[Ramana Radhakrishnan]

On 05/13/13 04:15, Kugan wrote:

Hi,

Ping this patch by Chung-Lin.
http://gcc.gnu.org/ml/gcc-patches/2011-05/msg01179.html

This patch allows lr registers to be used in leaf functions for ARM.

There were some concerns about performance regression in thumb2 mode for
CoreMark. However, looking at the code further shows that this
performance regression is due to alignment issue with
core_state_transition function and as a result taking longer time to
execute. In fact, there isn’t any change in the code generated for
core_state_transition with and without the patch. Adding Alignment to
this function improves the performance than without the patch.

Is this patch ok for trunk?

Thanks,
Kugan



Ok.

Ramana

Re: [PATCH] Add explicit default constructors where required by the standard

[Jonathan Wakely]

On 14 May 2013 10:45, Evgeniy Stepanov wrote:
> This must have fallen through the cracks.

It's still in my Git branch at home. I've been too busy to push any
commits recently, but I haven't forgotten it.


> I realized we also need it in the 4_7 branch. Could you backport the
> change there, too, if it is not too much trouble?

Yes, for such a small, safe change I'm happy to apply it to the 4.7 branch too.

[PATCH] Fix PR57269

[Richard Biener]

This backports a piece of Nathans patch to avoid opening two
gcov files at once (which ICEs).

Profiledbootstrap / regtest ongoing on x86_64-unknown-linux-gnu.

Richard.

2013-05-14  Richard Biener  

PR gcov-profile/57269
Backport from mainline
2012-06-30  Nathan Sidwell  

* coverage.c (coverage_init): Read counts file before writing
graph header.

Index: gcc/coverage.c
===
--- gcc/coverage.c  (revision 198575)
+++ gcc/coverage.c  (working copy)
@@ -1099,6 +1099,9 @@ coverage_init (const char *filename)
   memcpy (da_file_name + prefix_len, filename, len);
   strcpy (da_file_name + prefix_len + len, GCOV_DATA_SUFFIX);
 
+  if (flag_branch_probabilities)
+read_counts_file ();
+
   /* Name of bbg file.  */
   if (flag_test_coverage && !flag_compare_debug)
 {
@@ -1118,9 +1121,6 @@ coverage_init (const char *filename)
  gcov_write_unsigned (local_tick);
}
 }
-
-  if (flag_branch_probabilities)
-read_counts_file ();
 }
 
 /* Performs file-level cleanup.  Close graph file, generate coverage

[linaro/gcc-4_8-branch] Backports from trunk and merge from gcc-4_8-branch.

[Matthew Gretton-Dann]

All,

I have just backported the following revisions from trunk to 
linaro/gcc-4_8-branch: 197838, 198191, 198490-198496, 198575-198575, and 198677.


I have also merged the gcc-4_8-branch into linaro/gcc-4_8-branch up to 
revision 198615.


Thanks,

Matt

--
Matthew Gretton-Dann
Toolchain Working Group, Linaro

Re: GCC does not support *mmintrin.h with function specific opts

[Jakub Jelinek]

On Tue, May 14, 2013 at 10:39:13AM +0200, Jakub Jelinek wrote:
> When trying with -O2 -mno-avx:
> #ifndef __AVX__
> #pragma GCC push_options
> #pragma GCC target("avx")
> #define __DISABLE_AVX__
> #endif
> typedef float __v8sf __attribute__ ((__vector_size__ (32)));
> typedef float __m256 __attribute__ ((__vector_size__ (32), __may_alias__));
> extern __inline __m256 __attribute__((__gnu_inline__, __always_inline__, 
> __artificial__))
> _mm256_and_ps (__m256 __A, __m256 __B) { return (__m256) 
> __builtin_ia32_andps256 ((__v8sf)__A, (__v8sf)__B); }
> #ifdef __DISABLE_AVX__
> #pragma GCC pop_options
> #undef __DISABLE_AVX__
> #endif
> __m256 a, b, c;
> void __attribute__((target ("avx")))
> foo (void)
> {
>   a = _mm256_and_ps (b, c);
> }
> we get bogus errors and ICE:
> tty2.c: In function '_mm256_and_ps':
> tty2.c:9:1: note: The ABI for passing parameters with 32-byte alignment has 
> changed in GCC 4.6
> tty2.c: In function 'foo':
> tty2.c:9:82: error: '__builtin_ia32_andps256' needs isa option -m32
> tty2.c:9:82: internal compiler error: in emit_move_insn, at expr.c:3486
> 0x77a3d2 emit_move_insn(rtx_def*, rtx_def*)
>   ../../gcc/expr.c:3485
> (I have added "1 ||" instead of your generate_builtins into i386.c
> (def_builtin)), that just shows that target attribute/pragma support still
> has very severe issues that need to be fixed, instead of papered around.
> 
> Note, we ICE on:
> #pragma GCC target ("mavx")
> That should be fixed too.

Ok, I had a brief look at the above two issues.

The first testcase has the problem that the ix86_previous_fndecl cache
gets out of date.  When set_cfun is called on _mm256_and_ps (with the
implicit avx attribute), then ix86_previous_fndecl is set to _mm256_and_ps,
TARGET_AVX is set to true, target reinited.  Then set_cfun is called
with NULL, we don't do anything.  Later on #pragma GCC pop_options appears,
sets !TARGET_AVX (as that is the new target_option_current_node).
Next foo is being parsed, avx attribute is noticed, the same target node
is used for it, but when set_cfun is called for foo, ix86_previous_fndecl's
target node is the same as foo's and so we don't do cl_target_restore_option
at all, so !TARGET_AVX remains, while it should be set.  That is the reason
for the bogus inform etc.  Fixed by resetting the ix86_previous_fndecl cache
on any #pragma GCC target below.  The #pragma GCC target ("mavx") is also
fixed below.  The patch also includes the "1 ||" to enable building all
builtins.  We still ICE with:
#0  fancy_abort (file=0x11d8fad "../../gcc/expr.c", line=316, 
function=0x11dada3 "convert_move") at ../../gcc/diagnostic.c:1180
#1  0x00771c39 in convert_move (to=0x71b2df00, from=0x71b314e0, 
unsignedp=0) at ../../gcc/expr.c:316
#2  0x0078009f in store_expr (exp=0x719ab390, 
target=0x71b2df00, call_param_p=0, nontemporal=false) at 
../../gcc/expr.c:5300
#3  0x0077eba1 in expand_assignment (to=0x71b35090, 
from=0x719ab390, nontemporal=false) at ../../gcc/expr.c:5025
on the first testcase.  We don't ICE say on:
#ifndef __AVX__
#pragma GCC push_options
#pragma GCC target("avx")
#define __DISABLE_AVX__
#endif
typedef float __v8sf __attribute__ ((__vector_size__ (32)));
typedef float __m256 __attribute__ ((__vector_size__ (32), __may_alias__));
extern __inline __m256 __attribute__((__gnu_inline__, __always_inline__, 
__artificial__))
_mm256_and_ps (__m256 __A, __m256 __B) { return (__m256) 
__builtin_ia32_andps256 ((__v8sf)__A, (__v8sf)__B); }
#ifdef __DISABLE_AVX__
#pragma GCC pop_options
#undef __DISABLE_AVX__
#endif
__m256 a[10], b[10], c[10];
void __attribute__((target ("avx")))
foo (void)
{
  a[0] = _mm256_and_ps (b[0], c[0]);
}
The problem is that in the first testcase, the VAR_DECL c (guess also b and
a) have TYPE_MODE (TREE_TYPE (c)) == V8SFmode (this is dynamic, for vector
types TYPE_MODE is a function call), but DECL_MODE (c) is BLKmode
(it has been laid out while -mno-avx has been the current) and also
DECL_RTL which is a mem:BLK.  Guess expr.c would need to special case
TREE_STATIC or DECL_EXTERNAL VAR_DECLs with vector type, if they have
DECL_MODE BLKmode, but TYPE_MODE some vector type, just adjust the MEM
to the desired mode?

--- gcc/config/i386/i386-c.c.jj 2013-01-15 17:20:37.0 +0100
+++ gcc/config/i386/i386-c.c2013-05-14 11:46:50.773806894 +0200
@@ -369,20 +369,23 @@ ix86_pragma_target_parse (tree args, tre
 
   if (! args)
 {
-  cur_tree = ((pop_target)
- ? pop_target
- : target_option_default_node);
+  cur_tree = (pop_target ? pop_target : target_option_default_node);
   cl_target_option_restore (&global_options,
TREE_TARGET_OPTION (cur_tree));
 }
   else
 {
   cur_tree = ix86_valid_target_attribute_tree (args);
-  if (!cur_tree)
-   return false;
+  if (!cur_tree || cur_tree == error_mark_node)
+   {
+ cl_target_option_restore (&global_options,
+ 

Re: [gomp4] Basic vectorization enablement for #pragma omp simd

[Richard Biener]

On Tue, 14 May 2013, Jakub Jelinek wrote:

> On Tue, May 14, 2013 at 11:28:43AM +0200, Richard Biener wrote:
> > > +  /* If non-NULL, an INTEGER_CST, where the user asserted that for any
> > > + I in [ 0, nb_iterations ) and for any J in
> > > + [ I, min ( I + safelen, nb_iterations ) ), the Ith and Jth 
> > > iterations
> > > + of the loop can be safely evaluated concurrently.  */
> > > +  tree safelen;
> > 
> > Can you make this a double_int (or a HOST_WIDE_INT or an int) instead 
> > please?  It should map to data-dependence analysis distance vectors
> > which currently is a vector of 'int'.
> 
> If all we care about is int, it can be int.  Infinity is when
> #pragma omp simd
> doesn't contain any simdlen clause, or when Cilk+
> #pragma simd
> doesn't contain any vectorlength or vectorlengthfor clauses.
> So, shall we assign INT_MAX for infinity?  At least the vectorizer
> certainly doesn't care about anything beyond MAX_VECTORIZATION_FACTOR.
> And I can just map any explicit safelen in the source larger than INT_MAX
> as INT_MAX.

Works for me.

> > Is there a magic value to tell safelen is "infinity"?  As I read
> > above safelen == 0 would mean all iterations are dependent.  Are
> > negative safelen values well-defined?  The comment doesn't seem
> > to disallow them.
> 
> The FEs disallow safelen <= 0 or non-constant.
> 
> > Also make sure to copy the field in copy_loop_info and stream
> > it in output/input_cfg in lto-streamer-in/out.c.
> 
> Ok.
> 
> > > +  if (!broken_loop)
> > > +{
> > > +  struct loop *loop;
> > > +  calculate_dominance_info (CDI_DOMINATORS);
> > > +  fix_loop_structure (NULL);
> > 
> > Ick.  Didn't I properly add loops everywhere?
> 
> The loop was previously containing EDGE_ABNORMAL edges (that is something
> to prevent any optimizations on those until ompexp had a chance to deal with
> those), so there is no loop at all, just the loop->num == 0 for the whole
> function if #pragma omp simd appears outside of loops and doesn't contain
> any loops inside of its body.

But don't we now know the loop (it's header and possibly its latch)
and so we can simply add_loop here?

> > > --- gcc/tree-vectorizer.c.jj  2013-05-13 16:49:03.0 +0200
> > > +++ gcc/tree-vectorizer.c 2013-05-13 20:44:58.721863725 +0200
> > > @@ -101,7 +101,8 @@ vectorize_loops (void)
> > >   than all previously defined loops.  This fact allows us to run
> > >   only over initial loops skipping newly generated ones.  */
> > >FOR_EACH_LOOP (li, loop, 0)
> > > -if (optimize_loop_nest_for_speed_p (loop))
> > > +if ((flag_tree_vectorize && optimize_loop_nest_for_speed_p (loop))
> > > + || loop->safelen)
> > 
> > So you vectorize all loops with a safelen?  I'd say this warrants an
> > extra flag in struct loop, force_vect.
> 
> Ok.
> 
> > > @@ -225,7 +225,8 @@ tree_vectorize (void)
> > >  static bool
> > >  gate_tree_vectorize (void)
> > >  {
> > > -  return flag_tree_vectorize;
> > > +  return flag_tree_vectorize
> > > +  || (flag_openmp && !global_options_set.x_flag_tree_vectorize);
> > 
> > And a flag in cfun here, whether any loop has force_vect set (or
> > a flag in current_loops)
> 
> Ok.
> 
> > Rather than looking at safelen from data-dependence analysis consumers
> > data-dependence analysis itself should use the information.  Which
> > is why I'd like the 'safelen' thing to map to the distance vector
> > representation of dependence analysis.
> 
> Will try.

Might not be trivial - the dependency whould have to be of "known"
type and the distance vector maybe safelen+1 (which would be
not exactly correct I think, but there isn't sth like "at least"
safelen+1).  So eventually it needs to be an "unknown" dependency
still with a new interface of a "at least" distance result.

Richard.

Re: sparc64*-*-rtems* should not define __svr4__

[Joel Sherrill]

Thanks Eric. This is better. spaec64-elf should not define it either.

Eric Botcazou  wrote:


> sparc64*-*-rtems* ends up with __svr4__ defined. The attached
> patch corrects that.

Let's remove the FIXME instead.  Applied to mainline.


2013-05-14  Eric Botcazou  

* config/sparc/sp64-elf.h (CPP_SUBTARGET_SPEC): Delete.
* config/sparc/openbsd64.h (CPP_SUBTARGET_SPEC): Likewise.


--
Eric Botcazou

Re: GCC does not support *mmintrin.h with function specific opts

[Richard Biener]

On Tue, May 14, 2013 at 12:04 PM, Jakub Jelinek  wrote:
> On Tue, May 14, 2013 at 10:39:13AM +0200, Jakub Jelinek wrote:
>> When trying with -O2 -mno-avx:
>> #ifndef __AVX__
>> #pragma GCC push_options
>> #pragma GCC target("avx")
>> #define __DISABLE_AVX__
>> #endif
>> typedef float __v8sf __attribute__ ((__vector_size__ (32)));
>> typedef float __m256 __attribute__ ((__vector_size__ (32), __may_alias__));
>> extern __inline __m256 __attribute__((__gnu_inline__, __always_inline__, 
>> __artificial__))
>> _mm256_and_ps (__m256 __A, __m256 __B) { return (__m256) 
>> __builtin_ia32_andps256 ((__v8sf)__A, (__v8sf)__B); }
>> #ifdef __DISABLE_AVX__
>> #pragma GCC pop_options
>> #undef __DISABLE_AVX__
>> #endif
>> __m256 a, b, c;
>> void __attribute__((target ("avx")))
>> foo (void)
>> {
>>   a = _mm256_and_ps (b, c);
>> }
>> we get bogus errors and ICE:
>> tty2.c: In function '_mm256_and_ps':
>> tty2.c:9:1: note: The ABI for passing parameters with 32-byte alignment has 
>> changed in GCC 4.6
>> tty2.c: In function 'foo':
>> tty2.c:9:82: error: '__builtin_ia32_andps256' needs isa option -m32
>> tty2.c:9:82: internal compiler error: in emit_move_insn, at expr.c:3486
>> 0x77a3d2 emit_move_insn(rtx_def*, rtx_def*)
>>   ../../gcc/expr.c:3485
>> (I have added "1 ||" instead of your generate_builtins into i386.c
>> (def_builtin)), that just shows that target attribute/pragma support still
>> has very severe issues that need to be fixed, instead of papered around.
>>
>> Note, we ICE on:
>> #pragma GCC target ("mavx")
>> That should be fixed too.
>
> Ok, I had a brief look at the above two issues.
>
> The first testcase has the problem that the ix86_previous_fndecl cache
> gets out of date.  When set_cfun is called on _mm256_and_ps (with the
> implicit avx attribute), then ix86_previous_fndecl is set to _mm256_and_ps,
> TARGET_AVX is set to true, target reinited.  Then set_cfun is called
> with NULL, we don't do anything.  Later on #pragma GCC pop_options appears,
> sets !TARGET_AVX (as that is the new target_option_current_node).
> Next foo is being parsed, avx attribute is noticed, the same target node
> is used for it, but when set_cfun is called for foo, ix86_previous_fndecl's
> target node is the same as foo's and so we don't do cl_target_restore_option
> at all, so !TARGET_AVX remains, while it should be set.  That is the reason
> for the bogus inform etc.  Fixed by resetting the ix86_previous_fndecl cache
> on any #pragma GCC target below.  The #pragma GCC target ("mavx") is also
> fixed below.  The patch also includes the "1 ||" to enable building all
> builtins.  We still ICE with:
> #0  fancy_abort (file=0x11d8fad "../../gcc/expr.c", line=316, 
> function=0x11dada3 "convert_move") at ../../gcc/diagnostic.c:1180
> #1  0x00771c39 in convert_move (to=0x71b2df00, 
> from=0x71b314e0, unsignedp=0) at ../../gcc/expr.c:316
> #2  0x0078009f in store_expr (exp=0x719ab390, 
> target=0x71b2df00, call_param_p=0, nontemporal=false) at 
> ../../gcc/expr.c:5300
> #3  0x0077eba1 in expand_assignment (to=0x71b35090, 
> from=0x719ab390, nontemporal=false) at ../../gcc/expr.c:5025
> on the first testcase.  We don't ICE say on:
> #ifndef __AVX__
> #pragma GCC push_options
> #pragma GCC target("avx")
> #define __DISABLE_AVX__
> #endif
> typedef float __v8sf __attribute__ ((__vector_size__ (32)));
> typedef float __m256 __attribute__ ((__vector_size__ (32), __may_alias__));
> extern __inline __m256 __attribute__((__gnu_inline__, __always_inline__, 
> __artificial__))
> _mm256_and_ps (__m256 __A, __m256 __B) { return (__m256) 
> __builtin_ia32_andps256 ((__v8sf)__A, (__v8sf)__B); }
> #ifdef __DISABLE_AVX__
> #pragma GCC pop_options
> #undef __DISABLE_AVX__
> #endif
> __m256 a[10], b[10], c[10];
> void __attribute__((target ("avx")))
> foo (void)
> {
>   a[0] = _mm256_and_ps (b[0], c[0]);
> }
> The problem is that in the first testcase, the VAR_DECL c (guess also b and
> a) have TYPE_MODE (TREE_TYPE (c)) == V8SFmode (this is dynamic, for vector
> types TYPE_MODE is a function call), but DECL_MODE (c) is BLKmode
> (it has been laid out while -mno-avx has been the current) and also
> DECL_RTL which is a mem:BLK.  Guess expr.c would need to special case
> TREE_STATIC or DECL_EXTERNAL VAR_DECLs with vector type, if they have
> DECL_MODE BLKmode, but TYPE_MODE some vector type, just adjust the MEM
> to the desired mode?

I think any entity with static storage (maybe even automatic storage) should
have BLKmode (or rather its mode should not matter) and what matters
is the mode we use for the access - that is, the mode of the MEM_REF we
expand, for example.

That TYPE_MODE is dynamic for vector types is a bad thing.  It also means
that type layout may be variable (consider PPC where double has different
alignment in structs, so what layout would a struct with a vector_size(16)
double vector get with -mvsx vs. -mno-vsx?)

Richard.

> --- gcc/config/i386/i386-c.c.jj 2013-01-15 17:20:37.0

Re: [gomp4] Basic vectorization enablement for #pragma omp simd

[Jakub Jelinek]

On Tue, May 14, 2013 at 12:16:07PM +0200, Richard Biener wrote:
> > The loop was previously containing EDGE_ABNORMAL edges (that is something
> > to prevent any optimizations on those until ompexp had a chance to deal with
> > those), so there is no loop at all, just the loop->num == 0 for the whole
> > function if #pragma omp simd appears outside of loops and doesn't contain
> > any loops inside of its body.
> 
> But don't we now know the loop (it's header and possibly its latch)
> and so we can simply add_loop here?

Ah, add_loop, I was looking for something like that but didn't find it.
I see you've added add_loop for other places in omp-low.c, this spot was
just on gomp-4_0-branch and not on the trunk, will see if I can use it.

> > Will try.
> 
> Might not be trivial - the dependency whould have to be of "known"
> type and the distance vector maybe safelen+1 (which would be
> not exactly correct I think, but there isn't sth like "at least"
> safelen+1).  So eventually it needs to be an "unknown" dependency
> still with a new interface of a "at least" distance result.

I guess I'll start with all other points then...

Jakub

[testsuite] Fix gcc.dg/fstack-protector-strong.c on Solaris/x86

[Rainer Orth]

The new gcc.dg/fstack-protector-strong.c testcase is currently failing
on Solaris/x86 like this:

FAIL: gcc.dg/fstack-protector-strong.c (test for excess errors)

Excess errors:
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.dg/fstack-protector-strong.c:113:13:
 warning: incompatible implicit declaration of built-in function 'alloca' 
[enabled by default]

Matching other testcases that use alloca, I've fixed it by explicitly
declaring alloca.

Tested with the appropriate runtest invocations on i386-pc-solaris2.11
and x86_64-unknown-linux-gnu, installed on mainline.

Rainer


2013-05-14  Rainer Orth  

* gcc.dg/fstack-protector-strong.c (alloca): Declare.

# HG changeset patch
# Parent 677b6b866a10b42d04929883383fbf70e152c598
 Fix gcc.dg/fstack-protector-strong.c on Solaris/x86

diff --git a/gcc/testsuite/gcc.dg/fstack-protector-strong.c b/gcc/testsuite/gcc.dg/fstack-protector-strong.c
--- a/gcc/testsuite/gcc.dg/fstack-protector-strong.c
+++ b/gcc/testsuite/gcc.dg/fstack-protector-strong.c
@@ -6,6 +6,8 @@
 #include
 #include
 
+extern void *alloca(__SIZE_TYPE__);
+
 extern int g0;
 extern int* pg0;
 int

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

Re: [testsuite] Fix gcc.dg/fstack-protector-strong.c on Solaris/x86

[Jakub Jelinek]

On Tue, May 14, 2013 at 12:26:31PM +0200, Rainer Orth wrote:
> Tested with the appropriate runtest invocations on i386-pc-solaris2.11
> and x86_64-unknown-linux-gnu, installed on mainline.

I'd say the test should just use __builtin_alloca instead.

> 2013-05-14  Rainer Orth  
> 
>   * gcc.dg/fstack-protector-strong.c (alloca): Declare.
> 

> # HG changeset patch
> # Parent 677b6b866a10b42d04929883383fbf70e152c598
>  Fix gcc.dg/fstack-protector-strong.c on Solaris/x86
> 
> diff --git a/gcc/testsuite/gcc.dg/fstack-protector-strong.c 
> b/gcc/testsuite/gcc.dg/fstack-protector-strong.c
> --- a/gcc/testsuite/gcc.dg/fstack-protector-strong.c
> +++ b/gcc/testsuite/gcc.dg/fstack-protector-strong.c
> @@ -6,6 +6,8 @@
>  #include
>  #include
>  
> +extern void *alloca(__SIZE_TYPE__);
> +
>  extern int g0;
>  extern int* pg0;
>  int

Jakub

Re: [ping][patch, ARM] Fix PR42017, LR not used in leaf functions

[Kugan]

On 14/05/13 00:24, Chung-Lin Tang wrote:

On 13/5/13 11:15 AM, Kugan wrote:

Hi,

Ping this patch by Chung-Lin.
http://gcc.gnu.org/ml/gcc-patches/2011-05/msg01179.html

This patch allows lr registers to be used in leaf functions for ARM.

There were some concerns about performance regression in thumb2 mode for
CoreMark. However, looking at the code further shows that this
performance regression is due to alignment issue with
core_state_transition function and as a result taking longer time to
execute. In fact, there isn’t any change in the code generated for
core_state_transition with and without the patch. Adding Alignment to
this function improves the performance than without the patch.


Just curious, were changes to enforce the alignment added already? (I'm
quite out of ARM-specific context lately).


Changes to enforce the alignment is not part of the trunk. The thumb2 
regressions are not related to your patch and the patch improves 
performance otherwise.


Thanks,
Kugan


Chung-Lin

[C++ Patch] PR 53903

[Paolo Carlini]

Hi,

in this PR Jonathan noticed that we don't enforce the first part of 
8.4.2/2, about compatibility of the exception-specification of defaulted 
functions in general, not the special case of those defaulted on the 
first declaration. Extending the existing check beyond  
DECL_DEFAULTED_IN_CLASS_P (fn) seems easy, the below passes testing on 
x86_64-linux.


Thanks,
Paolo.


/cp
2013-05-14  Paolo Carlini  

PR c++/53903
* method.c (defaulted_late_check): Check for compatible exception
specification out of class explicitly defaulted functions too.

/testsuite
2013-05-14  Paolo Carlini  

PR c++/53903
* g++.dg/cpp0x/defaulted43.C: New.
Index: cp/method.c
===
--- cp/method.c (revision 198863)
+++ cp/method.c (working copy)
@@ -1755,6 +1755,7 @@ defaulted_late_check (tree fn)
   bool fn_const_p = (copy_fn_p (fn) == 2);
   tree implicit_fn = implicitly_declare_fn (kind, ctx, fn_const_p,
NULL, NULL);
+  tree eh_spec = TYPE_RAISES_EXCEPTIONS (TREE_TYPE (implicit_fn));
 
   if (!same_type_p (TREE_TYPE (TREE_TYPE (fn)),
TREE_TYPE (TREE_TYPE (implicit_fn)))
@@ -1766,33 +1767,42 @@ defaulted_late_check (tree fn)
"does not match expected signature %qD", implicit_fn);
 }
 
-  /* 8.4.2/2: If it is explicitly defaulted on its first declaration, it is
+  /* 8.4.2/2: An explicitly-defaulted function (...) may have an explicit
+ exception-specification only if it is compatible (15.4) with the 
+ exception-specification on the implicit declaration.  If a function
+ is explicitly defaulted on its first declaration, (...) it is
  implicitly considered to have the same exception-specification as if
  it had been implicitly declared.  */
-  if (DECL_DEFAULTED_IN_CLASS_P (fn))
+  if (TYPE_RAISES_EXCEPTIONS (TREE_TYPE (fn)))
 {
-  tree eh_spec = TYPE_RAISES_EXCEPTIONS (TREE_TYPE (implicit_fn));
-  if (TYPE_RAISES_EXCEPTIONS (TREE_TYPE (fn)))
+  maybe_instantiate_noexcept (fn);
+  if (!comp_except_specs (TYPE_RAISES_EXCEPTIONS (TREE_TYPE (fn)),
+ eh_spec, ce_normal))
{
- maybe_instantiate_noexcept (fn);
- if (!comp_except_specs (TYPE_RAISES_EXCEPTIONS (TREE_TYPE (fn)),
- eh_spec, ce_normal))
+ if (DECL_DEFAULTED_IN_CLASS_P (fn))
error ("function %q+D defaulted on its first declaration "
   "with an exception-specification that differs from "
   "the implicit declaration %q#D", fn, implicit_fn);
+ else
+   error ("function %q+D defaulted on its redeclaration "
+  "with an exception-specification that differs from "
+  "the implicit declaration %q#D", fn, implicit_fn);
}
-  TREE_TYPE (fn) = build_exception_variant (TREE_TYPE (fn), eh_spec);
-  if (DECL_DECLARED_CONSTEXPR_P (implicit_fn))
-   {
- /* Hmm...should we do this for out-of-class too? Should it be OK to
-add constexpr later like inline, rather than requiring
-declarations to match?  */
- DECL_DECLARED_CONSTEXPR_P (fn) = true;
- if (kind == sfk_constructor)
-   TYPE_HAS_CONSTEXPR_CTOR (ctx) = true;
-   }
 }
+  if (DECL_DEFAULTED_IN_CLASS_P (fn))
+TREE_TYPE (fn) = build_exception_variant (TREE_TYPE (fn), eh_spec);
 
+  if (DECL_DEFAULTED_IN_CLASS_P (fn)
+  && DECL_DECLARED_CONSTEXPR_P (implicit_fn))
+{
+  /* Hmm...should we do this for out-of-class too? Should it be OK to
+add constexpr later like inline, rather than requiring
+declarations to match?  */
+  DECL_DECLARED_CONSTEXPR_P (fn) = true;
+  if (kind == sfk_constructor)
+   TYPE_HAS_CONSTEXPR_CTOR (ctx) = true;
+}
+
   if (!DECL_DECLARED_CONSTEXPR_P (implicit_fn)
   && DECL_DECLARED_CONSTEXPR_P (fn))
 {
Index: testsuite/g++.dg/cpp0x/defaulted43.C
===
--- testsuite/g++.dg/cpp0x/defaulted43.C(revision 0)
+++ testsuite/g++.dg/cpp0x/defaulted43.C(working copy)
@@ -0,0 +1,50 @@
+// PR c++/53903
+// { dg-do compile { target c++11 } }
+
+struct T
+{
+  T() noexcept(false) { }
+  ~T() noexcept(false) { }
+};
+
+struct A
+{
+  A() noexcept;
+  ~A() noexcept;
+
+  T t;
+};
+
+A::A() noexcept = default;   // { dg-error "defaulted" }
+A::~A() noexcept = default;  // { dg-error "defaulted" }
+
+struct U
+{
+  U() noexcept(false) { }
+  ~U() noexcept(false) { }
+};
+
+struct B
+{
+  B() noexcept(false);
+  ~B() noexcept(false);
+
+  U u;
+};
+
+B::B() noexcept(false) = default;
+B::~B() noexcept(false) = default;
+
+struct V
+{
+  V() noexcept(false) { }
+  ~V() noexcept(false) { }
+};
+
+struct C
+{
+  C() noexcept = default; // { dg-error "defaulted" }
+  ~C() noexcept = default;  

Re: GCC does not support *mmintrin.h with function specific opts

[Jakub Jelinek]

On Tue, May 14, 2013 at 12:22:05PM +0200, Richard Biener wrote:
> > The problem is that in the first testcase, the VAR_DECL c (guess also b and
> > a) have TYPE_MODE (TREE_TYPE (c)) == V8SFmode (this is dynamic, for vector
> > types TYPE_MODE is a function call), but DECL_MODE (c) is BLKmode
> > (it has been laid out while -mno-avx has been the current) and also
> > DECL_RTL which is a mem:BLK.  Guess expr.c would need to special case
> > TREE_STATIC or DECL_EXTERNAL VAR_DECLs with vector type, if they have
> > DECL_MODE BLKmode, but TYPE_MODE some vector type, just adjust the MEM
> > to the desired mode?

--- gcc/expr.c.jj   2013-05-14 08:25:40.0 +0200
+++ gcc/expr.c  2013-05-14 12:55:46.331983406 +0200
@@ -9310,6 +9310,8 @@ expand_expr_real_1 (tree exp, rtx target
  set_curr_insn_location (saved_loc);
  if (REG_P (r) && !REG_EXPR (r))
set_reg_attrs_for_decl_rtl (SSA_NAME_VAR (exp), r);
+ if (MEM_P (r) && GET_MODE (r) == BLKmode && mode != BLKmode)
+   r = adjust_address (r, mode, 0);
  return r;
}

fixes the ICE on that testcase.

> I think any entity with static storage (maybe even automatic storage) should
> have BLKmode (or rather its mode should not matter) and what matters
> is the mode we use for the access - that is, the mode of the MEM_REF we
> expand, for example.

There wasn't any MEM_REF in that case, just SSA_NAME with SSA_NAME_DEF_STMT
of a load from VAR_DECL.

> That TYPE_MODE is dynamic for vector types is a bad thing.  It also means
> that type layout may be variable (consider PPC where double has different
> alignment in structs, so what layout would a struct with a vector_size(16)
> double vector get with -mvsx vs. -mno-vsx?)

I haven't introduced the dynamic TYPE_MODE, but getting rid of it would be
terribly hard I'm afraid.  Anyway, if struct layout depends on modes and
handles the vector modes differently from BLKmode, then it is a target bug,
it really should look at the types instead.  Otherwise if you have
such struct in a header, then -mvsx code will be ABI incompatible with
-mno-vsx code using the same header.

Jakub

[AARCH64] Set "simd" attribute for *movdi_aarch64 pattern

[Sofiane Naci]

Hi, 

This patch defines the "simd" attribute for the *movdi_aarch64 pattern.
Tested successfully with a full regression run on aarch64-elf.

OK for trunk?

Thanks
Sofiane

aarch64-set-simd-att.diff
Description: Binary data

Re: RFA: fix avr compile/limits-externdecl.c failures

[Denis Chertykov]

2013/5/13 Joern Rennecke 
>
> All the gcc.c-torture/compile/limits-externdecl.c currently give an
> error: size of array is too large, followed by an ICE in
> avr_encode_section_info, which goes on to try to find the address space
> of error_mark_node.
>
> Given the size of the array, it makes sense for the test to give an error
> where POINTER_SIZE is 16 bit, but then, we should mark this as an expected
> error for this target.
> Moreover, we shouldn't ICE after the error.
>
> The attached patch implements both these changes.
>
> regression tested for i686-pc-linux-gnu X avr, Running target atmega128-sim
>
> 2013-05-13  Joern Rennecke 
>
> gcc:
> * config/avr/avr.c (avr_encode_section_info): Bail out if the type
> is error_mark_node.
> gcc/testsuite:
> * testsuite/gcc.c-torture/compile/limits-externdecl.c [target 
> avr-*-*]:
> Expect "size of array is too large" error.
>

Applied.

Denis.

Restore m68k bootstrap

[Marc Glisse]

Hello,

in an earlier patch I apparently introduced a platform dependent signed / 
unsigned comparison, so here is a fix. I am taking the chance to fix the 
host_integerp second argument nearby: we want non-negative integers.


Passes bootstrap+testsuite on x86_64-linux-gnu and apparently bootstrap on 
m68k.


2013-05-13  Marc Glisse  

PR bootstrap/57266
* fold-const.c (fold_binary_loc) : Use an unsigned
variable for the shift amount. Check that we shift by non-negative
amounts.

--
Marc GlisseIndex: gcc/fold-const.c
===
--- gcc/fold-const.c(revision 198853)
+++ gcc/fold-const.c(working copy)
@@ -12416,27 +12416,27 @@ fold_binary_loc (location_t loc,
return fold_build2_loc (loc, code, type, op0, tem);
 
   /* Since negative shift count is not well-defined,
 don't try to compute it in the compiler.  */
   if (TREE_CODE (arg1) == INTEGER_CST && tree_int_cst_sgn (arg1) < 0)
return NULL_TREE;
 
   prec = element_precision (type);
 
   /* Turn (a OP c1) OP c2 into a OP (c1+c2).  */
-  if (TREE_CODE (op0) == code && host_integerp (arg1, false)
+  if (TREE_CODE (op0) == code && host_integerp (arg1, true)
  && TREE_INT_CST_LOW (arg1) < prec
- && host_integerp (TREE_OPERAND (arg0, 1), false)
+ && host_integerp (TREE_OPERAND (arg0, 1), true)
  && TREE_INT_CST_LOW (TREE_OPERAND (arg0, 1)) < prec)
{
- HOST_WIDE_INT low = (TREE_INT_CST_LOW (TREE_OPERAND (arg0, 1))
-  + TREE_INT_CST_LOW (arg1));
+ unsigned int low = (TREE_INT_CST_LOW (TREE_OPERAND (arg0, 1))
+ + TREE_INT_CST_LOW (arg1));
 
  /* Deal with a OP (c1 + c2) being undefined but (a OP c1) OP c2
 being well defined.  */
  if (low >= prec)
{
  if (code == LROTATE_EXPR || code == RROTATE_EXPR)
low = low % prec;
  else if (TYPE_UNSIGNED (type) || code == LSHIFT_EXPR)
return omit_one_operand_loc (loc, type, build_zero_cst (type),
 TREE_OPERAND (arg0, 0));

Re: More vector folding

[Richard Biener]

On Mon, May 13, 2013 at 1:40 PM, Marc Glisse  wrote:
> On Mon, 13 May 2013, Richard Biener wrote:
>
>> On Sat, May 11, 2013 at 11:38 AM, Marc Glisse 
>> wrote:
>>>
>>> Second try.
>>>
>>> I removed the fold_single_bit_test thing (I thought I'd handle it, so I
>>> started by the easy part, and never did the rest).
>>>
>>> Adapting invert_truthvalue_loc for vectors, I thought: calling
>>> fold_truth_not_expr and build1 if it fails is just the same as
>>> fold_build1.
>>> Except that it wasn't: fold_unary_loc fold_convert to boolean before
>>> calling
>>> fold_truth_not_expr and then back to the required type. And instead of
>>> simply changing the type of an EQ_EXPR, fold_convert introduces a
>>> NOP_EXPR
>>> (one that STRIP_NOPS doesn't remove), which hides the comparison from
>>> many
>>> other parts of the front-end (affects warnings) and folding. I hesitated
>>> between removing this cast and enhancing fold_convert, and chose the one
>>> that removes code. As a side benefit, I got an XPASS :-)
>>>
>>>
>>> Passes bootstrap+testsuite on x86_64-linux-gnu.
>>>
>>> 2013-05-11  Marc Glisse  
>>>
>>>
>>> gcc/
>>> * fold-const.c (fold_negate_expr): Handle vectors.
>>> (fold_truth_not_expr): Make it static.
>>> (invert_truthvalue_loc): Handle vectors. Do not call
>>> fold_truth_not_expr directly.
>>> (fold_unary_loc) : Handle vector comparisons.
>>> : Do not cast to boolean.
>>> (fold_comparison): Handle vector constants.
>>> (fold_ternary_loc) : Adapt more COND_EXPR
>>> optimizations.
>>> * tree.h (fold_truth_not_expr): Remove declaration.
>>>
>>>
>>> gcc/testsuite/
>>> * g++.dg/ext/vector22.C: New testcase.
>>> * gcc.dg/binop-xor3.c: Remove xfail.
>>>
>>> --
>>> Marc Glisse
>>> Index: gcc/fold-const.c
>>> ===
>>> --- gcc/fold-const.c(revision 198796)
>>> +++ gcc/fold-const.c(working copy)
>>> @@ -519,21 +519,21 @@ fold_negate_expr (location_t loc, tree t
>>>  {
>>>tree type = TREE_TYPE (t);
>>>tree tem;
>>>
>>>switch (TREE_CODE (t))
>>>  {
>>>  /* Convert - (~A) to A + 1.  */
>>>  case BIT_NOT_EXPR:
>>>if (INTEGRAL_TYPE_P (type))
>>>  return fold_build2_loc (loc, PLUS_EXPR, type, TREE_OPERAND (t,
>>> 0),
>>> -build_int_cst (type, 1));
>>> +build_one_cst (type));
>>>break;
>>>
>>>  case INTEGER_CST:
>>>tem = fold_negate_const (t, type);
>>>if (TREE_OVERFLOW (tem) == TREE_OVERFLOW (t)
>>>   || !TYPE_OVERFLOW_TRAPS (type))
>>> return tem;
>>>break;
>>>
>>>  case REAL_CST:
>>> @@ -3078,21 +3078,21 @@ omit_two_operands_loc (location_t loc, t
>>>  }
>>>
>>>
>>>  /* Return a simplified tree node for the truth-negation of ARG.  This
>>> never alters ARG itself.  We assume that ARG is an operation that
>>> returns a truth value (0 or 1).
>>>
>>> FIXME: one would think we would fold the result, but it causes
>>> problems with the dominator optimizer.  */
>>>
>>> -tree
>>> +static tree
>>>  fold_truth_not_expr (location_t loc, tree arg)
>>>  {
>>>tree type = TREE_TYPE (arg);
>>>enum tree_code code = TREE_CODE (arg);
>>>location_t loc1, loc2;
>>>
>>>/* If this is a comparison, we can simply invert it, except for
>>>   floating-point non-equality comparisons, in which case we just
>>>   enclose a TRUTH_NOT_EXPR around what we have.  */
>>>
>>> @@ -3215,38 +3215,33 @@ fold_truth_not_expr (location_t loc, tre
>>>return build1_loc (loc, CLEANUP_POINT_EXPR, type,
>>>  invert_truthvalue_loc (loc1, TREE_OPERAND (arg,
>>> 0)));
>>>
>>>  default:
>>>return NULL_TREE;
>>>  }
>>>  }
>>>
>>>  /* Return a simplified tree node for the truth-negation of ARG.  This
>>> never alters ARG itself.  We assume that ARG is an operation that
>>> -   returns a truth value (0 or 1).
>>> -
>>> -   FIXME: one would think we would fold the result, but it causes
>>> -   problems with the dominator optimizer.  */
>>> +   returns a truth value (0 or 1 for scalars, 0 or -1 for vectors).  */
>>>
>>>  tree
>>>  invert_truthvalue_loc (location_t loc, tree arg)
>>>  {
>>> -  tree tem;
>>> -
>>>if (TREE_CODE (arg) == ERROR_MARK)
>>>  return arg;
>>>
>>> -  tem = fold_truth_not_expr (loc, arg);
>>> -  if (!tem)
>>> -tem = build1_loc (loc, TRUTH_NOT_EXPR, TREE_TYPE (arg), arg);
>>> -
>>> -  return tem;
>>> +  tree type = TREE_TYPE (arg);
>>> +  return fold_build1_loc (loc, VECTOR_TYPE_P (type)
>>> +  ? BIT_NOT_EXPR
>>> +  : TRUTH_NOT_EXPR,
>>> + type, arg);
>>>  }
>>>
>>>  /* Given a bit-wise operation CODE applied to ARG0 and ARG1, see if both
>>> operands are another bit-wise operation with a common input.  If so,
>>> distribute the bit operations to save an operati

Re: sparc64*-*-rtems* should not define __svr4__

[Joel Sherrill]

I forgot to ask. Did you put this on the open branches as well? 4.7 and 4.8.

Please and thank you

Eric Botcazou  wrote:


> sparc64*-*-rtems* ends up with __svr4__ defined. The attached
> patch corrects that.

Let's remove the FIXME instead.  Applied to mainline.


2013-05-14  Eric Botcazou  

* config/sparc/sp64-elf.h (CPP_SUBTARGET_SPEC): Delete.
* config/sparc/openbsd64.h (CPP_SUBTARGET_SPEC): Likewise.


--
Eric Botcazou

Re: Restore m68k bootstrap

[Richard Biener]

On Tue, May 14, 2013 at 1:23 PM, Marc Glisse  wrote:
> Hello,
>
> in an earlier patch I apparently introduced a platform dependent signed /
> unsigned comparison, so here is a fix. I am taking the chance to fix the
> host_integerp second argument nearby: we want non-negative integers.
>
> Passes bootstrap+testsuite on x86_64-linux-gnu and apparently bootstrap on
> m68k.
>
> 2013-05-13  Marc Glisse  
>
> PR bootstrap/57266
> * fold-const.c (fold_binary_loc) : Use an unsigned
> variable for the shift amount. Check that we shift by non-negative
> amounts.
>
> --
> Marc Glisse
> Index: gcc/fold-const.c
> ===
> --- gcc/fold-const.c(revision 198853)
> +++ gcc/fold-const.c(working copy)
> @@ -12416,27 +12416,27 @@ fold_binary_loc (location_t loc,
> return fold_build2_loc (loc, code, type, op0, tem);
>
>/* Since negative shift count is not well-defined,
>  don't try to compute it in the compiler.  */
>if (TREE_CODE (arg1) == INTEGER_CST && tree_int_cst_sgn (arg1) < 0)
> return NULL_TREE;
>
>prec = element_precision (type);
>
>/* Turn (a OP c1) OP c2 into a OP (c1+c2).  */
> -  if (TREE_CODE (op0) == code && host_integerp (arg1, false)
> +  if (TREE_CODE (op0) == code && host_integerp (arg1, true)
>   && TREE_INT_CST_LOW (arg1) < prec
> - && host_integerp (TREE_OPERAND (arg0, 1), false)
> + && host_integerp (TREE_OPERAND (arg0, 1), true)
>   && TREE_INT_CST_LOW (TREE_OPERAND (arg0, 1)) < prec)

That looks good, but ...

> {
> - HOST_WIDE_INT low = (TREE_INT_CST_LOW (TREE_OPERAND (arg0, 1))
> -  + TREE_INT_CST_LOW (arg1));
> + unsigned int low = (TREE_INT_CST_LOW (TREE_OPERAND (arg0, 1))
> + + TREE_INT_CST_LOW (arg1));

that's wrong.  TREE_INT_CST_LOW doesn't fit in an unsigned int.
unsigned HOST_WIDE_INT would work though.

Ok with that change.

Thanks,
Richard.

>   /* Deal with a OP (c1 + c2) being undefined but (a OP c1) OP c2
>  being well defined.  */
>   if (low >= prec)
> {
>   if (code == LROTATE_EXPR || code == RROTATE_EXPR)
> low = low % prec;
>   else if (TYPE_UNSIGNED (type) || code == LSHIFT_EXPR)
> return omit_one_operand_loc (loc, type, build_zero_cst
> (type),
>  TREE_OPERAND (arg0, 0));
>

Re: Restore m68k bootstrap

[Marc Glisse]

On Tue, 14 May 2013, Richard Biener wrote:


On Tue, May 14, 2013 at 1:23 PM, Marc Glisse  wrote:

Hello,

in an earlier patch I apparently introduced a platform dependent signed /
unsigned comparison, so here is a fix. I am taking the chance to fix the
host_integerp second argument nearby: we want non-negative integers.

Passes bootstrap+testsuite on x86_64-linux-gnu and apparently bootstrap on
m68k.

2013-05-13  Marc Glisse  

PR bootstrap/57266
* fold-const.c (fold_binary_loc) : Use an unsigned
variable for the shift amount. Check that we shift by non-negative
amounts.

--
Marc Glisse
Index: gcc/fold-const.c
===
--- gcc/fold-const.c(revision 198853)
+++ gcc/fold-const.c(working copy)
@@ -12416,27 +12416,27 @@ fold_binary_loc (location_t loc,
return fold_build2_loc (loc, code, type, op0, tem);

   /* Since negative shift count is not well-defined,
 don't try to compute it in the compiler.  */
   if (TREE_CODE (arg1) == INTEGER_CST && tree_int_cst_sgn (arg1) < 0)
return NULL_TREE;

   prec = element_precision (type);

   /* Turn (a OP c1) OP c2 into a OP (c1+c2).  */
-  if (TREE_CODE (op0) == code && host_integerp (arg1, false)
+  if (TREE_CODE (op0) == code && host_integerp (arg1, true)
  && TREE_INT_CST_LOW (arg1) < prec
- && host_integerp (TREE_OPERAND (arg0, 1), false)
+ && host_integerp (TREE_OPERAND (arg0, 1), true)
  && TREE_INT_CST_LOW (TREE_OPERAND (arg0, 1)) < prec)


That looks good, but ...


{
- HOST_WIDE_INT low = (TREE_INT_CST_LOW (TREE_OPERAND (arg0, 1))
-  + TREE_INT_CST_LOW (arg1));
+ unsigned int low = (TREE_INT_CST_LOW (TREE_OPERAND (arg0, 1))
+ + TREE_INT_CST_LOW (arg1));


that's wrong.  TREE_INT_CST_LOW doesn't fit in an unsigned int.
unsigned HOST_WIDE_INT would work though.


The checks above show that both TREE_INT_CST_LOW are smaller than prec 
(for which I already used an unsigned int, but an unsigned char might have 
been enough until Kenneth introduces int512_t). Do you still want the 
change?



Ok with that change.

Thanks,
Richard.


  /* Deal with a OP (c1 + c2) being undefined but (a OP c1) OP c2
 being well defined.  */
  if (low >= prec)
{
  if (code == LROTATE_EXPR || code == RROTATE_EXPR)
low = low % prec;
  else if (TYPE_UNSIGNED (type) || code == LSHIFT_EXPR)
return omit_one_operand_loc (loc, type, build_zero_cst
(type),
 TREE_OPERAND (arg0, 0));


--
Marc Glisse

Re: More vector folding

[Marc Glisse]

On Tue, 14 May 2013, Richard Biener wrote:


On Mon, May 13, 2013 at 1:40 PM, Marc Glisse  wrote:

On Mon, 13 May 2013, Richard Biener wrote:


On Sat, May 11, 2013 at 11:38 AM, Marc Glisse 
wrote:

@@ -8274,28 +8269,34 @@ fold_unary_loc (location_t loc, enum tre
{
  elem = VECTOR_CST_ELT (arg0, i);
  elem = fold_unary_loc (loc, BIT_NOT_EXPR, TREE_TYPE (type),
elem);
  if (elem == NULL_TREE)
break;
  elements[i] = elem;
}
  if (i == count)
return build_vector (type, elements);
}
+  else if (COMPARISON_CLASS_P (arg0) && VECTOR_INTEGER_TYPE_P
(type))
+   {
+ tree op_type = TREE_TYPE (TREE_OPERAND (arg0, 0));
+ enum tree_code subcode = invert_tree_comparison (TREE_CODE
(arg0),
+HONOR_NANS (TYPE_MODE (op_type)));
+ if (subcode != ERROR_MARK)
+   return build2_loc (loc, subcode, type, TREE_OPERAND (arg0,
0),
+  TREE_OPERAND (arg0, 1));
+   }
+



I wonder why you restrict this to VECTOR_INTEGER_TYPE_P - for
TYPE_PRECISION == 1 type this should work, too.



If TYPE_PRECISION == 1, wouldn't it be better to turn BIT_NOT_EXPR into
TRUTH_NOT_EXPR? Then it will be handled by fold_truth_not_expr.


Hmm, not sure - on GIMPLE we are no longer having the TRUTH_* tree
codes, so we don't want to fold BIT_* to TRUTH_*.


!
I had never noticed that...


Also there should
never be a comparison resulting in a non-integer vector type, no?



Yes, I was going to write VECTOR_TYPE_P, and adding integer seemed more
explicit, but I can go back.


Works for me.


   return NULL_TREE;

 case TRUTH_NOT_EXPR:
-  /* The argument to invert_truthvalue must have Boolean type.  */
-  if (TREE_CODE (TREE_TYPE (arg0)) != BOOLEAN_TYPE)
-  arg0 = fold_convert_loc (loc, boolean_type_node, arg0);
-
   /* Note that the operand of this must be an int
 and its values must be 0 or 1.
 ("true" is a fixed value perhaps depending on the language,
 but we don't handle values other than 1 correctly yet.)  */
   tem = fold_truth_not_expr (loc, arg0);
   if (!tem)
return NULL_TREE;
   return fold_convert_loc (loc, type, tem);

 case REALPART_EXPR:
@@ -9579,21 +9580,21 @@ fold_comparison (location_t loc, enum tr
 {
   tree cmp_type = TREE_TYPE (TREE_OPERAND (arg0, 0));
   return fold_build2_loc (loc, code, type,
  fold_convert_loc (loc, cmp_type,
TREE_OPERAND (arg1, 0)),
  TREE_OPERAND (arg0, 0));
 }

   /* Fold ~X op C as X op' ~C, where op' is the swapped comparison.  */
   if (TREE_CODE (arg0) == BIT_NOT_EXPR
-  && TREE_CODE (arg1) == INTEGER_CST)
+  && (TREE_CODE (arg1) == INTEGER_CST || TREE_CODE (arg1) ==
VECTOR_CST))
 {
   tree cmp_type = TREE_TYPE (TREE_OPERAND (arg0, 0));
   return fold_build2_loc (loc, swap_tree_comparison (code), type,
  TREE_OPERAND (arg0, 0),
  fold_build1_loc (loc, BIT_NOT_EXPR, cmp_type,
   fold_convert_loc (loc, cmp_type,
arg1)));
 }

   return NULL_TREE;
 }
@@ -14030,61 +14031,67 @@ fold_ternary_loc (location_t loc, enum t
return tem;
}

   if (COMPARISON_CLASS_P (arg0)
  && operand_equal_for_comparison_p (TREE_OPERAND (arg0, 0),
 op2,
 TREE_OPERAND (arg0, 1))
  && !HONOR_SIGNED_ZEROS (TYPE_MODE (TREE_TYPE (op2
{
  location_t loc0 = expr_location_or (arg0, loc);
- tem = fold_truth_not_expr (loc0, arg0);
+ tem = fold_unary_loc (loc0, VECTOR_TYPE_P (type)
+ ? BIT_NOT_EXPR
+ : TRUTH_NOT_EXPR,
+   TREE_TYPE (arg0), arg0);



since you don't restrict it here either 


  if (tem && COMPARISON_CLASS_P (tem))
{
  tem = fold_cond_expr_with_comparison (loc, type, tem, op2,
op1);
  if (tem)
return tem;
}
}

-  /* ???  Fixup the code below for VEC_COND_EXPR.  */
-  if (code == VEC_COND_EXPR)
-   return NULL_TREE;
-
   /* If the second operand is simpler than the third, swap them
 since that produces better jump optimization results.  */
   if (truth_value_p (TREE_CODE (arg0))
  && tree_swap_operands_p (op1, op2, false))
{
  location_t loc0 = expr_location_or (arg0, loc);
  /* See if this can be inverted.  If it can't, possibly because
 it was a floating-point inequality comparison, don't do
 anything.  */
- tem = fold_truth_not_expr (loc0, arg0);
+ tem = fold_unary_loc (loc0, VECTOR_TYPE_P

Re: Restore m68k bootstrap

[Richard Biener]

On Tue, May 14, 2013 at 1:34 PM, Marc Glisse  wrote:
> On Tue, 14 May 2013, Richard Biener wrote:
>
>> On Tue, May 14, 2013 at 1:23 PM, Marc Glisse  wrote:
>>>
>>> Hello,
>>>
>>> in an earlier patch I apparently introduced a platform dependent signed /
>>> unsigned comparison, so here is a fix. I am taking the chance to fix the
>>> host_integerp second argument nearby: we want non-negative integers.
>>>
>>> Passes bootstrap+testsuite on x86_64-linux-gnu and apparently bootstrap
>>> on
>>> m68k.
>>>
>>> 2013-05-13  Marc Glisse  
>>>
>>> PR bootstrap/57266
>>> * fold-const.c (fold_binary_loc) : Use an unsigned
>>> variable for the shift amount. Check that we shift by
>>> non-negative
>>> amounts.
>>>
>>> --
>>> Marc Glisse
>>> Index: gcc/fold-const.c
>>> ===
>>> --- gcc/fold-const.c(revision 198853)
>>> +++ gcc/fold-const.c(working copy)
>>> @@ -12416,27 +12416,27 @@ fold_binary_loc (location_t loc,
>>> return fold_build2_loc (loc, code, type, op0, tem);
>>>
>>>/* Since negative shift count is not well-defined,
>>>  don't try to compute it in the compiler.  */
>>>if (TREE_CODE (arg1) == INTEGER_CST && tree_int_cst_sgn (arg1) <
>>> 0)
>>> return NULL_TREE;
>>>
>>>prec = element_precision (type);
>>>
>>>/* Turn (a OP c1) OP c2 into a OP (c1+c2).  */
>>> -  if (TREE_CODE (op0) == code && host_integerp (arg1, false)
>>> +  if (TREE_CODE (op0) == code && host_integerp (arg1, true)
>>>   && TREE_INT_CST_LOW (arg1) < prec
>>> - && host_integerp (TREE_OPERAND (arg0, 1), false)
>>> + && host_integerp (TREE_OPERAND (arg0, 1), true)
>>>   && TREE_INT_CST_LOW (TREE_OPERAND (arg0, 1)) < prec)
>>
>>
>> That looks good, but ...
>>
>>> {
>>> - HOST_WIDE_INT low = (TREE_INT_CST_LOW (TREE_OPERAND (arg0, 1))
>>> -  + TREE_INT_CST_LOW (arg1));
>>> + unsigned int low = (TREE_INT_CST_LOW (TREE_OPERAND (arg0, 1))
>>> + + TREE_INT_CST_LOW (arg1));
>>
>>
>> that's wrong.  TREE_INT_CST_LOW doesn't fit in an unsigned int.
>> unsigned HOST_WIDE_INT would work though.
>
>
> The checks above show that both TREE_INT_CST_LOW are smaller than prec (for
> which I already used an unsigned int, but an unsigned char might have been
> enough until Kenneth introduces int512_t). Do you still want the change?

Ah, ok.  No, fine without the change.

Thanks,
Richard.

>
>> Ok with that change.
>>
>> Thanks,
>> Richard.
>>
>>>   /* Deal with a OP (c1 + c2) being undefined but (a OP c1) OP c2
>>>  being well defined.  */
>>>   if (low >= prec)
>>> {
>>>   if (code == LROTATE_EXPR || code == RROTATE_EXPR)
>>> low = low % prec;
>>>   else if (TYPE_UNSIGNED (type) || code == LSHIFT_EXPR)
>>> return omit_one_operand_loc (loc, type, build_zero_cst
>>> (type),
>>>  TREE_OPERAND (arg0, 0));
>
>
> --
> Marc Glisse

Re: More vector folding

[Richard Biener]

On Tue, May 14, 2013 at 1:47 PM, Marc Glisse  wrote:
> On Tue, 14 May 2013, Richard Biener wrote:
>
>> On Mon, May 13, 2013 at 1:40 PM, Marc Glisse  wrote:
>>>
>>> On Mon, 13 May 2013, Richard Biener wrote:
>>>
 On Sat, May 11, 2013 at 11:38 AM, Marc Glisse 
 wrote:
>
> @@ -8274,28 +8269,34 @@ fold_unary_loc (location_t loc, enum tre
> {
>   elem = VECTOR_CST_ELT (arg0, i);
>   elem = fold_unary_loc (loc, BIT_NOT_EXPR, TREE_TYPE
> (type),
> elem);
>   if (elem == NULL_TREE)
> break;
>   elements[i] = elem;
> }
>   if (i == count)
> return build_vector (type, elements);
> }
> +  else if (COMPARISON_CLASS_P (arg0) && VECTOR_INTEGER_TYPE_P
> (type))
> +   {
> + tree op_type = TREE_TYPE (TREE_OPERAND (arg0, 0));
> + enum tree_code subcode = invert_tree_comparison (TREE_CODE
> (arg0),
> +HONOR_NANS (TYPE_MODE (op_type)));
> + if (subcode != ERROR_MARK)
> +   return build2_loc (loc, subcode, type, TREE_OPERAND (arg0,
> 0),
> +  TREE_OPERAND (arg0, 1));
> +   }
> +



 I wonder why you restrict this to VECTOR_INTEGER_TYPE_P - for
 TYPE_PRECISION == 1 type this should work, too.
>>>
>>>
>>>
>>> If TYPE_PRECISION == 1, wouldn't it be better to turn BIT_NOT_EXPR into
>>> TRUTH_NOT_EXPR? Then it will be handled by fold_truth_not_expr.
>>
>>
>> Hmm, not sure - on GIMPLE we are no longer having the TRUTH_* tree
>> codes, so we don't want to fold BIT_* to TRUTH_*.
>
>
> !
> I had never noticed that...
>
>
 Also there should
 never be a comparison resulting in a non-integer vector type, no?
>>>
>>>
>>>
>>> Yes, I was going to write VECTOR_TYPE_P, and adding integer seemed more
>>> explicit, but I can go back.
>>
>>
>> Works for me.
>>
>return NULL_TREE;
>
>  case TRUTH_NOT_EXPR:
> -  /* The argument to invert_truthvalue must have Boolean type.  */
> -  if (TREE_CODE (TREE_TYPE (arg0)) != BOOLEAN_TYPE)
> -  arg0 = fold_convert_loc (loc, boolean_type_node, arg0);
> -
>/* Note that the operand of this must be an int
>  and its values must be 0 or 1.
>  ("true" is a fixed value perhaps depending on the language,
>  but we don't handle values other than 1 correctly yet.)  */
>tem = fold_truth_not_expr (loc, arg0);
>if (!tem)
> return NULL_TREE;
>return fold_convert_loc (loc, type, tem);
>
>  case REALPART_EXPR:
> @@ -9579,21 +9580,21 @@ fold_comparison (location_t loc, enum tr
>  {
>tree cmp_type = TREE_TYPE (TREE_OPERAND (arg0, 0));
>return fold_build2_loc (loc, code, type,
>   fold_convert_loc (loc, cmp_type,
> TREE_OPERAND (arg1, 0)),
>   TREE_OPERAND (arg0, 0));
>  }
>
>/* Fold ~X op C as X op' ~C, where op' is the swapped comparison.
> */
>if (TREE_CODE (arg0) == BIT_NOT_EXPR
> -  && TREE_CODE (arg1) == INTEGER_CST)
> +  && (TREE_CODE (arg1) == INTEGER_CST || TREE_CODE (arg1) ==
> VECTOR_CST))
>  {
>tree cmp_type = TREE_TYPE (TREE_OPERAND (arg0, 0));
>return fold_build2_loc (loc, swap_tree_comparison (code), type,
>   TREE_OPERAND (arg0, 0),
>   fold_build1_loc (loc, BIT_NOT_EXPR, cmp_type,
>fold_convert_loc (loc, cmp_type,
> arg1)));
>  }
>
>return NULL_TREE;
>  }
> @@ -14030,61 +14031,67 @@ fold_ternary_loc (location_t loc, enum t
> return tem;
> }
>
>if (COMPARISON_CLASS_P (arg0)
>   && operand_equal_for_comparison_p (TREE_OPERAND (arg0, 0),
>  op2,
>  TREE_OPERAND (arg0, 1))
>   && !HONOR_SIGNED_ZEROS (TYPE_MODE (TREE_TYPE (op2
> {
>   location_t loc0 = expr_location_or (arg0, loc);
> - tem = fold_truth_not_expr (loc0, arg0);
> + tem = fold_unary_loc (loc0, VECTOR_TYPE_P (type)
> + ? BIT_NOT_EXPR
> + : TRUTH_NOT_EXPR,
> +   TREE_TYPE (arg0), arg0);



 since you don't restrict it here either 

>   if (tem && COMPARISON_CLASS_P (tem))
> {
>   tem = fold_cond_expr_with_comparison (loc, type, tem,
> op2,
> op1);
>   if (tem)
>   

[build, doc] Obsolete Solaris 9 support

[Rainer Orth]

I think the time has come to obsolete Solaris 9 support:

* According to
  http://www.oracle.com/us/support/library/lsp-coverage-sun-software-309122.pdf,
  p.17, Premier Support has already ended in October 2011 and even
  Extended Support will end in October 2014, which means it's impossible
  to get patches without a special contract.  By the time GCC 4.10 is
  expected to be released (Spring 2015), this period is well past.  This
  timescale is in line with what happened for Solaris 7 (obsoleted in
  GCC 4.5) and Solaris 8 (obsoleted in GCC 4.7).

* Solaris 9 seems to be far less popular than Solaris 8 was: last time I
  checked there was only a single Solaris 9 testresults posting apart
  from my own.

* By the time Solaris 12 appears, I'll need to reduce the testing matrix
  to keep the amount of work manageable.

Therefore the following patch does just that.  Tested by
configuring/building without and with --enable-obsolete and checking
gccinstall.info on i386-pc-solaris2.9.  The config-list.mk part is
untested, but should be straightforward.

Unless there are strong objections, I plan to install this patch in a
day or two.

Rainer


2013-05-14  Rainer Orth  

gcc:
* config.gcc: Obsolete *-*-solaris2.9*.
* doc/install.texi (Specific, *-*-solaris2*): Document it.

contrib:
* config-list.mk (LIST): Add -enable-obsolete for
sparc-sun-solaris2.9, i686-solaris2.9.

# HG changeset patch
# Parent 8dd34f8a37b7d71d46c5299a2d6dd8189d0867f9
Obsolete Solaris 9 support

diff --git a/contrib/config-list.mk b/contrib/config-list.mk
--- a/contrib/config-list.mk
+++ b/contrib/config-list.mk
@@ -67,7 +67,8 @@ LIST = aarch64-elf aarch64-linux-gnu \
   x86_64-elfOPT-with-fpmath=sse x86_64-freebsd6 x86_64-netbsd \
   x86_64-knetbsd-gnu x86_64-w64-mingw32 \
   x86_64-mingw32OPT-enable-sjlj-exceptions=yes xstormy16-elf xtensa-elf \
-  xtensa-linux sparc-sun-solaris2.9 i686-solaris2.9 \
+  xtensa-linux \
+  sparc-sun-solaris2.9OPT-enable-obsolete i686-solaris2.9OPT-enable-obsolete \
   i686-interix3OPT-enable-obsolete score-elfOPT-enable-obsolete
 
 LOGFILES = $(patsubst %,log/%-make.out,$(LIST))
diff --git a/gcc/config.gcc b/gcc/config.gcc
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -246,6 +246,7 @@ md_file=
 case ${target} in
picochip-*\
  | score-*\
+ | *-*-solaris2.9*			\
  )
 if test "x$enable_obsolete" != xyes; then
   echo "*** Configuration ${target} is obsolete." >&2
diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
--- a/gcc/doc/install.texi
+++ b/gcc/doc/install.texi
@@ -4068,8 +4068,10 @@ supported as cross-compilation target on
 @c alone is too unspecific and must be avoided.
 @heading @anchor{x-x-solaris2}*-*-solaris2*
 
-Support for Solaris 8 has removed in GCC 4.8.  Support for Solaris 7 has
-been removed in GCC 4.6.
+Support for Solaris 9 has been obsoleted in GCC 4.9, but can still be
+enabled by configuring with @option{--enable-obsolete}.  Support will be
+removed in GCC 4.10.  Support for Solaris 8 has removed in GCC 4.8.
+Support for Solaris 7 has been removed in GCC 4.6.
 
 Sun does not ship a C compiler with Solaris 2 before Solaris 10, though
 you can download the Sun Studio compilers for free.  In Solaris 10 and

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

Re: [AARCH64] Set "simd" attribute for *movdi_aarch64 pattern

[Marcus Shawcroft]

On 14/05/13 12:11, Sofiane Naci wrote:

Hi,

This patch defines the "simd" attribute for the *movdi_aarch64 pattern.
Tested successfully with a full regression run on aarch64-elf.

OK for trunk?

Thanks
Sofiane



OK
/Marcus

Re: [v3] Fix libstdc++/54577

[Paolo Carlini]

On 05/10/2013 04:17 PM, Paolo Carlini wrote:
this is the issue about the signatures of the erase member functions 
of the sequence containers. Mostly rather straightfoward stuff within 
the limits of the current infrastructure: the various _M_const_case 
are normally simple enough, I only mention the rather ugly std::vector 
one, required otherwise an ext_pointer testcase fails: I suppose that 
handling these issues in a proper way will happen together with 
changing the vector::pointer typedef to the conforming:


typedef typename _Alloc_traits::pointer  pointer;
Oops, the PR that Jonathan just filed made me notice that in fact 
std::vector must be correct, because _Base::pointer actually means using 
_Alloc_traits.


Then I suppose that the correct way to move forward to C++11 the 
ext/pointer.h stuff would be adding a pointer_traits specialization for 
those pointer-like types, which would also wrap the cast operations in 
pointer_to. Then, in __normal_iterator::_M_const_cast use pointer_traits.


Paolo.

Re: [C++ Patch] PR 53903

[Jason Merrill]

OK.

Jason

Re: C++ PATCH for c++/56998 (ICE with call in C++03 mode)

[Jason Merrill]

On 05/13/2013 03:36 PM, Jakub Jelinek wrote:

What about the 4 other
maybe_constant_value on fold_non_dependent_expr_sfinae (something, tf_none)
calls in typeck.c (two for -Wdiv-by-zero and two for shift diagnostics)?


You're right, that was a poor approach to fixing the bug.  This one 
properly fixes potential_constant_expression to recognize that the 
expression can't be constant, so it never gets to 
value_dependent_expression.


commit 24c19b3d38977fafbf870ef2ea45d05f37feb36a
Author: Jason Merrill 
Date:   Mon May 13 17:09:36 2013 -0400

	PR c++/56998
	* semantics.c (potential_constant_expression_1): Make sure the
	called function is potentially constant.
	* call.c (null_ptr_cst_p): Revert earlier change.

diff --git a/gcc/cp/call.c b/gcc/cp/call.c
index 9f3a50d..bd8f531 100644
--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -554,7 +554,7 @@ null_ptr_cst_p (tree t)
   if (CP_INTEGRAL_TYPE_P (TREE_TYPE (t)))
 {
   /* Core issue 903 says only literal 0 is a null pointer constant.  */
-  if (cxx_dialect < cxx0x && !TREE_SIDE_EFFECTS (t))
+  if (cxx_dialect < cxx0x)
 	t = maybe_constant_value (fold_non_dependent_expr_sfinae (t, tf_none));
   STRIP_NOPS (t);
   if (integer_zerop (t) && !TREE_OVERFLOW (t))
diff --git a/gcc/cp/semantics.c b/gcc/cp/semantics.c
index 3e78887..92a4917 100644
--- a/gcc/cp/semantics.c
+++ b/gcc/cp/semantics.c
@@ -8476,7 +8476,11 @@ potential_constant_expression_1 (tree t, bool want_rval, tsubst_flags_t flags)
 		  }
 	  }
 	else
-	  fun = get_first_fn (fun);
+	  {
+		if (!potential_constant_expression_1 (fun, true, flags))
+		  return false;
+		fun = get_first_fn (fun);
+	  }
 	/* Skip initial arguments to base constructors.  */
 	if (DECL_BASE_CONSTRUCTOR_P (fun))
 	  i = num_artificial_parms_for (fun);

Re: [v3] Fix libstdc++/54577

[Paolo Carlini]

On 05/14/2013 02:40 PM, Paolo Carlini wrote:
Then I suppose that the correct way to move forward to C++11 the 
ext/pointer.h stuff would be adding a pointer_traits specialization 
for those pointer-like types, which would also wrap the cast 
operations in pointer_to. Then, in __normal_iterator::_M_const_cast 
use pointer_traits.
... and even more interestingly, looks like Jonathan already did most of 
this, at the end of ext/pointer.h. Oh my ;)


Paolo.

Re: new port: msp430-elf, revision 2

[nick clifton]

Hi Steven,

> Should new ports be allowed in if they rely so heavily on reload?

As it happens I am currently working on enabling LRA for the MSP430 
target.  Although I have run into a roadblock with a possibly 
unacceptable patch to simplify_subreg_regno:


  http://gcc.gnu.org/ml/gcc-patches/2013-05/msg00135.html

The LRA conversion is a work in progress however, and one that does not 
have my highest priority, so we would really like to have the current 
reload-heavy version accepted.  The current version works, and it will 
be converted to LRA in the future, so is it really necessary to block 
its adoption now ?


Cheers
  Nick

Re: [testsuite] Fix gcc.dg/fstack-protector-strong.c on Solaris/x86

[Jeff Law]

On 05/14/2013 04:31 AM, Jakub Jelinek wrote:

On Tue, May 14, 2013 at 12:26:31PM +0200, Rainer Orth wrote:

Tested with the appropriate runtest invocations on i386-pc-solaris2.11
and x86_64-unknown-linux-gnu, installed on mainline.


I'd say the test should just use __builtin_alloca instead.

Yea, let's go with that.  OK with that fix.  I


Ranier, if you run into others, they're pre-approved to be fixed this 
way as well.


jeff

Re: [testsuite] Fix gcc.dg/fstack-protector-strong.c on Solaris/x86

[Rainer Orth]

Jeff Law  writes:

> On 05/14/2013 04:31 AM, Jakub Jelinek wrote:
>> On Tue, May 14, 2013 at 12:26:31PM +0200, Rainer Orth wrote:
>>> Tested with the appropriate runtest invocations on i386-pc-solaris2.11
>>> and x86_64-unknown-linux-gnu, installed on mainline.
>>
>> I'd say the test should just use __builtin_alloca instead.
> Yea, let's go with that.  OK with that fix.  I

Here's what I installed, tested as before:

2013-05-14  Rainer Orth  

* gcc.dg/fstack-protector-strong.c: Don't include .
(alloca): Remove declaration.
(foo9): Replace alloca by __builtin_alloca.

changeset:   7864:f9b5472f0ad7
tag: tip
user:Rainer Orth 
date:Tue May 14 15:10:31 2013 +0200
summary: Use __builtin_alloca in gcc.dg/fstack-protector-strong.c

diff --git a/gcc/testsuite/gcc.dg/fstack-protector-strong.c b/gcc/testsuite/gcc.dg/fstack-protector-strong.c
--- a/gcc/testsuite/gcc.dg/fstack-protector-strong.c
+++ b/gcc/testsuite/gcc.dg/fstack-protector-strong.c
@@ -4,9 +4,6 @@
 /* { dg-options "-O2 -fstack-protector-strong" } */
 
 #include
-#include
-
-extern void *alloca(__SIZE_TYPE__);
 
 extern int g0;
 extern int* pg0;
@@ -112,7 +109,7 @@ foo8 ()
 int
 foo9 ()
 {
-  char* p = alloca (100);
+  char* p = __builtin_alloca (100);
   return goo ((int *)(p + 50));
 }
 


> Ranier, if you run into others, they're pre-approved to be fixed this way
> as well.

The one above is the only one that currently fails on Solaris.

Rainer

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

[PATCH] Backport r192458 to gcc-4_7-branch

[Evgeniy Stepanov]

Hi,

this patch merges r192458 into gcc-4_7 to fix separate configure/build
of libstdc++.

A bit of history: a similar patch was committed to trunk & 4.7 back in
Oct'12, then reverted from both, than this patch was committed to
trunk only. I wonder if it was simply lost for some reason?

Is it OK for backporting to 4.7?


gthr.patch
Description: Binary data

Re: [PATCH] Backport r192458 to gcc-4_7-branch

[Jonathan Wakely]

On 14 May 2013 14:14, Evgeniy Stepanov wrote:
> Hi,
>
> this patch merges r192458 into gcc-4_7 to fix separate configure/build
> of libstdc++.
>
> A bit of history: a similar patch was committed to trunk & 4.7 back in
> Oct'12, then reverted from both, than this patch was committed to
> trunk only. I wonder if it was simply lost for some reason?
>
> Is it OK for backporting to 4.7?

I'd like to know what problem it solves and why it was reverted before
making that change on a stable release branch.

Re: [PATCH] Backport r192458 to gcc-4_7-branch

[Paolo Carlini]

On 05/14/2013 03:24 PM, Jonathan Wakely wrote:
I'd like to know what problem it solves and why it was reverted before 
making that change on a stable release branch. 

Indeed.

And please always post a clear ChangeLog and don't post regenerated 
files, which are normally big and only add to the confusion.


Paolo.

Re: [PATCH] Backport r192458 to gcc-4_7-branch

[Evgeniy Stepanov]

This is the original thread:
http://gcc.gnu.org/ml/gcc-patches/2012-10/msg00525.html

This exact patch was never reverted. It seems to be a second attempt,
that was only applied to trunk that time. I'm cc-ing the original
author.

Smaller patch attached.

* config/gthr.m4: New. Define GCC_AC_THREAD_HEADER.
* libgcc/configure: Regenerate.
* libgcc/configure.ac: Replace code with GCC_AC_THREAD_HEADER use.
* libstdc++-v3/Makefile.in: Regenerate.
* libstdc++-v3/acinclude.m4: Replace code with
GCC_AC_THREAD_HEADER use.
* libstdc++-v3/configure: Regenerate.
* libstdc++-v3/doc/Makefile.in: Regenerate.
* libstdc++-v3/include/Makefile.am: Regenerate.
* libstdc++-v3/include/Makefile.in: Rename variable.
* libstdc++-v3/libsupc++/Makefile.in: Regenerate.
* libstdc++-v3/po/Makefile.in: Regenerate.
* libstdc++-v3/python/Makefile.in: Regenerate.
* libstdc++-v3/src/Makefile.in: Regenerate.
* libstdc++-v3/src/c++11/Makefile.in: Regenerate.
* libstdc++-v3/src/c++98/Makefile.in: Regenerate.
* libstdc++-v3/testsuite/Makefile.in: Regenerate.


On Tue, May 14, 2013 at 5:24 PM, Jonathan Wakely  wrote:
> On 14 May 2013 14:14, Evgeniy Stepanov wrote:
>> Hi,
>>
>> this patch merges r192458 into gcc-4_7 to fix separate configure/build
>> of libstdc++.
>>
>> A bit of history: a similar patch was committed to trunk & 4.7 back in
>> Oct'12, then reverted from both, than this patch was committed to
>> trunk only. I wonder if it was simply lost for some reason?
>>
>> Is it OK for backporting to 4.7?
>
> I'd like to know what problem it solves and why it was reverted before
> making that change on a stable release branch.


gthr.patch
Description: Binary data

Re: [gomp4] Basic vectorization enablement for #pragma omp simd

[Jakub Jelinek]

On Tue, May 14, 2013 at 12:16:07PM +0200, Richard Biener wrote:
> Works for me.

...

Ok, here is what I've committed to gomp-4_0-branch.
tree-vect-data-refs.c was kept (almost) unchanged, as per IRC discussion,
something ++todo for the future.

2013-05-14  Jakub Jelinek  

* cfgloop.h (struct loop): Add safelen and force_vect fields.
* function.h (struct function): Add has_force_vect_loops field.
* omp-low.c (expand_omp_simd): If !broken_loop, create loop for
the simd region and set safelen and force_vect fields in it.
* tree-vectorizer.c (vectorize_loops): If loop has force_vect set,
vectorize it even if flag_vectorize isn't set.  Clear loop->force_vect
after vectorization.
* tree-ssa-loop.c (gate_tree_vectorize): Return true even
cfun->has_force_vect_loops.
* tree-ssa-loop-ivcanon.c (tree_unroll_loops_completely_1): Don't
unroll loops with loop->force_vect.
* tree-vect-data-refs.c (vect_analyze_data_ref_dependence): For
unknown or bad data dependency, if loop->safelen is non-zero, just
decrease *max_vf to loop->safelen if needed and return false.
* tree-if-conv.c (main_tree_if_conversion): If-convert also loops with
loop->force_vect.
(gate_tree_if_conversion): Return true even if
cfun->has_force_vect_loops.

--- gcc/cfgloop.h.jj2013-05-13 16:49:44.0 +0200
+++ gcc/cfgloop.h   2013-05-14 13:59:47.179036079 +0200
@@ -168,6 +168,15 @@ struct GTY ((chain_next ("%h.next"))) lo
  describes what is the state of the estimation.  */
   enum loop_estimation estimate_state;
 
+  /* If > 0, an integer, where the user asserted that for any
+ I in [ 0, nb_iterations ) and for any J in
+ [ I, min ( I + safelen, nb_iterations ) ), the Ith and Jth iterations
+ of the loop can be safely evaluated concurrently.  */
+  int safelen;
+
+  /* True if we should try harder to vectorize this loop.  */
+  bool force_vect;
+
   /* Upper bound on number of iterations of a loop.  */
   struct nb_iter_bound *bounds;
 
--- gcc/function.h.jj   2013-05-13 16:49:03.0 +0200
+++ gcc/function.h  2013-05-14 14:06:31.102720074 +0200
@@ -641,6 +641,10 @@ struct GTY(()) function {
  adjusts one of its arguments and forwards to another
  function.  */
   unsigned int is_thunk : 1;
+
+  /* Nonzero if the current function contains any loops with
+ loop->force_vect set.  */
+  unsigned int has_force_vect_loops : 1;
 };
 
 /* Add the decl D to the local_decls list of FUN.  */
--- gcc/omp-low.c.jj2013-05-13 16:37:05.0 +0200
+++ gcc/omp-low.c   2013-05-14 14:54:43.154188242 +0200
@@ -4960,6 +4960,8 @@ expand_omp_simd (struct omp_region *regi
   edge e, ne;
   tree *counts = NULL;
   int i;
+  tree safelen = find_omp_clause (gimple_omp_for_clauses (fd->for_stmt),
+ OMP_CLAUSE_SAFELEN);
 
   type = TREE_TYPE (fd->loop.v);
   entry_bb = region->entry;
@@ -5157,6 +5159,34 @@ expand_omp_simd (struct omp_region *regi
   set_immediate_dominator (CDI_DOMINATORS, l1_bb, entry_bb);
   set_immediate_dominator (CDI_DOMINATORS, l2_bb, l1_bb);
   set_immediate_dominator (CDI_DOMINATORS, l0_bb, l1_bb);
+
+  if (!broken_loop)
+{
+  struct loop *loop = alloc_loop ();
+  loop->header = l1_bb;
+  loop->latch = e->dest;
+  add_loop (loop, l1_bb->loop_father);
+  if (safelen == NULL_TREE)
+   loop->safelen = INT_MAX;
+  else
+   {
+ safelen = OMP_CLAUSE_SAFELEN_EXPR (safelen);
+ if (!host_integerp (safelen, 1)
+ || (unsigned HOST_WIDE_INT) tree_low_cst (safelen, 1)
+> INT_MAX)
+   loop->safelen = INT_MAX;
+ else
+   loop->safelen = tree_low_cst (safelen, 1);
+   }
+  /* If not -fno-tree-vectorize, hint that we want to vectorize
+the loop.  */
+  if (flag_tree_vectorize
+ || !global_options_set.x_flag_tree_vectorize)
+   {
+ loop->force_vect = true;
+ cfun->has_force_vect_loops = true;
+   }
+}
 }
 
 
--- gcc/tree-vectorizer.c.jj2013-05-13 16:49:03.0 +0200
+++ gcc/tree-vectorizer.c   2013-05-14 14:13:43.434236251 +0200
@@ -101,7 +101,8 @@ vectorize_loops (void)
  than all previously defined loops.  This fact allows us to run
  only over initial loops skipping newly generated ones.  */
   FOR_EACH_LOOP (li, loop, 0)
-if (optimize_loop_nest_for_speed_p (loop))
+if ((flag_tree_vectorize && optimize_loop_nest_for_speed_p (loop))
+   || loop->force_vect)
   {
loop_vec_info loop_vinfo;
vect_location = find_loop_location (loop);
@@ -122,6 +123,9 @@ vectorize_loops (void)
LOC_FILE (vect_location), LOC_LINE (vect_location));
vect_transform_loop (loop_vinfo);
num_vectorized_loops++;
+   /* Now that the loop has been vectorized, allow it to be unrolled
+  etc.  */
+   loop->

Re: [v3] Fix libstdc++/54577

[Jonathan Wakely]

On 14 May 2013 13:51, Paolo Carlini wrote:
> On 05/14/2013 02:40 PM, Paolo Carlini wrote:
>>
>> Then I suppose that the correct way to move forward to C++11 the
>> ext/pointer.h stuff would be adding a pointer_traits specialization for
>> those pointer-like types, which would also wrap the cast operations in
>> pointer_to. Then, in __normal_iterator::_M_const_cast use pointer_traits.
>
> ... and even more interestingly, looks like Jonathan already did most of
> this, at the end of ext/pointer.h. Oh my ;)

I forgot that I had marked your first mail in this thread, meaning to
come back to it when I had time to understand the vector::pointer
issue that I supposedly had under control :-)

I'd forgotten about the existence of __const_pointer_cast etc. in
 ... I agree that in C++11 mode
__normal_iterator::_M_const_cast should not rely on the existence of a
get() member on the custom pointer, because that's not required to
exist, and you can do it like this instead:

using PT = pointer_traits;
auto to = PT::pointer_to(const_cast(*from));

[AArch64] Fix vcond where comparison and result have different types.

[James Greenhalgh]

Hi,

For a statement like:

  INT = FLOAT > FLOAT ? INT : INT.

The vcond implementation in AArch64 is broken. We will try to force
the INT value to a FLOAT register and will ICE.

This patch fixes this.

Regression suite run for aarch64-none-elf with no regressions,
and more cases added to the testsuite to ensure this is caught
in future.

Thanks,
James Greenhalgh

---
gcc/

* config/aarch64/aarch64-simd.md
(aarch64_vcond_internal): Rename to...
(aarch64_vcond_internal): ...This, for integer modes.
(aarch64_vcond_internal): ...This for
float modes. Clarify all iterator modes.
(vcond): Use new name for vcond expanders.
(vcond): Likewise.
(vcondu: Likewise.
* config/aarch64/iterators.md (VDQF_COND): New.

gcc/testsuite/

* gcc.target/aarch64/vect-fcm.x: Add cases testing
FLOAT cmp FLOAT ? INT : INT.
 * gcc.target/aarch64/vect-fcm-eq-d.c: Define IMODE.
 * gcc.target/aarch64/vect-fcm-eq-f.c: Likewise.
 * gcc.target/aarch64/vect-fcm-ge-d.c: Likewise.
 * gcc.target/aarch64/vect-fcm-ge-f.c: Likewise.
 * gcc.target/aarch64/vect-fcm-gt-d.c: Likewise.
 * gcc.target/aarch64/vect-fcm-gt-f.c: Likewise.
diff --git a/gcc/config/aarch64/aarch64-simd.md b/gcc/config/aarch64/aarch64-simd.md
index 5626b55..6bc7dd7 100644
--- a/gcc/config/aarch64/aarch64-simd.md
+++ b/gcc/config/aarch64/aarch64-simd.md
@@ -1725,7 +1725,7 @@
   DONE;
 })
 
-(define_expand "aarch64_vcond_internal"
+(define_expand "aarch64_vcond_internal"
   [(set (match_operand:VDQ 0 "register_operand")
 	(if_then_else:VDQ
 	  (match_operator 3 "comparison_operator"
@@ -1820,14 +1820,14 @@
   DONE;
 })
 
-(define_expand "aarch64_vcond_internal"
-  [(set (match_operand:VDQF 0 "register_operand")
+(define_expand "aarch64_vcond_internal"
+  [(set (match_operand:VDQF_COND 0 "register_operand")
 	(if_then_else:VDQF
 	  (match_operator 3 "comparison_operator"
 	[(match_operand:VDQF 4 "register_operand")
 	 (match_operand:VDQF 5 "nonmemory_operand")])
-	  (match_operand:VDQF 1 "nonmemory_operand")
-	  (match_operand:VDQF 2 "nonmemory_operand")))]
+	  (match_operand:VDQF_COND 1 "nonmemory_operand")
+	  (match_operand:VDQF_COND 2 "nonmemory_operand")))]
   "TARGET_SIMD"
 {
   int inverse = 0;
@@ -1835,8 +1835,8 @@
   int swap_bsl_operands = 0;
   rtx op1 = operands[1];
   rtx op2 = operands[2];
-  rtx mask = gen_reg_rtx (mode);
-  rtx tmp = gen_reg_rtx (mode);
+  rtx mask = gen_reg_rtx (mode);
+  rtx tmp = gen_reg_rtx (mode);
 
   rtx (*base_comparison) (rtx, rtx, rtx);
   rtx (*complimentary_comparison) (rtx, rtx, rtx);
@@ -1856,7 +1856,7 @@
   /* Fall through.  */
 default:
   if (!REG_P (operands[5]))
-	operands[5] = force_reg (mode, operands[5]);
+	operands[5] = force_reg (mode, operands[5]);
 }
 
   switch (GET_CODE (operands[3]))
@@ -1869,8 +1869,8 @@
 case UNGE:
 case ORDERED:
 case UNORDERED:
-  base_comparison = gen_aarch64_cmge;
-  complimentary_comparison = gen_aarch64_cmgt;
+  base_comparison = gen_aarch64_cmge;
+  complimentary_comparison = gen_aarch64_cmgt;
   break;
 case LE:
 case UNLE:
@@ -1878,14 +1878,14 @@
   /* Fall through.  */
 case GT:
 case UNGT:
-  base_comparison = gen_aarch64_cmgt;
-  complimentary_comparison = gen_aarch64_cmge;
+  base_comparison = gen_aarch64_cmgt;
+  complimentary_comparison = gen_aarch64_cmge;
   break;
 case EQ:
 case NE:
 case UNEQ:
-  base_comparison = gen_aarch64_cmeq;
-  complimentary_comparison = gen_aarch64_cmeq;
+  base_comparison = gen_aarch64_cmeq;
+  complimentary_comparison = gen_aarch64_cmeq;
   break;
 default:
   gcc_unreachable ();
@@ -1913,10 +1913,10 @@
 	  switch (GET_CODE (operands[3]))
 	{
 	case LT:
-	  base_comparison = gen_aarch64_cmlt;
+	  base_comparison = gen_aarch64_cmlt;
 	  break;
 	case LE:
-	  base_comparison = gen_aarch64_cmle;
+	  base_comparison = gen_aarch64_cmle;
 	  break;
 	default:
 	  /* Do nothing, other zero form cases already have the correct
@@ -1959,9 +1959,9 @@
 	 true iff !(a != b && a ORDERED b), swapping the operands to BSL
 	 will then give us (a == b ||  a UNORDERED b) as intended.  */
 
-  emit_insn (gen_aarch64_cmgt (mask, operands[4], operands[5]));
-  emit_insn (gen_aarch64_cmgt (tmp, operands[5], operands[4]));
-  emit_insn (gen_ior3 (mask, mask, tmp));
+  emit_insn (gen_aarch64_cmgt (mask, operands[4], operands[5]));
+  emit_insn (gen_aarch64_cmgt (tmp, operands[5], operands[4]));
+  emit_insn (gen_ior3 (mask, mask, tmp));
   swap_bsl_operands = 1;
   break;
 case UNORDERED:
@@ -1970,9 +1970,9 @@
  swap_bsl_operands = 1;
  /* Fall through.  */
 case ORDERED:
-  emit_insn (gen_aarch64_cmgt (tmp, operands[4], operands[5]));
-  emit_insn (gen_aarch64_cmge (mask, operands[5], operands[4]));
-  emit

[PATCH][2/n] Re-organize -fvect-cost-model, enable basic vectorization at -O2

[Richard Biener]

The following patch makes the vectorizer cost model more finegrained
by splitting -f[no-]vect-cost-model into 
-fvect-cost-model=[unlimited|dynamic|cheap], thereby consuming
the -ftree-vect-loop-version flag.  The cost model will be always
enabled after this patch (as opposed to currently where
-O2 -ftree-vectorize will have it disabled but -O3 will have it
enabled).  It opens up the possibility to, in patch 3/n, enable
vectorization by default at -O2 but with the "cheap" cost-model
instead of the current default "dynamic".  This will disable
versioning for alias (but not versioning for alignment sofar).

@item -fvect-cost-model=@var{model}
@opindex fvect-cost-model
Alter the cost model used for vectorization.  The @var{model} argument
should be one of @code{unlimited}, @code{dynamic} or @code{cheap}.
With the @code{unlimited} model the vectorized code-path is assumed
to be profitable while with the @code{dynamic} model a runtime check
will guard the vectorized code-path to enable it only for iteration
counts that will likely execute faster than when executing the original
scalar loop.  The @code{cheap} model will disable vectorization of
loops where doing so would be cost prohibitive for example due to
required runtime checks for data dependence or alignment but otherwise
is equal to the @code{dynamic} model.
This option is enabled by default, the used cost model depends on
other optimization flags and is either @code{dynamic} or @code{cheap}.

Bootstrap / regtest running on x86_64-unknown-linux-gnu.

Any comments?

Thanks,
Richard.


2013-05-14  Richard Biener  

common/
* config/i386/i386-common.c (ix86_option_init_struct): Do not
enable OPT_fvect_cost_model.

* common.opt (fvect-cost-model=): New option, default to 'default'.
(vect_cost_model): New enum and values.
(fvect-cost-model): Alias to -fvect-cost-model=default.
(fno-vect-cost-model): Alias to -fvect-cost-model=unlimited.
(ftree-vect-loop-version): Ignore.
* opts.c (default_options_table): Do not set OPT_fvect_cost_model.
(common_handle_option): Likewise.
* flag-types.h (enum vect_cost_model): New enum.
* doc/invoke.texi (ftree-vect-loop-version): Remove.
(fvect-cost-model): Adjust documentation.
* targhooks.c (default_add_stmt_cost): Do not check
flag_vect_cost_model.
* tree-vectorizer.h (struct _loop_vec_info): Add cost model field.
(struct _bb_vec_info): Likewise.
* tree-vect-data-refs.c (vect_peeling_hash_insert): Check the
loops cost-model flag.
(vect_peeling_hash_choose_best_peeling): Likewise.
(vect_enhance_data_refs_alignment): Likewise.  Do not check
flag_tree_vect_loop_version but check the cost model.
* tree-vect-loop.c (vect_analyze_loop): Initialize the loops
cost model flag.
(vect_estimate_min_profitable_iters): Use the loops cost model flag.
* tree-vect-slp.c (vect_slp_analyze_bb_1): Initialize and use the BBs
cost model flag.
* tree-vectorizer.c (gate_vect_slp): Adjust.

Index: trunk/gcc/common.opt
===
*** trunk.orig/gcc/common.opt   2013-05-14 14:45:00.0 +0200
--- trunk/gcc/common.opt2013-05-14 15:26:09.640070043 +0200
*** ftree-slp-vectorize
*** 2270,2282 
  Common Report Var(flag_tree_slp_vectorize) Init(2) Optimization
  Enable basic block vectorization (SLP) on trees
  
  fvect-cost-model
! Common Report Var(flag_vect_cost_model) Optimization
! Enable use of cost model in vectorization
  
  ftree-vect-loop-version
! Common Report Var(flag_tree_vect_loop_version) Init(1) Optimization
! Enable loop versioning when doing loop vectorization on trees
  
  ftree-scev-cprop
  Common Report Var(flag_tree_scev_cprop) Init(1) Optimization
--- 2270,2305 
  Common Report Var(flag_tree_slp_vectorize) Init(2) Optimization
  Enable basic block vectorization (SLP) on trees
  
+ fvect-cost-model=
+ Common Joined RejectNegative Enum(vect_cost_model) Var(flag_vect_cost_model) 
Init(VECT_COST_MODEL_DEFAULT)
+ Specifies the cost model for vectorization
+ 
+ Enum
+ Name(vect_cost_model) Type(enum vect_cost_model) UnknownError(unknown 
vectorizer cost model %qs)
+ 
+ EnumValue
+ Enum(vect_cost_model) String(default) Value(VECT_COST_MODEL_DEFAULT)
+ 
+ EnumValue
+ Enum(vect_cost_model) String(unlimited) Value(VECT_COST_MODEL_UNLIMITED)
+ 
+ EnumValue
+ Enum(vect_cost_model) String(dynamic) Value(VECT_COST_MODEL_DYNAMIC)
+ 
+ EnumValue
+ Enum(vect_cost_model) String(cheap) Value(VECT_COST_MODEL_CHEAP)
+ 
  fvect-cost-model
! Common RejectNegative Alias(fvect-cost-model=,default)
! Enables the default vectorizer cost model.  Preserved for backward 
compatibility.
! 
! fno-vect-cost-model
! Common RejectNegative Alias(fvect-cost-model=,unlimited)
! Enables the unlimited vectorizer cost model.  Preserved for backward 
compatibility.

Re: [v3] Fix libstdc++/54577

[Paolo Carlini]

Hi,

On 05/14/2013 03:41 PM, Jonathan Wakely wrote:
I'd forgotten about the existence of __const_pointer_cast etc. in 
 ...

Me too ;) I resorted to it as a sort of temporary kludge.
I agree that in C++11 mode __normal_iterator::_M_const_cast should not 
rely on the existence of a get() member on the custom pointer, because 
that's not required to exist, and you can do it like this instead: 
using PT = pointer_traits; auto to = 
PT::pointer_to(const_cast(*from)); 

Indeed, I have something like this in my tree too.

Thanks!
Paolo.

Re: RFC: PATCH to avoid linking multiple front ends at once with parallel make

[Jason Merrill]

On 05/14/2013 12:49 AM, Alexandre Oliva wrote:

However, rather than implementing the locking in Makefiles, I'm thinking
it might be wiser to do so in a script that takes the lock name and the
command to run while holding the lock.


Good point.


trap 'rmdir "$lockdir"; exit $status' 0 1 2 15


In my testing I found that trapping signals other than 0 resulted in 
trying to rmdir twice if the process is interrupted.  The extra exit 
here also seems unnecessary.  And I added a check so that the script 
gives up and steals the lock after waiting 5 minutes.


2013-05-14  Jason Merrill  

	* Makefile.in (LLINKER): New variable.
	* configure.ac: Handle --enable-link-mutex.
	* lock-and-run.sh: New script.

diff --git a/gcc/lock-and-run.sh b/gcc/lock-and-run.sh
new file mode 100644
index 000..8beac5a
--- /dev/null
+++ b/gcc/lock-and-run.sh
@@ -0,0 +1,27 @@
+#! /bin/bash
+# Shell-based mutex using mkdir.
+
+lockdir=$1 prog=$2; shift 2 || exit 1
+count=0
+# Remember when we started trying to acquire the lock.
+touch lock-stamp.$$
+trap 'rm -r "$lockdir" lock-stamp.$$' 0
+until mkdir "$lockdir" 2>/dev/null; do
+# Say something periodically in case the lock is stale.
+if [ $((count++ % 30)) == 0 ]; then
+	# Reset if the lock has been renewed.
+	if [ "$lockdir" -nt lock-stamp.$$ ]; then
+	touch lock-stamp.$$
+	count=0
+	# Give up after 5 minutes.
+	elif [ $count == 300 ]; then
+	echo removing stale $lockdir
+	rm -r "$lockdir"
+	else
+	echo waiting to acquire $lockdir
+	fi
+fi
+sleep 1
+done
+echo $prog "$@"
+$prog "$@"
diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index 903125e..b7ade78 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -235,6 +235,13 @@ LINKER = $(CC)
 LINKER_FLAGS = $(CFLAGS)
 endif
 
+# Like LINKER, but use a mutex for serializing front end links.
+ifeq (@DO_LINK_MUTEX@,true)
+LLINKER = $(SHELL) $(srcdir)/lock-and-run.sh linkfe.lck $(LINKER)
+else
+LLINKER = $(LINKER)
+endif
+
 # ---
 # Programs which operate on the build machine
 # ---
diff --git a/gcc/ada/gcc-interface/Make-lang.in b/gcc/ada/gcc-interface/Make-lang.in
index ef12b4b..4fed34f 100644
--- a/gcc/ada/gcc-interface/Make-lang.in
+++ b/gcc/ada/gcc-interface/Make-lang.in
@@ -185,6 +185,7 @@ endif
 GCC_LINKERFLAGS = $(filter-out -Werror, $(ALL_LINKERFLAGS))
 
 GCC_LINK=$(LINKER) $(GCC_LINKERFLAGS) $(LDFLAGS)
+GCC_LLINK=$(LLINKER) $(GCC_LINKERFLAGS) $(LDFLAGS)
 
 # Lists of files for various purposes.
 
@@ -562,7 +563,8 @@ TARGET_ADA_SRCS =
 # Since the RTL should be built with the latest compiler, remove the
 #  stamp target in the parent directory whenever gnat1 is rebuilt
 gnat1$(exeext): $(TARGET_ADA_SRCS) $(GNAT1_OBJS) $(ADA_BACKEND) libcommon-target.a $(LIBDEPS)
-	+$(GCC_LINK) -o $@ $(GNAT1_OBJS) $(ADA_BACKEND) libcommon-target.a $(LIBS) $(SYSLIBS) $(BACKENDLIBS) $(CFLAGS)
+	+$(GCC_LLINK) -o $@ $(GNAT1_OBJS) $(ADA_BACKEND) \
+	  libcommon-target.a $(LIBS) $(SYSLIBS) $(BACKENDLIBS) $(CFLAGS)
 	$(RM) stamp-gnatlib2-rts stamp-tools
 
 gnatbind$(exeext): ada/b_gnatb.o $(CONFIG_H) $(GNATBIND_OBJS) ggc-none.o libcommon-target.a $(LIBDEPS)
diff --git a/gcc/c/Make-lang.in b/gcc/c/Make-lang.in
index 8310e0a..47aa4cb 100644
--- a/gcc/c/Make-lang.in
+++ b/gcc/c/Make-lang.in
@@ -75,7 +75,7 @@ cc1-checksum.c : build/genchecksum$(build_exeext) checksum-options \
 cc1-checksum.o : cc1-checksum.c $(CONFIG_H) $(SYSTEM_H)
 
 cc1$(exeext): $(C_OBJS) cc1-checksum.o $(BACKEND) $(LIBDEPS)
-	+$(LINKER) $(ALL_LINKERFLAGS) $(LDFLAGS) -o $@ $(C_OBJS) \
+	+$(LLINKER) $(ALL_LINKERFLAGS) $(LDFLAGS) -o $@ $(C_OBJS) \
 	  cc1-checksum.o $(BACKEND) $(LIBS) $(BACKENDLIBS)
 #
 # Build hooks:
diff --git a/gcc/configure b/gcc/configure
index 39e911c..1f03eac 100755
--- a/gcc/configure
+++ b/gcc/configure
@@ -670,6 +670,7 @@ subdirs
 dollar
 gcc_tooldir
 enable_lto
+DO_LINK_MUTEX
 MAINT
 zlibinc
 zlibdir
@@ -916,6 +917,7 @@ with_long_double_128
 with_gc
 with_system_zlib
 enable_maintainer_mode
+enable_link_mutex
 enable_version_specific_runtime_libs
 enable_plugin
 enable_libquadmath_support
@@ -1627,6 +1629,8 @@ Optional Features:
   --enable-maintainer-mode
   enable make rules and dependencies not useful (and
   sometimes confusing) to the casual installer
+  --enable-link-mutex avoid linking multiple front-ends at once to avoid
+  thrashing on the build machine
   --enable-version-specific-runtime-libs
   specify that runtime libraries should be installed
   in a compiler-specific directory
@@ -17830,7 +17834,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_status=$lt_dlunknown
   cat > conftest.$ac_ext <<_LT_EOF
-#line 17833 "configure"
+#line 17837 "configure"
 #include "confdefs.h"
 
 #if HAVE_DLFCN_H
@@ -17936,7 +17940,7 @@ else
   lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
   lt_statu

Re: C++ PATCH for c++/57041 (ICE with designated initializer)

[Jason Merrill]

On 05/13/2013 03:20 PM, Jason Merrill wrote:

If we don't like the designator, we should fail pleasantly.


And we ought to accept this case, anyway.



commit 6a9489bb28a4caf64e1b27ce35522990590a74a4
Author: Jason Merrill 
Date:   Tue May 14 09:08:15 2013 -0400

	PR c++/57041
	* pt.c (tsubst_copy_and_build): Don't recur into a designator.

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 60b0a8a..ea75b7f 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -14359,7 +14359,10 @@ tsubst_copy_and_build (tree t,
 newlen = vec_safe_length (n);
 	FOR_EACH_VEC_SAFE_ELT (n, idx, ce)
 	  {
-	if (ce->index && process_index_p)
+	if (ce->index && process_index_p
+		/* An identifier index is looked up in the type
+		   being initialized, not the current scope.  */
+		&& TREE_CODE (ce->index) != IDENTIFIER_NODE)
 	  ce->index = RECUR (ce->index);
 
 if (PACK_EXPANSION_P (ce->value))
diff --git a/gcc/testsuite/g++.dg/ext/desig6.C b/gcc/testsuite/g++.dg/ext/desig6.C
index 30882a6..ccdafa5 100644
--- a/gcc/testsuite/g++.dg/ext/desig6.C
+++ b/gcc/testsuite/g++.dg/ext/desig6.C
@@ -1,6 +1,5 @@
 // PR c++/57041
 // { dg-options "-std=gnu++11" }
-// { dg-prune-output "error:" }
 
 template
 union u {

[libgfortran, build] Use -z ignore instead of --as-needed on Solaris

[Rainer Orth]

As requested by Tobias, this patch supports -z ignore with Solaris ld
instead of GNU ld's --as-needed.

i386-pc-solaris2.10 and x86_64-unknown-linux-gnu bootstraps are still
running.  In both cases, the correct options were detected and written
into libgfortran.spec.  AFAICS the -static-libgfortran option isn't
exercised anywhere in the testsuite, so I've both relinked one of the
gfortran.dg testcases and a trivial FORTRAN hello world program with
-static-libgfortran.  -z ignore/--as-needed is passed correctly in both
cases, but while libgfortran is now linked statically, libquadmath.so is
still dragged in due to references to at least quadmath_snprintf.  I
thus can't tell if this --as-needed/-z ignore stuff ever does any good.

Ok for mainline if testing passes?

Thanks.
Rainer


2013-05-14  Rainer Orth  

* acinclude.m4 (libgfor_cv_have_as_needed): Check for -z ignore, too.
* configure: Regenerate.

# HG changeset patch
# Parent 552725704163412331462fc576619c0e82697a9a
 Use -z ignore instead of --as-needed on Solaris

diff --git a/libgfortran/acinclude.m4 b/libgfortran/acinclude.m4
--- a/libgfortran/acinclude.m4
+++ b/libgfortran/acinclude.m4
@@ -296,7 +296,7 @@ AC_DEFUN([LIBGFOR_CHECK_FLOAT128], [
   if test "x$libgfor_cv_have_float128" = xyes; then
 AC_DEFINE(HAVE_FLOAT128, 1, [Define if have a usable __float128 type.])
 
-dnl Check whether -Wl,--as-needed is supported
+dnl Check whether -Wl,--as-needed resp. -Wl,-zignore is supported
 dnl 
 dnl Turn warnings into error to avoid testsuite breakage.  So enable
 dnl AC_LANG_WERROR, but there's currently (autoconf 2.64) no way to turn
@@ -304,23 +304,39 @@ AC_DEFUN([LIBGFOR_CHECK_FLOAT128], [
 dnl AC_PATH_XTRA.
 dnl Cf. http://gcc.gnu.org/ml/gcc-patches/2010-05/msg01889.html
 ac_xsave_[]_AC_LANG_ABBREV[]_werror_flag=$ac_[]_AC_LANG_ABBREV[]_werror_flag
-AC_CACHE_CHECK([whether --as-needed works],
+AC_CACHE_CHECK([whether --as-needed/-z ignore works],
   [libgfor_cv_have_as_needed],
   [
+  # Test for native Solaris options first.
+  # No whitespace after -z to pass it through -Wl.
+  libgfor_cv_as_needed_option="-zignore"
+  libgfor_cv_no_as_needed_option="-zrecord"
   save_LDFLAGS="$LDFLAGS"
-  LDFLAGS="$LDFLAGS -Wl,--as-needed -lm -Wl,--no-as-needed"
+  LDFLAGS="$LDFLAGS -Wl,$libgfor_cv_as_needed_option -lm -Wl,$libgfor_cv_no_as_needed_option"
   libgfor_cv_have_as_needed=no
   AC_LANG_WERROR
   AC_LINK_IFELSE([AC_LANG_PROGRAM([])],
 		 [libgfor_cv_have_as_needed=yes],
 		 [libgfor_cv_have_as_needed=no])
   LDFLAGS="$save_LDFLAGS"
+  if test "x$libgfor_cv_have_as_needed" = xno; then
+	libgfor_cv_as_needed_option="--as-needed"
+	libgfor_cv_no_as_needed_option="--no-as-needed"
+	save_LDFLAGS="$LDFLAGS"
+	LDFLAGS="$LDFLAGS -Wl,$libgfor_cv_as_needed_option -lm -Wl,$libgfor_cv_no_as_needed_option"
+	libgfor_cv_have_as_needed=no
+	AC_LANG_WERROR
+	AC_LINK_IFELSE([AC_LANG_PROGRAM([])],
+		   [libgfor_cv_have_as_needed=yes],
+		   [libgfor_cv_have_as_needed=no])
+	LDFLAGS="$save_LDFLAGS"
+  fi
   ac_[]_AC_LANG_ABBREV[]_werror_flag=$ac_xsave_[]_AC_LANG_ABBREV[]_werror_flag
 ])
 
 dnl For static libgfortran linkage, depend on libquadmath only if needed.
 if test "x$libgfor_cv_have_as_needed" = xyes; then
-  LIBQUADSPEC="%{static-libgfortran:--as-needed} -lquadmath %{static-libgfortran:--no-as-needed}"
+  LIBQUADSPEC="%{static-libgfortran:$libgfor_cv_as_needed_option} -lquadmath %{static-libgfortran:$libgfor_cv_no_as_needed_option}"
 else
   LIBQUADSPEC="-lquadmath"
 fi

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

Re: [AArch64] Fix vcond where comparison and result have different types.

[Marcus Shawcroft]

OK
/M

On 14 May 2013 14:43, James Greenhalgh  wrote:
>
> Hi,
>
> For a statement like:
>
>   INT = FLOAT > FLOAT ? INT : INT.
>
> The vcond implementation in AArch64 is broken. We will try to force
> the INT value to a FLOAT register and will ICE.
>
> This patch fixes this.
>
> Regression suite run for aarch64-none-elf with no regressions,
> and more cases added to the testsuite to ensure this is caught
> in future.
>
> Thanks,
> James Greenhalgh
>
> ---
> gcc/
>
> * config/aarch64/aarch64-simd.md
> (aarch64_vcond_internal): Rename to...
> (aarch64_vcond_internal): ...This, for integer modes.
> (aarch64_vcond_internal): ...This for
> float modes. Clarify all iterator modes.
> (vcond): Use new name for vcond expanders.
> (vcond): Likewise.
> (vcondu: Likewise.
> * config/aarch64/iterators.md (VDQF_COND): New.
>
> gcc/testsuite/
>
> * gcc.target/aarch64/vect-fcm.x: Add cases testing
> FLOAT cmp FLOAT ? INT : INT.
>  * gcc.target/aarch64/vect-fcm-eq-d.c: Define IMODE.
>  * gcc.target/aarch64/vect-fcm-eq-f.c: Likewise.
>  * gcc.target/aarch64/vect-fcm-ge-d.c: Likewise.
>  * gcc.target/aarch64/vect-fcm-ge-f.c: Likewise.
>  * gcc.target/aarch64/vect-fcm-gt-d.c: Likewise.
>  * gcc.target/aarch64/vect-fcm-gt-f.c: Likewise.

Re: [v3] Fix libstdc++/54577

[Paolo Carlini]

... I'm finishing testing the below.

Paolo.


Index: include/bits/stl_iterator.h
===
--- include/bits/stl_iterator.h (revision 198885)
+++ include/bits/stl_iterator.h (working copy)
@@ -63,7 +63,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 namespace std _GLIBCXX_VISIBILITY(default)
 {
@@ -736,9 +736,17 @@
 
   __normal_iterator
   _M_const_cast() const
-  { return __normal_iterator
- (__gnu_cxx::__const_pointer_cast
-  (_M_current)); }
+  {
+#if __cplusplus >= 201103L
+   using _PTraits = std::pointer_traits;
+   return __normal_iterator
+ (_PTraits::pointer_to(const_cast
+   (*_M_current)));
+#else
+return __normal_iterator
+ (const_cast(_M_current));
+#endif
+  }
 
   // Forward iterator requirements
   reference

Re: [patch] Hash table changes from cxx-conversion branch - config part

[Steve Ellcey]

On Mon, 2013-05-13 at 15:03 -0700, Lawrence Crowl wrote:
> I still have not heard from i386 or ia64 folks.  Anyone?

The IA64 part looks OK to me.

Steve Ellcey
sell...@imgtec.com (sell...@mips.com)

Re: RFA: Allow simplification of SUBREGs involving the frame pointer during LRA

[nick clifton]

Hi Jeff,

   I would like to apply the patch below to allow simplify_subreg_regno()
   to treat the frame pointer register in the same way as the stack
   pointer register when the LRA pass is running.



Ew.

Before accepting this, I'd like to see more of the rationale behind the
change.


*sigh* Of course now I cannot reproduce the failure that this patch used 
to fix.  Oh well.  I withdraw the patch for now and if I can find a way 
to reproduce the problem I will post the patch again along with a more 
complete description of what is happening.


Cheers
  Nick

Re: [libgfortran, build] Use -z ignore instead of --as-needed on Solaris

[Tobias Burnus]

Rainer Orth wrote:

As requested by Tobias, this patch supports -z ignore with Solaris ld
instead of GNU ld's --as-needed.


For reference, my request was motivated by 
http://gcc.gnu.org/ml/gcc-patches/2013-04/msg00425.html

(The patch has been approved, but it does not seem to be in, yet.)


i386-pc-solaris2.10 and x86_64-unknown-linux-gnu bootstraps are still
running.  In both cases, the correct options were detected and written
into libgfortran.spec.  AFAICS the -static-libgfortran option isn't
exercised anywhere in the testsuite, so I've both relinked one of the
gfortran.dg testcases and a trivial FORTRAN hello world program with
-static-libgfortran.  -z ignore/--as-needed is passed correctly in both
cases, but while libgfortran is now linked statically, libquadmath.so is
still dragged in due to references to at least quadmath_snprintf.  I
thus can't tell if this --as-needed/-z ignore stuff ever does any good.


Well, it kind of works - but seemingly not fully. If I use:
   print *, "Hello World"; end
with -static-libgfortran, I get ("nm a.out"):
 w quadmath_snprintf@@QUADMATH_1.0

While using a quad-precision variable, e.g.,
   print *, 123.4_16; end
gives
 U quadmath_snprintf@@QUADMATH_1.0

I don't know whether one could do better.

 * * *

+  # Test for native Solaris options first.

Is there a reason that you first test the Solaris's options?



+  # No whitespace after -z to pass it through -Wl.

(By the way, you can use "-Wl,-z,ignore" if you want to have the space. 
For the purpose of this patch, the space doesn't matter.)



Ok for mainline if testing passes?


Looks fine to me - I don't know whether a build maintainer has still a 
comment.


Tobias


2013-05-14  Rainer Orth  

* acinclude.m4 (libgfor_cv_have_as_needed): Check for -z ignore, too.
* configure: Regenerate.

Re: [PATCH, x86] Use vector moves in memmove expanding

[H.J. Lu]

On Tue, May 14, 2013 at 7:34 AM, Michael Zolotukhin
 wrote:
> Hi,
> I attached an updated version of the patch.  Looks like the 64-bit issue is
> resolved in it (now a vector mode is explicitly chosen instead of TI- or
> another integer mode).  Also, some of remarks are fixed in it - some
> others are still not changed, because I don't know what to do with them right
> now (see my questions in the previous letter).
>
> Could you take a look at the patch?
>
> I checked it on i386/x86_64 bootstrap and make check, and on Specs2000/2006
> (I checked only stability).
>

You use Pmode as the largest integer mode.  Is word_mode better
than Pmode since word_mode is DI and Pmode may be SI for x32.


--
H.J.

Re: cfgexpand.c patch for [was new port: msp430-elf]

[DJ Delorie]

> How can you then ever "truncate" from SImode to PSImode?

If you use PARTIAL_INT_MODE(), you get a PSImode that has a "default"
bitsize (i.e. the value stored in the data structure) that's the same
as SImode, that is, 32.  There is no way to specify the usable
bitsize, so it's "undefined/unspecified" but, IMHO, assumed to be less
than the bit size of the parent mode.

One can assert that a PSImode will never have *more* precision than
SImode, though, so sign extending SImode to PSImode is never the right
thing to do.

> btw, what's the relation to fractional int modes?

I think fractional_int_mode allows you to specify the precision and
byte size, but in my experience, I've had trouble using it, especially
if you specify a non-power-of-two byte size.

Re: Using GS for TLS on x86-64 for target RDOS

[Leif Ekblad]

I've made a patch along these lines  (enclosed).

Change log:
* gcc/config/i386/i386.c: Use DEFAULT_TLS_SEG_REG to access TLS
* gcc/config/i386/i386.h: Define default segment register for TLS
* gcc/config/i386/rdos.h: Added TLS configuration for RDOS

Regards,
Leif Ekblad


- Original Message - 
From: "Uros Bizjak" 

To: "Michael Matz" 
Cc: ; "Leif Ekblad" 
Sent: Tuesday, May 14, 2013 11:35 AM
Subject: Re: Using GS for TLS on x86-64 for target RDOS



On Tue, May 14, 2013 at 11:13 AM, Michael Matz  wrote:


On Tue, 14 May 2013, Uros Bizjak wrote:


I'd propose to introduce:

a) #define DEFAULT_TLS_SEG_REG in i386.h to SEG_GS

b) #undef and #define DEFAULT_TLS_SEG_REG in x86-64.h to SEG_FS


This would break -m32.


Uh, yes.

So instead of a) and b), there should be:

#define DEFAULT_TLS_SEG_REG TARGET_64BIT ? SEG_FS : SEG_GS in i386.h.

Uros.

gcc-tls.diff
Description: Binary data

Re: new port: msp430-elf, revision 2

[Chung-Ju Wu]

2013/5/14 nick clifton :
> Hi Steven,
>
>
>> Should new ports be allowed in if they rely so heavily on reload?
>
> As it happens I am currently working on enabling LRA for the MSP430 target.
> Although I have run into a roadblock with a possibly unacceptable patch to
> simplify_subreg_regno:
>
>   http://gcc.gnu.org/ml/gcc-patches/2013-05/msg00135.html
>
> The LRA conversion is a work in progress however, and one that does not have
> my highest priority, so we would really like to have the current
> reload-heavy version accepted.  The current version works, and it will be
> converted to LRA in the future, so is it really necessary to block its
> adoption now ?
>
> Cheers
>   Nick


Hi, Nick,

Apparently I am not the one who have right to review your code.
But in my point of view, your implementation does not use reload
stuff such as push_reload or xxx_RELOAD_yyy target hooks.

So I think your msp430 contribution is a 'reload-light' port,
not a 'reload-heavy' version you worried about. ;)


Best regards,
jasonwucj

Re: [PATCH 2/5] Altera Nios II: libgcc

[Chung-Lin Tang]

On 13/4/26 4:00 AM, Joseph S. Myers wrote:
> On Thu, 18 Apr 2013, Chung-Lin Tang wrote:
> 
>> +nios2-*-linux*)
>> +tmake_file="$tmake_file nios2/t-nios2 nios2/t-linux t-libgcc-pic 
>> t-slibgcc-libgcc"
>> +extra_parts="$extra_parts crti.o crtn.o"
>> +md_unwind_header=nios2/linux-unwind.h
>> +;;
>> +nios2-*-*)
>> +tmake_file="$tmake_file nios2/t-nios2 t-fdpbit"
>> +extra_parts="$extra_parts crti.o crtn.o"
>> +;;
> 
> As I understand it, the port uses soft-fp in glibc so doesn't need it in 
> libgcc for nios2-*-linux*.  But why use the old fp-bit in libgcc for bare 
> metal (use of t-fdpbit here), rather than soft-fp?

I think this was oversight. I have switched the nios2-elf config to use
use softfp.

Although not currently utilized, nios2 does have the capability of a
hard-float multilib, so I have used t-softfp-excl for now.

The remaining more trivial formatting, file name issues, etc. should
have all been resolved. Please see attached patch.

Thanks,
Chung-Lin

Index: libgcc/config.host
===
--- libgcc/config.host	(revision 198891)
+++ libgcc/config.host	(working copy)
@@ -137,6 +137,9 @@ mips*-*-*)
 	cpu_type=mips
 	tmake_file=mips/t-mips
 	;;
+nios2*-*-*)
+	cpu_type=nios2
+	;;
 powerpc*-*-*)
 	cpu_type=rs6000
 	;;
@@ -814,6 +817,15 @@ moxie-*-rtems*)
 	# Don't use default.
 	extra_parts=
 	;;
+nios2-*-linux*)
+	tmake_file="$tmake_file nios2/t-nios2 nios2/t-linux t-libgcc-pic t-slibgcc-libgcc"
+	extra_parts="$extra_parts crti.o crtn.o"
+	md_unwind_header=nios2/linux-unwind.h
+	;;
+nios2-*-*)
+	tmake_file="$tmake_file nios2/t-nios2 t-softfp-sfdf t-softfp-excl t-softfp"
+	extra_parts="$extra_parts crti.o crtn.o"
+	;;
 pdp11-*-*)
 	tmake_file="pdp11/t-pdp11 t-fdpbit"
 	;;
Index: libgcc/config/nios2/crtn.S
===
--- libgcc/config/nios2/crtn.S	(revision 0)
+++ libgcc/config/nios2/crtn.S	(revision 0)
@@ -0,0 +1,60 @@
+/* Copyright (C) 2012-2013 Free Software Foundation, Inc.
+   Contributed by Jonah Graham (jgra...@altera.com).
+   Contributed by Mentor Graphics, Inc.
+
+This file 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 file 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
+.  */
+
+
+/* This file just makes sure that the .fini and .init sections do in
+fact return.  Users may put any desired instructions in those sections.
+This file is the last thing linked into any executable.
+*/	
+	.file	"crtn.asm"
+
+
+
+	.section	".init"
+	ldw	ra, 44(sp)
+	ldw	r23, 40(sp)
+	ldw	r22, 36(sp)
+	ldw	r21, 32(sp)
+	ldw	r20, 28(sp)
+	ldw	r19, 24(sp)
+	ldw	r18, 20(sp)
+	ldw	r17, 16(sp)
+	ldw	r16, 12(sp)
+	ldw	fp, 8(sp)
+	addi	sp, sp, 48
+	ret
+	
+	.section	".fini"
+	ldw	ra, 44(sp)
+	ldw	r23, 40(sp)
+	ldw	r22, 36(sp)
+	ldw	r21, 32(sp)
+	ldw	r20, 28(sp)
+	ldw	r19, 24(sp)
+	ldw	r18, 20(sp)
+	ldw	r17, 16(sp)
+	ldw	r16, 12(sp)
+	ldw	fp, 8(sp)
+	addi	sp, sp, 48
+	ret
+
Index: libgcc/config/nios2/linux-unwind.h
===
--- libgcc/config/nios2/linux-unwind.h	(revision 0)
+++ libgcc/config/nios2/linux-unwind.h	(revision 0)
@@ -0,0 +1,179 @@
+/* DWARF2 EH unwinding support for Nios II Linux.
+   Copyright (C) 2008-2013 Free Software Foundation, Inc.
+
+This file 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 file 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
+.  */
+
+#ifndef inhibit_lib

Re: new port: msp430-elf, revision 2

[Steven Bosscher]

On Tue, May 14, 2013 at 2:51 PM, nick clifton wrote:
> Hi Steven,
>
>> Should new ports be allowed in if they rely so heavily on reload?
>
> As it happens I am currently working on enabling LRA for the MSP430 target.
> Although I have run into a roadblock with a possibly unacceptable patch to
> simplify_subreg_regno:
>
>   http://gcc.gnu.org/ml/gcc-patches/2013-05/msg00135.html

Right, I've seen Jeff's comment and your reply.


> The LRA conversion is a work in progress however, and one that does not have
> my highest priority, so we would really like to have the current
> reload-heavy version accepted.  The current version works, and it will be
> converted to LRA in the future, so is it really necessary to block its
> adoption now ?

As long as the work to convert to LRA is completed ;-)

I understand the port is ready (maybe even already since very long)
and works, and even if I would want to block its adoption I'd be in no
position to do so. That wasn't the purpose of my message.

What worries me a lot, is that there are so many half-finished bits
and conversions in GCC, some ports/passes/... doing this and others
doing that, that it's very hard to bring some structure back into the
compiler and clean things up. Just see
http://gcc.gnu.org/wiki/Partial_Transitions (which is out-of-date but
not nearly complete), gcc.gnu.org/backends.html (the "does
not"-fields), the sched-deps representations and hooks, and so on. I
would like new contributions to try and be as "modern" as reasonably
possible. E.g. if someone at this point would contribute the SH port
(talk about reload-heavy...) I don't think that'd be good for the GCC
as a product overall. Likewise for ports that don't use define_c_enum
for unspec{,v}, define_peephole, and so on.

Ciao!
Steven

Print column information in dump_loc

[Easwaran Raman]

This patch dumps the column number as part of dump_loc making the
output similar to inform(). This allows these messages to be pattern
matched by dg_message. Bootstraps with this change. Ok for trunk?

- Easwaran
-

2013-05-14  Easwaran Raman  

* dumpfile.c (dump_loc): Print column number.

Index: gcc/dumpfile.c
===
--- gcc/dumpfile.c (revision 198852)
+++ gcc/dumpfile.c (working copy)
@@ -261,12 +261,13 @@ dump_loc (int dump_kind, FILE *dfile, source_locat
   if (dump_kind)
 {
   if (LOCATION_LOCUS (loc) > BUILTINS_LOCATION)
-fprintf (dfile, "\n%s:%d: note: ", LOCATION_FILE (loc),
- LOCATION_LINE (loc));
+fprintf (dfile, "\n%s:%d:%d: note: ", LOCATION_FILE (loc),
+ LOCATION_LINE (loc), LOCATION_COLUMN (loc));
   else if (current_function_decl)
-fprintf (dfile, "\n%s:%d: note: ",
+fprintf (dfile, "\n%s:%d:%d: note: ",
  DECL_SOURCE_FILE (current_function_decl),
- DECL_SOURCE_LINE (current_function_decl));
+ DECL_SOURCE_LINE (current_function_decl),
+ DECL_SOURCE_COLUMN (current_function_decl));
 }
 }

Re: [PATCH 0/5] Submission of Altera Nios II port

[Chung-Lin Tang]

On 2013/4/26 04:35 AM, Joseph S. Myers wrote:
> I should ask the following general standard new-port questions:
> 
> * Does the port build cleanly when configured with --enable-werror-always 
> and built using a native compiler from current GCC trunk - for both 32-bit 
> host, and 64-bit host?  It should.  This is the standard way of ensuring 
> the same level of warning-cleanness in a cross build as native bootstrap 
> automatically enforces (and the build compiler needs to be from current 
> trunk because warning-cleanness is only expected when the build compiler 
> is the same version as the compiler being built).
> 
> The new targets should be added to contrib/config-list.mk, which helps 
> test all targets with --enable-werror-always.  This is mentioned in "Back 
> End" in sourcebuild.texi - check there for any other pieces that should be 
> included in the port submission.

Currently, nios2 seems to be another affected target by PR 55035, when
building with a recent trunk with --enable-werror-always:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55035

I would like to ask this --enable-werror-always requirement be relaxed
for the nios2 port submission, as it is not alone in the above PR, and
we are early in the release cycle; there should be plenty of time to fix
any problems afterwards.

Though not included in the submitted patches, I will add the target
entries in contrib/config-list.mk when committing.

> * What are test results like for the port?  Again, both 32-bit and 64-bit 
> hosts, to detect any dependencies on whether the host is 32-bit or 64-bit.

Tests of i686 and x86_64 Linux hosts show same test results. FAILs that
still exist include g++.dg/debug/dwarf2/non-virtual-thunk.C, due to the
lack of target specific MI-thunk hooks right now, and a few tree-ssa
optimization FAILs, that might be worked around by augmenting the
testcase. The port in whole should be fairly stable.

Thanks,
Chung-Lin

Re: Fix weakrefs and LTO

[Jan Hubicka]

> On Tue, May 14, 2013 at 11:12 AM, Jan Hubicka  wrote:
> > Hi,
> > this patch fixes with weakrefs seen on building latest firefox.  The 
> > problem is
> > that currently we handle weakrefs as external variables/functions that 
> > makes us
> > to merge them.  In firefox there are two weakrefs with different aliases 
> > used
> > in different units.  This is correct and well defined even if weird use.
> >
> > This patch adds special cases for weakrefs into lto-symtab and lto-partition
> > to make them go through correctly.  I also fixed two fallouts of my previous
> > change that reproduce on firefox (and the testcase addded).
> >
> > For lto-partition the weakrefs with defined target are even bit more special
> > animals, since they needs to be duplicated into every unit that use them.
> >
> > It is ugly to special case wekarefs all around.  My plan is to cleanup whole
> > area, but it seems that the correctness issue deserve to be fixed first.
> >
> > I have bootstrapped/regtested x86_64-linux and tested mozilla build.  Will
> > commit it tonight if there are no complains.
> 
> Does this affect the 4.8 branch, too?

Yes,t he bug exists on release branches, too.
The patch will need a rework though, since 4.9 has new code for static var 
renaming.
I will check how hard it is fix with the old code.

Honza

Re: RFC: PATCH to avoid linking multiple front ends at once with parallel make

[Tom Tromey]

> "Alexandre" == Alexandre Oliva  writes:

Alexandre> However, rather than implementing the locking in Makefiles,
Alexandre> I'm thinking it might be wiser to do so in a script that
Alexandre> takes the lock name and the command to run while holding the
Alexandre> lock.

It seems to me you can get the desired functionality in the Makefiles
using order-only dependencies -- just force some ordering of the
targets.

Tom

Re: [PATCH,RFC] Make libbacktrace more standalone

[Alexander Monakov]

> > In the case where IN_GCC is defined, where are the types
> > dwarf_attribute, dwarf_form, and dwarf_tag defined?
> 
> In GCC's own dwarf2.h as enum tags; dwarf.h uses anonymous enums.

Ah, I still should have typedef'ed those types to enum tags when IN_GCC.  I've
verified the following patch bootstraps and passes testing.

libbacktrace/Changelog:
2013-05-14  Alexander Monakov  

* btest.c: [!IN_GCC] (IS_DIR_SEPARATOR): Define.
* configure.ac: (standalone): New configuration flag.
(EXTRA_FLAGS): Add -DIN_GCC.
(HAVE_DWARF2_FISSION, HAVE_DWARF2_DWZ_MULTIFILE): New
tests.  Use ...
* dwarf.c: (read_attribute): ... here.
[IN_GCC] (dwarf_attribute, dwarf_form, dwarf_tag): Typedef to
corresponding enums from dwarf2.h.  Update all uses.
[!IN_GCC] Use system dwarf.h. 
[!IN_GCC] (dwarf_attribute, dwarf_form, dwarf_tag): Typedef to int.
[!IN_GCC] (IS_ABSOLUTE_PATH): Define.
(read_line_program): Avoid use of DW_LNS_extended_op.
* configure: Regenerate.
* config.h.in: Regenerate.
* Makefile.in: Regenerate.


diff --git a/libbacktrace/btest.c b/libbacktrace/btest.c
index cc647b8..1516099 100644
--- a/libbacktrace/btest.c
+++ b/libbacktrace/btest.c
@@ -38,7 +38,11 @@ POSSIBILITY OF SUCH DAMAGE.  */
 #include 
 #include 
 
+#ifdef IN_GCC
 #include "filenames.h"
+#else
+#define IS_DIR_SEPARATOR(c) ((c) == '/')
+#endif
 
 #include "backtrace.h"
 #include "backtrace-supported.h"
diff --git a/libbacktrace/configure.ac b/libbacktrace/configure.ac
index 28b2a1c..ae23da4 100644
--- a/libbacktrace/configure.ac
+++ b/libbacktrace/configure.ac
@@ -58,6 +58,9 @@ AM_MAINTAINER_MODE
 AC_ARG_WITH(target-subdir,
 [  --with-target-subdir=SUBDIR  Configuring in a subdirectory for target])
 
+AC_ARG_ENABLE(standalone,
+[  --enable-standalone Do not use internal GCC headers])
+
 # We must force CC to /not/ be precious variables; otherwise
 # the wrong, non-multilib-adjusted value will be used in multilibs.
 # As a side effect, we have to subst CFLAGS ourselves.
@@ -72,7 +75,7 @@ AC_PROG_RANLIB
 
 AC_PROG_AWK
 case "$AWK" in
-"") AC_MSG_ERROR([can't build without awk]) ;;
+"") AC_MSG_ERROR([cannot build without awk]) ;;
 esac
 
 LT_INIT([disable-shared])
@@ -125,6 +128,10 @@ else
 EXTRA_FLAGS="$EXTRA_FLAGS -frandom-seed=\$@"
   fi
 fi
+
+if test "${enable_standalone}" != "yes"; then
+  EXTRA_FLAGS="$EXTRA_FLAGS -DIN_GCC"
+fi
 AC_SUBST(EXTRA_FLAGS)
 
 ACX_PROG_CC_WARNING_OPTS([-W -Wall -Wwrite-strings -Wstrict-prototypes \
@@ -314,6 +321,40 @@ if test "$have_getexecname" = "yes"; then
   AC_DEFINE(HAVE_GETEXECNAME, 1, [Define if getexecname is available.])
 fi
 
+# Check for DWARF2 extensions
+if test "${enable_standalone}" != "yes"; then
+  have_dwarf2_fission=yes
+  have_dwarf2_dwz_multifile=yes
+else
+  AC_CHECK_HEADER([dwarf.h],
+[
+  AC_MSG_CHECKING([for DW_FORM_GNU_addr_index])
+  AC_COMPILE_IFELSE(
+   [AC_LANG_PROGRAM(
+ [#include ],
+ [int i = DW_FORM_GNU_addr_index;])],
+   [have_dwarf2_fission=yes],
+   [have_dwarf2_fission=no])
+  AC_MSG_RESULT([$have_dwarf2_fission])
+  AC_MSG_CHECKING([for DW_FORM_GNU_ref_alt])
+  AC_COMPILE_IFELSE(
+   [AC_LANG_PROGRAM(
+ [#include ],
+ [int i = DW_FORM_GNU_ref_alt;])],
+   [have_dwarf2_dwz_multifile=yes],
+   [have_dwarf2_dwz_multifile=no])
+  AC_MSG_RESULT([$have_dwarf2_dwz_multifile])],
+[AC_MSG_ERROR([dwarf.h required when building standalone])])
+fi
+if test "$have_dwarf2_fission" = "yes"; then
+  AC_DEFINE(HAVE_DWARF2_FISSION, 1,
+   [Define if DWARF2 Fission enumeration values are defined.])
+fi
+if test "$have_dwarf2_dwz_multifile" = "yes"; then
+  AC_DEFINE(HAVE_DWARF2_DWZ_MULTFILE, 1,
+   [Define if DWARF2 DWZ multifile enumeration values are defined.])
+fi
+
 AC_CACHE_CHECK([whether tests can run],
   [libbacktrace_cv_sys_native],
   [AC_RUN_IFELSE([AC_LANG_PROGRAM([], [return 0;])],
diff --git a/libbacktrace/dwarf.c b/libbacktrace/dwarf.c
index 501afe5..6170ca0 100644
--- a/libbacktrace/dwarf.c
+++ b/libbacktrace/dwarf.c
@@ -37,9 +37,22 @@ POSSIBILITY OF SUCH DAMAGE.  */
 #include 
 #include 
 
+#ifdef IN_GCC
 #include "dwarf2.h"
 #include "filenames.h"
 
+typedef enum dwarf_attribute dwarf_attribute;
+typedef enum dwarf_form dwarf_form;
+typedef enum dwarf_tag dwarf_tag;
+#else
+#include 
+#define IS_ABSOLUTE_PATH(f) ((f)[0] == '/')
+
+typedef int dwarf_attribute;
+typedef int dwarf_form;
+typedef int dwarf_tag;
+#endif
+
 #include "backtrace.h"
 #include "internal.h"
 
@@ -89,9 +102,9 @@ struct dwarf_buf
 struct attr
 {
   /* The attribute name.  */
-  enum dwarf_attribute name;
+  dwarf_attribute name;
   /* The attribute form.  */
-  enum dwarf_form form;
+  dwarf_form form;
 };
 
 /* A single DWARF abbreviation.  */
@@ -101,7 +114,7 @@ struct abbrev
   /* The abbrev code--the number used to refer to the abbrev.  */
   uint64_t code;
   /* The 

Re: [PATCH] Use indentation in gtype.state to show nested structure

[Jeff Law]

On 05/06/2013 03:05 PM, David Malcolm wrote:


Note that this code is for the gengtype build-time utility, rather than
in GCC proper, so this wasn't on my own mental hitlist for fixing global
state.
Yea, but we probably should be taking opportunities to clean this stuff 
up even in the gen* utilities when we can.





The attached rewrite of the patch introduces classes to hold the new
internal state relating to writing out the s-expressions, and by doing
so implicitly adds a requirement that this code be compiled with C++
(I'm not sure that such a requirement existed before).
The introduction of C++ as a requirement for the gen* programs should be 
OK as long as we stick to the guidelines posted on the website.





The new variables become data members of a new s_expr_writer class (and
as such gain trailing underscores as per
http://gcc.gnu.org/codingconventions.html#Cxx_Names )

Right.




It does not remove all global state from the writer code, merely the new
state that the old version of the patch added.  For example:
   FILE * state_file
is still global (and shared by the reader code), but fixing that would
make the patch touch many more lines of code and thus be more difficult
to read.
Yea, I wasn't asking you to go back and remove all the state.  At least 
with your patch we have somewhere to hang the state, which makes a nice 
cleanup project for someone.


I believe I already fixed these in
http://gcc.gnu.org/ml/gcc-patches/2013-05/msg00259.html

(again, is there an automated way of checking this?)
I'm not aware of an automated way right now.  Probably the closest would 
be to use gnu-indent.  The problem is the sources aren't already in 
gnu-indent form.


That's the kind of thing I'd really like to see automated via commit 
hooks.  Declare gnu-indent as the standard form, then ensure the tree is 
always in that form.


Anyway, the patch is good to go.   Please install.

Thanks,
jeff

Re: RFC: PATCH to avoid linking multiple front ends at once with parallel make

[Mike Stump]

On May 13, 2013, at 9:49 PM, Alexandre Oliva  wrote:
> However, rather than implementing the locking in Makefiles, I'm thinking
> it might be wiser to do so in a script that takes the lock name and the
> command to run while holding the lock.

I worry about quoting.  Anytime you accept and pass on a argument list, 
typically means that you destroy the argument list, unless you have something 
to quote it for you.  bash (sh in general) has a fetish for destroying 
arguments.  :-(  A linker option that has \, or spaces or ' or " in it, is the 
type of problem I'm thinking of.  Also applies to filenames.

Re: Using GS for TLS on x86-64 for target RDOS

[Uros Bizjak]

On Tue, May 14, 2013 at 6:45 PM, Leif Ekblad  wrote:
> I've made a patch along these lines  (enclosed).
>
> Change log:
> * gcc/config/i386/i386.c: Use DEFAULT_TLS_SEG_REG to access TLS
> * gcc/config/i386/i386.h: Define default segment register for TLS
> * gcc/config/i386/rdos.h: Added TLS configuration for RDOS

*** gcc-4.9-20130512/gcc/config/i386/i386.h2013-04-29
13:00:10.0 +0200
--- gcc-work/gcc/config/i386/i386.h2013-05-14 13:36:19.041020400 +0200

+ /* The default TLS segment register used by target.  */
+ #define DEFAULT_TLS_SEG_REG TARGET_64BIT ? SEG_FS : SEG_GS

Precedence is a bit tricky with "?" ternary operand. Please put the
expression in braces...

*** gcc-4.9-20130512/gcc/config/i386/i386.c2013-05-06
16:53:03.0 +0200
--- gcc-work/gcc/config/i386/i386.c2013-05-14 13:37:14.338020400 +0200

!   || addr.seg != (DEFAULT_TLS_SEG_REG)

... and remove them there.

*** gcc-4.9-20130512/gcc/config/i386/rdos.h2013-01-28
21:42:55.0 +0100
--- gcc-work/gcc/config/i386/rdos.h2013-05-14 13:36:17.940020400 +0200

+ #undef TARGET_TLS_DIRECT_SEG_REFS
+ #define TARGET_TLS_DIRECT_SEG_REFS 1

TARGET_TLS_DIRECT_SEG_REFS_DEFAULT

! #define TARGET_OS_CPP_BUILTINS()\
!   do\
! {   \
!   builtin_define ("__RDOS__");  \
!   builtin_assert ("system=rdos");   \
! }   \

This looks like unwanted change to me.

The patch is OK for mainline with above changes, if tested on x86_64-linux-gnu.

Thanks,
Uros.

Re: web ICEs on subreg

[Mike Stump]

On May 10, 2013, at 5:27 PM, Kenneth Zadeck  wrote:
> Assuming the patch has been tested on a public port, it is ok for commit.

Thanks.  It turns out that my patch is necessary, but not sufficient, the code 
that exists must be left in place, as there are pre-existing test cases in the 
test suite that do depend upon the existing code.  In the below code, I leave 
the existing code alone, and merely add the additional code.  I reviewed the 
way the code gets here, and reasonably it can get here in either of the two 
ways, so having two checks is required.

Here is the version I checked in.

2013-05-14  Mike Stump  

* web.c (union_match_dups): Also check DF_REF_REAL_LOC.

Index: web.c
===
--- web.c   (revision 198796)
+++ web.c   (working copy)
@@ -132,14 +132,22 @@ union_match_dups (rtx insn, struct web_e
   ref = type == OP_IN ? use_link : def_link;
   entry = type == OP_IN ? use_entry : def_entry;
   for (; *ref; ref++)
-   if (DF_REF_LOC (*ref) == recog_data.operand_loc[op])
- break;
+   {
+ if (DF_REF_LOC (*ref) == recog_data.operand_loc[op])
+   break;
+ if (DF_REF_REAL_LOC (*ref) == recog_data.operand_loc[op])
+   break;
+   }
 
   if (!*ref && type == OP_INOUT)
{
  for (ref = use_link, entry = use_entry; *ref; ref++)
-   if (DF_REF_LOC (*ref) == recog_data.operand_loc[op])
- break;
+   {
+ if (DF_REF_LOC (*ref) == recog_data.operand_loc[op])
+   break;
+ if (DF_REF_REAL_LOC (*ref) == recog_data.operand_loc[op])
+   break;
+   }
}
 
   gcc_assert (*ref);
--

[C++ PATCH] Fix -Wsequence-point with SIZEOF_EXPR (PR c++/57274)

[Jakub Jelinek]

Hi!

Another regression caused by the delayed SIZEOF_EXPR evaluation.
For the purposes of -Wsequence-point warnings we should never
recurse into SIZEOF_EXPR operand, the expressions in there aren't
evaluated there.

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

2013-05-14  Jakub Jelinek  

PR c++/57274
* c-common.c (verify_tree): Don't recurse into SIZEOF_EXPR.

* c-c++-common/Wsequence-point-1.c: New test.

--- gcc/c-family/c-common.c.jj  2013-05-13 09:44:53.0 +0200
+++ gcc/c-family/c-common.c 2013-05-14 17:04:59.273912576 +0200
@@ -3032,6 +3032,7 @@ verify_tree (tree x, struct tlist **pbef
   switch (code)
 {
 case CONSTRUCTOR:
+case SIZEOF_EXPR:
   return;
 
 case COMPOUND_EXPR:
--- gcc/testsuite/c-c++-common/Wsequence-point-1.c.jj   2013-05-14 
17:02:55.588608130 +0200
+++ gcc/testsuite/c-c++-common/Wsequence-point-1.c  2013-05-14 
17:01:06.0 +0200
@@ -0,0 +1,17 @@
+/* PR c++/57274 */
+/* { dg-do compile } */
+/* { dg-options "-Wsequence-point" } */
+
+void foo (int, int);
+
+void
+bar (int *x)
+{
+  foo (*x++, sizeof (*x)); /* { dg-bogus "may be undefined" } */
+}
+
+void
+baz (int *x)
+{
+  foo (*x, sizeof (*x++) + sizeof (*x++)); /* { dg-bogus "may be 
undefined" } */
+}

Jakub

[PATCH] Small color diagnostics tweak

[Jakub Jelinek]

Hi!

A few spots which print file:line or file:line:column info, but weren't
using locus color for it.

Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux,
also tested with ./xg++ -B ./ -S -fdiagnostics-color=auto test.ii on:
# 1 "test.c"
# 1 ""
# 1 "test.c"
# 1 "test1.h" 1
# 1 "test2.h" 1
void foo (void) __attribute__((deprecated ("foo")));
int i;
void baz (void)
{
  i = i / 0;
}
# 1 "test1.h" 2
# 2 "test.c" 2
void
bar (void)
{
  foo ();
}

Ok for trunk?

2013-05-14  Jakub Jelinek  

* tree.c (warn_deprecated_use): Print file:line using locus color.
* diagnostic.c (diagnostic_report_current_module): Print file:line
and file:line:column using locus color.

--- gcc/tree.c.jj   2013-05-13 12:50:10.0 +0200
+++ gcc/tree.c  2013-05-14 17:54:46.835156217 +0200
@@ -11715,12 +11715,12 @@ warn_deprecated_use (tree node, tree att
   expanded_location xloc = expand_location (DECL_SOURCE_LOCATION (node));
   if (msg)
warning (OPT_Wdeprecated_declarations,
-"%qD is deprecated (declared at %s:%d): %s",
-node, xloc.file, xloc.line, msg);
+"%qD is deprecated (declared at %r%s:%d%R): %s",
+node, "locus", xloc.file, xloc.line, msg);
   else
warning (OPT_Wdeprecated_declarations,
-"%qD is deprecated (declared at %s:%d)",
-node, xloc.file, xloc.line);
+"%qD is deprecated (declared at %r%s:%d%R)",
+node, "locus", xloc.file, xloc.line);
 }
   else if (TYPE_P (node))
 {
@@ -11744,23 +11744,23 @@ warn_deprecated_use (tree node, tree att
{
  if (msg)
warning (OPT_Wdeprecated_declarations,
-"%qE is deprecated (declared at %s:%d): %s",
-what, xloc.file, xloc.line, msg);
+"%qE is deprecated (declared at %r%s:%d%R): %s",
+what, "locus", xloc.file, xloc.line, msg);
  else
warning (OPT_Wdeprecated_declarations,
-"%qE is deprecated (declared at %s:%d)", what,
-xloc.file, xloc.line);
+"%qE is deprecated (declared at %r%s:%d%R)",
+what, "locus", xloc.file, xloc.line);
}
  else
{
  if (msg)
warning (OPT_Wdeprecated_declarations,
-"type is deprecated (declared at %s:%d): %s",
-xloc.file, xloc.line, msg);
+"type is deprecated (declared at %r%s:%d%R): %s",
+"locus", xloc.file, xloc.line, msg);
  else
warning (OPT_Wdeprecated_declarations,
-"type is deprecated (declared at %s:%d)",
-xloc.file, xloc.line);
+"type is deprecated (declared at %r%s:%d%R)",
+"locus", xloc.file, xloc.line);
}
}
   else
--- gcc/diagnostic.c.jj 2013-04-26 08:54:05.0 +0200
+++ gcc/diagnostic.c2013-05-14 17:58:51.976769978 +0200
@@ -517,18 +517,18 @@ diagnostic_report_current_module (diagno
  map = INCLUDED_FROM (line_table, map);
  if (context->show_column)
pp_verbatim (context->printer,
-"In file included from %s:%d:%d",
+"In file included from %r%s:%d:%d%R", "locus",
 LINEMAP_FILE (map),
 LAST_SOURCE_LINE (map), LAST_SOURCE_COLUMN (map));
  else
pp_verbatim (context->printer,
-"In file included from %s:%d",
+"In file included from %r%s:%d%R", "locus",
 LINEMAP_FILE (map), LAST_SOURCE_LINE (map));
  while (! MAIN_FILE_P (map))
{
  map = INCLUDED_FROM (line_table, map);
  pp_verbatim (context->printer,
-  ",\n from %s:%d",
+  ",\n from %r%s:%d%R", "locus",
   LINEMAP_FILE (map), LAST_SOURCE_LINE (map));
}
  pp_verbatim (context->printer, ":");

Jakub

Re: [PATCH] Use indentation in gtype.state to show nested structure

[David Malcolm]

On Tue, 2013-05-14 at 11:44 -0600, Jeff Law wrote:
> On 05/06/2013 03:05 PM, David Malcolm wrote:

[...snip review and comments about auto-checking of formatting...]

> Anyway, the patch is good to go.   Please install.

Thanks for reviewing.

Probably a dumb question, but by "Please install", do you mean, "please
commit to SVN"?

This is my first accepted patch to GCC and I don't have rights to commit
to svn (sorry if that was unclear).

Dave

debuggability of recog_data

[Mike Stump]

Here is a trivial patch that improves the debuggability of recog_data.  Without 
this p recog_data in gdb on linux, didn't seem to work at all.  My fingers were 
not amused.  :-)

Checked it in a obvious.

2013-05-14  Mike Stump  

* recog.h: Rename struct recog_data to Recog_data.
* recog.c: Likewise.
* reload.c (can_reload_into): Likewise.
* config/picochip/picochip.c: Likewise.

Index: config/picochip/picochip.c
===
--- config/picochip/picochip.c  (revision 198896)
+++ config/picochip/picochip.c  (working copy)
@@ -187,7 +187,7 @@ struct vliw_state picochip_current_vliw_
 
 /* Save/restore recog_data. */
 static int picochip_saved_which_alternative;
-static struct recog_data picochip_saved_recog_data;
+static struct Recog_data picochip_saved_recog_data;
 
 /* Determine which ALU to use for the instruction in
picochip_current_prescan_insn. */
@@ -3150,7 +3150,7 @@ picochip_save_recog_data (void)
 {
   picochip_saved_which_alternative = which_alternative;
   memcpy (&picochip_saved_recog_data, &recog_data,
- sizeof (struct recog_data));
+ sizeof (struct Recog_data));
 }
 
 /* Restore some of the contents of global variable recog_data. */
@@ -3159,7 +3159,7 @@ picochip_restore_recog_data (void)
 {
   which_alternative = picochip_saved_which_alternative;
   memcpy (&recog_data, &picochip_saved_recog_data,
- sizeof (struct recog_data));
+ sizeof (struct Recog_data));
 }
 
 /* Ensure that no var tracking notes are emitted in the middle of a
Index: recog.c
===
--- recog.c (revision 198896)
+++ recog.c (working copy)
@@ -70,7 +70,7 @@ static rtx split_insn (rtx);
 
 int volatile_ok;
 
-struct recog_data recog_data;
+struct Recog_data recog_data;
 
 /* Contains a vector of operand_alternative structures for every operand.
Set up by preprocess_constraints.  */
Index: recog.h
===
--- recog.h (revision 198896)
+++ recog.h (working copy)
@@ -179,7 +179,7 @@ extern int which_alternative;
 
 /* The following vectors hold the results from insn_extract.  */
 
-struct recog_data
+struct Recog_data
 {
   /* It is very tempting to make the 5 operand related arrays into a
  structure and index on that.  However, to be source compatible
@@ -245,7 +245,7 @@ struct recog_data
   rtx insn;
 };
 
-extern struct recog_data recog_data;
+extern struct Recog_data recog_data;
 
 /* Contains a vector of operand_alternative structures for every operand.
Set up by preprocess_constraints.  */
Index: reload.c
===
--- reload.c(revision 198896)
+++ reload.c(working copy)
@@ -895,7 +895,7 @@ can_reload_into (rtx in, int regno, enum
 {
   rtx dst, test_insn;
   int r = 0;
-  struct recog_data save_recog_data;
+  struct Recog_data save_recog_data;
 
   /* For matching constraints, we often get notional input reloads where
  we want to use the original register as the reload register.  I.e.
--

[patch update] Support .eh_frame in crt1 x86_64 glibc (PR libgcc/57280, libc/15407)

[Jan Kratochvil]

Added its gcc/doc/ part.  Previous pending post was:
http://gcc.gnu.org/ml/gcc-patches/2013-05/msg00275.html
Message-ID: <20130506172221.ga21...@host2.jankratochvil.net>
--
Hi,

since
[patch] x86_64: CFI unwinding stop in _start
http://sourceware.org/ml/libc-alpha/2012-03/msg00573.html

there is a regression reproducible with gold:
http://sourceware.org/bugzilla/show_bug.cgi?id=15407
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57280 (GCC tracker)

as .eh_frame is created before the __EH_FRAME_BEGIN__ marker.  Linking order:
/usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../lib64/crt1.o
^^^ .eh_frame is used here
/usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../lib64/crti.o
/usr/lib/gcc/x86_64-redhat-linux/4.7.2/crtbegin.o
^^^ __EH_FRAME_BEGIN__ marker here

Therefore proposing to move the __EH_FRAME_BEGIN__ marker earlier:
/usr/lib/gcc/x86_64-redhat-linux/4.7.2/crtbegin1.o
^^^ __EH_FRAME_BEGIN__ marker here
/usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../lib64/crt1.o
^^^ .eh_frame is used here
/usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../lib64/crti.o
/usr/lib/gcc/x86_64-redhat-linux/4.7.2/crtbegin.o

It is questionable which all targets should this change affect.  If find it
a needless + untestable change to split crtbegin.o for very every target.
I have split it for every glibc x86_64 target (I hope) even if the one uses
PT_GNU_EH_FRAME (for which the __EH_FRAME_BEGIN__ marker is not needed),
it does not hurt and it was easier (possible?) that way.

I have split it also for the non-Linux glibc i386 + x86_64 targets as AFAIK
they are also affected the same way by the glibc change.

I had to split also i386 despite the glibc change affects only x86_64.  It was
needed for the case of --target=i686-pc-linux-gnu --enable-targets=all where:

gcc/config.gcc:
i[34567]86-*-linux* | i[34567]86-*-kfreebsd*-gnu | i[34567]86-*-knetbsd*-gnu | 
i[34567]86-*-gnu* | i[34567]86-*-kopensolaris*-gnu)
[...]
if test x$enable_targets = xall; then
tm_file="${tm_file} i386/x86-64.h 
i386/gnu-user-common.h i386/gnu-user64.h i386/linux-common.h i386/linux64.h"

Here the x86_64 *.h files get included even for the i386 target configuration
so it is no longer possible to make the spec change different for i386.

No regressions for Fedora 19 x86_64 GCC 4.9.0 20130504
and for gcc-4.8.0-3.fc19.{x86_64,i686}.

The x$enable_targets = xall case was tested on Debian 7.0 i386 with:
  --enable-languages=c --without-cloog --disable-libquadmath 
--enable-targets=all

It would be good to test also on some of the *BSD hosts, I will try some from
the GCC Compile Farm if this patch gets approved.


Thanks,
Jan


gcc/
2013-05-14  Jan Kratochvil  

* config/i386/gnu-user-common.h (USE_CRT_BEGIN1)
(GNU_USER_TARGET_BEGIN1_SPEC, STARTFILE_SPEC): New.
* config/i386/linux-common.h (STARTFILE_SPEC): Use also
GNU_USER_TARGET_BEGIN1_SPEC.
* doc/fragments.texi (Target Fragment): Mention also crtbeginS1.o for
CRTSTUFF_T_CFLAGS_S.
* doc/tm.texi.in (Initialization): Add crtbegin1.o to the example.
Mention also crtbeginS1.o for crtstuff.c.
(Exception Region Output): Add USE_CRT_BEGIN1.
* doc/tm.texi: Regenerated.

libgcc/
2013-05-06  Jan Kratochvil  

* Makefile.in (crtbegin1$(objext), crtbeginS1$(objext))
(crtbeginT1$(objext)): New.
* config.host (i[34567]86-*-linux*, i[34567]86-*-kfreebsd*-gnu)
(i[34567]86-*-knetbsd*-gnu, i[34567]86-*-gnu*)
(i[34567]86-*-kopensolaris*-gnu, x86_64-*-linux*)
(x86_64-*-kfreebsd*-gnu, x86_64-*-knetbsd*-gnu): Add crtbegin1.o,
crtbeginS1.o and crtbeginT1.o.
* crtstuff.c: New block for CRT_BEGIN1.  Copy __EH_FRAME_BEGIN__ there
and also move it to the start of CRT_BEGIN block.

diff --git a/gcc/config/i386/gnu-user-common.h 
b/gcc/config/i386/gnu-user-common.h
index e28483d..7848906 100644
--- a/gcc/config/i386/gnu-user-common.h
+++ b/gcc/config/i386/gnu-user-common.h
@@ -45,6 +45,14 @@ along with GCC; see the file COPYING3.  If not see
 #undef CC1_SPEC
 #define CC1_SPEC GNU_USER_TARGET_CC1_SPEC
 
+#undef USE_CRT_BEGIN1
+#define USE_CRT_BEGIN1
+#define GNU_USER_TARGET_BEGIN1_SPEC \
+  "%{static:crtbeginT1.o%s;shared|pie:crtbeginS1.o%s;:crtbegin1.o%s}"
+#undef  STARTFILE_SPEC
+#define STARTFILE_SPEC GNU_USER_TARGET_BEGIN1_SPEC " " \
+  GNU_USER_TARGET_STARTFILE_SPEC
+
 /* Similar to standard GNU userspace, but adding -ffast-math support.  */
 #define GNU_USER_TARGET_MATHFILE_SPEC \
   "%{Ofast|ffast-math|funsafe-math-optimizations:crtfastmath.o%s} \
diff --git a/gcc/config/i386/linux-common.h b/gcc/config/i386/linux-common.h
index 1e8bf6b..a442bb1 100644
--- a/gcc/config/i386/linux-common.h
+++ b/gcc/config/i386/linux-common

debuggability of DF_REF_LOC

[Mike Stump]

I was trying to debug with DF_REF_LOC in gdb on linux, and got:

(gdb) p DF_REF_LOC (*ref) == recog_data.operand_loc[op]
No symbol "__null" in current context.

My fingers were not amused.  I found if I did:

(gdb) macro define __null 0

then I could do:

(gdb) p DF_REF_LOC (*ref) == recog_data.operand_loc[op]
$3 = true

and my fingers were again happy.

I checked this in.

2013-05-14  Mike Stump  

* gdbinit.in: Add __null.

Index: gdbinit.in
===
--- gdbinit.in  (revision 198896)
+++ gdbinit.in  (working copy)
@@ -184,6 +184,7 @@ end
 # Define some macros helpful to gdb when it is expanding macros.
 macro define __FILE__ "gdb"
 macro define __LINE__ 1
+macro define __null 0
 
 # Gracefully handle aborts in functions used from gdb.
 set unwindonsignal on
--

Re: [PATCH] Small color diagnostics tweak

[Gabriel Dos Reis]

OK.

On Tue, May 14, 2013 at 1:52 PM, Jakub Jelinek  wrote:
> Hi!
>
> A few spots which print file:line or file:line:column info, but weren't
> using locus color for it.
>
> Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux,
> also tested with ./xg++ -B ./ -S -fdiagnostics-color=auto test.ii on:
> # 1 "test.c"
> # 1 ""
> # 1 "test.c"
> # 1 "test1.h" 1
> # 1 "test2.h" 1
> void foo (void) __attribute__((deprecated ("foo")));
> int i;
> void baz (void)
> {
>   i = i / 0;
> }
> # 1 "test1.h" 2
> # 2 "test.c" 2
> void
> bar (void)
> {
>   foo ();
> }
>
> Ok for trunk?
>
> 2013-05-14  Jakub Jelinek  
>
> * tree.c (warn_deprecated_use): Print file:line using locus color.
> * diagnostic.c (diagnostic_report_current_module): Print file:line
> and file:line:column using locus color.
>
> --- gcc/tree.c.jj   2013-05-13 12:50:10.0 +0200
> +++ gcc/tree.c  2013-05-14 17:54:46.835156217 +0200
> @@ -11715,12 +11715,12 @@ warn_deprecated_use (tree node, tree att
>expanded_location xloc = expand_location (DECL_SOURCE_LOCATION (node));
>if (msg)
> warning (OPT_Wdeprecated_declarations,
> -"%qD is deprecated (declared at %s:%d): %s",
> -node, xloc.file, xloc.line, msg);
> +"%qD is deprecated (declared at %r%s:%d%R): %s",
> +node, "locus", xloc.file, xloc.line, msg);
>else
> warning (OPT_Wdeprecated_declarations,
> -"%qD is deprecated (declared at %s:%d)",
> -node, xloc.file, xloc.line);
> +"%qD is deprecated (declared at %r%s:%d%R)",
> +node, "locus", xloc.file, xloc.line);
>  }
>else if (TYPE_P (node))
>  {
> @@ -11744,23 +11744,23 @@ warn_deprecated_use (tree node, tree att
> {
>   if (msg)
> warning (OPT_Wdeprecated_declarations,
> -"%qE is deprecated (declared at %s:%d): %s",
> -what, xloc.file, xloc.line, msg);
> +"%qE is deprecated (declared at %r%s:%d%R): %s",
> +what, "locus", xloc.file, xloc.line, msg);
>   else
> warning (OPT_Wdeprecated_declarations,
> -"%qE is deprecated (declared at %s:%d)", what,
> -xloc.file, xloc.line);
> +"%qE is deprecated (declared at %r%s:%d%R)",
> +what, "locus", xloc.file, xloc.line);
> }
>   else
> {
>   if (msg)
> warning (OPT_Wdeprecated_declarations,
> -"type is deprecated (declared at %s:%d): %s",
> -xloc.file, xloc.line, msg);
> +"type is deprecated (declared at %r%s:%d%R): %s",
> +"locus", xloc.file, xloc.line, msg);
>   else
> warning (OPT_Wdeprecated_declarations,
> -"type is deprecated (declared at %s:%d)",
> -xloc.file, xloc.line);
> +"type is deprecated (declared at %r%s:%d%R)",
> +"locus", xloc.file, xloc.line);
> }
> }
>else
> --- gcc/diagnostic.c.jj 2013-04-26 08:54:05.0 +0200
> +++ gcc/diagnostic.c2013-05-14 17:58:51.976769978 +0200
> @@ -517,18 +517,18 @@ diagnostic_report_current_module (diagno
>   map = INCLUDED_FROM (line_table, map);
>   if (context->show_column)
> pp_verbatim (context->printer,
> -"In file included from %s:%d:%d",
> +"In file included from %r%s:%d:%d%R", "locus",
>  LINEMAP_FILE (map),
>  LAST_SOURCE_LINE (map), LAST_SOURCE_COLUMN (map));
>   else
> pp_verbatim (context->printer,
> -"In file included from %s:%d",
> +"In file included from %r%s:%d%R", "locus",
>  LINEMAP_FILE (map), LAST_SOURCE_LINE (map));
>   while (! MAIN_FILE_P (map))
> {
>   map = INCLUDED_FROM (line_table, map);
>   pp_verbatim (context->printer,
> -  ",\n from %s:%d",
> +  ",\n from %r%s:%d%R", "locus",
>LINEMAP_FILE (map), LAST_SOURCE_LINE (map));
> }
>   pp_verbatim (context->printer, ":");
>
> Jakub

Re: debuggability of DF_REF_LOC

[Andrew Pinski]

On Tue, May 14, 2013 at 12:18 PM, Mike Stump  wrote:
> I was trying to debug with DF_REF_LOC in gdb on linux, and got:
>
> (gdb) p DF_REF_LOC (*ref) == recog_data.operand_loc[op]
> No symbol "__null" in current context.
>
> My fingers were not amused.  I found if I did:
>
> (gdb) macro define __null 0
>
> then I could do:
>
> (gdb) p DF_REF_LOC (*ref) == recog_data.operand_loc[op]
> $3 = true
>
> and my fingers were again happy.
>
> I checked this in.

I think gdb should support __null anyways.  Can you see if a newer
version of gdb supports it and if it does not, please file a bug?

Thanks,
Andrew

Re: Add std::unordered_* C++11 allocator support

[François Dumont]

Indeed, here is the patch to fix it. Also fix rendering of std::tr1 
unordered containers.


2013-05-15  François Dumont 

* python/libstdcxx/v6/printers.py (Tr1HashtableIterator): Fix
rendering of std::tr1 unordered containers iterator.
(StdHashtableIterator): New, render std unordered containers iterator.
* testsuite/libstdc++-prettyprinters/tr1.cc: New.


Tested under Linux x86_64 using gdb 7.6

Ok to commit ?

François

On 05/10/2013 06:43 PM, Paolo Carlini wrote:

.. looks like the prettyprinting code needs again adjustments:

FAIL: libstdc++-prettyprinters/cxx11.cc print uom
FAIL: libstdc++-prettyprinters/cxx11.cc print uomm
FAIL: libstdc++-prettyprinters/cxx11.cc print uos
FAIL: libstdc++-prettyprinters/cxx11.cc print uoms

Thanks,
Paolo.




Index: python/libstdcxx/v6/printers.py
===
--- python/libstdcxx/v6/printers.py	(revision 198805)
+++ python/libstdcxx/v6/printers.py	(working copy)
@@ -621,8 +621,16 @@
 
 class Tr1HashtableIterator:
 def __init__ (self, hash):
-self.node = hash['_M_bbegin']['_M_node']['_M_nxt']
-self.node_type = find_type(hash.type, '__node_type').pointer()
+self.buckets = hash['_M_buckets']
+self.bucket = 0
+self.bucket_count = hash['_M_bucket_count']
+self.node_type = find_type(hash.type, '_Node').pointer()
+self.node = 0
+while self.bucket != self.bucket_count:
+self.node = self.buckets[self.bucket]
+if self.node:
+break
+self.bucket = self.bucket + 1
 
 def __iter__ (self):
 return self
@@ -632,9 +640,33 @@
 raise StopIteration
 node = self.node.cast(self.node_type)
 result = node.dereference()['_M_v']
-self.node = node.dereference()['_M_nxt']
+self.node = node.dereference()['_M_next'];
+if self.node == 0:
+self.bucket = self.bucket + 1
+while self.bucket != self.bucket_count:
+self.node = self.buckets[self.bucket]
+if self.node:
+break
+self.bucket = self.bucket + 1
 return result
 
+class StdHashtableIterator:
+def __init__(self, hash):
+self.node = hash['_M_bbegin']['_M_node']['_M_nxt']
+self.node_type = find_type(hash.type, '__node_type').pointer()
+
+def __iter__(self):
+return self
+
+def next(self):
+if self.node == 0:
+raise StopIteration
+elt = self.node.cast(self.node_type).dereference()
+self.node = elt['_M_nxt']
+valptr = elt['_M_storage'].address
+valptr = valptr.cast(elt.type.template_argument(0).pointer())
+return valptr.dereference()
+
 class Tr1UnorderedSetPrinter:
 "Print a tr1::unordered_set"
 
@@ -656,7 +688,9 @@
 
 def children (self):
 counter = itertools.imap (self.format_count, itertools.count())
-return itertools.izip (counter, Tr1HashtableIterator (self.hashtable()))
+if self.typename.startswith('std::tr1'):
+return itertools.izip (counter, Tr1HashtableIterator (self.hashtable()))
+return itertools.izip (counter, StdHashtableIterator (self.hashtable()))
 
 class Tr1UnorderedMapPrinter:
 "Print a tr1::unordered_map"
@@ -690,9 +724,14 @@
 def children (self):
 counter = itertools.imap (self.format_count, itertools.count())
 # Map over the hash table and flatten the result.
-data = self.flatten (itertools.imap (self.format_one, Tr1HashtableIterator (self.hashtable(
+if self.typename.startswith('std::tr1'):
+data = self.flatten (itertools.imap (self.format_one, Tr1HashtableIterator (self.hashtable(
+# Zip the two iterators together.
+return itertools.izip (counter, data)
+data = self.flatten (itertools.imap (self.format_one, StdHashtableIterator (self.hashtable(
 # Zip the two iterators together.
 return itertools.izip (counter, data)
+
 
 def display_hint (self):
 return 'map'
Index: testsuite/libstdc++-prettyprinters/tr1.cc
===
--- testsuite/libstdc++-prettyprinters/tr1.cc	(revision 0)
+++ testsuite/libstdc++-prettyprinters/tr1.cc	(revision 0)
@@ -0,0 +1,90 @@
+// { dg-do run }
+// { dg-options "-g" }
+
+// 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
+

Re: sparc64*-*-rtems* should not define __svr4__

[Eric Botcazou]

> I forgot to ask. Did you put this on the open branches as well? 4.7 and 4.8.

No, on mainline only (as written in the previous message).  I can backport to 
4.8 though, but it's too late for 4.7.

-- 
Eric Botcazou

C++ PATCH for c++/57243 (range for in template)

[Jason Merrill]

We should call complete_type before deciding that a type can't be completed.

Tested x86_64-pc-linux-gnu, applying to trunk and 4.8.
commit a0f9f1db9cb900ac3ab2aa1e61bc51616b4d2be4
Author: Jason Merrill 
Date:   Tue May 14 11:50:26 2013 -0400

	PR c++/57243
	* parser.c (cp_parser_range_for): Call complete_type.

diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index f65ec97..0a075b2 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -9735,7 +9735,7 @@ cp_parser_range_for (cp_parser *parser, tree scope, tree init, tree range_decl)
   if (range_expr != error_mark_node
 	  && !type_dependent_expression_p (range_expr)
 	  /* The length of an array might be dependent.  */
-	  && COMPLETE_TYPE_P (TREE_TYPE (range_expr))
+	  && COMPLETE_TYPE_P (complete_type (TREE_TYPE (range_expr)))
 	  /* do_auto_deduction doesn't mess with template init-lists.  */
 	  && !BRACE_ENCLOSED_INITIALIZER_P (range_expr))
 	do_range_for_auto_deduction (range_decl, range_expr);
diff --git a/gcc/testsuite/g++.dg/cpp0x/range-for25.C b/gcc/testsuite/g++.dg/cpp0x/range-for25.C
new file mode 100644
index 000..8ba9f65
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/range-for25.C
@@ -0,0 +1,30 @@
+// PR c++/57243
+// { dg-require-effective-target c++11 }
+
+struct snarf
+{
+  template 
+  void get() {}
+};
+
+template 
+struct container
+{
+  snarf * begin() { return nullptr; }
+  snarf * end() { return nullptr; }
+};
+
+template 
+void foo()
+{
+  container arr;
+
+  for( auto i : arr )
+i.get();
+}
+
+int main()
+{
+  return 0;
+}
+

Re: RFC: PATCH to avoid linking multiple front ends at once with parallel make

[Jason Merrill]

On 05/14/2013 01:24 PM, Tom Tromey wrote:

It seems to me you can get the desired functionality in the Makefiles
using order-only dependencies -- just force some ordering of the
targets.


Order dependencies are the wrong solution: for one thing, they don't 
allow for building just a single front end, which I do all the time. 
And rebuilding, say, the Fortran front end shouldn't mean that we then 
need to rebuild the Java front end as well.


Jason

Re: RFC: PATCH to avoid linking multiple front ends at once with parallel make

[Jason Merrill]

On 05/14/2013 02:04 PM, Mike Stump wrote:

I worry about quoting.


In my experience, "$@" does fine for passing on arguments.

Jason

Re: [C++ PATCH] Fix -Wsequence-point with SIZEOF_EXPR (PR c++/57274)

[Jason Merrill]

Ok.

Jason

Re: [PATCH] New switch optimization pass (PR tree-optimization/54742)

[Steve Ellcey]

While Jeff works on the threader, I was wondering if I could get approval for
just the dominance.c part of the patch.  This would allow me to use my pass as
a dynamically loaded optimization pass.  But without this change to dominance.c,
the compiler aborts in iterate_fix_dominators when I do that.

Steve Ellcey
sell...@imgtec.com



2013-05-14  Steve Ellcey  

* dominance.c (iterate_fix_dominators): Add null check.


diff --git a/gcc/dominance.c b/gcc/dominance.c
index 5c96dad..d858ad1 100644
--- a/gcc/dominance.c
+++ b/gcc/dominance.c
@@ -1251,6 +1251,7 @@ iterate_fix_dominators (enum cdi_direction dir, 
vec bbs,
   struct pointer_map_t *map;
   int *parent, *son, *brother;
   unsigned int dir_index = dom_convert_dir_to_idx (dir);
+  void **slot;
 
   /* We only support updating dominators.  There are some problems with
  updating postdominators (need to add fake edges from infinite loops
@@ -1357,7 +1358,10 @@ iterate_fix_dominators (enum cdi_direction dir, 
vec bbs,
  if (dom == bb)
continue;
 
- dom_i = (size_t) *pointer_map_contains (map, dom);
+ slot = pointer_map_contains (map, dom);
+ if (slot == NULL)
+   continue;
+ dom_i = (size_t) *slot;
 
  /* Do not include parallel edges to G.  */
  if (!bitmap_set_bit ((bitmap) g->vertices[dom_i].data, i))