Re: [PATCH, libgfortran, committed] PR 64770 Segfault when trying to open existing file with status="new"

[Andreas Schwab]

Janne Blomqvist  writes:

> PR libfortran/64770
> * gfortran.dg/open_new_segv.f90: New test.

At line 9 of file 
/usr/local/gcc/gcc-20150125/gcc/testsuite/gfortran.dg/open_new_segv.f90 (unit = 
99)
Fortran runtime error: File 'pr64770test.dat' already exists
FAIL: gfortran.dg/open_new_segv.f90   -O0  execution test

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: [PATCH, libgfortran, committed] PR 64770 Segfault when trying to open existing file with status="new"

[Dominique Dhumieres]

> ... FAIL: gfortran.dg/open_new_segv.f90   -O0  execution test

This is fixed with something such as

--- ../_clean/gcc/testsuite/gfortran.dg/open_new_segv.f90   2015-01-25 
00:37:43.0 +0100
+++ gcc/testsuite/gfortran.dg/open_new_segv.f90 2015-01-25 10:31:40.0 
+0100
@@ -1,4 +1,5 @@
 ! { dg-do run }
+! { dg-shouldfail "File already exists" }
 ! PR 64770 SIGSEGV when trying to open an existing file with status="new"
 program pr64770
   implicit none
@@ -8,3 +9,5 @@ program pr64770
   open(99, file="pr64770test.dat", access="stream", form="unformatted", &
status="new")
 end program pr64770
+! { dg-output "At line 10 of file.*" }
+! { dg-output "Fortran runtime error: File .pr64770test.dat. already exists" }

Note that it may be worth to run a second test to cleanup the file 
'pr64770test.dat'.

Dominique

Re: Add to maintainers list.

[Tom de Vries]

On 24-01-15 20:41, Gerald Pfeifer wrote:

Hi Alex,

On Friday 2014-11-21 10:07, Alex Velenko wrote:

Can someone, please, approve?


we tried to document this in https://gcc.gnu.org/svnwrite.html .

Can you perhaps suggest a way for us to improve this to make
it more clear or easier to find?



How about this?

Thanks,
- Tom

diff --git a/MAINTAINERS b/MAINTAINERS
index 05cf4cd..c39dbae 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -597,6 +597,10 @@ Jon Ziegler 


 Roman Zippel   
 Josef Zlomek   

+Note that after receiving write approval, no patch approval is needed to add
+yourself to the Write-After-Approval list.  See also
+https://gcc.gnu.org/svnwrite.html#authenticated.
+
 Bug database only accounts

 James Dennett  

Re: [PATCH, libgfortran, committed] PR 64770 Segfault when trying to open existing file with status="new"

[Jakub Jelinek]

On Sun, Jan 25, 2015 at 10:35:50AM +0100, Dominique Dhumieres wrote:
> > ... FAIL: gfortran.dg/open_new_segv.f90   -O0  execution test
> 
> This is fixed with something such as
> 
> --- ../_clean/gcc/testsuite/gfortran.dg/open_new_segv.f90 2015-01-25 
> 00:37:43.0 +0100
> +++ gcc/testsuite/gfortran.dg/open_new_segv.f90   2015-01-25 
> 10:31:40.0 +0100
> @@ -1,4 +1,5 @@
>  ! { dg-do run }
> +! { dg-shouldfail "File already exists" }
>  ! PR 64770 SIGSEGV when trying to open an existing file with status="new"
>  program pr64770
>implicit none
> @@ -8,3 +9,5 @@ program pr64770
>open(99, file="pr64770test.dat", access="stream", form="unformatted", &
> status="new")
>  end program pr64770
> +! { dg-output "At line 10 of file.*" }
> +! { dg-output "Fortran runtime error: File .pr64770test.dat. already exists" 
> }
> 
> Note that it may be worth to run a second test to cleanup the file 
> 'pr64770test.dat'.

That is not possible in a second test, the second test might be scheduled in
a different job, in a different directory.
So you need to solve this either in the test (call some function that
removes it), or in dg-final.

Jakub

RE: [PATCH, RFC] LRA subreg handling

[Matthew Fortune]

