Re: [Patch, Fortran] Fix MOVE_ALLOC check

[Paul Richard Thomas]

Dear Tobias,

On Fri, Dec 2, 2011 at 10:07 PM, Tobias Burnus  wrote:
> This patches fixes my previous MOVE_ALLOC patch. The standard states for TO:
> "It shall be polymorphic if FROM is polymorphic."
>
> I somehow read this bijectively, but the it is actually allowed to have a
> nonpolymorphic FROM with a polymorphic TO. Thanks for Damian for finding
> this.
>
> Build and regtested on x86-64-linux.
> OK for the trunk?

Yes, of course this is OK.

Thanks for fixing it so quickly

Paul

>
> Tobias
>
> PS: Other pending patches:
> - http://gcc.gnu.org/ml/fortran/2011-11/msg00249.html - Pointer INTENT(IN)
> check for MOVE_ALLOC [4.6/4.7 rejects-valid regression]
> - http://gcc.gnu.org/ml/fortran/2011-11/msg00250.html - no -fcheck=bounds
> for character(LEN=:) to avoid ICE
> - http://gcc.gnu.org/ml/fortran/2011-11/msg00253.html - (Re)enable warning
> if a function result variable is not set [4.4-4.7 diagnostics regression]
> - http://gcc.gnu.org/ml/fortran/2011-11/msg00254.html - Thomas'
> dependency-ICE patch [4.6/4.7 regression]
> - http://gcc.gnu.org/ml/fortran/2011-12/msg5.html - Fix component-access
> check



-- 
The knack of flying is learning how to throw yourself at the ground and miss.
       --Hitchhikers Guide to the Galaxy

Re: [Patch, Fortran] [4.6/4.7] PR 50684 - fix intent(in) check

[Paul Richard Thomas]

Dear Tobias,

This is OK for both 4.6 and 4.7.

Many thanks, sir!

Paul

On Tue, Nov 29, 2011 at 7:32 PM, Tobias Burnus  wrote:
> Dear all,
>
> gfortran 4.6 and 4.7 have a too tight check whether a variable can be
> modified if the actual argument is INTENT(IN). This patch relaxes/fixes the
> checking.
>
> Build and regtested on x86-64-linux.
> OK for the trunk - and for 4.6 (as it is a regression)?
>
> Tobias



-- 
The knack of flying is learning how to throw yourself at the ground and miss.
       --Hitchhikers Guide to the Galaxy

[patch] add __is_final trait to fix libstdc++/51365

[Jonathan Wakely]

This implements a new C++ trait, __is_final, to query the 'final'
specifier that 4.7 supports. The trait is needed for the library so we
can detect when it's not possible to derive from a type in order to
exploit the empty base-class optimisation.  This affects all
containers, std::shared_ptr, std::future, std::tuple and anywhere else
that tries to use the EBO.  It's not a C++11-only problem because we
support __final in c++98 mode.  See PR libstdc++/51365 for examples of
programs using final classes that cause problems in libstdc++ and for
patches to the library that use this trait to solve the problems.

I originally thought about naming this __is_final_class, which would
allow a possible __is_final_function in future, but I think
__is_final(type) is pretty clear.  There is a proposal to add
__is_final to Clang with the same spelling and semantics.

Tested x86_64-linux, ok for trunk?

c-family/ChangeLog:

* c-common.c (RID_IS_FINAL): Add.
* c-common.h (RID_IS_FINAL): Add.

cp/ChangeLog:

* cp-tree.h (CPTK_IS_FINAL): Add.
* parser.c (cp_parser_translation_unit): Handle RID_IS_FINAL.
(cp_parser_primary_expression, cp_parser_trait_expr): Likewise.
* semantics.c (trait_expr_value, finish_trait_expr): Handle
CPTK_IS_FINAL.
* cxx-pretty-print.c (pp_cxx_trait_expression): Likewise.

ChangeLog:

* doc/extend.texi (Type Traits): Add __is_final.

testsuite/ChangeLog:

* g++.dg/ext/is_final.C: New.
Index: c-family/c-common.c
===
--- c-family/c-common.c (revision 181967)
+++ c-family/c-common.c (working copy)
@@ -462,6 +462,7 @@ const struct c_common_resword c_common_r
   { "__is_convertible_to", RID_IS_CONVERTIBLE_TO, D_CXXONLY },
   { "__is_empty",  RID_IS_EMPTY,   D_CXXONLY },
   { "__is_enum",   RID_IS_ENUM,D_CXXONLY },
+  { "__is_final",  RID_IS_FINAL,   D_CXXONLY },
   { "__is_literal_type", RID_IS_LITERAL_TYPE, D_CXXONLY },
   { "__is_pod",RID_IS_POD, D_CXXONLY },
   { "__is_polymorphic",RID_IS_POLYMORPHIC, D_CXXONLY },
Index: c-family/c-common.h
===
--- c-family/c-common.h (revision 181967)
+++ c-family/c-common.h (working copy)
@@ -134,7 +134,7 @@ enum rid
   RID_CONSTCAST, RID_DYNCAST, RID_REINTCAST, RID_STATCAST,
 
   /* C++ extensions */
-  RID_BASES,  RID_DIRECT_BASES,
+  RID_BASES,   RID_DIRECT_BASES,
   RID_HAS_NOTHROW_ASSIGN,  RID_HAS_NOTHROW_CONSTRUCTOR,
   RID_HAS_NOTHROW_COPY,RID_HAS_TRIVIAL_ASSIGN,
   RID_HAS_TRIVIAL_CONSTRUCTOR, RID_HAS_TRIVIAL_COPY,
@@ -142,12 +142,12 @@ enum rid
   RID_IS_ABSTRACT, RID_IS_BASE_OF,
   RID_IS_CLASS,RID_IS_CONVERTIBLE_TO,
   RID_IS_EMPTY,RID_IS_ENUM,
-  RID_IS_LITERAL_TYPE, RID_IS_POD,
-  RID_IS_POLYMORPHIC,  RID_IS_STD_LAYOUT,
-  RID_IS_TRIVIAL,  RID_IS_UNION,
-  RID_UNDERLYING_TYPE,
+  RID_IS_FINAL,RID_IS_LITERAL_TYPE,
+  RID_IS_POD,  RID_IS_POLYMORPHIC,
+  RID_IS_STD_LAYOUT,   RID_IS_TRIVIAL,
+  RID_IS_UNION,RID_UNDERLYING_TYPE,
 
-  /* C++0x */
+  /* C++11 */
   RID_CONSTEXPR, RID_DECLTYPE, RID_NOEXCEPT, RID_NULLPTR, RID_STATIC_ASSERT,
 
   /* Objective-C ("AT" reserved words - they are only keywords when
Index: cp/cp-tree.h
===
--- cp/cp-tree.h(revision 181967)
+++ cp/cp-tree.h(working copy)
@@ -584,6 +584,7 @@ typedef enum cp_trait_kind
   CPTK_IS_CONVERTIBLE_TO,
   CPTK_IS_EMPTY,
   CPTK_IS_ENUM,
+  CPTK_IS_FINAL,
   CPTK_IS_LITERAL_TYPE,
   CPTK_IS_POD,
   CPTK_IS_POLYMORPHIC,
@@ -4923,6 +4924,7 @@ extern bool user_provided_p   (tree);
 extern bool type_has_user_provided_constructor  (tree);
 extern bool type_has_user_provided_default_constructor (tree);
 extern tree default_init_uninitialized_part (tree);
+extern void warn_missing_meminits (tree, tree);
 extern bool trivial_default_constructor_is_constexpr (tree);
 extern bool type_has_constexpr_default_constructor (tree);
 extern bool type_has_virtual_destructor(tree);
Index: cp/parser.c
===
--- cp/parser.c (revision 181967)
+++ cp/parser.c (working copy)
@@ -3854,6 +3854,7 @@ cp_parser_translation_unit (cp_parser* p
  __is_convertible_to ( type-id , type-id ) 
  __is_empty ( type-id )
  __is_enum ( type-id )
+ __is_final ( type-id )
  __is_literal_type ( type-id )
  __is_pod ( type-id )
  __is_polymorphic ( type-id )
@@ -4199,6 +4200,7 @@ cp_parser_primary_expression (cp_parser
case RID_IS_CONVERTIBLE_TO:
case RID_IS_EMPTY:
case RID_IS_ENUM:
+   case RID_IS_FINAL:
case RID_IS_LITERAL_TYPE:
case RID_IS_POD:
case RID_IS_POLYMORPH

Re: [patch] add __is_final trait to fix libstdc++/51365

[Jonathan Wakely]

On 3 December 2011 12:00, Jonathan Wakely wrote:
> This implements a new C++ trait, __is_final, to query the 'final'
> specifier that 4.7 supports. The trait is needed for the library so we
> can detect when it's not possible to derive from a type in order to
> exploit the empty base-class optimisation.  This affects all
> containers, std::shared_ptr, std::future, std::tuple and anywhere else
> that tries to use the EBO.  It's not a C++11-only problem because we
> support __final in c++98 mode.  See PR libstdc++/51365 for examples of
> programs using final classes that cause problems in libstdc++ and for
> patches to the library that use this trait to solve the problems.
>
> I originally thought about naming this __is_final_class, which would
> allow a possible __is_final_function in future, but I think
> __is_final(type) is pretty clear.  There is a proposal to add
> __is_final to Clang with the same spelling and semantics.
>
> Tested x86_64-linux, ok for trunk?
>
> c-family/ChangeLog:
>
>        * c-common.c (RID_IS_FINAL): Add.
>        * c-common.h (RID_IS_FINAL): Add.
>
> cp/ChangeLog:
>
>        * cp-tree.h (CPTK_IS_FINAL): Add.
>        * parser.c (cp_parser_translation_unit): Handle RID_IS_FINAL.
>        (cp_parser_primary_expression, cp_parser_trait_expr): Likewise.
>        * semantics.c (trait_expr_value, finish_trait_expr): Handle
>        CPTK_IS_FINAL.
>        * cxx-pretty-print.c (pp_cxx_trait_expression): Likewise.
>
> ChangeLog:
>
>        * doc/extend.texi (Type Traits): Add __is_final.
>
> testsuite/ChangeLog:
>
>        * g++.dg/ext/is_final.C: New.


Oops, there was a stray chunk in that patch:

@@ -4923,6 +4924,7 @@ extern bool user_provided_p   (tree);
 extern bool type_has_user_provided_constructor  (tree);
 extern bool type_has_user_provided_default_constructor (tree);
 extern tree default_init_uninitialized_part (tree);
+extern void warn_missing_meminits (tree, tree);
 extern bool trivial_default_constructor_is_constexpr (tree);
 extern bool type_has_constexpr_default_constructor (tree);
 extern bool type_has_virtual_destructor(tree);

Here's the correct patch (identical except for removing that piece)
Index: c-family/c-common.c
===
--- c-family/c-common.c (revision 181967)
+++ c-family/c-common.c (working copy)
@@ -462,6 +462,7 @@ const struct c_common_resword c_common_r
   { "__is_convertible_to", RID_IS_CONVERTIBLE_TO, D_CXXONLY },
   { "__is_empty",  RID_IS_EMPTY,   D_CXXONLY },
   { "__is_enum",   RID_IS_ENUM,D_CXXONLY },
+  { "__is_final",  RID_IS_FINAL,   D_CXXONLY },
   { "__is_literal_type", RID_IS_LITERAL_TYPE, D_CXXONLY },
   { "__is_pod",RID_IS_POD, D_CXXONLY },
   { "__is_polymorphic",RID_IS_POLYMORPHIC, D_CXXONLY },
Index: c-family/c-common.h
===
--- c-family/c-common.h (revision 181967)
+++ c-family/c-common.h (working copy)
@@ -134,7 +134,7 @@ enum rid
   RID_CONSTCAST, RID_DYNCAST, RID_REINTCAST, RID_STATCAST,
 
   /* C++ extensions */
-  RID_BASES,  RID_DIRECT_BASES,
+  RID_BASES,   RID_DIRECT_BASES,
   RID_HAS_NOTHROW_ASSIGN,  RID_HAS_NOTHROW_CONSTRUCTOR,
   RID_HAS_NOTHROW_COPY,RID_HAS_TRIVIAL_ASSIGN,
   RID_HAS_TRIVIAL_CONSTRUCTOR, RID_HAS_TRIVIAL_COPY,
@@ -142,12 +142,12 @@ enum rid
   RID_IS_ABSTRACT, RID_IS_BASE_OF,
   RID_IS_CLASS,RID_IS_CONVERTIBLE_TO,
   RID_IS_EMPTY,RID_IS_ENUM,
-  RID_IS_LITERAL_TYPE, RID_IS_POD,
-  RID_IS_POLYMORPHIC,  RID_IS_STD_LAYOUT,
-  RID_IS_TRIVIAL,  RID_IS_UNION,
-  RID_UNDERLYING_TYPE,
+  RID_IS_FINAL,RID_IS_LITERAL_TYPE,
+  RID_IS_POD,  RID_IS_POLYMORPHIC,
+  RID_IS_STD_LAYOUT,   RID_IS_TRIVIAL,
+  RID_IS_UNION,RID_UNDERLYING_TYPE,
 
