Re: [PATCH PR71347][Partial revert r235513]Compute cost for all uses in group

2016-06-18 Thread Andreas Schwab
Bin Cheng  writes:

> diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr71347.c 
> b/gcc/testsuite/gcc.dg/tree-ssa/pr71347.c
> new file mode 100644
> index 000..7e5ad49
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/tree-ssa/pr71347.c
> @@ -0,0 +1,17 @@
> +/* { dg-do compile } */
> +/* { dg-options "-O2 -fdump-tree-optimized" } */
> +
> +double in;
> +extern void Write (double);
> +void foo (void)
> +{
> +  static double X[9];
> +  int i;
> +X[1] = in * in; 
> +for (i = 2; i <= 8; i++)
> +X[i] = X[i - 1] * X[1]; 
> +Write (X[5]);
> +}
> +
> +/* Load of X[i - i] can be omitted by reusing X[i] in previous iteration.  */
> +/* { dg-final { scan-tree-dump-not ".* = MEM.*;" "optimized"} } */

The test fails on ia64, this is what I get in .optimized:

;; Function foo (foo, funcdef_no=0, decl_uid=1387, cgraph_uid=0, symbol_order=1)

foo ()
{
  int i;
  static double X[9];
  double in.0_1;
  double in.1_2;
  double _3;
  int _4;
  double _5;
  double _6;
  double _7;
  double _8;

  :
  in.0_1 = in;
  in.1_2 = in;
  _3 = in.0_1 * in.1_2;
  X[1] = _3;
  i_13 = 2;
  goto ;

  :
  _4 = i_9 + -1;
  _5 = X[_4];
  _6 = X[1];
  _7 = _5 * _6;
  X[i_9] = _7;
  i_15 = i_9 + 1;

  :
  # i_9 = PHI 
  if (i_9 <= 8)
goto ;
  else
goto ;

  :
  _8 = X[5];
  Write (_8);
  return;

}


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."


Fix PR bootstrap/71435

2016-06-18 Thread Eric Botcazou
This fixes a bootstrap comparison failure on SPARC/Linux introduced by the 
reload change made for PR target/60040, which added calls to finish_spills 
without previously calling select_reload_regs.  This left finish_spills work 
on uninitialized data, hence the comparison failure.

The patch changes the new calls to pass 0 to finish_spills so that global 
reallocation is not done for them, but only after select_reload_regs is called 
in a next reload round.  In practice this should have a fairly limited impact 
and indeed there is no change in code generation at -O2 on SPARC for a build 
of the compiler proper without the special option of PR bootstrap/71435.

Bootstrapped/regtested on SPARC/Solaris and Linux, applied on the mainline.


2016-06-18  Eric Botcazou  

PR bootstrap/71435
* reload1.c (reload): Pass 0 to finish_spills when called because
update_eliminables_and_spill returns true and remove did_spill.
(finish_spills): Adjust comment and document GLOBAL parameter.

