Re: Symtab cleanups 2/17 - merge alias code

[Marcus Shawcroft]

On 7 June 2013 20:58, Jan Hubicka  wrote:

> Hi,
> I have comitted the following.  Does it solve your problem?
>
> Honza
>
> Index: ChangeLog
> ===
> --- ChangeLog   (revision 199834)
> +++ ChangeLog   (working copy)
> @@ -1,3 +1,7 @@
> +2013-06-07  Jan Hubicka  
> +
> +   * symtab.c (symtab_resolve_alias): Do not remove alias attribute.
> +

Honza, This fixes the issue I had with TLS.

Thank you.

/Marcus

[C++ docs patch] PR 56544

[Paolo Carlini]

Hi,

the bug reminds us to update the documentation about the value of 
__cplusplus. I tentatively prepared the below, is it clear enough?


We could probably apply something to the branch too, without the 
-std=c++1y bits, thus end simply like '; or @code{201103L}, per the 2011 
C++ standard' or more verbosely say that with -std=c++1y too the value 
is 201103L.


Thanks,
Paolo.

///
Index: doc/cpp.texi
===
--- doc/cpp.texi(revision 199792)
+++ doc/cpp.texi(working copy)
@@ -1926,11 +1926,11 @@ facilities of the standard C library available.
 This macro is defined when the C++ compiler is in use.  You can use
 @code{__cplusplus} to test whether a header is compiled by a C compiler
 or a C++ compiler.  This macro is similar to @code{__STDC_VERSION__}, in
-that it expands to a version number.  A fully conforming implementation
-of the 1998 C++ standard will define this macro to @code{199711L}.  The
-GNU C++ compiler is not yet fully conforming, so it uses @code{1}
-instead.  It is hoped to complete the implementation of standard C++
-in the near future.
+that it expands to a version number.  Depending on the language standard
+selected, the value of the macro is @code{199711L}, as mandated by the
+1998 C++ standard; @code{201103L}, per the 2011 C++ standard; an
+unspecified value strictly larger than @code{201103L} for the experimental 
+languages enabled by @option{-std=c++1y} and @option{-std=gnu++1y}.
 
 @item __OBJC__
 This macro is defined, with value 1, when the Objective-C compiler is in

Re: [Patch, Fortran] PR57553 - fix two STORAGE_SIZE bugs

[Mikael Morin]

Le 07/06/2013 18:11, Tobias Burnus a écrit :
> This patch fixes two issues:
> *  storage_size('aa')  was rejected as constant expression - as
> ts.u.cl->length == 0.
> * In trans*.c, there was a fold_convert missing (-> ICE). Additionally,
> I have replaced the detour to generate a tree containing the value "8"
> via a fortran expression.
> 
> Build and regtested on x86-64-gnu-linux.
> OK for the trunk?
> 
OK, thanks.

Mikael

Re: *PING* / Re: [Patch, Fortran] Finalize nonallocatables with INTENT(out)

[Mikael Morin]

Hello,