-  /* C++0x */
+  /* C++11 */
   RID_CONSTEXPR, RID_DECLTYPE, RID_NOEXCEPT, RID_NULLPTR, RID_STATIC_ASSERT,
 
   /* Objective-C ("AT" reserved words - they are only keywords when
Index: cp/cp-tree.h
===
--- cp/cp-tree.h(revision 181967)
+++ cp/cp-tree.h(working copy)
@@ -584,6 +584,7 @@ typedef enum cp_trait_kind
   CPTK_IS_CONVERTIBLE_TO,
   CPTK_IS_EMPTY,
   CPTK_IS_ENUM,
+  CPTK_IS_FINAL,
   CPTK_IS_LITERAL_TYPE,
   CPTK_IS_POD,
   CPTK_IS_POLYMORPHIC,
Index: cp/parser.c
===
--- cp/parser.c (revision 181967)
+++ cp/parser.c (working copy)
@@ -3854,6 +3854,7 @@ cp_parser_translation_unit (cp_parser* p
  __is_convertible_to ( type-id , type-id ) 
  __is_empty ( type-id )
  __is_enum ( type-id )
+ __is_final ( type-id )
  __is_literal_type ( type-id )
  __is_pod ( type-id )
  __is_polymorphic ( type-id )
@@ -4199,6 +4200,7 @@ cp_parser_primary_expr

Re: Yet another issue with gcc current trunk with ada on cygwin: s-tpoaal.adb:60:13: "Specific" is undefined (more references follow)

[Dave Korn]

On 23/11/2011 08:43, Eric Botcazou wrote:
> On 23/11/2011 07:28, Eric Botcazou wrote:
>>> /usr/local/src/trunk/objdir.withada/./gcc/xgcc
>>> -B/usr/local/src/trunk/objdir.withada/./gcc/
>>> -B/usr/i686-pc-cygwin/bin/ -B/usr/i686-pc-cygwin/lib/ -isystem
>>> /usr/i686-pc-cygwin/include -isystem /usr/i686-pc-cygwin/sys-include
>>>  -c -g -O2-W -Wall -gnatpg -nostdinc   g-socthi.adb -o g-socthi.o
>>> g-socthi.adb:615:15: "WSASYSNOTREADY" is undefined
>>> g-socthi.adb:616:15: "WSAVERNOTSUPPORTED" is undefined
>>> g-socthi.adb:618:15: "WSANOTINITIALISED" is undefined
>>> g-socthi.adb:620:15: "WSAEDISCON" is undefined
>>> g-socthi.adb:627:15: duplication of choice value at line 575
>>> make[6]: *** [g-socthi.o] Error 1

>>> and that is beyond my grasp, there is something odd when cygwin is to
>>> use, I guess, mingw variants of files...
>> 
>> But grep is your friend.  See s-oscons-tmplt.c lines 1343 and below.

> Try adding defined (__CYGWIN__) to the first line.

  Actually, the real problem is that the Cygwin-targeted version of gnat
shouldn't need those definitions in the first place.  Cygwin provides a fairly
complete Linux/Posix feature-set, and doing an end-run around it by using the
underlying winsock API isn't usually a good idea, so I think that the better
solution is to switch over to the standard berksock implementation.

  The attached patch does that, and it also switches to the standard c-malloc
implementation, as the MinGW version relies on the _msize() API that isn't
provided in Cygwin.

  I also had to rejig the sysdep functions a bit, in order to make
__gnat_is_windows_xp() and __gnat_get_stack_bounds() available, else the final
link fails.  (I don't know what uses those, but would guess exception
handling; we should switch that over at some point too most likely, but let's
go one step at a time.  In the long run we probably ought to switch Cygwin
gnat over to use all the standard implementations and none of the MinGW
versions, but that's a larger and more complicated job, so this patch just
switches those two mentioned, which is the minimum needed to get it building
again.)

gcc/ada/ChangeLog:

* gcc-interface/Makefile.in (WIN_TARG_SUFFIX): New variable, used by
windows targets only to differentiate between MinGW and Cygwin.
(LIBGNAT_TARGET_PAIRS [windows targets]): Correctly detect cygwin,
which no longer has the '32' suffix, and use WIN_TARG_SUFFIX to choose
appropriate implementations of the sockets and memory packages.
* sysdep.c (WIN_SETMODE): New define to choose the correct spelling of
setmode/_setmode for MinGW and Cygwin, respectively.
(__gnat_set_binary_mode [windows targets]): Use the above, and enable
the windows version for Cygwin as well as MinGW.
(__gnat_set_text_mode [windows targets]): Likewise.
(__gnat_ttyname [windows targets]): Provide a Cygwin implementation
in addition to the MinGW version.
(__gnat_is_windows_xp): Make available to Cygwin as well as MinGW.
(__gnat_get_stack_bounds): Likewise.

  With this patch it all builds again.  Tests running, but the results have to
be better than not even building at all!  OK for trunk?

cheers,
  DaveK

Index: gcc/ada/gcc-interface/Makefile.in
===
--- gcc/ada/gcc-interface/Makefile.in	(revision 181901)
+++ gcc/ada/gcc-interface/Makefile.in	(working copy)
@@ -1573,18 +1573,23 @@ ifeq ($(strip $(filter-out avr none powerpc% eabis
   indepsw.adb
+#else
+#define WIN_SETMODE _setmode
+#endif
+
 void
 __gnat_set_binary_mode (int handle)
 {
-  _setmode (handle, O_BINARY);
+  WIN_SETMODE (handle, O_BINARY);
 }
 
 void
 __gnat_set_text_mode (int handle)
 {
-  _setmode (handle, O_TEXT);
+  WIN_SETMODE (handle, O_TEXT);
 }
 
-#ifdef __MINGW32__
-#include 
+#ifdef __CYGWIN__
 
-/* Return the name of the tty.   Under windows there is no name for
-   the tty, so this function, if connected to a tty, returns the generic name
-   "console".  */
-
 char *
 __gnat_ttyname (int filedes)
 {
-  if (isatty (filedes))
-return "console";
-  else
-return NULL;
+  extern char *ttyname (int);
+
+  return ttyname (filedes);
 }
 
+#endif /* __CYGWIN__ */
+
+#if defined (__CYGWIN__) || defined (__MINGW32__)
+#include 
+
 #ifndef RTX
 
 int __gnat_is_windows_xp (void);
@@ -178,7 +184,7 @@ __gnat_is_windows_xp (void)
   return is_win_xp;
 }
 
-#endif
+#endif /* !RTX */
 
 /* Get the bounds of the stack.  The stack pointer is supposed to be
initialized to BASE when a thread is created and the stack can be extended
@@ -198,8 +204,25 @@ __gnat_get_stack_bounds (void **base, void **limit
   *limit = tib->StackLimit;
 }
 
-#endif /* !__MINGW32__ */
+#endif /* __CYGWIN__ || __MINGW32__ */
 
+#ifdef __MINGW32__
+
+/* Return the name of the tty.   Under windows there is no name for
+   the tty, so this function, if connected to a tty, returns the generic name
+   "console". 

[v3] Doc tweak

[Jonathan Wakely]

* doc/xml/manual/utilities.xml: Remove outdated text.

I think we can assume everyone has a compiler that supports member
function templates.

Committed to trunk.
Index: doc/xml/manual/utilities.xml
===
--- doc/xml/manual/utilities.xml(revision 181967)
+++ doc/xml/manual/utilities.xml(working copy)
@@ -50,8 +50,7 @@
does what you think it does, first getting x
   and second getting y.

-   There is a copy constructor, but it requires that your compiler
-  handle member function templates:
+   There is a constructor template for copying pairs of other types:


 template  pair (const pair& p);

[v3] RFC: rename __calculate_memory_order

[Jonathan Wakely]

Are there any objections to this patch?

I find the function easier to parse in this form and it allows it to
be constexpr. Maybe more importantly, it determines the memory order
to be used by compare_exchange_xxx on failure so I think
__cmpexch_failure_order is a more descriptive name than
__calculate_memory_order.

* include/bits/atomic_base.h (__calculate_memory_order): Rename to...
(__cmpexch_failure_order): This, and rewrite as constexpr function.
(compare_exchange_strong, compare_exchange_weak): Use it.
* include/std/atomic (compare_exchange_strong, compare_exchange_weak):
Likewise.

Tested x86_64-linux.
Index: include/bits/atomic_base.h
===
--- include/bits/atomic_base.h  (revision 181967)
+++ include/bits/atomic_base.h  (working copy)
@@ -59,14 +59,12 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   memory_order_seq_cst
 } memory_order;
 
-  inline memory_order
-  __calculate_memory_order(memory_order __m) noexcept
+  // Drop release ordering as per [atomics.types.operations.req]/21
+  constexpr memory_order
+  __cmpexch_failure_order(memory_order __m) noexcept
   {
-const bool __cond1 = __m == memory_order_release;
-const bool __cond2 = __m == memory_order_acq_rel;
-memory_order __mo1(__cond1 ? memory_order_relaxed : __m);
-memory_order __mo2(__cond2 ? memory_order_acquire : __mo1);
-return __mo2;
+return __m == memory_order_acq_rel ? memory_order_acquire
+  : __m == memory_order_release ? memory_order_relaxed : __m;
   }
 
   inline void
@@ -505,7 +503,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
memory_order __m = memory_order_seq_cst) noexcept
   {
return compare_exchange_weak(__i1, __i2, __m,
-__calculate_memory_order(__m));
+__cmpexch_failure_order(__m));
   }
 
   bool
@@ -513,7 +511,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   memory_order __m = memory_order_seq_cst) volatile noexcept
   {
return compare_exchange_weak(__i1, __i2, __m,
-__calculate_memory_order(__m));
+__cmpexch_failure_order(__m));
   }
 
   bool
@@ -544,7 +542,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
  memory_order __m = memory_order_seq_cst) noexcept
   {
return compare_exchange_strong(__i1, __i2, __m,
-  __calculate_memory_order(__m));
+  __cmpexch_failure_order(__m));
   }
 
   bool
@@ -552,7 +550,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 memory_order __m = memory_order_seq_cst) volatile noexcept
   {
return compare_exchange_strong(__i1, __i2, __m,
-  __calculate_memory_order(__m));
+  __cmpexch_failure_order(__m));
   }
 
   __int_type
Index: include/std/atomic
===
--- include/std/atomic  (revision 181967)
+++ include/std/atomic  (working copy)
@@ -408,7 +408,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
memory_order __m = memory_order_seq_cst) noexcept
   {
return compare_exchange_weak(__p1, __p2, __m,
-__calculate_memory_order(__m));
+__cmpexch_failure_order(__m));
   }
 
   bool
@@ -416,7 +416,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
memory_order __m = memory_order_seq_cst) volatile noexcept
   {
return compare_exchange_weak(__p1, __p2, __m,
-__calculate_memory_order(__m));
+__cmpexch_failure_order(__m));
   }
 
   bool
@@ -435,7 +435,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
  memory_order __m = memory_order_seq_cst) noexcept
   {
return _M_b.compare_exchange_strong(__p1, __p2, __m,
-   __calculate_memory_order(__m));
+   __cmpexch_failure_order(__m));
   }
 
   bool
@@ -443,7 +443,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
memory_order __m = memory_order_seq_cst) volatile noexcept
   {
return _M_b.compare_exchange_strong(__p1, __p2, __m,
-   __calculate_memory_order(__m));
+   __cmpexch_failure_order(__m));
   }
 
   __pointer_type

Re: PR libgomp/51376 fix

[Alan Modra]

On Fri, Dec 02, 2011 at 08:10:11PM +1030, Alan Modra wrote:
> On Thu, Dec 01, 2011 at 12:36:08PM +0100, Jakub Jelinek wrote:
> > On Thu, Dec 01, 2011 at 09:58:08PM +1030, Alan Modra wrote:
> > > The GOMP_task change fixes a similar potential problem.  Bootstrapped
> > > and regression tested powerpc-linux.  OK to apply?
> > > 
> > >   PR libgomp/51376
> > >   * task.c (GOMP_taskwait): Don't access task->children outside of
> > >   task_lock mutex region.
> > >   (GOMP_task): Likewise.
> > 
> > Can't this be solved just by adding a barrier?  The access to the var
> > outside of the lock has been quite intentional, to avoid locking in the
> > common case where there are no children.
> 
> No, I tried that and the task-6.C testcase still failed although not
> quite as readily.  I was using
> 
> if (task == NULL
> || __atomic_load_n (&task->children, MEMMODEL_ACQUIRE) == 0)
> 
> You need a release in the child as well as the acquire to ensure
> proper synchronisation, and there's a window for failure between the
> child clearing task->children and performing a release as part of the
> mutex unlock.

Perhaps I misunderstood your question.  I suppose you could solve the
problem by adding a barrier, if by that you meant the acquire barrier
in GOMP_taskwait as I tried before I fully understood the problem,
plus the corresponding release barrier in gomp_barrier_handle_tasks.
ie. replace
  parent->children = NULL;
with
  __atomic_write_n (&parent->children, NULL,
MEMMODEL_RELEASE);

That should work, but of course will slow down what I imagine is a
common multi-thread case where child threads don't complete before the
parent gets around to a taskwait.  Do you really want to do that?

-- 
Alan Modra
Australia Development Lab, IBM

Re: [C++ Patch] PR 51313

[Jason Merrill]

OK.

Jason

Re: [Patch] Increase array sizes in vect-tests to enable 256-bit vectorization

[Richard Guenther]

On Fri, Dec 2, 2011 at 6:39 PM, Michael Zolotukhin
 wrote:
>>
>> Shouldn't we add a variant for each testcase so that we still
>> excercise both 128-bit and 256-bit vectorization paths?
>
> These tests are still good to test 128-bit vectorization, the changes
> was made just to make sure that 256-bit vectorization is possible on
> the tests.
>
> Actually, It's just first step in enabling these tests for 256 bits -
> for now many of them are failing if '-mavx' or '-mavx2' is specified
> (mostly due to different diagnostics messages produced by vectorizer),
> but with original (small) sizes of arrays we couldn't even check that.
> When they are enabled, it'll be possible to use them for testing both
> 128- and 256- bit vectorization.

I mean, that, when 256-bit vectorization is enabled we still use 128bit
vectorization if the arrays are too short for 256bit vectorization.  You'll
lose this test coverage when you change the array sizes.

Richard.

> Michael
>
>
> 2011/12/2 Richard Guenther :
>> 2011/12/2 Michael Zolotukhin :
>>> Hi,
>>>
>>> This patch increases array sizes in tests from vect.exp suite, thus
>>> enabling 256-bit vectorization where it's available.
>>>
>>> Ok for trunk?
>>
>> Shouldn't we add a variant for each testcase so that we still
>> excercise both 128-bit and 256-bit vectorization paths?
>>
>>> Changelog:
>>> 2011-12-02  Michael Zolotukhin  
>>>
>>>        * gcc.dg/vect/slp-13.c: Increase array size, add initialization.
>>>        * gcc.dg/vect/slp-24.c: Ditto.
>>>        * gcc.dg/vect/slp-3.c: Likewise and fix scans.
>>>        * gcc.dg/vect/slp-34.c: Ditto.
>>>        * gcc.dg/vect/slp-4.c: Ditto.
>>>        * gcc.dg/vect/slp-cond-2.c: Ditto.
>>>        * gcc.dg/vect/slp-multitypes-11.c: Ditto.
>>>        * gcc.dg/vect/vect-1.c: Ditto.
>>>        * gcc.dg/vect/vect-10.c: Ditto.
>>>        * gcc.dg/vect/vect-105.c: Ditto.
>>>        * gcc.dg/vect/vect-112.c: Ditto.
>>>        * gcc.dg/vect/vect-15.c: Ditto.
>>>        * gcc.dg/vect/vect-2.c: Ditto.
>>>        * gcc.dg/vect/vect-31.c: Ditto.
>>>        * gcc.dg/vect/vect-32.c: Ditto.
>>>        * gcc.dg/vect/vect-33.c: Ditto.
>>>        * gcc.dg/vect/vect-34.c: Ditto.
>>>        * gcc.dg/vect/vect-35.c: Ditto.
>>>        * gcc.dg/vect/vect-36.c: Ditto.
>>>        * gcc.dg/vect/vect-6.c: Ditto.
>>>        * gcc.dg/vect/vect-73.c: Ditto.
>>>        * gcc.dg/vect/vect-74.c: Ditto.
>>>        * gcc.dg/vect/vect-75.c: Ditto.
>>>        * gcc.dg/vect/vect-76.c: Ditto.
>>>        * gcc.dg/vect/vect-80.c: Ditto.
>>>        * gcc.dg/vect/vect-85.c: Ditto.
>>>        * gcc.dg/vect/vect-89.c: Ditto.
>>>        * gcc.dg/vect/vect-97.c: Ditto.
>>>        * gcc.dg/vect/vect-98.c: Ditto.
>>>        * gcc.dg/vect/vect-all.c: Ditto.
>>>        * gcc.dg/vect/vect-double-reduc-6.c: Ditto.
>>>        * gcc.dg/vect/vect-iv-8.c: Ditto.
>>>        * gcc.dg/vect/vect-iv-8a.c: Ditto.
>>>        * gcc.dg/vect/vect-outer-1.c: Ditto.
>>>        * gcc.dg/vect/vect-outer-1a.c: Ditto.
>>>        * gcc.dg/vect/vect-outer-1b.c: Ditto.
>>>        * gcc.dg/vect/vect-outer-2.c: Ditto.
>>>        * gcc.dg/vect/vect-outer-2a.c: Ditto.
>>>        * gcc.dg/vect/vect-outer-2c.c: Ditto.
>>>        * gcc.dg/vect/vect-outer-3.c: Ditto.
>>>        * gcc.dg/vect/vect-outer-3a.c: Ditto.
>>>        * gcc.dg/vect/vect-outer-4a.c: Ditto.
>>>        * gcc.dg/vect/vect-outer-4b.c: Ditto.
>>>        * gcc.dg/vect/vect-outer-4c.c: Ditto.
>>>        * gcc.dg/vect/vect-outer-4d.c: Ditto.
>>>        * gcc.dg/vect/vect-outer-4m.c: Ditto.
>>>        * gcc.dg/vect/vect-outer-fir-lb.c: Ditto.
>>>        * gcc.dg/vect/vect-outer-fir.c: Ditto.
>>>        * gcc.dg/vect/vect-over-widen-1.c: Ditto.
>>>        * gcc.dg/vect/vect-over-widen-2.c: Ditto.
>>>        * gcc.dg/vect/vect-over-widen-3.c: Ditto.
>>>        * gcc.dg/vect/vect-over-widen-4.c: Ditto.
>>>        * gcc.dg/vect/vect-reduc-1char.c: Ditto.
>>>        * gcc.dg/vect/vect-reduc-2char.c: Ditto.
>>>        * gcc.dg/vect/vect-reduc-pattern-1b.c: Ditto.
>>>        * gcc.dg/vect/vect-reduc-pattern-1c.c: Ditto.
>>>        * gcc.dg/vect/vect-reduc-pattern-2b.c: Ditto.
>>>        * gcc.dg/vect/vect-shift-2.c: Ditto.
>>>        * gcc.dg/vect/vect-strided-a-u8-i8-gap2.c: Ditto.
>>>        * gcc.dg/vect/vect-strided-a-u8-i8-gap7.c: Ditto.
>>>        * gcc.dg/vect/vect-strided-u8-i8-gap2.c: Ditto.
>>>        * gcc.dg/vect/vect-strided-u8-i8-gap4.c: Ditto.
>>>        * gcc.dg/vect/vect-strided-u8-i8-gap7.c: Ditto.
>>>
>>> --
>>> ---
>>> Best regards,
>>> Michael V. Zolotukhin,
>>> Software Engineer
>>> Intel Corporation.

[Patch, Fortran] PR 48887 [4.7] Don't mark SELECT TYPE selector as allocatable/pointer

[Tobias Burnus]

gfortran wrongly marks the selector of a SELECT TYPE as having the 
pointer or allocatable attribute. Result: No error if one tries to 
change the allocation status.


"If the selector is allocatable, it shall be allocated; the associate 
name is associated with the data object and does not have the 
ALLOCATABLE attribute." (F2008).


Build and regtested on x86-64-linux.
OK for the trunk?

Tobias

2011-12-03  Tobias Burnus  

	PR fortran/48887
	* match.c (select_type_set_tmp): Don't set allocatable/pointer
	attribute.
	* class.c (gfc_build_class_symbol): Handle
	attr.select_type_temporary.

2011-12-03  Tobias Burnus  

	PR fortran/48887
	* gfortran.dg/select_type_24.f90: New.
	* gfortran.dg/select_type_23.f03: Add dg-error.
	* gfortran.dg/class_45a.f03: Add missing TARGET attribute.

Index: gcc/fortran/match.c
===
--- gcc/fortran/match.c	(Revision 181967)
+++ gcc/fortran/match.c	(Arbeitskopie)
@@ -5152,16 +5152,11 @@ select_type_set_tmp (gfc_typespec *ts)
   gfc_get_sym_tree (name, gfc_current_ns, &tmp, false);
   gfc_add_type (tmp->n.sym, ts, NULL);
   gfc_set_sym_referenced (tmp->n.sym);
-  if (select_type_stack->selector->ts.type == BT_CLASS &&
-  CLASS_DATA (select_type_stack->selector)->attr.allocatable)
-gfc_add_allocatable (&tmp->n.sym->attr, NULL);
-  else
-gfc_add_pointer (&tmp->n.sym->attr, NULL);
   gfc_add_flavor (&tmp->n.sym->attr, FL_VARIABLE, name, NULL);
+  tmp->n.sym->attr.select_type_temporary = 1;
   if (ts->type == BT_CLASS)
 gfc_build_class_symbol (&tmp->n.sym->ts, &tmp->n.sym->attr,
 			&tmp->n.sym->as, false);
-  tmp->n.sym->attr.select_type_temporary = 1;
 
   /* Add an association for it, so the rest of the parser knows it is
  an associate-name.  The target will be set during resolution.  */