-- 
Eric BotcazouIndex: reload1.c
===
--- reload1.c	(revision 237526)
+++ reload1.c	(working copy)
@@ -897,7 +897,6 @@ reload (rtx_insn *first, int global)
   for (;;)
 {
   int something_changed;
-  int did_spill;
   HOST_WIDE_INT starting_frame_size;
 
   starting_frame_size = get_frame_size ();
@@ -982,7 +981,7 @@ reload (rtx_insn *first, int global)
   if (something_was_spilled || starting_frame_size != get_frame_size ())
 	{
 	  if (update_eliminables_and_spill ())
-	finish_spills (global);
+	finish_spills (0);
 	  continue;
 	}
 
@@ -1001,8 +1000,6 @@ reload (rtx_insn *first, int global)
 	   is used.  */
 	CLEAR_REG_SET (&spilled_pseudos);
 
-  did_spill = 0;
-
   something_changed = 0;
 
   /* If we allocated any new memory locations, make another pass
@@ -1019,7 +1016,7 @@ reload (rtx_insn *first, int global)
 
   if (update_eliminables_and_spill ())
 	{
-	  did_spill = 1;
+	  finish_spills (0);
 	  something_changed = 1;
 	}
   else
@@ -1027,11 +1024,10 @@ reload (rtx_insn *first, int global)
 	  select_reload_regs ();
 	  if (failure)
 	goto failed;
+	  if (insns_need_reload)
+	something_changed |= finish_spills (global);
 	}
 
-  if (insns_need_reload != 0 || did_spill)
-	something_changed |= finish_spills (global);
-
   if (! something_changed)
 	break;
 
@@ -4281,10 +4277,13 @@ spill_hard_reg (unsigned int regno, int
   SET_REGNO_REG_SET (&spilled_pseudos, i);
 }
 
-/* After find_reload_regs has been run for all insn that need reloads,
-   and/or spill_hard_regs was called, this function is used to actually
-   spill pseudo registers and try to reallocate them.  It also sets up the
-   spill_regs array for use by choose_reload_regs.  */
+/* After spill_hard_reg was called and/or find_reload_regs was run for all
+   insns that need reloads, this function is used to actually spill pseudo
+   registers and try to reallocate them.  It also sets up the spill_regs
+   array for use by choose_reload_regs.
+
+   GLOBAL nonzero means we should attempt to reallocate any pseudo registers
+   that we displace from hard registers.  */
 
 static int
 finish_spills (int global)


[BUILDROBOT] Selftest failed for rs6000-ibm-aix4.3

2016-06-18 Thread Jan-Benedict Glaw
Hi David, Segher, Aldy!

Davids new selftest code found something for the rs6000-ibm-aix4.3
target, maybe you're interested:

/home/jbglaw/src/toolchain/build/./gcc/xgcc 
-B/home/jbglaw/src/toolchain/build/./gcc/ -xc -S -c /dev/null -fself-test
: internal compiler error: in altivec_init_builtins, at 
config/rs6000/rs6000.c:16675
0xe0ed04 altivec_init_builtins
../../gcc/gcc/config/rs6000/rs6000.c:16675
0xe0ed04 rs6000_init_builtins
../../gcc/gcc/config/rs6000/rs6000.c:15935
0x643c7e c_define_builtins
../../gcc/gcc/c-family/c-common.c:5208
0x643c7e c_common_nodes_and_builtins()
../../gcc/gcc/c-family/c-common.c:5656
0x590c49 c_init_decl_processing()
../../gcc/gcc/c/c-decl.c:3934
0x5dd7e8 c_objc_common_init()
../../gcc/gcc/c/c-objc-common.c:58
0x580cc1 lang_dependent_init
../../gcc/gcc/toplev.c:1757
0x580cc1 do_compile
../../gcc/gcc/toplev.c:1975
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
make[1]: *** [s-selftest] Error 1



See eg. build
http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=572874,
which is as simple as .../configure --enable-languages=c,c++
--target=rs6000-ibm-aix4.3 --without-headers --disable-threads

MfG, JBG

-- 
  Jan-Benedict Glaw  jbg...@lug-owl.de  +49-172-7608481
Signature of:  Alles sollte so einfach wie möglich gemacht sein.
the second  :  Aber nicht einfacher.  (Einstein)


signature.asc
Description: Digital signature


MAINTAINERS (Write After Approval): Add myself

2016-06-18 Thread Senthil Kumar Selvaraj

Added myself to MAINTAINERS (Write After Approval).

Regards
Senthil

Index: ChangeLog
===
--- ChangeLog   (revision 237571)
+++ ChangeLog   (working copy)
@@ -1,3 +1,7 @@
+2016-06-18  Senthil Kumar Selvaraj  
+
+   * MAINTAINERS (Write After Approval): Add myself.
+
 2016-06-16  Michael Collison  
 
* MAINTAINERS (Write After Approval): Add myself.
Index: MAINTAINERS
===
--- MAINTAINERS (revision 237571)
+++ MAINTAINERS (working copy)
@@ -569,6 +569,7 @@
 Martin Sebor   
 Dodji Seketeli 
 Svein Seldal   
+Senthil Kumar Selvaraj 

 Thiemo Seufer  
 Bill Seurer
 Marcus Shawcroft   


Re: [BUILDROBOT] Selftest failed for rs6000-ibm-aix4.3

2016-06-18 Thread David Malcolm
On Sat, 2016-06-18 at 15:06 +0200, Jan-Benedict Glaw wrote:
> Hi David, Segher, Aldy!
> 
> Davids new selftest code found something for the rs6000-ibm-aix4.3
> target, maybe you're interested:
> 
> /home/jbglaw/src/toolchain/build/./gcc/xgcc 
> -B/home/jbglaw/src/toolchain/build/./gcc/ -xc -S -c /dev/null -fself
> -test
> : internal compiler error: in altivec_init_builtins, at
> config/rs6000/rs6000.c:16675
> 0xe0ed04 altivec_init_builtins
> ../../gcc/gcc/config/rs6000/rs6000.c:16675
> 0xe0ed04 rs6000_init_builtins
> ../../gcc/gcc/config/rs6000/rs6000.c:15935
> 0x643c7e c_define_builtins
> ../../gcc/gcc/c-family/c-common.c:5208
> 0x643c7e c_common_nodes_and_builtins()
> ../../gcc/gcc/c-family/c-common.c:5656
> 0x590c49 c_init_decl_processing()
> ../../gcc/gcc/c/c-decl.c:3934
> 0x5dd7e8 c_objc_common_init()
> ../../gcc/gcc/c/c-objc-common.c:58
> 0x580cc1 lang_dependent_init
> ../../gcc/gcc/toplev.c:1757
> 0x580cc1 do_compile
> ../../gcc/gcc/toplev.c:1975
> Please submit a full bug report,
> with preprocessed source if appropriate.
> Please include the complete backtrace with any bug report.
> See  for instructions.
> make[1]: *** [s-selftest] Error 1
> 
> 
> 
> See eg. build
> http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=572874
> ,
> which is as simple as .../configure --enable-languages=c,c++
> --target=rs6000-ibm-aix4.3 --without-headers --disable-threads
> 

I looks like PR target/71375 ("Failure on startup on rs6000-ibm
-aix{4.3|5.1.0}"), which I believe is a pre-existing issue, and
unrelated to -fself-test.

Dave


Re: [PATCH] C++ FE: Show both locations in string literal concatenation error

2016-06-18 Thread Jason Merrill
OK.

Jason


[committed] Remove unused TARGET_LONG_PIC_PCREL_CALL define from pa.h

2016-06-18 Thread John David Anglin
This fixes oversight in previous change.  TARGET_LONG_PIC_PCREL_CALL is no 
longer used
and can be removed.

Dave
--
John David Anglin   dave.ang...@bell.net


2018-06-18  John David Anglin  

* config/pa/pa.h (TARGET_LONG_PIC_PCREL_CALL): Remove.

Index: config/pa/pa.h
===
--- config/pa/pa.h  (revision 237197)
+++ config/pa/pa.h  (working copy)
@@ -93,12 +93,6 @@
detect the sequence as a pc-relative call.  */
 #define TARGET_LONG_PIC_SDIFF_CALL (!TARGET_GAS && TARGET_HPUX)
 
-/* Define to a C expression evaluating to true to use long PIC
-   pc-relative calls.  Long PIC pc-relative calls are only used with
-   GAS.  Currently, they are usable for calls which bind local to a
-   module but not for external calls.  */
-#define TARGET_LONG_PIC_PCREL_CALL 0
-
 /* Define to a C expression evaluating to true to use SOM secondary
definition symbols for weak support.  Linker support for secondary
definition symbols is buggy prior to HP-UX 11.X.  */


[committed] Build valid PA-RISC function pointer for fixup in __canonicalize_funcptr_for_compare

2016-06-18 Thread John David Anglin
The attached change is preparation for a patch to optimize indirect calls.  For 
this, we need to a
valid function pointer for fixup in __canonicalize_funcptr_for_compare.  The 
least-significant two
bits of the pointer should have the value 2, not 3, when the pointer points to 
a function descriptor.

Tested on hppa-unknown-linux-gnu and committed to trunk.

Dave
--
John David Anglin   dave.ang...@bell.net


2016-06-18  John David Anglin  

* config/pa/fptr.c (__canonicalize_funcptr_for_compare): Don't set
least-significant bit in function pointer for fixup.

Index: config/pa/fptr.c
===
--- config/pa/fptr.c(revision 237565)
+++ config/pa/fptr.c(working copy)
@@ -113,7 +113,7 @@
   /* Build a plabel for an indirect call to _dl_fixup.  */
   fixup_plabel[0] = (unsigned int) iptr + 8;   /* address of fixup */
   fixup_plabel[1] = got[-1];   /* ltp for fixup */
-  fixup = (fixup_t) ((int) fixup_plabel | 3);
+  fixup = (fixup_t) ((int) fixup_plabel | 2);
 
   /* Call fixup to resolve the function address.  got[1] contains the
  link_map pointer and plabel[1] the relocation offset.  */


[patch, libgfortran] PR48552/48925 Invalid spaces in complex/code cleanup

2016-06-18 Thread Jerry DeLisle
Greetings all,

This is a major rework of floating point write routines. Most of the existing
critical code is retained. Much of the code is reorganized.

The problem with complex is that it is writing two floats with formatting.
Previously write_block, which does the actual output, was buried at the bottom
of all the functions. We do not know how wide the significant result is until
that point. These means we had no way to calculate how many blanks to transmit
first to right justify until we already sent the digits.

This patch modifies this by 1) moving the buffer creations up to the higher
routines, 2) formatting a string, 3) getting the final lengths, and 4)
calculating the leading blanks needed. Once this is determined, the complex
value can sent out correctly.