Richard Sandiford  writes:
> Jeff Law  writes:
> > On 01/15/15 03:13, Robert Suchanek wrote:
> >>> Robert, can you look at reload.c::reload_inner_reg_of_subreg and
> >>> verify that the comment just before its return statement is
> >>> effectively the situation you're in.
> >>>
> >>> There are certainly cases where a SUBREG needs to be treated as an
> >>> in-out operand.  We walked through them eons ago when we were poking
> >>> at SSA for RTL.  But the details have long since faded from memory.
> >>
> >> The comment pretty much applies to my situation.  The only difference
> >> I can see is that reload would have had hard registers at this point.
> >> In the testcase, LRA does not have hard registers assigned to the
> >> concerned pseudo(s), thus, it can't rely on the information in
> >> hard_regno_nregs to check if the number of registers in INNER is
> >> different to the number of words in INNER.
> 
> But the code you quote is:
> 
> if (GET_CODE (*loc) == SUBREG)
>   {
> reg = SUBREG_REG (*loc);
> byte = SUBREG_BYTE (*loc);
> if (REG_P (reg)
> /* Strict_low_part requires reload the register not
>the sub-register.  */
> && (curr_static_id->operand[i].strict_low
> || (GET_MODE_SIZE (mode)
> <= GET_MODE_SIZE (GET_MODE (reg))
> && (hard_regno
> = get_try_hard_regno (REGNO (reg))) >= 0
> && (simplify_subreg_regno
> (hard_regno,
>  GET_MODE (reg), byte, mode) < 0)
> && (goal_alt[i] == NO_REGS
> || (simplify_subreg_regno
> (ira_class_hard_regs[goal_alt[i]][0],
>  GET_MODE (reg), byte, mode) >= 0
> 
> Here we do have a hard register, but it isn't valid to form the subreg
> on that hard register.  Reload had to cope with that case too.
> 
> Since the subreg on the original hard register is invalid, we can't use
> it to decide whether the intention was to write to only a part of the
> inner register.  But I don't think we need to use the hard register
> here.  The original register was a psuedo and I'm pretty sure...
> 
> > The differences (hard vs pseudo regs) are primarily an implementation
> > detail.  I was really looking to see if there was existing code which
> > would turn an output reload into an in-out reload for these subregs.
> >
> > The in-out nature of certain subregs is something I've personally
> > stumbled over in various contexts (for example, this also came up
> > during RTL-SSA investigations years ago).
> 
> ...the rule for pseudos is that words of a multiword pseudo can be
> accessed independently but subword pieces of an individual word can't.
> This obviously isn't ideal if a mode is intended for wider-than-word
> registers, since not all words will be independently addressable when
> allocated to those registers.  The code above is partly dealing with the
> fallout from that.  It's also why we have strict_lowpart for cases like
> al on i386.
> 
> So IMO the patch is too broad.  I think it should only use INOUT reloads
> for !strict_low if the inner mode is wider than a word and the outer
> mode is strictly narrower than the inner mode.  That's on top of Vlad's
> comment about only converting OP_OUTs, of course.

This sounds correct/sensible. The change as committed will be turning
some OP_OUT reloads into OP_INOUT unnecessarily. Checking for !strict_low
is however probably redundant as strict_low must be OP_INOUT and never
OP_OUT but we could mask backend bugs by converting strict_low subregs.

I think this should be resolved for GCC 5 if others agree it is an issue.

Matthew

[4.8] backport PR57748 fixes (wrong-code and ICE regression)

[Mikael Pettersson]

This backports the fixes for PR middle-end/57748, a wrong-code and ICE
regression, to the 4.8 branch.

Tested extensively on x86_64, powerpc64, sparc64, ARMv{5,7}, and m68k.

Ok for 4.8?

(I don't have commit rights.)

/Mikael

gcc/

2015-01-25  Mikael Pettersson  

Backport from mainline

2013-09-20  Bernd Edlinger  

PR middle-end/57748
* expr.c (expand_assignment): Remove misalignp code path.

2014-01-08  Bernd Edlinger  

PR middle-end/57748
* expr.h (expand_expr_real, expand_expr_real_1): Add new parameter
inner_reference_p.
(expand_expr, expand_normal): Adjust.
* expr.c (expand_expr_real, expand_expr_real_1): Add new parameter
inner_reference_p. Use inner_reference_p to expand inner references.
(store_expr): Adjust.
* cfgexpand.c (expand_call_stmt): Adjust.

gcc/testsuite/

2015-01-25  Mikael Pettersson  

Backport from mainline

2013-09-20  Bernd Edlinger  

PR middle-end/57748
* gcc.dg/torture/pr57748-1.c: New test.
* gcc.dg/torture/pr57748-2.c: New test.

2014-01-08  Bernd Edlinger  

PR middle-end/57748
* gcc.dg/torture/pr57748-3.c: New test.
* gcc.dg/torture/pr57748-4.c: New test.

diff -rupN gcc-4.8-20150122/gcc/cfgexpand.c 
gcc-4.8-20150122.pr57748/gcc/cfgexpand.c
--- gcc-4.8-20150122/gcc/cfgexpand.c2014-01-07 17:49:22.0 +0100
+++ gcc-4.8-20150122.pr57748/gcc/cfgexpand.c2015-01-25 15:00:35.240949368 
+0100
@@ -2111,7 +2111,7 @@ expand_call_stmt (gimple stmt)
   if (lhs)
 expand_assignment (lhs, exp, false);
   else
-expand_expr_real_1 (exp, const0_rtx, VOIDmode, EXPAND_NORMAL, NULL);
+expand_expr (exp, const0_rtx, VOIDmode, EXPAND_NORMAL);
 
   mark_transaction_restart_calls (stmt);
 }
diff -rupN gcc-4.8-20150122/gcc/expr.c gcc-4.8-20150122.pr57748/gcc/expr.c
--- gcc-4.8-20150122/gcc/expr.c 2014-11-28 18:06:23.0 +0100
+++ gcc-4.8-20150122.pr57748/gcc/expr.c 2015-01-25 15:00:35.240949368 +0100
@@ -4708,8 +4708,6 @@ expand_assignment (tree to, tree from, b
   int unsignedp;
   int volatilep = 0;
   tree tem;
-  bool misalignp;
-  rtx mem = NULL_RTX;
 
   push_temp_slots ();
   tem = get_inner_reference (to, &bitsize, &bitpos, &offset, &mode1,
@@ -4728,40 +4726,7 @@ expand_assignment (tree to, tree from, b
  && DECL_BIT_FIELD_TYPE (TREE_OPERAND (to, 1)))
get_bit_range (&bitregion_start, &bitregion_end, to, &bitpos, &offset);
 
-  /* If we are going to use store_bit_field and extract_bit_field,
-make sure to_rtx will be safe for multiple use.  */
-  mode = TYPE_MODE (TREE_TYPE (tem));
-  if (TREE_CODE (tem) == MEM_REF
- && mode != BLKmode
- && ((align = get_object_alignment (tem))
- < GET_MODE_ALIGNMENT (mode))
- && ((icode = optab_handler (movmisalign_optab, mode))
- != CODE_FOR_nothing))
-   {
- struct expand_operand ops[2];
-
- misalignp = true;
- to_rtx = gen_reg_rtx (mode);
- mem = expand_expr (tem, NULL_RTX, VOIDmode, EXPAND_WRITE);
-
- /* If the misaligned store doesn't overwrite all bits, perform
-rmw cycle on MEM.  */
- if (bitsize != GET_MODE_BITSIZE (mode))
-   {
- create_input_operand (&ops[0], to_rtx, mode);
- create_fixed_operand (&ops[1], mem);
- /* The movmisalign pattern cannot fail, else the assignment
-would silently be omitted.  */
- expand_insn (icode, 2, ops);
-
- mem = copy_rtx (mem);
-   }
-   }
-  else
-   {
- misalignp = false;
- to_rtx = expand_expr (tem, NULL_RTX, VOIDmode, EXPAND_WRITE);
-   }
+  to_rtx = expand_expr (tem, NULL_RTX, VOIDmode, EXPAND_WRITE);
 
   /* If the bitfield is volatile, we want to access it in the
 field's mode, not the computed mode.
@@ -4900,17 +4865,6 @@ expand_assignment (tree to, tree from, b
  get_alias_set (to), nontemporal);
}
 
-  if (misalignp)
-   {
- struct expand_operand ops[2];
-
- create_fixed_operand (&ops[0], mem);
- create_input_operand (&ops[1], to_rtx, mode);
- /* The movmisalign pattern cannot fail, else the assignment
-would silently be omitted.  */
- expand_insn (icode, 2, ops);
-   }
-
   if (result)
preserve_temp_slots (result);
   pop_temp_slots ();
@@ -5262,7 +5216,7 @@ store_expr (tree exp, rtx target, int ca
   temp = expand_expr_real (exp, tmp_target, GET_MODE (target),
   (call_param_p
? EXPAND_STACK_PARM : EXPAND_NORMAL),
-  &alt_rtl);
+  &alt_rtl, false);
 }
 
   /* If TEMP is a VOIDmode constant and the mode of the type of EXP is not
@@ -7881,11 +7835,21 

[Patch, fortran] PR62044 ICE when loading use-renamed extended derived type

[Mikael Morin]

Hello,

I have had a look at PR62044 where the compiler ICEs when loading the
extensions of a derived type from a module file, because one use-renamed
extended type is not found under its original name.

After scratching my head on the tree of extended types (rooted at
derived->f2k_derived->sym_root), wondering whether the renamed or
original name should be used, I decided to remove all that nonsense.

So here is the patch, regression tested on x86_64-unknown-linux-gnu.
There is a failure, graphite/pr42393.f90, also present on mainline.
OK for trunk/4.9/4.8 ?

Mikael


2015-01-25  Mikael Morin  

PR fortran/62044
* decl.c (gfc_match_derived_decl): Don't insert a new symtree element.
* module.c (MOD_VERSION): Bump.
(write_module): Don't write list of extensions.
(read_module): Don't jump over list of extensions;
don't load list of extensions.
(load_derived_extensions, write_dt_extensions,
 write_derived_extensions): Remove.

2015-01-25  Mikael Morin  

PR fortran/62044
* gfortran.dg/use_rename_7.f90: New.



Index: decl.c
===
--- decl.c	(révision 220084)
+++ decl.c	(copie de travail)
@@ -7790,7 +7790,6 @@ gfc_match_derived_decl (void)
   if (extended && !sym->components)
 {
   gfc_component *p;
-  gfc_symtree *st;
 
   /* Add the extended derived type as the first component.  */
   gfc_add_component (sym, parent, &p);
@@ -7815,8 +7814,6 @@ gfc_match_derived_decl (void)
   /* Provide the links between the extended type and its extension.  */
   if (!extended->f2k_derived)
 	extended->f2k_derived = gfc_get_namespace (NULL, 0);
-  st = gfc_new_symtree (&extended->f2k_derived->sym_root, sym->name);
-  st->n.sym = sym;
 }
 
   if (!sym->hash_value)
Index: module.c
===
--- module.c	(révision 220084)
+++ module.c	(copie de travail)
@@ -92,7 +92,7 @@ along with GCC; see the file COPYING3.  If not see
 
 /* Don't put any single quote (') in MOD_VERSION, if you want it to be
recognized.  */
-#define MOD_VERSION "13"
+#define MOD_VERSION "14"
 
 
 /* Structure that describes a position within a module file.  */
@@ -4542,71 +4542,6 @@ load_equiv (void)
 }
 
 
-/* This function loads the sym_root of f2k_derived with the extensions to
-   the derived type.  */
-static void
-load_derived_extensions (void)
-{
-  int symbol, j;
-  gfc_symbol *derived;
-  gfc_symbol *dt;
-  gfc_symtree *st;
-  pointer_info *info;
-  char name[GFC_MAX_SYMBOL_LEN + 1];
-  char module[GFC_MAX_SYMBOL_LEN + 1];
-  const char *p;
-
-  mio_lparen ();
-  while (peek_atom () != ATOM_RPAREN)
-{
-  mio_lparen ();
-  mio_integer (&symbol);
-  info = get_integer (symbol);
-  derived = info->u.rsym.sym;
-
-  /* This one is not being loaded.  */
-  if (!info || !derived)
-	{
-	  while (peek_atom () != ATOM_RPAREN)
-	skip_list ();
-	  continue;
-	}
-
-  gcc_assert (derived->attr.flavor == FL_DERIVED);
-  if (derived->f2k_derived == NULL)
-	derived->f2k_derived = gfc_get_namespace (NULL, 0);
-
-  while (peek_atom () != ATOM_RPAREN)
-	{
-	  mio_lparen ();
-	  mio_internal_string (name);
-	  mio_internal_string (module);
-
-  /* Only use one use name to find the symbol.  */
-	  j = 1;
-	  p = find_use_name_n (name, &j, false);
-	  if (p)
-	{
-	  st = gfc_find_symtree (gfc_current_ns->sym_root, p);
-	  dt = st->n.sym;
-	  st = gfc_find_symtree (derived->f2k_derived->sym_root, name);
-	  if (st == NULL)
-		{
-		  /* Only use the real name in f2k_derived to ensure a single
-		symtree.  */
-		  st = gfc_new_symtree (&derived->f2k_derived->sym_root, name);
-		  st->n.sym = dt;
-		  st->n.sym->refs++;
-		}
-	}
-	  mio_rparen ();
-	}
-  mio_rparen ();
-}
-  mio_rparen ();
-}
-
-
 /* This function loads OpenMP user defined reductions.  */
 static void
 load_omp_udrs (void)
@@ -4907,7 +4842,7 @@ check_for_ambiguous (gfc_symbol *st_sym, pointer_i
 static void
 read_module (void)
 {
-  module_locus operator_interfaces, user_operators, extensions, omp_udrs;
+  module_locus operator_interfaces, user_operators, omp_udrs;
   const char *p;
   char name[GFC_MAX_SYMBOL_LEN + 1];
   int i;
@@ -4926,13 +4861,10 @@ read_module (void)
   skip_list ();
   skip_list ();
 
-  /* Skip commons, equivalences and derived type extensions for now.  */
+  /* Skip commons and equivalences for now.  */
   skip_list ();
   skip_list ();
 
-  get_module_locus (&extensions);
-  skip_list ();
-
   /* Skip OpenMP UDRs.  */
   get_module_locus (&omp_udrs);
   skip_list ();
@@ -5238,11 +5170,6 @@ read_module (void)
 		 module_name);
 }
 
-  /* Now we should be in a position to fill f2k_derived with derived type
- extensions, since everything has been loaded.  */
-  set_module_locus (&extensions);
-  load_derived_extensions ();
-
   /* Clean up symbol nodes

Re: [Patch, fortran] PR62044 ICE when loading use-renamed extended derived type

[Tobias Burnus]

Mikael Morin wrote:

I have had a look at PR62044 where the compiler ICEs when loading the
extensions of a derived type from a module file, because one use-renamed
extended type is not found under its original name.

After scratching my head on the tree of extended types (rooted at
derived->f2k_derived->sym_root), wondering whether the renamed or
original name should be used, I decided to remove all that nonsense.

So here is the patch, regression tested on x86_64-unknown-linux-gnu.
There is a failure, graphite/pr42393.f90, also present on mainline.
OK for trunk/4.9/4.8 ?


Regarding the failure: The reason of the failure is the GCC 5 change for 
Graphite from CLooG (using ISL) to ISL (used directly) and a bug in ISL 
0.12.2. The solution is to update to ISL 0.14.0 - or to ignore the 
failure. See also PR64017.


Regarding the patch: It looks fine to me – and as I assume/hope that the 
test suite is comprehensive, it shouldn't break something obvious.


Hence, OK from my side. Thanks for the patch!

Tobias

[SH][committed] Add some more addc/subc tests

[Oleg Endo]

Hi,

This adds some more addc/subc tests which are now working after the
treg_set_expr patch.
Tested with make -k check-gcc RUNTESTFLAGS="sh.exp=pr54236*
--target_board=sh-sim
\{-m2/-ml,-m2/-mb,-m2a/-mb,-m4/-ml,-m4/-mb,-m4a/-ml,-m4a/-mb}"
Committed as r220093.

Cheers,
Oleg

gcc/testsuite/ChangeLog:
PR target/54236
* gcc.target/sh/pr54236-4.c: New.
Index: gcc/testsuite/gcc.target/sh/pr54236-4.c
===
--- gcc/testsuite/gcc.target/sh/pr54236-4.c	(revision 0)
+++ gcc/testsuite/gcc.target/sh/pr54236-4.c	(revision 0)
@@ -0,0 +1,70 @@
+/* Check that addc and subc patterns are converted if the T value is
+   inverted.  */
+/* { dg-do compile }  */
+/* { dg-options "-O2" }  */
+/* { dg-skip-if "" { "sh*-*-*" } { "-m5*"} { "" } }  */
+/* { dg-final { scan-assembler-times "cmp/eq" 7 } }  */
+
+/* { dg-final { scan-assembler-times "subc" 5 { target { ! sh2a } } } }  */
+/* { dg-final { scan-assembler-times "not\t" 3 { target { ! sh2a } } } }  */
+/* { dg-final { scan-assembler-times "addc" 2 { target { ! sh2a } } } }  */
+
+/* { dg-final { scan-assembler-times "subc" 2 { target { sh2a } } } }  */
+/* { dg-final { scan-assembler-times "addc" 5 { target { sh2a } } } }  */
+/* { dg-final { scan-assembler-times "nott" 3 { target { sh2a } } } }  */
+
+/* { dg-final { scan-assembler-not "movt" } }  */
+/* { dg-final { scan-assembler-not "negc" } }  */
+/* { dg-final { scan-assembler-not "movrt" } }  */
+
+int
+test_0 (int a, int b, int c)
+{
+  /* 1x cmp/eq, 1x subc  */
+  return c + (a != b);
+}
+
+int
+test_1 (int a, int b, int c, int d)
+{
+  /* 1x cmp/eq, 1x not, 1x subc
+ SH2A: 1x cmp/eq, 1x nott, 1x addc  */
+  return (a != b) + c + d;
+}
+
+int
+test_2 (int a, int b, int c, int d)
+{
+  /* 1x cmp/eq, 1x not, 1x subc
+ SH2A: 1x cmp/eq, 1x nott, 1x addc  */
+  return c + (a != b) + d;
+}
+
+int
+test_3 (int a, int b, int c, int d)
+{
+  /* 1x cmp/eq, 1x not, 1x subc
+ SH2A: 1x cmp/eq, 1x nott, 1x addc  */
+  return c + d + (a != b);
+}
+
+int
+test_4 (int a, int b, int c, int d)
+{
+  /* 1x cmp/eq, 1x subc  */
+  return (a != b) - c;
+}
+
+int
+test_5 (int a, int b, int c, int d)
+{
+  /* 1x cmp/eq, 1x add #-1, 1x addc  */
+  return c - (a != b);
+}
+
+int
+test_6 (int a, int b, int c, int d)
+{
+  /* 1x cmp/eq, 1x add #-1, 1x addc  */
+  return c - (a != b) + d;
+}

Re: [Patch, i386] Support BMI and BMI2 targets in multiversioning

[Uros Bizjak]

On Sat, Jan 24, 2015 at 11:49 AM, Allan Sandfeld Jensen
 wrote:
> On Saturday 24 January 2015, Uros Bizjak wrote:
>> On Mon, Jan 12, 2015 at 6:02 PM, Uros Bizjak  wrote:
>> > Hello!
>> >
>> >>> On Wed, Dec 31, 2014 at 01:28:47PM +0100, Allan Sandfeld Jensen wrote:
>> >>> > I recently wanted to use multiversioning for BMI2 specific extensions
>> >>> > PDEP/PEXT, and noticed it wasn't there. So I wrote this patch to add
>> >>> > it, and also added AES, F16C and BMI1 for completeness.
>> >>>
>> >>> AES nor F16C doesn't make any sense IMHO for multiversioning, you need
>> >>> special intrinsics for that anyway and when you use them, the function
>> >>> will fail to compile without those features.
>> >>> Multiversioning only makes sense for ISA features the compiler uses for
>> >>> normal C/C++ code without any intrinsics.
>> >>
>> >> Patch reduced to just adding BMI and BMI2 multiversioning:
>> > +2014-12-29  Allan Sandfeld Jensen  
>> > +
>> > + * config/i386/i386.c (get_builtin_code_for_version): Add
>> > + support for BMI and BMI2 multiversion functions.
>> >
>> > +2014-12-29  Allan Sandfeld Jensen  
>> > +
>> > + * gcc.target/i386/funcspec-5.c: Test new multiversion targets.
>> > + * g++.dg/ext/mv17.C: Test BMI/BMI2 multiversion dispatcher.
>> >
>> > +2014-12-29  Allan Sandfeld Jensen  
>> > +
>> > + * config/i386/cpuinfo.c (enum processor_features): Add FEATURE_BMI and
>> > + FEATURE_BMI2.
>> > + (get_available_features): Detect FEATURE_BMI and FEATURE_BMI2.
>> >
>> > OK for mainline
>>
>> Allan, did you commit the patch to mainline? I don't see it in SVN logs.
>>
>> (If you don't have SVN commit access, please mention it in the patch
>> submission, so someone will commit the patch for you).
>>
> Sorry. I don't have SVN commit access.

Committed with a bunch of fixes (e.g. missing fold_builtin_cpu part in
gcc/config/i386/i386.c, and mv17.C test didn't compile at all due to
missing parenthesis).

Uros.

Re: [Patch, i386] Support BMI and BMI2 targets in multiversioning

[Uros Bizjak]

On Sun, Jan 25, 2015 at 7:23 PM, Uros Bizjak  wrote:
> On Sat, Jan 24, 2015 at 11:49 AM, Allan Sandfeld Jensen
>  wrote:
>> On Saturday 24 January 2015, Uros Bizjak wrote:
>>> On Mon, Jan 12, 2015 at 6:02 PM, Uros Bizjak  wrote:
>>> > Hello!
>>> >
>>> >>> On Wed, Dec 31, 2014 at 01:28:47PM +0100, Allan Sandfeld Jensen wrote:
>>> >>> > I recently wanted to use multiversioning for BMI2 specific extensions
>>> >>> > PDEP/PEXT, and noticed it wasn't there. So I wrote this patch to add
>>> >>> > it, and also added AES, F16C and BMI1 for completeness.
>>> >>>
>>> >>> AES nor F16C doesn't make any sense IMHO for multiversioning, you need
>>> >>> special intrinsics for that anyway and when you use them, the function
>>> >>> will fail to compile without those features.
>>> >>> Multiversioning only makes sense for ISA features the compiler uses for
>>> >>> normal C/C++ code without any intrinsics.
>>> >>
>>> >> Patch reduced to just adding BMI and BMI2 multiversioning:
>>> > +2014-12-29  Allan Sandfeld Jensen  
>>> > +
>>> > + * config/i386/i386.c (get_builtin_code_for_version): Add
>>> > + support for BMI and BMI2 multiversion functions.
>>> >
>>> > +2014-12-29  Allan Sandfeld Jensen  
>>> > +
>>> > + * gcc.target/i386/funcspec-5.c: Test new multiversion targets.
>>> > + * g++.dg/ext/mv17.C: Test BMI/BMI2 multiversion dispatcher.
>>> >
>>> > +2014-12-29  Allan Sandfeld Jensen  
>>> > +
>>> > + * config/i386/cpuinfo.c (enum processor_features): Add FEATURE_BMI and
>>> > + FEATURE_BMI2.
>>> > + (get_available_features): Detect FEATURE_BMI and FEATURE_BMI2.
>>> >
>>> > OK for mainline
>>>
>>> Allan, did you commit the patch to mainline? I don't see it in SVN logs.
>>>
>>> (If you don't have SVN commit access, please mention it in the patch
>>> submission, so someone will commit the patch for you).
>>>
>> Sorry. I don't have SVN commit access.
>
> Committed with a bunch of fixes (e.g. missing fold_builtin_cpu part in
> gcc/config/i386/i386.c, and mv17.C test didn't compile at all due to
> missing parenthesis).

... and now with committed ChangeLog and patch.

gcc/ChangeLog:

* config/i386/i386.c (get_builtin_code_for_version): Add
support for BMI and BMI2 multiversion functions.
(fold_builtin_cpu): Add F_BMI and F_BMI2.

libgcc/ChangeLog:

* config/i386/cpuinfo.c (enum processor_features): Add FEATURE_BMI and
FEATURE_BMI2.
(get_available_features): Detect FEATURE_BMI and FEATURE_BMI2.

testsuite/ChangeLog:

* gcc.target/i386/funcspec-5.c: Test new multiversion targets.
* g++.dg/ext/mv17.C: Test BMI/BMI2 multiversion dispatcher.

Uros.
Index: gcc/config/i386/i386.c
===
--- gcc/config/i386/i386.c  (revision 220091)
+++ gcc/config/i386/i386.c  (working copy)
@@ -34289,15 +34289,18 @@ get_builtin_code_for_version (tree decl, tree *pre
 P_PROC_SSE4_A,
 P_SSE4_1,
 P_SSE4_2,
+P_POPCNT,
 P_PROC_SSE4_2,
-P_POPCNT,
 P_AVX,
 P_PROC_AVX,
+P_BMI,
+P_PROC_BMI,
 P_FMA4,
 P_XOP,
 P_PROC_XOP,
 P_FMA,
 P_PROC_FMA,
+P_BMI2,
 P_AVX2,
 P_PROC_AVX2,
 P_AVX512F,
@@ -34323,12 +34326,14 @@ get_builtin_code_for_version (tree decl, tree *pre
   {"sse4.2", P_SSE4_2},
   {"popcnt", P_POPCNT},
   {"avx", P_AVX},
+  {"bmi", P_BMI},
   {"fma4", P_FMA4},
   {"xop", P_XOP},
   {"fma", P_FMA},
+  {"bmi2", P_BMI2},
   {"avx2", P_AVX2},
   {"avx512f", P_AVX512F}
 };
@@ -34423,7 +34428,7 @@ get_builtin_code_for_version (tree decl, tree *pre
  break;
case PROCESSOR_BTVER2:
  arg_str = "btver2";
- priority = P_PROC_AVX;
+ priority = P_PROC_BMI;
  break;
case PROCESSOR_BDVER1:
  arg_str = "bdver1";
@@ -35310,6 +35315,8 @@ fold_builtin_cpu (tree fndecl, tree *args)
 F_XOP,
 F_FMA,
 F_AVX512F,
+F_BMI,
+F_BMI2,
 F_MAX
   };
 
@@ -35403,7 +35410,9 @@ fold_builtin_cpu (tree fndecl, tree *args)
   {"xop",F_XOP},
   {"fma",F_FMA},
   {"avx2",   F_AVX2},
-  {"avx512f",F_AVX512F}
+  {"avx512f",F_AVX512F},
+  {"bmi",F_BMI},
+  {"bmi2",   F_BMI2}
 };
 
   tree __processor_model_type = build_processor_model_struct ();
Index: gcc/testsuite/gcc.target/i386/funcspec-5.c
===
--- gcc/testsuite/gcc.target/i386/funcspec-5.c  (revision 220091)
+++ gcc/testsuite/gcc.target/i386/funcspec-5.c  (working copy)
@@ -25,6 +25,8 @@ extern void test_tbm (void)   
__attribute__((__tar
 extern void test_avx (void)
__attribute__((__target__("avx")));
 extern void test_avx2 (void)   
__attribute__((__target__("avx2")));
 extern void test_avx512f (void)
__attribute__((__target__("avx512f")));
+extern void test_bmi (void)
__attribute__((__target__("bmi"

Re: minor: 2014 instead of 2015 in the timeline

[Gerald Pfeifer]

On Sunday 2015-01-25 20:04, Leonid Yuriev wrote:
> https://gcc.gnu.org/develop.html#timeline
> 
> s/GCC 5 Stage 4 (starts 2014-01-17)/GCC 5 Stage 4 (starts 2015-01-17)/

Thanks for reporting this, Leonid.

I just applied the obvious patch below.

Gerald

Index: develop.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/develop.html,v
retrieving revision 1.150
diff -u -r1.150 develop.html
--- develop.html19 Jan 2015 09:28:20 -  1.150
+++ develop.html25 Jan 2015 19:38:52 -
@@ -549,7 +549,7 @@
|
   GCC 5 Stage 3 (starts 2014-11-16)
|
-  GCC 5 Stage 4 (starts 2014-01-17)
+  GCC 5 Stage 4 (starts 2015-01-17)
|
|
v

Re: [build] libatomic, libgfortran: Use automake-1.11.1 to sync with the rest

[Jan-Benedict Glaw]

Hi Michael,

On Sun, 2015-01-04 20:20:40 +0100, Michael Haubenwallner 
 wrote:
> (CC'ing build machinery maintainers, maybe I should have done this initially)

Good point, that's my oversight and I'm quite undecided what to do.

> Am 2014-12-31 um 11:45 schrieb Janne Blomqvist:
> > On Fri, Dec 19, 2014 at 2:56 PM, Michael Haubenwallner 
> >  wrote:
> > > On the way to prepare some (aix) libtool patch for toplevel
> > > libtool.m4 I've discovered that different versions of automake
> > > were used to generate files across various libs:
> > >
> > > most libs:   automake-1.11.1
> > > libatomic   r211747: automake-1.11.6
> > > libgfortran r204654: automake-1.11.3
> > > r215741: automake-1.11.6
> > >
> > > Doesn't feel like there were specific reasons to use newer
> > > versions, but OTOH I've failed to find some docs on which
> > > versions to use, so I'd be fine with updating others to 1.11.6
> > > instead as well.
> > 
> > I'm far from an autotools expert, but one justification for
> > updating to 1.11.6 would be CVE-2012-3386, see
> > https://lists.gnu.org/archive/html/automake/2012-07/msg00023.html .
> > 
> > Whatever version we end up choosing, the docs should say it so
> > that there won't be such misconceptions in the future, IMHO.
> IMHO, changing an autotool's version in general should be up to
> (review by) the build machinery maintainers.
> 
> And it should be done across the whole tree, not just for various
> subdirectories.
> 
> However, each update listed here feels like happened by accident,
> using the version installed on the more or less up-to-date host OS.
>
> Am 2014-12-28 um 05:20 schrieb Bernd Edlinger:
> > On Fri, 19 Dec 2014 13:56:50, Michael Haubenwallner wrote:
>
> > > 
> > 
> > Michael proposes to change everything to automake-1.11.1.
> > But the helper files "missing" and friends were updated to automake-1.14.1
> > by:
> > 
> > 2014-11-16  Jan-Benedict Glaw  
> > 
> > * compile: Sync with upstream Automake.
> > * depcomp: Ditto.
> > * install-sh: Ditto.
> > * missing: Ditto.
> > * mkinstalldirs: Ditto.
> > * ylwrap: Ditto.
> > 
> > 
> > Actually I thought that was in preparation to move everything to
> > automake 1.14.1
> > 
> > If I see that right, calling automake without parameters does not
> > touch these helper files, but "automake --add-missing --copy
> > --force-missing" would replace them with the copy from the
> > automake installation additionally to just rewriting the
> > Makefile.in.

I actually updated `missing' by hand from upstream (thus sync'ing in
the current upstream version), later on regenerated the files.

  So this is my fault to not keep proper tool's vs. helper files's
versions together.

> > I think we should have all automake files from the same version,
> > either 1.11.1 or 1.14.1.
> > 
> > What do you think?

I think I totally agree.

> Updating to 1.14 might require more work like updating some .in
> files as well. I've seen automake-1.11 being explicitly used, so for
> now we really want 1.11.6 eventually?

Probably yes, we may want to stick to a well-known version. (Maybe
another way could be to really upgrade to current versions, with is, I
guess, more work than just sync files and rerun. That might be
fruitful (ie. to not stick to older versions), but this is a change I
don't see in the current stage.)

  To cut a long story short:

  * Do we actually see *problems* from the version inconsistencies
already introduced by me and/or others?
  * ...and: Do we want to stick to known versions, or update if?
(Probably not in such a late stage, though...)

MfG, JBG

-- 
  Jan-Benedict Glaw  jbg...@lug-owl.de  +49-172-7608481
Signature of: 17:44 <@uschebit> Evangelist ist doch ein Vertriebler
the second  :   für unverkäufliche Produkte, oder? (#korsett, 20120821)


signature.asc
Description: Digital signature

Re: [PATCH] toplev.c: Process the failure when read fails for random_seed

[Gerald Pfeifer]

On Friday 2015-01-23 04:50, Chen Gang S wrote:
> And I want to consult: for passing assignment working flow, must I 
> make a patch which contents much code lines? (At present, my patches 
> are all trivial patch).

No, the assignment process does not have any requirements on
past or current patches.  You even can complete the assignment
process without a single patch at that point.

So, do not worry.

And we are happy to see improvements and fixes of all kinds,
so please continue.

Gerald

Re: [PATCH] Fix ubsan and C++14 constexpr ICEs (PR sanitizer/63956)

[Mike Stump]

On Dec 1, 2014, at 2:52 AM, Marek Polacek  wrote:
> On Sun, Nov 30, 2014 at 11:00:12PM -0500, Jason Merrill wrote:
>> On 11/27/2014 08:57 AM, Marek Polacek wrote:
>>> -/* { dg-error "is not a constant expression" "" { target c++ } 12 } */
>>> +/* { dg-error "" "" { xfail { *-*-* } } 11 } */
>> 
>> Please keep the expected message.
> 
> Done in the below.
> 
> 2014-12-01  Marek Polacek  
> 
>   PR sanitizer/63956
>   * ubsan.c (is_ubsan_builtin_p): Check also built-in class.
> cp/
>   * constexpr.c: Include ubsan.h.
>   (cxx_eval_call_expression): Bail out for IFN_UBSAN_{NULL,BOUNDS}
>   internal functions and for ubsan builtins.
>   * error.c: Include internal-fn.h.
>   (dump_expr): Add printing of internal functions.
> testsuite/
>   * c-c++-common/ubsan/shift-5.c: Add fails.

Do you see:

PASS: c-c++-common/ubsan/shift-5.c   -O0   (test for errors, line 11)
XFAIL: c-c++-common/ubsan/shift-5.c   -O0   (test for errors, line 11)
PASS: c-c++-common/ubsan/shift-5.c   -O0   (test for errors, line 14)
XFAIL: c-c++-common/ubsan/shift-5.c   -O0   (test for errors, line 14)
PASS: c-c++-common/ubsan/shift-5.c   -O0   (test for errors, line 17)
XFAIL: c-c++-common/ubsan/shift-5.c   -O0   (test for errors, line 17)
PASS: c-c++-common/ubsan/shift-5.c   -O0   (test for errors, line 20)
XFAIL: c-c++-common/ubsan/shift-5.c   -O0   (test for errors, line 20)
PASS: c-c++-common/ubsan/shift-5.c   -O0   (test for errors, line 34)
XFAIL: c-c++-common/ubsan/shift-5.c   -O0   (test for errors, line 34)
PASS: c-c++-common/ubsan/shift-5.c   -O0   (test for errors, line 37)
XFAIL: c-c++-common/ubsan/shift-5.c   -O0   (test for errors, line 37)

on x86_64 on linux?

If so, this really isn’t cool.  You cannot have the same name as both pass and 
fail.  At the heart of regression analysis is the notion that no test that 
passed before now fails.  One can run contrib/compare_tests to see if a patch 
one is working on has any regressions in it, the beauty of the script is it 
will tell you in plain language if there are any regressions or not.  The 
standard for gcc is, no regressions.

Could you find a way to fix this?  Splitting into C and C++ test cases might be 
one way.  Fixing any expected failures might be another.

Re: Add to maintainers list.

[Mike Stump]

On Jan 25, 2015, at 2:10 AM, Tom de Vries  wrote:
> On 24-01-15 20:41, Gerald Pfeifer wrote:
>> Hi Alex,
>> 
>> On Friday 2014-11-21 10:07, Alex Velenko wrote:
>>> Can someone, please, approve?
>> 
>> we tried to document this in https://gcc.gnu.org/svnwrite.html .
>> 
>> Can you perhaps suggest a way for us to improve this to make
>> it more clear or easier to find?
>> 
> 
> How about this?

I’d rather not.  Policy should go into the policy page, and if people can’t 
read and understand the policy page and ask about policy anyway, then that is a 
good thing.  We can point them back at the policy page and they can read it 
again.  Edits to policy should go into the policy page.  That way, one can read 
just the policy page and keep up.  Anyway, that’s my take.

Re: [[ARM/AArch64][testsuite] 03/36] Add vmax, vmin, vhadd, vhsub and vrhadd tests.

[Christophe Lyon]

On 23 January 2015 at 14:44, Christophe Lyon  wrote:
> On 23 January 2015 at 12:42, Christophe Lyon  
> wrote:
>> On 23 January 2015 at 11:18, Tejas Belagod  wrote:
>>> On 22/01/15 21:31, Christophe Lyon wrote:

 On 22 January 2015 at 16:22, Tejas Belagod  wrote:
>
> On 22/01/15 14:28, Christophe Lyon wrote:
>>
>>
>> On 22 January 2015 at 12:19, Tejas Belagod 
>> wrote:
>>>
>>>
>>> On 21/01/15 15:07, Christophe Lyon wrote:



 On 19 January 2015 at 17:54, Marcus Shawcroft
  wrote:
>
>
>
> On 19 January 2015 at 15:43, Christophe Lyon
> 
> wrote:
>>
>>
>>
>> On 19 January 2015 at 14:29, Marcus Shawcroft
>>  wrote:
>>>
>>>
>>>
>>> On 16 January 2015 at 17:52, Christophe Lyon
>>>  wrote:
>>>
> OK provided, as per the previous couple, that we don;t regression
> or
> introduce new fails on aarch64[_be] or aarch32.




 This patch shows failures on aarch64 and aarch64_be for vmax and
 vmin
 when the input is -NaN.
 It's a corner case, and my reading of the ARM ARM is that the
 result
 should the same as on aarch32.
 I haven't had time to look at it in more details though.
 So, not OK?
>>>
>>>
>>>
>>>
>>> They should have the same behaviour in aarch32 and aarch64. Did you
>>> test on HW or a model?
>>>
>> I ran the tests on qemu for aarch32 and aarch64-linux, and on the
>> foundation model for aarch64*-elf.
>
>
>
>
> Leave this one out until we understand why it fails. /Marcus




 I've looked at this a bit more.
 We have
 fmaxv0.4s, v0.4s, v1.4s
 where v0 is a vector of -NaN (0xffc0) and v1 is a vector of 1.

 The output is still -NaN (0xffc0), while the test expects
 defaultNaN (0x7fc0).

>>>
>>> In the AArch32 execution state, Advanced SIMD FP arithmetic always uses
>>> the
>>> DefaultNaN setting regardless of the DN-bit value in the FPSCR. In
>>> AArch64
>>> execution state, result of Advanced SIMD FP arithmetic operations
>>> depend
>>> on
>>> the value of the DN-bit i.e. either propagate the input NaN or generate
>>> DefaultNaN depending on the value of DN.
>>
>>
>>
>> Maybe I'm using an outdated doc. On page 2282 of ARMv8 ARM rev C, I
>> can see only the latter (no diff between aarch32 and aarch64 in
>> FPProcessNan pseudo-code)
>>
>
> If you see pg. 4005 in the same doc(rev C), you'll see the FPSCR spec -
> under DN:
>
> "The value of this bit only controls scalar floating-point arithmetic.
> Advanced SIMD arithmetic always uses the Default NaN setting, regardless
> of
> the value of the DN bit."
>
> Also on page 3180 for the description of VMAX(vector FP), it says:
> "
> *  max(+0.0, -0.0) = +0.0
> * If any input is a NaN, the corresponding result element is the default
> NaN.
> "
>
 Oops I was looking at FMAX (vector) pg 936.

> The pseudocode for FPMax () on pg. 3180 passes StandardFPSCRValue() to
> FPMax() which is on pg. 2285
>
> // StandardFPSCRValue()
> // 
> FPCRType StandardFPSCRValue()
> return ‘0’ : FPSCR.AHP : ‘11’
>
> Here bit-25(FPSCR.DN) is set to 1.
>

 So, we should get defaultNaN too on aarch64, and no need to try to
 force DN to 1 in gdb?

 What can be wrong?

>>>
>>> On pg 3180, I see VMAX(FPSIMD) for A32/T32, not A64. I hope we're reading
>>> the same document.
>>>
>>> Regardless of the page number, if you see the pseudocode for VMAX(FPSIMD)
>>> for AArch32, StandardFPSCRValue() (i.e. DN = 1) is passed to FPMax() which
>>> means generate DefaultNaN() regardless.
>>>
>>> OTOH, on pg 936, you have FMAX(vector) for A64 where FPMax() in the
>>> pseudocode gets just FPCR.
>>>
>>>
>> Ok, that was my initial understanding but our discussion confused me.
>>
>> And that's why I tried to force DN = 1 in gdb before single-stepping over
>> fmaxv0.4s, v0.4s, v1.4s
>>
>> but it changed nothing :-(
>> Hence my question about a gdb possible bug or misuse.
>
> Hmm... user error, I missed one bit
> set $fpcr=0x200
> works under gdb.
>
>> I'll try modifying the test to have it force DN=1.
>>
> Forcing DN=1 in the test makes it pass.
>
> I am going to look at adding that cleanly to my test, and resubmit it.
>
> Thanks, and sorry for the noise.
>
Here is the updated version:
- Now I set DN=1 on AArch64 in clean_results, as it is the main
i

Re: New patch: [AArch64] [BE] [1/2] Make large opaque integer modes endianness-safe.

[Christophe Lyon]

On 17 December 2014 at 18:02, Tejas Belagod  wrote:
> On 17/12/14 16:46, Marcus Shawcroft wrote:
>>
>> On 17 December 2014 at 15:15, Tejas Belagod  wrote:
>>
 It isn;t clear to me how far through the various BE patches we need to
 get before 59810 is actually resolved?
>>>
>>>
>>>
>>> David's 2 patches
>>>
>>> https://gcc.gnu.org/ml/gcc-patches/2014-11/msg01431.html
>>> https://gcc.gnu.org/ml/gcc-patches/2014-10/msg01099.html
>>>
>>> and Alan's 2 patches:
>>>
>>> https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02797.html
>>
>>
>> OK, thanks, my understanding is that all of the above are now blocked
>> waiting some resolution on this patch to rtlanal.c:
>
>
> I believe so.
>
> Thanks,
> Tejas.
>

Hi,
If I'm not mistaken, this has been committed as r219959, and is
causing regressions on aarch64_be for several AdvSimd intrinsic tests:
vldX_lane, vtrn, vuzp, vzip, as well as vldN_1 and vstN_1

See:
http://abe.tcwglab.linaro.org/logs/validations/cross-validation/gcc/trunk/219959/report-build-info.html

These tests started passing at the previous commit (r219958) with the
other half of this patch.

I haven't looked at the details yet.

Christophe.

>>
>>> https://gcc.gnu.org/ml/gcc-patches/2014-12/msg01087.html
>>
>>
>> /Marcus
>>
>
>

Re: [PATCH] toplev.c: Process the failure when read fails for random_seed

[Chen Gang S]

On 1/26/15 03:50, Gerald Pfeifer wrote:
> On Friday 2015-01-23 04:50, Chen Gang S wrote:
>> And I want to consult: for passing assignment working flow, must I 
>> make a patch which contents much code lines? (At present, my patches 
>> are all trivial patch).
> 
> No, the assignment process does not have any requirements on
> past or current patches.  You even can complete the assignment
> process without a single patch at that point.
> 
> So, do not worry.
> 
> And we are happy to see improvements and fixes of all kinds,
> so please continue.
> 

Thank you very much for your encourage. :-)

-- 
Chen Gang

Open, share, and attitude like air, water, and life which God blessed

Re: [wwwdocs] C++ SD-6 feature test column for cxx0x.html and cxx1y.html

[Gerald Pfeifer]

Hi Ed,

On Friday 2015-01-02 13:59, Ed Smith-Rowland wrote:
>>> I would like peoples opinion of adding another column to the tables
>>> indicating C++ feature status for C++11 and C++14 that contains the
>>> relevant SD-6 feature macro.
>> Sure, that makes sense.
> I seem unable to commit to wwwdocs.
> Could you or someone else commit this for me?

does https://gcc.gnu.org/about.html help?  If you have SVN write
access, you should have write access to the web pages.

If not, can you please advise (and we can look into debugging it
off-list)?

Also if your concrete patch has not been applied yet, can you please 
share again and I'll apply it on your behalf?

Gerald

Re: PR39570 (gfortran) cabs and cabsf are named differently on NetBSD 5

[Gerald Pfeifer]

Kai-Uwe,

according to gcc/MAINTAINERS Jason and Krister are NetBSD 
maintainers for GCC and can approve patches like yours, so
let me copy them.

(Should this be applied now, at least the copyright years
need to be adjusted to include 2015.)

Gerald

On Wednesday 2014-12-17 23:10, Kai-Uwe Eckhardt wrote:
> I have used the darwin files as templates and made the necessary changes. 
> It reduces test failures from over 15000 (all run tests) to 27 in 3 files
> (patch for PR 48244 applied as well) on NetBSD 7.0 amd64.
> 
> --- /dev/null 2014-12-15 07:13:57.0 +
> +++ gcc/config/netbsd-protos.h
> @@ -0,0 +1,29 @@
> +/* Prototypes.
> +   Copyright (C) 2001-2014 Free Software Foundation, Inc.
> +
> +This file is part of GCC.
> +
> +GCC is free software; you can redistribute it and/or modify
> +it under the terms of the GNU General Public License as published by
> +the Free Software Foundation; either version 3, or (at your option)
> +any later version.
> +
> +GCC is distributed in the hope that it will be useful,
> +but WITHOUT ANY WARRANTY; without even the implied warranty of
> +MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> +GNU General Public License for more details.
> +
> +You should have received a copy of the GNU General Public License
> +along with GCC; see the file COPYING3.  If not see
> +.  */
> +
> +#ifndef _NETBSD_PROTOS_H_
> +#define _NETBSD_PROTOS_H_
> +
> +double __c99_cabs (double complex);
> +float __c99_cabsf (float complex);
> +long double __c99_cabsl (long double complex);
> +
> +void netbsd_patch_builtins (void);
> +
> +#endif /* _NETBSD_PROTOS_H_ */
> 
> 
> --- /dev/null 2014-12-17 06:10:54.0 +
> +++ gcc/config/netbsd.c
> @@ -0,0 +1,106 @@
> +/* Functions for generic NetBSD as target machine for GNU C compiler.
> +   Copyright (C) 1989-2014 Free Software Foundation, Inc.
> +   Contributed by Apple Computer Inc.
> +
> +This file is part of GCC.
> +
> +GCC is free software; you can redistribute it and/or modify
> +it under the terms of the GNU General Public License as published by
> +the Free Software Foundation; either version 3, or (at your option)
> +any later version.
> +
> +GCC is distributed in the hope that it will be useful,
> +but WITHOUT ANY WARRANTY; without even the implied warranty of
> +MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> +GNU General Public License for more details.
> +
> +You should have received a copy of the GNU General Public License
> +along with GCC; see the file COPYING3.  If not see
> +.  */
> +
> +#include "config.h"
> +#include "system.h"
> +#include "coretypes.h"
> +#include "tm.h"
> +#include "rtl.h"
> +#include "regs.h"
> +#include "hard-reg-set.h"
> +#include "insn-config.h"
> +#include "conditions.h"
> +#include "insn-flags.h"
> +#include "output.h"
> +#include "insn-attr.h"
> +#include "flags.h"
> +#include "tree.h"
> +#include "stringpool.h"
> +#include "varasm.h"
> +#include "stor-layout.h"
> +#include "expr.h"
> +#include "reload.h"
> +#include "hashtab.h"
> +#include "hash-set.h"
> +#include "vec.h"
> +#include "machmode.h"
> +#include "input.h"
> +#include "function.h"
> +#include "ggc.h"
> +#include "langhooks.h"
> +#include "target.h"
> +#include "tm_p.h"
> +#include "diagnostic-core.h"
> +#include "toplev.h"
> +#include "dominance.h"
> +#include "cfg.h"
> +#include "cfgrtl.h"
> +#include "cfganal.h"
> +#include "lcm.h"
> +#include "cfgbuild.h"
> +#include "cfgcleanup.h"
> +#include "predict.h"
> +#include "basic-block.h"
> +#include "df.h"
> +#include "debug.h"
> +#include "obstack.h"
> +#include "hash-table.h"
> +#include "tree-ssa-alias.h"
> +#include "internal-fn.h"
> +#include "gimple-fold.h"
> +#include "tree-eh.h"
> +#include "gimple-expr.h"
> +#include "is-a.h"
> +#include "gimple.h"
> +#include "gimplify.h"
> +#include "hash-map.h"
> +#include "plugin-api.h"
> +#include "ipa-ref.h"
> +#include "cgraph.h"
> +#include "lto-streamer.h"
> +#include "lto-section-names.h"
> +
> +static void
> +netbsd_patch_builtin (enum built_in_function fncode)
> +{
> +  tree fn = builtin_decl_explicit (fncode);
> +  tree sym;
> +  char *newname;
> +
> +  if (!fn)
> +return;
> +
> +  sym = DECL_ASSEMBLER_NAME (fn);
> +  newname = ACONCAT (("__c99_", IDENTIFIER_POINTER (sym), NULL));
> +
> +  set_user_assembler_name (fn, newname);
> +
> +  fn = builtin_decl_implicit (fncode);
> +  if (fn)
> +set_user_assembler_name (fn, newname);
> +}
> +
> +void
> +netbsd_patch_builtins (void)
> +{
> +  netbsd_patch_builtin (BUILT_IN_CABSF);
> +  netbsd_patch_builtin (BUILT_IN_CABS);
> +  netbsd_patch_builtin (BUILT_IN_CABSL);
> +}
> 
> 
> --- gcc/config/netbsd.h.orig  2014-01-02 22:23:26.0 +
> +++ gcc/config/netbsd.h
> @@ -17,6 +17,9 @@ You should have received a copy of the G
>  along with GCC; see the file COPYING3.  If not see
>  .  */
>  
> +
> +#include "netbsd-protos.h"
> +
>  /* TARGET_OS_CPP_BUILTIN

Re: [PATCH][www] Tidy criteria.html

[Gerald Pfeifer]

On Wednesday 2015-01-21 14:17, Richard Biener wrote:
> Just read it and thought the following may apply.

This is a minor follow up.  It makes a link relative and removes
a direct reference to Bugzilla.

Applied.

Gerald

Index: criteria.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-5/criteria.html,v
retrieving revision 1.3
diff -u -r1.3 criteria.html
--- criteria.html   21 Jan 2015 13:30:56 -  1.3
+++ criteria.html   25 Jan 2015 22:21:51 -
@@ -86,7 +86,7 @@
 There are no release criteria for tertiary platforms.
 
 In general bugs blocking the release are marked with priority P1
-in bugzilla (https://gcc.gnu.org/bugs/management.html";>Maintaining 
the GCC Bugzilla database).
+(Maintaining the GCC Bugzilla 
database).
 
 In contrast to previous releases, we have removed all mention of
 explicit application testing.  It is our experience that, with the

Re: [doc, committed] fix @var markup on option keyword choices

[Gerald Pfeifer]

On Wednesday 2015-01-07 19:20, Sandra Loosemore wrote:

The documented syntax for most GCC options that take magic keywords is of the
form @option{-ffoo=@var{magic}}, with the various literal values for
@var{magic} listed in the option description.  There are a number, though,
that list the keyword choices in the syntax, but with two different markup
conventions.  This patch changes the ones that wrap the whole keyword list in
@var, like -fvtable-verify, to use the same markup convention as the others,
like -Wsuggest-attribute, which use the regular option/code font for the
keywords but set off the syntactic delimiters "[", "|", and "]" in Roman
font..  @var is supposed to be for metasyntactic variables and seems
inappropriate for literal keywords, so I think it's less correct than the
other convention.


Agreed, thanks for making this change!

Gerald

Re: [wwwdocs] Buildstat update for 4.8

[Gerald Pfeifer]

On Monday 2014-12-01 20:44, Tom G. Christensen wrote:
> Testresults for 4.8.3
>   hppa-unknown-linux-gnu
>   x86_64-apple-darwin14.0.0

Applied, thank you.

Gerald

Re: [PATCH, libgfortran, committed] PR 64770 Segfault when trying to open existing file with status="new"

[Janne Blomqvist]

On Sun, Jan 25, 2015 at 1:28 PM, Jakub Jelinek  wrote:
> On Sun, Jan 25, 2015 at 10:35:50AM +0100, Dominique Dhumieres wrote:
>> > ... FAIL: gfortran.dg/open_new_segv.f90   -O0  execution test
>>
>> This is fixed with something such as
>>
>> --- ../_clean/gcc/testsuite/gfortran.dg/open_new_segv.f90 2015-01-25 
>> 00:37:43.0 +0100
>> +++ gcc/testsuite/gfortran.dg/open_new_segv.f90   2015-01-25 
>> 10:31:40.0 +0100
>> @@ -1,4 +1,5 @@
>>  ! { dg-do run }
>> +! { dg-shouldfail "File already exists" }
>>  ! PR 64770 SIGSEGV when trying to open an existing file with status="new"
>>  program pr64770
>>implicit none
>> @@ -8,3 +9,5 @@ program pr64770
>>open(99, file="pr64770test.dat", access="stream", form="unformatted", &
>> status="new")
>>  end program pr64770
>> +! { dg-output "At line 10 of file.*" }
>> +! { dg-output "Fortran runtime error: File .pr64770test.dat. already 
>> exists" }
>>
>> Note that it may be worth to run a second test to cleanup the file 
>> 'pr64770test.dat'.
>
> That is not possible in a second test, the second test might be scheduled in
> a different job, in a different directory.
> So you need to solve this either in the test (call some function that
> removes it), or in dg-final.
>
> Jakub

Sorry about that, committed r220098 as obvious which should fix the testcase.

Index: gcc/testsuite/ChangeLog
===
--- gcc/testsuite/ChangeLog (revision 220097)
+++ gcc/testsuite/ChangeLog (working copy)
@@ -1,3 +1,9 @@
+2015-01-26  Janne Blomqvist  
+
+   PR libfortran/64770
+   * gfortran.dg/open_new_segv.f90: Add dg- stuff to make test work
+   correctly, clean up afterwards.
+
 2015-01-25  Mikael Morin  

PR fortran/62044
Index: gcc/testsuite/gfortran.dg/open_new_segv.f90
===
--- gcc/testsuite/gfortran.dg/open_new_segv.f90 (revision 220097)
+++ gcc/testsuite/gfortran.dg/open_new_segv.f90 (working copy)
@@ -1,4 +1,5 @@
 ! { dg-do run }
+! { dg-shouldfail "File already exists" }
 ! PR 64770 SIGSEGV when trying to open an existing file with status="new"
 program pr64770
   implicit none
@@ -8,3 +9,6 @@ program pr64770
   open(99, file="pr64770test.dat", access="stream", form="unformatted", &
status="new")
 end program pr64770
+! { dg-output "At line 10 of file.*" }
+! { dg-output "Fortran runtime error: File .pr64770test.dat. already exists" }
+! { dg-final { remote_file build delete "pr64770test.dat" } }



-- 
Janne Blomqvist

[wwwdocs] gcc-5/changes.html and -malign-data

[Gerald Pfeifer]

This fixes grammar and avoids "alignment value" without "an" or "the".

Applied.

Gerald

Index: gcc-5/changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-5/changes.html,v
retrieving revision 1.70
diff -u -r1.70 changes.html
--- gcc-5/changes.html  21 Jan 2015 22:04:43 -  1.70
+++ gcc-5/changes.html  25 Jan 2015 10:08:07 -
@@ -531,12 +531,12 @@
place of the __fentry__ or mcount call, so that a call per function
can be later patched in. This can be used for low overhead tracing or
hot code patching.
-The new -malign-data= option controls to how
+   The new -malign-data option controls how
GCC aligns variables.  -malign-data=compat uses
-   increased alignment value compatible with GCC 4.8 and earlier,
-   -malign-data=abi uses alignment value as specified by
+   increased alignment compatible with GCC 4.8 and earlier,
+   -malign-data=abi uses alignment as specified by
the psABI, and -malign-data=cacheline uses increased
-   alignment value to match the cache line size.
+   alignment to match the cache line size.
-malign-data=compat is the default.
The new -mskip-rax-setup option skips setting
up the RAX register when SSE is disabled and there are no variable

Re: [doc, committed] copy-edit documentation for -fisolate-erroneous-paths-*

[Gerald Pfeifer]

On Saturday 2015-01-03 17:59, Sandra Loosemore wrote:
> * most places in the manual use "null" or more rarely "@code{NULL}" 
> rather than "NULL"

So, should this be documented in gcc.gnu.org/codingconventions.html?

Joseph?

Gerald

Re: [doc, committed] invoke.texi markup fixes

[Gerald Pfeifer]

On Monday 2015-01-05 19:37, Sandra Loosemore wrote:

(I'm actually surprised that anybody even bothered to look at the patch
If the doc maintainers would prefer me to post these kinds of copy-editing
changes for review rather than just commit them, please let me know.)


I am fine, in fact happy, for you to make and just commit these
changes (and did not see Joseph indicate otherwise).

Gerald

Re: [wwwdocs] Re: [patch] Update C++11 status in libstdc++ docs

[Gerald Pfeifer]

On Tuesday 2015-01-20 16:38, Jonathan Wakely wrote:

Here's the wwwdocs patch for gcc-5/changes.html


I applied this little follow-up which ends lists with a full stop
instead of using a semi-colon.

Gerald

Index: changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-5/changes.html,v
retrieving revision 1.71
diff -u -r1.71 changes.html
--- changes.html25 Jan 2015 10:10:20 -  1.71
+++ changes.html25 Jan 2015 23:46:31 -
@@ -297,9 +297,9 @@

  Runtime Library (libstdc++)
  
- A new implementation of std::string is enabled by 
default,
+A new implementation of std::string is enabled by default,
using the small string optimization instead of
-copy-on-write reference counting; 
+copy-on-write reference counting.
 A new implementation of std::list is enabled by default,
with an O(1) size() function; 
https://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html#status.iso.2011";>
@@ -321,7 +321,7 @@
 locale facets for Unicode conversion; 
 atomic operations for std::shared_ptr; 
 std::notify_all_at_thread_exit() and functions
-  for making futures ready at thread exit; 
+  for making futures ready at thread exit.
  

 Support for the C++11 hexfloat manipulator changes how
@@ -353,7 +353,7 @@
 function template std::experimental::search and
  related searcher types; 
 variable templates for type traits; 
- function template std::experimental::not_fn; 
+ function template std::experimental::not_fn.
  

New random number distributions logistic_distribution and

Re: [wwwdocs] Mention ipa-ICF and auto-FDO

[Gerald Pfeifer]

Hi Honza,

thanks for putting this together.  Please find some notes below.
Can you please take these plus the other bits of feedback you got
and post an updated patch for a quick final check?

On Wednesday 2015-01-21 22:58, Jan Hubicka wrote:
> Index: changes.html
> ===
> + New identical code folding pass (controled via 
> -fipa-icf).

"An Identical Code Folding (ICF) pass...has been added."

> +  Compared to the identical code folding performed by Gold linker this

"by the Gold linker"

> +  pass does not require function sections.  It also performs merging
> +  pre-inline so inter-procedural optimizations are aware of the

pre-inlining or before inlining?

> +  code re-use. On the other hand not all unifications performed
> +  by linker are doable by GCC pass; the GCC pass must honnor

"by a linker"

"doable by GCC which must honor" (no double n in honor)

> +  aliasing information. During link-time optimization of Firefox,
> +  the pass unify about 29000 functions that is 10% overall

"this pass unifies"

"that is..." -> "or 10% overall." (with full stop)

> + Devirtualization pass was significantly improved by adding

"The Devirtualization pass..."

> +  New auto-FDO mode that use profiles collected by low overhead
> +   profiling tools (perf) instead of more expensive program

"A new auto-FDO mode uses ..."

> +   instrumentation (via -fprofile-generate). SPEC2006
> +   benchmarks improve by 4.7% with auto-FDO and by 7.3% with
> +   traditional feedback directed optimization.

On which architecture?

Gerald

[PATCH, rs6000] Allow swap removal for convert-splat idiom

[Bill Schmidt]

Hi,

A not uncommon idiom on Power for vector floating-point computation is
used to convert a double-precision value to single-precision and copy it
to all elements of a vector float.  For this we see a specific convert
UNSPEC feeding an xxspltw pattern that copies from BE element zero.
Since all elements of the result are the same regardless of whether
swaps are present, this should not kill the vector swap removal
optimization for the containing computation.  This patch permits that.

The issue was reported privately to me, and I have created a test case
that reduces and anonymizes the original code.

Is this ok for trunk after GCC 5 branches?  I would also like to
backport it to GCC 5 subsequently.

Thanks,
Bill


[gcc]

2015-01-25  Bill Schmidt  

* config/rs6000/rs6000.c (rtx_is_swappable_p): Commentary
adjustments.
(insn_is_swappable_p): Return 1 for a convert from double to
single precision when all of its uses are splats of BE element
zero.

[gcc/testsuite]

2015-01-25  Bill Schmidt  

* gcc.target/powerpc/swaps-p8-18.c: New test.


Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c  (revision 219191)
+++ gcc/config/rs6000/rs6000.c  (working copy)
@@ -34046,7 +34046,8 @@ rtx_is_swappable_p (rtx op, unsigned int *special)
   order-dependent element, so additional fixup code would be
   needed to make those work.  Vector set and non-immediate-form
   vector splat are element-order sensitive.  A few of these
-  cases might be workable with special handling if required.  */
+  cases might be workable with special handling if required.
+  Adding cost modeling would be appropriate in some cases.  */
int val = XINT (op, 1);
switch (val)
  {
@@ -34085,12 +34086,6 @@ rtx_is_swappable_p (rtx op, unsigned int *special)
  case UNSPEC_VUPKLPX:
  case UNSPEC_VUPKLS_V4SF:
  case UNSPEC_VUPKLU_V4SF:
- /* The following could be handled as an idiom with XXSPLTW.
-These place a scalar in BE element zero, but the XXSPLTW
-will currently expect it in BE element 2 in a swapped
-region.  When one of these feeds an XXSPLTW with no other
-defs/uses either way, we can avoid the lane change for
-XXSPLTW and things will be correct.  TBD.  */
  case UNSPEC_VSX_CVDPSPN:
  case UNSPEC_VSX_CVSPDP:
  case UNSPEC_VSX_CVSPDPN:
@@ -34179,6 +34174,36 @@ insn_is_swappable_p (swap_web_entry *insn_entry, r
return 0;
 }
 
+  /* A convert to single precision can be left as is provided that
+ all of its uses are in xxspltw instructions that splat BE element
+ zero.  */
+  if (GET_CODE (body) == SET
+  && GET_CODE (SET_SRC (body)) == UNSPEC
+  && XINT (SET_SRC (body), 1) == UNSPEC_VSX_CVDPSPN)
+{
+  df_ref def;
+  struct df_insn_info *insn_info = DF_INSN_INFO_GET (insn);
+
+  FOR_EACH_INSN_INFO_DEF (def, insn_info)
+   {
+ struct df_link *link = DF_REF_CHAIN (def);
+ if (!link)
+   return 0;
+
+ for (; link; link = link->next) {
+   rtx use_insn = DF_REF_INSN (link->ref);
+   rtx use_body = PATTERN (use_insn);
+   if (GET_CODE (use_body) != SET
+   || GET_CODE (SET_SRC (use_body)) != UNSPEC
+   || XINT (SET_SRC (use_body), 1) != UNSPEC_VSX_XXSPLTW
+   || XEXP (XEXP (SET_SRC (use_body), 0), 1) != const0_rtx)
+ return 0;
+ }
+   }
+
+  return 1;
+}
+
   /* Otherwise check the operands for vector lane violations.  */
   return rtx_is_swappable_p (body, special);
 }
Index: gcc/testsuite/gcc.target/powerpc/swaps-p8-18.c
===
--- gcc/testsuite/gcc.target/powerpc/swaps-p8-18.c  (revision 0)
+++ gcc/testsuite/gcc.target/powerpc/swaps-p8-18.c  (working copy)
@@ -0,0 +1,35 @@
+/* { dg-do compile { target { powerpc64le-*-* } } } */
+/* { dg-skip-if "do not override -mcpu" { powerpc*-*-* } { "-mcpu=*" } { 
"-mcpu=power8" } } */
+/* { dg-options "-mcpu=power8 -O3" } */
+/* { dg-final { scan-assembler-not "xxpermdi" } } */
+
+/* This is a test for a specific convert-splat permute removal.  */
+
+void compute (float*, float*, float*, int, int);
+double test (void);
+double gorp;
+
+int main (void)
+{
+  float X[1], Y[256], Z[2000];
+  int i;
+  for (i = 0; i < 2500; i++)
+compute (X, Y, Z, 256, 2000);
+  gorp = test ();
+}
+
+void compute(float *X, float *Y, float *Z, int m, int n)
+{
+  int i, j;
+  float w, *x, *y;
+
+  for (i = 0; i < n; i++)
+{
+  w = 0.0;
+  x = X++;
+  y = Y;
+  for (j = 0; j < m; j++)
+   w += (*x++) * (*y++);
+  Z[i] = w;
+}
+}

RE: [PATCH, ARM, testsuite] Improve scd42-1.c for UAL

[Terry Guo]

> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Ramana Radhakrishnan
> Sent: Friday, January 23, 2015 6:35 PM
> To: Tony Liu
> Cc: gcc-patches; Ramana Radhakrishnan; Richard Earnshaw
> Subject: Re: [PATCH, ARM, testsuite] Improve scd42-1.c for UAL
> 
> On Thu, Jan 15, 2015 at 12:10 PM, Tony Liu  wrote:
> > Hi,
> >
> > This is the patch to improve the test case gcc.target/arm/scd42-1.c
> > for both UAL and non-UAL. It now checks UAL format assembly code for
> > Thumb1 and
> > Thumb2 while non-UAL format assembly code for ARM mode.
> 
> 
> OK.
> 
> Ramana
> >
> > With this patch, the test passes for both cases.
> >
> > Thanks,
> > Tony
> >
> > 2015-01-15  Tony Liu  
> >
> >* gcc.target/arm/scd42-1.c: Improve the check for UAL and
> > non-UAL cases.

Committed this patch on behalf of Tony:
https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=220102

BR,
Terry

Re: [wwwdocs] C++ SD-6 feature test column for cxx0x.html and cxx1y.html

[Ed Smith-Rowland]

On 01/25/2015 05:04 PM, Gerald Pfeifer wrote:

Hi Ed,

On Friday 2015-01-02 13:59, Ed Smith-Rowland wrote:

I would like peoples opinion of adding another column to the tables
indicating C++ feature status for C++11 and C++14 that contains the
relevant SD-6 feature macro.

Sure, that makes sense.

I seem unable to commit to wwwdocs.
Could you or someone else commit this for me?

does https://gcc.gnu.org/about.html help?  If you have SVN write
access, you should have write access to the web pages.

If not, can you please advise (and we can look into debugging it
off-list)?

Also if your concrete patch has not been applied yet, can you please
share again and I'll apply it on your behalf?

Gerald


Here is a new patch (no change from previous)..

If you could apply it that would be great.


Index: htdocs/projects/cxx0x.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/projects/cxx0x.html,v
retrieving revision 1.66
diff -r1.66 cxx0x.html
63a64
>   SD-6 Feature Test
68a70
>   __cpp_rvalue_references >= 200610
73a76
>   __cpp_ref_qualifiers >= 200710
78a82
>   
83a88
>   __cpp_nsdmi >= 200809
89a95
>   __cpp_variadic_templates >= 200704
95a102
>   
100a108
>   __cpp_initializer_lists >= 200806
105a114
>   __cpp_static_assert >= 200410
110a120
>   
115a126
>   
120a132
>   
125a138
>   
130a144
>   __cpp_lambdas >= 200907
136a151
>   __cpp_decltype >= 200707
141a157
>   
147a164
>   
153a171
>   
159a178
>   
164a184
>   __cpp_alias_templates >= 200704
169a190
>   
174a196
>   
180a203
>   
187a211
>   
192a217,218
>   __cpp_attributes >= 200809; __has_cpp_attribute(noreturn) >= 200809;
>   __has_cpp_attribute(carries_dependency) == 0 (not implemented)
197a224
>   __cpp_constexpr >= 200704
202a230
>   
209a238
>   __cpp_delegating_constructors >= 200604
214a244
>   __cpp_inheriting_constructors >= 200802
219a250
>   
224a256
>   __cpp_unicode_characters >= 200704
229a262
>   __cpp_unicode_literals >= 200710
234a268
>   __cpp_raw_strings >= 200710
239a274
>   
244a280
>   __cpp_user_defined_literals >= 200809
249a286
>   
255a293
>   
260a299
>   
265a305
>   
271a312
>   
276a318
>   
281a324
>   
286a330
>   __cpp_range_based_for >= 200907
293a338
>   
298a344
>   
303a350
>   
308a356
>   
312c360
<   Concurrency
---
>   Concurrency
317a366
>   
322a372
>   
327a378
>   
332a384
>   
338a391
>   
343a397
>   
349a404
>   
354a410
>   
359a416
>   
364a422
>   
369a428
>   
373c432
<   C99 Features in C++11
---
>   C99 Features in C++11
379a439
>   
385a446
>   
391a453
>   
396a459
>   
Index: htdocs/projects/cxx1y.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/projects/cxx1y.html,v
retrieving revision 1.21
diff -r1.21 cxx1y.html
47a48
>   SD-6 Feature Test
59a61,62
>   __cpp_binary_literals >= 201304
> 
66a70,71
>   __cpp_decltype_auto >= 201304
> 
73a79,80
>   __cpp_init_captures >= 201304
> 
80a88,89
>   __cpp_generic_lambdas >= 201304
> 
87a97,98
>   __cpp_variable_templates >= 201304
> 
94a106
>   __cpp_constexpr >= 201304
101a114
>   __cpp_aggregate_nsdmi >= 201304
106a120
>   
113a128
>   __cpp_sized_deallocation >= 201309
119a135
>   __has_cpp_attribute(deprecated) >= 201309
125a142,143
>   __has_cpp_attribute(deprecated) >= 201309
>   __cpp_digit_separator >= 201309
145a164
>   __cpp_runtime_arrays >= 198712

Re: [wwwdocs] Mention ipa-ICF and auto-FDO

[Jan Hubicka]

> Hi Honza,
> 
> thanks for putting this together.  Please find some notes below.
> Can you please take these plus the other bits of feedback you got
> and post an updated patch for a quick final check?

Thanks, here is updated patch!

Index: changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-5/changes.html,v
retrieving revision 1.72
diff -u -r1.72 changes.html
--- changes.html25 Jan 2015 23:47:32 -  1.72
+++ changes.html26 Jan 2015 06:10:15 -
@@ -35,6 +35,15 @@
   
 Inter-procedural optimization improvements:
 
+ An Identical Code Folding (ICF) pass (controled via
+-fipa-icf) has been added.  Compared to the identical
+code folding performed by the Gold linker this
+pass does not require function sections.  It also performs merging
+before inlining so inter-procedural optimizations are aware of the
+code re-use. On the other hand not all unifications performed
+by a linker are doable by GCC which must honor
+aliasing information. During link-time optimization of Firefox,
+this pass unifies about 29000 functions that is 10% overall.
  The devirtualization pass was significantly improved by adding
 better support for speculative devirtualization and dynamic type
 detection. About 50% of virtual calls in Firefox are speculatively
@@ -72,6 +81,11 @@
 
 Feedback directed optimization improvements:
 
+  A new auto-FDO mode uses profiles collected by low overhead
+ profiling tools (perf) instead of more expensive program
+ instrumentation (via -fprofile-generate). SPEC2006
+ benchmarks on x86-64 improve by 4.7% with auto-FDO and by 7.3% with
+ traditional feedback directed optimization.
   Profile precision was improved in presence of C++ inline and extern
  inline functions.
   New gcov-tool to manipulate profiles.

Re: Re: PR39570 (gfortran) cabs and cabsf are named differently on NetBSD 5

[Kai-Uwe Eckhardt]

Hello,

> according to gcc/MAINTAINERS Jason and Krister are NetBSD 
> maintainers for GCC and can approve patches like yours, so
> let me copy them.
> 
> (Should this be applied now, at least the copyright years
> need to be adjusted to include 2015.)

Due to the latest changes in tree-core.h and darwin.c I had
to change the patch for netbsd.c as well:
 
--- /dev/null   2015-01-20 20:33:39.0 +
+++ gcc/config/netbsd.c
@@ -0,0 +1,122 @@
+/* Functions for generic NetBSD as target machine for GNU C compiler.
+   Copyright (C) 1989-2015 Free Software Foundation, Inc.
+   Contributed by Apple Computer Inc.
+
+This file is part of GCC.
+
+GCC is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 3, or (at your option)
+any later version.
+
+GCC is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with GCC; see the file COPYING3.  If not see
+.  */
+
+
+#include "config.h"
+#include "system.h"
+#include "coretypes.h"
+#include "tm.h"
+#include "rtl.h"
+#include "regs.h"
+#include "hard-reg-set.h"
+#include "insn-config.h"
+#include "conditions.h"
+#include "insn-flags.h"
+#include "output.h"
+#include "insn-attr.h"
+#include "flags.h"
+#include "hash-set.h"
+#include "machmode.h"
+#include "vec.h"
+#include "double-int.h"
+#include "input.h"
+#include "alias.h"
+#include "symtab.h"
+#include "wide-int.h"
+#include "inchash.h"
+#include "tree.h"
+#include "fold-const.h"
+#include "stringpool.h"
+#include "varasm.h"
+#include "stor-layout.h"
+#include "hashtab.h"
+#include "function.h"
+#include "statistics.h"
+#include "real.h"
+#include "fixed-value.h"
+#include "expmed.h"
+#include "dojump.h"
+#include "explow.h"
+#include "calls.h"
+#include "emit-rtl.h"
+#include "stmt.h"
+#include "expr.h"
+#include "reload.h"
+#include "ggc.h"
+#include "langhooks.h"
+#include "target.h"
+#include "tm_p.h"
+#include "diagnostic-core.h"
+#include "toplev.h"
+#include "dominance.h"
+#include "cfg.h"
+#include "cfgrtl.h"
+#include "cfganal.h"
+#include "lcm.h"
+#include "cfgbuild.h"
+#include "cfgcleanup.h"
+#include "predict.h"
+#include "basic-block.h"
+#include "df.h"
+#include "debug.h"
+#include "obstack.h"
+#include "hash-table.h"
+#include "tree-ssa-alias.h"
+#include "internal-fn.h"
+#include "gimple-fold.h"
+#include "tree-eh.h"
+#include "gimple-expr.h"
+#include "is-a.h"
+#include "gimple.h"
+#include "gimplify.h"
+#include "hash-map.h"
+#include "plugin-api.h"
+#include "ipa-ref.h"
+#include "cgraph.h"
+#include "lto-streamer.h"
+#include "lto-section-names.h"
+
+static void
+netbsd_patch_builtin (enum built_in_function fncode)
+{
+  tree fn = builtin_decl_explicit (fncode);
+  tree sym;
+  char *newname;
+
+  if (!fn)
+return;
+
+  sym = DECL_ASSEMBLER_NAME (fn);
+  newname = ACONCAT (("__c99_", IDENTIFIER_POINTER (sym), NULL));
+
+  set_user_assembler_name (fn, newname);
+
+  fn = builtin_decl_implicit (fncode);
+  if (fn)
+set_user_assembler_name (fn, newname);
+}
+
+void
+netbsd_patch_builtins (void)
+{
+  netbsd_patch_builtin (BUILT_IN_CABSF);
+  netbsd_patch_builtin (BUILT_IN_CABS);
+  netbsd_patch_builtin (BUILT_IN_CABSL);
+}

Re: [Patch, Fortran] PR63861 - fix OpenMP/ACC's gfc_has_alloc_comps

[Jakub Jelinek]

On Sat, Jan 24, 2015 at 07:21:27PM +0100, Tobias Burnus wrote:
> gfortran's scalar coarray are special: The descriptorless variant is a
> normal variable with some language-specific additional information (corank,
> bounds). The descriptor variant has a descriptor but the _data component is
> just a pointer to the scalar variable.
> 
> As the element type of a descriptorless coarray is the type itself, we need
> to break the while loop.
> 
> Build and regtested on x86-64-gnu-linux.
> OK for the trunk?

Won't that break e.g.

subroutine foo
  type x
integer, allocatable :: y
  end type
  type(x) :: z(2, 2)
  !$omp parallel private (z)
allocate (z(2, 2)%y)
  !$omp end parallel
end subroutine

In that case I believe we have GFC_ARRAY_TYPE_P and !GFC_DESCRIPTOR_TYPE_P,
and GFC_TYPE_ARRAY_RANK (type) is 2, and the struct has allocatable
components, but we would return that we don't have them?

> --- a/gcc/fortran/trans-openmp.c
> +++ b/gcc/fortran/trans-openmp.c
> @@ -189,7 +189,8 @@ gfc_has_alloc_comps (tree type, tree decl)
>   return false;
>  }
>  
> -  while (GFC_DESCRIPTOR_TYPE_P (type) || GFC_ARRAY_TYPE_P (type))
> +  if (GFC_DESCRIPTOR_TYPE_P (type)
> +  || (GFC_ARRAY_TYPE_P (type) && GFC_TYPE_ARRAY_RANK (type) == 0))
>  type = gfc_get_element_type (type);
>  
>if (TREE_CODE (type) != RECORD_TYPE)

Jakub