Index: gcc/fortran/class.c
===
--- gcc/fortran/class.c	(Revision 181967)
+++ gcc/fortran/class.c	(Arbeitskopie)
@@ -188,7 +188,8 @@ gfc_build_class_symbol (gfc_typespec *ts, symbol_a
 /* Class container has already been built.  */
 return SUCCESS;
 
-  attr->class_ok = attr->dummy || attr->pointer || attr->allocatable;
+  attr->class_ok = attr->dummy || attr->pointer || attr->allocatable
+		   || attr.select_type_temporary;
   
   if (!attr->class_ok)
 /* We can not build the class container yet.  */
@@ -239,7 +240,8 @@ gfc_build_class_symbol (gfc_typespec *ts, symbol_a
   c->attr.access = ACCESS_PRIVATE;
   c->ts.u.derived = ts->u.derived;
   c->attr.class_pointer = attr->pointer;
-  c->attr.pointer = attr->pointer || attr->dummy;
+  c->attr.pointer = attr->pointer || attr->dummy
+			|| attr.select_type_temporary;
   c->attr.allocatable = attr->allocatable;
   c->attr.dimension = attr->dimension;
   c->attr.codimension = attr->codimension;
Index: gcc/testsuite/gfortran.dg/select_type_24.f90
===
--- gcc/testsuite/gfortran.dg/select_type_24.f90	(Revision 0)
+++ gcc/testsuite/gfortran.dg/select_type_24.f90	(Arbeitskopie)
@@ -0,0 +1,50 @@
+! { dg-do compile }
+!
+! PR fortran/48887
+!
+! "If the selector is allocatable, it shall be allocated; the
+!  associate name is associated with the data object and does
+!  not have the ALLOCATABLE attribute."
+!
+module m
+  type t
+  end type t
+contains
+  subroutine one(a)
+class(t), allocatable :: a
+class(t), allocatable :: b
+allocate (b)
+select type (b)
+  type is(t)
+call move_alloc (b, a) ! { dg-error "must be ALLOCATABLE" }
+end select
+  end subroutine one
+
+  subroutine two (a)
+class(t), allocatable :: a
+type(t), allocatable :: b
+allocate (b)
+associate (c => b)
+  call move_alloc (b, c) ! { dg-error "must be ALLOCATABLE" }
+end associate
+  end subroutine two
+end module m
+
+type t
+end type t
+class(t), allocatable :: x
+
+select type(x)
+  type is(t)
+print *, allocated (x) ! { dg-error "must be ALLOCATABLE" }
+end select
+
+select type(y=>x)
+  type is(t)
+print *, allocated (y)  ! { dg-error "must be ALLOCATABLE" }
+end select
+
+associate (y=>x)
+  print *, allocated (y)  ! { dg-error "must be ALLOCATABLE" }
+end associate
+end
Index: gcc/testsuite/gfortran.dg/select_type_23.f03
===
--- gcc/testsuite/gfortran.dg/select_type_23.f03	(Revision 181967)
+++ gcc/testsuite/gfortran.dg/select_type_23.f03	(Arbeitskopie)
@@ -3,6 +3,8 @@
 ! PR 48699: [OOP] MOVE_ALLOC inside SELECT TYPE
 !
 ! Contributed by Salvatore Filippone 
+!
+! Updated for PR fortran/48887
 
 program testmv2
 
@@ -16,7 +18,7 @@ program testmv2
 
   select type(sm2) 
   type is (bar)
-call move_alloc(sm2,sm)
+call move_alloc(sm2,sm) ! { dg-error "must be ALLOCATABLE" }
   end select
 
 end program testmv2
Index: gcc/testsuite/gfortran.dg/class_45a.f03
==

Re: [PATCH] Fold constant argument VEC_{PACK_{,FIX_}TRUNC,{UNPACK{,_FLOAT},WIDEN_MULT}_{LO,HI}}_EXPR

[Richard Guenther]

On Fri, Dec 2, 2011 at 8:26 PM, Jakub Jelinek  wrote:
> Hi!
>
> As I found during investigation of PR51387, e.g. on the attached testcase
> we generate pretty bad code (for f1 even with bigger N like 256 for avx2),
> because after vectorization cunroll unrolls the loops completely and we
> end up with lots of VEC_PACK_TRUNC_EXPR etc. expressions with VECTOR_CST
> arguments.  We don't fold them, thus we read lots of constants from memory
> and reshuffle them in lots of code.  This patch adds folding for these
> expressions, we end up on this testcase with the same amount of loaded
> constants from memory, but no need to reshuffle it.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

Ok.

Thanks,
Richard.

> 2011-12-02  Jakub Jelinek  
>
>        * fold-const.c (fold_unary_loc): Fold VEC_UNPACK_LO_EXPR,
>        VEC_UNPACK_HI_EXPR, VEC_UNPACK_FLOAT_LO_EXPR and
>        VEC_UNPACK_FLOAT_HI_EXPR with VECTOR_CST argument.
>        (fold_binary_loc): Fold VEC_PACK_TRUNC_EXPR,
>        VEC_PACK_FIX_TRUNC_EXPR, VEC_WIDEN_MULT_LO_EXPR
>        and VEC_WIDEN_MULT_HI_EXPR with VECTOR_CST arguments.
>
>        * gcc.dg/vect/vect-122.c: New test.
>
> --- gcc/fold-const.c.jj 2011-12-02 01:52:26.0 +0100
> +++ gcc/fold-const.c    2011-12-02 17:43:09.246557524 +0100
> @@ -7651,6 +7651,8 @@ build_fold_addr_expr_loc (location_t loc
>   return build_fold_addr_expr_with_type_loc (loc, t, ptrtype);
>  }
>
> +static bool vec_cst_ctor_to_array (tree, tree *);
> +
>  /* Fold a unary expression of code CODE and type TYPE with operand
>    OP0.  Return the folded expression if folding is successful.
>    Otherwise, return NULL_TREE.  */
> @@ -8294,6 +8296,44 @@ fold_unary_loc (location_t loc, enum tre
>        }
>       return NULL_TREE;
>
> +    case VEC_UNPACK_LO_EXPR:
> +    case VEC_UNPACK_HI_EXPR:
> +    case VEC_UNPACK_FLOAT_LO_EXPR:
> +    case VEC_UNPACK_FLOAT_HI_EXPR:
> +      {
> +       unsigned int nelts = TYPE_VECTOR_SUBPARTS (type), i;
> +       tree *elts, vals = NULL_TREE;
> +       enum tree_code subcode;
> +
> +       gcc_assert (TYPE_VECTOR_SUBPARTS (TREE_TYPE (arg0)) == nelts * 2);
> +       if (TREE_CODE (arg0) != VECTOR_CST)
> +         return NULL_TREE;
> +
> +       elts = XALLOCAVEC (tree, nelts * 2);
> +       if (!vec_cst_ctor_to_array (arg0, elts))
> +         return NULL_TREE;
> +
> +       if ((!BYTES_BIG_ENDIAN) ^ (code == VEC_UNPACK_LO_EXPR
> +                                  || code == VEC_UNPACK_FLOAT_LO_EXPR))
> +         elts += nelts;
> +
> +       if (code == VEC_UNPACK_LO_EXPR || code == VEC_UNPACK_HI_EXPR)
> +         subcode = NOP_EXPR;
> +       else
> +         subcode = FLOAT_EXPR;
> +
> +       for (i = 0; i < nelts; i++)
> +         {
> +           elts[i] = fold_convert_const (subcode, TREE_TYPE (type), elts[i]);
> +           if (elts[i] == NULL_TREE || !CONSTANT_CLASS_P (elts[i]))
> +             return NULL_TREE;
> +         }
> +
> +       for (i = 0; i < nelts; i++)
> +         vals = tree_cons (NULL_TREE, elts[nelts - i - 1], vals);
> +       return build_vector (type, vals);
> +      }
> +
>     default:
>       return NULL_TREE;
>     } /* switch (code) */
> @@ -13498,6 +13538,73 @@ fold_binary_loc (location_t loc,
>        }
>       return NULL_TREE;
>
> +    case VEC_PACK_TRUNC_EXPR:
> +    case VEC_PACK_FIX_TRUNC_EXPR:
> +      {
> +       unsigned int nelts = TYPE_VECTOR_SUBPARTS (type), i;
> +       tree *elts, vals = NULL_TREE;
> +
> +       gcc_assert (TYPE_VECTOR_SUBPARTS (TREE_TYPE (arg0)) == nelts / 2
> +                   && TYPE_VECTOR_SUBPARTS (TREE_TYPE (arg1)) == nelts / 2);
> +       if (TREE_CODE (arg0) != VECTOR_CST || TREE_CODE (arg1) != VECTOR_CST)
> +         return NULL_TREE;
> +
> +       elts = XALLOCAVEC (tree, nelts);
> +       if (!vec_cst_ctor_to_array (arg0, elts)
> +           || !vec_cst_ctor_to_array (arg1, elts + nelts / 2))
> +         return NULL_TREE;
> +
> +       for (i = 0; i < nelts; i++)
> +         {
> +           elts[i] = fold_convert_const (code == VEC_PACK_TRUNC_EXPR
> +                                         ? NOP_EXPR : FIX_TRUNC_EXPR,
> +                                         TREE_TYPE (type), elts[i]);
> +           if (elts[i] == NULL_TREE || !CONSTANT_CLASS_P (elts[i]))
> +             return NULL_TREE;
> +         }
> +
> +       for (i = 0; i < nelts; i++)
> +         vals = tree_cons (NULL_TREE, elts[nelts - i - 1], vals);
> +       return build_vector (type, vals);
> +      }
> +
> +    case VEC_WIDEN_MULT_LO_EXPR:
> +    case VEC_WIDEN_MULT_HI_EXPR:
> +      {
> +       unsigned int nelts = TYPE_VECTOR_SUBPARTS (type), i;
> +       tree *elts, vals = NULL_TREE;
> +
> +       gcc_assert (TYPE_VECTOR_SUBPARTS (TREE_TYPE (arg0)) == nelts * 2
> +                   && TYPE_VECTOR_SUBPARTS (TREE_TYPE (arg1)) == nelts * 2);
> +       if (TREE_CODE (arg0) != VECTOR_CST || TREE_CODE (arg1) != VECTOR_CST)
> +         return NULL_TREE;
> +
> +       elts = XALLOCAVEC (tree, nelts * 4);
> +       if

Re: [PATCH] Improve debug info if tree DCE removes stores (PR debug/50317, fallout)

[Richard Guenther]

On Fri, Dec 2, 2011 at 8:28 PM, Jakub Jelinek  wrote:
> On Fri, Dec 02, 2011 at 02:27:40PM +0100, Richard Guenther wrote:
>> This change seems wrong.  We are turning valid gimple
>>
>> # DEBUG D#2 => transfer.0  [with addres taken]
>>
>> into invalid one
>>
>> # DEBUG D#2 => transfer.0  [without address taken]
>>
>> once you update that stmt with update_stmt you'll get an SSA operand
>> for transfer.0 which is not in SSA form because you fail to rewrite it
>> into.
>>
>> Why do this in remove_unused_locals and not in update_address_taken?
>> Or, why do it at all?
>>
>> I have a SSA operand checking patch that catches this now ...
>
> Here is a fix for that.  Instead of clearing TREE_ADDRESSABLE for
> unreferenced vars we allow them in target_for_debug_bind if they aren't
> referenced vars (thus we don't risk mixing VALUE tracking with the
> old style REG_EXPR/MEM_EXPR tracking of these variables).
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

Ok.  (Note that the outcome of target_for_debug_bind may change during
compilation, but only from false to true as far as I can see, so that
should be ok)

Thanks,
Richard.

> 2011-12-02  Jakub Jelinek  
>
>        PR debug/50317
>        * tree-ssa.c (target_for_debug_bind): Also allow is_gimple_reg_type
>        vars that aren't referenced.
>        (tree-ssa-live.c (remove_unused_locals): Don't clear TREE_ADDRESSABLE
>        of unreferenced local vars.
>        * cfgexpand.c (expand_debug_expr): For DEBUG_IMPLICIT_PTR allow also
>        TREE_ADDRESSABLE vars that satisfy target_for_debug_bind.
>
> --- gcc/tree-ssa.c.jj   2011-11-29 08:58:52.0 +0100
> +++ gcc/tree-ssa.c      2011-12-02 15:04:03.494148642 +0100
> @@ -264,7 +264,12 @@ target_for_debug_bind (tree var)
>     return NULL_TREE;
>
>   if (!is_gimple_reg (var))
> -    return NULL_TREE;
> +    {
> +      if (is_gimple_reg_type (TREE_TYPE (var))
> +         && referenced_var_lookup (cfun, DECL_UID (var)) == NULL_TREE)
> +       return var;
> +      return NULL_TREE;
> +    }
>
>   return var;
>  }
> --- gcc/tree-ssa-live.c.jj      2011-12-02 01:52:27.0 +0100
> +++ gcc/tree-ssa-live.c 2011-12-02 15:04:59.601816335 +0100
> @@ -814,15 +814,7 @@ remove_unused_locals (void)
>              bitmap_set_bit (global_unused_vars, DECL_UID (var));
>            }
>          else
> -           {
> -             /* For unreferenced local vars drop TREE_ADDRESSABLE
> -                bit in case it is referenced from debug stmts.  */
> -             if (DECL_CONTEXT (var) == current_function_decl
> -                 && TREE_ADDRESSABLE (var)
> -                 && is_gimple_reg_type (TREE_TYPE (var)))
> -               TREE_ADDRESSABLE (var) = 0;
> -             continue;
> -           }
> +           continue;
>        }
>       else if (TREE_CODE (var) == VAR_DECL
>               && DECL_HARD_REGISTER (var)
> --- gcc/cfgexpand.c.jj  2011-12-02 01:52:27.0 +0100
> +++ gcc/cfgexpand.c     2011-12-02 15:24:37.982327507 +0100
> @@ -3325,7 +3325,8 @@ expand_debug_expr (tree exp)
>          if ((TREE_CODE (TREE_OPERAND (exp, 0)) == VAR_DECL
>               || TREE_CODE (TREE_OPERAND (exp, 0)) == PARM_DECL
>               || TREE_CODE (TREE_OPERAND (exp, 0)) == RESULT_DECL)
> -             && !TREE_ADDRESSABLE (TREE_OPERAND (exp, 0)))
> +             && (!TREE_ADDRESSABLE (TREE_OPERAND (exp, 0))
> +                 || target_for_debug_bind (TREE_OPERAND (exp, 0
>            return gen_rtx_DEBUG_IMPLICIT_PTR (mode, TREE_OPERAND (exp, 0));
>
>          if (handled_component_p (TREE_OPERAND (exp, 0)))
> @@ -3337,7 +3338,8 @@ expand_debug_expr (tree exp)
>              if ((TREE_CODE (decl) == VAR_DECL
>                   || TREE_CODE (decl) == PARM_DECL
>                   || TREE_CODE (decl) == RESULT_DECL)
> -                 && !TREE_ADDRESSABLE (decl)
> +                 && (!TREE_ADDRESSABLE (decl)
> +                     || target_for_debug_bind (decl))
>                  && (bitoffset % BITS_PER_UNIT) == 0
>                  && bitsize > 0
>                  && bitsize == maxsize)
>
>
>        Jakub

[PATCH] pass -no_pie to LINK_GCC_C_SEQUENCE_SPEC on darwin

[Jack Howarth]

   FSF gcc currently doesn't handle -fno-pie and friends properly under Lion.
The darwin11 linker now defaults to -pie and must be explicitly passed -no_pie
in such cases. The following patch extends LINK_GCC_C_SEQUENCE_SPEC to handle
those instances which should pass -no_pie to the linker. The 
gcc.dg/darwin-segaddr.c
testcase is also fixed by explicitly passing -fno-pie on dg-options since the 
test
is meaningless for PIE. These patches also eliminate the excessive error 
failure 
currently since in gcc.dg/20020312-2.c as -fno-pic will now pass -no_pie to the
linker which eliminates the linker warning...

ld: warning: PIE disabled. Absolute addressing (perhaps -mdynamic-no-pic) not 
allowed in code signed PIE, but used in _f from /var/tmp//ccVNy9V9.o. To fix 
this warning, don't compile with -mdynamic-no-pic or link with -Wl,-no_pie

Bootstrap and regression tested on x86_64-apple-darwin11. 

http://gcc.gnu.org/ml/gcc-testresults/2011-12/msg00287.html

Okay for gcc trunk and backports to gcc-4_5-branch/gcc-4_6-branch?
Jack
Note that when -mmacosx-version-min=10.6 is used under Lion, the linker doesn't 
default
to -pie so only the case of targeting 10.7 or later has to be considered.

gcc/

2011-12-03  Jack Howarth 

* gcc/config/darwin10.h (LINK_GCC_C_SEQUENCE_SPEC):
  Pass -no_pie for non-PIC code when targeting 10.7 or later.

gcc/testsuite/

2011-12-03  Jack Howarth 

* gcc.dg/darwin-segaddr.c: Use -no-pie.

Index: gcc/testsuite/gcc.dg/darwin-segaddr.c
===
--- gcc/testsuite/gcc.dg/darwin-segaddr.c   (revision 181953)
+++ gcc/testsuite/gcc.dg/darwin-segaddr.c   (working copy)
@@ -1,7 +1,7 @@
 /* Check that -segaddr gets through and works.  */
 /* { dg-do run { target *-*-darwin* } } */
-/* { dg-options "-O0 -segaddr __TEST 0x20" { target { *-*-darwin* && { ! 
lp64 } } } } */
-/* { dg-options "-O0 -segaddr __TEST 0x11000" { target { *-*-darwin* && 
lp64 } } } */
+/* { dg-options "-O0 -segaddr __TEST 0x20 -fno-pie" { target { *-*-darwin* 
&& { ! lp64 } } } } */
+/* { dg-options "-O0 -segaddr __TEST 0x11000 -fno-pie" { target { 
*-*-darwin* && lp64 } } } */
 
 extern void abort ();
 
Index: gcc/config/darwin10.h
===
--- gcc/config/darwin10.h   (revision 181953)
+++ gcc/config/darwin10.h   (working copy)
@@ -26,7 +26,9 @@ along with GCC; see the file COPYING3.  
 #define LINK_GCC_C_SEQUENCE_SPEC \
 "%:version-compare(>= 10.6 mmacosx-version-min= -no_compact_unwind) \
%{!static:%{!static-libgcc: \
-  %:version-compare(>= 10.6 mmacosx-version-min= -lSystem) } } %G %L"
+  %:version-compare(>= 10.6 mmacosx-version-min= -lSystem) } } \
+   
%{fno-pic|fno-PIC|fno-pie|fno-PIE|fapple-kext|mkernel|static|mdynamic-no-pic: \
+  %:version-compare(>= 10.7 mmacosx-version-min= -no_pie) } %G %L"
 
 #undef DEF_MIN_OSX_VERSION
 #define DEF_MIN_OSX_VERSION "10.6"

Re: empty range in pop_heap

[Jonathan Wakely]

On 12 November 2011 15:14, Jonathan Wakely wrote:
> On 12 November 2011 15:04, Marc Glisse wrote:
>>
>> Debug-mode seems to check that first,last is a valid range, is a heap, but
>> not that it is not empty. Maybe it could?
>
> Good idea, thanks.  I'll change that.

As promised.

* include/debug/macros.h (__glibcxx_check_non_empty_range): Define.
* include/debug/debug.h (__glibcxx_requires_non_empty_range): Define.
* include/debug/formatter.h (__msg_non_empty_range): Add.
* src/debug.cc: Message text for __msg_non_empty_range.
* include/bits/stl_heap.h (pop_heap): Check for non-empty range.
* testsuite/25_algorithms/pop_heap/empty_neg.cc: New.

Tested x86_64-linux, committed to trunk.
Index: include/debug/macros.h
===
--- include/debug/macros.h  (revision 181967)
+++ include/debug/macros.h  (working copy)
@@ -57,6 +57,13 @@ _GLIBCXX_DEBUG_VERIFY(__gnu_debug::__val
  ._M_iterator(_First, #_First) \
  ._M_iterator(_Last, #_Last))
 
+// Verify that [_First, _Last) forms a non-empty iterator range.
+#define __glibcxx_check_non_empty_range(_First,_Last)  \
+_GLIBCXX_DEBUG_VERIFY(_First != _Last, \
+ _M_message(__gnu_debug::__msg_non_empty_range)\
+ ._M_iterator(_First, #_First) \
+ ._M_iterator(_Last, #_Last))
+
 /** Verify that we can insert into *this with the iterator _Position.
  *  Insertion into a container at a specific position requires that
  *  the iterator be nonsingular, either dereferenceable or past-the-end,
Index: include/debug/debug.h
===
--- include/debug/debug.h   (revision 181967)
+++ include/debug/debug.h   (working copy)
@@ -1,6 +1,6 @@
 // Debugging support implementation -*- C++ -*-
 
-// Copyright (C) 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010
+// Copyright (C) 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011
 // Free Software Foundation, Inc.
 //
 // This file is part of the GNU ISO C++ Library.  This library is free
@@ -64,6 +64,7 @@ namespace __gnu_debug
 # define _GLIBCXX_DEBUG_ONLY(_Statement) ;
 # define __glibcxx_requires_cond(_Cond,_Msg)
 # define __glibcxx_requires_valid_range(_First,_Last)
+# define __glibcxx_requires_non_empty_range(_First,_Last)
 # define __glibcxx_requires_sorted(_First,_Last)
 # define __glibcxx_requires_sorted_pred(_First,_Last,_Pred)
 # define __glibcxx_requires_sorted_set(_First1,_Last1,_First2)
@@ -96,6 +97,8 @@ namespace __gnu_debug
 # define __glibcxx_requires_cond(_Cond,_Msg) _GLIBCXX_DEBUG_VERIFY(_Cond,_Msg)
 # define __glibcxx_requires_valid_range(_First,_Last) \
  __glibcxx_check_valid_range(_First,_Last)
+# define __glibcxx_requires_non_empty_range(_First,_Last) \
+ __glibcxx_check_non_empty_range(_First,_Last)
 # define __glibcxx_requires_sorted(_First,_Last) \
  __glibcxx_check_sorted(_First,_Last)
 # define __glibcxx_requires_sorted_pred(_First,_Last,_Pred) \
Index: include/debug/formatter.h
===
--- include/debug/formatter.h   (revision 181967)
+++ include/debug/formatter.h   (working copy)
@@ -108,7 +108,8 @@ namespace __gnu_debug
 __msg_erase_after_bad,
 __msg_valid_range2,
 // unordered sequence local iterators
-__msg_local_iter_compare_bad
+__msg_local_iter_compare_bad,
+__msg_non_empty_range
   };
 
   class _Error_formatter
Index: src/debug.cc
===
--- src/debug.cc(revision 181967)
+++ src/debug.cc(working copy)
@@ -176,7 +176,8 @@ namespace __gnu_debug
 ", \"%2.name;\" shall be before and not equal to \"%3.name;\"",
 // std::unordered_container::local_iterator
 "attempt to compare local iterators from different unordered container"
-" buckets"
+" buckets",
+"function requires a non-empty iterator range [%1.name;, %2.name;)"
   };
 
   void
Index: include/bits/stl_heap.h
===
--- include/bits/stl_heap.h (revision 181967)
+++ include/bits/stl_heap.h (working copy)
@@ -1,7 +1,7 @@
 // Heap implementation -*- C++ -*-
 
-// Copyright (C) 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010
-// Free Software Foundation, Inc.
+// Copyright (C) 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010,
+// 2011 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
@@ -270,6 +270,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
*  @brief  Pop an element off a heap.
*  @param  __first  Start of heap.
*  @param  __last   End of heap.
+   *  @pre[__first, __last) is a

Re: Implement C1X _Alignas, _Alignof, max_align_t, stdalign.h

[Jonathan Wakely]

patch ping ...

On 7 November 2011 09:58, Jonathan Wakely wrote:
>
> And then this adjusts  and  for C++11 conformance.
>
> C++11 requires stdbool.h so providing it is not a GCC extension, but
> defining _Bool is. I don't see the point of defining bool, true and
> false as macros in C++ and it's explicitly forbidden by C++11.
> Personally I'd prefer if _Bool was a typedef rather than a macro, but
> I haven't changed that.
>
>
> gcc/ChangeLog:
>        * ginclude/stdalign.h (__alignas_is_defined, __alignof_is_defined):
>        Define for C++.
>        * ginclude/stdbool.h (bool, true, false): Do not define for C++.
>
> libstdc++-v3/ChangeLog:
>        * testsuite/18_support/headers/cstdalign/macros.cc: New.
>        * testsuite/18_support/headers/cstdbool/macros.cc: New.
>
>
> Tested x86_64-linux, OK for trunk?
Index: gcc/ginclude/stdalign.h
===
--- gcc/ginclude/stdalign.h	(revision 181077)
+++ gcc/ginclude/stdalign.h	(working copy)
@@ -31,9 +31,9 @@
 #define alignas _Alignas
 #define alignof _Alignof
 
+#endif
+
 #define __alignas_is_defined 1
 #define __alignof_is_defined 1
 
-#endif
-
 #endif	/* stdalign.h */
Index: gcc/ginclude/stdbool.h
===
--- gcc/ginclude/stdbool.h	(revision 181077)
+++ gcc/ginclude/stdbool.h	(working copy)
@@ -1,4 +1,4 @@
-/* Copyright (C) 1998, 1999, 2000, 2009 Free Software Foundation, Inc.
+/* Copyright (C) 1998, 1999, 2000, 2009, 2011 Free Software Foundation, Inc.
 
 This file is part of GCC.
 
@@ -36,11 +36,8 @@
 
 #else /* __cplusplus */
 
-/* Supporting  in C++ is a GCC extension.  */
+/* Supporting _Bool in C++ is a GCC extension.  */
 #define _Bool	bool
-#define bool	bool
-#define false	false
-#define true	true
 
 #endif /* __cplusplus */
 
Index: libstdc++-v3/testsuite/18_support/headers/cstdalign/macros.cc
===
--- libstdc++-v3/testsuite/18_support/headers/cstdalign/macros.cc	(revision 0)
+++ libstdc++-v3/testsuite/18_support/headers/cstdalign/macros.cc	(revision 0)
@@ -0,0 +1,30 @@
+// { dg-do compile }
+// { dg-options "-std=gnu++11" }
+
+// Copyright (C) 2011 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library.  This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+// GNU General Public License for more details.
+
+// You should have received a copy of the GNU General Public License along
+// with this library; see the file COPYING3.  If not see
+// .
+
+#include 
+
+#ifdef alignas
+# error "The header  defines a macro named alignas"
+#endif
+
+#ifndef __alignas_is_defined
+# error "The header  fails to define a macro named __alignas_is_defined"
+#endif
+
Index: libstdc++-v3/testsuite/18_support/headers/cstdbool/macros.cc
===
--- libstdc++-v3/testsuite/18_support/headers/cstdbool/macros.cc	(revision 0)
+++ libstdc++-v3/testsuite/18_support/headers/cstdbool/macros.cc	(revision 0)
@@ -0,0 +1,38 @@
+// { dg-do compile }
+// { dg-options "-std=gnu++11" }
+
+// Copyright (C) 2011 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library.  This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+// GNU General Public License for more details.
+
+// You should have received a copy of the GNU General Public License along
+// with this library; see the file COPYING3.  If not see
+// .
+
+#include 
+
+#ifndef __bool_true_false_are_defined
+# error "The header  fails to define a macro named __bool_true_false_are_defined"
+#endif
+
+#ifdef bool
+# error "The header  defines a macro named bool"
+#endif
+
+#ifdef true
+# error "The header  defines a macro named true"
+#endif
+
+#ifdef false
+# error "The header  defines a macro named false"
+#endif
+

Re: [RFC] Port libitm to powerpc

[Mike Stump]

Once you want to check it in, consider any Darwin aspects pre-approved.

[patch] fix typo in gcc/java/expr.c

[Matthias Klose]

fix typo in message, committed as obvious.

  Matthias

2011-12-03  Matthias Klose  

* expr.c (SPECIAL_WIDE): Fix typo in message.

Index: gcc/java/expr.c
===
--- gcc/java/expr.c (revision 181969)
+++ gcc/java/expr.c (working copy)
@@ -3546,7 +3546,7 @@
  break; \
} \
   default: \
-error ("unrecogized wide sub-instruction"); \
+error ("unrecognized wide sub-instruction"); \
   } \
   }
 

Re: [Patch] Increase array sizes in vect-tests to enable 256-bit vectorization

[Michael Zolotukhin]

> I mean, that, when 256-bit vectorization is enabled we still use 128bit
> vectorization if the arrays are too short for 256bit vectorization.  You'll
> lose this test coverage when you change the array sizes.
That's true, but do we need all these test both with short and long
arrays? We could have the tests with increased sizes and compile them
with/without use of avx, thus testing both 256- and 128- bit
vectorization. Additionally, we might want to add several tests with
short arrays to check what happens if 256-bit is available, but arrays
is too short for it. I mean we don't need to duplicate all of the
tests to check this situation.

On 3 December 2011 18:31, Richard Guenther  wrote:
> On Fri, Dec 2, 2011 at 6:39 PM, Michael Zolotukhin
>  wrote:
>>>
>>> Shouldn't we add a variant for each testcase so that we still
>>> excercise both 128-bit and 256-bit vectorization paths?
>>
>> These tests are still good to test 128-bit vectorization, the changes
>> was made just to make sure that 256-bit vectorization is possible on
>> the tests.
>>
>> Actually, It's just first step in enabling these tests for 256 bits -
>> for now many of them are failing if '-mavx' or '-mavx2' is specified
>> (mostly due to different diagnostics messages produced by vectorizer),
>> but with original (small) sizes of arrays we couldn't even check that.
>> When they are enabled, it'll be possible to use them for testing both
>> 128- and 256- bit vectorization.
>
> I mean, that, when 256-bit vectorization is enabled we still use 128bit
> vectorization if the arrays are too short for 256bit vectorization.  You'll
> lose this test coverage when you change the array sizes.
>
> Richard.
>
>> Michael
>>
>>
>> 2011/12/2 Richard Guenther :
>>> 2011/12/2 Michael Zolotukhin :
 Hi,

 This patch increases array sizes in tests from vect.exp suite, thus
 enabling 256-bit vectorization where it's available.

 Ok for trunk?
>>>
>>> Shouldn't we add a variant for each testcase so that we still
>>> excercise both 128-bit and 256-bit vectorization paths?
>>>
 Changelog:
 2011-12-02  Michael Zolotukhin  

        * gcc.dg/vect/slp-13.c: Increase array size, add initialization.
        * gcc.dg/vect/slp-24.c: Ditto.
        * gcc.dg/vect/slp-3.c: Likewise and fix scans.
        * gcc.dg/vect/slp-34.c: Ditto.
        * gcc.dg/vect/slp-4.c: Ditto.
        * gcc.dg/vect/slp-cond-2.c: Ditto.
        * gcc.dg/vect/slp-multitypes-11.c: Ditto.
        * gcc.dg/vect/vect-1.c: Ditto.
        * gcc.dg/vect/vect-10.c: Ditto.
        * gcc.dg/vect/vect-105.c: Ditto.
        * gcc.dg/vect/vect-112.c: Ditto.
        * gcc.dg/vect/vect-15.c: Ditto.
        * gcc.dg/vect/vect-2.c: Ditto.
        * gcc.dg/vect/vect-31.c: Ditto.
        * gcc.dg/vect/vect-32.c: Ditto.
        * gcc.dg/vect/vect-33.c: Ditto.
        * gcc.dg/vect/vect-34.c: Ditto.
        * gcc.dg/vect/vect-35.c: Ditto.
        * gcc.dg/vect/vect-36.c: Ditto.
        * gcc.dg/vect/vect-6.c: Ditto.
        * gcc.dg/vect/vect-73.c: Ditto.
        * gcc.dg/vect/vect-74.c: Ditto.
        * gcc.dg/vect/vect-75.c: Ditto.
        * gcc.dg/vect/vect-76.c: Ditto.
        * gcc.dg/vect/vect-80.c: Ditto.
        * gcc.dg/vect/vect-85.c: Ditto.
        * gcc.dg/vect/vect-89.c: Ditto.
        * gcc.dg/vect/vect-97.c: Ditto.
        * gcc.dg/vect/vect-98.c: Ditto.
        * gcc.dg/vect/vect-all.c: Ditto.
        * gcc.dg/vect/vect-double-reduc-6.c: Ditto.
        * gcc.dg/vect/vect-iv-8.c: Ditto.
        * gcc.dg/vect/vect-iv-8a.c: Ditto.
        * gcc.dg/vect/vect-outer-1.c: Ditto.
        * gcc.dg/vect/vect-outer-1a.c: Ditto.
        * gcc.dg/vect/vect-outer-1b.c: Ditto.
        * gcc.dg/vect/vect-outer-2.c: Ditto.
        * gcc.dg/vect/vect-outer-2a.c: Ditto.
        * gcc.dg/vect/vect-outer-2c.c: Ditto.
        * gcc.dg/vect/vect-outer-3.c: Ditto.
        * gcc.dg/vect/vect-outer-3a.c: Ditto.
        * gcc.dg/vect/vect-outer-4a.c: Ditto.
        * gcc.dg/vect/vect-outer-4b.c: Ditto.
        * gcc.dg/vect/vect-outer-4c.c: Ditto.
        * gcc.dg/vect/vect-outer-4d.c: Ditto.
        * gcc.dg/vect/vect-outer-4m.c: Ditto.
        * gcc.dg/vect/vect-outer-fir-lb.c: Ditto.
        * gcc.dg/vect/vect-outer-fir.c: Ditto.
        * gcc.dg/vect/vect-over-widen-1.c: Ditto.
        * gcc.dg/vect/vect-over-widen-2.c: Ditto.
        * gcc.dg/vect/vect-over-widen-3.c: Ditto.
        * gcc.dg/vect/vect-over-widen-4.c: Ditto.
        * gcc.dg/vect/vect-reduc-1char.c: Ditto.
        * gcc.dg/vect/vect-reduc-2char.c: Ditto.
        * gcc.dg/vect/vect-reduc-pattern-1b.c: Ditto.
        * gcc.dg/vect/vect-reduc-pattern-1c.c: Ditto.
        * gcc.dg/vect/vect-reduc-pattern-2b.c: Ditto.
        * gcc.dg/vect/vect-shift-2.c: Ditto.
        * gcc.dg/vect/vect-strided-a-u8

Re: [Patch, Fortran] PR 48887 [4.7] Don't mark SELECT TYPE selector as allocatable/pointer

[Paul Richard Thomas]

Dear Tobias,

Are you checking to see if the patches really are reviewed :-)

Index: gcc/fortran/class.c
===
--- gcc/fortran/class.c (Revision 181967)
+++ gcc/fortran/class.c (Arbeitskopie)
@@ -188,7 +188,8 @@ gfc_build_class_symbol (gfc_typespec *ts, symbol_a
 /* Class container has already been built.  */
 return SUCCESS;

-  attr->class_ok = attr->dummy || attr->pointer || attr->allocatable;
+  attr->class_ok = attr->dummy || attr->pointer || attr->allocatable
+  || attr.select_type_temporary;
/* Ahem, ahem! */

   if (!attr->class_ok)
 /* We can not build the class container yet.  */
@@ -239,7 +240,8 @@ gfc_build_class_symbol (gfc_typespec *ts, symbol_a
   c->attr.access = ACCESS_PRIVATE;
   c->ts.u.derived = ts->u.derived;
   c->attr.class_pointer = attr->pointer;
-  c->attr.pointer = attr->pointer || attr->dummy;
+  c->attr.pointer = attr->pointer || attr->dummy
+   || attr.select_type_temporary;   /* Ahem, 
ahem! */
   c->attr.allocatable = attr->allocatable;
   c->attr.dimension = attr->dimension;
   c->attr.codimension = attr->codimension;

The latter change gets rejected with my class array patch in place
because I have:
  c->attr.pointer = attr->pointer || (attr->allocatable ? 0 :  attr->dummy);

This prevents the conflict that occurs when an allocatable dummy is
allocated in the sub-program scope.  This is OK:

  c->attr.pointer = attr->pointer || (attr->allocatable ? 0 :  attr->dummy)
|| attr->select_type_temporary;

Apart from the two points above, it's OK for trunk.

Thanks for the patch and the test of my attention!

Paul


On Sat, Dec 3, 2011 at 4:06 PM, Tobias Burnus  wrote:
> gfortran wrongly marks the selector of a SELECT TYPE as having the pointer
> or allocatable attribute. Result: No error if one tries to change the
> allocation status.
>
> "If the selector is allocatable, it shall be allocated; the associate name
> is associated with the data object and does not have the ALLOCATABLE
> attribute." (F2008).
>
> Build and regtested on x86-64-linux.
> OK for the trunk?
>
> Tobias
>



-- 
The knack of flying is learning how to throw yourself at the ground and miss.
       --Hitchhikers Guide to the Galaxy

Re: [RFC] Port libitm to powerpc

[Iain Sandoe]

Hi Richard,

On 2 Dec 2011, at 23:36, Iain Sandoe wrote:


On 2 Dec 2011, at 22:59, Richard Henderson wrote:

I personally think the whole thing would be much easier to read  
without relying on the redzone.  Aside from that, there's actually  
very little real difference in the two files.  Essentially, you're  
storing the registers in a different order because the prologue  
does, just so you can make use of the redzone.


OK -  I guess I got carried away with thinking that I might be able  
to re-use the save_world () routine - but that doesn't look feasible  
after all so


The aix abi saves r2; darwin 32-bit saves r13.  One extra register  
in both cases, which could use the same slot.


... will take another look tomorrow
 although we still have some syntax issues that might make  
sharing the original code somewhat ugly


Two versions attached, both of which produce working code on darwin  
(although the attached modification to yours will be broken on  
assemblers needing % in front of reg names).


version 1 is a tidied up red-zone implementation.

===

version 2 is a modification of your original:

a)  -FRAME+BASE(r1) cannot be guaranteed to be vec-aligned in general  
(it isn't on m32 darwin)


... so I've taken the liberty of rounding the gtm_buffer object and  
then pointing r4 at  original_sp-rounded_size, which is what we want  
for the call to GTM_begin_transaction anyway.


b) I've added the CR etc. wrapped in  __MACH__ ifdefs.

c) ";" is a comment introducer for Darwin's asm .. so I unwrapped  
those lines ...


d) I put in the logic for handling __USER_LABEL_PREFIX__ .

===

e) The real problem is finding a non-horrible way of dealing with the  
%r <=> r issue - and I've not done that so far...


... pending your opinion on the best way forward

cheers
Iain


Index: libitm/config/darwin/powerpc/sjlj.S
===
--- libitm/config/darwin/powerpc/sjlj.S (revision 0)
+++ libitm/config/darwin/powerpc/sjlj.S (revision 0)
@@ -0,0 +1,335 @@
+/* Copyright (C) 2011 Free Software Foundation, Inc.
+   Contributed by Iain Sandoe .
+
+   This file is part of the GNU Transactional Memory Library (libitm).
+
+   Libitm 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 of the License, or
+   (at your option) any later version.
+
+   Libitm 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
+   .  */
+
+
+#if defined(__ppc64__)
+#define MODE_CHOICE(x, y) y
+#else
+#define MODE_CHOICE(x, y) x
+#endif
+
+#define MACHINEMODE_CHOICE(ppc7400,ppc64)
+#define g_long MODE_CHOICE(long, quad) /* usage is ".g_long" */
+#define GPR_BYTES  MODE_CHOICE(4,8)/* size of a GPR in bytes */
+#define FPR_BYTES  8   /* size of a FPR in bytes */
+#define LOG2_GPR_BYTES MODE_CHOICE(2,3)/* log2(GPR_BYTES) */
+
+#define cmpg   MODE_CHOICE(cmpw, cmpd)
+#define lg MODE_CHOICE(lwz, ld)
+#define sg MODE_CHOICE(stw, std)
+#define lgxMODE_CHOICE(lwzx, ldx)
+#define sgxMODE_CHOICE(stwx, stdx)
+#define lguMODE_CHOICE(lwzu, ldu)
+#define sguMODE_CHOICE(stwu, stdu)
+#define lgux   MODE_CHOICE(lwzux, ldux)
+#define sgux   MODE_CHOICE(stwux, stdux)
+#define lgwa   MODE_CHOICE(lwz, lwa)
+
+/* Stack frame constants.  */
+#define RED_ZONE_SIZE  MODE_CHOICE(224,288)
+#define LINKAGE_SIZE   MODE_CHOICE(24,48)
+#define SAVED_LR_OFFSETMODE_CHOICE(8,16)
+#define SAVED_CR_OFFSETMODE_CHOICE(4,8)
+
+/* We will assume that the code is to be built for a processor with Altivec.
+
+   TODO 1:
+   For Darwin 8 or earlier, which might be on hardware with either G3 or G4/G5,
+   then the vecSave code here would ideally need to be made conditional (for
+   m32) on __cpu_has_altivec from the system framework (as is done in Darwin`s
+   save_world () routine in libgcc). I.E. One needs to check for Altivec at
+   runtime.  As things stand, it should be fine on Darwin 8/9 with G4/G5.  */
+
+/* TODO 2:
+   Generate eh_frame data.  */
+
+# define VECS_SIZ  12*16
+
+#ifdef __ppc64__
+# define VEC_PAD   0
+#else
+# define VEC_PAD   8
+#endif
+
+#defin

Wrong parameter type for _mm256_insert_epi64 in avxintrin.h

[Jérémie Detrey]

Dear all,

Attached is a patch which fixes bug target/51393:

  http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51393

Also attached, avx_bug.c is a minimal example to reproduce the bug
(requires an AVX-capable CPU):

  $ gcc -O3 -mavx avx_bug.c
  $ ./a.out 0x8000
  in  = 0x8000
  out = 0x8000

The correct output should be:

  $ ./a.out 0x8000
  in  = 0x8000
  out = 0x8000

As explained in the bug report, it's just a matter of the second
parameter of _mm256_insert_epi64 being declared as int where it should
be long long (avxintrin.h:762). A simple typo, trivially fixed by the
attached patch.

Thanks a lot!
Cheers,
Jérémie.
Index: gcc/config/i386/avxintrin.h
===
--- gcc/config/i386/avxintrin.h (revision 181965)
+++ gcc/config/i386/avxintrin.h (working copy)
@@ -759,7 +759,7 @@ _mm256_insert_epi8 (__m256i __X, int __D
 
 #ifdef __x86_64__
 extern __inline __m256i __attribute__((__gnu_inline__, __always_inline__, 
__artificial__))
-_mm256_insert_epi64 (__m256i __X, int __D, int const __N)
+_mm256_insert_epi64 (__m256i __X, long long __D, int const __N)
 {
   __m128i __Y = _mm256_extractf128_si256 (__X, __N >> 1);
   __Y = _mm_insert_epi64 (__Y, __D, __N % 2);
2011-12-03  Jérémie Detrey  

PR target/51393
* config/i386/avxintrin.h (_mm256_insert_epi64): Declare second
parameter as long long.

[PATCH] [RFC] PR debug/49951 - jumpy stepping at end of scope in C++

[Dodji Seketeli]

Hello,

Consider this short C++ example annotated with line numbers for better
legibility and compiled without optimization:

 1  class MyClass
 2  {
 3  public:
 4MyClass() {};
 5   ~MyClass() {};
 6  };
 7  
 8  int
 9  main ()
10  {
11   MyClass m;
12   return 0;
13  }

When one steps (using e.g, 'next' in GDB) into the "main" function,
reaches line 12, and issues a 'next' again, the current line pointer
jumps back to line 11 (where 'm' is) before the function exits.

Jumping backward like this seems unexpected and annoying.

In the audit trail of the PR, Richard Guenther noted that the gimple
dump of the example code above is:

int main() ()
{
  int D.;

  [test.cc : 12:14] {
struct MyClass m;

try
  {
[test.cc : 11:14] MyClass::MyClass ([test.cc : 11] &m);
[test.cc : 12:14] try
  {
[test.cc : 12:13] D. = 0;
[test.cc : 12:13] return D.;
  }
finally
  {
[test.cc : 11:14] MyClass::~MyClass ([test.cc : 11] &m);
  }
  }
finally
  {
m = {CLOBBER};
  }
  }
  [test.cc : 13:1] D. = 0;
  [test.cc : 13:1] return D.;
}

We see that the line location of the call to the destructor of MyClass
is set to 11.  I think it should be set to the location of '}' of the
enclosing scope of the 'm' variable, thus 13.

My understanding is that when G++ sees the variable 'm' at line 11,
cp_finish_decl, via initialize_local_var builds a CLEANUP_STMT (by
indirectly calling push_cleanup) whose CLEANUP_EXPR is a call
expression to the destructor of m.  This will later be expanded to the
GIMPLE_TRY_FINALLY we see in the gimple dump above.

The problem is that the location of the call expression representing
the call to MyClass::~MyClass is set to the line that is current when
we are at 'm'.  Thus 11.

What I am proposing in the patch below is to wait until the closing
'}' of a given scope, walk the statements of that scope, and fixup the
locations of CLEANUP_STMTs by setting them the current location, i.e,
the location of the closing '}'.

I wanted to do that directly in the code of pop_stmt_list, but it's in
gcc/c-family/c-semantics.c so it won't know about the G++-specific
CLEANUP_STMTs tree.  So I went for a language hook instead.  It's
named lang_hooks.decls.statements and is called at the end of a scope
with the statements of that scope in argument.  The line location
fixup is thus done in the G++ specific implementation of that language
hook.

Bootstrapped and tested on x86_64-unknown-linux-gnu against trunk.

Comments?

gcc/
PR debug/49951
* langhooks.h (lang_hooks_for_decls::statement_at_end_of_scope):
New language hook.
* gcc/langhooks-def.h (LANG_HOOKS_STATEMENT_AT_END_OF_SCOPE):
Initialize the new lang hook.

gcc/c-family/

PR debug/49951
* c-semantics.c (pop_stmt_list): Call
lang_hooks.decls.statement_at_end_of_scope for the statements of
the scope.

gcc/cp/

PR debug/49951
* cp-objcp-common.h (LANG_HOOKS_STATEMENT_AT_END_OF_SCOPE): Set
this hook to cxx_statement_at_end_of_scope for G++.
* cp/cp-tree.h (cxx_statement_at_end_of_scope): Declare new
function.
* cp-objcp-common.c (cxx_statement_at_end_of_scope): Define it.
* parser.c (cp_parser_compound_statement):  Make sure that
input_location is set to the closing '}' when finish_compound_stmt
is called.
* Make-lang.in: add tree-iterator.h as a dependency of
cp/cp-objcp-common.o.

gcc/testsuite/

PR debug/49951
* g++.dg/gcov/gcov-2.C: Adjust test.
---
 gcc/c-family/c-semantics.c |8 +++-
 gcc/cp/Make-lang.in|3 ++-
 gcc/cp/cp-objcp-common.c   |   32 
 gcc/cp/cp-objcp-common.h   |2 ++
 gcc/cp/cp-tree.h   |1 +
 gcc/cp/parser.c|9 ++---
 gcc/langhooks-def.h|2 ++
 gcc/langhooks.h|4 
 gcc/testsuite/g++.dg/gcov/gcov-2.C |4 ++--
 9 files changed, 58 insertions(+), 7 deletions(-)

diff --git a/gcc/c-family/c-semantics.c b/gcc/c-family/c-semantics.c
index cb0f2be..222071b 100644
--- a/gcc/c-family/c-semantics.c
+++ b/gcc/c-family/c-semantics.c
@@ -30,6 +30,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "flags.h"
 #include "output.h"
 #include "tree-iterator.h"
+#include "langhooks.h"
 
 /* Create an empty statement tree rooted at T.  */
 
@@ -42,7 +43,11 @@ push_stmt_list (void)
   return t;
 }
 
-/* Finish the statement tree rooted at T.  */
+/* Finish the statement tree rooted at T.  Note that this will call
+   lang_hooks.decls.statement_at_end_of_scope with the list of
+   statements of 

Re: [Patch, Fortran] PR 48887 [4.7] Don't mark SELECT TYPE selector as allocatable/pointer

[Tobias Burnus]

Dear Paul,

Paul Richard Thomas wrote:

Are you checking to see if the patches really are reviewed :-)

t
I am - but involuntarily. I am sure that I build and regtested - but 
seemingly a different tree :-(



The latter change gets rejected with my class array patch in place
because I have:


I am really looking forward to have that patch in the trunk - it makes 
patch writing and testing easier if one does not have two separate 
trees, one clean with minor patches and one with your patch and 
occasionally some on-top patches.



This is OK:

   c->attr.pointer = attr->pointer || (attr->allocatable ? 0 :  attr->dummy)
|| attr->select_type_temporary;


I have now used
|| (attr->dummy && !attr->allocatable)
instead of
|| (attr->allocatable ? 0 : attr->dummy)
which I found more readable.

I did also did a rebuild, regtested it and committed the patch as Rev. 
181975.


Thanks for the careful review!

Tobias

[Patch, Fortran] PR 51383 - fix ASSOCIATE with extended types

[Tobias Burnus]

Another OOP-related patch: If one uses type extension, the first 
REF_COMPONENT does not necessarily refer directly to a component in the 
linked list starting at sym->ts.u.derived->components.


Using simply ref->u.c.component directly seems to work fine, thus, I do 
this with this patch.


Build and regtested on x86-64-linux.
OK for the trunk?

Tobias

PS: Other patches where review is pending:
- http://gcc.gnu.org/ml/fortran/2011-11/msg00250.html - no 
-fcheck=bounds for character(LEN=:) to avoid ICE
- http://gcc.gnu.org/ml/fortran/2011-11/msg00253.html - (Re)enable 
warning if a function result variable is not set [4.4-4.7 diagnostics 
regression]
- http://gcc.gnu.org/ml/fortran/2011-11/msg00254.html - Thomas' 
dependency-ICE patch [4.6/4.7 regression] (I will try to review this 
one, unless someone else is faster)
2011-12-03  Tobias Burnus  

	PR fortran/51383
	* resolve.c (find_array_spec): Use ref->u.c.component
	directly without starting from ts.u.derived.

2011-12-03  Tobias Burnus  

	PR fortran/51383
	* gfortran.dg/associate_10.f90: New.

Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c	(Revision 181975)
+++ gcc/fortran/resolve.c	(Arbeitskopie)
@@ -4515,14 +4515,12 @@ find_array_spec (gfc_expr *e)
 {
   gfc_array_spec *as;
   gfc_component *c;
-  gfc_symbol *derived;
   gfc_ref *ref;
 
   if (e->symtree->n.sym->ts.type == BT_CLASS)
 as = CLASS_DATA (e->symtree->n.sym)->as;
   else
 as = e->symtree->n.sym->as;
-  derived = NULL;
 
   for (ref = e->ref; ref; ref = ref->next)
 switch (ref->type)
@@ -4536,26 +4534,7 @@ find_array_spec (gfc_expr *e)
 	break;
 
   case REF_COMPONENT:
-	if (derived == NULL)
-	  derived = e->symtree->n.sym->ts.u.derived;
-
-	if (derived->attr.is_class)
-	  derived = derived->components->ts.u.derived;
-
-	c = derived->components;
-
-	for (; c; c = c->next)
-	  if (c == ref->u.c.component)
-	{
-	  /* Track the sequence of component references.  */
-	  if (c->ts.type == BT_DERIVED)
-		derived = c->ts.u.derived;
-	  break;
-	}
-
-	if (c == NULL)
-	  gfc_internal_error ("find_array_spec(): Component not found");
-
+	c = ref->u.c.component;
 	if (c->attr.dimension)
 	  {
 	if (as != NULL)
Index: gcc/testsuite/gfortran.dg/associate_10.f90
===
--- gcc/testsuite/gfortran.dg/associate_10.f90	(Revision 0)
+++ gcc/testsuite/gfortran.dg/associate_10.f90	(Arbeitskopie)
@@ -0,0 +1,23 @@
+! { dg-do compile }
+!
+! PR fortran/51383
+!
+! Contributed by kaiserkar...@yahoo.com
+!
+! Was failing before at the ref resolution of y1(1)%i.
+!
+program extend
+   type :: a
+  integer :: i
+   end type a
+   type, extends (a) :: b
+  integer :: j
+   end type b
+   type (a) :: x(2)
+   type (b) :: y(2)
+   associate (x1 => x, y1 => y)
+  x1(1)%i = 1
+  ! Commenting out the following line will avoid the error
+  y1(1)%i = 2
+   end associate
+end program extend

[Patch, fortran] PR 50690 Disable common function elimination in WORKSHAREs

[Thomas Koenig]

Hello world,

the recent discussion has convinced me that there is no way to
mix OMP workshares and common function elimination as practiced by
frontend-passes.c.  This patch therefore disables that
particular optimization within workshares.

Regression-tested.  OK for trunk?

Thomas

2011-12-02  Thomas Koenig  

PR fortran/50690
* frontend-passes.c (workshare_level):  New variable.
(cfe_expr_0):  Don't eliminiat common functions within
workshares.
(gfc_code_walker):  Keep track of workshare level.

2011-12-02  Thomas Koenig  

PR fortran/50690
* gfortran.dg/gomp/workshare2.f90:  New test.
! { dg-do compile }
! { dg-options "-ffrontend-optimize" }
! PR 50690 - this used to ICE because workshare could not handle
! BLOCKs.
! To test for correct execution, run this program (but don't forget
! to unset the stack limit).
program foo
  implicit none
  integer, parameter :: n = 1
  real, parameter :: eps = 3e-7
  integer :: i,j
  real :: A(n), B(5), C(n)
  real :: tmp
  B(1) = 3.344
  tmp = B(1)
  do i=1,10
 call random_number(a)
 c = a
 !$omp parallel default(shared)
 !$omp workshare
 A(:) = A(:)*cos(B(1))+A(:)*cos(B(1))
 !$omp end workshare nowait
 !$omp end parallel ! sync is implied here
  end do

  c = c*tmp + c*tmp

  do j=1,n
 if (abs(a(j)-c(j)) > eps) then
print *,1,j,a(j), c(j)
call abort
 end if
  end do

  do i=1,10
 call random_number(a)
 c = a
 !$omp parallel workshare default(shared)
 A(:) = A(:)*cos(B(1))+A(:)*cos(B(1))
 !$omp end parallel workshare
  end do

  c = c*tmp + c*tmp
  do j=1,n
 if (abs(a(j)-c(j)) > eps) then
print *,2,j,a(j), c(j)
call abort
 end if
  end do

end program foo
Index: frontend-passes.c
===
--- frontend-passes.c	(Revision 181809)
+++ frontend-passes.c	(Arbeitskopie)
@@ -66,6 +66,10 @@ static gfc_namespace *current_ns;
 
 static int forall_level;
 
+/* If we are within an OMP WORKSHARE or OMP PARALLEL WORKSHARE.  */
+
+static int workshare_level;
+
 /* Entry point - run all passes for a namespace.  So far, only an
optimization pass is run.  */
 
@@ -367,6 +371,13 @@ cfe_expr_0 (gfc_expr **e, int *walk_subtrees,
   int i,j;
   gfc_expr *newvar;
 
+  /* Don't do this optimization within WORKSHARES.  */
+  if (workshare_level > 0)
+{
+  *walk_subtrees = 0;
+  return 0;
+}
+
   expr_count = 0;
 
   gfc_expr_walker (e, cfe_register_funcs, NULL);
@@ -505,6 +516,7 @@ optimize_namespace (gfc_namespace *ns)
 
   current_ns = ns;
   forall_level = 0;
+  workshare_level = 0;
 
   gfc_code_walker (&ns->code, convert_do_while, dummy_expr_callback, NULL);
   gfc_code_walker (&ns->code, cfe_code, cfe_expr_0, NULL);
@@ -1330,14 +1342,18 @@ gfc_code_walker (gfc_code **c, walk_code_fn_t code
 	  WALK_SUBEXPR (co->ext.dt->extra_comma);
 	  break;
 
+	case EXEC_OMP_PARALLEL_WORKSHARE:
+	case EXEC_OMP_WORKSHARE:
+	  workshare_level ++;
+
+	  /* Fall through.  */
+
 	case EXEC_OMP_DO:
 	case EXEC_OMP_PARALLEL:
 	case EXEC_OMP_PARALLEL_DO:
 	case EXEC_OMP_PARALLEL_SECTIONS:
-	case EXEC_OMP_PARALLEL_WORKSHARE:
 	case EXEC_OMP_SECTIONS:
 	case EXEC_OMP_SINGLE:
-	case EXEC_OMP_WORKSHARE:
 	case EXEC_OMP_END_SINGLE:
 	case EXEC_OMP_TASK:
 	  if (co->ext.omp_clauses)
@@ -1366,6 +1382,10 @@ gfc_code_walker (gfc_code **c, walk_code_fn_t code
 	  if (co->op == EXEC_FORALL)
 	forall_level --;
 
+	  if (co->op == EXEC_OMP_WORKSHARE
+	  || co->op == EXEC_OMP_PARALLEL_WORKSHARE)
+	workshare_level --;
+
 	}
 }
   return 0;

Re: [C++ Patch] PR 51326

[Dodji Seketeli]

Hello Paolo,

Paolo Carlini  a écrit:

> Index: cp/call.c
> ===
> --- cp/call.c (revision 181875)
> +++ cp/call.c (working copy)
> @@ -3373,7 +3373,7 @@ static struct z_candidate *
>  build_user_type_conversion_1 (tree totype, tree expr, int flags)
>  {
>struct z_candidate *candidates, *cand;
> -  tree fromtype = TREE_TYPE (expr);
> +  tree fromtype;
>tree ctors = NULL_TREE;
>tree conv_fns = NULL_TREE;
>conversion *conv = NULL;
> @@ -3382,6 +3382,11 @@ build_user_type_conversion_1 (tree totype, tree ex
>bool any_viable_p;
>int convflags;
>  
> +  if (!expr)
> +return NULL;
> +
> +  fromtype = TREE_TYPE (expr);
> +
>/* We represent conversion within a hierarchy using RVALUE_CONV and
>   BASE_CONV, as specified by [over.best.ics]; these become plain
>   constructor calls, as specified in [dcl.init].  */

This might be a theoretical nit, but it looks like if expr is
error_mark_node, we'd crash as well, because of the line below that comes
right after the comment above:

  gcc_assert (!MAYBE_CLASS_TYPE_P (fromtype) || !MAYBE_CLASS_TYPE_P (totype)
  || !DERIVED_FROM_P (totype, fromtype));

I don't have a test case for that though.

-- 
Dodji

Re: [Patch, fortran] PR 50690 Disable common function elimination in WORKSHAREs

[Jakub Jelinek]

On Sat, Dec 03, 2011 at 09:58:17PM +0100, Thomas Koenig wrote:
> the recent discussion has convinced me that there is no way to
> mix OMP workshares and common function elimination as practiced by
> frontend-passes.c.  This patch therefore disables that
> particular optimization within workshares.
> 
> Regression-tested.  OK for trunk?

I think disabling these optimizations in workshare/parallel workshare
is reasonable, though perhaps you could enable it again in
EXEC_OMP_PARALLEL{,_DO,_SECTIONS} nested in the
EXEC_OMP_WORKSHARE/EXEC_OMP_PARALLEL_WORKSHARE.

E.g. in
  $omp parallel workshare
a = b
$omp parallel
  c = cos(d) + cos(d)
$omp end parallel
e = f
  $omp end parallel workshare
the body of the inner $omp parallel can be optimized just fine.

Jakub

[PATCH, libcpp] Add 'inline' to prototype of tokens_buff_remove_last_token

[Dodji Seketeli]

Hello,

in macro.c, I have inadvertently added an "inline" function specifier
to the definition of the static tokens_buff_remove_last_token
definition while its previous prototype didn't have the "inline".

There is code using the that function before the definition (and after
its declaration) and apparently GCC 4.3 warns about that, as Steven
Bosscher reported at http://gcc.gnu.org/ml/gcc/2011-12/msg2.html.

I am thus simply adding the "inline" to the prototype and am going to
commit it as obvious.  I did the same to the other occurrence of the
same issue that I found in the file.

Bootstrapped on x86_64-unknown-linux-gnu against trunk.

libcpp/

* macro.c (tokens_buff_remove_last_token)
(tokens_buff_put_token_to): Add an 'inline' function specifier to
the prototype.
---
 libcpp/ChangeLog |6 ++
 libcpp/macro.c   |   16 
 2 files changed, 14 insertions(+), 8 deletions(-)

diff --git a/libcpp/ChangeLog b/libcpp/ChangeLog
index 1df9e08..f47bf03 100644
--- a/libcpp/ChangeLog
+++ b/libcpp/ChangeLog
@@ -1,3 +1,9 @@
+2011-12-03  Dodji Seketeli  
+
+   * macro.c (tokens_buff_remove_last_token)
+   (tokens_buff_put_token_to): Add an 'inline' function specifier to
+   the prototype.
+
 2011-11-22   Diego Novillo  
 
* include/line-map.h (linemap_dump): Declare.
diff --git a/libcpp/macro.c b/libcpp/macro.c
index f313959..d96b263 100644
--- a/libcpp/macro.c
+++ b/libcpp/macro.c
@@ -128,13 +128,13 @@ static _cpp_buff *tokens_buff_new (cpp_reader *, size_t,
   source_location **);
 static size_t tokens_buff_count (_cpp_buff *);
 static const cpp_token **tokens_buff_last_token_ptr (_cpp_buff *);
-static const cpp_token **tokens_buff_put_token_to (const cpp_token **,
-  source_location *, 
-  const cpp_token *,
-  source_location,
-  source_location,
-  const struct line_map *,
-  unsigned int);
+static inline const cpp_token **tokens_buff_put_token_to (const cpp_token **,
+  source_location *,
+  const cpp_token *,
+  source_location,
+  source_location,
+  const struct 
line_map *,
+  unsigned int);
 
 static const cpp_token **tokens_buff_add_token (_cpp_buff *,
source_location *,
@@ -143,7 +143,7 @@ static const cpp_token **tokens_buff_add_token (_cpp_buff *,
source_location,
const struct line_map *,
unsigned int);
-static void tokens_buff_remove_last_token (_cpp_buff *);
+static inline void tokens_buff_remove_last_token (_cpp_buff *);
 static void replace_args (cpp_reader *, cpp_hashnode *, cpp_macro *,
  macro_arg *, source_location);
 static _cpp_buff *funlike_invocation_p (cpp_reader *, cpp_hashnode *,
-- 
1.7.6.4



-- 
Dodji

Re: [PATCH] Remove dead labels to increase superblock scope

[Tom de Vries]

On 02/12/11 11:40, Richard Sandiford wrote:
> Tom de Vries  writes:
>> On 27/11/11 23:59, Eric Botcazou wrote:
 No, DELETED_LABEL notes still work just fine. It depends on how you
 remove the label and replace it with a note, and Tom isn't showing
 what he did, so...
>>>
>>> I agree that there is no obvious reason why just calling delete_insn would 
>>> not 
>>> work, so this should be investigated first.
>>>
>>
>> The reason it didn't work, is because after turning a label into a
>> NOTE_INSN_DELETED_LABEL, one needs to move it to after the 
>> NOTE_INSN_BASIC_BLOCK
>> as in cfgcleanup.c:try_optimize_cfg():
>> ...
>>delete_insn_chain (label, label, false);
>>/* If the case label is undeletable, move it after the
>>   BASIC_BLOCK note.  */
>>if (NOTE_KIND (BB_HEAD (b)) == NOTE_INSN_DELETED_LABEL)
>>  {
>>rtx bb_note = NEXT_INSN (BB_HEAD (b));
>>
>>reorder_insns_nobb (label, label, bb_note);
>>BB_HEAD (b) = bb_note;
>>if (BB_END (b) == bb_note)
>>  BB_END (b) = label;
>>  }
>> ...
>>
>> Attached patch factors out this piece of code and reuses it in 
>> fixup_reorder_chain.
> 
> But isn't...
> 
>> @@ -2637,15 +2658,7 @@ try_optimize_cfg (int mode)
>>delete_insn_chain (label, label, false);
>>/* If the case label is undeletable, move it after the
>>   BASIC_BLOCK note.  */
>> -  if (NOTE_KIND (BB_HEAD (b)) == NOTE_INSN_DELETED_LABEL)
>> -{
>> -  rtx bb_note = NEXT_INSN (BB_HEAD (b));
>> -
>> -  reorder_insns_nobb (label, label, bb_note);
>> -  BB_HEAD (b) = bb_note;
>> -  if (BB_END (b) == bb_note)
>> -BB_END (b) = label;
>> -}
>> +  fixup_deleted_label (b);
> 
> ...this "delete_insn_chain (label, label, false);" call equivalent
> to "delete_insn (label)"?  

Indeed, it is.

> Splitting the operation in two here and:
> 
>> Index: gcc/cfglayout.c
>> ===
>> --- gcc/cfglayout.c (revision 181652)
>> +++ gcc/cfglayout.c (working copy)
>> @@ -857,6 +857,12 @@ fixup_reorder_chain (void)
>> (e_taken->src, e_taken->dest));
>>e_taken->flags |= EDGE_FALLTHRU;
>>update_br_prob_note (bb);
>> +  if (LABEL_NUSES (ret_label) == 0
>> +  && single_pred_p (e_taken->dest))
>> +{
>> +  delete_insn (ret_label);
>> +  fixup_deleted_label (e_taken->dest);
>> +}
> 
> ...here seems a little odd.
> 
> Richard

OK, factored out delete_label now.

Bootstrapped and reg-tested on x86_64.

Ok for next stage1?

Thanks,
- Tom

2011-12-03  Tom de Vries  

* cfgcleanup.c (delete_label): New function, factored out of ...
(try_optimize_cfg): Use deleted_label.
* basic-block.h (delete_label): Declare.
* cfglayout.c (fixup_reorder_chain): Delete unused label using
delete_label.

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

Index: gcc/cfgcleanup.c
===
--- gcc/cfgcleanup.c (revision 181172)
+++ gcc/cfgcleanup.c (working copy)
@@ -2518,6 +2518,39 @@ trivially_empty_bb_p (basic_block bb)
 }
 }
 
+/* Delete the label at the head of BB, and if that results in a DELETED_LABEL
+   note, move it after the BASIC_BLOCK note of BB.  */
+
+void
+delete_label (basic_block bb)
+{
+  rtx label = BB_HEAD (bb), deleted_label, bb_note;
+  gcc_assert (LABEL_P (label));
+
+  /* Delete the label.  */
+  delete_insn (label);
+  if (dump_file)
+fprintf (dump_file, "Deleted label in block %i.\n",
+	 bb->index);
+
+  /* Find the DELETED_LABEL note.  */
+  deleted_label = BB_HEAD (bb);
+  if (deleted_label == NULL_RTX
+  || !NOTE_P (deleted_label)
+  || NOTE_KIND (deleted_label) != NOTE_INSN_DELETED_LABEL)
+return;
+
+  /* Find the BASIC_BLOCK note.  */
+  bb_note = NEXT_INSN (deleted_label);
+  gcc_assert (bb_note != NULL_RTX && NOTE_INSN_BASIC_BLOCK_P (bb_note));
+
+  /* Move the DELETED_LABEL note after the BASIC_BLOCK note.  */
+  reorder_insns_nobb (deleted_label, deleted_label, bb_note);
+  BB_HEAD (bb) = bb_note;
+  if (BB_END (bb) == bb_note)
+BB_END (bb) = deleted_label;
+}
+
 /* Do simple CFG optimizations - basic block merging, simplifying of jump
instructions etc.  Return nonzero if changes were made.  */
 
@@ -2631,25 +2664,7 @@ try_optimize_cfg (int mode)
 		  || !JUMP_P (BB_END (single_pred (b)))
 		  || ! label_is_jump_target_p (BB_HEAD (b),
 		   BB_END (single_pred (b)
-		{
-		  rtx label = BB_HEAD (b);
-
-		  delete_insn_chain (label, label, false);
-		  /* If the case label is undeletable, move it aft

Re: [C++ Patch] PR 51326

[Jason Merrill]

On 12/03/2011 04:25 PM, Dodji Seketeli wrote:

This might be a theoretical nit, but it looks like if expr is
error_mark_node, we'd crash as well, because of the line below that comes
right after the comment above:

   gcc_assert (!MAYBE_CLASS_TYPE_P (fromtype) || !MAYBE_CLASS_TYPE_P (totype)
  || !DERIVED_FROM_P (totype, fromtype));


That should be OK, since TREE_TYPE (error_mark_node) is error_mark_node.

Jason

Re: [testsuite,committed] Fix gcc.c-torture/execute/vector-subscript-1.c

[Mike Stump]

On Dec 2, 2011, at 10:48 AM, Georg-Johann Lay wrote:
> http://gcc.gnu.org/viewcvs?view=revision&revision=181933
> 
> Committed the following, obvious fix to a test case that assumed
> sizeof(int) = 4:

Thanks.

Re: [Patch PPC/Darwin] some tidy-ups for save_world (and a prelude to splitting it out of the rs6000 code).

[Mike Stump]

On Nov 30, 2011, at 6:28 AM, Iain Sandoe wrote:
> While trying to track down the vector unwind problems on ppc-darwin, I made 
> some tidy-ups for "save_world()".
> In the end, that was not where the main problem, lay - but I did find a few 
> things wrong there on the way - they should be fixed, even if there's no 
> specific bug filed at present.
> 
> I'm also attaching a second patch which is purely cosmetic 
> white-space/comment tidies I'd also like to apply.
> 
> checked on powerpc-darwin{8-G4,9-G5} and crosses to powerpc-eabisim and 
> powerpc-ibm-aix6.1.3.0

> -  /* On Darwin, the unwind routines are compiled without
> - TARGET_ALTIVEC, and use save_world to save/restore the
> - altivec registers when necessary.  */
> +  /* When generating code for earlier versions of Darwin, which might run on
> + hardware with or without Altivec, we use out-of-line save/restores in
> + function prologues/epilogues that require it.  These routines determine
> + whether to save/restore Altivec at runtime.  */

So, we need to first settle on how the library is compiled before this becomes 
true...


> +save_world:
> + trap
> +
> + .private_extern eh_rest_world_r10
> +eh_rest_world_r10:
> + trap

So, I can't see the necessity of doing this.  I think it is bad style to 
generate code that will die at runtime.  I'd rather have it not link.


> - /* We should really use VRSAVE to figure out which vector regs
> + /* ??? We should really use VRSAVE to figure out which vector regs
>  we actually need to save and restore.  Some other time :-/  */

Why add   Could you elaborate.  I see two possibilities, you think it 
impossible, and thus the comment should be changes to say, we need to save all 
the register because..., or you don't understand what is meant by the comment...

Patch 2 is fine without this change.

Re: [PATCH] pass -no_pie to LINK_GCC_C_SEQUENCE_SPEC on darwin

[Mike Stump]

On Dec 3, 2011, at 7:25 AM, Jack Howarth wrote:
> FSF gcc currently doesn't handle -fno-pie and friends properly under Lion.
> The darwin11 linker now defaults to -pie

> Okay for gcc trunk and backports to gcc-4_5-branch/gcc-4_6-branch?

Ok.

Re: [C++ Patch] PR 51326

[Dodji Seketeli]

Jason Merrill  a écrit:

> On 12/03/2011 04:25 PM, Dodji Seketeli wrote:
>> This might be a theoretical nit, but it looks like if expr is
>> error_mark_node, we'd crash as well, because of the line below that comes
>> right after the comment above:
>>
>>gcc_assert (!MAYBE_CLASS_TYPE_P (fromtype) || !MAYBE_CLASS_TYPE_P (totype)
>>|| !DERIVED_FROM_P (totype, fromtype));
>
> That should be OK, since TREE_TYPE (error_mark_node) is
> error_mark_node.

Oh, right.

-- 
Dodji

Update Objective-C++ testcase

[Mike Stump]

I've approved and applied this...

Index: testsuite/ChangeLog
===
--- testsuite/ChangeLog (revision 181983)
+++ testsuite/ChangeLog (working copy)
@@ -1,3 +1,9 @@
+2011-12-03  Dominique d'Humieres  
+
+   PR obj-c++/51349
+   * obj-c++.dg/naming-3.mm: Adjust for changing error messages.
+   * obj-c++.dg/naming-4.mm: Likewise.
+
 2011-12-03  Jack Howarth  
 
* gcc.dg/darwin-segaddr.c: Use -no-pie.
Index: testsuite/obj-c++.dg/naming-3.mm
===
--- testsuite/obj-c++.dg/naming-3.mm(revision 181980)
+++ testsuite/obj-c++.dg/naming-3.mm(working copy)
@@ -3,9 +3,9 @@
 
 @interface A 
 {
-  char x; /* { dg-error "conflicts" } */
+  char x; /* { dg-message "previous declaration" } */
   char x;
-} /* { dg-error "declaration" } */
+} /* { dg-error "redeclaration" } */
 @end
 
 @interface B : A
Index: testsuite/obj-c++.dg/naming-4.mm
===
--- testsuite/obj-c++.dg/naming-4.mm(revision 181980)
+++ testsuite/obj-c++.dg/naming-4.mm(working copy)
@@ -28,12 +28,12 @@
   char r0; char r1; char r2; char r3; char r4; char r5; char r6; char r7; char 
r8; char r9;
   char s0; char s1; char s2; char s3; char s4; char s5; char s6; char s7; char 
s8; char s9;
 
-  char x; /* { dg-error "conflicts" } */
+  char x; /* { dg-message "previous declaration" } */
   char x;
 
   char z; /* { dg-message "previous declaration" } */
   char k; /* { dg-message "previous declaration" } */
-}  /* { dg-error "declaration" } */
+}  /* { dg-error "redeclaration" } */
 @end
 
 @interface B : A
@@ -60,11 +60,11 @@
   char Br0; char Br1; char Br2; char Br3; char Br4; char Br5; char Br6; char 
Br7; char Br8; char Br9;
   char Bs0; char Bs1; char Bs2; char Bs3; char Bs4; char Bs5; char Bs6; char 
Bs7; char Bs8; char Bs9;
 
-  char y; /* { dg-message "conflicts" } */
+  char y; /* { dg-message "previous declaration" } */
   char y;
 
   char z; /* { dg-error "duplicate instance variable" } */
-} /* { dg-error "declaration" } */
+} /* { dg-error "redeclaration" } */
 @end
 
 @interface C : A
@@ -97,12 +97,12 @@
   char Dr0; char Dr1; char Dr2; char Dr3; char Dr4; char Dr5; char Dr6; char 
Dr7; char Dr8; char Dr9;
   char Ds0; char Ds1; char Ds2; char Ds3; char Ds4; char Ds5; char Ds6; char 
Ds7; char Ds8; char Ds9;
 
-  char y; /* { dg-message "conflicts" } */
+  char y; /* { dg-message "previous declaration" } */
   char y;
 
   char w; /* { dg-error "duplicate instance variable" } */
   char k; /* { dg-error "duplicate instance variable" } */
-}  /* { dg-error "declaration" } */
+}  /* { dg-error "redeclaration" } */
 @end
 
 /* Finally, make sure that anonymous instance variables don't trigger



Index: testsuite/ChangeLog
===
--- testsuite/ChangeLog (revision 181983)
+++ testsuite/ChangeLog (working copy)
@@ -1,3 +1,9 @@
+2011-12-03  Dominique d'Humieres  
+
+   PR obj-c++/51349
+   * obj-c++.dg/naming-3.mm: Adjust for changing error messages.
+   * obj-c++.dg/naming-4.mm: Likewise.
+
 2011-12-03  Jack Howarth  
 
* gcc.dg/darwin-segaddr.c: Use -no-pie.
Index: testsuite/obj-c++.dg/naming-3.mm
===
--- testsuite/obj-c++.dg/naming-3.mm(revision 181980)
+++ testsuite/obj-c++.dg/naming-3.mm(working copy)
@@ -3,9 +3,9 @@
 
 @interface A 
 {
-  char x; /* { dg-error "conflicts" } */
+  char x; /* { dg-message "previous declaration" } */
   char x;
-} /* { dg-error "declaration" } */
+} /* { dg-error "redeclaration" } */
 @end
 
 @interface B : A