Several helper functions are created. The most significant is probably
write_float_string. It takes a simple string from all the other lower level
routines, and uses write_block. All the previous kind=4 character internal  unit
code spread throughout the previous output_float routines is now done with about
5 lines of code.

Regression tested on x86_64. Test cases modified for the new format of default
complex.
(changelog for test cases will be done of course)

OK for trunk?

Regards,

Jerry

2016-06-18  Jerry DeLisle  

PR libgfortran/48852
* io/write.c: Cleaned up whitespace.
(write_d, write_e, write_f, write_es, write_en): Use new helper function
write_float_0. (write_float_0): New helper function.
(get_precision, select_buffer, select_string, write_float_string): New
helper functions used in remaining float writing functions. Helper 
function
write_float_string now contains code for writing to kind=4 character
internal units.
(write_real): Modified to establish working buffers at this level and to
use new helper functions.
(write_real_g0): Likewise modified.
(write_complex): Likewise modified. Gets both float strings before
output so that final lengths can be determined which allows right
justifying the complex number with no intervening spaces.
* io/write_float.def (build_float_string): Renamed from previously
output_float, modified to use buffers passed in from higher functions,
builds a null terminated string of the floating point value. Character
kind=4 code eliminated.
(write_infnan): Likewise modified to use incoming buffers and eliminate
kind=4 related code.
(OUTPUT_FLOAT_FMT_G): Deleted. Functionality moved into FORMAT_FLOAT.
(FORMAT_FLOAT): Renamed macro from WRITE_FLOAT. Use build_float_string.
(get_float_string): Renamed from write_float, uses FORMAT_FLOAT macro.
Buffer allocation removed, now at higher level.
diff --git a/gcc/testsuite/gfortran.dg/char4_iunit_1.f03 b/gcc/testsuite/gfortran.dg/char4_iunit_1.f03
index f02cc1a7..7d388ad9 100644
--- a/gcc/testsuite/gfortran.dg/char4_iunit_1.f03
+++ b/gcc/testsuite/gfortran.dg/char4_iunit_1.f03
@@ -30,5 +30,5 @@ program char4_iunit_1
   write(string, '(10x,f3.1,3x,f9.1)') nan, inf
   if (string .ne. 4_"  NaNInfinity ") call abort
   write(string, *) (1.2, 3.4 )
-  if (string .ne. 4_" (  1.2005,  3.4010)  ") call abort
+  if (string .ne. 4_" (1.2005,3.4010)") call abort
 end program char4_iunit_1
diff --git a/gcc/testsuite/gfortran.dg/f2003_io_5.f03 b/gcc/testsuite/gfortran.dg/f2003_io_5.f03
index c064e0cf..34b8adbb 100644
--- a/gcc/testsuite/gfortran.dg/f2003_io_5.f03
+++ b/gcc/testsuite/gfortran.dg/f2003_io_5.f03
@@ -18,9 +18,9 @@ close(99, status="delete")
 
 c = (3.123,4.456)
 write(complex,*,decimal="comma") c
-if (complex.ne." (  3,1221;  4,45599985)") call abort
+if (complex.ne." (3,1221;4,45599985)") call abort
 c = (0.0, 0.0)
 read(complex,*,decimal="comma") c
-if (complex.ne." (  3,1221;  4,45599985)") call abort
+if (complex.ne." (3,1221;4,45599985)") call abort
 
 end
diff --git a/gcc/testsuite/gfortran.dg/real_const_3.f90 b/gcc/testsuite/gfortran.dg/real_const_3.f90
index e4b5de7e..c70591d3 100644
--- a/gcc/testsuite/gfortran.dg/real_const_3.f90
+++ b/gcc/testsuite/gfortran.dg/real_const_3.f90
@@ -42,15 +42,14 @@ program main
   if (trim(adjustl(str)) .ne. 'NaN') call abort
 
   write(str,*) z
-  if (trim(adjustl(str)) .ne. '( NaN, NaN)') call abort
+  if (trim(adjustl(str)) .ne. '(NaN,NaN)') call abort
 
   write(str,*) z2
-  if (trim(adjustl(str)) .ne. '( NaN, NaN)') call abort
+  if (trim(adjustl(str)) .ne. '(NaN,NaN)') call abort
 
   write(str,*) z3
-  if (trim(adjustl(str)) .ne. '(Infinity,   -Infinity)') call abort
+  if (trim(adjustl(str)) .ne. '(Inf,-Inf)') call abort
 
   write(str,*) z4
