Re: PING: PATCH [4/n]: Prepare x32: Permute the conversion and addition if one operand is a constant

[Paolo Bonzini]

Il 29/05/2014 19:20, pins...@gmail.com ha scritto:

What is your Pmode?


Pmode is dimode while ptr_mode is simode.  Pointers are zero extended when 
converting between si and di modes.


As you noted, the fundamental difference between x32 and aarch64 is that 
aarch64 will still use 64-bit accesses instead of 32-bit.  Did you 
define the VALID_POINTER_MODE hook to rule out Pmode as a valid pointer 
mode?  Perhaps you can use it to make this transformation conditional on 
VALID_POINTER_MODE(Pmode).


Paolo

Re: Patch RFA: Move x86 _mm_pause out of pragma target("sse") scope

[Uros Bizjak]

Hello!

> This error is because _mm_pause is defined in the scope of #pragma GCC
> target("sse").  But _mm_pause, which simply generates the pause
> instruction, does not require SSE support.  The pause instruction has
> nothing really to do with SSE, and it works on all x86 processors (on
> processors that do not explicitly recognize it, it is a nop).
>
> I propose the following patch, which moves _mm_pause out of the pragma
> target scope.
>
> I know that x86intrin.h provides a similar intrinsic, __pause, but I
> think it's worth making _mm_pause work reasonably as well.
>
> I'm running a full testsuite run.  OK for mainline if it passes?
>
> gcc/ChangeLog:
>
> 2014-05-29  Ian Lance Taylor  
>
> * config/i386/xmmintrin.h (_mm_pause): Move out of scope of pragma
> target("sse").
>
> gcc/testsuite/ChangeLog:
>
> 2014-05-29  Ian Lance Taylor  
>
> * gcc.target/i386/pause-2.c: New test.

The patch looks OK to me, but please wait a day or two for possible
comments (compatibility, etc) from Kirill.

Thanks,
Uros.

Re: ipa-visibility TLC 2/n

[Richard Sandiford]

Jan Hubicka  writes:
>> Jan Hubicka  writes:
>> >> Richard Sandiford wrote the original section anchors implementation,
>> >> so he would be a good person to comment about the interaction between
>> >> aliases and section anchors.
>> >
>> > Thanks! Richard, does this patch seem sane?
>> 
>> Looks good to me in principle, but with:
>> 
>> > +  struct symtab_node *snode;
>> >decl = SYMBOL_REF_DECL (symbol);
>> > +
>> > +  snode = symtab_node (decl);
>> > +  if (snode->alias)
>> > +   {
>> > + rtx target = DECL_RTL (symtab_alias_ultimate_target
>> > (snode)->decl);
>> > + SYMBOL_REF_BLOCK_OFFSET (symbol) = SYMBOL_REF_BLOCK_OFFSET
>> > (target);
>> > + return;
>> > +   }
>> 
>> is SYMBOL_REF_BLOCK_OFFSET (target) guaranteed to be valid at this point?
>> It looked at face value like you'd need a recursive call to 
>> place_block_symbol
>> on the target before the copy.
>
> My reading was that SYMBOL_REF_BLOCK_OFFSET is computed at DECL_RTL
> calculation time. But you are right - it is done by validize_mem that
> is not done by DECL_RTL.  Shall I just call it on target first?

Yeah, sounds like calling place_block_symbol would be safer.

IIRC, the reason I didn't do it at SET_DECL_RTL time is that some frontends
tended to create placeholder decls that for whatever reason ended up with
an initial DECL_RTL, then changed the properties of the decl later once
more information was known.  (This was all many years ago.)

Thanks,
Richard

[PATCH] Dumping Fields of A Class When -fdump-class-hierarchy

[lin zuojian]

* class.c (dump_class_hierarchy_1): dump fields after hierarchy information.

---
 gcc/cp/class.c | 38 ++
 1 file changed, 38 insertions(+)

diff --git a/gcc/cp/class.c b/gcc/cp/class.c
index 14780e7..13579ac 100644
--- a/gcc/cp/class.c
+++ b/gcc/cp/class.c
@@ -8202,6 +8202,44 @@ dump_class_hierarchy_1 (FILE *stream, int flags, tree t)
   (unsigned long)(TYPE_ALIGN (CLASSTYPE_AS_BASE (t))
   / BITS_PER_UNIT));
   dump_class_hierarchy_r (stream, flags, TYPE_BINFO (t), TYPE_BINFO (t), 0);
+  if (TYPE_P (t))
+{
+  enum tree_code code;
+
+  code = TREE_CODE (t);
+  if (code == RECORD_TYPE || code == UNION_TYPE)
+{
+  tree field;
+  fprintf (stream, "fields:\n");
+  for (field = TYPE_FIELDS (t); field; field = DECL_CHAIN (field))
+{
+  tree field_type;
+  tree field_name;
+  tree size;
+  tree bpos;
+  enum tree_code code;
+
+  code = TREE_CODE (field);
+  if (code != FIELD_DECL)
+continue;
+  field_type = TREE_TYPE (field);
+  field_name = DECL_NAME (field);
+  size = DECL_SIZE (field);
+
+  if (DECL_FIELD_OFFSET (field))
+bpos = bit_position (field);
+  else
+bpos = NULL;
+  fprintf (
+  stream, "%s %s;\n"
+  "size: %ld, bpos: %ld\n",
+  type_as_string (field_type, TFF_PLAIN_IDENTIFIER),
+  field_name ? IDENTIFIER_POINTER (field_name) : "(base)",
+  tree_to_shwi (size), bpos == NULL ? 0 : tree_to_shwi (bpos));
+}
+}
+}
+
   fprintf (stream, "\n");
 }
 
-- 
1.9.1

[PATCH] Fix up GCC_EXEC_PREFIX handling with ALT_*_UNDER_TEST

[Jakub Jelinek]

Hi!

I've noticed that when running
make check ALT_CC_UNDER_TEST=gcc ALT_CXX_UNDER_TEST=g++
when the newly built compiler is built into a different prefix
than the system compiler (4.8.x or 4.4.x) lots of tests fail with
errors where the system compiler either couldn't find headers
or even can't exec cc1*.

{set,restore}_ld_library_path_env_vars already sets/restores
GCC_EXEC_PREFIX env var, but unfortunately compat-use-alt-compiler
doesn't restore_ld_library_path_env_vars, instead it
set_ld_library_path_env_vars with just a different ld_library_path.
This patch doesn't change that, supposedly someone needs that, but
just makes sure GCC_EXEC_PREFIX has the original value (or none if it wasn't
in the environment) when invoking the alt compiler.

Tested on x86_64-linux and i686-linux, ok for trunk/4.9?

2014-05-30  Jakub Jelinek  

* lib/target-libpath.exp (set_gcc_exec_prefix_env_var,
restore_gcc_exec_prefix_env_var): New procedures.
(set_ld_library_path_env_vars,
restore_ld_library_path_env_vars): Use them.
* lib/c-compat.exp: Load target-libpath.exp.
(compat-use-alt-compiler): Call restore_gcc_exec_prefix_env_var.
(compat-use-tst-compiler): Call set_gcc_exec_prefix_env_var.
* g++.dg/compat/compat.exp (compat-use-alt-compiler): Call
restore_gcc_exec_prefix_env_var.
* g++.dg/compat/struct-layout-1.exp (compat-use-alt-compiler):
Likewise.

--- gcc/testsuite/lib/target-libpath.exp.jj 2014-03-20 16:29:20.0 
+0100
+++ gcc/testsuite/lib/target-libpath.exp2014-05-29 19:32:58.192043417 
+0200
@@ -28,6 +28,21 @@ set orig_gcc_exec_prefix_checked 0
 
 
 ###
+# proc set_gcc_exec_prefix_env_var { }
+###
+
+proc set_gcc_exec_prefix_env_var { } {
+  global TEST_GCC_EXEC_PREFIX
+  global env
+
+  # Set GCC_EXEC_PREFIX for the compiler under test to pick up files not in
+  # the build tree from a specified location (normally the install tree).
+  if [info exists TEST_GCC_EXEC_PREFIX] {
+setenv GCC_EXEC_PREFIX "$TEST_GCC_EXEC_PREFIX"
+  }
+}
+
+###
 # proc set_ld_library_path_env_vars { }
 ###
 