Le 06/06/2013 10:35, Tobias Burnus a écrit :
> * PING *
> 
> Attached is a rediff - including the later posted additional test case
> (http://gcc.gnu.org/ml/fortran/2013-05/msg00141.html)
> 
> 
> On May 31, 2013 18:39, Tobias Burnus wrote:
>> This patch adds finalization support for INTENT(out) for
>> nonallocatable dummy arguments.
>>
>> Additionally, it addresses a missed optimization: The previous code
>> tried to deallocate allocatable components even if the dummy argument
>> was already an allocatable. That's a missed optimization as gfortran
>> deallocates allocatables in the caller.
>>
Is there any reason to handle them in the caller?

The patch is OK.

Mikael

Re: *PING* / Re: [Patch, Fortran] Finalize nonallocatables with INTENT(out)

[Tobias Burnus]

Hello Mikael,

thanks for your patch reviews! Regarding your question:

Mikael Morin worte:

Le 06/06/2013 10:35, Tobias Burnus a écrit :

On May 31, 2013 18:39, Tobias Burnus wrote:

This patch adds finalization support for INTENT(out) for
nonallocatable dummy arguments.

Additionally, it addresses a missed optimization: The previous code
tried to deallocate allocatable components even if the dummy argument
was already an allocatable. That's a missed optimization as gfortran
deallocates allocatables in the caller.


Is there any reason to handle them in the caller?


I don't think that there is real reason - and I don't know why Erik 
Edelmann and Paul have chosen to do so for GCC 4.2. In principle, either 
location is fine. I think I had placed it into the callee, but now we 
cannot change it anymore without breaking the ABI.


For TS29113 (i.e. for bind(C)), the Fortran procedure has to handle the 
deallocate for allocatable dummys with intent(out). Thus, in that case, 
one needs to have the deallocation code both in the caller and in the 
callee. (TS29113 only permits interoperable types with ALLOCATABLE or 
INTENT(OUT) - noninteroperable vars (i.e. extensible types, allocatable 
components, finalizers etc.) can be used in BIND(C) procedures - but 
only with the dummy argument TYPE(*) - and hence without ALLOCATABLE and 
INTENT(OUT)).


Tobias

PS: Pending patches:
* 4.8/4.9 regression: http://gcc.gnu.org/ml/fortran/2013-06/msg00047.html
* CLASS as result var: http://gcc.gnu.org/ml/fortran/2013-06/msg00053.html

Re: [c++-concepts] code review

[Andrew Sutton]

>> +C++ ObjC++ Var(flag_concepts, true)
>
> This line declares flag_concepts implicitly.

Ah... I see. Fixed.


>> That's the long and short of it. Gaby suggested writing constraints
>> here so that, for any instantiation, you would have easy access to the
>> constraints for that declaration.
>
> I'm not sure why you would care about the constraints for a particular
> instantiation; constraints only apply to the template, right?

In concepts lite, yes. Moving forward... I'm less certain. In the
context of separate checking, instantiated requirements may carry
lookup information into the current instantiation. But that's just
speculation.

I think I previously put constraint_info in lang_decl_min, right next
to template_info no less. It was easy to manage there, and initialized
as part of build_template_decl. But this obviously doesn't work for
partial specializations unless they get template_decls.

I'd be okay committing the current design with the caveat that it may
need to be rewritten in the not-so-distant future. I've already
written the other other way two or three times, so I'm familiar with
those changes.


>> branch_goal queues a copy of the current sub-goal, returning a
>> reference to that new branch. The insertion of the operands are done
>> on different sub-goals, giving the expected results.
>
> Right, I suppose I should have paid more attention to "This does not update
> the current goal"...

On the topic of logic.cc, I'm plan on rewriting this module to use a
set instead of lists. There will be some pretty substantial changes to
the internal interfaces.

Would it be reasonable to commit this now (since it works correctly),
and plan to rewrite it in the near future?


> template
> tree
> extract_goals (proof_state& s)
> ...
>  return extract_goals(s);
>
> but I suppose STL style is OK, too.


Huh. I didn't realize that could be inlined. Neat.


>> I was trying to write the parsing code a little more modularly so I
>> could keep my parse functions as small as possible. I use the facility
>> more heavily in the requires/validexpr code that's not included here.
>
>
> Hmm, to me it seems more modular to keep all of the code for handling e.g.
> "requires" in its own function rather than needing two different places to
> know how a requires clause starts.

I think I see where the problem is. cp_parser_requires_clause is
parsed non-optionally in a requires expression, but that's not
included in the patch. I factored out the explicit parsing (hence the
assertion) from the optional parsing.

I could remove the assertion. There's no path to that function that
does not first check that 'requires' has been found.


>>> Why don't you use 'release' and conjoin_requirements here?
>>
>>
>> Because there is no template parameter list that can provide
>> additional requirements in this declaration.
>
>
> OK, please add a comment to that effect.

On second thought, the absence of release() may actually have been a
bug. Comment added.


>>> The comment sounds more like tsubst_template_parms than
>>> coerce_template_parms.
>>
>>
>> It might be... I'll have to look. What I actually want to get is the
>> set of actual arguments that will be substituted for template
>> parameters given an initial set of arguments (lookup default
>> arguments, generate pack arguments, etc).
>
>
> Right, I think coerce_template_parms has the effect you want, I just don't
> think of it as doing substitution, so the comment and name could use a
> tweak.  If the function doesn't go away, that is.

Still looking at this.

What is the main entry point to overload resolution?

Andrew

Re: [PATCH] DATA_ALIGNMENT vs. DATA_ABI_ALIGNMENT (PR target/56564)

[Jakub Jelinek]

On Fri, Jun 07, 2013 at 06:56:34PM -0400, Hans-Peter Nilsson wrote:
> > criscompiler options for alignment -- systemwide or local?
> 
> No, DATA_ALIGNMENT in cris.h is not intended as an ABI
> indication, but as an optimization when emitting data.
> (This was the way to do it at the time.  Has this changed?)
> 
> The ABI is as indicated by BIGGEST_ALIGNMENT: 8 (bits; one
> byte).  Nothing is guaranteed (to the data referer) to have a
> bigger alignment - unless otherwise indicated by attribute-align.
> 
> (Unfortunately I can't change BIGGEST_ALIGNMENT to indicate that
> atomic variables require "natural alignment", or actually not to
> straddle a cache-boundary, as increasing BIGGEST_ALIGNMENT makes
> GCC change the ABI.  But that's a slightly different issue.)

Right now it is unfortunately part of ABI, which is something the patch
attempts to cure in a backwards compatible way (i.e., data will be still
alignment the way it used to be, but code will no longer assume it is that
much aligned, unless it is DATA_ABI_ALIGNMENT).
> 
> > mmixcomment mentions GETA instruction
> 
> Yep, data must be at least 32-bit-aligned so addresses can be
> formed with a GETA insn.  BIGGEST_ALIGNMENT is 64 though and
> STRICT_ALIGNMENT; natural alignment is required for proper
> interpretation as the low bits are ignored.

Then mmix would probably want to define DATA_ABI_ALIGNMENT instead of
DATA_ALIGNMENT after the patch (or both).

Jakub

Re: [PATCH] DATA_ALIGNMENT vs. DATA_ABI_ALIGNMENT (PR target/56564)

[Jakub Jelinek]

On Fri, Jun 07, 2013 at 11:14:19PM +0200, Jakub Jelinek wrote:
> > This structure would seem to do the wrong thing if DATA_ABI_ALIGNMENT is
> > defined, but DATA_ALIGNMENT isn't.  And while I realize you documented it, I
> > don't like the restriction that D_A /must/ return something larger than 
> > D_A_A.
> >  All that means is that in complex cases D_A will have to call D_A_A itself.
> 
> Yeah, I guess I can rearrange it.  The reason I wrote it that way was to
> avoid an extra function call, but that is probably not big enough overhead.

Here is the code rearranged so that DATA_ABI_ALIGNMENT is independent of
DATA_ALIGNMENT.  The rest of stuff is kept as is.

As for the commons getting bigger alignment than the ABI has for them, I'm
afraid the linker usually has no option but to warn and don't do anything.
Because if the non-common definition that is supposed to win over the common
one isn't sufficiently aligned (and it could be aligned just to the ABI
mandated boundary), that definition could be already in the middle of say
.data or other section and so the linker doesn't have the luxury of aligning
it individually.

E.g. vect_can_force_dr_alignment_p has been changed some time ago to:
  /* We cannot change alignment of common or external symbols as another
 translation unit may contain a definition with lower alignment.
 The rules of common symbol linking mean that the definition
 will override the common symbol.  The same is true for constant
 pool entries which may be shared and are not properly merged
 by LTO.  */
  if (DECL_EXTERNAL (decl)
  || DECL_COMMON (decl)
  || DECL_IN_CONSTANT_POOL (decl))
return false;
but at that point we haven't changed align_variable.  Thus perhaps we want
in align_variable handle DECL_COMMON the same way as we handle TLS with >
word alignment.

2013-06-08  Jakub Jelinek  

PR target/56564
* varasm.c (align_variable): Don't use DATA_ALIGNMENT or
CONSTANT_ALIGNMENT if !decl_binds_to_current_def_p (decl).
Use DATA_ABI_ALIGNMENT for that case instead if defined.
(get_variable_align): New function.
(get_variable_section, emit_bss, emit_common,
assemble_variable_contents, place_block_symbol): Use
get_variable_align instead of DECL_ALIGN.
(assemble_noswitch_variable): Add align argument, use it
instead of DECL_ALIGN.
(assemble_variable): Adjust caller.  Use get_variable_align
instead of DECL_ALIGN.
* config/i386/i386.h (DATA_ALIGNMENT): Adjust x86_data_alignment
caller.
(DATA_ABI_ALIGNMENT): Define.
* config/i386/i386-protos.h (x86_data_alignment): Adjust prototype.
* config/i386/i386.c (x86_data_alignment): Add opt argument.  If
opt is false, only return the psABI mandated alignment increase.
* doc/tm.texi.in (DATA_ABI_ALIGNMENT): Document.
* doc/tm.texi: Regenerated.

* gcc.target/i386/pr56564-1.c: New test.
* gcc.target/i386/pr56564-2.c: New test.
* gcc.target/i386/pr56564-3.c: New test.
* gcc.target/i386/pr56564-4.c: New test.
* gcc.target/i386/avx256-unaligned-load-4.c: Add -fno-common.
* gcc.target/i386/avx256-unaligned-store-1.c: Likewise.
* gcc.target/i386/avx256-unaligned-store-3.c: Likewise.
* gcc.target/i386/avx256-unaligned-store-4.c: Likewise.
* gcc.target/i386/vect-sizes-1.c: Likewise.
* gcc.target/i386/memcpy-1.c: Likewise.
* gcc.dg/vect/costmodel/i386/costmodel-vect-31.c (tmp): Initialize.
* gcc.dg/vect/costmodel/x86_64/costmodel-vect-31.c (tmp): Likewise.

--- gcc/varasm.c.jj 2013-06-07 13:17:17.0 +0200
+++ gcc/varasm.c2013-06-08 16:53:40.717372488 +0200
@@ -966,13 +966,80 @@ align_variable (tree decl, bool dont_out
   align = MAX_OFILE_ALIGNMENT;
 }
 
-  /* On some machines, it is good to increase alignment sometimes.  */
   if (! DECL_USER_ALIGN (decl))
 {
+#ifdef DATA_ABI_ALIGNMENT
+  unsigned int data_abi_align
+   = DATA_ABI_ALIGNMENT (TREE_TYPE (decl), align);
+  /* For backwards compatibility, don't assume the ABI alignment for
+TLS variables.  */
+  if (! DECL_THREAD_LOCAL_P (decl) || data_abi_align <= BITS_PER_WORD)
+   align = data_abi_align;
+#endif
+
+  /* On some machines, it is good to increase alignment sometimes.
+But as DECL_ALIGN is used both for actually emitting the variable
+and for code accessing the variable as guaranteed alignment, we
+can only increase the alignment if it is a performance optimization
+if the references to it must bind to the current definition.  */
+  if (decl_binds_to_current_def_p (decl))
+   {
+#ifdef DATA_ALIGNMENT
+ unsigned int data_align = DATA_ALIGNMENT (TREE_TYPE (decl), align);
+ /* Don't increase alignment too much for TLS variables - TLS space
+is too precious.  */
+ if (! DECL_THREAD

Re: PR57548 - Call to multiversioned function from global namespace

[Eric Botcazou]

> The ICE here is because of a multi-versioned function called from
> global namespace and has no caller.  This ICEs in target hook
> ix86_can_inline_p as caller is 0x0.  The following simple patch
> attached fixes this problem.
> 
> * cp/call.c (build_over_call):  Check if current_function_decl is
> NULL.
> * testsuite/g++.dg/ext/pr57548.C: New test.

ChangeLogs for cp/ must go into cp/ChangeLog without the cp/ prefix.

-- 
Eric Botcazou

Tidy up output_constructor_bitfield

[Eric Botcazou]

The main point is to simplify the interface between output_constructor and 
output_constructor_bitfield, i.e. to avoid passing the outer state from the 
former to the latter given that only one field is read and none of them are 
written to.  No functional changes whatsoever.

Bootstrapped/regtested on x86_64-suse-linux, applied on mainline as obvious.


2013-06-08  Eric Botcazou  

* varasm.c (struct oc_local_state): Reorder fields.
(output_constructor_bitfield): Replace OUTER parameter with BIT_OFFSET
and adjust accordingly.
(output_constructor): Reorder initialization code and adjust call to
output_constructor_bitfield.


-- 
Eric BotcazouIndex: varasm.c
===
--- varasm.c	(revision 199788)
+++ varasm.c	(working copy)
@@ -4470,7 +4470,7 @@ static unsigned HOST_WIDE_INT
   output_constructor (tree, unsigned HOST_WIDE_INT, unsigned int,
 		  oc_outer_state *);
 
-/* Output assembler code for constant EXP to FILE, with no label.
+/* Output assembler code for constant EXP, with no label.
This includes the pseudo-op such as ".int" or ".byte", and a newline.
Assumes output_addressed_constants has been done on EXP already.
 
@@ -4706,25 +4706,22 @@ typedef struct {
 
   /* Received arguments.  */
   tree exp; /* Constructor expression.  */
+  tree type;/* Type of constructor expression.  */
   unsigned HOST_WIDE_INT size;  /* # bytes to output - pad if necessary.  */
   unsigned int align;   /* Known initial alignment.  */
-
-  /* Constructor expression data.  */
-  tree type;   /* Expression type.  */
-  tree field;  /* Current field decl in a record.  */
-  tree min_index;  /* Lower bound if specified for an array.  */
+  tree min_index;   /* Lower bound if specified for an array.  */
 
   /* Output processing state.  */
   HOST_WIDE_INT total_bytes;  /* # bytes output so far / current position.  */
-  bool byte_buffer_in_use;/* Whether byte ...  */
-  int byte;   /* ... contains part of a bitfield byte yet to
-			 be output.  */
-
+  int byte;   /* Part of a bitfield byte yet to be output.  */
   int last_relative_index;/* Implicit or explicit index of the last
  array element output within a bitfield.  */
+  bool byte_buffer_in_use;/* Whether BYTE is in use.  */
+
   /* Current element.  */
-  tree val;/* Current element value.  */
-  tree index;  /* Current element index.  */
+  tree field;  /* Current field decl in a record.  */
+  tree val;/* Current element value.  */
+  tree index;  /* Current element index.  */
 
 } oc_local_state;
 
@@ -4846,11 +4843,12 @@ output_constructor_regular_field (oc_loc
   local->total_bytes += fieldsize;
 }
 
-/* Helper for output_constructor.  From the current LOCAL and OUTER states,
-   output an element that is a true bitfield or part of an outer one.  */
+/* Helper for output_constructor.  From the LOCAL state, output an element
+   that is a true bitfield or part of an outer one.  BIT_OFFSET is the offset
+   from the start of a possibly ongoing outer byte buffer.  */
 
 static void
-output_constructor_bitfield (oc_local_state *local, oc_outer_state *outer)
+output_constructor_bitfield (oc_local_state *local, unsigned int bit_offset)
 {
   /* Bit size of this element.  */
   HOST_WIDE_INT ebitsize
@@ -4877,7 +4875,7 @@ output_constructor_bitfield (oc_local_st
   /* Bit position of this element from the start of a possibly ongoing
  outer byte buffer.  */
   HOST_WIDE_INT byte_relative_ebitpos
-  = ((outer ? outer->bit_offset : 0) + constructor_relative_ebitpos);
+  = bit_offset + constructor_relative_ebitpos;
 
   /* From the start of a possibly ongoing outer byte buffer, offsets to
  the first bit of this element and to the first bit past the end of
@@ -4901,8 +4899,7 @@ output_constructor_bitfield (oc_local_st
   return;
 }
 
-  /* If this field does not start in this (or, next) byte,
- skip some bytes.  */
+  /* If this field does not start in this (or next) byte, skip some bytes.  */
   if (next_offset / BITS_PER_UNIT != local->total_bytes)
 {
   /* Output remnant of any bit field in previous bytes.  */
@@ -4934,13 +4931,12 @@ output_constructor_bitfield (oc_local_st
  pending data, then retrieve the new pending data afterwards.  */
   if (TREE_CODE (local->val) == CONSTRUCTOR)
 {
-  oc_outer_state output_state;
-
-  output_state.bit_offset = next_offset % BITS_PER_UNIT;
-  output_state.byte = local->byte;
+  oc_outer_state temp_state;
+  temp_state.bit_offset = next_offset % BITS_PER_UNIT;
+  temp_state.byte = local->byte;
   local->total_bytes
-	  += output_constructor (local->val, 0, 0, &output_state);
-  local->byte = output_state.byte;
+	  += output_constructor (local->val, 0, 0, &temp_state);
+  local->byte = temp_state.byte;

Re: [libstdc++-v3][C++14] Implement N3654 - Quoted Strings

[Jonathan Wakely]

On 6 June 2013 15:55, Ed Smith-Rowland wrote:
> On 06/05/2013 04:01 PM, Jonathan Wakely wrote:
>>
>>
>> _Quoted_string appears to do two copies of the string, one for the
>> constructor argument and one for the member variable, do they
>> definitely get elided?
>
> I looks that way.  But all used of the template parm String are either
> references or pointers so these operations should be efficient.

Ahh, I didn't notice that, sorry.

Re: [libstdc++-v3][C++14] Implement N3654 - Quoted Strings

[Jonathan Wakely]

On 8 June 2013 04:44, Ed Smith-Rowland wrote:
>
> OK, I added a static_assert to check that _String is only reference or
> pointer.
> I also added a tests that check the case where _String is 'const
> basic_string<>&'.
>
> Built and tested on x86_64-linux.
>
> OK?

This is OK to commit to trunk. Thanks, Ed!

[patch] N3545 change to std::integral_constant

[Jonathan Wakely]

Another C++14 feature.

* include/std/type-traits (integral_constant::operator()): Implement
N3545.
* testsuite/20_util/integral_constant/call_operator.cc: New.
* testsuite/20_util/declval/requirements/1_neg.cc: Adjust dg-error
line numbers.
* testsuite/20_util/make_signed/requirements/typedefs_neg.cc:
Likewise.
* testsuite/20_util/make_unsigned/requirements/typedefs_neg.cc:
Likewise.

Tested x86_64-linux, committed to trunk.
commit e3b2b5a9475b7146469e6cb4c35a140c7506df63
Author: Jonathan Wakely 
Date:   Sat Jun 8 16:45:53 2013 +0100

* include/std/type-traits (integral_constant::operator()): Implement
N3545.
* testsuite/20_util/integral_constant/call_operator.cc: New.
* testsuite/20_util/declval/requirements/1_neg.cc: Adjust dg-error
line numbers.
* testsuite/20_util/make_signed/requirements/typedefs_neg.cc:
Likewise.
* testsuite/20_util/make_unsigned/requirements/typedefs_neg.cc:
Likewise.

diff --git a/libstdc++-v3/include/std/type_traits 
b/libstdc++-v3/include/std/type_traits
index a0a8327..99d0a5b 100644
--- a/libstdc++-v3/include/std/type_traits
+++ b/libstdc++-v3/include/std/type_traits
@@ -60,6 +60,9 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   typedef _Tp   value_type;
   typedef integral_constant<_Tp, __v>   type;
   constexpr operator value_type() const { return value; }
+#if __cplusplus > 201103L
+  constexpr value_type operator()() const { return value; }
+#endif
 };
   
   template
diff --git a/libstdc++-v3/testsuite/20_util/declval/requirements/1_neg.cc 
b/libstdc++-v3/testsuite/20_util/declval/requirements/1_neg.cc
index ad82190..5b5a8eb 100644
--- a/libstdc++-v3/testsuite/20_util/declval/requirements/1_neg.cc
+++ b/libstdc++-v3/testsuite/20_util/declval/requirements/1_neg.cc
@@ -19,7 +19,7 @@
 // with this library; see the file COPYING3.  If not see
 // .
 
-// { dg-error "static assertion failed" "" { target *-*-* } 1859 }
+// { dg-error "static assertion failed" "" { target *-*-* } 1862 }
 
 #include 
 
diff --git a/libstdc++-v3/testsuite/20_util/integral_constant/call_operator.cc 
b/libstdc++-v3/testsuite/20_util/integral_constant/call_operator.cc
new file mode 100644
index 000..c5b0385
--- /dev/null
+++ b/libstdc++-v3/testsuite/20_util/integral_constant/call_operator.cc
@@ -0,0 +1,36 @@
+// { dg-do compile }
+// { dg-options "-std=gnu++1y" }
+//
+// Copyright (C) 2013 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library.  This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+//
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+// GNU General Public License for more details.
+//
+// You should have received a copy of the GNU General Public License along
+// with this library; see the file COPYING3.  If not see
+// .
+
+#include 
+#include  //testsuite_hooks.h>
+
+typedef std::integral_constant   ic_one;
+typedef std::integral_constant   ic_zero;
+typedef std::integral_constant  ic_minus_one;
+
+typedef std::integral_constant   ic_true;
+typedef std::integral_constant  ic_false;
+
+static_assert( ic_one{}() == 1, "1" );
+static_assert( ic_zero{}() == 0, "0" );
+static_assert( ic_minus_one{}() == -1, "-1" );
+
+static_assert( ic_true{}() == true, "true" );
+static_assert( ic_false{}() == false, "false" );
diff --git 
a/libstdc++-v3/testsuite/20_util/make_signed/requirements/typedefs_neg.cc 
b/libstdc++-v3/testsuite/20_util/make_signed/requirements/typedefs_neg.cc
index 077e327..afb7336 100644
--- a/libstdc++-v3/testsuite/20_util/make_signed/requirements/typedefs_neg.cc
+++ b/libstdc++-v3/testsuite/20_util/make_signed/requirements/typedefs_neg.cc
@@ -48,5 +48,5 @@ void test01()
 // { dg-error "required from here" "" { target *-*-* } 40 }
 // { dg-error "required from here" "" { target *-*-* } 42 }
 
-// { dg-error "invalid use of incomplete type" "" { target *-*-* } 1601 }
-// { dg-error "declaration of" "" { target *-*-* } 1565 }
+// { dg-error "invalid use of incomplete type" "" { target *-*-* } 1604 }
+// { dg-error "declaration of" "" { target *-*-* } 1568 }
diff --git 
a/libstdc++-v3/testsuite/20_util/make_unsigned/requirements/typedefs_neg.cc 
b/libstdc++-v3/testsuite/20_util/make_unsigned/requirements/typedefs_neg.cc
index 2bc1cbb..ba5f582 100644
--- a/libstdc++-v3/testsuite/20_util/make_unsigned/requirements/typedefs_neg.cc
+++ b/libstdc++-v3/testsuite/20_util/make_unsigned/requirements/typedefs_neg.cc
@@ -48,5 +48,5 @@ void test01()
 // { dg-error "required from

[patch] C++14: N3671 Making non-modifying sequence operations more robust

[Jonathan Wakely]

Another C++14 feature.

* include/bits/stl_algo.h (is_permutation): Add overloads from N3671.
* include/bits/stl_algobase.h (equal, mismatch): Likewise.
* testsuite/25_algorithms/equal/1.cc: Remove duplicate test case.
* testsuite/25_algorithms/equal/2.cc: New.
* testsuite/25_algorithms/equal/check_type2.cc: New.
* testsuite/25_algorithms/is_permutationqual/2.cc: New.
* testsuite/25_algorithms/is_permutationqual/check_type2.cc: New.
* testsuite/25_algorithms/mismatch/2.cc: New.
* testsuite/25_algorithms/mismatch/check_type2.cc: New.
* testsuite/util/testsuite_iterators.h: Fix spelling.

Tested x86_64-linux, committed to trunk.
commit d38ec2374fd13499d9aa3d6e504193edb2cbf703
Author: Jonathan Wakely 
Date:   Sat Jun 8 16:46:23 2013 +0100

* include/bits/stl_algo.h (is_permutation): Add overloads from N3671.
* include/bits/stl_algobase.h (equal, mismatch): Likewise.
* testsuite/25_algorithms/equal/1.cc: Remove duplicate test case.
* testsuite/25_algorithms/equal/2.cc: New.
* testsuite/25_algorithms/equal/check_type2.cc: New.
* testsuite/25_algorithms/is_permutationqual/2.cc: New.
* testsuite/25_algorithms/is_permutationqual/check_type2.cc: New.
* testsuite/25_algorithms/mismatch/2.cc: New.
* testsuite/25_algorithms/mismatch/check_type2.cc: New.
* testsuite/util/testsuite_iterators.h: Fix spelling.

diff --git a/libstdc++-v3/include/bits/stl_algo.h 
b/libstdc++-v3/include/bits/stl_algo.h
index 873005b..e61f22b 100644
--- a/libstdc++-v3/include/bits/stl_algo.h
+++ b/libstdc++-v3/include/bits/stl_algo.h
@@ -4371,6 +4371,140 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   return true;
 }
 
+#if __cplusplus > 201103L
+  /**
+   *  @brief  Checks whether a permutaion of the second sequence is equal
+   *  to the first sequence.
+   *  @ingroup non_mutating_algorithms
+   *  @param  __first1  Start of first range.
+   *  @param  __last1   End of first range.
+   *  @param  __first2  Start of second range.
+   *  @param  __last2   End of first range.
+   *  @return true if there exists a permutation of the elements in the range
+   *  [__first2, __last2), beginning with ForwardIterator2 begin,
+   *  such that equal(__first1, __last1, begin) returns true;
+   *  otherwise, returns false.
+  */
+  template
+bool
+is_permutation(_ForwardIterator1 __first1, _ForwardIterator1 __last1,
+  _ForwardIterator2 __first2, _ForwardIterator2 __last2)
+{
+  using _Cat1
+   = typename iterator_traits<_ForwardIterator1>::iterator_category;
+  using _Cat2
+   = typename iterator_traits<_ForwardIterator2>::iterator_category;
+  using _It1_is_RA = is_same<_Cat1, random_access_iterator_tag>;
+  using _It2_is_RA = is_same<_Cat2, random_access_iterator_tag>;
+  if (_It1_is_RA() && _It1_is_RA())
+   {
+ auto __d1 = std::distance(__first1, __last1);
+ auto __d2 = std::distance(__first2, __last2);
+ if (__d1 != __d2)
+   return false;
+   }
+
+  // Efficiently compare identical prefixes:  O(N) if sequences
+  // have the same elements in the same order.
+  for (; __first1 != __last1 && __first2 != __last2; ++__first1, 
++__first2)
+   if (!(*__first1 == *__first2))
+ break;
+
+  if (__first1 == __last1 && __first2 == __last2)
+   return true;
+
+  if (std::distance(__first1, __last1) != std::distance(__first2, __last2))
+   return false;
+
+  for (auto __scan = __first1; __scan != __last1; ++__scan)
+   {
+ if (__scan != _GLIBCXX_STD_A::find(__first1, __scan, *__scan))
+   continue; // We've seen this one before.
+
+ auto __matches = std::count(__first2, __last2, *__scan);
+ if (0 == __matches
+ || std::count(__scan, __last1, *__scan) != __matches)
+   return false;
+   }
+  return true;
+}
+
+  /**
+   *  @brief  Checks whether a permutation of the second sequence is equal
+   *  to the first sequence.
+   *  @ingroup non_mutating_algorithms
+   *  @param  __first1  Start of first range.
+   *  @param  __last1   End of first range.
+   *  @param  __first2  Start of second range.
+   *  @param  __last2   End of first range.
+   *  @param  __predA binary predicate.
+   *  @return true if there exists a permutation of the elements in the range
+   *  [__first2, __last2), beginning with ForwardIterator2 begin,
+   *  such that equal(__first1, __last1, __begin, __pred) returns true;
+   *  otherwise, returns false.
+  */
+  template
+bool
+is_permutation(_ForwardIterator1 __first1, _ForwardIterator1 __last1,
+  _ForwardIterator2 __first2, _ForwardIterator2 __last2,
+  _BinaryPredicate __pred)
+{
+  using _Cat1
+   = typename iterator_traits<_ForwardIterator1>::iterato

Re: Clean up after standard literals patch.

[Jonathan Wakely]

On 7 June 2013 15:45, Ed Smith-Rowland wrote:
> Greetings,
>
> Jonathan had asked if I could make some simplifications to the organization
> of C++ versioning macros and namespaces in my standard literals patch.  I
> plum forgot to do it before I put in the patch.
>
> Also, I noticed I had picked up some garbage comments in the test cases.
>
> This patch cleans all that up.
>
> Built and tested on x86_64-linux.

This is OK for trunk, thanks.

Re: [RFC] Implement Undefined Behavior Sanitizer (take 2)

[Marek Polacek]

Thanks for the reviews, here is another version.  I haven't touched
the division by zero instrumentation, but the shift instrumentation is
revamped; what it should instrument now is, as Jakub wrote:
1) if ((unsigned) y > precm1) ub
plus for signed x << y:
2) for C99/C11 if ((unsigned) x >> (precm1 - y)) ub
3) for C++11/C++14 if (x < 0 || ((unsigned) x >> (precm1 - y)) > 1) ub
Is there anything left to do for shifts?

The c-ubsan.c now resides in c-family/.
I also fixed the ICE with long/long long type (the resulting type of
a RSHIFT_EXPR should really be that of the left operand).
But I have no clue how it behaves with e.g. constexpr specifier.

When/if this is ok enough, I think we could put this on a branch,
together with Jakub's patches from
http://gcc.gnu.org/ml/gcc-patches/2013-06/msg00291.html

The next part will be to construct arguments for the ubsan library;
hopefully I can (mis)use parts of asan.c code.  Then the command-line
parsing (parse options into the flag_sanitize bitmask).  And after this
is done, I'd say we should add a testsuite, ideally something in
c-c++-common/ and something in g++.dg/ (templates and other stuff).

Regtested/bootstrapped on x86_64-linux.

2013-06-07  Marek Polacek  

* Makefile.in: Add ubsan.c.
* common.opt: Add -fsanitize=undefined option.
* doc/invoke.texi: Document the new flag.
* sanitizer.def (DEF_SANITIZER_BUILTIN): Define.
* builtin-attrs.def (ATTR_COLD): Define.
* asan.c (initialize_sanitizer_builtins): Build
BT_FN_VOID_PTR_PTR_PTR.
* builtins.def (BUILT_IN_UBSAN_HANDLE_DIVREM_OVERFLOW,
BUILT_IN_UBSAN_HANDLE_SHIFT_OUT_OF_BOUNDS): Define.

c-family/
* c-ubsan.c: New file.
* c-ubsan.h: New file.

cp/
* typeck.c (cp_build_binary_op): Add division by zero and shift
instrumentation.

c/
* c-typeck.c (build_binary_op): Add division by zero and shift
instrumentation.

--- gcc/c-family/c-ubsan.c.mp   2013-06-07 22:58:18.084990548 +0200
+++ gcc/c-family/c-ubsan.c  2013-06-07 22:29:34.677588474 +0200
@@ -0,0 +1,120 @@
+/* UndefinedBehaviorSanitizer, undefined behavior detector.
+   Copyright (C) 2013 Free Software Foundation, Inc.
+   Contributed by Marek Polacek 
+
+This file is part of GCC.
+
+GCC 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.
+
+GCC 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 GCC; see the file COPYING3.  If not see
+.  */
+
+#include "config.h"
+#include "system.h"
+#include "coretypes.h"
+#include "tree.h"
+#include "c-family/c-common.h"
+#include "c-family/c-ubsan.h"
+
+/* Instrument division by zero and INT_MIN / -1.  */
+
+tree
+ubsan_instrument_division (location_t loc, enum tree_code code,
+  tree op0, tree op1)
+{
+  tree t, tt;
+  tree orig = build2 (code, TREE_TYPE (op0), op0, op1);
+
+  if (TREE_CODE (TREE_TYPE (op0)) != INTEGER_TYPE
+  || TREE_CODE (TREE_TYPE (op1)) != INTEGER_TYPE)
+return orig;
+
+  /* If we *know* that the divisor is not -1 or 0, we don't have to
+ instrument this expression.
+ ??? We could use decl_constant_value to cover up more cases.  */
+  if (TREE_CODE (op1) == INTEGER_CST
+  && integer_nonzerop (op1)
+  && !integer_minus_onep (op1))
+return orig;
+
+  tt = fold_build2 (EQ_EXPR, boolean_type_node, op1,
+   integer_minus_one_node);
+  t = fold_build2 (EQ_EXPR, boolean_type_node, op0,
+  TYPE_MIN_VALUE (TREE_TYPE (op0)));
+  t = fold_build2 (TRUTH_AND_EXPR, boolean_type_node, t, tt);
+  tt = build2 (EQ_EXPR, boolean_type_node,
+  op1, integer_zero_node);
+  t = fold_build2 (TRUTH_OR_EXPR, boolean_type_node, tt, t);
+  tt = builtin_decl_explicit (BUILT_IN_UBSAN_HANDLE_DIVREM_OVERFLOW);
+  tt = build_call_expr_loc (loc, tt, 0);
+  t = fold_build3 (COND_EXPR, void_type_node, t, tt, void_zero_node);
+  t = fold_build2 (COMPOUND_EXPR, TREE_TYPE (orig), t, orig);
+
+  return t;
+}
+
+/* Instrument left and right shifts.  */
+
+tree
+ubsan_instrument_shift (location_t loc, enum tree_code code,
+   tree op0, tree op1)
+{
+  tree t, tt = NULL_TREE;
+  tree orig = build2 (code, TREE_TYPE (op0), op0, op1);
+  tree uprecm1 = build_int_cst (unsigned_type_for (TREE_TYPE (op1)),
+  TYPE_PRECISION (TREE_TYPE (op0)) - 1);
+  tree precm1 = build_int_cst (TREE_TYPE (op1),
+  TYPE_PRECISION (TREE_TYPE (op0)) - 1);
+
+  t = fold_convert_loc (loc, unsigned_type_for (TREE_TYPE (op1)), op1);
+  t =

[patch] Add noexcept to allocator_traits::max_size()

[Jonathan Wakely]

* include/bits/alloc_traits.h (allocator_traits::max_size()): LWG
2162: Add noexcept.

Tested x86_64-linux, committed to trunk
commit 10087221105c7f621a06137189c16886213c68b2
Author: Jonathan Wakely 
Date:   Sat Jun 8 18:31:18 2013 +0100

* include/bits/alloc_traits.h (allocator_traits::max_size()): LWG
2162: Add noexcept.

diff --git a/libstdc++-v3/include/bits/alloc_traits.h 
b/libstdc++-v3/include/bits/alloc_traits.h
index 33ea145..e68d317 100644
--- a/libstdc++-v3/include/bits/alloc_traits.h
+++ b/libstdc++-v3/include/bits/alloc_traits.h
@@ -412,7 +412,7 @@ _GLIBCXX_ALLOC_TR_NESTED_TYPE(propagate_on_container_swap,
*  Returns @c __a.max_size() if that expression is well-formed,
*  otherwise returns @c numeric_limits::max()
   */
-  static size_type max_size(const _Alloc& __a)
+  static size_type max_size(const _Alloc& __a) noexcept
   { return _S_max_size(__a); }
 
   /**

Re: [RFC] Implement Undefined Behavior Sanitizer (take 2)

[Marc Glisse]

Hello,

thanks for working on this. Just a few questions inline:

On Sat, 8 Jun 2013, Marek Polacek wrote:


+/* Instrument division by zero and INT_MIN / -1.  */
+
+tree
+ubsan_instrument_division (location_t loc, enum tree_code code,
+  tree op0, tree op1)
+{
+  tree t, tt;
+  tree orig = build2 (code, TREE_TYPE (op0), op0, op1);
+
+  if (TREE_CODE (TREE_TYPE (op0)) != INTEGER_TYPE
+  || TREE_CODE (TREE_TYPE (op1)) != INTEGER_TYPE)
+return orig;


Type promotion means that INTEGRAL_TYPE_P wouldn't catch anything this 
doesn't?



+  /* If we *know* that the divisor is not -1 or 0, we don't have to
+ instrument this expression.
+ ??? We could use decl_constant_value to cover up more cases.  */
+  if (TREE_CODE (op1) == INTEGER_CST
+  && integer_nonzerop (op1)
+  && !integer_minus_onep (op1))
+return orig;


This is just to speed up compilation a bit, I assume, since fold would 
remove the instrumentation anyway.



+  tt = fold_build2 (EQ_EXPR, boolean_type_node, op1,
+   integer_minus_one_node);


Don't we usually try to have both operands of a comparison of the same 
type?



+  t = fold_build2 (EQ_EXPR, boolean_type_node, op0,
+  TYPE_MIN_VALUE (TREE_TYPE (op0)));


I didn't see where this test was restricted to the signed case (0u/-1 
is well defined)?



+  t = fold_build2 (TRUTH_AND_EXPR, boolean_type_node, t, tt);
+  tt = build2 (EQ_EXPR, boolean_type_node,
+  op1, integer_zero_node);


Why not fold this one?


+  t = fold_build2 (TRUTH_OR_EXPR, boolean_type_node, tt, t);
+  tt = builtin_decl_explicit (BUILT_IN_UBSAN_HANDLE_DIVREM_OVERFLOW);
+  tt = build_call_expr_loc (loc, tt, 0);
+  t = fold_build3 (COND_EXPR, void_type_node, t, tt, void_zero_node);
+  t = fold_build2 (COMPOUND_EXPR, TREE_TYPE (orig), t, orig);
+
+  return t;
+}
+
+/* Instrument left and right shifts.  */
+
+tree
+ubsan_instrument_shift (location_t loc, enum tree_code code,
+   tree op0, tree op1)
+{
+  tree t, tt = NULL_TREE;
+  tree orig = build2 (code, TREE_TYPE (op0), op0, op1);
+  tree uprecm1 = build_int_cst (unsigned_type_for (TREE_TYPE (op1)),
+  TYPE_PRECISION (TREE_TYPE (op0)) - 1);
+  tree precm1 = build_int_cst (TREE_TYPE (op1),
+  TYPE_PRECISION (TREE_TYPE (op0)) - 1);


(if we later want to extend this to vector-scalar shifts, 
element_precision will be better than TYPE_PRECISION)


Name unsigned_type_for (TREE_TYPE (op1)) and TYPE_PRECISION (TREE_TYPE 
(op0)) that are used several times?



+  t = fold_convert_loc (loc, unsigned_type_for (TREE_TYPE (op1)), op1);
+  t = fold_build2 (GT_EXPR, boolean_type_node, t, uprecm1);

[...]

--- gcc/cp/typeck.c.mp  2013-06-07 23:01:16.779536165 +0200
+++ gcc/cp/typeck.c 2013-06-07 23:04:47.625161351 +0200
@@ -37,6 +37,7 @@ along with GCC; see the file COPYING3.
#include "convert.h"
#include "c-family/c-common.h"
#include "c-family/c-objc.h"
+#include "c-family/c-ubsan.h"
#include "params.h"

static tree pfn_from_ptrmemfunc (tree);
@@ -3891,6 +3892,12 @@ cp_build_binary_op (location_t location,
  op0 = orig_op0;
  op1 = orig_op1;

+  /* Remember whether we're doing / or %.  */
+  bool doing_div_or_mod = false;
+
+  /* Remember whether we're doing << or >>.  */
+  bool doing_shift = false;
+
  if (code == TRUTH_AND_EXPR || code == TRUTH_ANDIF_EXPR
  || code == TRUTH_OR_EXPR || code == TRUTH_ORIF_EXPR
  || code == TRUTH_XOR_EXPR)
@@ -4070,8 +4077,15 @@ cp_build_binary_op (location_t location,
{
  enum tree_code tcode0 = code0, tcode1 = code1;
  tree cop1 = fold_non_dependent_expr_sfinae (op1, tf_none);
+ cop1 = maybe_constant_value (cop1);

- warn_for_div_by_zero (location, maybe_constant_value (cop1));
+ if (!processing_template_decl && tcode0 == INTEGER_TYPE
+ && (TREE_CODE (cop1) != INTEGER_CST
+ || integer_zerop (cop1)
+ || integer_minus_onep (cop1)))
+   doing_div_or_mod = true;


Aren't you already doing this test in ubsan_instrument_division?


--
Marc Glisse

Re: [RFC] Implement Undefined Behavior Sanitizer (take 2)

[Jakub Jelinek]

On Sat, Jun 08, 2013 at 07:48:27PM +0200, Marc Glisse wrote:
> >+/* Instrument division by zero and INT_MIN / -1.  */
> >+
> >+tree
> >+ubsan_instrument_division (location_t loc, enum tree_code code,
> >+   tree op0, tree op1)
> >+{
> >+  tree t, tt;
> >+  tree orig = build2 (code, TREE_TYPE (op0), op0, op1);
> >+
> >+  if (TREE_CODE (TREE_TYPE (op0)) != INTEGER_TYPE
> >+  || TREE_CODE (TREE_TYPE (op1)) != INTEGER_TYPE)
> >+return orig;
> 
> Type promotion means that INTEGRAL_TYPE_P wouldn't catch anything
> this doesn't?

This is after type promotion, and e.g. cp_build_binary_op already checks
for == INTEGER_TYPE, so I think enums/bools won't show up here.

> >+  /* If we *know* that the divisor is not -1 or 0, we don't have to
> >+ instrument this expression.
> >+ ??? We could use decl_constant_value to cover up more cases.  */
> >+  if (TREE_CODE (op1) == INTEGER_CST
> >+  && integer_nonzerop (op1)
> >+  && !integer_minus_onep (op1))
> >+return orig;
> 
> This is just to speed up compilation a bit, I assume, since fold
> would remove the instrumentation anyway.

Yeah.
> 
> >+  tt = fold_build2 (EQ_EXPR, boolean_type_node, op1,
> >+integer_minus_one_node);
> 
> Don't we usually try to have both operands of a comparison of the
> same type?

Not just usually, it really has to be build_int_cst (TREE_TYPE (op1), -1).
And, more importantly, at least in cp_build_binary_op the calls need to be
moved further down in the function, at least after if (processing_template_decl)
but e.g. for division the trouble is that shorten_binary_op is performed
before actually promoting one or both operand to the result_type.  I guess
for the diagnostics which prints the types, it would be best to diagnose
using the promoted types and result_type constructed out of that, but
without shorten_binary_op etc., that is just an optimization I think.
So, maybe record the original result_type before shortening, and if
shortening changed that, convert the arguments for the instrumentation only
to the original result_type, otherwise use the conversion done normally.
For shifts this isn't a big deal, because they always use result_type of the
first operand after promotion, and the ubsan handler wants to see two types
there (the question is, does it want for the shift amount look for the
original shift count type, or the one converted to int)?

Also, perhaps it would be better if these ubsan_instrument* functions
didn't return a COMPOUND_EXPR, but instead just the lhs of that (i.e. the
actual instrumentation) and let the caller set some var to that and if that
var is non-NULL, after building the binary operation build a COMPOUND_EXPR
with lhs being the instrumentation and rhs the binary operation itself.

> 
> >+  t = fold_build2 (EQ_EXPR, boolean_type_node, op0,
> >+   TYPE_MIN_VALUE (TREE_TYPE (op0)));
> 
> I didn't see where this test was restricted to the signed case
> (0u/-1 is well defined)?
> 
> >+  t = fold_build2 (TRUTH_AND_EXPR, boolean_type_node, t, tt);
> >+  tt = build2 (EQ_EXPR, boolean_type_node,
> >+   op1, integer_zero_node);
> 
> Why not fold this one?

Sure.  And yeah, the INT_MIN/-1 checking needs to be done for signed types
only.

> >+tree
> >+ubsan_instrument_shift (location_t loc, enum tree_code code,
> >+tree op0, tree op1)
> >+{
> >+  tree t, tt = NULL_TREE;
> >+  tree orig = build2 (code, TREE_TYPE (op0), op0, op1);
> >+  tree uprecm1 = build_int_cst (unsigned_type_for (TREE_TYPE (op1)),
> >+   TYPE_PRECISION (TREE_TYPE (op0)) - 1);
> >+  tree precm1 = build_int_cst (TREE_TYPE (op1),
> >+   TYPE_PRECISION (TREE_TYPE (op0)) - 1);
> 
> (if we later want to extend this to vector-scalar shifts,
> element_precision will be better than TYPE_PRECISION)
> 
> Name unsigned_type_for (TREE_TYPE (op1)) and TYPE_PRECISION
> (TREE_TYPE (op0)) that are used several times?

Yes.  Note that for vector-scalar shifts (and even vector-vector) we'd need
library support to handle that.

Jakub

patch to fix PR57559 for s390

[Vladimir Makarov]

The following patch fixes

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

The problem was in systematic discouraging reload symbol address in 
memory.  The patch actually reverts a fix for a x86/x86-64 PR for 
-fpie.  The patch implements another solution for this problem (see 
changes for lra_emit_add).


The patch was successfully bootstrapped and tested on x86/x86-64 and s390.

Committed as rev. 199859.

2013-06-08  Vladimir Makarov  

PR rtl-optimization/57559
* lra-constraints.c (process_alt_operands): Don't discourage
memory with known offset for offsetable memory constraint.
* lra.c (lra_emit_add): Exchange y and z for 2-op add insn.

2013-06-08  Vladimir Makarov  

PR rtl-optimization/57559
* gcc.target/s390/pr57559.c : Newtest.

Index: lra-constraints.c
===
--- lra-constraints.c   (revision 199762)
+++ lra-constraints.c   (working copy)
@@ -1997,15 +1997,8 @@ process_alt_operands (int only_alternati
  (op, this_alternative) == NO_REGS
reject += LRA_MAX_REJECT;
 
- if (MEM_P (op) && offmemok)
-   {
- /* If we know offset and this non-offsetable memory,
-something wrong with this memory and it is better
-to try other memory possibilities.  */
- if (MEM_OFFSET_KNOWN_P (op))
-   reject += LRA_MAX_REJECT;
-   }
- else if (! (const_to_mem && constmemok))
+ if (! (MEM_P (op) && offmemok)
+ && ! (const_to_mem && constmemok))
{
  /* We prefer to reload pseudos over reloading other
 things, since such reloads may be able to be
Index: lra.c
===
--- lra.c   (revision 199753)
+++ lra.c   (working copy)
@@ -306,11 +306,11 @@ lra_emit_add (rtx x, rtx y, rtx z)
  || (disp != NULL_RTX && ! CONSTANT_P (disp))
  || (scale != NULL_RTX && ! CONSTANT_P (scale)))
{
- /* Its is not an address generation.  Probably we have no 3 op
+ /* It is not an address generation.   Probably we have no 3 op
 add.  Last chance is to use 2-op add insn.  */
  lra_assert (x != y && x != z);
- emit_move_insn (x, z);
- insn = gen_add2_insn (x, y);
+ emit_move_insn (x, y);
+ insn = gen_add2_insn (x, z);
  emit_insn (insn);
}
   else
Index: testsuite/gcc.target/s390/pr57559.c
===
--- testsuite/gcc.target/s390/pr57559.c (revision 0)
+++ testsuite/gcc.target/s390/pr57559.c (working copy)
@@ -0,0 +1,24 @@
+/* PR rtl-optimization/57559  */
+
+/* { dg-do compile } */
+/* { dg-options "-march=z10 -m64 -mzarch  -O1" } */
+
+typedef int int32_t;
+typedef unsigned char uint8_t;
+typedef unsigned int uint32_t;
+struct _IO_marker
+{
+};
+static const int32_t mfcone = 1;
+static const uint8_t *mfctop = (const uint8_t *) &mfcone;
+int32_t
+decContextTestEndian (uint8_t quiet)
+{
+  int32_t res = 0;
+  uint32_t dle = (uint32_t) 0;
+  if (*(int *) 10 != 0)
+{
+  res = (int32_t) * mfctop - dle;
+}
+  return res;
+}

Re: RFA: Switching LRA on for s390

[Vladimir Makarov]

On 13-06-07 11:12 AM, Vladimir Makarov wrote:

On 13-06-07 10:57 AM, Andreas Krebbel wrote:

I've applied the attached patch. This helps me getting a little
further when bootstrapping with lra and --with-arch=zEC12.

2013-06-07  Andreas Krebbel  

* config/s390/s390.md (cpu_facility): Add cpu_zarch.
("*movmem_short", "*clrmem_short", "*cmpmem_short): Use cpu_zarch
for last alternative in the cpu_facility attribute.

---
  gcc/config/s390/s390.md |   13 !
  1 file changed, 4 insertions(+), 9 modifications(!)


Thanks, Andreas.  I am not a specialist in 390 architecture.  You are 
the expert.  I'll check the bootstrap with this option too on a 
machine available for me.  I've checked the bootstrap without any 
-with-arch option before submitting the patch for approval. If I find 
some problems, I'll work on them too.  I'll work on PR57599 you just 
reported too.


I've fixed PR57599.  Unfortunately, I can not bootstrap with 
--with-arch=zEC12 as a machine available for me does not support this 
subtarget.

Re: PR57548 - Call to multiversioned function from global namespace

[David Edelsohn]

FYI, gcc/cp has it's own ChangeLog file.  Yes, it is confusing that
some directories have their own and others do not.

- David

[committed] TILEPro atomics.[c,h] fixes

[Walter Lee]

This patch cleans up a few issues with atomic.h and atomic.c: remove a
few glibc include files to facilitate bootstrapping, but include
config.h in atomic.c.  Add __extension__ where appropriate, and
replace int64_t with long long.

* config/tilepro/atomic.h: Don't include stdint.h or features.h.
Replace int64_t with long long.  Add __extension__ where
appropriate.
* config/tilepro/atomic.c: Include config.h.

--- trunk/libgcc/config/tilepro/atomic.h2013/02/04 19:06:20 195731
+++ trunk/libgcc/config/tilepro/atomic.h2013/06/08 16:26:32 199855
@@ -92,8 +92,6 @@
compare-and-exchange routine, so may be potentially less efficient.  */
 #endif
 
-#include 
-#include 
 #ifdef __tilegx__
 #include 
 #else
@@ -122,9 +120,9 @@
 
 /* 64-bit integer compare-and-exchange.  */
 static __inline __attribute__ ((always_inline))
- int64_t arch_atomic_val_compare_and_exchange_8 (volatile int64_t * mem,
-int64_t oldval,
-int64_t newval)
+ long long arch_atomic_val_compare_and_exchange_8 (volatile long long
+  *mem, long long oldval,
+  long long newval)
 {
 #ifdef __tilegx__
   __insn_mtspr (SPR_CMPEXCH_VALUE, oldval);
@@ -139,7 +137,7 @@
"R04" (newval_lo), "R05" (newval_hi),
"m" (*mem):"r20", "r21", "r22", "r23", "r24", "r25",
"r26", "r27", "r28", "r29", "memory");
-  return ((uint64_t) result_hi) << 32 | result_lo;
+  return ((long long) result_hi) << 32 | result_lo;
 #endif
 }
 
@@ -150,11 +148,11 @@
 
 
 #define arch_atomic_val_compare_and_exchange(mem, o, n) \
-  ({\
+  __extension__ ({  \
 (__typeof(*(mem)))(__typeof(*(mem)-*(mem))) \
   ((sizeof(*(mem)) == 8) ?  \
arch_atomic_val_compare_and_exchange_8(  \
- (volatile int64_t*)(mem), (__typeof((o)-(o)))(o),  \
+ (volatile long long*)(mem), (__typeof((o)-(o)))(o),\
  (__typeof((n)-(n)))(n)) :  \
(sizeof(*(mem)) == 4) ?  \
arch_atomic_val_compare_and_exchange_4(  \
@@ -164,7 +162,7 @@
   })
 
 #define arch_atomic_bool_compare_and_exchange(mem, o, n)\
-  ({\
+  __extension__ ({  \
 __typeof(o) __o = (o);  \
 __builtin_expect(   \
   __o == arch_atomic_val_compare_and_exchange((mem), __o, (n)), 1); \
@@ -174,7 +172,7 @@
 /* Loop with compare_and_exchange until we guess the correct value.
Normally "expr" will be an expression using __old and __value.  */
 #define __arch_atomic_update_cmpxchg(mem, value, expr)  \
-  ({\
+  __extension__ ({  \
 __typeof(value) __value = (value);  \
 __typeof(*(mem)) *__mem = (mem), __old = *__mem, __guess;   \
 do {\
@@ -189,12 +187,14 @@
 /* Generic atomic op with 8- or 4-byte variant.
The _mask, _addend, and _expr arguments are ignored on tilegx.  */
 #define __arch_atomic_update(mem, value, op, _mask, _addend, _expr) \
-  ({\
+  __extension__ ({  \
 ((__typeof(*(mem))) \
  ((sizeof(*(mem)) == 8) ? (__typeof(*(mem)-*(mem)))__insn_##op( \
-(void *)(mem), (int64_t)(__typeof((value)-(value)))(value)) :   \
+(volatile void *)(mem), \
+(long long)(__typeof((value)-(value)))(value)) :\
   (sizeof(*(mem)) == 4) ? (int)__insn_##op##4(  \
-(void *)(mem), (int32_t)(__typeof((value)-(value)))(value)) :   \
+(volatile void *)(mem), \
+(int)(__typeof((value)-(value)))(value)) :  \
   __arch_atomic_error_bad_argument_size()));\
   })
 
@@ -224,7 +224,7 @@
 /* Generic atomic op with 8- or 4-byte variant.
The _op argument is ignored on tilepro.  */
 #define __arch_atomic_update(mem, value, _op, mask, addend, expr)   \
-  ({

[PATCH] Fix for PR c/57563

[Iyer, Balaji V]

Hello Everyone,
Attached, please find a patch that will fix the bug reported in PR 
57563. There are a couple issues that went wrong. First, in the test case, we 
have a double multiplied to a double. When -std=c99 flag is used, they get 
converted to long double. The way to fix this is to add a type cast to the 
array notation to the same type as identity variable and thus they will all be 
double. 
The second issue, was that a sec_reduce_mutating function takes in the 
address of a "mutating variable" (i.e. the variable that will hold the result), 
the array notation and a function pointer. For example, for the following code:

int a[10], x = 0;
void function_name (int *p, int r);
__sec_reduce_mutating (&x,  a[0:10], function_name);


__sec_reduce_mutating should be converted to:

for (ii =0; ii < 10; ii++)
function_name (&x, a[ii]);

In the test case I was not representing this correctly (as shown in the 
conversion above), but just computing the value that the function should do, 
thus making the test flaky. I made this fix in the test case. The other 
advantage of this change is that, in future I can change the what the function 
does (maybe with #defines and have multiple checks for different function body) 
and I don't have to change a lot of things.

I tried the patch on x86 and x86_64 and it works fine. I am assuming -m32 on 
x86_64 should have the same behavior as x86. So, is this OK for trunk?

Here are the Changelog entries:

gcc/c/ChangeLog
2013-06-08  Balaji V. Iyer  

* c-array-notation.c (fix_builtin_array_notation_fn): Added a cast
for all the usage of function parameter to match the identity var.

gcc/testsuite/ChangeLog
2013-06-08  Balaji V. Iyer  

PR c/57563
* c-c++-common/cilk-plus/AN/builtin_fn_mutating.c (main): Fixed a bug
in how we check __sec_reduce_mutating function's result.

Thanks,

Balaji V. Iyer.
diff --git a/gcc/c/ChangeLog b/gcc/c/ChangeLog
index 5fbb31f..caf2146 100644
Binary files a/gcc/c/ChangeLog and b/gcc/c/ChangeLog differ
diff --git a/gcc/c/c-array-notation.c b/gcc/c/c-array-notation.c
index b1040da..1914a24 100644
--- a/gcc/c/c-array-notation.c
+++ b/gcc/c/c-array-notation.c
@@ -133,7 +133,7 @@ fix_builtin_array_notation_fn (tree an_builtin_fn, tree 
*new_var)
   bool **count_down, **array_vector;
   location_t location = UNKNOWN_LOCATION;
   tree loop_with_init = alloc_stmt_list ();
-  
+  tree new_comp_expr = NULL_TREE, identity_expr = NULL_TREE;
   enum built_in_function an_type =
 is_cilkplus_reduce_builtin (CALL_EXPR_FN (an_builtin_fn));
   if (an_type == BUILT_IN_NONE)
@@ -483,10 +483,12 @@ fix_builtin_array_notation_fn (tree an_builtin_fn, tree 
*new_var)
   new_yes_expr = build_modify_expr
(location, *new_var, TREE_TYPE (*new_var), NOP_EXPR,
 location, func_parm, TREE_TYPE (*new_var));
-  new_expr = build_conditional_expr
-   (location,
-build2 (LT_EXPR, TREE_TYPE (*new_var), *new_var, func_parm), false,
-new_yes_expr, TREE_TYPE (*new_var), new_no_expr, TREE_TYPE (*new_var));
+  new_comp_expr = build2 (LT_EXPR, TREE_TYPE (*new_var), *new_var,
+ build_c_cast (location, TREE_TYPE (*new_var),
+   func_parm));
+  new_expr = build_conditional_expr (location, new_comp_expr, false,
+new_yes_expr, TREE_TYPE (*new_var),
+new_no_expr, TREE_TYPE (*new_var));
   break;
 case BUILT_IN_CILKPLUS_SEC_REDUCE_MIN:
   if (TYPE_MAX_VALUE (new_var_type))
@@ -503,10 +505,12 @@ fix_builtin_array_notation_fn (tree an_builtin_fn, tree 
*new_var)
   new_yes_expr = build_modify_expr
(location, *new_var, TREE_TYPE (*new_var), NOP_EXPR,
 location, func_parm, TREE_TYPE (*new_var));
-  new_expr = build_conditional_expr
-   (location,
-build2 (GT_EXPR, TREE_TYPE (*new_var), *new_var, func_parm), false,
-new_yes_expr, TREE_TYPE (*new_var), new_no_expr, TREE_TYPE (*new_var));
+  new_comp_expr = build2 (GT_EXPR, TREE_TYPE (*new_var), *new_var,
+ build_c_cast (location, TREE_TYPE (*new_var),
+   func_parm));
+  new_expr = build_conditional_expr (location, new_comp_expr, false,
+new_yes_expr, TREE_TYPE (*new_var),
+new_no_expr, TREE_TYPE (*new_var));
   break;
 case BUILT_IN_CILKPLUS_SEC_REDUCE_MAX_IND:
   new_var_init = build_modify_expr
@@ -551,12 +555,13 @@ fix_builtin_array_notation_fn (tree an_builtin_fn, tree 
*new_var)
   append_to_statement_list (new_no_ind, &new_no_list);
   append_to_statement_list (new_no_expr, &new_no_list);
  
+  new_comp_expr =
+   build2 (LE_EXPR, TREE_TYPE (array_ind_value), array_ind_value,
+   build_c_cast (location, TREE_TYPE (array_ind_va

[GOOGLE] Avoid emitting duplicated weakref

[Dehao Chen]

This patch fixes a bug when two weakref symbols are mapped to a same
assembler name.

Testing on going.

OK for google branches if test is fine?

Thanks,
Dehao

Index: gcc/varasm.c
===
--- gcc/varasm.c (revision 199844)
+++ gcc/varasm.c (working copy)
@@ -5502,6 +5502,10 @@ do_assemble_alias (tree decl, tree target)
   if (TREE_ASM_WRITTEN (decl))
 return;

+  if (lookup_attribute ("weakref", DECL_ATTRIBUTES (decl))
+  && TREE_ASM_WRITTEN (DECL_ASSEMBLER_NAME (decl)))
+return;
+
   /* We must force creation of DECL_RTL for debug info generation, even though
  we don't use it here.  */
   make_decl_rtl (decl);

Re: [GOOGLE] Avoid emitting duplicated weakref

[Xinliang David Li]

Guard also with L_IPO_COMP_MODE as this is lipo specific.

David

On Sat, Jun 8, 2013 at 8:29 PM, Dehao Chen  wrote:
> This patch fixes a bug when two weakref symbols are mapped to a same
> assembler name.
>
> Testing on going.
>
> OK for google branches if test is fine?
>
> Thanks,
> Dehao
>
> Index: gcc/varasm.c
> ===
> --- gcc/varasm.c (revision 199844)
> +++ gcc/varasm.c (working copy)
> @@ -5502,6 +5502,10 @@ do_assemble_alias (tree decl, tree target)
>if (TREE_ASM_WRITTEN (decl))
>  return;
>
> +  if (lookup_attribute ("weakref", DECL_ATTRIBUTES (decl))
> +  && TREE_ASM_WRITTEN (DECL_ASSEMBLER_NAME (decl)))
> +return;
> +
>/* We must force creation of DECL_RTL for debug info generation, even 
> though
>   we don't use it here.  */
>make_decl_rtl (decl);