-  if (trim(adjustl(str)) .ne. '(  0., -0.)') call abort
-
+  if (trim(adjustl(str)) .ne. 

[PATCH] PR52665 do not let .ident confuse assembler scan tests

2016-06-18 Thread Bernhard Reutner-Fischer
A branch with a name matching scan-assembler pattern triggers
inappropriate FAIL.

E.g. branch fixups-testsuite and
- gcc.target/i386/pr65871-?.c (scan-assembler-not "test")
- gcc.target/i386/pr41442.c (scan-assembler-times "test|cmp" 2)
etc.

This is a recurring problem as can be seen by some -fno-ident additions
by commits from e.g. Michael Meissner over the years: builtins-58.c,
powerpc/pr46728-?.c

The patch below adds -fno-ident if a testcase contains one of
scan-assembler, scan-assembler-not or scan-assembler-times.

Regression tested on x86_64-unknown-linux on a fixups-testsuite branch
where it fixes several false FAILs without regressions.

gcc/testsuite/ChangeLog

2016-06-18  Bernhard Reutner-Fischer  

PR testsuite/52665
* lib/gcc-dg.exp (gcc-dg-test-1): Iterate over _required_options.
* lib/target-supports.exp (scan-assembler_required_options,
scan-assembler-not_required_options,
scan-assembler-times_required_options): Add -fno-ident.
* lib/scanasm.exp (scan-assembler-times): Fix error message.
* c-c++-common/ident-0a.c: New test.
* c-c++-common/ident-0b.c: New test.
* c-c++-common/ident-1a.c: New test.
* c-c++-common/ident-1b.c: New test.
* c-c++-common/ident-2a.c: New test.
* c-c++-common/ident-2b.c: New test.

Ok for trunk?

PS: proc force_conventional_output_for would be a bit misnomed by this,
not sure if it should be renamed to maybe set_required_options_for or
the like?

Signed-off-by: Bernhard Reutner-Fischer 
Cc: Mike Stump 
Cc: Rainer Orth 
Signed-off-by: Bernhard Reutner-Fischer 
---
 gcc/testsuite/c-c++-common/ident-0a.c |  6 ++
 gcc/testsuite/c-c++-common/ident-0b.c | 10 ++
 gcc/testsuite/c-c++-common/ident-1a.c |  8 
 gcc/testsuite/c-c++-common/ident-1b.c |  7 +++
 gcc/testsuite/c-c++-common/ident-2a.c |  6 ++
 gcc/testsuite/c-c++-common/ident-2b.c |  7 +++
 gcc/testsuite/lib/gcc-dg.exp  |  8 +---
 gcc/testsuite/lib/scanasm.exp |  4 ++--
 gcc/testsuite/lib/target-supports.exp |  6 ++
 9 files changed, 57 insertions(+), 5 deletions(-)
 create mode 100644 gcc/testsuite/c-c++-common/ident-0a.c
 create mode 100644 gcc/testsuite/c-c++-common/ident-0b.c
 create mode 100644 gcc/testsuite/c-c++-common/ident-1a.c
 create mode 100644 gcc/testsuite/c-c++-common/ident-1b.c
 create mode 100644 gcc/testsuite/c-c++-common/ident-2a.c
 create mode 100644 gcc/testsuite/c-c++-common/ident-2b.c

diff --git a/gcc/testsuite/c-c++-common/ident-0a.c 
b/gcc/testsuite/c-c++-common/ident-0a.c
new file mode 100644
index 000..900d206
--- /dev/null
+++ b/gcc/testsuite/c-c++-common/ident-0a.c
@@ -0,0 +1,6 @@
+/* PR testsuite/52665
+ * Make sure scan-assembler-not turns off .ident  */
+/* { dg-do compile } */
+int i;
+
+/* { dg-final { scan-assembler-not "GCC: " } } */
diff --git a/gcc/testsuite/c-c++-common/ident-0b.c 
b/gcc/testsuite/c-c++-common/ident-0b.c
new file mode 100644
index 000..e08126d
--- /dev/null
+++ b/gcc/testsuite/c-c++-common/ident-0b.c
@@ -0,0 +1,10 @@
+/* PR testsuite/52665
+ * Make sure scan-assembler-not turns off .ident unless -fident in testcase */
+/* { dg-do compile } */
+/* { dg-options "-fident" } */
+int i;
+
+/* { dg-final { scan-assembler-not "GCC: " { xfail *-*-* } } } */
+/* The testsuite saw scan-assembler-not and turned off .ident so the above
+ * has to fail for proper operation since the testsuite itself forced
+ * -fident on again.  */
diff --git a/gcc/testsuite/c-c++-common/ident-1a.c 
b/gcc/testsuite/c-c++-common/ident-1a.c
new file mode 100644
index 000..867ee43
--- /dev/null
+++ b/gcc/testsuite/c-c++-common/ident-1a.c
@@ -0,0 +1,8 @@
+/* PR testsuite/52665
+ * Make sure scan-assembler turns off .ident  */
+/* { dg-do compile } */
+int i;
+
+/* { dg-final { scan-assembler "GCC: " { xfail *-*-* } } } */
+/* The testsuite saw scan-assembler and turned off .ident so the above
+ * has to fail for proper operation.  */
diff --git a/gcc/testsuite/c-c++-common/ident-1b.c 
b/gcc/testsuite/c-c++-common/ident-1b.c
new file mode 100644
index 000..2431086
--- /dev/null
+++ b/gcc/testsuite/c-c++-common/ident-1b.c
@@ -0,0 +1,7 @@
+/* PR testsuite/52665
+ * Make sure scan-assembler turns off .ident unless -fident in testcase */
+/* { dg-do compile } */
+/* { dg-options "-fident" } */
+int i;
+
+/* { dg-final { scan-assembler "GCC: " } } */
diff --git a/gcc/testsuite/c-c++-common/ident-2a.c 
b/gcc/testsuite/c-c++-common/ident-2a.c
new file mode 100644
index 000..131b867
--- /dev/null
+++ b/gcc/testsuite/c-c++-common/ident-2a.c
@@ -0,0 +1,6 @@
+/* PR testsuite/52665
+ * Make sure scan-assembler-times turns off .ident  */
+/* { dg-do compile } */
+int i;
+
+/* { dg-final { scan-assembler-times "GCC: " 0 } } */ /* internal test, keep 
-times 0 ! */
diff --git a/gcc/testsuite/c-c++-common/ident-2b.c 
b/gcc/testsuite/c-c++-common/ident-2b.c
new file mode 100644
index 000..a21e25f
--- /dev/null
+++ b/gcc/testsuite/c-c++-

Re: [PATCH] Derive interface buffers from max name length

2016-06-18 Thread Bernhard Reutner-Fischer
On December 3, 2015 10:46:09 AM GMT+01:00, Janne Blomqvist 
 wrote:
>On Tue, Dec 1, 2015 at 6:51 PM, Bernhard Reutner-Fischer
> wrote:
>> On 1 December 2015 at 15:52, Janne Blomqvist
> wrote:
>>> On Tue, Dec 1, 2015 at 2:54 PM, Bernhard Reutner-Fischer
>>>  wrote:
 These three function used a hardcoded buffer of 100 but would be
>better
 off to base off GFC_MAX_SYMBOL_LEN which denotes the maximum length
>of a
 name in any of our supported standards (63 as of f2003 ff.).
>>>
>>> Please use xasprintf() instead (and free the result, or course). One
>>> of my backburner projects is to get rid of these static symbol
>>> buffers, and use dynamic buffers (or the symbol table) instead. We
>>> IIRC already have some ugly hacks by using hashing to get around
>>> GFC_MAX_SYMBOL_LEN when handling mangled symbols. Your patch doesn't
>>> make the situation worse per se, but if you're going to fix it, lets
>>> do it properly.
>>
>> I see.
>>
>> /scratch/src/gcc-6.0.mine/gcc/fortran$ git grep
>> "^[[:space:]]*char[[:space:]][[:space:]]*[^[;[:space:]]*\[" | wc -l
>> 142
>> /scratch/src/gcc-6.0.mine/gcc/fortran$ git grep "xasprintf" | wc -l
>> 32
>
>Yes, that's why it's on the TODO-list rather than on the DONE-list. :)
>
>> What about memory fragmentation when switching to heap-based
>allocation?
>> Or is there consensus that these are in the noise compared to other
>> parts of the compiler?
>
>Heap fragmentation is an issue, yes. I'm not sure it's that
>performance-critical, but I don't think there is any consensus. I just
>want to avoid ugly hacks like symbol hashing to fit within some fixed
>buffer. Perhaps an good compromise would be something like std::string
>with small string optimization, but as you have seen there is some
>resistance to C++. But this is more relevant for mangled symbols, so
>GFC_MAX_MANGLED_SYMBOL_LEN is more relevant here, and there's only a
>few of them left. So, well, if you're sure that mangled symbols are
>never copied into the buffers your patch modifies, please consider
>your original patch Ok as well. Whichever you prefer.
>
>Performance-wise I think a bigger benefit would be to use the symbol
>table more and then e.g. be able to do pointer comparisons rather than
>strcmp(). But that is certainly much more work.