Index: testsuite/obj-c++.dg/naming-4.mm
===
--- testsuite/obj-c++.dg/naming-4.mm(revision 181980)
+++ testsuite/obj-c++.dg/naming-4.mm(working copy)
@@ -28,12 +28,12 @@
   char r0; char r1; char r2; char r3; char r4; char r5; char r6; char r7; char 
r8; char r9;
   char s0; char s1; char s2; char s3; char s4; char s5; char s6; char s7; char 
s8; char s9;
 
-  char x; /* { dg-error "conflicts" } */
+  char x; /* { dg-message "previous declaration" } */
   char x;
 
   char z; /* { dg-message "previous declaration" } */
   char k; /* { dg-message "previous declaration" } */
-}  /* { dg-error "declaration" } */
+}  /* { dg-error "redeclaration" } */
 @end
 
 @interface B : A
@@ -60,11 +60,11 @@
   char Br0; char Br1; char Br2; char Br3; char Br4; char Br5; char Br6; char 
Br7; char Br8; char Br9;
   char Bs0; char Bs1; char Bs2; char Bs3; char Bs4; char Bs5; char Bs6; char 
Bs7; char Bs8; char Bs9;
 
-  char y; /* { dg-message "conflicts" } */
+  char y; /* { dg-message "previous declaration" } */
   char y;
 
   char z; /* { dg-error "duplicate instance variable" } */
-} /* { dg-error "declaration" } */
+} /* { dg-error "redeclaration" } */
 @end
 
 @interface C : A
@@ -97

Re: [RFA/testsuite] Use rand instead of random (again)

[Mike Stump]

On Nov 30, 2011, at 6:06 AM, Matthew Gretton-Dann wrote:
> The attached patch changes another use of random in the testsuite to rand.

> Please can someone review.

Ok?  is the canonical spelling for this...  :-)

Ok.  (is the canonical answer.)

> 2011-11-30  Matthew Gretton-Dann  
> 
>   * gcc.dg/torture/vec-cvt-1.c (FLTTEST): Call rand instead of
>   random.