@@ -49,7 +64,6 @@ proc set_ld_library_path_env_vars { } {
   global orig_ld_library_path_64
   global orig_dyld_library_path
   global orig_gcc_exec_prefix
-  global TEST_GCC_EXEC_PREFIX
   global env
 
   # Save the original GCC_EXEC_PREFIX.
@@ -61,11 +75,7 @@ proc set_ld_library_path_env_vars { } {
 set orig_gcc_exec_prefix_checked 1
   }
 
-  # Set GCC_EXEC_PREFIX for the compiler under test to pick up files not in
-  # the build tree from a specified location (normally the install tree).
-  if [info exists TEST_GCC_EXEC_PREFIX] {
-setenv GCC_EXEC_PREFIX "$TEST_GCC_EXEC_PREFIX"
-  }
+  set_gcc_exec_prefix_env_var
 
   # Setting the ld library path causes trouble when testing cross-compilers.
   if { [is_remote target] } {
@@ -164,6 +174,22 @@ proc set_ld_library_path_env_vars { } {
 }
 
 ###
+# proc restore_gcc_exec_prefix_env_var { }
+###
+
+proc restore_gcc_exec_prefix_env_var { } {
+  global orig_gcc_exec_prefix_saved
+  global orig_gcc_exec_prefix
+  global env
+
+  if { $orig_gcc_exec_prefix_saved } {
+setenv GCC_EXEC_PREFIX "$orig_gcc_exec_prefix"
+  } elseif [info exists env(GCC_EXEC_PREFIX)] {
+unsetenv GCC_EXEC_PREFIX
+  }
+}
+
+###
 # proc restore_ld_library_path_env_vars { }
 ###
 
@@ -175,21 +201,15 @@ proc restore_ld_library_path_env_vars {
   global orig_ld_library_path_32_saved
   global orig_ld_library_path_64_saved
   global orig_dyld_library_path_saved
-  global orig_gcc_exec_prefix_saved
   global orig_ld_library_path
   global orig_ld_run_path
   global orig_shlib_path
   global orig_ld_library_path_32
   global orig_ld_library_path_64
   global orig_dyld_library_path
-  global orig_gcc_exec_prefix
   global env
 
-  if { $orig_gcc_exec_prefix_saved } {
-setenv GCC_EXEC_PREFIX "$orig_gcc_exec_prefix"
-  } elseif [info exists env(GCC_EXEC_PREFIX)] {
-unsetenv GCC_EXEC_PREFIX
-  }
+  restore_gcc_exec_prefix_env_var
 
   if { $orig_environment_saved == 0 } {
 return
--- gcc/testsuite/lib/c-compat.exp.jj   2014-01-03 11:40:40.0 +0100
+++ gcc/testsuite/lib/c-compat.exp  2014-05-29 19:33:15.870952346 +0200
@@ -28,6 +28,7 @@ global compat_skip_list
 # compilers for compatibility tests.
 
 load_lib target-supports.exp
+load_lib target-libpath.exp
 
 #
 # compat-use-alt-compiler -- make the alternate compiler the default
@@ -47,6 +48,7 @@ proc compat-use-alt-compiler { } {
if { $compat_alt_color == 0 } then {
regsub -- "-fdiagnostics-color=never" $TEST_ALWAYS_FLAGS "" 
TEST_ALWAYS_FLAGS
}
+   restore_gcc_exec_prefix_env_var
 }
 }
 
@@ -64,6 +66,7 @@ pr

Re: [patch ping] libstdc++ testsuite cxxflags

[Ramana Radhakrishnan]

On Sat, May 24, 2014 at 5:54 PM, Jonathan Wakely  wrote:
> On 24 May 2014 17:07, David Edelsohn wrote:
>> This patch broke the ability to run the libstdc++ testsuite on AIX.
>>
>> I now see the following errors:
>>
>> bad switch "-O": must be -all, -about, -indices, -inline, -expanded, -line, 
>> -lin
>> estop, -lineanchor, -nocase, -start, or --
>> while executing
>> "regexp "\-O" $cxxflags"
>
> Would this work instead?
>
>regexp ".*-O" $cxxflags


With all the other build breakages in the past week,  I've just
started seeing the first set of testresults from an auto-tester. It
looks like on a cross test using rhe5 / x86_64  with the version of
tcl8.4 I'm using I see the same errors that David saw.

The testsuite starts running if I tried the above

regexp ".*-O" $cxxflags

Is this going to be applied - what gives ?

regards
Ramana

[PATCH, Fortran] PR61234: -Wuse-no-only

[VandeVondele Joost]

Hi,

the attached patch fixes PR61234 by introducing a warning for modules used 
without an only qualifier, triggered by a flag '-Wuse-no-only'. 

It is a two line addition to module.c, plus mechanical changes to initialize 
the flag and keep the tests up-to-date. I currently have no copyright 
assignment filed, so I hope it can pass as 'trivial' or it needs to wait till I 
get the paperwork sorted.

The patch has been bootstrapped and regtested on x86_64-unknown-linux-gnu. If 
OK, please apply to trunk.

gcc/fortran/ChangeLog:

2014-05-29 Joost VandeVondele  

PR fortran/61234
* lang.opt (Wuse-no-only): New flag.
* gfortran.h (gfc_option_t): Add it.
* invoke.texi: Document it.
* module.c (gfc_use_module): Warn if needed.
* options.c (gfc_init_options,set_Wall,gfc_handle_option): Init 
accordingly.

gcc/testsuite/ChangeLog:

2014-05-29 Joost VandeVondele  

* gfortran.dg/c_by_val_5.f90: Add expected -Wall warning.
* gfortran.dg/transfer_check_4.f90: idem.
* gfortran.dg/iso_c_binding_compiler_3.f90: idem.
* gfortran.dg/pr52370.f90: idem.
* gfortran.dg/use_no_only_1.f90: New test.

Thanks in advance,

Joostgcc/fortran/ChangeLog:

2014-05-29 Joost VandeVondele  

PR fortran/61234
* lang.opt (Wuse-no-only): New flag.
* gfortran.h (gfc_option_t): Add it.
* invoke.texi: Document it.
* module.c (gfc_use_module): Warn if needed.
* options.c (gfc_init_options,set_Wall,gfc_handle_option): Init accordingly.

gcc/testsuite/ChangeLog:

2014-05-29 Joost VandeVondele  

	* gfortran.dg/c_by_val_5.f90: Add expected -Wall warning.
	* gfortran.dg/transfer_check_4.f90: idem.
	* gfortran.dg/iso_c_binding_compiler_3.f90: idem.
	* gfortran.dg/pr52370.f90: idem.
	* gfortran.dg/use_no_only_1.f90: New test.

Index: gcc/testsuite/gfortran.dg/c_by_val_5.f90
===
--- gcc/testsuite/gfortran.dg/c_by_val_5.f90	(revision 211022)
+++ gcc/testsuite/gfortran.dg/c_by_val_5.f90	(working copy)
@@ -59,7 +59,7 @@ END module x
 !end subroutine test
 
 program main
-  use x
+  use x ! { dg-warning "has no ONLY qualifier" }
   implicit none
 !  external test
   call Grid2BMP(10)
Index: gcc/testsuite/gfortran.dg/transfer_check_4.f90
===
--- gcc/testsuite/gfortran.dg/transfer_check_4.f90	(revision 211022)
+++ gcc/testsuite/gfortran.dg/transfer_check_4.f90	(working copy)
@@ -6,7 +6,7 @@
 
 subroutine transfers (test)
 
-  use, intrinsic :: iso_fortran_env
+  use, intrinsic :: iso_fortran_env ! { dg-warning "has no ONLY qualifier" }
   
   integer, intent(in) :: test
 
Index: gcc/testsuite/gfortran.dg/iso_c_binding_compiler_3.f90
===
--- gcc/testsuite/gfortran.dg/iso_c_binding_compiler_3.f90	(revision 211022)
+++ gcc/testsuite/gfortran.dg/iso_c_binding_compiler_3.f90	(working copy)
@@ -7,8 +7,8 @@
 !  "Type specified for intrinsic function" for this file
 !
 
-use iso_c_binding
-use iso_Fortran_env
+use iso_c_binding ! { dg-warning "has no ONLY qualifier" }
+use iso_Fortran_env ! { dg-warning "has no ONLY qualifier" }
 implicit none
 intrinsic sin
 real :: x = 3.4
@@ -17,9 +17,9 @@ end
 
 
 module test_mod
-use iso_fortran_env
+use iso_fortran_env ! { dg-warning "has no ONLY qualifier" }
 end module test_mod
 
 subroutine test
-use test_mod
+use test_mod ! { dg-warning "has no ONLY qualifier" }
 end subroutine test
Index: gcc/testsuite/gfortran.dg/use_no_only_1.f90
===
--- gcc/testsuite/gfortran.dg/use_no_only_1.f90	(revision 0)
+++ gcc/testsuite/gfortran.dg/use_no_only_1.f90	(revision 0)
@@ -0,0 +1,22 @@
+! PR fortran/61234 Warn for use-stmt without explicit only-list.
+! { dg-do compile }
+! { dg-options "-Wuse-no-only" }
+MODULE foo
+  INTEGER :: bar
+END MODULE
+
+MODULE testmod
+  USE foo ! { dg-warning "has no ONLY qualifier" }
+  IMPLICIT NONE
+CONTAINS
+  SUBROUTINE S1
+ USE foo ! { dg-warning "has no ONLY qualifier" }
+  END SUBROUTINE S1
+  SUBROUTINE S2
+ USE foo, ONLY: bar ! { dg-bogus "has no ONLY qualifier" }
+  END SUBROUTINE
+  SUBROUTINE S3
+ USE ISO_C_BINDING ! { dg-warning "has no ONLY qualifier" }
+  END SUBROUTINE S3
+END MODULE
+! { dg-final { cleanup-modules "foo testmod" } }
Index: gcc/testsuite/gfortran.dg/pr52370.f90
===
--- gcc/testsuite/gfortran.dg/pr52370.f90	(revision 211022)
+++ gcc/testsuite/gfortran.dg/pr52370.f90	(working copy)
@@ -15,7 +15,7 @@ contains
 end module pr52370
 
 program prg52370
-  use pr52370
+  use pr52370 ! { dg-warning "has no ONLY qualifier" }
   real :: a
   call foo(a)
 end program prg52370
Index: gcc/fortran/invoke.texi
===
--- gcc/fortran/invoke.texi	(revision 211022)

Re: [patch i386]: Expand sibling-tail-calls via accumulator register

[Kai Tietz]

So, completed bootstrap and regression-test for x86_64-unknown-linux-gnu 
(multilib) by using following predicate for sibcall-patch.

(define_predicate "sibcall_memory_operand"
  (match_operand 0 "memory_operand")
{
  return CONSTANT_P (op);
})


Worked fine, no regressions.  Is sibcall-patch ok with that predicate to be 
applied?

Regards,
Kai

[AARCH64, PATCH] Fix ICE in aarch64_float_const_representable_p

[Tom de Vries]

Marcus,

when building for aarch64-linux-gnu with --enable-checking=yes,rtl, I run into 
the following error:

...
In file included from src/libgcc/libgcc2.c:56:0:
src/libgcc/libgcc2.c: In function ‘__floattisf’:
src/libgcc/libgcc2.h:200:20: internal compiler error: RTL check: expected code 
'const_double' and not mode 'VOID', have code 'const_double' and mode 'VOID' in 
aarch64_float_const_representable_p, at config/aarch64/aarch64.c:8481

 #define __NDW(a,b) __ ## a ## ti ## b
^
src/libgcc/libgcc2.h:293:21: note: in expansion of macro ‘__NDW’
 #define __floatdisf __NDW(float,sf)
 ^
src/libgcc/libgcc2.c:1569:14: note: in expansion of macro ‘__floatdisf’
 #define FUNC __floatdisf
  ^
src/libgcc/libgcc2.c:1579:1: note: in expansion of macro ‘FUNC’
 FUNC (DWtype u)
 ^
0xc1a278 rtl_check_failed_code_mode(rtx_def const*, rtx_code, machine_mode, 
bool, char const*, int, char const*)

src/gcc/rtl.c:833
0x1062b7b aarch64_float_const_representable_p(rtx_def*)
src/gcc/config/aarch64/aarch64.c:8481
0x1052ae2 aarch64_rtx_costs
src/gcc/config/aarch64/aarch64.c:5003
0x1059a9c aarch64_rtx_costs_wrapper
src/gcc/config/aarch64/aarch64.c:5804
0xc38f1a rtx_cost(rtx_def*, rtx_code, int, bool)
src/gcc/rtlanal.c:3878
0xb159a9 avoid_expensive_constant
src/gcc/optabs.c:1389
0xb15ca9 expand_binop_directly
src/gcc/optabs.c:1441
0xb161e7 expand_binop(machine_mode, optab_tag, rtx_def*, rtx_def*, rtx_def*, 
int, optab_methods)

src/gcc/optabs.c:1568
0x87f27f expand_expr_real_2(separate_ops*, rtx_def*, machine_mode, 
expand_modifier)
src/gcc/expr.c:9200
0x87fe4b expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, 
rtx_def**, bool)

src/gcc/expr.c:9388
0x879534 expand_expr_real(tree_node*, rtx_def*, machine_mode, expand_modifier, 
rtx_def**, bool)

src/gcc/expr.c:7921
0x79a720 expand_normal
src/gcc/expr.h:471
0x79cdb3 do_jump_by_parts_greater
src/gcc/dojump.c:741
0x79b682 do_jump_1(tree_code, tree_node*, tree_node*, rtx_def*, rtx_def*, int)
src/gcc/dojump.c:280
0x79a8ce jumpifnot_1(tree_code, tree_node*, tree_node*, rtx_def*, int)
src/gcc/dojump.c:138
0x700de4 expand_gimple_cond
src/gcc/cfgexpand.c:2145
0x70ed7f expand_gimple_basic_block
src/gcc/cfgexpand.c:5063
0x71189c execute
src/gcc/cfgexpand.c:5803
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
...

We assert here during REAL_VALUE_FROM_CONST_DOUBLE because x has VOIDmode, which 
means it has integer rather than floating point type:

...
bool
aarch64_float_const_representable_p (rtx x)
{
  /* This represents our current view of how many bits
 make up the mantissa.  */
  int point_pos = 2 * HOST_BITS_PER_WIDE_INT - 1;
  int exponent;
  unsigned HOST_WIDE_INT mantissa, mask;
  REAL_VALUE_TYPE r, m;
  bool fail;

  if (!CONST_DOUBLE_P (x))
return false;

  REAL_VALUE_FROM_CONST_DOUBLE (r, x);
...

Attached patch fixes the ICE by handling the case that x is VOIDmode, and allows 
me to complete the build.


OK for trunk if build and test succeeds?

I think the call site in aarch64_rtx_costs may need a separate fix.

Thanks,
- Tom
2014-05-30  Tom de Vries  

	* config/aarch64/aarch64.c (aarch64_float_const_representable_p): Handle
	case that x has VOIDmode.
---
 gcc/config/aarch64/aarch64.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index 4ece0c6..ce0e7dc 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -8478,6 +8478,9 @@ aarch64_float_const_representable_p (rtx x)
   if (!CONST_DOUBLE_P (x))
 return false;
 
+  if (GET_MODE (x) == VOIDmode)
+return false;
+
   REAL_VALUE_FROM_CONST_DOUBLE (r, x);
 
   /* We cannot represent infinities, NaNs or +/-zero.  We won't
-- 
1.9.1

Re: [AARCH64, PATCH] Fix ICE in aarch64_float_const_representable_p

[Ramana Radhakrishnan]

On Fri, May 30, 2014 at 9:14 AM, Tom de Vries  wrote:
> Marcus,
>
> when building for aarch64-linux-gnu with --enable-checking=yes,rtl, I run
> into the following error:
> ...
> In file included from src/libgcc/libgcc2.c:56:0:
> src/libgcc/libgcc2.c: In function ‘__floattisf’:
> src/libgcc/libgcc2.h:200:20: internal compiler error: RTL check: expected
> code 'const_double' and not mode 'VOID', have code 'const_double' and mode
> 'VOID' in aarch64_float_const_representable_p, at
> config/aarch64/aarch64.c:8481
>  #define __NDW(a,b) __ ## a ## ti ## b
> ^
> src/libgcc/libgcc2.h:293:21: note: in expansion of macro ‘__NDW’
>  #define __floatdisf __NDW(float,sf)
>  ^
> src/libgcc/libgcc2.c:1569:14: note: in expansion of macro ‘__floatdisf’
>  #define FUNC __floatdisf
>   ^
> src/libgcc/libgcc2.c:1579:1: note: in expansion of macro ‘FUNC’
>  FUNC (DWtype u)
>  ^
> 0xc1a278 rtl_check_failed_code_mode(rtx_def const*, rtx_code, machine_mode,
> bool, char const*, int, char const*)
> src/gcc/rtl.c:833
> 0x1062b7b aarch64_float_const_representable_p(rtx_def*)
> src/gcc/config/aarch64/aarch64.c:8481
> 0x1052ae2 aarch64_rtx_costs
> src/gcc/config/aarch64/aarch64.c:5003
> 0x1059a9c aarch64_rtx_costs_wrapper
> src/gcc/config/aarch64/aarch64.c:5804
> 0xc38f1a rtx_cost(rtx_def*, rtx_code, int, bool)
> src/gcc/rtlanal.c:3878
> 0xb159a9 avoid_expensive_constant
> src/gcc/optabs.c:1389
> 0xb15ca9 expand_binop_directly
> src/gcc/optabs.c:1441
> 0xb161e7 expand_binop(machine_mode, optab_tag, rtx_def*, rtx_def*, rtx_def*,
> int, optab_methods)
> src/gcc/optabs.c:1568
> 0x87f27f expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
> expand_modifier)
> src/gcc/expr.c:9200
> 0x87fe4b expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
> expand_modifier, rtx_def**, bool)
> src/gcc/expr.c:9388
> 0x879534 expand_expr_real(tree_node*, rtx_def*, machine_mode,
> expand_modifier, rtx_def**, bool)
> src/gcc/expr.c:7921
> 0x79a720 expand_normal
> src/gcc/expr.h:471
> 0x79cdb3 do_jump_by_parts_greater
> src/gcc/dojump.c:741
> 0x79b682 do_jump_1(tree_code, tree_node*, tree_node*, rtx_def*, rtx_def*,
> int)
> src/gcc/dojump.c:280
> 0x79a8ce jumpifnot_1(tree_code, tree_node*, tree_node*, rtx_def*, int)
> src/gcc/dojump.c:138
> 0x700de4 expand_gimple_cond
> src/gcc/cfgexpand.c:2145
> 0x70ed7f expand_gimple_basic_block
> src/gcc/cfgexpand.c:5063
> 0x71189c execute
> src/gcc/cfgexpand.c:5803
> Please submit a full bug report,
> with preprocessed source if appropriate.
> Please include the complete backtrace with any bug report.
> See  for instructions.
> ...
>
> We assert here during REAL_VALUE_FROM_CONST_DOUBLE because x has VOIDmode,
> which means it has integer rather than floating point type:
> ...
> bool
> aarch64_float_const_representable_p (rtx x)
> {
>   /* This represents our current view of how many bits
>  make up the mantissa.  */
>   int point_pos = 2 * HOST_BITS_PER_WIDE_INT - 1;
>   int exponent;
>   unsigned HOST_WIDE_INT mantissa, mask;
>   REAL_VALUE_TYPE r, m;
>   bool fail;
>
>   if (!CONST_DOUBLE_P (x))
> return false;
>
>   REAL_VALUE_FROM_CONST_DOUBLE (r, x);
> ...
>
> Attached patch fixes the ICE by handling the case that x is VOIDmode, and
> allows me to complete the build.
>

IIUC it would be better to shift the AArch64 port to
TARGET_SUPPORTS_WIDE_INT and not worry about x being VOIDmode at all.
In this case we should not have any const_double's containing
integers.

I have a couple of patches in testing that did this but with all the
other breakages in AArch64 and ARM land in the past couple of weeks I
have been unable to submit this.

regards
Ramana

> OK for trunk if build and test succeeds?
>
> I think the call site in aarch64_rtx_costs may need a separate fix.
>
> Thanks,
> - Tom

Re: [PATCH][ARM] Use mov_imm type for movw operations consistently

[Ramana Radhakrishnan]

On 05/29/14 16:25, Kyrill Tkachov wrote:

Hi all,

I noticed that in some of our move patterns the movw instruction is given the 
mov_reg type rather than the
mov_imm type that all other uses of movw have. This patch fixes that.

Scanning through our pipeline descriptions I see that mov_imm is treated the 
same way as mov_reg everywhere anyway. In the Cortex-A7 description we do have 
a bit more complicated logic:

;; ALU instruction with an immediate operand can dual-issue.
(define_insn_reservation "cortex_a7_alu_imm" 2
(and (eq_attr "tune" "cortexa7")
 (ior (eq_attr "type" "adr,alu_imm,alus_imm,logic_imm,logics_imm,\
   mov_imm,mvn_imm,extend")
  (and (eq_attr "type" "mov_reg,mov_shift,mov_shift_reg")
   (not (eq_attr "length" "8")
"cortex_a7_ex2|cortex_a7_ex1")

In the two patterns that I change the mov_imm has a length of 4 an hence will 
still use this reservation.
Thus I don't expect codegen to change at all from this patch but for future 
scheduling jobs this could make a
difference.


This is ok. Well spotted.

Ramana



Tested arm-none-eabi on qemu.

Ok for trunk?

Thanks,
Kyrill

2014-05-29  Kyrylo Tkachov  

* config/arm/thumb2.md (*thumb2_movhi_insn): Set type of movw
to mov_imm.
* config/arm/vfp.md (*thumb2_movsi_vfp): Likewise.

Re: [RFC][ARM] TARGET_ATOMIC_ASSIGN_EXPAND_FENV hook

[Ramana Radhakrishnan]

>+  if (!TARGET_VFP)
>+return;
>+
>+  /* Generate the equivalence of :

s/equivalence/equivalent.

Ok with that change and if no regressions.

Ramana

On Mon, May 26, 2014 at 9:01 AM, Kugan
 wrote:
> Ping^2 ?
>
> Thanks,
> Kugan
>
> On 12/05/14 09:47, Kugan wrote:
>> Ping ?
>>
>> Thanks,
>> Kugan
>>
>> On 02/05/14 19:04, Kugan wrote:
>>> On 02/05/14 10:15, Joseph S. Myers wrote:
 It doesn't seem a good idea to me for a host-side GCC file to use the FE_*
 names for the target's FE_* values; you'd run into problems if that file
 ever ends up including the host's , directly or indirectly, on any
 host.  The same comment applies to the AArch64 patch as well.

 Instead I suggest names such as ARM_FE_* that won't conflict with the
 host's system headers.

>>> Thanks for spotting it. Here is the updated patch that changes it to
>>> ARM_FE_*.
>>>
>>> Thanks,
>>> Kugan
>>>
>>>
>>> gcc/
>>>
>>> +2014-05-02  Kugan Vivekanandarajah  
>>> +
>>> +* config/arm/arm.c (TARGET_ATOMIC_ASSIGN_EXPAND_FENV): New define.
>>> +(arm_builtins) : Add ARM_BUILTIN_GET_FPSCR and ARM_BUILTIN_SET_FPSCR.
>>> +(bdesc_2arg) : Add description for builtins __builtins_arm_set_fpscr
>>> +and __builtins_arm_get_fpscr.
>>> +(arm_init_builtins) : Initialize builtins __builtins_arm_set_fpscr and
>>> +__builtins_arm_get_fpscr.
>>> +(arm_expand_builtin) : Expand builtins __builtins_arm_set_fpscr and
>>> +__builtins_arm_ldfpscr.
>>> +(arm_atomic_assign_expand_fenv): New function.
>>> +* config/arm/vfp.md (set_fpscr): New pattern.
>>> +(get_fpscr) : Likewise.
>>> +* config/arm/unspecs.md (unspecv): Add VUNSPEC_GET_FPSCR and
>>> +VUNSPEC_SET_FPSCR.
>>> +* doc/extend.texi (AARCH64 Built-in Functions) : Document
>>> +__builtins_arm_set_fpscr, __builtins_arm_get_fpscr.
>>> +
>>>
>>

Re: [RFC] optimize x - y cmp 0 with undefined overflow

[Eric Botcazou]

> I'd say we still handle "basic" symbolic range ops in
> extract_range_from_binary_1
> but in extract_range_from_binary_expr for a symbolic op0 we try to simplify
> it with both [op1, op1] and with the value-range of op1 until we get a
> non-varying range as result.  Not sure if it's worth restricting that
> to the case
> where op0s value-range refers to op1 or vice versa, and eventually only
> use op1 symbolically then.

Patch along these lines attached.  A bit heavy as expected, but it's VRP...
It deals with my pet problem, you might want to check it does so with yours.

Tested on x86_64-suse-linux with no regressions.


2014-05-30  Eric Botcazou  

* tree-vrp.c (get_single_symbol): New function.
(build_symbolic_expr): Likewise.
(symbolic_range_based_on_p): New predicate.
(extract_range_from_binary_expr_1): Deal with single-symbolic ranges
for PLUS and MINUS.  Do not drop symbolic ranges at the end.
(extract_range_from_binary_expr): Try harder for PLUS and MINUS if
operand is symbolic and based on the other operand.


2014-05-30  Eric Botcazou  

* gcc.dg/tree-ssa/vrp93.c: New test.
* gnat.dg/opt38.adb: Likewise.


-- 
Eric BotcazouIndex: tree-vrp.c
===
--- tree-vrp.c	(revision 211019)
+++ tree-vrp.c	(working copy)
@@ -916,6 +916,93 @@ symbolic_range_p (value_range_t *vr)
   || !is_gimple_min_invariant (vr->max));
 }
 
+/* Return the single symbol (an SSA_NAME) contained in T if any, or NULL_TREE
+   otherwise.  We only handle additive operations and set NEG to true if the
+   symbol is negated and INV to the invariant part, if any.  */
+
+static tree
+get_single_symbol (tree t, bool *neg, tree *inv)
+{
+  if (TREE_CODE (t) == PLUS_EXPR
+  || TREE_CODE (t) == POINTER_PLUS_EXPR
+  || TREE_CODE (t) == MINUS_EXPR)
+{
+  if (is_gimple_min_invariant (TREE_OPERAND (t, 0)))
+	{
+	  *inv = TREE_OPERAND (t, 0);
+	  *neg = (TREE_CODE (t) == MINUS_EXPR);
+	  t = TREE_OPERAND (t, 1);
+	}
+  else if (is_gimple_min_invariant (TREE_OPERAND (t, 1)))
+	{
+	  *inv = TREE_OPERAND (t, 1);
+	  *neg = false;
+	  t = TREE_OPERAND (t, 0);
+	}
+  else
+return NULL_TREE;
+}
+  else
+{
+  *inv = NULL_TREE;
+  *neg = false;
+}
+
+  if (TREE_CODE (t) == NEGATE_EXPR)
+{
+  t = TREE_OPERAND (t, 0);
+  *neg = true;
+}
+
+  if (TREE_CODE (t) != SSA_NAME)
+return NULL_TREE;
+
+  return t;
+}
+
+/* The reverse operation: build a symbolic expression with TYPE
+   from symbol SYM, negated according to NEG, and invariant INV.  */
+
+static tree
+build_symbolic_expr (tree type, tree sym, bool neg, tree inv)
+{
+  const bool pointer_p = POINTER_TYPE_P (type);
+  tree t = sym;
+
+  if (neg)
+t = build1 (NEGATE_EXPR, type, t);
+
+  if (integer_zerop (inv))
+return t;
+
+  return build2 (pointer_p ? POINTER_PLUS_EXPR : PLUS_EXPR, type, t, inv);
+}
+
+/* Return true if value range VR involves exactly one symbol SYM.  */
+
+static bool
+symbolic_range_based_on_p (value_range_t *vr, const_tree sym)
+{
+  bool neg, min_has_symbol, max_has_symbol;
+  tree inv;
+
+  if (is_gimple_min_invariant (vr->min))
+min_has_symbol = false;
+  else if (get_single_symbol (vr->min, &neg, &inv) == sym)
+min_has_symbol = true;
+  else
+return false;
+
+  if (is_gimple_min_invariant (vr->max))
+max_has_symbol = false;
+  else if (get_single_symbol (vr->max, &neg, &inv) == sym)
+max_has_symbol = true;
+  else
+return false;
+
+  return (min_has_symbol || max_has_symbol);
+}
+
 /* Return true if value range VR uses an overflow infinity.  */
 
 static inline bool
@@ -2209,7 +2296,7 @@ extract_range_from_multiplicative_op_1 (
 }
 
 /* Extract range information from a binary operation CODE based on
-   the ranges of each of its operands, *VR0 and *VR1 with resulting
+   the ranges of each of its operands *VR0 and *VR1 with resulting
type EXPR_TYPE.  The resulting range is stored in *VR.  */
 
 static void
@@ -2303,11 +2390,12 @@ extract_range_from_binary_expr_1 (value_
   type = vr0.type;
 
   /* Refuse to operate on VARYING ranges, ranges of different kinds
- and symbolic ranges.  As an exception, we allow BIT_AND_EXPR
+ and symbolic ranges.  As an exception, we allow BIT_{AND,IOR}
  because we may be able to derive a useful range even if one of
  the operands is VR_VARYING or symbolic range.  Similarly for
- divisions.  TODO, we may be able to derive anti-ranges in
- some cases.  */
+ divisions, MIN/MAX and PLUS/MINUS.
+
+ TODO, we may be able to derive anti-ranges in some cases.  */
   if (code != BIT_AND_EXPR
   && code != BIT_IOR_EXPR
   && code != TRUNC_DIV_EXPR
@@ -2318,6 +2406,8 @@ extract_range_from_binary_expr_1 (value_
   && code != TRUNC_MOD_EXPR
   && code != MIN_EXPR
   && code != MAX_EXPR
+  && code != PLUS_EXPR
+  && code != MINUS_EXPR
   && (vr0.

Re: [PATCH, Fortran] PR61234: -Wuse-no-only

[Jakub Jelinek]

On Fri, May 30, 2014 at 08:03:45AM +, VandeVondele  Joost wrote:
> +@item -Wuse-no-only
> +@opindex @code{Wuse-no-only}
> +@cindex warnings, use statements
> +@cindex intrinsic
> +Warn if a use statement has no only qualifier and thus implicitly imports
> +all public entities of the used module.
> +This option is implied by @option{-Wall}.

I think it is really weird if a coding style warning is included in -Wall.

Jakub

Re: [PATCH][IRA] Analysis of register usage of functions for usage by IRA.

[Tom de Vries]

On 14-01-14 20:36, Vladimir Makarov wrote:

Unfortunately I haven't been able to find time to work further on the
>>LRA part.
>>So if you're still willing to pick up that part, that would be great.

>
>Vladimir,
>
>I gave this a try. The attached patch works for the included test-case
>for x86_64.
>
>I've bootstrapped and reg-tested the patch (in combination with the
>other patches from the series) on x86_64.
>
>OK for stage1?
>

Yes, it is ok for stage1.  Thanks for not forgetting LRA and sorry for
the delay with the answer (it is not a high priority patch for me right
now).

I believe, this patch helps to improve code also because of better
spilling into SSE regs.  Spilling into SSE regs instead of memory has a
rare probability right now as all SSE regs are call clobbered.



Vladimir,

After committing the original patch, Martin Liška told me on IRC that the patch 
broke the build with --enable-checking=release.


The bit in lra_assign used the call_p field unconditionally, while the 
definition of the call_p field is guarded with #ifdef ENABLE_CHECKING.


I've reverted the original patch, and bootstrapped and reg-tested this version 
of the patch, which has a simplified bit for lra_assign.


The only functional difference between the patches is that we no longer add 
printing a debug message in lra_assign. Committed (since the difference between 
the approved and new patch is trivial).


Thanks,
- Tom

2014-05-30  Tom de Vries  

	* lra-int.h (struct lra_reg): Add field actual_call_used_reg_set.
	* lra.c (initialize_lra_reg_info_element): Add init of
	actual_call_used_reg_set field.
	(lra): Call lra_create_live_ranges before lra_inheritance for
	-fuse-caller-save.
	* lra-assigns.c (lra_assign): Allow call_used_regs to cross calls for
	-fuse-caller-save.
	* lra-constraints.c (need_for_call_save_p): Use actual_call_used_reg_set
	instead of call_used_reg_set for -fuse-caller-save.
	* lra-lives.c (process_bb_lives): Calculate actual_call_used_reg_set.

diff --git a/gcc/lra-assigns.c b/gcc/lra-assigns.c
index f7bb86b..03c2506 100644
--- a/gcc/lra-assigns.c
+++ b/gcc/lra-assigns.c
@@ -1460,12 +1460,13 @@ lra_assign (void)
   create_live_range_start_chains ();
   setup_live_pseudos_and_spill_after_risky_transforms (&all_spilled_pseudos);
 #ifdef ENABLE_CHECKING
-  for (i = FIRST_PSEUDO_REGISTER; i < max_regno; i++)
-if (lra_reg_info[i].nrefs != 0 && reg_renumber[i] >= 0
-	&& lra_reg_info[i].call_p
-	&& overlaps_hard_reg_set_p (call_used_reg_set,
-PSEUDO_REGNO_MODE (i), reg_renumber[i]))
-  gcc_unreachable ();
+  if (!flag_use_caller_save)
+for (i = FIRST_PSEUDO_REGISTER; i < max_regno; i++)
+  if (lra_reg_info[i].nrefs != 0 && reg_renumber[i] >= 0
+	  && lra_reg_info[i].call_p
+	  && overlaps_hard_reg_set_p (call_used_reg_set,
+  PSEUDO_REGNO_MODE (i), reg_renumber[i]))
+	gcc_unreachable ();
 #endif
   /* Setup insns to process on the next constraint pass.  */
   bitmap_initialize (&changed_pseudo_bitmap, ®_obstack);
diff --git a/gcc/lra-constraints.c b/gcc/lra-constraints.c
index 2df841a..7eb9dbc 100644
--- a/gcc/lra-constraints.c
+++ b/gcc/lra-constraints.c
@@ -4605,7 +4605,10 @@ need_for_call_save_p (int regno)
   lra_assert (regno >= FIRST_PSEUDO_REGISTER && reg_renumber[regno] >= 0);
   return (usage_insns[regno].calls_num < calls_num
 	  && (overlaps_hard_reg_set_p
-	  (call_used_reg_set,
+	  ((flag_use_caller_save &&
+		! hard_reg_set_empty_p (lra_reg_info[regno].actual_call_used_reg_set))
+	   ? lra_reg_info[regno].actual_call_used_reg_set
+	   : call_used_reg_set,
 	   PSEUDO_REGNO_MODE (regno), reg_renumber[regno])
 	  || HARD_REGNO_CALL_PART_CLOBBERED (reg_renumber[regno],
 		 PSEUDO_REGNO_MODE (regno;
diff --git a/gcc/lra-int.h b/gcc/lra-int.h
index 41c9849..3c89734 100644
--- a/gcc/lra-int.h
+++ b/gcc/lra-int.h
@@ -77,6 +77,10 @@ struct lra_reg
   /* The following fields are defined only for pseudos.	 */
   /* Hard registers with which the pseudo conflicts.  */
   HARD_REG_SET conflict_hard_regs;
+  /* Call used registers with which the pseudo conflicts, taking into account
+ the registers used by functions called from calls which cross the
+ pseudo.  */
+  HARD_REG_SET actual_call_used_reg_set;
   /* We assign hard registers to reload pseudos which can occur in few
  places.  So two hard register preferences are enough for them.
  The following fields define the preferred hard registers.	If
diff --git a/gcc/lra-lives.c b/gcc/lra-lives.c
index 8444ade..26ba0d2 100644
--- a/gcc/lra-lives.c
+++ b/gcc/lra-lives.c
@@ -624,6 +624,17 @@ process_bb_lives (basic_block bb, int &curr_point)
 
   if (call_p)
 	{
+	  if (flag_use_caller_save)
+	{
+	  HARD_REG_SET this_call_used_reg_set;
+	  get_call_reg_set_usage (curr_insn, &this_call_used_reg_set,
+  call_used_reg_set);
+
+	  EXECUTE_IF_SET_IN_SPARSESET (pseudos_live, j)
+		IOR_HARD_REG_SET (lra_reg_info[j].actual_call_used_reg_set,
+  this_call

RE: [PATCH, Fortran] PR61234: -Wuse-no-only

[VandeVondele Joost]

> I think it is really weird if a coding style warning is included in -Wall.

I have no strong opinion on this, I followed the -Wintrinsic-shadow example, 
and I'm happy to change things. 

Note however, that even the Fortran standard recommends the ONLY option for 
example for intrinsic modules, to guarantee that a program is portable to other 
processors and future versions of the standard, i.e. to avoid potential name 
conflicts (see Note 15.1 in F2003 standard).

[PATCH, i386] Enable fuse-caller-save for i386

[Tom de Vries]

Uros,

This patch enables the fuse-caller-save optimization for i386.

It sets the hook TARGET_CALL_FUSAGE_CONTAINS_NON_CALLEE_CLOBBERS to true.

The definition of the hook is:
...
set to true if all the calls in the current function contain clobbers in 
CALL_INSN_FUNCTION_USAGE for the registers that are clobbered by the call rather 
than by the callee, and are not already set or clobbered in the call pattern. 
Examples of such registers are registers used in PLTs and stubs, and temporary 
registers used in the call instruction but not present in the rtl pattern. 
Another way to formulate it is the registers not present in the rtl pattern that 
are clobbered by the call assuming the callee does not clobber any register. The 
default version of this hook is set to false.

...

Bootstrapped and reg-tested this patch on x86_64, no issues found.

Is it in fact safe to set this hook to true for i386? Are there clobbers which 
need to be added?


If it's safe to set this hook to true, OK for trunk?

Thanks,
- Tom
2014-05-30  Tom de Vries  

	* config/i386/i386.c (TARGET_CALL_FUSAGE_CONTAINS_NON_CALLEE_CLOBBERS):
	Redefine as true.

	* gcc.target/i386/fuse-caller-save.c: New test.
	* gcc.dg/ira-shrinkwrap-prep-1.c: Run with -fno-use-caller-save.
	* gcc.dg/ira-shrinkwrap-prep-2.c: Same.
---
 gcc/config/i386/i386.c   |  3 +++
 gcc/testsuite/gcc.dg/ira-shrinkwrap-prep-1.c |  2 +-
 gcc/testsuite/gcc.dg/ira-shrinkwrap-prep-2.c |  2 +-
 gcc/testsuite/gcc.target/i386/fuse-caller-save.c | 25 
 4 files changed, 30 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/i386/fuse-caller-save.c

diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 8827256..83d3ba3 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -47272,6 +47272,9 @@ ix86_atomic_assign_expand_fenv (tree *hold, tree *clear, tree *update)
 #undef TARGET_MODE_PRIORITY
 #define TARGET_MODE_PRIORITY ix86_mode_priority
 
+#undef TARGET_CALL_FUSAGE_CONTAINS_NON_CALLEE_CLOBBERS
+#define TARGET_CALL_FUSAGE_CONTAINS_NON_CALLEE_CLOBBERS true
+
 struct gcc_target targetm = TARGET_INITIALIZER;
 
 #include "gt-i386.h"
diff --git a/gcc/testsuite/gcc.dg/ira-shrinkwrap-prep-1.c b/gcc/testsuite/gcc.dg/ira-shrinkwrap-prep-1.c
index 171a2bd..fc7b142 100644
--- a/gcc/testsuite/gcc.dg/ira-shrinkwrap-prep-1.c
+++ b/gcc/testsuite/gcc.dg/ira-shrinkwrap-prep-1.c
@@ -1,5 +1,5 @@
 /* { dg-do compile { target { { x86_64-*-* && lp64 } || { powerpc*-*-* && lp64 } } } } */
-/* { dg-options "-O3 -fdump-rtl-ira -fdump-rtl-pro_and_epilogue"  } */
+/* { dg-options "-O3 -fdump-rtl-ira -fdump-rtl-pro_and_epilogue -fno-use-caller-save"  } */
 
 long __attribute__((noinline, noclone))
 foo (long a)
diff --git a/gcc/testsuite/gcc.dg/ira-shrinkwrap-prep-2.c b/gcc/testsuite/gcc.dg/ira-shrinkwrap-prep-2.c
index ed08494..2e5a9cf 100644
--- a/gcc/testsuite/gcc.dg/ira-shrinkwrap-prep-2.c
+++ b/gcc/testsuite/gcc.dg/ira-shrinkwrap-prep-2.c
@@ -1,5 +1,5 @@
 /* { dg-do compile { target { { x86_64-*-* && lp64 } || { powerpc*-*-* && lp64 } } } } */
-/* { dg-options "-O3 -fdump-rtl-ira -fdump-rtl-pro_and_epilogue"  } */
+/* { dg-options "-O3 -fdump-rtl-ira -fdump-rtl-pro_and_epilogue -fno-use-caller-save"  } */
 
 long __attribute__((noinline, noclone))
 foo (long a)
diff --git a/gcc/testsuite/gcc.target/i386/fuse-caller-save.c b/gcc/testsuite/gcc.target/i386/fuse-caller-save.c
new file mode 100644
index 000..ff77d81
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/fuse-caller-save.c
@@ -0,0 +1,25 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fuse-caller-save" } */
+/* Testing -fuse-caller-save optimization option.  */
+
+static int __attribute__((noinline))
+bar (int x)
+{
+  return x + 3;
+}
+
+int __attribute__((noinline))
+foo (int y)
+{
+  return y + bar (y);
+}
+
+int
+main (void)
+{
+  return !(foo (5) == 13);
+}
+
+/* { dg-final { scan-assembler-not "\.cfi_def_cfa_offset"  } } */
+/* { dg-final { scan-assembler-not "\.cfi_offset"  } } */
+
-- 
1.9.1

Re: [PATCH, i386] Enable fuse-caller-save for i386

[Uros Bizjak]

On Fri, May 30, 2014 at 11:45 AM, Tom de Vries  wrote:

> This patch enables the fuse-caller-save optimization for i386.
>
> It sets the hook TARGET_CALL_FUSAGE_CONTAINS_NON_CALLEE_CLOBBERS to true.
>
> The definition of the hook is:
> ...
> set to true if all the calls in the current function contain clobbers in
> CALL_INSN_FUNCTION_USAGE for the registers that are clobbered by the call
> rather than by the callee, and are not already set or clobbered in the call
> pattern. Examples of such registers are registers used in PLTs and stubs,
> and temporary registers used in the call instruction but not present in the
> rtl pattern. Another way to formulate it is the registers not present in the
> rtl pattern that are clobbered by the call assuming the callee does not
> clobber any register. The default version of this hook is set to false.
> ...
>
> Bootstrapped and reg-tested this patch on x86_64, no issues found.
>
> Is it in fact safe to set this hook to true for i386? Are there clobbers
> which need to be added?
>
> If it's safe to set this hook to true, OK for trunk?

AFAIK, this is true for all targets, including cross-calls between MS
and SYSV ABIs, so I'd say OK.

Uros.

Re: [patch ping] libstdc++ testsuite cxxflags

[Jonathan Wakely]

On 30/05/14 08:53 +0100, Ramana Radhakrishnan wrote:

With all the other build breakages in the past week,  I've just
started seeing the first set of testresults from an auto-tester. It
looks like on a cross test using rhe5 / x86_64  with the version of
tcl8.4 I'm using I see the same errors that David saw.

The testsuite starts running if I tried the above

regexp ".*-O" $cxxflags

Is this going to be applied - what gives ?


Fixed with the attached patch.

Tested x86_64-linux (but onnly with Tcl 8.5), committed to trunk.


commit 8e72d35ed67a51df88c359249590e266c476044e
Author: Jonathan Wakely 
Date:   Fri May 30 11:10:57 2014 +0100

* testsuite/lib/libstdc++.exp (libstdc++_init): Adjust regexp to
work with previous versions of Tcl.

diff --git a/libstdc++-v3/testsuite/lib/libstdc++.exp 
b/libstdc++-v3/testsuite/lib/libstdc++.exp
index 2b2a38b..d91bed6 100644
--- a/libstdc++-v3/testsuite/lib/libstdc++.exp
+++ b/libstdc++-v3/testsuite/lib/libstdc++.exp
@@ -283,7 +283,7 @@ proc libstdc++_init { testfile } {
 append cxxflags " "
 append cxxflags [getenv CXXFLAGS]
 
-if ![regexp "\-O" $cxxflags] {
+if ![regexp ".*-O" $cxxflags] {
append cxxflags " -g -O2"
 }
 

Script for generating libstdc++ web docs for releases

[Jonathan Wakely]

This script automates the process of creating the libstdc++ release
docs in various formats. I didn't try to integrate it with the
update_web_docs_svn script because there are a lot of dependencies
which aren't installed on sourceware.org anyway, so it needs to be run
on another machine (but at least it's just one script now).

There's a small kluge needed for the 4.7 branch which I'll remove once
that branch is closed.

Tested on trunk, 4.9, 4.8 and 4.7, committed to trunk.

The wwwdocs patch for releasing.html is also attached.
commit 32a0c3ecbf8fee5c17f7fb89f6d755967f8d00b8
Author: Jonathan Wakely 
Date:   Thu May 29 16:53:52 2014 +0100

	* generate_libstdcxx_web_docs: New script.

diff --git a/maintainer-scripts/generate_libstdcxx_web_docs b/maintainer-scripts/generate_libstdcxx_web_docs
new file mode 100644
index 000..700e522
--- /dev/null
+++ b/maintainer-scripts/generate_libstdcxx_web_docs
@@ -0,0 +1,56 @@
+#!/bin/bash
+# Generate the libstdc++ onlinedocs for a GCC release
+# i.e. http://gcc.gnu.org/onlinedocs/gcc-x.y.z/libstdc++*
+
+SRCDIR=${1}
+DOCSDIR=${2}
+
+if ! [ $# -eq 2 -a -x "${SRCDIR}/configure" -a -d "${DOCSDIR}" ]
+then
+  echo "Usage: $0  " >&2
+  exit 1
+fi
+
+set -e
+
+# Check we have some of the required tools
+for i in doxygen dot dblatex pdflatex makeindex
+do
+  echo -n "Checking for $i... "
+  which $i
+done
+
+start=$PWD
+WORKDIR=`mktemp -d $PWD/build.XX`
+DESTDIR=`mktemp -d $PWD/dest.XX`
+cd $WORKDIR
+disabled_libs=
+for dir in ${SRCDIR}/lib*
+do
+  dir="${dir##*/}"
+  [ $dir == 'libstdc++-v3' ] || disabled_libs="$disabled_libs --disable-$dir"
+done
+set -x
+${SRCDIR}/configure --enable-languages=c,c++ --disable-gcc $disabled_libs --docdir=/docs
+eval `grep '^target=' config.log`
+make configure-target
+make -C $target/libstdc++-v3 doc-install-html doc-install-xml doc-install-pdf DESTDIR=$DESTDIR
+cd $DESTDIR/docs
+mkdir libstdc++
+for which in api manual
+do
+  if [ -f libstdc++-$which-single.xml ] # Only needed for GCC 4.7.x
+  then
+mv libstdc++-$which-single.xml libstdc++-$which.xml
+  fi
+  gzip --best libstdc++-$which.xml
+  gzip --best libstdc++-$which.pdf
+  mv libstdc++-$which{.html,-html}
+  tar czf libstdc++-$which-html.tar.gz libstdc++-$which-html
+  mv libstdc++-$which-html libstdc++/$which
+done
+mv *.gz libstdc++ $DOCSDIR/
+cd $start
+rm -r $WORKDIR
+rm -r $DESTDIR
+
Index: htdocs/releasing.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/releasing.html,v
retrieving revision 1.41
diff -u -r1.41 releasing.html
--- htdocs/releasing.html   22 Mar 2013 14:54:01 -  1.41
+++ htdocs/releasing.html   30 May 2014 10:18:53 -
@@ -86,6 +86,15 @@
 onlinedocs/version-number/index.html by copying it
 from a previous release and adjust it.
 
+Generate online libstdc++ documentation with the
+maintainer-scripts/generate_libstdcxx_web_docs script on trunk.
+That currently can't be done on sourceware.org due to dependencies on a
+number of DocBook and LaTeX packages. The script takes two arguments, the
+root of the GCC sources (for the new release) and the output directory
+for the generated files.  All the output that gets created should be placed
+in the same onlinedocs/version-number/ directory
+as the other documentation for the release.
+
 Update the online-documentation links in changes.html
 to point to the online-documentation for the branch.
 

Re: Patch RFA: Move x86 _mm_pause out of pragma target("sse") scope

[Kirill Yukhin]

Hello Ian, Uroš,
On 30 May 09:19, Uros Bizjak wrote:
> Hello!
> 
> > This error is because _mm_pause is defined in the scope of #pragma GCC
> > target("sse").  But _mm_pause, which simply generates the pause
> > instruction, does not require SSE support.  The pause instruction has
> > nothing really to do with SSE, and it works on all x86 processors (on
> > processors that do not explicitly recognize it, it is a nop).
> >
> > I propose the following patch, which moves _mm_pause out of the pragma
> > target scope.
> >
> > I know that x86intrin.h provides a similar intrinsic, __pause, but I
> > think it's worth making _mm_pause work reasonably as well.
> >
> > I'm running a full testsuite run.  OK for mainline if it passes?
> >
> > gcc/ChangeLog:
> >
> > 2014-05-29  Ian Lance Taylor  
> >
> > * config/i386/xmmintrin.h (_mm_pause): Move out of scope of pragma
> > target("sse").
> >
> > gcc/testsuite/ChangeLog:
> >
> > 2014-05-29  Ian Lance Taylor  
> >
> > * gcc.target/i386/pause-2.c: New test.
> 
> The patch looks OK to me, but please wait a day or two for possible
> comments (compatibility, etc) from Kirill.
That is definetely a bug and I see no compatibility issues in the fix.

The only nit I see: maybe it'd be better to put this cpuid-less intrinsic
into immintin.h? xmmintrin.h serves for SSE.

--
Thanks, K

Re: Patch RFA: Move x86 _mm_pause out of pragma target("sse") scope

[Jakub Jelinek]

On Fri, May 30, 2014 at 03:41:22PM +0400, Kirill Yukhin wrote:
> That is definetely a bug and I see no compatibility issues in the fix.
> 
> The only nit I see: maybe it'd be better to put this cpuid-less intrinsic
> into immintin.h? xmmintrin.h serves for SSE.

Wouldn't that be an API compatibility problem?
I mean, xmmintrin.h header isn't a new header that can be only included
as part of immintrin.h or x86intrin.h, and people who include xmmintrin.h
and expect to find _mm_pause would suddenly get compiler errors.

Jakub

Re: Patch RFA: Move x86 _mm_pause out of pragma target("sse") scope

[Kirill Yukhin]

On 30 May 13:45, Jakub Jelinek wrote:
> On Fri, May 30, 2014 at 03:41:22PM +0400, Kirill Yukhin wrote:
> > That is definetely a bug and I see no compatibility issues in the fix.
> > 
> > The only nit I see: maybe it'd be better to put this cpuid-less intrinsic
> > into immintin.h? xmmintrin.h serves for SSE.
> 
> Wouldn't that be an API compatibility problem?
> I mean, xmmintrin.h header isn't a new header that can be only included
> as part of immintrin.h or x86intrin.h, and people who include xmmintrin.h
> and expect to find _mm_pause would suddenly get compiler errors.
Makes sense. Moreover we already have cpuid-less _mm_prefetch () in that
header. So, I take it back.

--
Thanks, K

[PATCH, Pointer Bounds Checker 15/x] Keep instrumented versions

[Ilya Enkovich]

Hi,

Before any instrumentation happens, instrumentation clones do not actually have 
any uses and thus may be removed.  This patch fixes it by forbiding removal of 
not instrumented instrumentation clones.

Bootstrapped and tested on linux-x86_64.

Thanks,
Ilya
--
gcc/

2014-05-30  Ilya Enkovich  

* cgraph.c (cgraph_can_remove_if_no_direct_calls_and_refs_p): Keep
all not instrumented instrumentation clones alive.


diff --git a/gcc/cgraph.c b/gcc/cgraph.c
index 6210c68..1f684c2 100644
--- a/gcc/cgraph.c
+++ b/gcc/cgraph.c
@@ -2425,6 +2425,12 @@ bool
 cgraph_can_remove_if_no_direct_calls_and_refs_p (struct cgraph_node *node)
 {
   gcc_assert (!node->global.inlined_to);
+  /* Instrumentation clones should not be removed before
+ instrumentation happens.  New callers may appear after
+ instrumentation.  */
+  if (node->instrumentation_clone
+  && !chkp_function_instrumented_p (node->decl))
+return false;
   /* Extern inlines can always go, we will use the external definition.  */
   if (DECL_EXTERNAL (node->decl))
 return true;

[PATCH, Pointer Bounds Checker 16/x] Register statically initialized pointers

[Ilya Enkovich]

Hi,

This patchs registers all statically initialized vars in Pointer Bounds 
Checker. It allows to build proper Bounds Tables for statically initialized 
pointers.

Bootstrapped and tested on linux-x86_64.

Thanks,
Ilya
--
gcc/

2014-05-30  Ilya Enkovich  

* cgraphunit.c: Include tree-chkp.h.
(varpool_finalize_decl): Register statically
initialized decls in Pointer Bounds Checker.


diff --git a/gcc/cgraphunit.c b/gcc/cgraphunit.c
index ceb4060..c5c 100644
--- a/gcc/cgraphunit.c
+++ b/gcc/cgraphunit.c
@@ -210,6 +210,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "pass_manager.h"
 #include "tree-nested.h"
 #include "gimplify.h"
+#include "tree-chkp.h"
 
 /* Queue of cgraph nodes scheduled to be added into cgraph.  This is a
secondary queue used during optimization to accommodate passes that
@@ -839,6 +840,9 @@ varpool_finalize_decl (tree decl)
   if (cgraph_state == CGRAPH_STATE_FINISHED
   || (!flag_toplevel_reorder && cgraph_state == CGRAPH_STATE_EXPANSION))
 varpool_assemble_decl (node);
+
+  if (DECL_INITIAL (decl))
+chkp_register_var_initializer (decl);
 }
 
 /* EDGE is an polymorphic call.  Mark all possible targets as reachable

Re: [PATCH] Do not build libsanitizer also for powerpc*-*-linux*

[Peter Bergner]

On Thu, 2014-05-29 at 14:07 -0500, Peter Bergner wrote:
> On Wed, 2014-05-28 at 09:36 +0200, Thomas Schwinge wrote:
> > This is being discussed in the thread at
> > .  Until that
> > has been resolved, I do agree to check in the following patch (and have
> > successfully tested it, but cannot formally approve it for commit; thus
> > copying the libsanitizer maintainers):
> 
> The re-enablement patch was submitted to the llvm mailing list here:
> 
>   
> http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20140526/219249.html
> 
> Once that is committed and merged into gcc, we can re-enable building
> libsanitizer for powerpc*-linux.

Ok, it was committed upstream as revision 209879.  Kostya, can we get
this merged into gcc trunk and powerpc*-linux re-enabled again?  Thanks.

Peter

Re: [PATCH] Do not build libsanitizer also for powerpc*-*-linux*

[Jakub Jelinek]

On Fri, May 30, 2014 at 08:09:22AM -0500, Peter Bergner wrote:
> On Thu, 2014-05-29 at 14:07 -0500, Peter Bergner wrote:
> > On Wed, 2014-05-28 at 09:36 +0200, Thomas Schwinge wrote:
> > > This is being discussed in the thread at
> > > .  Until that
> > > has been resolved, I do agree to check in the following patch (and have
> > > successfully tested it, but cannot formally approve it for commit; thus
> > > copying the libsanitizer maintainers):
> > 
> > The re-enablement patch was submitted to the llvm mailing list here:
> > 
> >   
> > http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20140526/219249.html
> > 
> > Once that is committed and merged into gcc, we can re-enable building
> > libsanitizer for powerpc*-linux.
> 
> Ok, it was committed upstream as revision 209879.  Kostya, can we get
> this merged into gcc trunk and powerpc*-linux re-enabled again?  Thanks.

I've cherry-picked the two upstream commits and after testing on
x86_64-linux/i686-linux committed to trunk.

2014-05-30  Jakub Jelinek  

* sanitizer_common/sanitizer_stacktrace.cc: Cherry pick upstream
r209879.
* sanitizer_common/sanitizer_common.h: Likewise.
* asan/asan_mapping.h: Likewise.
* asan/asan_linux.cc: Likewise.
* tsan/tsan_mman.cc: Cherry pick upstream r209744.
* sanitizer_common/sanitizer_allocator.h: Likewise.

--- libsanitizer/sanitizer_common/sanitizer_stacktrace.cc   (revision 
209878)
+++ libsanitizer/sanitizer_common/sanitizer_stacktrace.cc   (revision 
209879)
@@ -18,11 +18,13 @@
 namespace __sanitizer {
 
 uptr StackTrace::GetPreviousInstructionPc(uptr pc) {
-#ifdef __arm__
+#if defined(__arm__)
   // Cancel Thumb bit.
   pc = pc & (~1);
-#endif
-#if defined(__sparc__)
+#elif defined(__powerpc__) || defined(__powerpc64__)
+  // PCs are always 4 byte aligned.
+  return pc - 4;
+#elif defined(__sparc__)
   return pc - 8;
 #else
   return pc - 1;
--- libsanitizer/sanitizer_common/sanitizer_common.h(revision 209878)
+++ libsanitizer/sanitizer_common/sanitizer_common.h(revision 209879)
@@ -28,7 +28,11 @@ struct StackTrace;
 const uptr kWordSize = SANITIZER_WORDSIZE / 8;
 const uptr kWordSizeInBits = 8 * kWordSize;
 
-const uptr kCacheLineSize = 64;
+#if defined(__powerpc__) || defined(__powerpc64__)
+  const uptr kCacheLineSize = 128;
+#else
+  const uptr kCacheLineSize = 64;
+#endif
 
 const uptr kMaxPathLength = 512;
 
--- libsanitizer/asan/asan_mapping.h(revision 209878)
+++ libsanitizer/asan/asan_mapping.h(revision 209879)
@@ -87,6 +87,7 @@ static const u64 kDefaultShadowOffset64
 static const u64 kDefaultShort64bitShadowOffset = 0x7FFF8000;  // < 2G.
 static const u64 kAArch64_ShadowOffset64 = 1ULL << 36;
 static const u64 kMIPS32_ShadowOffset32 = 0x0aaa8000;
+static const u64 kPPC64_ShadowOffset64 = 1ULL << 41;
 static const u64 kFreeBSD_ShadowOffset32 = 1ULL << 30;  // 0x4000
 static const u64 kFreeBSD_ShadowOffset64 = 1ULL << 46;  // 0x4000
 
@@ -109,6 +110,8 @@ static const u64 kFreeBSD_ShadowOffset64
 # else
 #  if defined(__aarch64__)
 #define SHADOW_OFFSET kAArch64_ShadowOffset64
+#  elif defined(__powerpc64__)
+#define SHADOW_OFFSET kPPC64_ShadowOffset64
 #  elif SANITIZER_FREEBSD
 #define SHADOW_OFFSET kFreeBSD_ShadowOffset64
 #  elif SANITIZER_MAC
--- libsanitizer/asan/asan_linux.cc (revision 209878)
+++ libsanitizer/asan/asan_linux.cc (revision 209879)
@@ -188,6 +188,13 @@ void GetPcSpBp(void *context, uptr *pc,
   *bp = ucontext->uc_mcontext.gregs[REG_EBP];
   *sp = ucontext->uc_mcontext.gregs[REG_ESP];
 # endif
+#elif defined(__powerpc__) || defined(__powerpc64__)
+  ucontext_t *ucontext = (ucontext_t*)context;
+  *pc = ucontext->uc_mcontext.regs->nip;
+  *sp = ucontext->uc_mcontext.regs->gpr[PT_R1];
+  // The powerpc{,64}-linux ABIs do not specify r31 as the frame
+  // pointer, but GCC always uses r31 when we need a frame pointer.
+  *bp = ucontext->uc_mcontext.regs->gpr[PT_R31];
 #elif defined(__sparc__)
   ucontext_t *ucontext = (ucontext_t*)context;
   uptr *stk_ptr;
--- libsanitizer/tsan/tsan_mman.cc  (revision 209743)
+++ libsanitizer/tsan/tsan_mman.cc  (revision 209744)
@@ -217,19 +217,15 @@ using namespace __tsan;
 
 extern "C" {
 uptr __tsan_get_current_allocated_bytes() {
-  u64 stats[AllocatorStatCount];
+  uptr stats[AllocatorStatCount];
   allocator()->GetStats(stats);
-  u64 m = stats[AllocatorStatMalloced];
-  u64 f = stats[AllocatorStatFreed];
-  return m >= f ? m - f : 1;
+  return stats[AllocatorStatAllocated];
 }
 
 uptr __tsan_get_heap_size() {
-  u64 stats[AllocatorStatCount];
+  uptr stats[AllocatorStatCount];
   allocator()->GetStats(stats);
-  u64 m = stats[AllocatorStatMmapped];
-  u64 f = stats[AllocatorStatUnmapped];
-  return m >= f ? m - f : 1;
+  return stats[AllocatorStatMapped];
 }
 
 uptr __tsan_get_free_bytes() {
--- libsanitizer/sanitizer_common/sanitizer_allocator.h (revision 209743)
+

libgo patch committed: Use _mm_pause rather than __builtin_ia32_pause

[Ian Lance Taylor]

This patch based on one by Peter Collingbourne changes libgo to use the
somewhat portable _mm_pause intrinsic rather than the GCC-specific
__builtin_ia32_pause builtin function.  This makes it easier to compile
libgo with compilers other than GCC.  Bootstrapped and ran Go testsuite
on x86_64-unknown-linux-gnu.  Committed to mainline.

Ian

diff -r 4d88292e0727 libgo/runtime/yield.c
--- a/libgo/runtime/yield.c	Thu May 29 13:21:58 2014 -0700
+++ b/libgo/runtime/yield.c	Fri May 30 06:51:16 2014 -0700
@@ -14,6 +14,10 @@
 #include 
 #endif
 
+#if defined (__i386__) || defined (__x86_64__)
+#include 
+#endif
+
 #include "runtime.h"
 
 /* Spin wait.  */
@@ -26,7 +30,7 @@
   for (i = 0; i < cnt; ++i)
 {
 #if defined (__i386__) || defined (__x86_64__)
-  __builtin_ia32_pause ();
+  _mm_pause ();
 #endif
 }
 }

Re: [C++ Patch] PR 57543

[Jason Merrill]

On 05/29/2014 03:17 PM, Paolo Carlini wrote:

I put together the below which already passes testing.


Thanks!


+  bool do_inject = this_type && !dependent_type_p (this_type);


!dependent_type_p should be !dependent_scope_p, or perhaps even 
CLASS_TYPE_P.  It should be OK to inject a this pointer of a dependent 
class, and we might need it to get the right semantics.


You also need to propagate the flag in a bunch of other places: 
everywhere we call build_method_type_directly ought to cover it.


Jason

Re: [C++ Patch] PR 57543

[Paolo Carlini]

Hi,

On 05/30/2014 04:13 PM, Jason Merrill wrote:

On 05/29/2014 03:17 PM, Paolo Carlini wrote:

I put together the below which already passes testing.


Thanks!

You are welcome. Let's finish this, then ;)



+  bool do_inject = this_type && !dependent_type_p (this_type);


!dependent_type_p should be !dependent_scope_p, or perhaps even 
CLASS_TYPE_P.  It should be OK to inject a this pointer of a dependent 
class, and we might need it to get the right semantics.

I suspected that. I'll experiment with the latter, or in case the former.
You also need to propagate the flag in a bunch of other places: 
everywhere we call build_method_type_directly ought to cover it.
Agreed, I spotted a few places. What about build_function_type? I think 
it's the same issue, right? Because in that case we don't have any 
problem with the injection of this but we want to propagate the flag in 
order to eventually have tsubst_function_type substituting in the right 
order.


Paolo.

Re: [C++ Patch] PR 57543

[Jason Merrill]

On 05/30/2014 10:21 AM, Paolo Carlini wrote:

You also need to propagate the flag in a bunch of other places:
everywhere we call build_method_type_directly ought to cover it.

Agreed, I spotted a few places. What about build_function_type? I think
it's the same issue, right?


Right, I was just thinking that the relevant uses of build_function_type 
will be near calls to build_method_type_directly.  :)


Jason

Re: [PATCH, libgfortran] Add overflow check to xmalloc

[Janne Blomqvist]

PING

On Tue, May 20, 2014 at 12:42 AM, Janne Blomqvist
 wrote:
> On Thu, May 15, 2014 at 1:00 AM, Janne Blomqvist
>  wrote:
>> Hi,
>>
>> a common malloc() pattern is "malloc(num_foo * sizeof(foo_t)", that
>> is, create space for an array of type foo_t with num_foo elements.
>> There is a slight danger here in that the multiplication can overflow
>> and wrap around, and then the caller thinks it has a larger array than
>> what malloc has actually created. The attached patch changes the
>> libgfortran xmalloc() function to have an API similar to calloc() with
>> two arguments, and the implementation checks for wraparound.
>
> Hello,
>
> attached is an updated patch which instead introduces a new function,
> xmallocarray, with the overflow check, and leaves the existing xmalloc
> as is. Thus avoiding the extra checking in the common case where one
> of the arguments to xmallocarray would be 1.
>
> Tested on x86_64-unknown-linux-gnu, Ok for trunk?
>
> 2014-05-20  Janne Blomqvist  
>
> * libgfortran.h (xmallocarray): New prototype.
> * runtime/memory.c (xmallocarray): New function.
> (xcalloc): Check for nonzero separately instead of multiplying.
> * generated/*.c: Regenerated.
> * intrinsics/cshift0.c (cshift0): Call xmallocarray instead of
> xmalloc.
> * intrinsics/eoshift0.c (eoshift0): Likewise.
> * intrinsics/eoshift2.c (eoshift2): Likewise.
> * intrinsics/pack_generic.c (pack_internal): Likewise.
> (pack_s_internal): Likewise.
> * intrinsics/reshape_generic.c (reshape_internal): Likewise.
> * intrinsics/spread_generic.c (spread_internal): Likewise.
> (spread_internal_scalar): Likewise.
> * intrinsics/string_intrinsics_inc.c (string_trim): Likewise.
> (string_minmax): Likewise.
> * intrinsics/transpose_generic.c (transpose_internal): Likewise.
> * intrinsics/unpack_generic.c (unpack_internal): Likewise.
> * io/list_read.c (nml_touch_nodes): Don't cast xmalloc return value.
> * io/transfer.c (st_set_nml_var): Call xmallocarray instead of
> xmalloc.
> * io/unit.c (get_internal_unit): Likewise.
> (filename_from_unit): Don't cast xmalloc return value.
> * io/write.c (nml_write_obj): Likewise, formatting.
> * m4/bessel.m4 (bessel_jn_r'rtype_kind`): Call xmallocarray
> instead of xmalloc.
> (besse_yn_r'rtype_kind`): Likewise.
> * m4/cshift1.m4 (cshift1): Likewise.
> * m4/eoshift1.m4 (eoshift1): Likewise.
> * m4/eoshift3.m4 (eoshift3): Likewise.
> * m4/iforeach.m4: Likewise.
> * m4/ifunction.m4: Likewise.
> * m4/ifunction_logical.m4 (name`'rtype_qual`_'atype_code):
> Likewise.
> * m4/in_pack.m4 (internal_pack_'rtype_ccode`): Likewise.
> * m4/matmul.m4 (matmul_'rtype_code`): Likewise.
> * m4/matmull.m4 (matmul_'rtype_code`): Likewise.
> * m4/pack.m4 (pack_'rtype_code`): Likewise.
> * m4/reshape.m4 (reshape_'rtype_ccode`): Likewise.
> * m4/shape.m4 (shape_'rtype_kind`): Likewise.
> * m4/spread.m4 (spread_'rtype_code`): Likewise.
> (spread_scalar_'rtype_code`): Likewise.
> * m4/transpose.m4 (transpose_'rtype_code`): Likewise.
> * m4/unpack.m4 (unpack0_'rtype_code`): Likewise.
> (unpack1_'rtype_code`): Likewise.
> * runtime/convert_char.c (convert_char1_to_char4): Likewise.
> (convert_char4_to_char1): Simplify.
> * runtime/environ.c (init_unformatted): Call xmallocarray instead
> of xmalloc.
> * runtime/in_pack_generic.c (internal_pack): Likewise.
>
>
>
>
> --
> Janne Blomqvist



-- 
Janne Blomqvist

Re: C++ PATCH for c++/60992 (lambda and constant variable)

[Jason Merrill]

On 05/02/2014 03:46 PM, Jason Merrill wrote:

My change to avoid building a dummy variable in a nested function turns
out to have been too aggressive; in this case, we have a reference to a
local const variable in the type of an array that we're capturing.  It
seems safe enough to make dummy copies of const and static variables
when instantiating a lambda operator, so let's do that.


This was incomplete; we also need to instantiate the initializer.

And as long as we're handling this in some cases, let's stop returning 
the identifier from finish_id_expression.


Tested x86_64-pc-linux-gnu, applying to trunk.


commit 08e64eaaa5576eba62851b374fe734ff762bcc7e
Author: Jason Merrill 
Date:   Tue May 27 17:12:35 2014 -0400

	PR c++/60992
	* pt.c (tsubst_init): Split out from...
	(tsubst_expr) [DECL_EXPR]: Here.
	(tsubst_copy) [VAR_DECL]: Use it.
	* semantics.c (finish_id_expression): Return the decl for static/const.

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 0b3cd7f..a24e044 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -12513,6 +12513,37 @@ tsubst_qualified_id (tree qualified_id, tree args,
   return expr;
 }
 
+/* tsubst the initializer for a VAR_DECL.  INIT is the unsubstituted
+   initializer, DECL is the substituted VAR_DECL.  Other arguments are as
+   for tsubst.  */
+
+static tree
+tsubst_init (tree init, tree decl, tree args,
+	 tsubst_flags_t complain, tree in_decl)
+{
+  if (!init)
+return NULL_TREE;
+
+  init = tsubst_expr (init, args, complain, in_decl, false);
+
+  if (!init)
+{
+  /* If we had an initializer but it
+	 instantiated to nothing,
+	 value-initialize the object.  This will
+	 only occur when the initializer was a
+	 pack expansion where the parameter packs
+	 used in that expansion were of length
+	 zero.  */
+  init = build_value_init (TREE_TYPE (decl),
+			   complain);
+  if (TREE_CODE (init) == AGGR_INIT_EXPR)
+	init = get_target_expr_sfinae (init, complain);
+}
+
+  return init;
+}
+
 /* Like tsubst, but deals with expressions.  This function just replaces
template parms; to finish processing the resultant expression, use
tsubst_copy_and_build or tsubst_expr.  */
@@ -12670,11 +12701,34 @@ tsubst_copy (tree t, tree args, tsubst_flags_t complain, tree in_decl)
 		 local static or constant.  Building a new VAR_DECL
 		 should be OK in all those cases.  */
 		  r = tsubst_decl (t, args, complain);
-		  if (decl_constant_var_p (r))
-		/* A use of a local constant must decay to its value.  */
-		return integral_constant_value (r);
+		  if (decl_maybe_constant_var_p (r))
+		{
+		  /* We can't call cp_finish_decl, so handle the
+			 initializer by hand.  */
+		  tree init = tsubst_init (DECL_INITIAL (t), r, args,
+	   complain, in_decl);
+		  if (!processing_template_decl)
+			init = maybe_constant_init (init);
+		  if (processing_template_decl
+			  ? potential_constant_expression (init)
+			  : reduced_constant_expression_p (init))
+			DECL_INITIALIZED_BY_CONSTANT_EXPRESSION_P (r)
+			  = TREE_CONSTANT (r) = true;
+		  DECL_INITIAL (r) = init;
+		}
 		  gcc_assert (cp_unevaluated_operand || TREE_STATIC (r)
+			  || decl_constant_var_p (r)
 			  || errorcount || sorrycount);
+		  if (!processing_template_decl)
+		{
+		  if (TREE_STATIC (r))
+			rest_of_decl_compilation (r, toplevel_bindings_p (),
+		  at_eof);
+		  else if (decl_constant_var_p (r))
+			/* A use of a local constant decays to its value.
+			   FIXME update for core DR 696.  */
+			return integral_constant_value (r);
+		}
 		  return r;
 		}
 	}
@@ -13544,26 +13598,7 @@ tsubst_expr (tree t, tree args, tsubst_flags_t complain, tree in_decl,
 			init = cp_fname_init (name, &TREE_TYPE (decl));
 		  }
 		else
-		  {
-			tree t = RECUR (init);
-
-			if (init && !t)
-			  {
-			/* If we had an initializer but it
-			   instantiated to nothing,
-			   value-initialize the object.  This will
-			   only occur when the initializer was a
-			   pack expansion where the parameter packs
-			   used in that expansion were of length
-			   zero.  */
-			init = build_value_init (TREE_TYPE (decl),
-		 complain);
-			if (TREE_CODE (init) == AGGR_INIT_EXPR)
-			  init = get_target_expr_sfinae (init, complain);
-			  }
-			else
-			  init = t;
-		  }
+		  init = tsubst_init (init, decl, args, complain, in_decl);
 
 		if (VAR_P (decl))
 		  const_init = (DECL_INITIALIZED_BY_CONSTANT_EXPRESSION_P
diff --git a/gcc/cp/semantics.c b/gcc/cp/semantics.c
index edab330..396a893 100644
--- a/gcc/cp/semantics.c
+++ b/gcc/cp/semantics.c
@@ -3166,12 +3166,7 @@ finish_id_expression (tree id_expression,
   else if (TREE_STATIC (decl)
 	   /* It's not a use (3.2) if we're in an unevaluated context.  */
 	   || cp_unevaluated_operand)
-	{
-	  if (processing_template_decl)
-	/* For a use of an outer static/unevaluated va

C++ PATCH for c++/56947

[Jason Merrill]

Here the change to look up static/const vars from the enclosing context 
of a lambda again at instantiation time was breaking on 4.7 because we 
weren't instantiating the lambda op() until EOF.  Fixed this way in 4.7; 
in later versions we already instantiate it early as part of the 
TAG_DEFN.  Added the testcase and an assert to the trunk.


Tested x86_64-pc-linux-gnu, applying to trunk and 4.7.
commit f2301b6e7e569c4312c0a3844ac13f76459af597
Author: Jason Merrill 
Date:   Tue May 27 17:12:35 2014 -0400

	PR c++/56947
	* pt.c (instantiate_decl): Don't defer instantiation of a nested
	function.

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index f2b2f9b..e1cc59d 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -18191,6 +18191,7 @@ instantiate_decl (tree d, int defer_ok,
  if the variable has a constant value the referring expression can
  take advantage of that fact.  */
   if (TREE_CODE (d) == VAR_DECL
+  || decl_function_context (d)
   || DECL_DECLARED_CONSTEXPR_P (d))
 defer_ok = 0;
 
diff --git a/gcc/testsuite/g++.dg/template/local8.C b/gcc/testsuite/g++.dg/template/local8.C
new file mode 100644
index 000..006bd8c
--- /dev/null
+++ b/gcc/testsuite/g++.dg/template/local8.C
@@ -0,0 +1,18 @@
+// PR c++/56947
+
+struct A
+{
+A (int);
+};
+
+template < typename >
+void Fn ()
+{
+const int kCapacity = 0;
+struct Q:A
+{
+Q ():A (kCapacity) { }
+};
+Q q;
+}
+template void Fn < int >();
commit 86b12872ec09b670b9be689d5c87c245b1745941
Author: Jason Merrill 
Date:   Thu May 29 17:22:36 2014 -0400

	PR c++/56947
	* pt.c (instantiate_decl): Check that defer_ok is not set for
	local class members.

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index a24e044..0d22fae 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -19696,6 +19696,11 @@ instantiate_decl (tree d, int defer_ok,
   if (external_p && !always_instantiate_p (d))
 return d;
 
+  /* Any local class members should be instantiated from the TAG_DEFN
+ with defer_ok == 0.  */
+  gcc_checking_assert (!defer_ok || !decl_function_context (d)
+		   || LAMBDA_TYPE_P (DECL_CONTEXT (d)));
+
   gen_tmpl = most_general_template (tmpl);
   gen_args = DECL_TI_ARGS (d);
 
diff --git a/gcc/testsuite/g++.dg/template/local8.C b/gcc/testsuite/g++.dg/template/local8.C
new file mode 100644
index 000..006bd8c
--- /dev/null
+++ b/gcc/testsuite/g++.dg/template/local8.C
@@ -0,0 +1,18 @@
+// PR c++/56947
+
+struct A
+{
+A (int);
+};
+
+template < typename >
+void Fn ()
+{
+const int kCapacity = 0;
+struct Q:A
+{
+Q ():A (kCapacity) { }
+};
+Q q;
+}
+template void Fn < int >();

[Patch ARM] PR 61154 - Define TARGET_SUPPORTS_WIDE_INT.

[Ramana Radhakrishnan]

Hi,

	This is the simplest patch to fix PR61154 that came after the wide-int 
merge. I've got a patch stack that tries to audit the use of GEN_INT vs 
gen_int_mode and the use of CONST_DOUBLE with VOIDmode in the backend 
but it's still not safe to go and TBH I'd like to deal with that 
separately given the current state of brokenness in the tree.


Tested with a bootstrap again today on top of 211072 and earlier 
regression tests showed no regressions.


Will apply once regression tests finish.

regards
Ramana

  Ramana Radhakrishnan  

   * config/arm/arm.h (TARGET_SUPPORTS_WIDE_INT): Define.
   * config/arm/arm.md (movdi splitter): Replace const_double_operand
 with immediate_operand.
Index: gcc/config/arm/arm.h
===
--- gcc/config/arm/arm.h(revision 211084)
+++ gcc/config/arm/arm.h(working copy)
@@ -2395,5 +2395,5 @@ extern const char *host_detect_local_cpu
 #endif
 
 #define DRIVER_SELF_SPECS MCPU_MTUNE_NATIVE_SPECS
-
+#define TARGET_SUPPORTS_WIDE_INT 1
 #endif /* ! GCC_ARM_H */
Index: gcc/config/arm/arm.md
===
--- gcc/config/arm/arm.md   (revision 211084)
+++ gcc/config/arm/arm.md   (working copy)
@@ -5990,7 +5990,7 @@ (define_insn "*arm_movdi"
 
 (define_split
   [(set (match_operand:ANY64 0 "arm_general_register_operand" "")
-   (match_operand:ANY64 1 "const_double_operand" ""))]
+   (match_operand:ANY64 1 "immediate_operand" ""))]
   "TARGET_32BIT
&& reload_completed
&& (arm_const_double_inline_cost (operands[1])

Re: ipa-visibility TLC 2/n

[David Edelsohn]

Honza,

I finally was able to bootstrap GCC on AIX yesterday. The bootstrap
works, but the testsuite results are in extremely bad shape: 250
failures in G++ testsuite and 470 failures in libstdc++ testsuite.

G++ previously had about 65 failures, mainly TLS and init. libstdc++
previously hovered around 12-14 failure.

This is unacceptable breakage and fallout from the recent changes.

- David

On Fri, May 30, 2014 at 3:20 AM, Richard Sandiford
 wrote:
> Jan Hubicka  writes:
>>> Jan Hubicka  writes:
>>> >> Richard Sandiford wrote the original section anchors implementation,
>>> >> so he would be a good person to comment about the interaction between
>>> >> aliases and section anchors.
>>> >
>>> > Thanks! Richard, does this patch seem sane?
>>>
>>> Looks good to me in principle, but with:
>>>
>>> > +  struct symtab_node *snode;
>>> >decl = SYMBOL_REF_DECL (symbol);
>>> > +
>>> > +  snode = symtab_node (decl);
>>> > +  if (snode->alias)
>>> > +   {
>>> > + rtx target = DECL_RTL (symtab_alias_ultimate_target
>>> > (snode)->decl);
>>> > + SYMBOL_REF_BLOCK_OFFSET (symbol) = SYMBOL_REF_BLOCK_OFFSET
>>> > (target);
>>> > + return;
>>> > +   }
>>>
>>> is SYMBOL_REF_BLOCK_OFFSET (target) guaranteed to be valid at this point?
>>> It looked at face value like you'd need a recursive call to 
>>> place_block_symbol
>>> on the target before the copy.
>>
>> My reading was that SYMBOL_REF_BLOCK_OFFSET is computed at DECL_RTL
>> calculation time. But you are right - it is done by validize_mem that
>> is not done by DECL_RTL.  Shall I just call it on target first?
>
> Yeah, sounds like calling place_block_symbol would be safer.
>
> IIRC, the reason I didn't do it at SET_DECL_RTL time is that some frontends
> tended to create placeholder decls that for whatever reason ended up with
> an initial DECL_RTL, then changed the properties of the decl later once
> more information was known.  (This was all many years ago.)
>
> Thanks,
> Richard

Re: [patch i386]: Expand sibling-tail-calls via accumulator register

[Richard Henderson]

On 05/30/2014 01:08 AM, Kai Tietz wrote:
> (define_predicate "sibcall_memory_operand"
>   (match_operand 0 "memory_operand")
> {
>   return CONSTANT_P (op);
> })

Surely that always returns false?  Surely XEXP (op, 0) so that you look at the
address, not the memory.


r~

Re: [PATCH, Pointer Bounds Checker 16/x] Register statically initialized pointers

[Jeff Law]

On 05/30/14 07:00, Ilya Enkovich wrote:

Hi,

This patchs registers all statically initialized vars in Pointer Bounds 
Checker. It allows to build proper Bounds Tables for statically initialized 
pointers.

Bootstrapped and tested on linux-x86_64.

Thanks,
Ilya
--
gcc/

2014-05-30  Ilya Enkovich  

* cgraphunit.c: Include tree-chkp.h.
(varpool_finalize_decl): Register statically
initialized decls in Pointer Bounds Checker.
This is fine for the trunk when all the other bounds checker stuff is 
approved.


jeff

Re: [PATCH, Pointer Bounds Checker 15/x] Keep instrumented versions

[Jeff Law]

On 05/30/14 06:56, Ilya Enkovich wrote:

Hi,

Before any instrumentation happens, instrumentation clones do not actually have 
any uses and thus may be removed.  This patch fixes it by forbiding removal of 
not instrumented instrumentation clones.

Bootstrapped and tested on linux-x86_64.

Thanks,
Ilya
--
gcc/

2014-05-30  Ilya Enkovich  

* cgraph.c (cgraph_can_remove_if_no_direct_calls_and_refs_p): Keep
all not instrumented instrumentation clones alive.

OK for the trunk when the rest of the bounds checker stuff is approved.

jeff

Re: ipa-visibility TLC 2/n

[Ramana Radhakrishnan]

On Thu, May 29, 2014 at 3:17 PM, Yufeng Zhang  wrote:
> Hi Honza,
>
> I can confirm that with your commit r211045 the arm-none-linux-gnueabi{hf}
> builds are OK now.  Thanks for the fix.

Testsuite regressions like


FAIL: g++.dg/ipa/devirt-21.C -std=gnu++1y (test for excess errors)
Excess errors:
src/gcc/gcc/testsuite/g++.dg/ipa/devirt-21.C:39:1: internal compiler
error: in gimple_get_virt_method_for_vtable, at gimple-fold.c:3273
0x9ed491 record_target_from_binfo
src/gcc/gcc/ipa-devirt.c:868
0x9ed574 record_target_from_binfo
gcc/gcc/ipa-devirt.c:885
0x9edb09 possible_polymorphic_call_targets_1
gcc/gcc/ipa-devirt.c:932
0x9eff59 possible_polymorphic_call_targets(tree_node*, long,
ipa_polymorphic_call_context, bool*, void**, int*)
gcc/gcc/ipa-devirt.c:1744
0xa19724 possible_polymorphic_call_targets
src/gcc/gcc/ipa-utils.h:121
0xa19724 walk_polymorphic_call_targets
src/gcc/gcc/ipa.c:151
0xa19724 symtab_remove_unreachable_nodes(bool, _IO_FILE*)
src/gcc/gcc/ipa.c:384
0xadc4d3 execute_todo
src/gcc/gcc/passes.c:1843

Number of unexpected g++ failures now up to 127 on arm-linux-gnueabi(hf).

regards
Ramana


>
> Yufeng
>
>
> On 05/28/14 22:56, Jan Hubicka wrote:
>>>
>>> Any update?
>>>
>>> I've managed to generate a simple test case from
>>> libstdc++-v3/src/c++98/strstream.cc which reproduces the issue on
>>> ARM that Ramana has reported previously:
>>>
>>>
>>> template   struct char_traits;
>>>
>>> template
>>> class basic_ios
>>> {
>>> };
>>>
>>> template  >
>>> class basic_istream : virtual public basic_ios<_CharT, _Traits>
>>> {
>>> protected:
>>>int _M_gcount;
>>>virtual ~basic_istream()
>>>  { }
>>> };
>>>
>>> class istrstream : public basic_istream
>>> {
>>>virtual ~istrstream();
>>> };
>>>
>>> istrstream::~istrstream()
>>> {
>>> }
>>>
>>> -- CUT --
>>>
>>> With an arm-none-linux-gnueabi gcc configured as:
>>>
>>> ./gcc/configure --target=arm-none-linux-gnueabi
>>> --enable-gnu-indirect-function --enable-shared --with-arch=armv7-a
>>> --with-fpu=vfpv3-d16 --with-float=softfp --with-arch=armv7-a
>>> (irrelevant parts omitted)
>>>
>>> With the following command line options:
>>>
>>>   -fdata-sections-O2  -fPIC  -S ./test.cpp
>>>
>>> We'll see
>>>
>>> ./test.cpp:17:7: error: istrstream::_ZTV10istrstream.localalias.0
>>> causes a section type conflict with istrstream::_ZTV10istrstream
>>>   class istrstream : public basic_istream
>>> ^
>>> ./test.cpp:17:7: note: 'istrstream::_ZTV10istrstream' was declared here
>>
>>
>> This seems to be same cause as on AIX - we do section for decl rather than
>> original.  The following patch seems to fix it.  Does it allows bootstrap
>> for you? (it doesn't for AIX. but that seems bug in output machinery)
>>
>> Index: varasm.c
>> ===
>> --- varasm.c(revision 210914)
>> +++ varasm.c(working copy)
>> @@ -1083,6 +1083,9 @@
>>   {
>> addr_space_t as = ADDR_SPACE_GENERIC;
>> int reloc;
>> +  symtab_node *snode = symtab_get_node (decl);
>> +  if (snode)
>> +decl = symtab_alias_ultimate_target (snode)->decl;
>>
>> if (TREE_TYPE (decl) != error_mark_node)
>>   as = TYPE_ADDR_SPACE (TREE_TYPE (decl));
>>>
>>>
>>>
>>> Yufeng
>>
>>
>
>

Re: Require '%' to be at the beginning of a constraint string

[Jeff Law]

On 05/28/14 13:50, Richard Sandiford wrote:

Thanks for the review.

Jeff Law  writes:

On 05/26/14 13:21, Richard Sandiford wrote:

If we're going to change it, then clearly the docs need to change and
ideally we'd statically check the port's constraints during the build
process to ensure they meet the tighter definition.


OK, how does this look?  I built a cc1 for one target per config/
directory to (try to) check that there were no remaining cases.

This means that we will silently ignore '%'s that are embedded in the
middle of an asm constraint string, but in a way that's already true for
most places that check for commutativity.  An error seems a bit extreme
when '%' is only a hint.  If we want a warning, what should the option
be called?  And should it be under -Wall, -Wextra, or on by default?

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

OK.  My initial thought on adding a warning was to weed out bad
constraints.  You've already done that for the in-tree ports.  I'm a lot
less inclined to do much more here to help the out-of-tree ports, so
upon further review, let's not worry about the warning unless you've
already got it ready to go :-)


Well, the new genoutput.c error should catch problems in out-of-tree ports.

Right.


It's just asms where the non-initial '%'s would be silently accepted
and have no effect.
Right.  And I believe that it's conservatively correct -- so we're OK 
here as well.




David W suggested off-list that I add "Only input operands can use
@samp{%}." to the documention as well.  That seemed like it was
obviously an improvement so I applied the patch with that change (below).
Funny I was thinking about that when looking at the arc changes.  I saw 
the '%' on operand0 and was confused thinking it made no sense to have a 
'%' for an output operand.  Then I realized that 0/1 were inputs and 2 
was the output.


Thanks for pushing this through.

jeff

Re: [PATCH 1/4] Make coverage_compute_cfg_checksum callable with an argument

[Jeff Law]

On 05/30/14 00:47, Martin Liška wrote:

Hello,
   this is a small patchset that prepares API for new IPA Identical code
folding pass. The patch adds an argument for coverage_compute_cfg_checksum.

Bootstrapped and tested on x86_64-linux.
OK for trunk?

Thanks,
Martin

2014-05-29  Martin Liska  

 * coverage.h (coverage_compute_cfg_checksum): Argument added.
 * coverage.c (coverage_compute_cfg_checksum): Likewise.
 * profile.c (branch_prob): Likewise.
The block comment for coverage_compute_cfg_checksum needs to be updated. 
 We're no longer computing the checksum for the current function 
(cfun), but instead computing the checksum for the argument FN.



Otherwise OK for the trunk.

jeff

[RFC ARM] Error if overriding --with-tune by --with-cpu

[James Greenhalgh]

Hi,

We error in the case where both --with-tune and --with-cpu are specified at
configure time. In this case, we cannot distinguish this situation from the
situation where --with-tune was specified at configure time and -mcpu was
passed on the command line, so we give -mcpu precedence.

This might be surprising if you expect the precedence rules we give
to the command line options, but we can't change this precedence without
breaking our definition of -mcpu.

We also promote the warning which used to be thrown in the case of
--with-arch and --with-cpu to an error.

I've marked this is an RFC as it isn't clear that configure should be
catching something like this. Other blatant errors in configuration
options like passing "--with-languages=c,c++" pass without event.

Tested with a few combinations of configure options with no issues and the
expected behaviour.

Any opinions, and if not, OK for trunk?

Thanks,
James

---
gcc/

2014-05-30  James Greenhalgh  

* config.gcc (supported_defaults): Error when passing either
--with-tune or --with-arch in conjunction with --with-cpu for ARM.
diff --git a/gcc/config.gcc b/gcc/config.gcc
index c3f3ea6..7e82700 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -3560,7 +3560,13 @@ case "${target}" in
 		esac
 
 		if test "x$with_arch" != x && test "x$with_cpu" != x; then
-			echo "Warning: --with-arch overrides --with-cpu=$with_cpu" 1>&2
+			echo "Switch \"--with-arch\" may not be used with switch \"--with-cpu\""  1>&2
+			exit 1
+		fi
+
+		if test "x$with_cpu" != x && test "x$with_tune" != x; then
+			echo "Switch \"--with-tune\" may not be used with switch \"--with-cpu\""  1>&2
+			exit 1
 		fi
 
 		# Add extra multilibs

Re: [patch, avr] ata6289 device ISA is updated

[Denis Chertykov]

2014-05-29 22:27 GMT+04:00 S, Pitchumani :
> Hi,
>
> Device ATA6289 has MUL instruction and it belongs to avr4 ISA.
> Now it is incorrectly listed under avr25. Attached patch corrects it.
>
> Please commit if the patch is OK. I do not have commit access.
>
> Regards,
> Pitchumani
>
> 2014-05-29  Pitchumani Sivanupandi 
>
> * config/avr/avr-mcus.def: Change ATA6289 ISA to AVR4
> * config/avr/avr-tables.opt: Regenerate.
> * config/avr/t-multilib: Regenerate.
> * doc/avr-mmcu.texi: Regenerate.
>

Committed.

Denis.

Re: [PATCH 3/4] New attribute lookup function addition

[Jeff Law]

On 05/30/14 00:49, Martin Liška wrote:

Hi,
this patch introduces a new function lookup_attribute_starting that
can find all attributes starting with a specified string. Purpose of the
function is to be able to identify e.g. if a function has any 'omp'
attribute.

Bootstrapped and tested on x86_64-linux.
OK for trunk?

Thanks,
Martin

2014-05-29  Martin Liska  

 * tree.h (private_lookup_attribute_starting): New function.
 (lookup_attribute_starting): Likewise.
 * tree.c (private_lookup_attribute_starting): Likewise.

private_lookup_attribute_starting needs a block comment.



+tree
+private_lookup_attribute_starting (const char *attr_name, size_t
attr_len, tree list)
Long line needs to be wrapped?   Please review the patch for lines that 
need wrapping at 80 columns.


So it's really a lookup by prefix, so I'd probably use a name like
lookup_attribute_by_prefix.  Why "private_" in the function name?


It appears it just returns the first attribute from LIST with the given 
prefix.  Presumably you use it iteratively.



+/* Given an attribute name ATTR_NAME and a list of attributes LIST,
+   return a pointer to the attribute's list element if the attribute
+   starts with ATTR_NAME. ATTR_NAME must be in the form 'text' (not
+   '__text__').  */
+
+static inline tree
+lookup_attribute_starting (const char *attr_name, tree list)
+{
+  gcc_checking_assert (attr_name[0] != '_');
+  /* In most cases, list is NULL_TREE.  */
+  if (list == NULL_TREE)
+return NULL_TREE;
+  else
+return private_lookup_attribute_starting (attr_name, strlen
(attr_name), list);
+}
So again, I prefer "prefix" rather than "starting".  Similarly this is 
meant to be called iteratively since you only get the first attribute 
with the given prefix, right?


OK with the nit fixes mentioned above.


Jeff

Re: [PATCH 4/4] New callgraph wrapper function creation added

[Jeff Law]

On 05/30/14 00:49, Martin Liška wrote:

Hello,
cgraph_make_wrapper is a new function that creates a simple wrapper
of a function. The function will be used further in identical code
folding if a pass proves that two functions are semantically equivalent.

Bootstrapped and tested on x86_64-linux.
OK for trunk?

Thanks,
Martin

2014-05-29  Martin Liska  

 * cgraph.h (cgraph_make_wrapper): New function introduced.
 * cgraphunit.c (cgraph_make_wrapper): The function implementation.
 * ipa-inline.h (inline_analyze_function): The function is global.
 * ipa-inline-analysis.c (inline_analyze_function): Likewise.

OK for the trunk.

jeff

Re: [PATCH 2/4] Enhancement of call graph API

[Jeff Law]

On 05/30/14 00:47, Martin Liška wrote:

Hello,
this patch enhances callgraph API to enable more precise control of
expand_thunk; another function becomes global.

Bootstrapped and tested on x86_64-linux.
OK for trunk?

Thanks,
Martin

2014-05-29  Martin Liska  

 * cgraph.h (expand_thunk): New argument added.
 (address_taken_from_non_vtable_p): New global function.
 * ipa-visibility.c (address_taken_from_non_vtable_p): Likewise.
 * cgraphclones.c (duplicate_thunk_for_node): Argument added to call.
 * cgraphunit.c (analyze_function): Likewise.
 (assemble_thunks_and_aliases): Argument added to call.
 (expand_thunk): New argument forces to produce GIMPLE thunk.
Only concern here is the location of the prototype for 
address_taken_from_non_vtable_p.  Though I guess other things form 
ipa-visibility.c are prototyped in cgraph.h.


Can you put the prototype here in cgraph.h:


/* In ipa-visibility.c */
bool cgraph_local_node_p (struct cgraph_node *);

Otherwise OK.

Real curious to see the meat of the optimization now :-)

jeff

Re: [PATCH, i386, Pointer Bounds Checker 11/x] Keep bounds initial values

[Jeff Law]

On 05/29/14 04:53, Ilya Enkovich wrote:

Hi,

This patch tries to keep bounds initial values when it may be needed.  Even if 
initial value is not fully known (e.g. we know only low bound) it still may 
help to remove some redundant checks.

Bootstrapped and tested on linux-x86_64.

Thanks,
Ilya
--
gcc/

2013-05-29  Ilya Enkovich  

* ipa.c (symtab_remove_unreachable_nodes): Kepp initial values for
pointer bounds to be used for checks eliminations.
* lto-cgraph.c (compute_ltrans_boundary): Likewise.
* add_references_to_partition (add_references_to_partition): Add
references to pointer bounds vars.

Typo in the ChangeLog "kepp" -> "keep".

OK for the trunk when the rest of the stuff is approved, though I'm 
curious how, for example, keeping the initial value for an unreachable 
node in symtab_remove_unreachable_nodes helps eliminate redundant checks.


Jeff

Re: [PATCH, i386, Pointer Bounds Checker 12/x] Recognize instrumented special functions

[Jeff Law]

On 05/29/14 05:00, Ilya Enkovich wrote:

Hi,

This patch allows to recognize instrumented call to special function by using 
the original function name for recognition.

Bootstrapped and tested on linux-x86_64.

Thanks,
Ilya
--
gcc/

2014-05-29  Ilya Enkovich  

* calls.c (special_function_p): Use original decl name
when analyzing instrumentation clone.

OK for the trunk when the rest of the patches are approved.

Presumably we have to use the original decl because we twiddle the name 
in the clones, right?  Just want to make sure I understand why we're 
dong this :-)



jeff

Re: libsanitizer merge from upstream r208536

[Dodji Seketeli]

Jakub Jelinek  writes:

[...]

> Ok, tried to merge also g++.dg/asan from the same revision as you've merged
> libsanitizer.

[...]

>
> 2014-05-22  Jakub Jelinek  
>
>   * g++.dg/asan/asan_test.C: Add -std=c++11 and
>   -DSANITIZER_USE_DEJAGNU_GTEST=1 to dg-options, remove
>   -DASAN_USE_DEJAGNU_GTEST=1.
>   * g++.dg/asan/asan_mem_test.cc: Updated from upstream
>   r209283.
>   * g++.dg/asan/asan_oob_test.cc: Likewise.
>   * g++.dg/asan/sanitizer_test_utils.h: Likewise.
>   * g++.dg/asan/asan_str_test.cc: Likewise.
>   * g++.dg/asan/asan_test_utils.h: Likewise.
>   * g++.dg/asan/sanitizer_test_config.h: Likewise.
>   * g++.dg/asan/asan_test.cc: Likewise.
>   * g++.dg/asan/sanitizer_pthread_wrappers.h: New file.
>   Imported from upstream r209283.
>   * g++.dg/asan/asan_test_config.h: Likewise.

This is OK.

Thanks.

-- 
Dodji

Re: [patch i386]: Expand sibling-tail-calls via accumulator register

[Kai Tietz]

- Original Message -
> On 05/30/2014 01:08 AM, Kai Tietz wrote:
> > (define_predicate "sibcall_memory_operand"
> >   (match_operand 0 "memory_operand")
> > {
> >   return CONSTANT_P (op);
> > })
> 
> Surely that always returns false?  Surely XEXP (op, 0) so that you look at
> the
> address, not the memory.
> 
> 
> r~
> 

Doh ... of course


(define_predicate "sibcall_memory_operand"
  (match_operand 0 "memory_operand")
{
  return CONSTANT_P (XEXP (op, 0));
})


Actually I tested the proper version :}

Kai

Re: libsanitizer merge from upstream r208536

[Dodji Seketeli]

Jakub Jelinek  writes:

> On Thu, May 22, 2014 at 04:07:38PM +0200, Jakub Jelinek wrote:
>> 2014-05-22  Jakub Jelinek  
>> 
>>  * sanitizer.def (BUILT_IN_ASAN_REPORT_LOAD_N,
>>  BUILT_IN_ASAN_REPORT_STORE_N): New.
>>  * asan.c (struct asan_mem_ref): Change access_size type to
>>  HOST_WIDE_INT.
>>  (asan_mem_ref_init, asan_mem_ref_new, get_mem_refs_of_builtin_call,
>>  update_mem_ref_hash_table): Likewise.
>>  (asan_mem_ref_hasher::hash): Hash in a HWI.
>>  (report_error_func): Change size_in_bytes argument to HWI.
>>  Use *_N builtins if size_in_bytes is larger than 16 or not power of
>>  two.
>>  (build_shadow_mem_access): New function.
>>  (build_check_stmt): Use it.  Change size_in_bytes argument to HWI.
>>  Handle size_in_bytes not power of two or larger than 16.
>>  (instrument_derefs): Don't give up if size_in_bytes is not
>>  power of two or is larger than 16.
>
> Both patches bootstrapped/regtested on x86_64-linux and i686-linux
> successfully, ok for trunk for both?

Yes, this is OK.  Thanks.

-- 
Dodji

Re: [PATCH, Pointer Bounds Checker 13/x] Early versioning

[Jeff Law]

On 05/29/14 05:05, Ilya Enkovich wrote:

Hi,

This patch allows to perform function versioning when some structures are not 
available yet.  It is required to make clones for Pointer Bounds Checker right 
after SSA build.

Bootstrapped and tested on linux-x86_64.

Thanks,
Ilya
--
gcc/

2014-05-29  Ilya Enkovich  

* tree-inline.c (copy_cfg_body): Check loop tree
existence before accessing it.
(tree_function_versioning): Check DF info existence
before accessing it.

diff --git a/gcc/tree-inline.c b/gcc/tree-inline.c
index 4293241..23fef90 100644
--- a/gcc/tree-inline.c
+++ b/gcc/tree-inline.c
@@ -2544,7 +2544,8 @@ copy_cfg_body (copy_body_data * id, gcov_type count, int 
frequency_scale,

/* If the loop tree in the source function needed fixup, mark the
   destination loop tree for fixup, too.  */
-  if (loops_for_fn (src_cfun)->state & LOOPS_NEED_FIXUP)
+  if (loops_for_fn (src_cfun)
+  && loops_for_fn (src_cfun)->state & LOOPS_NEED_FIXUP)
  loops_state_set (LOOPS_NEED_FIXUP);
Hmm, so if I understand things correctly, src_fun has no loop structures 
attached, thus there's nothing to copy.  Presumably at some later point 
we build loop structures for the copy from scratch?


Similarly for the PTA info, we just build it from scratch in the copy at 
some point?


Assuming the answers to both are yes, then this patch is OK for the 
trunk when the rest of the patches are approved.  It's not great, bit 
it's OK.


jeff

Re: libsanitizer merge from upstream r208536

[Dodji Seketeli]

Jakub Jelinek  writes:


[...]

> Here is the GCC side of the thing, 

[...]

> 2014-05-23  Jakub Jelinek  
>
>   * asan.c (report_error_func): Add SLOW_P argument, use
>   BUILT_IN_ASAN_*_N if set.
>   (build_check_stmt): Likewise.
>   (instrument_derefs): If T has insufficient alignment,
>   force same handling as for odd sizes.
>
>   * c-c++-common/asan/misalign-1.c: New test.
>   * c-c++-common/asan/misalign-2.c: New test.
>

> ok for trunk if it bootstraps/regtests?

Yes, this is OK for me.

Thanks.

-- 
Dodji

[patch] Update email address in docs

[Jonathan Wakely]

The docs still give Benjamin's old address for copyright assignment
questions. Changed to my address, although I considered "volunteering"
Paolo to get the mails ;-)

Committed to trunk.
commit 297bdcf296627c890b00db21a0333a7d0bb0a899
Author: Jonathan Wakely 
Date:   Fri May 30 17:57:32 2014 +0100

	* doc/xml/manual/appendix_contributing.xml (list.copyright): Replace
	Benjamin's old email address.

diff --git a/libstdc++-v3/doc/xml/manual/appendix_contributing.xml b/libstdc++-v3/doc/xml/manual/appendix_contributing.xml
index bd7dfc7..e59e2f7 100644
--- a/libstdc++-v3/doc/xml/manual/appendix_contributing.xml
+++ b/libstdc++-v3/doc/xml/manual/appendix_contributing.xml
@@ -110,11 +110,11 @@
 
 
 
-  Please contact Benjamin Kosnik at
-  bkoz+ass...@redhat.com if you are confused
+  Please contact Jonathan Wakely at
+  jwakely+ass...@redhat.com if you are confused
   about the assignment or have general licensing questions. When
   requesting an assignment form from
-  mailto:ass...@gnu.org, please cc the libstdc++
+  ass...@gnu.org, please CC the libstdc++
   maintainer above so that progress can be monitored.
 
   

Re: [PATCH, i386, Pointer Bounds Checker 10/x] Partitions

[Jeff Law]

On 05/28/14 10:06, Ilya Enkovich wrote:

Hi,

This patch keeps instrumented and original versions together and preserve 
tranparent alias chain during symbol name privatization.

Bootstrapped and tested on linux-x86_64.

Thanks,
Ilya
--
gcc/

2013-05-28  Ilya Enkovich  

* lto/lto-partition.c (add_symbol_to_partition_1): Keep original
and instrumented versions together.
This part is OK.  Note lto/ has its own ChangeLog, so put the ChangeLog 
entry there and don't use the "lto/" prefix in the ChangeLog entry.



(privatize_symbol_name): Restore transparent alias chain if required.
What exactly are you doing here?  The comment in the code doesn't really 
make it clear what you are doing or why.



+  /* We could change name which is a target of transparent alias
+ chain of instrumented function name.  Fix alias chain if so  .*/
So are you saying that we want to change the name?  Or that it could 
have been changed and we have to adjust something because it was changed?


I'm certainly not as familiar with the LTO stuff as I should be -- what 
is the purpose behing chaining the DECL_ASSEMBLER_NAME nodes?


jeff

Re: [patch] libstdc++/61011 fix --disable-libstdcxx in top-level configure

[Jonathan Wakely]

PING

This is a change to top-level configure, not libstdc++ itself, so I
need approval.


On 20/05/14 15:59 +0100, Jonathan Wakely wrote:

On 20/05/14 15:53 +0100, Jonathan Wakely wrote:

The first part of this patch fixes the PR, we should be adding
target-libstdc++-v3 to noconfigdirs, not libstdc++-v3.

The second part disables the target libs that can't be bootstrapped
without libstdc++.

libcilkrts and libsanitizer use lots of std:: stuff.
libitm only uses std::atomic, but in any case fails to build when
--disable-libstdcxx is used, with this error:

xg++: error: unrecognized command line option ‘-funconfigured-libstdc++-v3’

Bootstrapped with and without --disable-libstdcxx and tested on
x86_64-linux.

PR libstdc++/61011
* configure.ac (--disable-libstdcxx): Set noconfigdirs correctly.
Disable libcilkrts, libitm, libsanitizer when not building libstdc++.
* configure: Regenerate.

OK for trunk?


With the patch this time ...


commit c384fef85bca43046b65eb02267169a5613af2b8
Author: Jonathan Wakely 
Date:   Tue May 20 12:13:43 2014 +0100

PR libstdc++/61011
* configure.ac (--disable-libstdcxx): Set noconfigdirs correctly.
Disable libcilkrts, libitm, libsanitizer when not building libstdc++.
* configure: Regenerate.

diff --git a/configure.ac b/configure.ac
index 07c3a66..548525b 100644
--- a/configure.ac
+++ b/configure.ac
@@ -435,7 +435,7 @@ AS_HELP_STRING([--disable-libstdcxx],
ENABLE_LIBSTDCXX=$enableval,
ENABLE_LIBSTDCXX=default)
[if test "${ENABLE_LIBSTDCXX}" = "no" ; then
-  noconfigdirs="$noconfigdirs libstdc++-v3"
+  noconfigdirs="$noconfigdirs target-libstdc++-v3"
fi]

# Save it here so that, even in case of --enable-libgcj, if the Java
@@ -2057,9 +2057,17 @@ case ,${enable_languages},:${enable_objc_gc} in
;;
esac

-# Disable libitm, libsanitizer, libvtv if we're not building C++
+# Disable libcilkrts, libitm, libsanitizer, libvtv if we're not building C++
case ,${enable_languages}, in
-  *,c++,*) ;;
+  *,c++,*)
+# Disable libcilkrts, libitm, libsanitizer if we're not building libstdc++
+case "${noconfigdirs}" in
+  *target-libstdc++-v3*)
+noconfigdirs="$noconfigdirs target-libcilkrts target-libitm 
target-libsanitizer"
+;;
+  *) ;;
+esac
+;;
  *)
noconfigdirs="$noconfigdirs target-libcilkrts target-libitm target-libsanitizer 
target-libvtv"
;;

Re: [patch] libstdc++/61011 fix --disable-libstdcxx in top-level configure

[Jeff Law]

On 05/30/14 11:09, Jonathan Wakely wrote:

PING

This is a change to top-level configure, not libstdc++ itself, so I
need approval.


On 20/05/14 15:59 +0100, Jonathan Wakely wrote:

On 20/05/14 15:53 +0100, Jonathan Wakely wrote:

The first part of this patch fixes the PR, we should be adding
target-libstdc++-v3 to noconfigdirs, not libstdc++-v3.

The second part disables the target libs that can't be bootstrapped
without libstdc++.

libcilkrts and libsanitizer use lots of std:: stuff.
libitm only uses std::atomic, but in any case fails to build when
--disable-libstdcxx is used, with this error:

xg++: error: unrecognized command line option
‘-funconfigured-libstdc++-v3’

Bootstrapped with and without --disable-libstdcxx and tested on
x86_64-linux.

 PR libstdc++/61011
 * configure.ac (--disable-libstdcxx): Set noconfigdirs correctly.
 Disable libcilkrts, libitm, libsanitizer when not building
libstdc++.
 * configure: Regenerate.

OK for trunk?


With the patch this time ...


commit c384fef85bca43046b65eb02267169a5613af2b8
Author: Jonathan Wakely 
Date:   Tue May 20 12:13:43 2014 +0100

PR libstdc++/61011
* configure.ac (--disable-libstdcxx): Set noconfigdirs correctly.
Disable libcilkrts, libitm, libsanitizer when not building
libstdc++.
* configure: Regenerate.
While it may be a top-level configure change, I'd consider it part of 
the libstdc++ world by extension.  Approved.


Jeff

Re: [patch i386]: Expand sibling-tail-calls via accumulator register

[Jeff Law]

On 05/30/14 10:51, Kai Tietz wrote:

- Original Message -

On 05/30/2014 01:08 AM, Kai Tietz wrote:

(define_predicate "sibcall_memory_operand"
   (match_operand 0 "memory_operand")
{
   return CONSTANT_P (op);
})


Surely that always returns false?  Surely XEXP (op, 0) so that you look at
the
address, not the memory.


r~



Doh ... of course


(define_predicate "sibcall_memory_operand"
   (match_operand 0 "memory_operand")
{
   return CONSTANT_P (XEXP (op, 0));
})


Actually I tested the proper version :}

In that case, it's good to go.  OK for the trunk.

jeff

Re: [PATCH i386 5/8] [AVX-512] Extend vectorizer hooks.

[H.J. Lu]

On Thu, May 22, 2014 at 10:38 AM, H.J. Lu  wrote:
> On Thu, May 22, 2014 at 2:01 AM, Kirill Yukhin  
> wrote:
>> Hello,
>> On 20 May 08:24, H.J. Lu wrote:
>>> ABI alignment should be sufficient for correctness. Bigger alignments
>>> are supposed to give better performance.  Can you try this patch on
>>> HSW and SLM to see if it has any impact on performance?
>>
>> Here is perf. data of your patch.
>>
>> Only HSW so far
>>
>> HSW, 64 bits, base
>>
>> Test Previous Current Ratio(%)
>> 400.perlbench 37.700037.7000 +0%
>> 401.bzip2 24.800024.7000 -0.40%
>> 403.gcc   35.100035.2000 +0.28%
>> 429.mcf   41.700042. +0.71%
>> 445.gobmk 26.900027. +0.37%
>> 456.hmmer 27.200027.2000 +0%
>> 458.sjeng 30.200030.1000 -0.33%
>> 462.libquantum77.400076.7000 -0.90%
>> 464.h264ref   52.500052.8000 +0.57%
>> 471.omnetpp   23.800023.7000 -0.42%
>> 473.astar 23.200023.1000 -0.43%
>> 483.xalancbmk 39.800040.1000 +0.75%
>> 410.bwaves78.400078.5000 +0.12%
>> 416.gamess33.900033.9000 +0%
>> 433.milc  34.700034.8000 +0.28%
>> 434.zeusmp38.600038.4000 -0.51%
>> 435.gromacs   26.900027. +0.37%
>> 436.cactusADM 54.700062. +13.34%
>> 437.leslie3d  45.300045.3000 +0%
>> 444.namd  27.200027.1000 -0.36%
>> 447.dealII56.700056.7000 +0%
>> 450.soplex39.300039.3000 +0%
>> 453.povray49.49.1000 +0.20%
>> 454.calculix  28.800029.3000 +1.73%
>> 459.GemsFDTD  38.900039. +0.25%
>> 465.tonto 23.100023.3000 +0.86%
>> 470.lbm   55.300055.6000 +0.54%
>> 481.wrf   40.800040.8000 +0%
>> 482.sphinx3   47.800047.9000 +0.20%
>>
>> HSW, 64 bits, o2
>>
>> Test Previous Current Ratio(%)
>> 400.perlbench 39.700039.7000 +0%
>> 401.bzip2 25.100025.1000 +0%
>> 403.gcc   33.700033.7000 +0%
>> 429.mcf   40.100039.9000 -0.49%
>> 445.gobmk 26.500026.4000 -0.37%
>> 456.hmmer 24.800024.8000 +0%
>> 458.sjeng 28.400028.5000 +0.35%
>> 462.libquantum74.400074.4000 +0%
>> 464.h264ref   50.100050.3000 +0.39%
>> 471.omnetpp   22.600022.5000 -0.44%
>> 473.astar 20.700021. +1.44%
>> 483.xalancbmk 37.37.4000 +1.08%
>> 410.bwaves60.100060.1000 +0%
>> 416.gamess35.500035.4000 -0.28%
>> 433.milc  29.900029.8000 -0.33%
>> 434.zeusmp34.800034.6000 -0.57%
>> 435.gromacs   27.400027.5000 +0.36%
>> 436.cactusADM 32.300033.8000 +4.64%
>> 437.leslie3d  32.600032.6000 +0%
>> 444.namd  26.900026.9000 +0%
>> 447.dealII45.200045.1000 -0.22%
>> 450.soplex42.500042.6000 +0.23%
>> 453.povray45.900046.1000 +0.43%
>> 454.calculix  12.900012.9000 +0%
>> 459.GemsFDTD  38.600038.7000 +0.25%
>> 465.tonto 23.700023.8000 +0.42%
>> 470.lbm   56.700056.7000 +0%
>> 481.wrf   28.900028.9000 +0%
>> 482.sphinx3   43.900043.8000 -0.22%
>>
>
> So extra alignment doesn't have any performance impact
> on HSW with SPEC CPU 2006.  So the question is if using
> alignment specified by ABI will cause any correctness issue.
> I am concerned about the comment:
>
>   /* GCC 4.8 and earlier used to incorrectly assume this alignment even
>  for symbols from other compilation units or symbols that don't need
>  to bind locally.  In order to preserve some ABI compatibility with
>  those compilers, ensure we don't decrease alignment from what we
>  used to assume.  */
>
> Jakub,  will we into any correctness issue if ix86_data_alignment
> always returns ABI alignment?
>

The ABI issue is

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56564

That is we shouldn't use alignment beyond ABI if the definition
may come from a different compilation unit.   But DATA_ALIGNMENT
is only for optimization purpose.  I opened:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61296

for excessive x86 data alignment.  It looks like that started as
an accident from:

https://gcc.gnu.org/ml/gcc-patches/2000-06/msg00871.html

which aligned struct >= 32 bytes to 32 bytes.  But alignment beyond
natural alignment doesn't provide performance benefit.  Should
we limit DATA_ALIGNMENT to MAX (ABI alignment, natural alignment)?


-- 
H.J.

Re: ipa-visibility TLC 2/n

[David Edelsohn]

Honza,

For example g++.dg/abi/vcall1.C fails at a call in a "localalias"
function, which jumps to a bad location:


(gdb) up
#1  0x14c0 in B::B() [clone .localalias.2] ()
(gdb) x/16i $pc-32
   0x14a0 <_ZN1BC2Ev+156>:  add r10,r10,r8
   0x14a4 <_ZN1BC2Ev+160>:  mr  r3,r10
   0x14a8 <_ZN1BC2Ev+164>:  stw r2,20(r1)
   0x14ac <_ZN1BC2Ev+168>:  lwz r10,0(r9)
   0x14b0 <_ZN1BC2Ev+172>:  lwz r11,8(r9)
   0x14b4 <_ZN1BC2Ev+176>:  mtctr   r10
   0x14b8 <_ZN1BC2Ev.localalias.2+180>: lwz r2,4(r9)
   0x14bc <_ZN1BC2Ev.localalias.2+184>: bctrl
=> 0x14c0 <_ZN1BC2Ev.localalias.2+188>: lwz r2,20(r1)
   0x14c4 <_ZN1BC2Ev.localalias.2+192>: addir1,r31,64
   0x14c8 <_ZN1BC2Ev.localalias.2+196>: lwz r0,8(r1)
   0x14cc <_ZN1BC2Ev.localalias.2+200>: mtlrr0
   0x14d0 <_ZN1BC2Ev.localalias.2+204>: lwz r31,-4(r1)
   0x14d4 <_ZN1BC2Ev.localalias.2+208>: blr



On Fri, May 30, 2014 at 3:20 AM, Richard Sandiford
 wrote:
> Jan Hubicka  writes:
>>> Jan Hubicka  writes:
>>> >> Richard Sandiford wrote the original section anchors implementation,
>>> >> so he would be a good person to comment about the interaction between
>>> >> aliases and section anchors.
>>> >
>>> > Thanks! Richard, does this patch seem sane?
>>>
>>> Looks good to me in principle, but with:
>>>
>>> > +  struct symtab_node *snode;
>>> >decl = SYMBOL_REF_DECL (symbol);
>>> > +
>>> > +  snode = symtab_node (decl);
>>> > +  if (snode->alias)
>>> > +   {
>>> > + rtx target = DECL_RTL (symtab_alias_ultimate_target
>>> > (snode)->decl);
>>> > + SYMBOL_REF_BLOCK_OFFSET (symbol) = SYMBOL_REF_BLOCK_OFFSET
>>> > (target);
>>> > + return;
>>> > +   }
>>>
>>> is SYMBOL_REF_BLOCK_OFFSET (target) guaranteed to be valid at this point?
>>> It looked at face value like you'd need a recursive call to 
>>> place_block_symbol
>>> on the target before the copy.
>>
>> My reading was that SYMBOL_REF_BLOCK_OFFSET is computed at DECL_RTL
>> calculation time. But you are right - it is done by validize_mem that
>> is not done by DECL_RTL.  Shall I just call it on target first?
>
> Yeah, sounds like calling place_block_symbol would be safer.
>
> IIRC, the reason I didn't do it at SET_DECL_RTL time is that some frontends
> tended to create placeholder decls that for whatever reason ended up with
> an initial DECL_RTL, then changed the properties of the decl later once
> more information was known.  (This was all many years ago.)
>
> Thanks,
> Richard

Re: [PATCH 2/3] PR other/61321 - demangler crash on casts in template parameters

[Cary Coutant]

> Fix this by adding a new DEMANGLE_COMPONENT_CONVERSION component type,
> which does what DEMANGLE_COMPONENT_CAST does today, and making
> DEMANGLE_COMPONENT_CAST just simply print its component subtree.
>
> I think we could instead reuse DEMANGLE_COMPONENT_CAST and in
> d_print_comp_inner still do:
>
>  @@ -5001,9 +5013,9 @@ d_print_comp_inner (struct d_print_info *dpi, int 
> options,
> d_print_comp (dpi, options, dc->u.s_extended_operator.name);
> return;
>
>  case DEMANGLE_COMPONENT_CAST:
>d_append_string (dpi, "operator ");
>  - d_print_cast (dpi, options, dc);
>  + d_print_conversion (dpi, options, dc);
>return;
>
> leaving the unary cast case below calling d_print_cast, but seems to
> me that spliting the component types makes it easier to reason about
> the code.

I agree.

> libiberty/
> 2014-05-27  Pedro Alves 
>
> PR other/61321
> PR other/61233
> * demangle.h (enum demangle_component_type)
> : New value.
> * cp-demangle.c (d_demangle_callback, d_make_comp): Handle
> DEMANGLE_COMPONENT_CONVERSION.
> (is_ctor_dtor_or_conversion): Handle DEMANGLE_COMPONENT_CONVERSION
> instead of DEMANGLE_COMPONENT_CAST.
> (d_operator_name): Return a DEMANGLE_COMPONENT_CONVERSION
> component if handling a conversion.
> (d_count_templates_scopes, d_print_comp_inner): Handle
> DEMANGLE_COMPONENT_CONVERSION.
> (d_print_comp_inner): Handle DEMANGLE_COMPONENT_CONVERSION instead
> of DEMANGLE_COMPONENT_CAST.
> (d_print_cast): Rename as ...
> (d_print_conversion): ... this.  Adjust comments.
> (d_print_cast): Rewrite - simply print the left subcomponent.
> * cp-demint.c (cplus_demangle_fill_component): Handle
> DEMANGLE_COMPONENT_CONVERSION.
>
> * testsuite/demangle-expected: Add tests.

Looks good to me. Thanks!

Ian, does this look good to you?

-cary

Re: [C++ Patch] PR 57543

[Paolo Carlini]

Hi,

On 05/30/2014 04:41 PM, Jason Merrill wrote:

On 05/30/2014 10:21 AM, Paolo Carlini wrote:

You also need to propagate the flag in a bunch of other places:
everywhere we call build_method_type_directly ought to cover it.

Agreed, I spotted a few places. What about build_function_type? I think
it's the same issue, right?


Right, I was just thinking that the relevant uses of 
build_function_type will be near calls to build_method_type_directly.  :)
Indeed. Thus I have the below, which passes testing. Most of the changes 
are quite obvious, some maybe redundant but safe, I think. Exceptions:
1- I'm not sure cp_reconstruct_complex_type needs the changes, but 
probably cannot hurt.

2- Likewise change_return_type, for different reasons.
3- I understand Core/1227 as including the case of the late return type 
vs the parameters of generic lambdas, thus the rather heavy handed tweak 
to cp_parser_lambda_declarator_opt, which appears to work under the 
debugger (in the sense that for testcases like 
cpp1y/lambda-generic-cfun.C I checked that the on flag is still there in 
the eventual tsubst_function_type), but I need help about the conversion 
operator: should I do something in maybe_add_lambda_conv_op, thus 
propagate somehow from TREE_TYPE (callop)?!? In case, it would be easy, 
but I need help about the actual semantics we want (this isn't really 
about our impl, more about the specs of generic lambdas, sorry).


Finally, about !dependent_scope_p vs CLASS_TYPE_P, just wanted to 
mention, in case isn't obvious already, that build_this_parm has 
CLASS_TYPE_P which we badly want to be true if we want to avoid 
immediate ICEs in type_of_this_parm. Thus, it seems in fact the minimal 
check to use in tsusbt_function_type.


Thanks!
Paolo.


Index: cp/cp-tree.h
===
--- cp/cp-tree.h(revision 211072)
+++ cp/cp-tree.h(working copy)
@@ -125,7 +125,7 @@ c-common.h, not after.
Usage of TYPE_LANG_FLAG_?:
0: TYPE_DEPENDENT_P
1: TYPE_HAS_USER_CONSTRUCTOR.
-   2: unused
+   2: TYPE_HAS_LATE_RETURN_TYPE (in FUNCTION_TYPE, METHOD_TYPE)
3: TYPE_FOR_JAVA.
4: TYPE_HAS_NONTRIVIAL_DESTRUCTOR
5: CLASS_TYPE_P (in RECORD_TYPE and UNION_TYPE)
@@ -3404,6 +3404,11 @@ more_aggr_init_expr_args_p (const aggr_init_expr_a
user-declared constructor.  */
 #define TYPE_HAS_USER_CONSTRUCTOR(NODE) (TYPE_LANG_FLAG_1 (NODE))
 
+/* Nonzero means that the FUNCTION_TYPE or METHOD_TYPE has a
+   late-specified return type.  */
+#define TYPE_HAS_LATE_RETURN_TYPE(NODE) \
+  (TYPE_LANG_FLAG_2 (FUNC_OR_METHOD_CHECK (NODE)))
+
 /* When appearing in an INDIRECT_REF, it means that the tree structure
underneath is actually a call to a constructor.  This is needed
when the constructor must initialize local storage (which can
Index: cp/decl.c
===
--- cp/decl.c   (revision 211072)
+++ cp/decl.c   (working copy)
@@ -8817,6 +8817,7 @@ grokdeclarator (const cp_declarator *declarator,
   bool template_parm_flag = false;
   bool typedef_p = decl_spec_seq_has_spec_p (declspecs, ds_typedef);
   bool constexpr_p = decl_spec_seq_has_spec_p (declspecs, ds_constexpr);
+  bool late_return_type_p = false;
   source_location saved_loc = input_location;
   const char *errmsg;
 
@@ -9660,6 +9661,9 @@ grokdeclarator (const cp_declarator *declarator,
if (type == error_mark_node)
  return error_mark_node;
 
+   if (declarator->u.function.late_return_type)
+ late_return_type_p = true;
+
if (ctype == NULL_TREE
&& decl_context == FIELD
&& funcdecl_p
@@ -10590,6 +10594,10 @@ grokdeclarator (const cp_declarator *declarator,
  decl_function_context (TYPE_MAIN_DECL (ctype)) : NULL_TREE;
publicp = (! friendp || ! staticp)
  && function_context == NULL_TREE;
+
+   if (late_return_type_p)
+ TYPE_HAS_LATE_RETURN_TYPE (type) = 1;
+
decl = grokfndecl (ctype, type,
   TREE_CODE (unqualified_id) != TEMPLATE_ID_EXPR
   ? unqualified_id : dname,
@@ -10814,6 +10822,9 @@ grokdeclarator (const cp_declarator *declarator,
publicp = (ctype != NULL_TREE
   || storage_class != sc_static);
 
+   if (late_return_type_p)
+ TYPE_HAS_LATE_RETURN_TYPE (type) = 1;
+
decl = grokfndecl (ctype, type, original_name, parms, unqualified_id,
   virtualp, flags, memfn_quals, rqual, raises,
   1, friendp,
@@ -14421,6 +14432,8 @@ static_fn_type (tree memfntype)
(fntype, TYPE_ATTRIBUTES (memfntype)));
   fntype = (build_exception_variant
(fntype, TYPE_RAISES_EXCEPTIONS (memfntype)));
+  if (TYPE_HAS_LATE_RETURN_TYPE (memfntype))
+TYPE_HAS_LATE_RETURN_TYPE (fntype) = 1;
   return fntype;
 }
 
Ind

Re: [patch] Update email address in docs

[Paolo Carlini]

Hi,

On 05/30/2014 07:04 PM, Jonathan Wakely wrote:

The docs still give Benjamin's old address for copyright assignment
questions. Changed to my address, although I considered "volunteering"
Paolo to get the mails ;-)
We may considering adding my email too, in the past I did that a lot 
anyway, behind the scenes ;)


Paolo.

Re: [PATCH, PR58942, Cilk+] Fix ICE when pointer is used in array notation

[Jeff Law]

On 05/25/14 03:31, Zamyatin, Igor wrote:

Hi!

Following patch handles the case of pointers in Cilk+ builtins.

Regtested in x86_64.
Ok for trunk and 4.9?

Thanks,
Igor

gcc/c/ChangeLog:

2014-05-23  Igor Zamyatin  

PR c/58942
* c-array-notation.c (fix_builtin_array_notation_fn): Handle the case
with a pointer.

gcc/cp/ChangeLog:

2014-05-23  Igor Zamyatin  

PR c/58942
* cp-array-notation.c (expand_sec_reduce_builtin): Handle the case
with a pointer.

gcc/testsuite/ChangeLog

2014-05-23  Igor Zamyatin  

PR c/58942
* c-c++-common/cilk-plus/AN/pr58942.c: Check for correct handling
of the case with a pointer.

OK for the trunk and 4.9.

Thanks,
jeff

Re: [PATCH] Fix up GCC_EXEC_PREFIX handling with ALT_*_UNDER_TEST

[Mike Stump]

On May 30, 2014, at 12:39 AM, Jakub Jelinek  wrote:
> Tested on x86_64-linux and i686-linux, ok for trunk/4.9?

Ok.

Re: [PATCH] Do not build libsanitizer also for powerpc*-*-linux*

[Konstantin Serebryany]

Thanks Jakub!
Looks like there is not rush with another merge now.

--kcc

On Fri, May 30, 2014 at 5:49 PM, Jakub Jelinek  wrote:
> On Fri, May 30, 2014 at 08:09:22AM -0500, Peter Bergner wrote:
>> On Thu, 2014-05-29 at 14:07 -0500, Peter Bergner wrote:
>> > On Wed, 2014-05-28 at 09:36 +0200, Thomas Schwinge wrote:
>> > > This is being discussed in the thread at
>> > > .  Until that
>> > > has been resolved, I do agree to check in the following patch (and have
>> > > successfully tested it, but cannot formally approve it for commit; thus
>> > > copying the libsanitizer maintainers):
>> >
>> > The re-enablement patch was submitted to the llvm mailing list here:
>> >
>> >   
>> > http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20140526/219249.html
>> >
>> > Once that is committed and merged into gcc, we can re-enable building
>> > libsanitizer for powerpc*-linux.
>>
>> Ok, it was committed upstream as revision 209879.  Kostya, can we get
>> this merged into gcc trunk and powerpc*-linux re-enabled again?  Thanks.
>
> I've cherry-picked the two upstream commits and after testing on
> x86_64-linux/i686-linux committed to trunk.
>
> 2014-05-30  Jakub Jelinek  
>
> * sanitizer_common/sanitizer_stacktrace.cc: Cherry pick upstream
> r209879.
> * sanitizer_common/sanitizer_common.h: Likewise.
> * asan/asan_mapping.h: Likewise.
> * asan/asan_linux.cc: Likewise.
> * tsan/tsan_mman.cc: Cherry pick upstream r209744.
> * sanitizer_common/sanitizer_allocator.h: Likewise.
>
> --- libsanitizer/sanitizer_common/sanitizer_stacktrace.cc   (revision 
> 209878)
> +++ libsanitizer/sanitizer_common/sanitizer_stacktrace.cc   (revision 
> 209879)
> @@ -18,11 +18,13 @@
>  namespace __sanitizer {
>
>  uptr StackTrace::GetPreviousInstructionPc(uptr pc) {
> -#ifdef __arm__
> +#if defined(__arm__)
>// Cancel Thumb bit.
>pc = pc & (~1);
> -#endif
> -#if defined(__sparc__)
> +#elif defined(__powerpc__) || defined(__powerpc64__)
> +  // PCs are always 4 byte aligned.
> +  return pc - 4;
> +#elif defined(__sparc__)
>return pc - 8;
>  #else
>return pc - 1;
> --- libsanitizer/sanitizer_common/sanitizer_common.h(revision 209878)
> +++ libsanitizer/sanitizer_common/sanitizer_common.h(revision 209879)
> @@ -28,7 +28,11 @@ struct StackTrace;
>  const uptr kWordSize = SANITIZER_WORDSIZE / 8;
>  const uptr kWordSizeInBits = 8 * kWordSize;
>
> -const uptr kCacheLineSize = 64;
> +#if defined(__powerpc__) || defined(__powerpc64__)
> +  const uptr kCacheLineSize = 128;
> +#else
> +  const uptr kCacheLineSize = 64;
> +#endif
>
>  const uptr kMaxPathLength = 512;
>
> --- libsanitizer/asan/asan_mapping.h(revision 209878)
> +++ libsanitizer/asan/asan_mapping.h(revision 209879)
> @@ -87,6 +87,7 @@ static const u64 kDefaultShadowOffset64
>  static const u64 kDefaultShort64bitShadowOffset = 0x7FFF8000;  // < 2G.
>  static const u64 kAArch64_ShadowOffset64 = 1ULL << 36;
>  static const u64 kMIPS32_ShadowOffset32 = 0x0aaa8000;
> +static const u64 kPPC64_ShadowOffset64 = 1ULL << 41;
>  static const u64 kFreeBSD_ShadowOffset32 = 1ULL << 30;  // 0x4000
>  static const u64 kFreeBSD_ShadowOffset64 = 1ULL << 46;  // 0x4000
>
> @@ -109,6 +110,8 @@ static const u64 kFreeBSD_ShadowOffset64
>  # else
>  #  if defined(__aarch64__)
>  #define SHADOW_OFFSET kAArch64_ShadowOffset64
> +#  elif defined(__powerpc64__)
> +#define SHADOW_OFFSET kPPC64_ShadowOffset64
>  #  elif SANITIZER_FREEBSD
>  #define SHADOW_OFFSET kFreeBSD_ShadowOffset64
>  #  elif SANITIZER_MAC
> --- libsanitizer/asan/asan_linux.cc (revision 209878)
> +++ libsanitizer/asan/asan_linux.cc (revision 209879)
> @@ -188,6 +188,13 @@ void GetPcSpBp(void *context, uptr *pc,
>*bp = ucontext->uc_mcontext.gregs[REG_EBP];
>*sp = ucontext->uc_mcontext.gregs[REG_ESP];
>  # endif
> +#elif defined(__powerpc__) || defined(__powerpc64__)
> +  ucontext_t *ucontext = (ucontext_t*)context;
> +  *pc = ucontext->uc_mcontext.regs->nip;
> +  *sp = ucontext->uc_mcontext.regs->gpr[PT_R1];
> +  // The powerpc{,64}-linux ABIs do not specify r31 as the frame
> +  // pointer, but GCC always uses r31 when we need a frame pointer.
> +  *bp = ucontext->uc_mcontext.regs->gpr[PT_R31];
>  #elif defined(__sparc__)
>ucontext_t *ucontext = (ucontext_t*)context;
>uptr *stk_ptr;
> --- libsanitizer/tsan/tsan_mman.cc  (revision 209743)
> +++ libsanitizer/tsan/tsan_mman.cc  (revision 209744)
> @@ -217,19 +217,15 @@ using namespace __tsan;
>
>  extern "C" {
>  uptr __tsan_get_current_allocated_bytes() {
> -  u64 stats[AllocatorStatCount];
> +  uptr stats[AllocatorStatCount];
>allocator()->GetStats(stats);
> -  u64 m = stats[AllocatorStatMalloced];
> -  u64 f = stats[AllocatorStatFreed];
> -  return m >= f ? m - f : 1;
> +  return stats[AllocatorStatAllocated];
>  }
>
>  uptr __tsan_get_heap_size() {
> -  u64 stats[AllocatorStatCount

Re: [PATCH 2/3] PR other/61321 - demangler crash on casts in template parameters

[Ian Lance Taylor]

On Fri, May 30, 2014 at 10:37 AM, Cary Coutant  wrote:
>> Fix this by adding a new DEMANGLE_COMPONENT_CONVERSION component type,
>> which does what DEMANGLE_COMPONENT_CAST does today, and making
>> DEMANGLE_COMPONENT_CAST just simply print its component subtree.
>>
>> I think we could instead reuse DEMANGLE_COMPONENT_CAST and in
>> d_print_comp_inner still do:
>>
>>  @@ -5001,9 +5013,9 @@ d_print_comp_inner (struct d_print_info *dpi, int 
>> options,
>> d_print_comp (dpi, options, dc->u.s_extended_operator.name);
>> return;
>>
>>  case DEMANGLE_COMPONENT_CAST:
>>d_append_string (dpi, "operator ");
>>  - d_print_cast (dpi, options, dc);
>>  + d_print_conversion (dpi, options, dc);
>>return;
>>
>> leaving the unary cast case below calling d_print_cast, but seems to
>> me that spliting the component types makes it easier to reason about
>> the code.
>
> I agree.
>
>> libiberty/
>> 2014-05-27  Pedro Alves 
>>
>> PR other/61321
>> PR other/61233
>> * demangle.h (enum demangle_component_type)
>> : New value.
>> * cp-demangle.c (d_demangle_callback, d_make_comp): Handle
>> DEMANGLE_COMPONENT_CONVERSION.
>> (is_ctor_dtor_or_conversion): Handle DEMANGLE_COMPONENT_CONVERSION
>> instead of DEMANGLE_COMPONENT_CAST.
>> (d_operator_name): Return a DEMANGLE_COMPONENT_CONVERSION
>> component if handling a conversion.
>> (d_count_templates_scopes, d_print_comp_inner): Handle
>> DEMANGLE_COMPONENT_CONVERSION.
>> (d_print_comp_inner): Handle DEMANGLE_COMPONENT_CONVERSION instead
>> of DEMANGLE_COMPONENT_CAST.
>> (d_print_cast): Rename as ...
>> (d_print_conversion): ... this.  Adjust comments.
>> (d_print_cast): Rewrite - simply print the left subcomponent.
>> * cp-demint.c (cplus_demangle_fill_component): Handle
>> DEMANGLE_COMPONENT_CONVERSION.
>>
>> * testsuite/demangle-expected: Add tests.
>
> Looks good to me. Thanks!
>
> Ian, does this look good to you?

I tend to defer to Jason on this sort of newfangled mangling
nuttiness, but I can take a look if he doesn't have time.

Ian

Re: [patch] Update email address in docs

[Jonathan Wakely]

On 30/05/14 19:38 +0200, Paolo Carlini wrote:

Hi,

On 05/30/2014 07:04 PM, Jonathan Wakely wrote:

The docs still give Benjamin's old address for copyright assignment
questions. Changed to my address, although I considered "volunteering"
Paolo to get the mails ;-)
We may considering adding my email too, in the past I did that a lot 
anyway, behind the scenes ;)


Cool, like this then?

commit 95eb2e55844d56db67ed2cf10a031f6e4a9d35d3
Author: Jonathan Wakely 
Date:   Fri May 30 19:21:12 2014 +0100

	* doc/xml/manual/appendix_contributing.xml (list.copyright): Add
	Paolo's address too.

diff --git a/libstdc++-v3/doc/xml/manual/appendix_contributing.xml b/libstdc++-v3/doc/xml/manual/appendix_contributing.xml
index e59e2f7..2c3b9fb 100644
--- a/libstdc++-v3/doc/xml/manual/appendix_contributing.xml
+++ b/libstdc++-v3/doc/xml/manual/appendix_contributing.xml
@@ -110,12 +110,14 @@
 
 
 
-  Please contact Jonathan Wakely at
-  jwakely+ass...@redhat.com if you are confused
-  about the assignment or have general licensing questions. When
-  requesting an assignment form from
+  Please contact
+  Paolo Carlini at paolo.carl...@oracle.com
+  or
+  Jonathan Wakely at jwakely+ass...@redhat.com
+  if you are confused about the assignment or have general licensing
+  questions. When requesting an assignment form from
   ass...@gnu.org, please CC the libstdc++
-  maintainer above so that progress can be monitored.
+  maintainers above so that progress can be monitored.
 
   
 

[patch, arm] fix gcc.target/arm/pr45094.c options

[Sandra Loosemore]

This execution test specifies -mcpu=cortex-a8 but there is no 
corresponding check to make sure that the hardware/simulator being used 
to run the test can run cortex-a8 code.  (The specific case we tripped 
over was in combination with a -mbig-endian multilib; the combination of 
the two options results in BE8 code rather than BE32.)  It seems 
simplest just to remove the specific -mcpu option and rely on the 
multilib options to supply appropriate test flags for the execution 
environment.


OK to commit?

-Sandra


2014-05-30  Julian Brown  
Sandra Loosemore  

gcc/testsuite/
* gcc.target/arm/pr45094.c: Remove -mcpu=cortex-a8, dg-skip-if
options.

Index: gcc/testsuite/gcc.target/arm/pr45094.c
===
--- gcc/testsuite/gcc.target/arm/pr45094.c	(revision 211087)
+++ gcc/testsuite/gcc.target/arm/pr45094.c	(working copy)
@@ -1,7 +1,6 @@
 /* { dg-do run } */
-/* { dg-skip-if "incompatible options" { arm*-*-* } { "-march=*" } { "-march=armv7-a" } } */
 /* { dg-require-effective-target arm_neon_hw } */
-/* { dg-options "-O2 -mcpu=cortex-a8" } */
+/* { dg-options "-O2" } */
 /* { dg-add-options arm_neon } */
 
 #include 

Re: [C++ Patch] PR 57543

[Jason Merrill]

On 05/30/2014 01:36 PM, Paolo Carlini wrote:

3- I understand Core/1227 as including the case of the late return type
vs the parameters of generic lambdas, thus the rather heavy handed tweak
to cp_parser_lambda_declarator_opt, which appears to work under the
debugger (in the sense that for testcases like
cpp1y/lambda-generic-cfun.C I checked that the on flag is still there in
the eventual tsubst_function_type), but I need help about the conversion
operator: should I do something in maybe_add_lambda_conv_op, thus
propagate somehow from TREE_TYPE (callop)?!? In case, it would be easy,
but I need help about the actual semantics we want (this isn't really
about our impl, more about the specs of generic lambdas, sorry).


I don't think we need to worry about the conversion op, as it doesn't 
have any parameters.


The patch is OK.

Jason

Re: [PATCH 2/3] PR other/61321 - demangler crash on casts in template parameters

[Pedro Alves]

On 05/30/2014 07:05 PM, Ian Lance Taylor wrote:
>> > Looks good to me. Thanks!

Thanks Cary!

>> > Ian, does this look good to you?
> I tend to defer to Jason on this sort of newfangled mangling
> nuttiness, but I can take a look if he doesn't have time.

Thanks!

FWIW, it'd be great to have this approved/rejected, as I'd
like to get this fixed in gdb 7.8, and we're just about
to branch.

Thanks,
-- 
Pedro Alves

[PATCH, Fortan] fix initialization of flag_errno_math and flag_associative_math

[VandeVondele Joost]

Hi,

the Fortran FE sets flag_errno_math and flag_associative_math

https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=94447
https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=159620

Seemingly it (now?) needs to communicate that it is doing so, since otherwise 
this is overwritten later on and ignored.

The attached patch does so and comes with two testcases to verify the expected 
effect. 

The patch has been bootstrapped and regtested on x86_64-unknown-linux-gnu. If 
OK, please apply to trunk.

Thanks in advance,

Joostgcc/fortran/ChangeLog:

2014-05-30 Joost VandeVondele  

	* options.c (gfc_init_options_struct): assert that the frontend sets
flag_errno_math and flag_associative_math.

gcc/testsuite/ChangeLog:

2014-05-30 Joost VandeVondele  

	* gfortran.dg/errnocheck_1.f90: New test.
	* gfortran.dg/associative_1.f90: New test.


Index: gcc/fortran/options.c
===
--- gcc/fortran/options.c	(revision 211022)
+++ gcc/fortran/options.c	(working copy)
@@ -66,7 +66,9 @@ void
 gfc_init_options_struct (struct gcc_options *opts)
 {
   opts->x_flag_errno_math = 0;
+  opts->frontend_set_flag_errno_math = true;
   opts->x_flag_associative_math = -1;
+  opts->frontend_set_flag_associative_math = true;
 }
 
 /* Get ready for options handling. Keep in sync with
Index: gcc/testsuite/gfortran.dg/errnocheck_1.f90
===
--- gcc/testsuite/gfortran.dg/errnocheck_1.f90	(revision 0)
+++ gcc/testsuite/gfortran.dg/errnocheck_1.f90	(revision 0)
@@ -0,0 +1,8 @@
+! { dg-do compile { target x86_64-*-* } }
+! Fortran should default to -fno-math-errno
+! and thus no call to sqrt in asm
+subroutine mysqrt(a)
+ real(KIND=KIND(0.0D0)) :: a
+ a=sqrt(a)
+end subroutine
+! { dg-final { scan-assembler-times "call" 0 } }
Index: gcc/testsuite/gfortran.dg/associative_1.f90
===
--- gcc/testsuite/gfortran.dg/associative_1.f90	(revision 0)
+++ gcc/testsuite/gfortran.dg/associative_1.f90	(revision 0)
@@ -0,0 +1,10 @@
+! { dg-do compile }
+! { dg-options "-O1 -fno-signed-zeros -fno-trapping-math -fdump-tree-optimized" }
+! Fortran defaults to associative by default,
+! with -fno-signed-zeros -fno-trapping-math this should optimize away all additions
+SUBROUTINE S1(a)
+ REAL :: a
+ a=1+a-1
+END SUBROUTINE S1
+! { dg-final { scan-tree-dump-times " \\\+ " 0 "optimized" } }
+! { dg-final { cleanup-tree-dump "optimized" } }

Re: [patch] Update email address in docs

[Paolo Carlini]

On 05/30/2014 08:23 PM, Jonathan Wakely wrote:

On 30/05/14 19:38 +0200, Paolo Carlini wrote:

Hi,

On 05/30/2014 07:04 PM, Jonathan Wakely wrote:

The docs still give Benjamin's old address for copyright assignment
questions. Changed to my address, although I considered "volunteering"
Paolo to get the mails ;-)
We may considering adding my email too, in the past I did that a lot 
anyway, behind the scenes ;)


Cool, like this then?

Sure.

Paolo.

Re: [AArch64/ARM 2/3] Detect EXT patterns to vec_perm_const, use for EXT intrinsics

[Christophe Lyon]

Hi Alan

This causes g++ to ICE on pr59378 test, for aarch64 targets:
http://cbuild.validation.linaro.org/build/cross-validation/gcc/211058/report-build-info.html

Can you check?

Thanks,

Christophe.


On 19 May 2014 14:53, Marcus Shawcroft  wrote:
> On 23 April 2014 21:22, Alan Lawrence  wrote:
>
>> 2014-03-27  Alan Lawrence  
>> * config/aarch64/aarch64-builtins.c
>> (aarch64_types_binopv_qualifiers,
>> TYPES_BINOPV): New static data.
>> * config/aarch64/aarch64-simd-builtins.def (im_lane_bound): New
>> builtin.
>> * config/aarch64/aarch64-simd.md (aarch64_ext,
>> aarch64_im_lane_boundsi):
>> New patterns.
>> * config/aarch64/aarch64.c (aarch64_expand_vec_perm_const_1): Match
>> patterns for EXT.
>> (aarch64_evpc_ext): New function.
>>
>> * config/aarch64/iterators.md (UNSPEC_EXT): New enum element.
>>
>> * config/aarch64/arm_neon.h (vext_f32, vext_f64, vext_p8, vext_p16,
>> vext_s8, vext_s16, vext_s32, vext_s64, vext_u8, vext_u16, vext_u32,
>> vext_u64, vextq_f32, vextq_f64, vextq_p8, vextq_p16, vextq_s8,
>> vextq_s16, vextq_s32, vextq_s64, vextq_u8, vextq_u16, vextq_u32,
>> vextq_u64): Replace __asm with __builtin_shuffle and
>> im_lane_boundsi.
>
>
> OK /Marcus

Re: ipa-visibility TLC 2/n

[Jan Hubicka]

> Honza,
> 
> For example g++.dg/abi/vcall1.C fails at a call in a "localalias"
> function, which jumps to a bad location:
> 
> 
> (gdb) up
> #1  0x14c0 in B::B() [clone .localalias.2] ()
> (gdb) x/16i $pc-32
>0x14a0 <_ZN1BC2Ev+156>:  add r10,r10,r8
>0x14a4 <_ZN1BC2Ev+160>:  mr  r3,r10
>0x14a8 <_ZN1BC2Ev+164>:  stw r2,20(r1)
>0x14ac <_ZN1BC2Ev+168>:  lwz r10,0(r9)
>0x14b0 <_ZN1BC2Ev+172>:  lwz r11,8(r9)
>0x14b4 <_ZN1BC2Ev+176>:  mtctr   r10
>0x14b8 <_ZN1BC2Ev.localalias.2+180>: lwz r2,4(r9)
>0x14bc <_ZN1BC2Ev.localalias.2+184>: bctrl
> => 0x14c0 <_ZN1BC2Ev.localalias.2+188>: lwz r2,20(r1)
>0x14c4 <_ZN1BC2Ev.localalias.2+192>: addir1,r31,64
>0x14c8 <_ZN1BC2Ev.localalias.2+196>: lwz r0,8(r1)
>0x14cc <_ZN1BC2Ev.localalias.2+200>: mtlrr0
>0x14d0 <_ZN1BC2Ev.localalias.2+204>: lwz r31,-4(r1)
>0x14d4 <_ZN1BC2Ev.localalias.2+208>: blr

I suppose this is the problem Richard mentioned - the offsets are not computed
by DECL_RTL callback but by place_block. 

> >>> is SYMBOL_REF_BLOCK_OFFSET (target) guaranteed to be valid at this point?
> >>> It looked at face value like you'd need a recursive call to 
> >>> place_block_symbol
> >>> on the target before the copy.
> >>
> >> My reading was that SYMBOL_REF_BLOCK_OFFSET is computed at DECL_RTL
> >> calculation time. But you are right - it is done by validize_mem that
> >> is not done by DECL_RTL.  Shall I just call it on target first?
> >
> > Yeah, sounds like calling place_block_symbol would be safer.

I will test:
Index: varasm.c
===
--- varasm.c(revision 211096)
+++ varasm.c(working copy)
@@ -7094,6 +7094,7 @@
   if (snode->alias)
{
  rtx target = DECL_RTL (symtab_alias_ultimate_target (snode)->decl);
+ place_block_symbol (symbol);
  SYMBOL_REF_BLOCK_OFFSET (symbol) = SYMBOL_REF_BLOCK_OFFSET (target);
  return;
}


Honza
> >
> > IIRC, the reason I didn't do it at SET_DECL_RTL time is that some frontends
> > tended to create placeholder decls that for whatever reason ended up with
> > an initial DECL_RTL, then changed the properties of the decl later once
> > more information was known.  (This was all many years ago.)
> >
> > Thanks,
> > Richard

[PATCH] Updates merged bb count

[Dehao Chen]

This patch updates the merged bb count only when they are in the same loop.

Bootstrapped and passed regression test.

Ok for trunk?

Thanks,
Dehao

gcc/ChangeLog:
2014-05-30  Dehao Chen  

* tree-cfg.c (gimple_merge_blocks): Only reset count when BBs are in
the same loop.

gcc/testsuite/ChangeLog:
2014-05-30  Dehao Chen  

* gcc.dg/tree-prof/merge_block.c: New test.

Index: gcc/testsuite/gcc.dg/tree-prof/merge_block.c
===
--- gcc/testsuite/gcc.dg/tree-prof/merge_block.c (revision 0)
+++ gcc/testsuite/gcc.dg/tree-prof/merge_block.c (revision 0)
@@ -0,0 +1,20 @@
+
+/* { dg-options "-O2 -fno-ipa-pure-const
-fdump-tree-optimized-blocks-details -fno-early-inlining" } */
+int a[8];
+int t()
+{
+ int i;
+ for (i = 0; i < 3; i++)
+ if (a[i])
+ break;
+ return i;
+}
+main ()
+{
+  int i;
+  for (i = 0; i < 1000; i++)
+t ();
+  return 0;
+}
+/* { dg-final-use { scan-tree-dump-not "Invalid sum" "optimized"} } */
+/* { dg-final-use { cleanup-tree-dump "optimized" } } */
Index: gcc/tree-cfg.c
===
--- gcc/tree-cfg.c (revision 211096)
+++ gcc/tree-cfg.c (working copy)
@@ -1880,8 +1880,11 @@ gimple_merge_blocks (basic_block a, basic_block b)
   /* When merging two BBs, if their counts are different, the larger count
  is selected as the new bb count. This is to handle inconsistent
  profiles.  */
-  a->count = MAX (a->count, b->count);
-  a->frequency = MAX (a->frequency, b->frequency);
+  if (a->loop_father == b->loop_father)
+{
+  a->count = MAX (a->count, b->count);
+  a->frequency = MAX (a->frequency, b->frequency);
+}

   /* Merge the sequences.  */
   last = gsi_last_bb (a);

Re: [patch, mips, tree] align microMIPS functions to 16 bits with -Os

[Sandra Loosemore]

On 05/28/2014 01:09 PM, Richard Sandiford wrote:

Sandra Loosemore  writes:


On 05/19/2014 01:38 PM, Sandra Loosemore wrote:


2014-05-19  Iain Sandoe  
  Catherine Moore  
  Sandra Loosemore  

  gcc/
  * config/mips/mips.c (mips_set_current_function): Choose
  function alignment once the current mode is known.

  gcc/testsuite/
  * gcc.target/mips/umips-align-1.c: New.
  * gcc.target/mips/umips-align-2.c: New.
  * gcc.target/mips/umips-align-3.c: New.
  * gcc.target/mips/mips.exp: Add interlink-compressed to
  -mfoo/-mno-foo options.


Ping?

https://gcc.gnu.org/ml/gcc-patches/2014-05/msg01536.html

-Sandra


FAOD, I wasn't commenting because I still think it's the wrong place but
still don't have a specific counter-suggestion.  mips_set_current_function
is potentially called many times for the same function but setting the
alignment seems like something that should only happen once.  I think it
could potentially mean that alignment tests against the function address
could be optimised away based on the FUNCTION_BOUNDARY before
mips_set_current_function is called.

As a strawman, maybe adding a new target hook to cgraph_create_node
would work?


H, why there?


Hopefully that'll prompt someone to say how stupid that
idea is and say what the right way of doing it would be.


If the implementation in the current patch is considered too stupid, I'd 
rather spend my time implementing a plausibly correct version on my next 
try instead of another stupid one.


My best guess is that this belongs somewhere in stor-layout.c, but the 
comments on layout_decl explicitly say FUNCTION_DECLs are not handled 
there, and I am not so familiar with the code as to be able to identify 
all the places where FUNCTION_DECLs ought to get their storage laid out 
but are not currently having it done.  So that's probably a stupid idea, 
too  :-(


-Sandra

Re: [patch i386]: Expand sibling-tail-calls via accumulator register

[H.J. Lu]

On Fri, May 30, 2014 at 9:51 AM, Kai Tietz  wrote:
> - Original Message -
>> On 05/30/2014 01:08 AM, Kai Tietz wrote:
>> > (define_predicate "sibcall_memory_operand"
>> >   (match_operand 0 "memory_operand")
>> > {
>> >   return CONSTANT_P (op);
>> > })
>>
>> Surely that always returns false?  Surely XEXP (op, 0) so that you look at
>> the
>> address, not the memory.
>>
>>
>> r~
>>
>
> Doh ... of course
>
>
> (define_predicate "sibcall_memory_operand"
>   (match_operand 0 "memory_operand")
> {
>   return CONSTANT_P (XEXP (op, 0));
> })
>
>
> Actually I tested the proper version :}
>

Have you tested bootstrap on i686?  I think it may have broken bootstrap
on i686:

https://gcc.gnu.org/ml/gcc-regression/2014-05/msg00408.html

-- 
H.J.

Re: [GOOGLE] Emit linkage_name when built with -gmlt and for abstract decls

[Dehao Chen]

As we are pushing AutoFDO patch upstream, is this patch OK for trunk?

Thanks,
Dehao

On Mon, Aug 19, 2013 at 1:32 PM, Dehao Chen  wrote:
> After rerunning test, this will fail one gcc regression test. So I
> updated the patch to make sure all test will pass:
>
> Index: gcc/dwarf2out.c
> ===
> --- gcc/dwarf2out.c (revision 201850)
> +++ gcc/dwarf2out.c (working copy)
> @@ -16545,10 +16545,9 @@ add_src_coords_attributes (dw_die_ref die, tree de
>  static void
>  add_linkage_name (dw_die_ref die, tree decl)
>  {
> -  if (debug_info_level > DINFO_LEVEL_TERSE
> +  if (debug_info_level > DINFO_LEVEL_NONE
>&& (TREE_CODE (decl) == FUNCTION_DECL || TREE_CODE (decl) == VAR_DECL)
>&& TREE_PUBLIC (decl)
> -  && !DECL_ABSTRACT (decl)
>&& !(TREE_CODE (decl) == VAR_DECL && DECL_REGISTER (decl))
>&& die->die_tag != DW_TAG_member)
>  {
> Index: gcc/testsuite/g++.dg/debug/dwarf2/cdtor-1.C
> ===
> --- gcc/testsuite/g++.dg/debug/dwarf2/cdtor-1.C (revision 201850)
> +++ gcc/testsuite/g++.dg/debug/dwarf2/cdtor-1.C (working copy)
> @@ -14,4 +14,4 @@ main()
>K k;
>  }
>
> -// { dg-final {scan-assembler-times " DW_AT_\[MIPS_\]*linkage_name" 2 } }
> +// { dg-final {scan-assembler-times " DW_AT_\[MIPS_\]*linkage_name" 4 } }
>
> On Mon, Aug 19, 2013 at 9:22 AM, Cary Coutant  wrote:
>>> This patch emits linkage_name at -gmlt. It also make sure abstract
>>> decls' linkage_names are emitted so that inlined functions can also
>>> find linkage name.
>>>
>>> Bootstrapped and passed regression test.
>>>
>>> OK for google branches?
>>
>> OK.
>>
>> -cary

[PATCH, PR 61211] Fix a bug in clone_of_p verification

[Martin Jambor]

Hi,

after a clone is materialized, its clone_of field is cleared which in
PR 61211 leads to a failure in the skipped_thunk path in clone_of_p in
cgraph.c, which then leads to a false positive verification failure.

Fixed by the following patch.  Bootstrapped and tested on x86_64-linux
on both the trunk and the 4.9 branch.  OK for both?

Thanks,

Martin


2014-05-30  Martin Jambor  

PR ipa/61211
* cgraph.c (clone_of_p): Allow skipped_branch to deal with
expanded clones.

diff --git a/gcc/cgraph.c b/gcc/cgraph.c
index ff65b86..f18f977 100644
--- a/gcc/cgraph.c
+++ b/gcc/cgraph.c
@@ -2566,11 +2566,16 @@ clone_of_p (struct cgraph_node *node, struct 
cgraph_node *node2)
   skipped_thunk = true;
 }
 
-  if (skipped_thunk
-  && (!node2->clone_of
- || !node2->clone.args_to_skip
- || !bitmap_bit_p (node2->clone.args_to_skip, 0)))
-return false;
+  if (skipped_thunk)
+{
+  if (!node2->clone.args_to_skip
+ || !bitmap_bit_p (node2->clone.args_to_skip, 0))
+   return false;
+  if (node2->former_clone_of == node->decl)
+   return true;
+  else if (!node2->clone_of)
+   return false;
+}
 
   while (node != node2 && node2)
 node2 = node2->clone_of;

Re: [patch i386]: Expand sibling-tail-calls via accumulator register

[H.J. Lu]

On Fri, May 30, 2014 at 3:05 PM, H.J. Lu  wrote:
> On Fri, May 30, 2014 at 9:51 AM, Kai Tietz  wrote:
>> - Original Message -
>>> On 05/30/2014 01:08 AM, Kai Tietz wrote:
>>> > (define_predicate "sibcall_memory_operand"
>>> >   (match_operand 0 "memory_operand")
>>> > {
>>> >   return CONSTANT_P (op);
>>> > })
>>>
>>> Surely that always returns false?  Surely XEXP (op, 0) so that you look at
>>> the
>>> address, not the memory.
>>>
>>>
>>> r~
>>>
>>
>> Doh ... of course
>>
>>
>> (define_predicate "sibcall_memory_operand"
>>   (match_operand 0 "memory_operand")
>> {
>>   return CONSTANT_P (XEXP (op, 0));
>> })
>>
>>
>> Actually I tested the proper version :}
>>
>
> Have you tested bootstrap on i686?  I think it may have broken bootstrap
> on i686:
>
> https://gcc.gnu.org/ml/gcc-regression/2014-05/msg00408.html
>

The function is

void
ira_traverse_loop_tree (bool bb_p, ira_loop_tree_node_t loop_node,
void (*preorder_func) (ira_loop_tree_node_t),
void (*postorder_func) (ira_loop_tree_node_t))
{
...
if (postorder_func != NULL)
  (*postorder_func) (loop_node);
}

postorder_func is passed on stack for i686 and we generate

   jmp*0x28(%esp)

sibcall invalidates the original arguments on stack and puts
the new argument on stack.  There is no place on stack to
be used for indirect sibcall via memory.  In this case,
sibcall_memory_operand should return false.

-- 
H.J.

[PATCH, PR 61160] IPA-CP and edges leading to thunks of clones

[Martin Jambor]

Hi,

PR 61160 is actually two problems, this patch deals with the one
reported in comment one.  The underlying cause is that an IPA-CP test
whether an edge is already leading to a clone does not look through
thunks, which caused it to double count and doubly-redirect them.

Bootstrapped and tested on x86_64-linux, I will run the test on the
4.9 branch later.  OK for both if it passed everywhere?

Thanks,

Martin


2014-05-28  Martin Jambor  

PR ipa/61160
* ipa-cp.c (cgraph_edge_brings_value_p): Handle edges leading to
thunks.

testsuite/
* g++.dg/ipa/pr61160-1.C: New test.

diff --git a/gcc/ipa-cp.c b/gcc/ipa-cp.c
index d1f882a..2ebfd18 100644
--- a/gcc/ipa-cp.c
+++ b/gcc/ipa-cp.c
@@ -2482,7 +2482,8 @@ cgraph_edge_brings_value_p (struct cgraph_edge *cs,
struct ipcp_value_source *src)
 {
   struct ipa_node_params *caller_info = IPA_NODE_REF (cs->caller);
-  struct ipa_node_params *dst_info = IPA_NODE_REF (cs->callee);
+  cgraph_node *real_dest = cgraph_function_node (cs->callee);
+  struct ipa_node_params *dst_info = IPA_NODE_REF (real_dest);
 
   if ((dst_info->ipcp_orig_node && !dst_info->is_all_contexts_clone)
   || caller_info->node_dead)
diff --git a/gcc/testsuite/g++.dg/ipa/pr61160-1.C 
b/gcc/testsuite/g++.dg/ipa/pr61160-1.C
new file mode 100644
index 000..a0fbb5f
--- /dev/null
+++ b/gcc/testsuite/g++.dg/ipa/pr61160-1.C
@@ -0,0 +1,31 @@
+/* { dg-do compile } */
+/* { dg-options "-O3"  } */
+
+struct CBase {
+  virtual void BaseFunc () {}
+};
+
+struct MMixin {
+  virtual void * MixinFunc (int, void *) = 0;
+};
+
+struct CExample: CBase, public MMixin
+{
+  void *MixinFunc (int arg, void *arg2)
+  {
+if (arg != 1 || arg2)
+  return 0;
+return this;
+  }
+};
+
+void *test (MMixin & anExample)
+{
+  return anExample.MixinFunc (1, 0);
+}
+
+int main ()
+{
+  CExample c;
+  return (test (c) != &c);
+}

Re: [patch i386]: Expand sibling-tail-calls via accumulator register

[Bernd Edlinger]

Hi Kai,

this patch also mis-compiles binuitls-2.24 on x86_64.

In the function walk_wild_consider_section (ld/ldlang.c)
a tail-call gets miscompiled:

The stack frame is cleaned up, but now the jump target is invalid.

   0x0040c801 <+193>:    add    $0x28,%rsp
   0x0040c805 <+197>:    mov    %r13,%rsi
   0x0040c808 <+200>:    pop    %rbx
   0x0040c809 <+201>:    mov    %r14,%rdi
   0x0040c80c <+204>:    pop    %rbp
   0x0040c80d <+205>:    pop    %r12
   0x0040c80f <+207>:    pop    %r13
   0x0040c811 <+209>:    pop    %r14
   0x0040c813 <+211>:    pop    %r15
   0x0040c815 <+213>:    jmpq   *0x10(%rsp)

before the patch the sequence did save the jump target in rax:

   0x0040c801 <+193>:    mov    0x10(%rsp),%rax
   0x0040c806 <+198>:    add    $0x28,%rsp
   0x0040c80a <+202>:    pop    %rbx
   0x0040c80b <+203>:    mov    %r13,%rsi
   0x0040c80e <+206>:    mov    %r14,%rdi
   0x0040c811 <+209>:    pop    %rbp
   0x0040c812 <+210>:    pop    %r12
   0x0040c814 <+212>:    pop    %r13
   0x0040c816 <+214>:    pop    %r14
   0x0040c818 <+216>:    pop    %r15
   0x0040c81a <+218>:    jmpq   *%rax


Regards
Bernd.
  

[PATCH, PR 61160] Artificial thunks need combined_args_to_skip

[Martin Jambor]

Hi,

the second issue in PR 61160 is that because artificial thunks
(produced by duplicate_thunk_for_node) do not have
combined_args_to_skip, calls to them do not get actual arguments
removed, while the actual functions do loose their formal parameters,
leading to mismatches.

Currently, the combined_args_to_skip is computed in of
cgraph_create_virtual_clone only after all the edge redirection and
thunk duplication is done so it had to be moved to a spot before
that.  Since we already pass args_to_skip to cgraph_clone_node, I
moved the computation there (otherwise it would have to duplicate the
old value and also pass the new one to the redirection routine).

I have also noticed that the code producing combined_args_to_skip from
an old value and new args_to_skip cannot work in LTO because we do not
have DECL_ARGUMENTS available at WPA in LTO.  The wrong code is
however never executed and so I replaced it with a simple bitmap_ior.
This changes the semantics of args_to_skip for any user of
cgraph_create_virtual_clone that would like to remove some parameters
from something which is already a clone.  However, currently there are
no such users and the new semantics is saner because WPA code will be
happier using the old indices rather than remapping everything the
whole time.

I am still in the process of bootstrapping and testing this patch on
trunk, I will test it on the 4.9 branch too.  OK if it passes
everywhere?

Thanks,

Martin



2014-05-29  Martin Jambor  

PR ipa/61160
* cgraphclones.c (duplicate_thunk_for_node): Removed parameter
args_to_skip, use those from node instead.  Copy args_to_skip and
combined_args_to_skip from node to the new thunk.
(redirect_edge_duplicating_thunks): Removed parameter args_to_skip.
(cgraph_create_virtual_clone): Moved computation of
combined_args_to_skip...
(cgraph_clone_node): ...here, simplify it to bitmap_ior..

testsuite/
* g++.dg/ipa/pr61160-2.C: New test.
* g++.dg/ipa/pr61160-3.C: Likewise.

diff --git a/gcc/cgraphclones.c b/gcc/cgraphclones.c
index 4387b99..91cc13c 100644
--- a/gcc/cgraphclones.c
+++ b/gcc/cgraphclones.c
@@ -301,14 +301,13 @@ set_new_clone_decl_and_node_flags (cgraph_node *new_node)
thunk is this_adjusting but we are removing this parameter.  */
 
 static cgraph_node *
-duplicate_thunk_for_node (cgraph_node *thunk, cgraph_node *node,
- bitmap args_to_skip)
+duplicate_thunk_for_node (cgraph_node *thunk, cgraph_node *node)
 {
   cgraph_node *new_thunk, *thunk_of;
   thunk_of = cgraph_function_or_thunk_node (thunk->callees->callee);
 
   if (thunk_of->thunk.thunk_p)
-node = duplicate_thunk_for_node (thunk_of, node, args_to_skip);
+node = duplicate_thunk_for_node (thunk_of, node);
 
   struct cgraph_edge *cs;
   for (cs = node->callers; cs; cs = cs->next_caller)
@@ -320,17 +319,18 @@ duplicate_thunk_for_node (cgraph_node *thunk, cgraph_node 
*node,
   return cs->caller;
 
   tree new_decl;
-  if (!args_to_skip)
+  if (!node->clone.args_to_skip)
 new_decl = copy_node (thunk->decl);
   else
 {
   /* We do not need to duplicate this_adjusting thunks if we have removed
 this.  */
   if (thunk->thunk.this_adjusting
- && bitmap_bit_p (args_to_skip, 0))
+ && bitmap_bit_p (node->clone.args_to_skip, 0))
return node;
 
-  new_decl = build_function_decl_skip_args (thunk->decl, args_to_skip,
+  new_decl = build_function_decl_skip_args (thunk->decl,
+   node->clone.args_to_skip,
false);
 }
   gcc_checking_assert (!DECL_STRUCT_FUNCTION (new_decl));
@@ -348,6 +348,8 @@ duplicate_thunk_for_node (cgraph_node *thunk, cgraph_node 
*node,
   new_thunk->thunk = thunk->thunk;
   new_thunk->unique_name = in_lto_p;
   new_thunk->former_clone_of = thunk->decl;
+  new_thunk->clone.args_to_skip = node->clone.args_to_skip;
+  new_thunk->clone.combined_args_to_skip = node->clone.combined_args_to_skip;
 
   struct cgraph_edge *e = cgraph_create_edge (new_thunk, node, NULL, 0,
  CGRAPH_FREQ_BASE);
@@ -364,12 +366,11 @@ duplicate_thunk_for_node (cgraph_node *thunk, cgraph_node 
*node,
chain.  */
 
 void
-redirect_edge_duplicating_thunks (struct cgraph_edge *e, struct cgraph_node *n,
- bitmap args_to_skip)
+redirect_edge_duplicating_thunks (struct cgraph_edge *e, struct cgraph_node *n)
 {
   cgraph_node *orig_to = cgraph_function_or_thunk_node (e->callee);
   if (orig_to->thunk.thunk_p)
-n = duplicate_thunk_for_node (orig_to, n, args_to_skip);
+n = duplicate_thunk_for_node (orig_to, n);
 
   cgraph_redirect_edge_callee (e, n);
 }
@@ -422,9 +423,21 @@ cgraph_clone_node (struct cgraph_node *n, tree decl, 
gcov_type count, int freq,
   new_node->rtl = n->rtl;
   new_node->count = count;
   new_node->frequency = n->frequency;
-  new_no

Re: [patch i386]: Expand sibling-tail-calls via accumulator register

[Tom de Vries]

On 28-05-14 10:43, Kai Tietz wrote:

Index: gcc/testsuite/gcc.target/i386/sibcall-4.c
===
--- gcc/testsuite/gcc.target/i386/sibcall-4.c   (revision 0)
+++ gcc/testsuite/gcc.target/i386/sibcall-4.c   (working copy)
@@ -0,0 +1,15 @@
+/* Testcase for PR target/46219.  */
+/* { dg-do compile { xfail { *-*-* } } */


Hi,

I've committed this follow-up patch to add a missing closing brace.

Thanks,
- Tom
2014-05-31  Tom de Vries  

	* gcc.target/i386/sibcall-4.c: Add missing closing brace.

diff --git a/gcc/testsuite/gcc.target/i386/sibcall-4.c b/gcc/testsuite/gcc.target/i386/sibcall-4.c
index e157338..e9ae939 100644
--- a/gcc/testsuite/gcc.target/i386/sibcall-4.c
+++ b/gcc/testsuite/gcc.target/i386/sibcall-4.c
@@ -1,5 +1,5 @@
 /* Testcase for PR target/46219.  */
-/* { dg-do compile { xfail { *-*-* } } */
+/* { dg-do compile { xfail { *-*-* } } } */
 /* { dg-require-effective-target ia32 } */
 /* { dg-options "-O2" } */
 
-- 
1.9.1

Re: [GOOGLE] Emit linkage_name when built with -gmlt and for abstract decls

[Dehao Chen]

This will increase c++ g1/g2 binary size a little. For all spec
cint2006 benchmarks, the binary size change is shown below.

400 0.00% 0.00% 0.00% 0.00%
401 0.00% 0.00% 0.00% 0.00%
403 0.00% 0.00% 0.00% 0.00%
429 0.00% 0.00% 0.00% 0.00%
445 0.00% 0.00% 0.00% 0.00%
456 0.00% 0.00% 0.00% 0.00%
458 0.00% 0.00% 0.00% 0.00%
462 0.00% 0.00% 0.00% 0.00%
464 0.00% 0.00% 0.00% 0.00%
471 1.28% 0.20% 1.23% 0.15%
473 0.36% 0.00% 0.35% 0.01%
483 12.79% 1.73% 13.65% 2.12%
geomean 1.14% 0.16% 1.20% 0.19%

The 4 columns are:

o0 -g1
o0 -g2
o2 -g1
o2 -g2

Thanks,
Dehao

On Fri, May 30, 2014 at 3:23 PM, Dehao Chen  wrote:
> As we are pushing AutoFDO patch upstream, is this patch OK for trunk?
>
> Thanks,
> Dehao
>
> On Mon, Aug 19, 2013 at 1:32 PM, Dehao Chen  wrote:
>> After rerunning test, this will fail one gcc regression test. So I
>> updated the patch to make sure all test will pass:
>>
>> Index: gcc/dwarf2out.c
>> ===
>> --- gcc/dwarf2out.c (revision 201850)
>> +++ gcc/dwarf2out.c (working copy)
>> @@ -16545,10 +16545,9 @@ add_src_coords_attributes (dw_die_ref die, tree de
>>  static void
>>  add_linkage_name (dw_die_ref die, tree decl)
>>  {
>> -  if (debug_info_level > DINFO_LEVEL_TERSE
>> +  if (debug_info_level > DINFO_LEVEL_NONE
>>&& (TREE_CODE (decl) == FUNCTION_DECL || TREE_CODE (decl) == VAR_DECL)
>>&& TREE_PUBLIC (decl)
>> -  && !DECL_ABSTRACT (decl)
>>&& !(TREE_CODE (decl) == VAR_DECL && DECL_REGISTER (decl))
>>&& die->die_tag != DW_TAG_member)
>>  {
>> Index: gcc/testsuite/g++.dg/debug/dwarf2/cdtor-1.C
>> ===
>> --- gcc/testsuite/g++.dg/debug/dwarf2/cdtor-1.C (revision 201850)
>> +++ gcc/testsuite/g++.dg/debug/dwarf2/cdtor-1.C (working copy)
>> @@ -14,4 +14,4 @@ main()
>>K k;
>>  }
>>
>> -// { dg-final {scan-assembler-times " DW_AT_\[MIPS_\]*linkage_name" 2 } }
>> +// { dg-final {scan-assembler-times " DW_AT_\[MIPS_\]*linkage_name" 4 } }
>>
>> On Mon, Aug 19, 2013 at 9:22 AM, Cary Coutant  wrote:
 This patch emits linkage_name at -gmlt. It also make sure abstract
 decls' linkage_names are emitted so that inlined functions can also
 find linkage name.

 Bootstrapped and passed regression test.

 OK for google branches?
>>>
>>> OK.
>>>
>>> -cary

Re: [PATCH] Updates merged bb count

[Steven Bosscher]

On Fri, May 30, 2014 at 11:43 PM, Dehao Chen wrote:
> Index: gcc/testsuite/gcc.dg/tree-prof/merge_block.c
> ===
> --- gcc/testsuite/gcc.dg/tree-prof/merge_block.c (revision 0)
> +++ gcc/testsuite/gcc.dg/tree-prof/merge_block.c (revision 0)
> @@ -0,0 +1,20 @@
> +
> +/* { dg-options "-O2 -fno-ipa-pure-const
> -fdump-tree-optimized-blocks-details -fno-early-inlining" } */
> +int a[8];
> +int t()
> +{
> + int i;
> + for (i = 0; i < 3; i++)
> + if (a[i])
> + break;
> + return i;
> +}
> +main ()
> +{
> +  int i;
> +  for (i = 0; i < 1000; i++)
> +t ();
> +  return 0;
> +}
> +/* { dg-final-use { scan-tree-dump-not "Invalid sum" "optimized"} } */
> +/* { dg-final-use { cleanup-tree-dump "optimized" } } */


I suppose you want to avoid having t() inlined into main()? If so,
then I'd suggest adding __attribute__((__noinline__,__noclone__)) to
"robustify" the test case.

Ciao!
Steven

Re: [PATCH] Updates merged bb count

[Dehao Chen]

Thanks for the suggestion. I actually want this function to be inlined
in ipa-inline phase, not einline phase.

Dehao

On Fri, May 30, 2014 at 4:50 PM, Steven Bosscher  wrote:
> On Fri, May 30, 2014 at 11:43 PM, Dehao Chen wrote:
>> Index: gcc/testsuite/gcc.dg/tree-prof/merge_block.c
>> ===
>> --- gcc/testsuite/gcc.dg/tree-prof/merge_block.c (revision 0)
>> +++ gcc/testsuite/gcc.dg/tree-prof/merge_block.c (revision 0)
>> @@ -0,0 +1,20 @@
>> +
>> +/* { dg-options "-O2 -fno-ipa-pure-const
>> -fdump-tree-optimized-blocks-details -fno-early-inlining" } */
>> +int a[8];
>> +int t()
>> +{
>> + int i;
>> + for (i = 0; i < 3; i++)
>> + if (a[i])
>> + break;
>> + return i;
>> +}
>> +main ()
>> +{
>> +  int i;
>> +  for (i = 0; i < 1000; i++)
>> +t ();
>> +  return 0;
>> +}
>> +/* { dg-final-use { scan-tree-dump-not "Invalid sum" "optimized"} } */
>> +/* { dg-final-use { cleanup-tree-dump "optimized" } } */
>
>
> I suppose you want to avoid having t() inlined into main()? If so,
> then I'd suggest adding __attribute__((__noinline__,__noclone__)) to
> "robustify" the test case.
>
> Ciao!
> Steven

Re: ipa-visibility TLC 2/n

[David Edelsohn]

Honza,

With the patch, I cannot bootstrap.

I am concerned about the much greater frequency of AIX linker warnings
about branch not followed by no-op after your patch.

GCC may bootstrap only because it links libstdc++ statically. If your
patch is too aggressive in its effort to remove PLT calls, it may be
breaking shared library support on AIX. Previously there were a few
recursive libstdc++ calls that binds_local_p() asserted were bound
locally to functions declared global.  I hope that cross-module calls
have not been incorrectly analyzed as local.

Thanks, David


On Fri, May 30, 2014 at 5:02 PM, Jan Hubicka  wrote:
>> Honza,
>>
>> For example g++.dg/abi/vcall1.C fails at a call in a "localalias"
>> function, which jumps to a bad location:
>>
>>
>> (gdb) up
>> #1  0x14c0 in B::B() [clone .localalias.2] ()
>> (gdb) x/16i $pc-32
>>0x14a0 <_ZN1BC2Ev+156>:  add r10,r10,r8
>>0x14a4 <_ZN1BC2Ev+160>:  mr  r3,r10
>>0x14a8 <_ZN1BC2Ev+164>:  stw r2,20(r1)
>>0x14ac <_ZN1BC2Ev+168>:  lwz r10,0(r9)
>>0x14b0 <_ZN1BC2Ev+172>:  lwz r11,8(r9)
>>0x14b4 <_ZN1BC2Ev+176>:  mtctr   r10
>>0x14b8 <_ZN1BC2Ev.localalias.2+180>: lwz r2,4(r9)
>>0x14bc <_ZN1BC2Ev.localalias.2+184>: bctrl
>> => 0x14c0 <_ZN1BC2Ev.localalias.2+188>: lwz r2,20(r1)
>>0x14c4 <_ZN1BC2Ev.localalias.2+192>: addir1,r31,64
>>0x14c8 <_ZN1BC2Ev.localalias.2+196>: lwz r0,8(r1)
>>0x14cc <_ZN1BC2Ev.localalias.2+200>: mtlrr0
>>0x14d0 <_ZN1BC2Ev.localalias.2+204>: lwz r31,-4(r1)
>>0x14d4 <_ZN1BC2Ev.localalias.2+208>: blr
>
> I suppose this is the problem Richard mentioned - the offsets are not computed
> by DECL_RTL callback but by place_block.
>
>> >>> is SYMBOL_REF_BLOCK_OFFSET (target) guaranteed to be valid at this point?
>> >>> It looked at face value like you'd need a recursive call to 
>> >>> place_block_symbol
>> >>> on the target before the copy.
>> >>
>> >> My reading was that SYMBOL_REF_BLOCK_OFFSET is computed at DECL_RTL
>> >> calculation time. But you are right - it is done by validize_mem that
>> >> is not done by DECL_RTL.  Shall I just call it on target first?
>> >
>> > Yeah, sounds like calling place_block_symbol would be safer.
>
> I will test:
> Index: varasm.c
> ===
> --- varasm.c(revision 211096)
> +++ varasm.c(working copy)
> @@ -7094,6 +7094,7 @@
>if (snode->alias)
> {
>   rtx target = DECL_RTL (symtab_alias_ultimate_target (snode)->decl);
> + place_block_symbol (symbol);
>   SYMBOL_REF_BLOCK_OFFSET (symbol) = SYMBOL_REF_BLOCK_OFFSET (target);
>   return;
> }
>
>
> Honza
>> >
>> > IIRC, the reason I didn't do it at SET_DECL_RTL time is that some frontends
>> > tended to create placeholder decls that for whatever reason ended up with
>> > an initial DECL_RTL, then changed the properties of the decl later once
>> > more information was known.  (This was all many years ago.)
>> >
>> > Thanks,
>> > Richard

[C++11, C++14 PATCH 0/3] Support for SD-6: SG10 Feature Test Recommendations

[Ed Smith-Rowland]

A group within the C++ standards committee was charged with the 
responibility of coming up with a way for users to test a C++ compiler 
and runtime for the availability of new features.  These features are 
intended to aid users in a time of intense C++ evolution.  These 
features are not really part of the C++ standard and probably can't be 
really.


The latest paper is:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4030.htm

Also, an earlier version is supplied as a standing document on the 
isocpp website:

https://isocpp.org/std/standing-documents/sd-6-sg10-feature-test-recommendations

The current patch implements __has_include and many of the language 
feature and library version macros outlined in these documents.


I builds and tests clean on x86_64-linux.

I anticipate that the next C++ meeting will see some additions (new 
library and language macros and a __has_cpp_attribute).  I will add 
these as a separate patch if needed.


I took the liberty of adding __has_include_next.  clang has both 
__has_include and __has_include_next.  Also, while the underlying cpp 
builtin that supports __has_include, __has_include__, is available to C 
and C++ in all language versions, the macro __has_include is only 
available for C++11 onwards.  One could however anticipate that this 
feature has utility for all C/C++ users.  What do you think?


Ed

[C++11, C++14 PATCH 2/3] Support for SD-6: SG10 Feature Test Recommendations - c-family and testsuite

[Ed Smith-Rowland]

This is the c-family part: Setting the language feature macos and 
defining the __has_include macro.



c-family:

2014-05-31  Ed Smith-Rowland  <3dw...@verizon.net>

Implement SD-6: SG10 Feature Test Recommendations
* c-cppbuiltin.c (c_cpp_builtins()): Define language feature
macros and the __has_header macro.


libstdc++:

2014-05-31  Ed Smith-Rowland  <3dw...@verizon.net>

Implement SD-6: SG10 Feature Test Recommendations
* g++.dg/cpp1y/feat-cxx11-neg.C: New.
* g++.dg/cpp1y/feat-cxx11.C: New.
* g++.dg/cpp1y/feat-cxx14-neg.C: New.
* g++.dg/cpp1y/feat-cxx14.C: New.
* g++.dg/cpp1y/phoobhar.h: New.
* g++.dg/cpp1y/testinc/phoobhar.h: New.
* g++.dg/cpp1y/testinc/phoobhar.h: New.
Index: c-family/c-cppbuiltin.c
===
--- c-family/c-cppbuiltin.c (revision 211078)
+++ c-family/c-cppbuiltin.c (working copy)
@@ -805,7 +805,43 @@
   if (flag_rtti)
cpp_define (pfile, "__GXX_RTTI");
   if (cxx_dialect >= cxx11)
-cpp_define (pfile, "__GXX_EXPERIMENTAL_CXX0X__");
+   {
+  cpp_define (pfile, "__GXX_EXPERIMENTAL_CXX0X__");
+ /* Set feature test macros for C++11  */
+ cpp_define (pfile, "__has_include(STR)=__has_include__(STR)");
+ cpp_define (pfile,
+ "__has_include_next(STR)=__has_include_next__(STR)");
+
+ cpp_define (pfile, "__cpp_unicode_characters=200704");
+ cpp_define (pfile, "__cpp_raw_strings=200710");
+ cpp_define (pfile, "__cpp_unicode_literals=200710");
+ cpp_define (pfile, "__cpp_user_defined_literals=200809");
+ cpp_define (pfile, "__cpp_lambdas=200907");
+ cpp_define (pfile, "__cpp_constexpr=200704");
+ cpp_define (pfile, "__cpp_static_assert=200410");
+ cpp_define (pfile, "__cpp_decltype=200707");
+ cpp_define (pfile, "__cpp_attributes=200809");
+ cpp_define (pfile, "__cpp_rvalue_reference=200610");
+ cpp_define (pfile, "__cpp_variadic_templates=200704");
+ cpp_define (pfile, "__cpp_alias_templates=200704");
+   }
+  if (cxx_dialect > cxx11)
+   {
+ /* Set feature test macros for C++14  */
+ cpp_define (pfile, "__cpp_binary_literals=201304");
+ cpp_define (pfile, "__cpp_init_captures=201304");
+ cpp_define (pfile, "__cpp_generic_lambdas=201304");
+ cpp_undef (pfile, "__cpp_constexpr");
+ cpp_define (pfile, "__cpp_constexpr=201304");
+ cpp_define (pfile, "__cpp_decltype_auto=201304");
+ cpp_define (pfile, "__cpp_return_type_deduction=201304");
+ cpp_define (pfile, "__cpp_runtime_arrays=201304");
+ //cpp_define (pfile, "__cpp_aggregate_nsdmi=201304");
+ //cpp_define (pfile, "__cpp_variable_templates=201304");
+ cpp_define (pfile, "__cpp_digit_separators=201309");
+ cpp_define (pfile, "__cpp_attribute_deprecated=201309");
+ //cpp_define (pfile, "__cpp_sized_deallocation=201309");
+   }
 }
   /* Note that we define this for C as well, so that we know if
  __attribute__((cleanup)) will interface with EH.  */
Index: testsuite/g++.dg/cpp1y/feat-cxx11-neg.C
===
--- testsuite/g++.dg/cpp1y/feat-cxx11-neg.C (revision 0)
+++ testsuite/g++.dg/cpp1y/feat-cxx11-neg.C (working copy)
@@ -0,0 +1,35 @@
+// { dg-do compile { target c++11_only } }
+
+// These *are* defined in C++14 onwards.
+
+#ifndef __cpp_binary_literals
+#  error "__cpp_binary_literals" // { dg-error "error" }
+#endif
+
+#ifndef __cpp_init_captures
+#  error "__cpp_init_captures" // { dg-error "error" }
+#endif
+
+#ifndef __cpp_generic_lambdas
+#  error "__cpp_generic_lambdas" // { dg-error "error" }
+#endif
+
+#ifndef __cpp_decltype_auto
+#  error "__cpp_decltype_auto" // { dg-error "error" }
+#endif
+
+#ifndef __cpp_return_type_deduction
+#  error "__cpp_return_type_deduction" // { dg-error "error" }
+#endif
+
+#ifndef __cpp_runtime_arrays
+#  error "__cpp_runtime_arrays" // { dg-error "error" }
+#endif
+
+#ifndef __cpp_digit_separators
+#  error "__cpp_digit_separators" // { dg-error "error" }
+#endif
+
+#ifndef __cpp_attribute_deprecated
+#  error "__cpp_attribute_deprecated" // { dg-error "error" }
+#endif
Index: testsuite/g++.dg/cpp1y/feat-cxx11.C
===
--- testsuite/g++.dg/cpp1y/feat-cxx11.C (revision 0)
+++ testsuite/g++.dg/cpp1y/feat-cxx11.C (working copy)
@@ -0,0 +1,73 @@
+// { dg-do compile { target c++11_only } }
+
+#ifndef __cpp_unicode_characters
+#  error "__cpp_unicode_characters"
+#elif  __cpp_unicode_characters != 200704
+#  error "__cpp_unicode_characters != 200704"
+#endif
+
+#ifndef __cpp_raw_strings
+#  error "__cpp_raw_strings"
+#elif  __cpp_raw_strings != 200710
+#  error "__cpp_raw_strings != 200710"
+#endif
+
+#ifndef __cpp_unicode_literal

[C++11, C++14 PATCH 1/3] Support for SD-6: SG10 Feature Test Recommendations - libcpp

[Ed Smith-Rowland]

Here is the libcpp portion.

2014-05-31  Ed Smith-Rowland  <3dw...@verizon.net>

Implement SD-6: SG10 Feature Test Recommendations
* directives.c: Support __has_include__ builtin.
* expr.c (parse_has_include): New function to parse __has_include__
builtin; (eval_token()): Use it.
* files.c (_cpp_has_header()): New funtion to look for header;
(open_file_failed()): Not an error to not find a header file for
__has_include__.
* identifiers.c (_cpp_init_hashtable()): Add entry for __has_include__.
* internal.h (lexer_state, spec_nodes): Add in__has_include__.
* pch.c (cpp_read_state): Lookup __has_include__.
* traditional.c (enum ls, _cpp_scan_out_logical_line()): Walk through
__has_include__ statements.
Index: directives.c
===
--- directives.c(revision 211078)
+++ directives.c(working copy)
@@ -549,6 +549,11 @@
   if (is_def_or_undef && node == pfile->spec_nodes.n_defined)
cpp_error (pfile, CPP_DL_ERROR,
   "\"defined\" cannot be used as a macro name");
+  else if (is_def_or_undef
+   && (node == pfile->spec_nodes.n__has_include__
+|| node == pfile->spec_nodes.n__has_include_next__))
+   cpp_error (pfile, CPP_DL_ERROR,
+  "\"__has_include__\" cannot be used as a macro name");
   else if (! (node->flags & NODE_POISONED))
return node;
 }
@@ -2601,3 +2606,12 @@
   node->directive_index = i;
 }
 }
+
+/* Extract header file from a bracket include. Parsing starts after '<'.
+   The string is malloced and must be freed by the caller.  */
+char *
+_cpp_bracket_include(cpp_reader *pfile)
+{
+  return glue_header_name (pfile);
+}
+
Index: expr.c
===
--- expr.c  (revision 211078)
+++ expr.c  (working copy)
@@ -64,6 +64,8 @@
 static unsigned int interpret_int_suffix (cpp_reader *, const uchar *, size_t);
 static void check_promotion (cpp_reader *, const struct op *);
 
+static cpp_num parse_has_include (cpp_reader *, enum include_type);
+
 /* Token type abuse to create unary plus and minus operators.  */
 #define CPP_UPLUS ((enum cpp_ttype) (CPP_LAST_CPP_OP + 1))
 #define CPP_UMINUS ((enum cpp_ttype) (CPP_LAST_CPP_OP + 2))
@@ -1041,6 +1043,10 @@
 case CPP_NAME:
   if (token->val.node.node == pfile->spec_nodes.n_defined)
return parse_defined (pfile);
+  else if (token->val.node.node == pfile->spec_nodes.n__has_include__)
+   return parse_has_include (pfile, IT_INCLUDE);
+  else if (token->val.node.node == pfile->spec_nodes.n__has_include_next__)
+   return parse_has_include (pfile, IT_INCLUDE_NEXT);
   else if (CPP_OPTION (pfile, cplusplus)
   && (token->val.node.node == pfile->spec_nodes.n_true
   || token->val.node.node == pfile->spec_nodes.n_false))
@@ -2065,3 +2071,71 @@
 
   return lhs;
 }
+
+/* Handle meeting "__has_include__" in a preprocessor expression.  */
+static cpp_num
+parse_has_include (cpp_reader *pfile, enum include_type type)
+{
+  cpp_num result;
+  bool paren = false;
+  cpp_hashnode *node = 0;
+  const cpp_token *token;
+  bool bracket = false;
+  char *fname = 0;
+
+  result.unsignedp = false;
+  result.high = 0;
+  result.overflow = false;
+  result.low = 0;
+
+  pfile->state.in__has_include__++;
+
+  token = cpp_get_token (pfile);
+  if (token->type == CPP_OPEN_PAREN)
+{
+  paren = true;
+  token = cpp_get_token (pfile);
+}
+  if (token->type == CPP_STRING || token->type == CPP_HEADER_NAME)
+{
+  if (token->type == CPP_HEADER_NAME)
+   bracket = true;
+  fname = XNEWVEC (char, token->val.str.len - 1);
+  memcpy (fname, token->val.str.text + 1, token->val.str.len - 2);
+  fname[token->val.str.len - 2] = '\0';
+  node = token->val.node.node;
+}
+  else if (token->type == CPP_LESS)
+{
+  bracket = true;
+  fname = _cpp_bracket_include (pfile);
+}
+  else
+cpp_error (pfile, CPP_DL_ERROR,
+  "operator \"__has_include__\" requires a header string");
+
+  if (fname)
+{
+  int angle_brackets = (bracket ? 1 : 0);
+
+  if (_cpp_has_header (pfile, fname, angle_brackets, type))
+   result.low = 0;
+  else
+   result.low = 1;
+
+  XDELETEVEC (fname);
+}
+
+  if (paren && cpp_get_token (pfile)->type != CPP_CLOSE_PAREN)
+cpp_error (pfile, CPP_DL_ERROR,
+  "missing ')' after \"__has_include__\"");
+
+  /* A possible controlling macro of the form #if !__has_include__ ().
+ _cpp_parse_expr checks there was no other junk on the line.  */
+  if (node)
+pfile->mi_ind_cmacro = node;
+
+  pfile->state.in__has_include__--;
+
+  return result;
+}
Index: files.c
===
--- files.c (revision 211078)
+++ files.c (working cop

[C++11, C++14 PATCH 3/3] Support for SD-6: SG10 Feature Test Recommendations - libstdc++

[Ed Smith-Rowland]

This is the libstdc++ and libstdc++ testsuite part.

2014-05-31  Ed Smith-Rowland  <3dw...@verizon.net>

Implement SD-6: SG10 Feature Test Recommendations
* include/bits/basic_string.h: Add __cpp_lib feature test macro.
* include/bits/stl_algobase.h: Ditto.
* include/bits/stl_function.h: Ditto.
* include/bits/unique_ptr.h: Ditto.
* include/std/array: Ditto.
* include/std/chrono: Ditto.
* include/std/complex: Ditto.
* include/std/iomanip: Ditto.
* include/std/mutex: Ditto.
* include/std/shared_mutex: Ditto.
* include/std/tuple: Ditto.
* include/std/type_traits: Ditto.
* include/std/utility: Ditto.
* testsuite/experimental/feat-cxx14.cc: New.
* testsuite/experimental/feat-lib-fund.cc: New.
Index: include/bits/basic_string.h
===
--- include/bits/basic_string.h (revision 211078)
+++ include/bits/basic_string.h (working copy)
@@ -3124,6 +3124,8 @@
 
 #if __cplusplus > 201103L
 
+#define __cpp_lib_string_udls 201304
+
   inline namespace literals
   {
   inline namespace string_literals
Index: include/bits/stl_algobase.h
===
--- include/bits/stl_algobase.h (revision 211078)
+++ include/bits/stl_algobase.h (working copy)
@@ -1091,6 +1091,7 @@
 }
 
 #if __cplusplus > 201103L
+#define __cpp_lib_robust_nonmodifying_seq_ops 201304
   /**
*  @brief Tests a range for element-wise equality.
*  @ingroup non_mutating_algorithms
Index: include/bits/stl_function.h
===
--- include/bits/stl_function.h (revision 211078)
+++ include/bits/stl_function.h (working copy)
@@ -217,6 +217,10 @@
 };
 
 #if __cplusplus > 201103L
+
+#define __cpp_lib_transparent_operators 201210
+#define __cpp_lib_generic_associative_lookup 201304
+
   template<>
 struct plus
 {
Index: include/bits/unique_ptr.h
===
--- include/bits/unique_ptr.h   (revision 211078)
+++ include/bits/unique_ptr.h   (working copy)
@@ -743,6 +743,9 @@
 };
 
 #if __cplusplus > 201103L
+
+#define __cpp_lib_make_unique 201304
+
   template
 struct _MakeUniq
 { typedef unique_ptr<_Tp> __single_object; };
Index: include/std/array
===
--- include/std/array   (revision 211078)
+++ include/std/array   (working copy)
@@ -35,6 +35,8 @@
 # include 
 #else
 
+#define __cpp_lib_constexpr_functions 201210
+
 #include 
 #include 
 #include 
Index: include/std/chrono
===
--- include/std/chrono  (revision 211078)
+++ include/std/chrono  (working copy)
@@ -43,6 +43,8 @@
 
 #ifdef _GLIBCXX_USE_C99_STDINT_TR1
 
+#define __cpp_lib_constexpr_functions 201210
+
 namespace std _GLIBCXX_VISIBILITY(default)
 {
   /**
@@ -782,6 +784,8 @@
 
 #if __cplusplus > 201103L
 
+#define __cpp_lib_chrono_udls 201304
+
   inline namespace literals
   {
   inline namespace chrono_literals
Index: include/std/complex
===
--- include/std/complex (revision 211078)
+++ include/std/complex (working copy)
@@ -1929,6 +1929,8 @@
 inline namespace literals {
 inline namespace complex_literals {
 
+#define __cpp_lib_complex_udls 201309
+
   constexpr std::complex
   operator""if(long double __num)
   { return std::complex{0.0F, static_cast(__num)}; }
Index: include/std/iomanip
===
--- include/std/iomanip (revision 211078)
+++ include/std/iomanip (working copy)
@@ -336,6 +336,8 @@
 
 #if __cplusplus > 201103L
 
+#define __cpp_lib_quoted_string_io 201304
+
 _GLIBCXX_END_NAMESPACE_VERSION
   namespace __detail {
   _GLIBCXX_BEGIN_NAMESPACE_VERSION
Index: include/std/mutex
===
--- include/std/mutex   (revision 211078)
+++ include/std/mutex   (working copy)
@@ -35,6 +35,9 @@
 # include 
 #else
 
+// For backwards compatibility of SD-6.
+#define __cpp_lib_shared_mutex 201304
+
 #include 
 #include 
 #include 
Index: include/std/shared_mutex
===
--- include/std/shared_mutex(revision 211078)
+++ include/std/shared_mutex(working copy)
@@ -52,6 +52,9 @@
*/
 
 #if defined(_GLIBCXX_HAS_GTHREADS) && defined(_GLIBCXX_USE_C99_STDINT_TR1)
+
+#define __cpp_lib_shared_mutex 201402
+
   /// shared_timed_mutex
   class shared_timed_mutex
   {
Index: include/std/tuple
===
--- include/std/tuple   (revision 211078)
+++ include/std/tuple   (working copy)
@@ -744,6 +744,9 @@
 }
 
 #if __cplusplus > 201103L
+
+#define __cpp_lib_tuples_by_type 201304
+
   template
 constexpr _Head

Re: [C++11, C++14 PATCH 0/3] Support for SD-6: SG10 Feature Test Recommendations

[Andrew Pinski]

On Fri, May 30, 2014 at 8:41 PM, Ed Smith-Rowland <3dw...@verizon.net> wrote:
> A group within the C++ standards committee was charged with the
> responibility of coming up with a way for users to test a C++ compiler and
> runtime for the availability of new features.  These features are intended
> to aid users in a time of intense C++ evolution.  These features are not
> really part of the C++ standard and probably can't be really.
>
> The latest paper is:
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4030.htm
>
> Also, an earlier version is supplied as a standing document on the isocpp
> website:
> https://isocpp.org/std/standing-documents/sd-6-sg10-feature-test-recommendations
>
> The current patch implements __has_include and many of the language feature
> and library version macros outlined in these documents.
>
> I builds and tests clean on x86_64-linux.
>
> I anticipate that the next C++ meeting will see some additions (new library
> and language macros and a __has_cpp_attribute).  I will add these as a
> separate patch if needed.
>
> I took the liberty of adding __has_include_next.  clang has both
> __has_include and __has_include_next.  Also, while the underlying cpp
> builtin that supports __has_include, __has_include__, is available to C and
> C++ in all language versions, the macro __has_include is only available for
> C++11 onwards.  One could however anticipate that this feature has utility
> for all C/C++ users.  What do you think?

I think having __has_include for all languages is fine since it is
already in the implementation defined namespace.

Thanks,
Andrew


>
> Ed
>

Re: [C++11, C++14 PATCH 2/3] Support for SD-6: SG10 Feature Test Recommendations - c-family and testsuite

[Marc Glisse]

On Fri, 30 May 2014, Ed Smith-Rowland wrote:


+ cpp_undef (pfile, "__cpp_constexpr");
+ cpp_define (pfile, "__cpp_constexpr=201304");


Could you set the other value in an else branch to avoid a def undef redef 
game?


Also, I am pretty sure that gcc doesn't support the latest constexpr, we 
shouldn't define those macros lightly.


--
Marc Glisse

Re: [C++11, C++14 PATCH 3/3] Support for SD-6: SG10 Feature Test Recommendations - libstdc++

[Marc Glisse]

On Fri, 30 May 2014, Ed Smith-Rowland wrote:


+#define __cpp_lib_constexpr_functions 201210


appears quite a few times, I believe it will warn with -Wsystem-headers. I 
think you should check if it is already defined (or undefine it first).


(you forgot to Cc: libstdc++)

--
Marc Glisse