Hm, worth a look indeed since that would certainly be a step in the right 
direction.

>
>> BTW:
>> $ git grep APO
>> io.c:  static const char *delim[] = { "APOSTROPHE", "QUOTE", "NONE",
>NULL };
>> io.c:  static const char *delim[] = { "APOSTROPHE", "QUOTE", "NONE",
>NULL };
>
>? What are you saying?

delim is duplicated, we should remove one instance.
thanks,



Re: [PATCH] Use gfc_add_*_component defines where appropriate

2016-06-18 Thread Bernhard Reutner-Fischer
Ping.

On December 1, 2015 1:54:58 PM GMT+01:00, Bernhard Reutner-Fischer 
 wrote:
>A couple of places used gfc_add_component_ref(expr, "string") instead
>of
>the defines from gfortran.h
>
>Regstrapped without regressions, ok for trunk stage3 now / next stage1?
>
>gcc/fortran/ChangeLog
>
>2015-11-29  Bernhard Reutner-Fischer  
>
> * class.c (gfc_add_class_array_ref): Call gfc_add_data_component()
>instead of gfc_add_component_ref().
>   (gfc_get_len_component): Call gfc_add_len_component() instead of
>gfc_add_component_ref().
>* trans-intrinsic.c (gfc_conv_intrinsic_loc): Call
>gfc_add_data_component() instead of gfc_add_component_ref().
>* trans.c (gfc_add_finalizer_call): Call
>gfc_add_final_component() and gfc_add_size_component() instead
>of gfc_add_component_ref.
>
>Signed-off-by: Bernhard Reutner-Fischer 
>---
> gcc/fortran/class.c   | 4 ++--
> gcc/fortran/trans-intrinsic.c | 2 +-
> gcc/fortran/trans.c   | 4 ++--
> 3 files changed, 5 insertions(+), 5 deletions(-)
>
>diff --git a/gcc/fortran/class.c b/gcc/fortran/class.c
>index 8b49ae9..027cb89 100644
>--- a/gcc/fortran/class.c
>+++ b/gcc/fortran/class.c
>@@ -258,7 +258,7 @@ gfc_add_class_array_ref (gfc_expr *e)
>   int rank = CLASS_DATA (e)->as->rank;
>   gfc_array_spec *as = CLASS_DATA (e)->as;
>   gfc_ref *ref = NULL;
>-  gfc_add_component_ref (e, "_data");
>+  gfc_add_data_component (e);
>   e->rank = rank;
>   for (ref = e->ref; ref; ref = ref->next)
> if (!ref->next)
>@@ -584,7 +584,7 @@ gfc_get_len_component (gfc_expr *e)
>   ref = ref->next;
> }
>   /* And replace if with a ref to the _len component.  */
>-  gfc_add_component_ref (ptr, "_len");
>+  gfc_add_len_component (ptr);
>   return ptr;
> }
> 
>diff --git a/gcc/fortran/trans-intrinsic.c
>b/gcc/fortran/trans-intrinsic.c
>index 1dabc26..2ef0709 100644
>--- a/gcc/fortran/trans-intrinsic.c
>+++ b/gcc/fortran/trans-intrinsic.c
>@@ -7112,7 +7112,7 @@ gfc_conv_intrinsic_loc (gfc_se * se, gfc_expr *
>expr)
>   if (arg_expr->rank == 0)
> {
>   if (arg_expr->ts.type == BT_CLASS)
>-  gfc_add_component_ref (arg_expr, "_data");
>+  gfc_add_data_component (arg_expr);
>   gfc_conv_expr_reference (se, arg_expr);
> }
>   else
>diff --git a/gcc/fortran/trans.c b/gcc/fortran/trans.c
>index 2a91c35..14dad0f 100644
>--- a/gcc/fortran/trans.c
>+++ b/gcc/fortran/trans.c
>@@ -1132,11 +1132,11 @@ gfc_add_finalizer_call (stmtblock_t *block,
>gfc_expr *expr2)
> 
>   final_expr = gfc_copy_expr (expr);
>   gfc_add_vptr_component (final_expr);
>-  gfc_add_component_ref (final_expr, "_final");
>+  gfc_add_final_component (final_expr);
> 
>   elem_size = gfc_copy_expr (expr);
>   gfc_add_vptr_component (elem_size);
>-  gfc_add_component_ref (elem_size, "_size");
>+  gfc_add_size_component (elem_size);
> }
> 
>   gcc_assert (final_expr->expr_type == EXPR_VARIABLE);




[PATCH, fortran, v4] Use Levenshtein spelling suggestions in Fortran FE

2016-06-18 Thread Bernhard Reutner-Fischer
Hi,

Ok for trunk?

Changes for v4 -> v3:

- rebased
- Use 4 argument levenshtein_distance() to save multiple strlen(typo)
  calls as suggested by dmalcolm

Changes for v2 -> v3:

- rebased

Changes for v1 -> v2:

- subroutines using interfaces
- keyword arguments (named parameters)

Rewrite C++ autovec in plain C.
Factor out levenshtein distance handling into a commonly used
gfc_closest_fuzzy_match().

gcc/fortran/ChangeLog

2015-12-27  Bernhard Reutner-Fischer  

* gfortran.h (gfc_lookup_function_fuzzy): New declaration.
(gfc_closest_fuzzy_match): New declaration.
(vec_push): New definition.
* misc.c (gfc_closest_fuzzy_match): New definition.
* resolve.c: Include spellcheck.h.
(lookup_function_fuzzy_find_candidates): New static function.
(lookup_uop_fuzzy_find_candidates): Likewise.
(lookup_uop_fuzzy): Likewise.
(resolve_operator) : Call lookup_uop_fuzzy.
(gfc_lookup_function_fuzzy): New definition.
(resolve_unknown_f): Call gfc_lookup_function_fuzzy.
* interface.c (check_interface0): Likewise.
(lookup_arg_fuzzy_find_candidates): New static function.
(lookup_arg_fuzzy ): Likewise.
(compare_actual_formal): Call lookup_arg_fuzzy.
* symbol.c: Include spellcheck.h.
(lookup_symbol_fuzzy_find_candidates): New static function.
(lookup_symbol_fuzzy): Likewise.
(gfc_set_default_type): Call lookup_symbol_fuzzy.
(lookup_component_fuzzy_find_candidates): New static function.
(lookup_component_fuzzy): Likewise.
(gfc_find_component): Call lookup_component_fuzzy.

gcc/testsuite/ChangeLog

2015-12-27  Bernhard Reutner-Fischer  

* gfortran.dg/spellcheck-operator.f90: New testcase.
* gfortran.dg/spellcheck-procedure_1.f90: New testcase.
* gfortran.dg/spellcheck-procedure_2.f90: New testcase.
* gfortran.dg/spellcheck-structure.f90: New testcase.
* gfortran.dg/spellcheck-parameter.f90: New testcase.

---

David Malcolm's nice Levenshtein distance spelling check helpers
were used in some parts of other frontends. This proposed patch adds
some spelling corrections to the fortran frontend.

Suggestions are printed if we can find a suitable name, currently
perusing a very simple cutoff factor:
/* If more than half of the letters were misspelled, the suggestion is
   likely to be meaningless.  */
cutoff = MAX (strlen (typo), strlen (best_guess)) / 2;
which effectively skips names with less than 4 characters.
For e.g. structures, one could try to be much smarter in an attempt to
also provide suggestions for single-letter members/components.

This patch covers (at least partly):
- user-defined operators
- structures (types and their components)
- functions
- symbols (variables)

If anybody has a testcase where a spelling-suggestion would make sense
then please pass it along so we maybe can add support for GCC-7.

Signed-off-by: Bernhard Reutner-Fischer 
---
 gcc/fortran/gfortran.h |  12 +++
 gcc/fortran/interface.c|  72 +--
 gcc/fortran/misc.c |  41 +
 gcc/fortran/resolve.c  | 100 -
 gcc/fortran/symbol.c   |  86 +-
 gcc/testsuite/gfortran.dg/spellcheck-operator.f90  |  30 +++
 gcc/testsuite/gfortran.dg/spellcheck-parameter.f90 |  15 
 .../gfortran.dg/spellcheck-procedure_1.f90 |  41 +
 .../gfortran.dg/spellcheck-procedure_2.f90 |  35 
 gcc/testsuite/gfortran.dg/spellcheck-structure.f90 |  35 
 10 files changed, 450 insertions(+), 17 deletions(-)
 create mode 100644 gcc/testsuite/gfortran.dg/spellcheck-operator.f90
 create mode 100644 gcc/testsuite/gfortran.dg/spellcheck-parameter.f90
 create mode 100644 gcc/testsuite/gfortran.dg/spellcheck-procedure_1.f90
 create mode 100644 gcc/testsuite/gfortran.dg/spellcheck-procedure_2.f90
 create mode 100644 gcc/testsuite/gfortran.dg/spellcheck-structure.f90

diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h
index 0bb71cb..5d43c2d 100644
--- a/gcc/fortran/gfortran.h
+++ b/gcc/fortran/gfortran.h
@@ -2682,6 +2682,17 @@ void gfc_done_2 (void);
 
 int get_c_kind (const char *, CInteropKind_t *);
 
+const char *gfc_closest_fuzzy_match (const char *, char **);
+static inline void
+vec_push (char **&optr, size_t &osz, const char *elt)
+{
+  /* {auto,}vec.safe_push () replacement.  Don't ask..  */
+  // if (strlen (elt) < 4) return; premature optimization: eliminated by cutoff
+  optr = XRESIZEVEC (char *, optr, osz + 2);
+  optr[osz] = CONST_CAST (char *, elt);
+  optr[++osz] = NULL;
+}
+
 /* options.c */
 unsigned int gfc_option_lang_mask (void);
 void gfc_init_options_struct (struct gcc_options *);
@@ -3103,6 +3114,7 @@ bool gfc_type_is_extensible (gfc_symbol *);
 bool gfc_resolve_intrinsic (gfc_symbol *, locus *);
 bool gfc_expli

Re: [PATCH] Commentary typo fix for gfc_typenode_for_spec()

2016-06-18 Thread Bernhard Reutner-Fischer
On Tue, Dec 01, 2015 at 08:00:15AM -0800, Steve Kargl wrote:
> On Tue, Dec 01, 2015 at 01:55:00PM +0100, Bernhard Reutner-Fischer wrote:
> > Regstrapped without regressions, ok for trunk stage3 now / next stage1?
> > 
> > gcc/fortran/ChangeLog
> > 
> > 2015-11-29  Bernhard Reutner-Fischer  
> > 
> > * trans-types.c (gfc_typenode_for_spec): Commentary typo fix.
> > 
> 
> Patches to fix typographical errors in comments are pre-approved.

Ack.

This one applied as r237575

Thanks!


[PATCH] c/71552 - Confusing error for incorrect struct initialization

2016-06-18 Thread Martin Sebor

The attached patch slightly changes the order in which initializers
are checked for type compatibility to issue the same error for static
initializers of incompatible types as for automatic objects, rather
than rejecting the former for their lack of constness first.

I originally closed the bug as WontFix but a better test case sent
by the submitter to gcc-help in a subsequent discussion convinced
me that there is an improvement to be made here:

  https://gcc.gnu.org/ml/gcc-help/2016-06/msg00057.html

Martin
PR c/71552 - Confusing error for incorrect struct initialization

gcc/c/ChangeLog:
2016-06-18  Martin Sebor  

	PR c/71552
	* c-typeck.c (output_init_element): Diagnose incompatible types
	before non-constant initializers.

gcc/testsuite/ChangeLog:
2016-06-18  Martin Sebor  

	PR c/71552
	* gcc.dg/init-bad-9.c: New test.

Index: gcc/c/c-typeck.c
===
--- gcc/c/c-typeck.c	(revision 237461)
+++ gcc/c/c-typeck.c	(working copy)
@@ -8760,6 +8760,22 @@ output_init_element (location_t loc, tre
   if (!maybe_const)
 constructor_nonconst = 1;
 
+  /* Digest the initializer and issue any errors about incompatible
+ types before issuing errors about non-constant initializers.  */
+  tree new_value = value;
+  if (semantic_type)
+new_value = build1 (EXCESS_PRECISION_EXPR, semantic_type, value);
+  new_value = digest_init (loc, type, new_value, origtype, npc, strict_string,
+			   require_constant_value);
+  if (new_value == error_mark_node)
+{
+  constructor_erroneous = 1;
+  return;
+}
+  if (require_constant_value || require_constant_elements)
+constant_expression_warning (new_value);
+
+  /* Proceed to check the constness of the original initializer.  */
   if (!initializer_constant_valid_p (value, TREE_TYPE (value)))
 {
   if (require_constant_value)
@@ -8804,17 +8820,8 @@ output_init_element (location_t loc, tre
 		  || DECL_CHAIN (field)
 return;
 
-  if (semantic_type)
-value = build1 (EXCESS_PRECISION_EXPR, semantic_type, value);
-  value = digest_init (loc, type, value, origtype, npc, strict_string,
-		   require_constant_value);
-  if (value == error_mark_node)
-{
-  constructor_erroneous = 1;
-  return;
-}
-  if (require_constant_value || require_constant_elements)
-constant_expression_warning (value);
+  /* Finally, set VALUE to the initializer value digested above.  */
+  value = new_value;
 
   /* If this element doesn't come next in sequence,
  put it on constructor_pending_elts.  */
Index: gcc/testsuite/gcc.dg/init-bad-9.c
===
--- gcc/testsuite/gcc.dg/init-bad-9.c	(revision 0)
+++ gcc/testsuite/gcc.dg/init-bad-9.c	(working copy)
@@ -0,0 +1,12 @@
+/* PR c/71552 - Confusing error for incorrect struct initialization */
+/* { dg-do compile } */
+
+struct A { void *p; };
+struct B { struct A *p; };
+struct A a;
+
+/* Verify that the initializer is diagnosed for its incompatibility
+   with the type of the object being initialized, not for its lack
+   of constness (which is a lesser problem).  */
+struct B b = { a };   /* { dg-error "incompatible types when initializing" } */
+struct B *p = a;  /* { dg-error "incompatible types when initializing" } */


Re: [PATCH] PR52665 do not let .ident confuse assembler scan tests

2016-06-18 Thread Hans-Peter Nilsson
On Sat, 18 Jun 2016, Bernhard Reutner-Fischer wrote:
> A branch with a name matching scan-assembler pattern triggers
> inappropriate FAIL.
>
> E.g. branch fixups-testsuite and
> - gcc.target/i386/pr65871-?.c (scan-assembler-not "test")
> - gcc.target/i386/pr41442.c (scan-assembler-times "test|cmp" 2)
> etc.
>
> This is a recurring problem as can be seen by some -fno-ident additions
> by commits from e.g. Michael Meissner over the years: builtins-58.c,
> powerpc/pr46728-?.c
>
> The patch below adds -fno-ident if a testcase contains one of
> scan-assembler, scan-assembler-not or scan-assembler-times.

This reminds me of a related but not opposing idea that I have
never acted on (besides bouncing it off a global maintainer
quite some time ago, with a positive response), to make common
identifier-like and filename-like strings invalid for use in
scan-assembler; there'd have to be a meta-character such as
whitespace.  It would help for "test" but admittedly not for
"test|cmp" given e.g. an objdir named "/tmp/mytest/gccmp/nop1".

Then there'd be an error thrown for such test-cases, alerting
the author (well, hopefully) that the test-case is in error, and
a comment in the scan-assembler code would make it prominent
that there'd have to be a whitespace or meta-like character
(i.e. [^-a-zA-Z_\.]) included in the string.  Yes, I know
whitespace can be included in filenames and that's regularly
done at least on some systems, but I bet you really get into
problems trying that for srcdir or objdir in a gcc build.

Sorry, still not going to act on it for now, but feel free if so
inclined.

brgds, H-P


Re: RFC: pass to warn on questionable uses of alloca().

2016-06-18 Thread Martin Sebor

On 06/16/2016 02:32 AM, Aldy Hernandez wrote:

Hi folks!

I've been working on a plugin to warn on unbounded uses of alloca() to
help find questionable uses in glibc and other libraries.  It occurred
to me that the broader community could benefit from it, as it has found
quite a few interesting cases. So, I've reimplemented it as an actual
pass, lest it be lost in plugin la-la land and bit-rot.

Before I sink any more time cleaning it up, would this be something
acceptable into the compiler?  It doesn't have anything glibc specific,
except possibly the following idiom which I allow:

 if (gate_function (length))
 alloca(length);

...and the above is probably common enough that we should handle it.

The testcase has a lot of examples of what the pass handles.

Thoughts?


I think detecting potentially problematic uses of alloca would
be useful, especially when done in an intelligent way like in
your patch (as opposed to simply diagnosing every call to
the function regardless of the value of its argument).  At
the same time, it seems that an even more reliable solution
than pointing out potentially unsafe calls to the function
and relying on users to modify their code to use malloc for
large/unbounded allocations would be to let GCC do it for
them automatically (i.e., in response to some other option,
emit a call to malloc instead, and insert a call to free when
appropriate).

I applied the patch and experimented with it a bit (I haven't
studied the code in any detail yet) and found a few opportunities
for improvements.  I describe them below (Sorry in advance for
the length of my comments!)

I found the "warning: unbounded use of alloca" misleading when
a call to the function was, in fact, bounded but to a limit
that's greater than alloca-max-size as in the program below:

  void f (void*);

  void g (int n)
  {
void *p;
if (n < 4096)
  p = __builtin_alloca (n);
else
  p = __builtin_malloc (n);
f (p);
  }
  t.C: In function ‘g’:
  t.C:7:7: warning: unbounded use of alloca [-Walloca]
   p = __builtin_alloca (n);

I would suggest to rephrase the diagnostic to mention the limit,
e.g.,

  warning: calling alloca with an argument in excess of '4000'
  bytes

I'm not sure I understand how -Walloca-max-size is supposed to
be used.  For example, it has no effect on the test case above
(i.e., I couldn't find a way to use it to raise the limit to
avoid the warning).  Maybe the interaction of the two options
is more subtle than I think.  I would have expected either
a single option to control whether alloca warnings are to be
emitted and also (optionally) the allocation threshold, or
perhaps two options, one to turn the warning on and off, and
another just to override the threshold (though this latter
approach seems superfluous given that a single option can do
both).

In other words, I would expect a -Walloca alone to diagnose
all calls to alloca with an argument in excess of the default
maximum or with one whose value is unknown, and -Walloca=N
to enable the same warnings but change the threshold to N
bytes. (-Walloca=0 would then diagnose every call to alloca).

As a separate enhancement, since in the (idiomatic) example
above the malloc memory is allowed to leak, issuing a distinct
warning for it would help detect this class of bugs that's
likely to be common as users replace unbounded uses of alloca
with malloc in response to the new option and forget to free
the memory.  Diagnosing freeing the alloca memory would be
a nice touch as well.


Aldy

p.s. The pass currently warns on all uses of VLAs.  I'm not completely
sold on this idea, so perhaps we could remove it, or gate it with a flag.


I also think that VLA diagnostics would be better controlled
by a separate option, and emit a different diagnostic (one
that mentions VLA rather than alloca).  Although again, and
for VLAs even more so than for alloca, providing an option
to have GCC use dynamic allocation, would be an even more
robust solution than issuing warnings.  IIRC, this was the
early implementation of VLAs in GCC so there is a precedent
for it.  (Though this seems complementary to the warnings.)
In addition, I'm of the opinion that potentially unbounded
VLA allocation should be checked at runtime and made trap on
size overflow in C and throw an exception in C++ (e.g., when
int a [A][B] when A * B * sizeof (int) exceeds SIZE_MAX / 2
or some runtime-configurable limit).  My C++ patch for bug
69517 does just that (it needs to be resubmitted with the
runtime configuration limit added).

For a choice of VLA warning options, there already is -Wvla,
though it simply points out every VLA definition regardless
of its size.  It also issues a diagnostic that's questionable
in C99 and later modes (that "ISO C90 forbids variable length
array" is only relevant in C90; what matters when -Wvla is
specified in C99 and C11 modes is that a VLA has been seen).

To keep things consistent with -Walloca, perhaps -Wvla could
be extend

Re: [Patch, avr] Fix PR 71151

2016-06-18 Thread Senthil Kumar Selvaraj

Georg-Johann Lay writes:

> Senthil Kumar Selvaraj schrieb:
>> Hi,
>> 
>>   This patch fixes PR 71151 by eliminating the
>>   TARGET_ASM_FUNCTION_RODATA_SECTION hook and setting
>>   JUMP_TABLES_IN_TEXT_SECTION to 1.
>> 
>>   As described in the bugzilla entry, this hook assumed it will get
>>   called only for jumptable rodata for functions. This was true until
>>   6.1, when a commit in varasm.c started calling the hook for mergeable
>>   string/constant data as well.
>> 
>>   This resulted in string constants ending up in a section intended for
>>   jumptables (flash), and broke code using those constants, which
>>   expects them to be present in rodata (SRAM).
>> 
>>   Given that the original reason for placing jumptables in a section was
>>   fixed by Johann in PR 63323, this patch restores the original
>>   behavior. Reg testing on both gcc-6-branch and trunk showed no regressions.
>> 
>>   As pointed out by Johann, this may end up increasing code
>>   size if there are lots of branches that cross the jump tables. I
>>   intend to propose a separate patch that gives additional information
>>   to the target hook (SECCAT_RODATA_{STRING,JUMPTABLE}) so it can know
>>   what type of function rodata is coming on. Johann also suggested
>>   handling jump table generation ourselves - I'll experiment with that
>>   some more.
>> 
>>   If ok, could someone commit please? Could you also backport to
>>   gcc-6-branch?
>> 
>> Regards
>> Senthil
>> 
>> gcc/ChangeLog
>> 
>> 2016-06-03  Senthil Kumar Selvaraj  
>> 
>
> Missing PR target/71151
>
>>  * config/avr/avr.c (avr_asm_function_rodata_section): Remove.
>>  * config/avr/avr.c (TARGET_ASM_FUNCTION_RODATA_SECTION): Remove.
>> 
>> gcc/testsuite/ChangeLog
>> 
>> 2016-06-03  Senthil Kumar Selvaraj  
>> 
>
> Missing PR target/71151
>
>>  * gcc/testsuite/gcc.target/avr/pr71151-1.c: New.
>>  * gcc/testsuite/gcc.target/avr/pr71151-2.c: New.
>> 

Sorry I missed that. Is it ok to modify the entry alone again?

I just started using the mklog perl script from gcc/contrib
instead of writing the entries by hand - I didn't realize
that script doesn't know about PRs.

Regards
Senthil