Re: [Patch, libgfortran, committed] Don't use rand_s on CYGWIN

[NightStrike]

On Mon, Mar 13, 2017 at 5:01 AM, Janne Blomqvist
 wrote:
> On Sun, Mar 12, 2017 at 10:46 PM, Janne Blomqvist
>  wrote:
>> On Sun, Mar 12, 2017 at 7:26 PM, NightStrike  wrote:
>>> On Mon, Feb 27, 2017 at 6:15 AM, Janne Blomqvist
>>>  wrote:
 Don't try to use rand_s on CYGWIN

 CYGWIN seems to include _mingw.h and thus __MINGW64_VERSION_MAJOR is
 defined even though rand_s is not available. Thus add an extra check
 for __CYGWIN__.

 Thanks to Tim Prince and Nightstrike for bringing this issue to my 
 attention.

 Committed as r245755.

 2017-02-27  Janne Blomqvist  

 * intrinsics/random.c (getosrandom): Don't try to use rand_s on
 CYGWIN.
>>>
>>> 1) There was no patch attached to the email.
>>
>> Oh, sorry. Well, you can see it at
>> https://gcc.gnu.org/viewcvs/gcc?view=revision=245755

Thanks.  You know, this is actually better than attaching a patch (as
a general thing for emails sent after things are already committed),
as there can be no difference between what was emailed and what was
committed.

>>> 2) As mentioned on IRC, I don't think this is the right fix.  The real
>>> problem is that time_1.h includes windows.h on CYGWIN, which it
>>> shouldn't be doing.  This then pollutes the translation unit with all
>>> sorts of MINGW-isms that aren't exactly appropriate for cygwin.
>>> Removing the include in time_1.h and then adjusting a few ifdefs in
>>> system_clock.c that also had the same bug fixes the problem.  The
>>> testsuite is running right now on this.
>>
>> It used to be something like that, but IIRC there were some complaints
>> about SYSTEM_CLOCK on cygwin that were due to the cygwin
>> clock_gettime() or something like that, and after some discussion with
>> someone who knows something about cygwin/mingw (since you apparently
>> have no memory of it, I guess it was Kai), it was decided to use
>> GetTickCount & QPC also on cygwin.
>
> I searched a bit, and it seems the culprit is the thread starting at
>
> https://gcc.gnu.org/ml/fortran/2013-04/msg00033.html
>
> So it turned out that clock_gettime(CLOCK_MONOTONIC, ...) always
> returned 0 on cygwin, hence the code was changed to use the windows
> API functions GetTickCount and QPC also on cygwin at
>
> https://gcc.gnu.org/ml/fortran/2013-04/msg00124.html
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56919

That all led me to this thread:

https://cygwin.com/ml/cygwin/2013-04/msg00184.html

which led me to:

https://cygwin.com/ml/cygwin/2013-04/msg00191.html

where Corinna fixed Angelo's original issue that sparked the whole
thing.  So, from my perspective, Cygwin hasn't had this problem in
about 4 years.

To be complete, though, I took Angelo's original code and compiled it
with a GCC built with the change I suggested, and I received this:

$ ./a.exe
   9.50646996E-02  0.435180306  0.939791977  0.851783216
0.308901191  0.447312355  0.766363919  0.163527727
1.25432014E-02

$ ./a.exe
  0.445786893   9.30446386E-03  0.880381405  0.123394549
1.23693347E-02  0.485788047  0.623361290  0.921140671
0.119319797

$ ./a.exe
  0.378171027  0.439836979  0.440582573   1.17767453E-02
0.427448869  0.530438244  0.182108700  0.147965968
0.668991745

$ ./a.exe
   2.73125172E-02  0.916011810  0.854288757  0.913502872
0.508077919  0.210798383   8.76839161E-02  0.120695710
0.337186754


I then tried Janus' enhanced version from
https://gcc.gnu.org/ml/fortran/2013-04/msg00034.html

$ ./a.exe
 n=  33
 clock:   744091787
 seed:744091787   744091824   744091861   744091898   744091935
744091972   744092009   744092046   744092083   744092120   744092157
 744092194   744092231   744092268   744092305   744092342   744092379
  744092416   744092453   744092490   744092527   744092564
744092601   744092638   744092675   744092712   744092749   744092786
 744092823   744092860   744092897   744092934   744092971
 random:   0.801897824  0.180594921  0.280960143
8.65536928E-03  0.122029424  0.473693788  0.161536098
0.228073180  0.441518903

$ ./a.exe
 n=  33
 clock:   744093409
 seed:744093409   744093446   744093483   744093520   744093557
744093594   744093631   744093668   744093705   744093742   744093779
 744093816   744093853   744093890   744093927   744093964   744094001
  744094038   744094075   744094112   744094149   744094186
744094223   744094260   744094297   744094334   744094371   744094408
 744094445   744094482   744094519   744094556   744094593
 random:   0.164107382  0.762304962  0.511664748
0.700617492  0.692375600  0.207925439  0.920203805
0.160881400  0.339902878

$ ./a.exe
 n=  33
 clock:   744094930
 seed:744094930   744094967   744095004   744095041   744095078
744095115   744095152   744095189   

Re: FIx riscv port building with the trunk

[Palmer Dabbelt]

Thanks Kito -- this had broken my build too, I'd just gotten distracted by
another bug and had forgotten to commit it.  It's now in as

commit 6ca48c85b40db96f01d49f37afb19100b4a6b75b
Author: palmer 
Date:   Tue Mar 14 03:51:24 2017 +

Use gcc_fallthrough() instead of __attribute__((fallthrough)

Without this my build breaks on older compilers like GCC-5.4.

gcc/ChangeLog:

2017-03-13  Kito Cheng  

   * config/riscv/riscv.c (riscv_emit_float_compare>: Use
   gcc_fallthrough() instead of __attribute__((fallthrough));

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@246116 
138bc75d-0d04-0410-961f-82ee72b054a4

On Mon, 13 Mar 2017 20:00:36 PDT (-0700), kito.ch...@gmail.com wrote:
> Hi Jeff:
>
> It's make older gcc version can't build RISC-V port, how about use
> gcc_fallthrough instead?
>
> diff --git a/gcc/config/riscv/riscv.c b/gcc/config/riscv/riscv.c
> index f4c1f23..d1af07f5 100644
> --- a/gcc/config/riscv/riscv.c
> +++ b/gcc/config/riscv/riscv.c
> @@ -2089,13 +2089,13 @@ riscv_emit_float_compare (enum rtx_code *code,
> rtx *op0, rtx *op1)
>
>  case UNLT:
>std::swap (cmp_op0, cmp_op1);
> -  __attribute__((fallthrough));
> +  gcc_fallthrough ();
>
>  UNORDERED_COMPARISON(UNGT, le)
>
>  case UNLE:
>std::swap (cmp_op0, cmp_op1);
> -  __attribute__((fallthrough));
> +  gcc_fallthrough ();
>
>  UNORDERED_COMPARISON(UNGE, lt)
>  #undef UNORDERED_COMPARISON
>
> On Tue, Mar 14, 2017 at 2:22 AM, Palmer Dabbelt  wrote:
>> On Mon, 13 Mar 2017 10:50:28 PDT (-0700), l...@redhat.com wrote:
>>>
>>> RISCV targets were failing to build due to implicit-fallthru warnings.
>>>
>>> This changes comments which indicated expected fallthru to use the
>>> attribute and the port builds again.   I assume something about the use
>>> of the cpp macro is causing the comment to not have the intended effect.
>>>   I didn't dig into that.  Nor did I try to change all the fallthru
>>> comments to use the attribute -- just the two that implicit-fallthru was
>>> complaining about.
>>>
>>> Verified that after this patch the two riscv targets build.  Installed
>>> on the trunk.
>>>
>>> Jeff
>>>
>>> commit 448373f1f2912228dc72605fb6f3343fd57023ee
>>> Author: law 
>>> Date:   Mon Mar 13 17:49:40 2017 +
>>>
>>> * config/riscv/riscv.c (riscv_emit_float_compare): Use fallthru
>>> attribute rather than comments.
>>>
>>> git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@246101 
>>> 138bc75d-0d04-0410-961f-82ee72b054a4
>>>
>>> diff --git a/gcc/ChangeLog b/gcc/ChangeLog
>>> index 124dca3..e863cdf 100644
>>> --- a/gcc/ChangeLog
>>> +++ b/gcc/ChangeLog
>>> @@ -1,5 +1,8 @@
>>>  2017-03-13  Jeff Law  
>>>
>>> + * config/riscv/riscv.c (riscv_emit_float_compare): Use fallthru
>>> + attribute rather than comments.
>>> +
>>>   * config/pdp11/pdp11.md (movmemhi): Adjust operand numbers to
>>>   match_scratch operand is highest.
>>>
>>> diff --git a/gcc/config/riscv/riscv.c b/gcc/config/riscv/riscv.c
>>> index 89567f7..e5044ba 100644
>>> --- a/gcc/config/riscv/riscv.c
>>> +++ b/gcc/config/riscv/riscv.c
>>> @@ -2089,13 +2089,13 @@ riscv_emit_float_compare (enum rtx_code *code, rtx 
>>> *op0, rtx *op1)
>>>
>>>  case UNLT:
>>>std::swap (cmp_op0, cmp_op1);
>>> -  /* Fall through.  */
>>> +  __attribute__((fallthrough));
>>>
>>>  UNORDERED_COMPARISON(UNGT, le)
>>>
>>>  case UNLE:
>>>std::swap (cmp_op0, cmp_op1);
>>> -  /* Fall through.  */
>>> +  __attribute__((fallthrough));
>>>
>>>  UNORDERED_COMPARISON(UNGE, lt)
>>>  #undef UNORDERED_COMPARISON
>>
>> Thanks!

Re: FIx riscv port building with the trunk

[Kito Cheng]

Hi Jeff:

It's make older gcc version can't build RISC-V port, how about use
gcc_fallthrough instead?

diff --git a/gcc/config/riscv/riscv.c b/gcc/config/riscv/riscv.c
index f4c1f23..d1af07f5 100644
--- a/gcc/config/riscv/riscv.c
+++ b/gcc/config/riscv/riscv.c
@@ -2089,13 +2089,13 @@ riscv_emit_float_compare (enum rtx_code *code,
rtx *op0, rtx *op1)

 case UNLT:
   std::swap (cmp_op0, cmp_op1);
-  __attribute__((fallthrough));
+  gcc_fallthrough ();

 UNORDERED_COMPARISON(UNGT, le)

 case UNLE:
   std::swap (cmp_op0, cmp_op1);
-  __attribute__((fallthrough));
+  gcc_fallthrough ();

 UNORDERED_COMPARISON(UNGE, lt)
 #undef UNORDERED_COMPARISON

On Tue, Mar 14, 2017 at 2:22 AM, Palmer Dabbelt  wrote:
> On Mon, 13 Mar 2017 10:50:28 PDT (-0700), l...@redhat.com wrote:
>>
>> RISCV targets were failing to build due to implicit-fallthru warnings.
>>
>> This changes comments which indicated expected fallthru to use the
>> attribute and the port builds again.   I assume something about the use
>> of the cpp macro is causing the comment to not have the intended effect.
>>   I didn't dig into that.  Nor did I try to change all the fallthru
>> comments to use the attribute -- just the two that implicit-fallthru was
>> complaining about.
>>
>> Verified that after this patch the two riscv targets build.  Installed
>> on the trunk.
>>
>> Jeff
>>
>> commit 448373f1f2912228dc72605fb6f3343fd57023ee
>> Author: law 
>> Date:   Mon Mar 13 17:49:40 2017 +
>>
>> * config/riscv/riscv.c (riscv_emit_float_compare): Use fallthru
>> attribute rather than comments.
>>
>> git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@246101 
>> 138bc75d-0d04-0410-961f-82ee72b054a4
>>
>> diff --git a/gcc/ChangeLog b/gcc/ChangeLog
>> index 124dca3..e863cdf 100644
>> --- a/gcc/ChangeLog
>> +++ b/gcc/ChangeLog
>> @@ -1,5 +1,8 @@
>>  2017-03-13  Jeff Law  
>>
>> + * config/riscv/riscv.c (riscv_emit_float_compare): Use fallthru
>> + attribute rather than comments.
>> +
>>   * config/pdp11/pdp11.md (movmemhi): Adjust operand numbers to
>>   match_scratch operand is highest.
>>
>> diff --git a/gcc/config/riscv/riscv.c b/gcc/config/riscv/riscv.c
>> index 89567f7..e5044ba 100644
>> --- a/gcc/config/riscv/riscv.c
>> +++ b/gcc/config/riscv/riscv.c
>> @@ -2089,13 +2089,13 @@ riscv_emit_float_compare (enum rtx_code *code, rtx 
>> *op0, rtx *op1)
>>
>>  case UNLT:
>>std::swap (cmp_op0, cmp_op1);
>> -  /* Fall through.  */
>> +  __attribute__((fallthrough));
>>
>>  UNORDERED_COMPARISON(UNGT, le)
>>
>>  case UNLE:
>>std::swap (cmp_op0, cmp_op1);
>> -  /* Fall through.  */
>> +  __attribute__((fallthrough));
>>
>>  UNORDERED_COMPARISON(UNGE, lt)
>>  #undef UNORDERED_COMPARISON
>
> Thanks!

Re: [PATCH] add calls.c to GTFILES in Makefile.in (PR 79936)

[Martin Sebor]

Ping: this a P3 regression targeted at 7.0.1.  It was found
on x86_64-apple-darwin10.8.0 but affects all targets (even
if it doesn't happen to manifest on them):

  https://gcc.gnu.org/ml/gcc-patches/2017-03/msg00342.html

On 03/07/2017 06:03 PM, Martin Sebor wrote:

In bug 79936 - ICE with -Walloc-size-larger-than=32767 the reporter
encountered an ICE on x86_64-apple-darwin10.8.0 caused by GCC source
file that implements the warning accessing a global tree without
having included the file in GTFILES make variable.  (Thanks again
to David Malcolm who helped me root cause this bug.)

The attached patch fixes this by adding calls.c to the variable and
by including the requisite generated header, gt-calls.h, at the end
of the source.

Martin

[PATCH] correct handling of negative-positive precision ranges with floating directives (PR 79800)

[Martin Sebor]

The output of a floating point directive whose precision is
specified by an asterisk with an argument that's in a range
that includes both negative and positive values less than
six may include between zero and six fractional digits plus
a decimal point.  For example,

  printf ("%.*e", p, x);

results in the 14 bytes

  -1.797693e+308

when p == -1 and x == -DBL_MIN because a negative precision
is ignored and the directive assumes the default 6, and in
just the one byte

  0

when p == 0 and x == 0.0.

Current trunk doesn't handle this case correctly when the
floating argument isn't known and uses the upper bound of
the specified precision as the maximum number of fractional
digits.  As a result, it sets the range on the return value
in this case as [5, 7] (plus 5 for the longest multibyte
decimal decimal point) when the correct range is [5, 14] as
explained above (plus 5 again).

The attached patch corrects the handling of such precision
ranges to avoid this unlikely bug.

Martin
PR tree-optimization/79800 - wrong snprintf result range with precision in a narrow negative-positive range

gcc/ChangeLog:

	PR tree-optimization/79800
	* gimple-ssa-sprintf.c (format_floating: Add argument.  Handle
	precision in negative-positive range.
	(format_floating): Call non-const overload with adjusted precision.

gcc/testsuite/ChangeLog:

	PR tree-optimization/79800
	* gcc.dg/tree-ssa/builtin-sprintf-warn-15.c: Add test cases.
	* gcc.dg/tree-ssa/pr79800.c: New test.

diff --git a/gcc/gimple-ssa-sprintf.c b/gcc/gimple-ssa-sprintf.c
index 0448b21..2474391 100644
--- a/gcc/gimple-ssa-sprintf.c
+++ b/gcc/gimple-ssa-sprintf.c
@@ -1499,11 +1499,13 @@ format_floating_max (tree type, char spec, HOST_WIDE_INT prec)
 }
 
 /* Return a range representing the minimum and maximum number of bytes
-   that the directive DIR will output for any argument.  This function
-   is used when the directive argument or its value isn't known.  */
+   that the directive DIR will output for any argument.  PREC gives
+   the adjusted precision range to account for negative precisions
+   meaning the default 6.  This function is used when the directive
+   argument or its value isn't known.  */
 
 static fmtresult
-format_floating (const directive )
+format_floating (const directive , const HOST_WIDE_INT prec[2])
 {
   tree type;
 
@@ -1532,8 +1534,8 @@ format_floating (const directive )
   /* The minimum output as determined by flags.  It's always at least 1.
  When plus or space are set the output is preceded by either a sign
  or a space.  */
-  int flagmin = (1 /* for the first digit */
-		 + (dir.get_flag ('+') | dir.get_flag (' ')));
+  unsigned flagmin = (1 /* for the first digit */
+		  + (dir.get_flag ('+') | dir.get_flag (' ')));
 
   /* When the pound flag is set the decimal point is included in output
  regardless of precision.  Whether or not a decimal point is included
@@ -1557,14 +1559,13 @@ format_floating (const directive )
 			 + minprec
 			 + 3 /* p+0 */);
 
-	res.range.max = format_floating_max (type, 'a', dir.prec[1]);
+	res.range.max = format_floating_max (type, 'a', prec[1]);
 	res.range.likely = res.range.min;
 
 	/* The unlikely maximum accounts for the longest multibyte
 	   decimal point character.  */
 	res.range.unlikely = res.range.max;
-	if (dir.prec[0] != dir.prec[1]
-	|| dir.prec[0] == -1 || dir.prec[0] > 0)
+	if (dir.prec[1] > 0)
 	  res.range.unlikely += target_mb_len_max () - 1;
 
 	break;
@@ -1573,23 +1574,18 @@ format_floating (const directive )
 case 'E':
 case 'e':
   {
+	/* Minimum output attributable to precision and, when it's
+	   non-zero, decimal point.  */
+	HOST_WIDE_INT minprec = prec[0] ? prec[0] + !radix : 0;
+
 	/* The minimum output is "[-+]1.234567e+00" regardless
 	   of the value of the actual argument.  */
-	HOST_WIDE_INT minprec = 6 + !radix /* decimal point */;
-	if ((dir.prec[0] < 0 && dir.prec[1] > -1) || dir.prec[0] == 0)
-	  minprec = 0;
-	else if (dir.prec[0] > 0)
-	  minprec = dir.prec[0] + !radix /* decimal point */;
-
 	res.range.min = (flagmin
 			 + radix
 			 + minprec
 			 + 2 /* e+ */ + 2);
-	/* MPFR uses a precision of 16 by default for some reason.
-	   Set it to the C default of 6.  */
-	int maxprec = dir.prec[1] < 0 ? 6 : dir.prec[1];
-	res.range.max = format_floating_max (type, 'e', maxprec);
 
+	res.range.max = format_floating_max (type, 'e', prec[1]);
 	res.range.likely = res.range.min;
 
 	/* The unlikely maximum accounts for the longest multibyte
@@ -1605,21 +1601,19 @@ format_floating (const directive )
 case 'F':
 case 'f':
   {
+	/* Minimum output attributable to precision and, when it's non-zero,
+	   decimal point.  */
+	HOST_WIDE_INT minprec = prec[0] ? prec[0] + !radix : 0;
+
 	/* The lower bound when precision isn't specified is 8 bytes
 	   ("1.23456" since precision is taken to be 6).  When precision
 	   is zero, the lower bound is 1 byte (e.g., "1").  Otherwise,
 	   when precision is greater than zero, then 

[PATCH] Fix PR79908

[Bill Schmidt]

Hi,

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79908 shows a case where
pass_stdarg ICEs attempting to gimplify a COMPLEX_EXPR with side
effects as an lvalue.  The expression is not addressable, so the
gimplification fails.  This patch says, hey, don't do that!  

The resulting GIMPLE looks fine afterward.  Bootstrapped and tested
on powerpc64le-unknown-linux-gnu with no regressions.  Is this ok
for trunk?

Thanks,
Bill


[gcc]

2017-03-13  Bill Schmidt  

PR tree-optimization/79908
* tree-stdarg.c (expand_ifn_va_arg_1): Don't force something to be
an lvalue that isn't addressable.

[gcc/testsuite]

2017-03-13  Bill Schmidt  

PR tree-optimization/79908
* gcc.dg/torture/pr79908.c: New file.


Index: gcc/testsuite/gcc.dg/torture/pr79908.c
===
--- gcc/testsuite/gcc.dg/torture/pr79908.c  (nonexistent)
+++ gcc/testsuite/gcc.dg/torture/pr79908.c  (working copy)
@@ -0,0 +1,12 @@
+/* { dg-do compile } */
+
+/* Used to fail in the stdarg pass before fix for PR79908.  */
+
+typedef __builtin_va_list __gnuc_va_list;
+typedef __gnuc_va_list va_list;
+
+void testva (int n, ...)
+{
+  va_list ap;
+  _Complex int i = __builtin_va_arg (ap, _Complex int);
+}
Index: gcc/tree-stdarg.c
===
--- gcc/tree-stdarg.c   (revision 246109)
+++ gcc/tree-stdarg.c   (working copy)
@@ -1057,7 +1057,7 @@ expand_ifn_va_arg_1 (function *fun)
   types.  */
gimplify_assign (lhs, expr, );
  }
-   else
+   else if (is_gimple_addressable (expr))
  gimplify_expr (, , , is_gimple_lvalue, fb_lvalue);
 
input_location = saved_location;

Re: [PATCH v2, doc] Revise GCC manual section 6.11, Additional Floating Types

[Bill Schmidt]

> On Mar 13, 2017, at 6:31 PM, Segher Boessenkool  
> wrote:
> 
> Hi Bill,
> 
> On Mon, Mar 13, 2017 at 01:11:01PM -0500, Bill Schmidt wrote:
>> Index: gcc/doc/extend.texi
>> ===
>> --- gcc/doc/extend.texi  (revision 246014)
>> +++ gcc/doc/extend.texi  (working copy)
>> @@ -948,10 +948,28 @@ names can be used together with @code{_Complex} to
>> types.
>> 
>> As an extension, GNU C and GNU C++ support additional floating
>> -types, @code{__float80} and @code{__float128} to support 80-bit
>> -(@code{XFmode}) and 128-bit (@code{TFmode}) floating types; these are
>> -aliases for the type names @code{_Float64x} and @code{_Float128}.
>> -Support for additional types includes the arithmetic operators:
>> +types, which are not supported by all targets.
>> +@itemize @bullet
>> +@item @code{__float128} is available on i386, x86_64, IA-64, and
>> +hppa HP-UX, as well as on PowerPC 64-bit GNU/Linux targets that enable
>> +the vector scalar (VSX) instruction set.  @code{__float128} supports
>> +the 128-bit floating type.  On i386, x86_64, PowerPC, and IA-64
>> +other than HP-UX, @code{__float128} is an alias for @code{_Float128}.
>> +On hppa and IA-64 HP-UX, @code{__float128} is an alias for @code{long
>> +double}.
> 
> __float128 (-mfloat128) does not require 64-bit PowerPC, only hardware
> support (-mfloat128-hardware) requires it (and only because we haven't
> implemented it for 32-bit).

OK, I will drop the "64-bit" modifier.

Thanks,
Bill
> 
> 
> Segher
> 

Re: [PATCH v2, doc] Revise GCC manual section 6.11, Additional Floating Types

[Segher Boessenkool]

Hi Bill,

On Mon, Mar 13, 2017 at 01:11:01PM -0500, Bill Schmidt wrote:
> Index: gcc/doc/extend.texi
> ===
> --- gcc/doc/extend.texi   (revision 246014)
> +++ gcc/doc/extend.texi   (working copy)
> @@ -948,10 +948,28 @@ names can be used together with @code{_Complex} to
>  types.
>  
>  As an extension, GNU C and GNU C++ support additional floating
> -types, @code{__float80} and @code{__float128} to support 80-bit
> -(@code{XFmode}) and 128-bit (@code{TFmode}) floating types; these are
> -aliases for the type names @code{_Float64x} and @code{_Float128}.
> -Support for additional types includes the arithmetic operators:
> +types, which are not supported by all targets.
> +@itemize @bullet
> +@item @code{__float128} is available on i386, x86_64, IA-64, and
> +hppa HP-UX, as well as on PowerPC 64-bit GNU/Linux targets that enable
> +the vector scalar (VSX) instruction set.  @code{__float128} supports
> +the 128-bit floating type.  On i386, x86_64, PowerPC, and IA-64
> +other than HP-UX, @code{__float128} is an alias for @code{_Float128}.
> +On hppa and IA-64 HP-UX, @code{__float128} is an alias for @code{long
> +double}.

__float128 (-mfloat128) does not require 64-bit PowerPC, only hardware
support (-mfloat128-hardware) requires it (and only because we haven't
implemented it for 32-bit).


Segher

Re: terminology: zero character vs. null character

[Bruce Korb]

On 03/13/17 15:02, Gerald Pfeifer wrote:
> On Mon, 13 Mar 2017, Joseph Myers wrote:
> I am currently translating GCC into German. During that, I noticed that
> in some places the term "zero character" means '\0'. The official term
> though is "null character", as per the C standard.
>>> Joseph, do you also agree (and with the patch below to document this)?
>> Yes.
> 
> Cool; I committed the change to codingconventions.html .

I'm likely late to the party, but what's wrong with the traditional
"NUL"?  Googling "NUL vs. NULL" yields up:

NULL is a macro defined in  for the null pointer. NUL is the
name of the first character in the ASCII character set. It corresponds
to a zero value. There s no standard macro NUL in C, but some people
like to define it.

[patch, libfortran] [patch, fortran] Fix PR 79956, part two, attempt 2

[Thomas Koenig]

Hello world,

Following Richard's suggestion, I have implemented the GFC_ASSERT macro
and used it to (hopefully) silence the ominous warning and allow
further optimization.

OK for trunk?

Regards

Thomas

2017-03-12  Thomas Koenig  

PR libfortran/79956
* libgfortran.h (GFC_ASSERT):  New macro.
* m4/reshape.m4 (reshape_'rtype_ccode`):  Use GFC_ASSERT
to specify that sdim > 0.
* intrinsic/reshape_generic.c (reshape_internal):  Likweise.
* generated/reshape_c10.c: Regenerated.
* generated/reshape_c16.c: Regenerated.
* generated/reshape_c4.c: Regenerated.
* generated/reshape_c8.c: Regenerated.
* generated/reshape_i16.c: Regenerated.
* generated/reshape_i4.c: Regenerated.
* generated/reshape_i8.c: Regenerated.
* generated/reshape_r10.c: Regenerated.
* generated/reshape_r16.c: Regenerated.
* generated/reshape_r4.c: Regenerated.
* generated/reshape_r8.c: Regenerated.
Index: generated/reshape_c10.c
===
--- generated/reshape_c10.c	(Revision 245760)
+++ generated/reshape_c10.c	(Arbeitskopie)
@@ -232,6 +232,11 @@ reshape_c10 (gfc_array_c10 * const restrict ret,
 }
 
   sdim = GFC_DESCRIPTOR_RANK (source);
+
+  /* sdim is always > 0; this lets the compiler optimize more and
+   avoids a warning.  */
+  GFC_ASSERT(sdim>0);
+
   ssize = 1;
   sempty = 0;
   for (n = 0; n < sdim; n++)
Index: generated/reshape_c16.c
===
--- generated/reshape_c16.c	(Revision 245760)
+++ generated/reshape_c16.c	(Arbeitskopie)
@@ -232,6 +232,11 @@ reshape_c16 (gfc_array_c16 * const restrict ret,
 }
 
   sdim = GFC_DESCRIPTOR_RANK (source);
+
+  /* sdim is always > 0; this lets the compiler optimize more and
+   avoids a warning.  */
+  GFC_ASSERT(sdim>0);
+
   ssize = 1;
   sempty = 0;
   for (n = 0; n < sdim; n++)
Index: generated/reshape_c4.c
===
--- generated/reshape_c4.c	(Revision 245760)
+++ generated/reshape_c4.c	(Arbeitskopie)
@@ -232,6 +232,11 @@ reshape_c4 (gfc_array_c4 * const restrict ret,
 }
 
   sdim = GFC_DESCRIPTOR_RANK (source);
+
+  /* sdim is always > 0; this lets the compiler optimize more and
+   avoids a warning.  */
+  GFC_ASSERT(sdim>0);
+
   ssize = 1;
   sempty = 0;
   for (n = 0; n < sdim; n++)
Index: generated/reshape_c8.c
===
--- generated/reshape_c8.c	(Revision 245760)
+++ generated/reshape_c8.c	(Arbeitskopie)
@@ -232,6 +232,11 @@ reshape_c8 (gfc_array_c8 * const restrict ret,
 }
 
   sdim = GFC_DESCRIPTOR_RANK (source);
+
+  /* sdim is always > 0; this lets the compiler optimize more and
+   avoids a warning.  */
+  GFC_ASSERT(sdim>0);
+
   ssize = 1;
   sempty = 0;
   for (n = 0; n < sdim; n++)
Index: generated/reshape_i16.c
===
--- generated/reshape_i16.c	(Revision 245760)
+++ generated/reshape_i16.c	(Arbeitskopie)
@@ -232,6 +232,11 @@ reshape_16 (gfc_array_i16 * const restrict ret,
 }
 
   sdim = GFC_DESCRIPTOR_RANK (source);
+
+  /* sdim is always > 0; this lets the compiler optimize more and
+   avoids a warning.  */
+  GFC_ASSERT(sdim>0);
+
   ssize = 1;
   sempty = 0;
   for (n = 0; n < sdim; n++)
Index: generated/reshape_i4.c
===
--- generated/reshape_i4.c	(Revision 245760)
+++ generated/reshape_i4.c	(Arbeitskopie)
@@ -232,6 +232,11 @@ reshape_4 (gfc_array_i4 * const restrict ret,
 }
 
   sdim = GFC_DESCRIPTOR_RANK (source);
+
+  /* sdim is always > 0; this lets the compiler optimize more and
+   avoids a warning.  */
+  GFC_ASSERT(sdim>0);
+
   ssize = 1;
   sempty = 0;
   for (n = 0; n < sdim; n++)
Index: generated/reshape_i8.c
===
--- generated/reshape_i8.c	(Revision 245760)
+++ generated/reshape_i8.c	(Arbeitskopie)
@@ -232,6 +232,11 @@ reshape_8 (gfc_array_i8 * const restrict ret,
 }
 
   sdim = GFC_DESCRIPTOR_RANK (source);
+
+  /* sdim is always > 0; this lets the compiler optimize more and
+   avoids a warning.  */
+  GFC_ASSERT(sdim>0);
+
   ssize = 1;
   sempty = 0;
   for (n = 0; n < sdim; n++)
Index: generated/reshape_r10.c
===
--- generated/reshape_r10.c	(Revision 245760)
+++ generated/reshape_r10.c	(Arbeitskopie)
@@ -232,6 +232,11 @@ reshape_r10 (gfc_array_r10 * const restrict ret,
 }
 
   sdim = GFC_DESCRIPTOR_RANK (source);
+
+  /* sdim is always > 0; this lets the compiler optimize more and
+   avoids a warning.  */
+  GFC_ASSERT(sdim>0);
+
   ssize = 1;
   sempty = 0;
   for (n = 0; n < sdim; n++)
Index: generated/reshape_r16.c
===

Re: [C++ PATCH] 79393 fix

[Nathan Sidwell]

On 03/13/2017 05:05 PM, Jason Merrill wrote:


It looks like you're ignoring the access for all base destructors;
handling this in synthesized_method_base_walk would let you limit the
change to vbases with virtual destructors.  That function also already
handles ignoring access control for an inherited constructor.


d'oh! you're right.  I was in two minds about ignoring access at all -- and 
xfailing that testcase for the moment.  That would avoid an unfortunate possible 
future where the DR resolves to revert to the pre DR 1658 behaviour for dtors. 
thoughts?


nathan

--
Nathan Sidwell

New Spanish PO file for 'gcc' (version 7.1-b20170226)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'gcc' has been submitted
by the Spanish team of translators.  The file is available at:

http://translationproject.org/latest/gcc/es.po

(This file, 'gcc-7.1-b20170226.es.po', has just now been sent to you in
a separate email.)

All other PO files for your package are available in:

http://translationproject.org/latest/gcc/

Please consider including all of these in your next release, whether
official or a pretest.

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

The following HTML page has been updated:

http://translationproject.org/domain/gcc.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.

Re: terminology: zero character vs. null character

[Gerald Pfeifer]

On Mon, 13 Mar 2017, Joseph Myers wrote:
 I am currently translating GCC into German. During that, I noticed that
 in some places the term "zero character" means '\0'. The official term
 though is "null character", as per the C standard.
>> Joseph, do you also agree (and with the patch below to document this)?
> Yes.

Cool; I committed the change to codingconventions.html .

Roland (and Manuel), that means you can now proceed according to
Manuel's recommendation.

Gerald

Re: install.texi and avr (was: Target maintainers: doc/install.texi love and care)

[Gerald Pfeifer]

On Mon, 13 Mar 2017, Denis Chertykov wrote:
>> The avr section currently has this:
>>
>>   We @emph{strongly} recommend using binutils 2.13 or newer.
>>
>> Okay to yank it?
> We can remove this line.

Done thusly, thank you.

Gerald

2017-03-13  Gerald Pfeifer  

* doc/install.texi (Specific) : Remove reference to
binutils 2.13.

Index: doc/install.texi
===
--- doc/install.texi(revision 246109)
+++ doc/install.texi(working copy)
@@ -3396,8 +3396,6 @@
 @uref{http://www.amelek.gda.pl/avr/,,http://www.amelek.gda.pl/avr/}
 @end itemize
 
-We @emph{strongly} recommend using binutils 2.13 or newer.
-
 The following error:
 @smallexample
 Error: register required
> 

Re: [C++ PATCH] 79393 fix

[Jason Merrill]

On Mon, Mar 13, 2017 at 8:06 AM, Nathan Sidwell  wrote:
> The resolution to DR 1658 causes vbases of abstract classes to be ignored
> when building the cdtors.  That made sense for ctors, when there might be no
> default ctor available.  But for dtors, there is only oe dtor and they can
> be virtual.  That can break virtual overriding, as 79393 discovered.
>
> I've reported this as a DR, but so GCC 7 doesn't break currently working
> code, I've committed this patch to skip that part of 1658's resolution.
>
> The inhibiting of access checks was needed of pr66443-cxx14-3.C to continue
> passing.  That's a case where the vbase's dtor is inaccessible from the
> abstract base.  That seemed like the most conservative way to inhibit 1658's
> impact by allowing the most code to be compiled, but of course is
> speculative.

It looks like you're ignoring the access for all base destructors;
handling this in synthesized_method_base_walk would let you limit the
change to vbases with virtual destructors.  That function also already
handles ignoring access control for an inherited constructor.

Jason

Re: [v3 PATCH] PR libstdc++/80034

[Jonathan Wakely]

On 13/03/17 20:57 +0200, Ville Voutilainen wrote:

All branches tested on Linux-x64.

Changelogs for trunk, gcc-6-branch, gcc-5-branch (the last two are identical, as
are probably their patches).


OK for all three, thanks.

[PATCH] Various fixes for facets

[Jonathan Wakely]

This is a series of patches to fix various bugs in the Unicode
character conversion facets.

Ther first patch fixes a silly < versus <= bug that meant that 0x
got written as a surrogate pair instead of as simply 0xff, and an
endianness bug for the internal representation of UTF-16 code units
stored in char32_t or wchar_t values. That's PR 79511.

The second patch fixes some incorrect bitwise operations (because I
confused & and |) and some incorrect limits (because I confused max
and min). That fixes determining the endianness of the external
representation bytes when they start with a Byte OrderMark, and
correctly reports errors on invalid UCS2. It also fixes
wstring_convert so that it reports the number of characters that were
converted prior to an error. That's PR 79980.

The third patch fixes the output of the encoding() and max_length()
member functions on the codecvt facets, because I wasn't correctly
accounting for a BOM or for the differences between UTF-16 and UCS2.

I plan to commit these for all branches, but I'll wait until after GCC
7.1 is released, and fix it for 7.2 instead. These bugs aren't
important enough to rush into trunk now.


commit c5bbc9258a7182e14eb731e5251842bc417b5822
Author: Jonathan Wakely 
Date:   Fri Mar 10 20:12:09 2017 +

PR libstdc++/79511 fix endianness of UTF-16 data

PR libstdc++/79511
* src/c++11/codecvt.cc (write_utf16_code_point): Don't write 0x
as a surrogate pair.
(__codecvt_utf8_utf16_base::do_in): Use native endianness
for internal representation.
(__codecvt_utf8_utf16_base::do_in): Likewise.
* testsuite/22_locale/codecvt/codecvt_utf8_utf16/79511.cc: New test.

diff --git a/libstdc++-v3/src/c++11/codecvt.cc 
b/libstdc++-v3/src/c++11/codecvt.cc
index 12a4d4f..9b63e2b 100644
--- a/libstdc++-v3/src/c++11/codecvt.cc
+++ b/libstdc++-v3/src/c++11/codecvt.cc
@@ -315,7 +315,7 @@ namespace
   {
 static_assert(sizeof(C) >= 2, "a code unit must be at least 16-bit");
 
-if (codepoint < max_single_utf16_unit)
+if (codepoint <= max_single_utf16_unit)
   {
if (to.size() > 0)
  {
@@ -1341,7 +1341,11 @@ do_in(state_type&, const extern_type* __from, const 
extern_type* __from_end,
 {
   range from{ __from, __from_end };
   range to{ __to, __to_end };
-  auto res = utf16_in(from, to, _M_maxcode, _M_mode);
+  codecvt_mode mode = codecvt_mode(_M_mode & (consume_header|generate_header));
+#if __BYTE_ORDER__ != __ORDER_BIG_ENDIAN__
+  mode = codecvt_mode(mode | little_endian);
+#endif
+  auto res = utf16_in(from, to, _M_maxcode, mode);
   __from_next = from.next;
   __to_next = to.next;
   return res;
@@ -1411,7 +1415,11 @@ do_in(state_type&, const extern_type* __from, const 
extern_type* __from_end,
 {
   range from{ __from, __from_end };
   range to{ __to, __to_end };
-  auto res = utf16_in(from, to, _M_maxcode, _M_mode);
+  codecvt_mode mode = codecvt_mode(_M_mode & (consume_header|generate_header));
+#if __BYTE_ORDER__ != __ORDER_BIG_ENDIAN__
+  mode = codecvt_mode(mode | little_endian);
+#endif
+  auto res = utf16_in(from, to, _M_maxcode, mode);
   __from_next = from.next;
   __to_next = to.next;
   return res;
diff --git 
a/libstdc++-v3/testsuite/22_locale/codecvt/codecvt_utf8_utf16/79511.cc 
b/libstdc++-v3/testsuite/22_locale/codecvt/codecvt_utf8_utf16/79511.cc
new file mode 100644
index 000..bcb
--- /dev/null
+++ b/libstdc++-v3/testsuite/22_locale/codecvt/codecvt_utf8_utf16/79511.cc
@@ -0,0 +1,60 @@
+// Copyright (C) 2017 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library.  This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+// GNU General Public License for more details.
+
+// You should have received a copy of the GNU General Public License along
+// with this library; see the file COPYING3.  If not see
+// .
+
+// { dg-do run { target c++11 } }
+
+#include 
+#include 
+#include 
+
+// PR libstdc++/79511
+
+template
+  std::basic_string conv(const char* src)
+  {
+std::wstring_convert conv;
+return conv.from_bytes(src);
+  }
+
+void
+test01()
+{
+  static char const src[] = "\xEF\xBF\xBF";
+  VERIFY( conv(src) == u"\x" );
+  VERIFY( conv(src) == U"\x" );
+#ifdef _GLIBCXX_USE_WCHAR_T
+  VERIFY( conv(src) == L"\x" );
+#endif
+}
+
+void
+test02()
+{
+  static char const src[] = "\xE2\x82\xAC";
+  VERIFY( conv(src) == u"\x20ac" );
+  VERIFY( conv(src) == U"\x20ac" );
+#ifdef _GLIBCXX_USE_WCHAR_T
+  VERIFY( conv(src) == L"\x20ac" );
+#endif
+}
+

[v3 PATCH] PR libstdc++/80034

[Ville Voutilainen]

All branches tested on Linux-x64.

Changelogs for trunk, gcc-6-branch, gcc-5-branch (the last two are identical, as
are probably their patches).

2017-03-13  Ville Voutilainen  

PR libstdc++/80034
* include/bits/list.tcc (merge(list&&)): Use const for the size_t
in the catch-block.
(merge(list&&, _StrictWeakOrdering)): Likewise.
* testsuite/23_containers/list/operations/80034.cc: New.

2017-03-13  Ville Voutilainen  

PR libstdc++/80034
* include/bits/list.tcc (merge(list&&)): Use const for the size_t
in the function and in the catch-block, qualify uses of std::distance.
(merge(list&&, _StrictWeakOrdering)): Likewise.
* testsuite/23_containers/list/operations/80034.cc: New.

2017-03-13  Ville Voutilainen  

PR libstdc++/80034
* include/bits/list.tcc (merge(list&&)): Use const for the size_t
in the function and in the catch-block, qualify uses of std::distance.
(merge(list&&, _StrictWeakOrdering)): Likewise.
* testsuite/23_containers/list/operations/80034.cc: New.
diff --git a/libstdc++-v3/include/bits/list.tcc 
b/libstdc++-v3/include/bits/list.tcc
index 9623a13..fcb8353 100644
--- a/libstdc++-v3/include/bits/list.tcc
+++ b/libstdc++-v3/include/bits/list.tcc
@@ -405,7 +405,7 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
  }
  __catch(...)
{
- size_t __dist = std::distance(__first2, __last2);
+ const size_t __dist = std::distance(__first2, __last2);
  this->_M_inc_size(__orig_size - __dist);
  __x._M_set_size(__dist);
  __throw_exception_again;
@@ -453,7 +453,7 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
  }
__catch(...)
  {
-   size_t __dist = std::distance(__first2, __last2);
+   const size_t __dist = std::distance(__first2, __last2);
this->_M_inc_size(__orig_size - __dist);
__x._M_set_size(__dist);
__throw_exception_again;
diff --git a/libstdc++-v3/testsuite/23_containers/list/operations/80034.cc 
b/libstdc++-v3/testsuite/23_containers/list/operations/80034.cc
new file mode 100644
index 000..5c3decd
--- /dev/null
+++ b/libstdc++-v3/testsuite/23_containers/list/operations/80034.cc
@@ -0,0 +1,32 @@
+// { dg-do compile }
+// Copyright (C) 2017 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library.  This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+// GNU General Public License for more details.
+
+// You should have received a copy of the GNU General Public License along
+// with this library; see the file COPYING3.  If not see
+// .
+
+#include 
+
+namespace X {
+  struct Y { };
+  bool operator<(Y, Y) { return false; }
+  template
+void distance(T, T) { }
+}
+
+int main()
+{
+  std::list l;
+  l.sort();
+}
diff --git a/libstdc++-v3/include/bits/list.tcc 
b/libstdc++-v3/include/bits/list.tcc
index 81b8be2..81f6f0a 100644
--- a/libstdc++-v3/include/bits/list.tcc
+++ b/libstdc++-v3/include/bits/list.tcc
@@ -386,7 +386,7 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
  iterator __last1 = end();
  iterator __first2 = __x.begin();
  iterator __last2 = __x.end();
- size_t __orig_size = __x.size();
+ const size_t __orig_size = __x.size();
  __try {
while (__first1 != __last1 && __first2 != __last2)
  if (*__first2 < *__first1)
@@ -405,7 +405,7 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
  }
  __catch(...)
{
- size_t __dist = distance(__first2, __last2);
+ const size_t __dist = std::distance(__first2, __last2);
  this->_M_inc_size(__orig_size - __dist);
  __x._M_set_size(__dist);
  __throw_exception_again;
@@ -433,7 +433,7 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
iterator __last1 = end();
iterator __first2 = __x.begin();
iterator __last2 = __x.end();
-   size_t __orig_size = __x.size();
+   const size_t __orig_size = __x.size();
__try
  {
while (__first1 != __last1 && __first2 != __last2)
@@ -453,7 +453,7 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
  }
__catch(...)
  {
-   size_t __dist = distance(__first2, __last2);
+   const size_t __dist = std::distance(__first2, __last2);
this->_M_inc_size(__orig_size - __dist);

Re: [PATCH] libiberty: Initialize d_printing in all cplus_demangle_* functions.

[Pedro Alves]

On 03/13/2017 06:29 PM, Mark Wielaard wrote:

> O, sorry. I should have let Nick known about the gdb regressions I found.
> Besides this patch gdb needs the following one-liner fix:
> 
> diff --git a/gdb/cp-name-parser.y b/gdb/cp-name-parser.y
> index fd1e949..5278c05 100644
> --- a/gdb/cp-name-parser.y
> +++ b/gdb/cp-name-parser.y
> @@ -201,6 +201,7 @@ make_empty (enum demangle_component_type d_type)
>  {
>struct demangle_component *ret = d_grab ();
>ret->type = d_type;
> +  ret->d_printing = 0;
>return ret;
>  }

Should gdb be memsetting instead to avoid having to know about
libiberty's "internals"?  Either version is pre-approved for GDB.

Thanks,
Pedro Alves

Re: [doc] Omit up pointer (DIR) in gcc.texi and gccint.texi?

[Joseph Myers]

On Sat, 11 Mar 2017, Gerald Pfeifer wrote:

> Joseph, Sandra,
> 
> I am thinking about the patch below; what do you think?

I think that as far as possible we should just use "@node node-name" 
without any of the subsequent arguments pointing to other nodes.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [RFC] [PATCH v3 0/8] [i386] Use out-of-line stubs for ms_abi pro/epilogues

[Daniel Santos]

Uros,
Testing on Cygwin only turns out to be a nightmare, but I've finally 
gotten some test results that I'm calling "clean enough".  I have only 
done 64-bit Cygwin thus far, (still need 32-bit Cygwin as well as 32/64 
MinGW), but I've hit a snag.  The first patch set ("Use aligned SSE movs 
for re-aligned MS ABI pro/epilogues" -- 
https://gcc.gnu.org/ml/gcc-patches/2016-12/msg01859.html) modifies how 
we select a base register and offset for accessing the stack. The test 
gcc.target/x86_64/abi/callabi/vaarg-5a.c uses a realigned stack pointer 
in a cross-abi case that triggers an internal compiler error at 
config/i386/winnt.c:1132 where i386_pe_seh_unwind_emit() doesn't like 
REG_CFA_EXPRESSION in the notes. This is the snippet:


  for (note = REG_NOTES (insn); note ; note = XEXP (note,  1))
  {
switch (REG_NOTE_KIND (note))
  {
  case REG_FRAME_RELATED_EXPR:
pat = XEXP (note, 0);
goto found;
  
  case REG_CFA_DEF_CFA:

  case REG_CFA_EXPRESSION:
/* Only emitted with DRAP, which we disable.  */
gcc_unreachable ();
break;


This is the chunk that introduces this new behavior:

@@ -12824,6 +12878,13 @@ ix86_emit_save_reg_using_mov (machine_mode mode, 
unsigned int regno,
}
 }
 
+  else if (base == stack_pointer_rtx && m->fs.sp_realigned

+  && cfa_offset >= m->fs.sp_realigned_offset)
+{
+  gcc_checking_assert (stack_realign_fp);
+  add_reg_note (insn, REG_CFA_EXPRESSION, gen_rtx_SET (mem, reg));
+}
+
   /* The memory may not be relative to the current CFA register,
  which means that we may need to generate a new pattern for
  use by the unwind info.  */

And this is a sample of pre- and post-patch in pro_and_epilogue:

RTL pre-patch:

(insn/f 41 40 42 2 (set (mem/c:V4SF (plus:DI (reg/f:DI 6 bp)
(const_int -160 [0xff60])) [6  S16 A64])
(reg:V4SF 27 xmm6)) 
"/c/Users/daniel/proj/sys/gcc/github/gcc/testsuite/gcc.target/x86_64/abi/callabi/vaarg-5b.c":29
 -1
 (nil))


RTL post-patch:

(insn/f 41 40 42 2 (set (mem/c:V4SF (plus:DI (reg/f:DI 7 sp)
(const_int 48 [0x30])) [6  S16 A128])
(reg:V4SF 27 xmm6)) 
"/c/Users/daniel/proj/sys/gcc/github/gcc/testsuite/gcc.target/x86_64/abi/callabi/vaarg-5b.c":29
 -1
 (expr_list:REG_CFA_EXPRESSION (set (mem/c:V4SF (plus:DI (reg/f:DI 7 sp)
(const_int 48 [0x30])) [6  S16 A128])
(reg:V4SF 27 xmm6))
(nil)))


I haven't learned much of the dwarf code so I can't fully appreciate the 
function of all of these notes, but if we're using the SP should I just 
omit the note and let dwarf intuit the insn? The test in 
i386_pe_seh_unwind_emit() presumes that if we're using 
REG_CFA_EXPRESSION then we've used DRAP, but that isn't the case after 
this patch. Can you please advise on the correct solution?  My current 
guess is to just remove the above chunk (or at least remove the note).


Also of note, I need to do more analysis on why my tests did not expose 
this flaw, since va args is something that it tests.


Thanks!
Daniel

Re: [PATCH] libiberty: Initialize d_printing in all cplus_demangle_* functions.

[Mark Wielaard]

On Mon, Mar 13, 2017 at 07:11:50PM +0100, Markus Trippelsdorf wrote:
> On 2017.03.12 at 23:05 +0100, Mark Wielaard wrote:
> > While integrating the d_printing recursion guard change into gdb I
> > noticed we forgot to initialize the demangle_component d_printing
> > field in cplus_demangle_fill_{name,extended_operator,ctor,dtor}.
> > As is done in cplus_demangle_fill_{component,builtin_type,operator}.
> > It happened to work because in gcc all demangle_components were
> > allocated through d_make_empty. But gdb has its own allocation
> > mechanism (as might other users).
> 
> Nick has synced the binutils-gdb repro with gcc's. 
> I think you should commit your fix as obvious.

Ian just approved it and I checked it in. gcc svn r246105.

> And it would be nice if Nick could sync again, after your patch went in.

O, sorry. I should have let Nick known about the gdb regressions I found.
Besides this patch gdb needs the following one-liner fix:

diff --git a/gdb/cp-name-parser.y b/gdb/cp-name-parser.y
index fd1e949..5278c05 100644
--- a/gdb/cp-name-parser.y
+++ b/gdb/cp-name-parser.y
@@ -201,6 +201,7 @@ make_empty (enum demangle_component_type d_type)
 {
   struct demangle_component *ret = d_grab ();
   ret->type = d_type;
+  ret->d_printing = 0;
   return ret;
 }
 

Cheers,

Mark

Re: FIx riscv port building with the trunk

[Palmer Dabbelt]

On Mon, 13 Mar 2017 10:50:28 PDT (-0700), l...@redhat.com wrote:
>
> RISCV targets were failing to build due to implicit-fallthru warnings.
>
> This changes comments which indicated expected fallthru to use the
> attribute and the port builds again.   I assume something about the use
> of the cpp macro is causing the comment to not have the intended effect.
>   I didn't dig into that.  Nor did I try to change all the fallthru
> comments to use the attribute -- just the two that implicit-fallthru was
> complaining about.
>
> Verified that after this patch the two riscv targets build.  Installed
> on the trunk.
>
> Jeff
>
> commit 448373f1f2912228dc72605fb6f3343fd57023ee
> Author: law 
> Date:   Mon Mar 13 17:49:40 2017 +
>
> * config/riscv/riscv.c (riscv_emit_float_compare): Use fallthru
> attribute rather than comments.
>
> git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@246101 
> 138bc75d-0d04-0410-961f-82ee72b054a4
>
> diff --git a/gcc/ChangeLog b/gcc/ChangeLog
> index 124dca3..e863cdf 100644
> --- a/gcc/ChangeLog
> +++ b/gcc/ChangeLog
> @@ -1,5 +1,8 @@
>  2017-03-13  Jeff Law  
>
> + * config/riscv/riscv.c (riscv_emit_float_compare): Use fallthru
> + attribute rather than comments.
> +
>   * config/pdp11/pdp11.md (movmemhi): Adjust operand numbers to
>   match_scratch operand is highest.
>
> diff --git a/gcc/config/riscv/riscv.c b/gcc/config/riscv/riscv.c
> index 89567f7..e5044ba 100644
> --- a/gcc/config/riscv/riscv.c
> +++ b/gcc/config/riscv/riscv.c
> @@ -2089,13 +2089,13 @@ riscv_emit_float_compare (enum rtx_code *code, rtx 
> *op0, rtx *op1)
>
>  case UNLT:
>std::swap (cmp_op0, cmp_op1);
> -  /* Fall through.  */
> +  __attribute__((fallthrough));
>
>  UNORDERED_COMPARISON(UNGT, le)
>
>  case UNLE:
>std::swap (cmp_op0, cmp_op1);
> -  /* Fall through.  */
> +  __attribute__((fallthrough));
>
>  UNORDERED_COMPARISON(UNGE, lt)
>  #undef UNORDERED_COMPARISON

Thanks!

Re: terminology: zero character vs. null character

[Joseph Myers]

On Sun, 12 Mar 2017, Gerald Pfeifer wrote:

> On Fri, 10 Mar 2017, Manuel López-Ibáñez wrote:
> >> I am currently translating GCC into German. During that, I noticed that
> >> in some places the term "zero character" means '\0'. The official term
> >> though is "null character", as per the C standard.
> > I don't see anything explicit here: 
> > https://gcc.gnu.org/codingconventions.html
> > But I believe we follow standards' language and it should always be "null
> > character".
> 
> Agreed.
> 
> Joseph, do you also agree (and with the patch below to document this)?

Yes.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [PATCH] libiberty: Initialize d_printing in all cplus_demangle_* functions.

[Markus Trippelsdorf]

On 2017.03.12 at 23:05 +0100, Mark Wielaard wrote:
> While integrating the d_printing recursion guard change into gdb I
> noticed we forgot to initialize the demangle_component d_printing
> field in cplus_demangle_fill_{name,extended_operator,ctor,dtor}.
> As is done in cplus_demangle_fill_{component,builtin_type,operator}.
> It happened to work because in gcc all demangle_components were
> allocated through d_make_empty. But gdb has its own allocation
> mechanism (as might other users).

Nick has synced the binutils-gdb repro with gcc's. 
I think you should commit your fix as obvious.

And it would be nice if Nick could sync again, after your patch went in.

-- 
Markus

[PATCH v2, doc] Revise GCC manual section 6.11, Additional Floating Types

[Bill Schmidt]

Hi Joseph,

Thanks for the review!  Re-sending this patch to gcc-patches as I ran 
into MIME problems with my previous reply.

I've made corrections as suggested, and chosen to just remove the 
paragraph describing machine modes.  The typedef descriptions can stand
on their own well enough.

Revised patch below.  Is this ok for trunk?

Thanks,
Bill


2017-03-13  Bill Schmidt  

* doc/extend.texi (6.11 Additional Floating Types): Revise.


Index: gcc/doc/extend.texi
===
--- gcc/doc/extend.texi (revision 246014)
+++ gcc/doc/extend.texi (working copy)
@@ -948,10 +948,28 @@ names can be used together with @code{_Complex} to
 types.
 
 As an extension, GNU C and GNU C++ support additional floating
-types, @code{__float80} and @code{__float128} to support 80-bit
-(@code{XFmode}) and 128-bit (@code{TFmode}) floating types; these are
-aliases for the type names @code{_Float64x} and @code{_Float128}.
-Support for additional types includes the arithmetic operators:
+types, which are not supported by all targets.
+@itemize @bullet
+@item @code{__float128} is available on i386, x86_64, IA-64, and
+hppa HP-UX, as well as on PowerPC 64-bit GNU/Linux targets that enable
+the vector scalar (VSX) instruction set.  @code{__float128} supports
+the 128-bit floating type.  On i386, x86_64, PowerPC, and IA-64
+other than HP-UX, @code{__float128} is an alias for @code{_Float128}.
+On hppa and IA-64 HP-UX, @code{__float128} is an alias for @code{long
+double}.
+
+@item @code{__float80} is available on the i386, x86_64, and IA-64
+targets, and supports the 80-bit (@code{XFmode}) floating type.  It is
+an alias for the type name @code{_Float64x} on these targets.
+
+@item @code{__ibm128} is available on PowerPC targets, and provides
+access to the IBM extended double format which is the current format
+used for @code{long double}.  When @code{long double} transitions to
+@code{__float128} on PowerPC in the future, @code{__ibm128} will remain
+for use in conversions between the two types.
+@end itemize
+
+Support for these additional types includes the arithmetic operators:
 add, subtract, multiply, divide; unary arithmetic operators;
 relational operators; equality operators; and conversions to and from
 integer and other floating types.  Use a suffix @samp{w} or @samp{W}
@@ -958,6 +976,22 @@ integer and other floating types.  Use a suffix @s
 in a literal constant of type @code{__float80} or type
 @code{__ibm128}.  Use a suffix @samp{q} or @samp{Q} for @code{_float128}.
 
+In order to use @code{_Float128}, @code{__float128}, and @code{__ibm128}
+on PowerPC Linux systems, you must use the @option{-mfloat128} option. It is
+expected in future versions of GCC that @code{_Float128} and @code{__float128}
+will be enabled automatically.
+
+The @code{_Float128} type is supported on all systems where
+@code{__float128} is supported or where @code{long double} has the
+IEEE binary128 format.  The @code{_Float64x} type is supported on all
+systems where @code{__float128} is supported.  The @code{_Float32}
+type is supported on all systems supporting IEEE binary32; the
+@code{_Float64} and @code{_Float32x} types are supported on all systems
+supporting IEEE binary64.  The @code{_Float16} type is supported on AArch64
+systems by default, and on ARM systems when the IEEE format for 16-bit
+floating-point types is selected with @option{-mfp16-format=ieee}.
+GCC does not currently support @code{_Float128x} on any systems.
+
 On the i386, x86_64, IA-64, and HP-UX targets, you can declare complex
 types using the corresponding internal complex type, @code{XCmode} for
 @code{__float80} type and @code{TCmode} for @code{__float128} type:
@@ -967,16 +1001,6 @@ typedef _Complex float __attribute__((mode(TC))) _
 typedef _Complex float __attribute__((mode(XC))) _Complex80;
 @end smallexample
 
-In order to use @code{_Float128}, @code{__float128} and
-@code{__ibm128} on PowerPC Linux
-systems, you must use the @option{-mfloat128}. It is expected in
-future versions of GCC that @code{_Float128} and @code{__float128}
-will be enabled
-automatically.  In addition, there are currently problems in using the
-complex @code{__float128} type.  When these problems are fixed, you
-would use the following syntax to declare @code{_Complex128} to be a
-complex @code{__float128} type:
-
 On the PowerPC Linux VSX targets, you can declare complex types using
 the corresponding internal complex type, @code{KCmode} for
 @code{__float128} type and @code{ICmode} for @code{__ibm128} type:
@@ -986,27 +1010,6 @@ typedef _Complex float __attribute__((mode(KC))) _
 typedef _Complex float __attribute__((mode(IC))) _Complex_ibm128;
 @end smallexample
 
-Not all targets support additional floating-point types.
-@code{__float80} and @code{__float128} types are supported on x86 and
-IA-64 targets.  The @code{__float128} type is supported on hppa HP-UX.
-The @code{__float128} type is 

Re: [PATCH] libiberty: Initialize d_printing in all cplus_demangle_* functions.

[Ian Lance Taylor via gcc-patches]

On Sun, Mar 12, 2017 at 3:05 PM, Mark Wielaard  wrote:
> While integrating the d_printing recursion guard change into gdb I
> noticed we forgot to initialize the demangle_component d_printing
> field in cplus_demangle_fill_{name,extended_operator,ctor,dtor}.
> As is done in cplus_demangle_fill_{component,builtin_type,operator}.
> It happened to work because in gcc all demangle_components were
> allocated through d_make_empty. But gdb has its own allocation
> mechanism (as might other users).
>
> libiberty/ChangeLog:
>
>* cp-demangle.c (cplus_demangle_fill_name): Initialize
>demangle_component d_printing.
>(cplus_demangle_fill_extended_operator): Likewise.
>(cplus_demangle_fill_ctor): Likewise.
>(cplus_demangle_fill_dtor): Likewise.

This is OK.

Thanks.

Ian

FIx riscv port building with the trunk

[Jeff Law]

RISCV targets were failing to build due to implicit-fallthru warnings.

This changes comments which indicated expected fallthru to use the 
attribute and the port builds again.   I assume something about the use 
of the cpp macro is causing the comment to not have the intended effect. 
 I didn't dig into that.  Nor did I try to change all the fallthru 
comments to use the attribute -- just the two that implicit-fallthru was 
complaining about.


Verified that after this patch the two riscv targets build.  Installed 
on the trunk.


Jeff

commit 448373f1f2912228dc72605fb6f3343fd57023ee
Author: law 
Date:   Mon Mar 13 17:49:40 2017 +

* config/riscv/riscv.c (riscv_emit_float_compare): Use fallthru
attribute rather than comments.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@246101 
138bc75d-0d04-0410-961f-82ee72b054a4

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 124dca3..e863cdf 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,5 +1,8 @@
 2017-03-13  Jeff Law  
 
+   * config/riscv/riscv.c (riscv_emit_float_compare): Use fallthru
+   attribute rather than comments.
+
* config/pdp11/pdp11.md (movmemhi): Adjust operand numbers to
match_scratch operand is highest.
 
diff --git a/gcc/config/riscv/riscv.c b/gcc/config/riscv/riscv.c
index 89567f7..e5044ba 100644
--- a/gcc/config/riscv/riscv.c
+++ b/gcc/config/riscv/riscv.c
@@ -2089,13 +2089,13 @@ riscv_emit_float_compare (enum rtx_code *code, rtx 
*op0, rtx *op1)
 
 case UNLT:
   std::swap (cmp_op0, cmp_op1);
-  /* Fall through.  */
+  __attribute__((fallthrough));
 
 UNORDERED_COMPARISON(UNGT, le)
 
 case UNLE:
   std::swap (cmp_op0, cmp_op1);
-  /* Fall through.  */
+  __attribute__((fallthrough));
 
 UNORDERED_COMPARISON(UNGE, lt)
 #undef UNORDERED_COMPARISON

Fix pdp11 building with the current trunk

[Jeff Law]

Additional checking of MD files has exposed a bug in the pdp11 backend. 
Namely it has a scratch operand with a lower number than other operands.


This patch adjusts the operand numbers.  I've verified this allows the 
pdp11 backend to build again.  Installed on the trunk.


Jeff

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index a4cd56f..124dca3 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,8 @@
+2017-03-13  Jeff Law  
+
+   * config/pdp11/pdp11.md (movmemhi): Adjust operand numbers to
+   match_scratch operand is highest.
+
 2017-03-13  Martin Liska  
 
PR middle-end/78339
diff --git a/gcc/config/pdp11/pdp11.md b/gcc/config/pdp11/pdp11.md
index ee820f2..dde7711 100644
--- a/gcc/config/pdp11/pdp11.md
+++ b/gcc/config/pdp11/pdp11.md
@@ -373,9 +373,9 @@
   (match_operand:BLK 1 "general_operand" "g,g"))
  (use (match_operand:HI 2 "general_operand" "n,mr"))
  (use (match_operand:HI 3 "immediate_operand" "i,i"))
- (clobber (match_scratch:HI 4 "=,X"))
+ (clobber (match_scratch:HI 6 "=,X"))
+ (clobber (match_dup 4))
  (clobber (match_dup 5))
- (clobber (match_dup 6))
  (clobber (match_dup 2))])]
   "(TARGET_BCOPY_BUILTIN)"
   "
@@ -387,8 +387,8 @@
 = replace_equiv_address (operands[1],
 copy_to_mode_reg (Pmode, XEXP (operands[1], 0)));
 
-  operands[5] = XEXP (operands[0], 0);
-  operands[6] = XEXP (operands[1], 0);
+  operands[4] = XEXP (operands[0], 0);
+  operands[5] = XEXP (operands[1], 0);
 }")
 
 

Re: [v3 PATCH] Implement LWG 2806, Base class of bad_optional_access.

[Jonathan Wakely]

On 12/03/17 13:47 +0200, Ville Voutilainen wrote:

Tested on Linux-x64.

2017-03-12  Ville Voutilainen  

   Implement LWG 2806, Base class of bad_optional_access.
   * include/std/optional (bad_optional_access):
   Derive from std::exception.
   (bad_optional_access::bad_optional_access): Adjust.
   (bad_optional_access::what): New.
   (__throw_bad_optional_access(const char*)):
   Remove the parameter and adjust calls.
   * testsuite/20_util/optional/cons/value_neg.cc: Adjust.
   * testsuite/20_util/optional/typedefs.cc: Likewise.


OK, thanks.

Re: [PATCH] [ADA] Fix bootstrap failure on mips64el-linux-gnuabi64

[James Cowgill]

Hi,

On 11/03/17 12:11, Arnaud Charlet wrote:
>> This patch fixes an error caused by my changing of the signal constants
>> on MIPS in r244026. While that patch worked on mipsel, ada fails to
>> bootstrap with it on mips64el with the error:
>>
>> s-osinte.ads:610:07: component "sa_flags" overlaps "sa_handler" at
>> line 608
>> ../gcc-interface/Makefile:297: recipe for target 'a-dispat.o' failed
>> make[9]: *** [a-dispat.o] Error 1
>>
>> The fix is to adjust the size of sa_flags in struct_sigaction from an
>> unsigned long to an int. I checked the glibc sources and sa_flags is an
>> int on all Linux arches.
> 
> Patch is OK, thanks.

Can you commit it for me?

James

>> gcc/ada/Changelog:
>>
>> 2017-03-10  James Cowgill  
>>
>>  * s-osinte-linux.ads (struct_sigaction): Use correct type for
>>  sa_flags.

[PATCH][PR sanitizer/77631] Support separate debug info in libbacktrace

[Denis Khalikov]

Hello everyone, i have a patch for this issue.

List of implemented functionality:

1.Reading .gnu_debuglink section from ELF file:
 a. Reading name of debug info file.
 b. Verifying crc32 sum.

2. Searching for separate debug info file from paths:
 a. /usr/lib/debug/path/to/executable
 b. /path/to/executable
 c. /path/to/executable/.debug

Assumed that debug info file generated by objcopy from binutils.

objcopy --only-keep-debug foo foo.debug
strip -g foo
objcopy --add-gnu-debuglink=foo.debug foo

commit 6147ee1a9aeeb748563a8998033f2ce195460162
Author: Denis Khalikov 
Date:   Mon Mar 13 18:55:36 2017 +0300

   PR sanitizer/77631
   * Makefile.am: Update to support glinktest.
   * Makefile.in: Regenerated.
   * configure.ac: Add AC_CHECK_PROG for objcopy.
   * configure: Regenerated.
   * elf.c (elf_header_is_valid): New function. Verify elf header.
   (elf_add): Move code which reads elf header to elf_header_is_valid.
   (elf_gnu_debuglink_section): New function. Read debuglink section from
elf.
   (phdr_callback): Call backtrace_open_debugfile function for shared
library.
   * fileline.c (fileline_initialize): Call backtrace_open_debugfile
function for executable.
   * glinktest.c: New test.
   * internal.h (MAX_PATH_LEN): Defined new variable.
   * posix.c (enum type_of_file): New enum.
   (enum debug_path): New enum.
   (getl32): New function.
   (gnu_debuglink_crc32): New function. Generate crc32 sum.
   (get_crc32): New function.
   (pathlen): New function.
   (check_sum): New function. Verify sum.
   (get_debug_filename_len): New function.
   (backtrace_readlink): New function.
   (backtrace_open_debugfile): New function.

diff --git a/libbacktrace/ChangeLog b/libbacktrace/ChangeLog
index 25cd921..cec5d3f 100644
--- a/libbacktrace/ChangeLog
+++ b/libbacktrace/ChangeLog
@@ -1,3 +1,30 @@
+2017-03-13  Denis Khalikov  
+
+   PR sanitizer/77631
+   * Makefile.am: Update to support glinktest.
+   * Makefile.in: Regenerated.
+   * configure: Add script to find objcopy in the system.
+   * elf.c (elf_header_is_valid): New function. Verify elf header.
+   (elf_add): Move code which reads elf header to elf_header_is_valid.
+   (elf_gnu_debuglink_section): New function. Read debuglink section from
+elf.
+   (phdr_callback): Call backtrace_open_debugfile function for shared
+library.
+   * fileline.c (fileline_initialize): Call backtrace_open_debugfile
+function for executable.
+   * glinktest.c: New test.
+   * internal.h (MAX_PATH_LEN): Defined new variable.
+   * posix.c (enum type_of_file): New enum.
+   (enum debug_path): New enum.
+   (getl32): New function.
+   (gnu_debuglink_crc32): New function. Generate crc32 sum.
+   (get_crc32): New function.
+   (pathlen): New function.
+   (check_sum): New function. Verify sum.
+   (get_debug_filename_len): New function.
+   (backtrace_readlink): New function.
+   (backtrace_open_debugfile): New function.
+
 2017-03-08  Sam Thursfield  
 
* btest.c (test5): Replace #ifdef guard with 'unused' attribute
diff --git a/libbacktrace/Makefile.am b/libbacktrace/Makefile.am
index 344dad5..17460a5 100644
--- a/libbacktrace/Makefile.am
+++ b/libbacktrace/Makefile.am
@@ -81,6 +81,17 @@ libbacktrace_la_LIBADD = \
 
 libbacktrace_la_DEPENDENCIES = $(libbacktrace_la_LIBADD)
 
+clean_separate:glinktest.debug
+   rm -f glinktest.debug
+
+separate: glinktest
+   if test -n "$(OBJCOPY)" &&  test -n "$(STRIP)";  \
+   then \
+   $(OBJCOPY) --only-keep-debug glinktest glinktest.debug;\
+   $(STRIP) glinktest;\
+   $(OBJCOPY) --add-gnu-debuglink=glinktest.debug glinktest;\
+   fi;
+
 # Testsuite.
 
 check_PROGRAMS =
@@ -100,6 +111,12 @@ stest_LDADD = libbacktrace.la
 
 check_PROGRAMS += stest
 
+glinktest_SOURCES = glinktest.c
+glinktest_CFLAGS = $(AM_CFLAGS) -g -O
+glinktest_LDADD = libbacktrace.la
+
+check_PROGRAMS += glinktest
+
 endif NATIVE
 
 # We can't use automake's automatic dependency tracking, because it
@@ -134,3 +151,4 @@ sort.lo: config.h backtrace.h internal.h
 stest.lo: config.h backtrace.h internal.h
 state.lo: config.h backtrace.h backtrace-supported.h internal.h
 unknown.lo: config.h backtrace.h internal.h
+glinktest.lo: (INCDIR)/filenames.h backtrace.h backtrace-supported.h
diff --git a/libbacktrace/Makefile.in b/libbacktrace/Makefile.in
index de74b5d..354ecc7 100644
--- a/libbacktrace/Makefile.in
+++ b/libbacktrace/Makefile.in
@@ -84,7 +84,7 @@ build_triplet = @build@
 host_triplet = @host@
 target_triplet = @target@
 check_PROGRAMS = $(am__EXEEXT_1)
-@NATIVE_TRUE@am__append_1 = btest stest
+@NATIVE_TRUE@am__append_1 = btest stest glinktest
 subdir = .
 DIST_COMMON = README ChangeLog 

Re: Updating config.guess

[Jeff Law]

On 03/07/2017 01:01 PM, Gerald Pfeifer wrote:

On Tue, 7 Mar 2017, Jeff Law wrote:

When/if this has been accepted, is it okay to pull the latest config.guess
into GCC even at this stage of the release process?  (We're only looking
at this change and the addition of nsx-tandem compared to what we have
right now.)

If it's just those, I'd think it'd be reasonable.


Here is the entire difference between the config.guess we have
and upstream.


Yea, fine with me.

Jeff

[PATCH 1/3] Error message on target attribute on power target (PR target/79906)

[marxin]

gcc/ChangeLog:

2017-03-13  Martin Liska  

PR target/79906
* config/rs6000/rs6000.c (rs6000_inner_target_options): Show
error message instead of an ICE.

gcc/testsuite/ChangeLog:

2017-03-13  Martin Liska  

PR target/79906
* g++.dg/ext/mv8.C: Add power* targets.
---
 gcc/config/rs6000/rs6000.c | 5 -
 gcc/testsuite/g++.dg/ext/mv8.C | 2 +-
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index a1b58e21450..8bf5ee098dd 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -39204,7 +39204,10 @@ rs6000_inner_target_options (tree args, bool attr_p)
 }
 
   else
-gcc_unreachable ();
+{
+  error ("attribute % argument not a string");
+  return false;
+}
 
   return ret;
 }
diff --git a/gcc/testsuite/g++.dg/ext/mv8.C b/gcc/testsuite/g++.dg/ext/mv8.C
index 2e98dd7ad85..bbf90b5a328 100644
--- a/gcc/testsuite/g++.dg/ext/mv8.C
+++ b/gcc/testsuite/g++.dg/ext/mv8.C
@@ -1,4 +1,4 @@
-// { dg-do compile { target i?86-*-* x86_64-*-* } }
+// { dg-do compile { target i?86-*-* x86_64-*-* powerpc*-*-* } }
 // { dg-options "" }
 
 __attribute__((target (11,12)))
-- 
2.11.1

[PATCH 0/3] Do not ICE on unsupported value of target attribute.

[marxin]

Hello.

There are various targets that support target attribute. However do ICE
when one passes a wrong value. I hope displaying an error message
(similar to what we do on i386) is the proper thing.

Apart from that, multiversioning should not rely on just target ifunc
support.

Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.
Tested with cross-compilers that it does not ICE any longer.

Thanks,
Martin

marxin (3):
  Error message on target attribute on power target (PR target/79906)
  Error message on target attribute on aarch64 target (PR target/79889).
  Verify that target can create a dispatcher call (PR target/79892).

 gcc/config/aarch64/aarch64.c   | 8 ++--
 gcc/config/rs6000/rs6000.c | 5 -
 gcc/multiple_target.c  | 7 +++
 gcc/testsuite/g++.dg/ext/mv8.C | 2 +-
 4 files changed, 18 insertions(+), 4 deletions(-)

-- 
2.11.1

[PATCH 3/3] Verify that target can create a dispatcher call (PR target/79892).

[marxin]

gcc/ChangeLog:

2017-03-13  Martin Liska  

* multiple_target.c (create_dispatcher_calls): Check that
a target can create a function dispatcher.
---
 gcc/multiple_target.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/gcc/multiple_target.c b/gcc/multiple_target.c
index 7b735ae81ae..cb792262d6e 100644
--- a/gcc/multiple_target.c
+++ b/gcc/multiple_target.c
@@ -68,6 +68,13 @@ create_dispatcher_calls (struct cgraph_node *node)
" supported by this target");
  break;
}
+  else if (!targetm.get_function_versions_dispatcher)
+   {
+ error_at (gimple_location (call),
+   "target does not support function version dispatcher");
+ break;
+   }
+
   e_next = e->next_caller;
   idecl = targetm.get_function_versions_dispatcher (decl);
   if (!idecl)
-- 
2.11.1

[PATCH 2/3] Error message on target attribute on aarch64 target (PR target/79889).

[marxin]

gcc/testsuite/ChangeLog:

2017-03-13  Martin Liska  

* g++.dg/ext/mv8.C: Add aarch64* targets.

gcc/ChangeLog:

2017-03-13  Martin Liska  

* config/aarch64/aarch64.c (aarch64_process_target_attr):
Show error message instead of an ICE.
---
 gcc/config/aarch64/aarch64.c   | 8 ++--
 gcc/testsuite/g++.dg/ext/mv8.C | 2 +-
 2 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index a069427f576..3107d6b84bf 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -9533,8 +9533,12 @@ aarch64_process_target_attr (tree args, const char* 
pragma_or_attr)
 
   return true;
 }
-  /* We expect to find a string to parse.  */
-  gcc_assert (TREE_CODE (args) == STRING_CST);
+
+  if (TREE_CODE (args) != STRING_CST)
+{
+  error ("attribute % argument not a string");
+  return false;
+}
 
   size_t len = strlen (TREE_STRING_POINTER (args));
   char *str_to_check = (char *) alloca (len + 1);
diff --git a/gcc/testsuite/g++.dg/ext/mv8.C b/gcc/testsuite/g++.dg/ext/mv8.C
index bbf90b5a328..b49ef84f392 100644
--- a/gcc/testsuite/g++.dg/ext/mv8.C
+++ b/gcc/testsuite/g++.dg/ext/mv8.C
@@ -1,4 +1,4 @@
-// { dg-do compile { target i?86-*-* x86_64-*-* powerpc*-*-* } }
+// { dg-do compile { target i?86-*-* x86_64-*-* powerpc*-*-* aarch64*-*-* } }
 // { dg-options "" }
 
 __attribute__((target (11,12)))
-- 
2.11.1

[PATCH] pahole guided packing

[Richard Biener]

Just skimmed over a pahole -I -H 1 report and came up with the following
(far from complete but should catch stuff that looked important).

Bootstrap / regtest running on x86_64-unknown-linux-gnu.

Richard.

2017-03-13  Richard Biener  

* alias.c (struct alias_set_entry): Pack properly.
* cfgloop.h (struct loop): Likewise.
* cse.c (struct set): Likewise.
* ipa-utils.c (struct searchc_env): Likewise.
* loop-invariant.c (struct invariant): Likewise.
* lra-remat.c (struct cand): Likewise.
* recog.c (struct change_t): Likewise.
* rtl.h (struct address_info): Likewise.
* symbol-summary.h (function_summary): Likewise.
* tree-loop-distribution.c (struct partition): Likewise.
* tree-object-size.c (struct object_size_info): Likewise.
* tree-ssa-loop-ivopts.c (struct cost_pair): Likewise.
* tree-ssa-threadupdate.c (struct ssa_local_info_t): Likewise.
* tree-vect-data-refs.c (struct _vect_peel_info): Likewise.
* tree-vect-slp.c (struct _slp_oprnd_info): Likewise.
* tree-vect-stmts.c (struct simd_call_arg_info): Likewise.
* tree-vectorizer.h (struct _loop_vec_info): Likewise.
(struct _stmt_vec_info): Likewise.

Index: gcc/alias.c
===
--- gcc/alias.c (revision 246082)
+++ gcc/alias.c (working copy)
@@ -126,15 +126,6 @@ struct GTY(()) alias_set_entry {
   /* The alias set number, as stored in MEM_ALIAS_SET.  */
   alias_set_type alias_set;
 
-  /* The children of the alias set.  These are not just the immediate
- children, but, in fact, all descendants.  So, if we have:
-
-   struct T { struct S s; float f; }
-
- continuing our example above, the children here will be all of
- `int', `double', `float', and `struct S'.  */
-  hash_map *children;
-
   /* Nonzero if would have a child of zero: this effectively makes this
  alias set the same as alias set zero.  */
   bool has_zero_child;
@@ -145,6 +136,15 @@ struct GTY(()) alias_set_entry {
   bool is_pointer;
   /* Nonzero if is_pointer or if one of childs have has_pointer set.  */
   bool has_pointer;
+
+  /* The children of the alias set.  These are not just the immediate
+ children, but, in fact, all descendants.  So, if we have:
+
+   struct T { struct S s; float f; }
+
+ continuing our example above, the children here will be all of
+ `int', `double', `float', and `struct S'.  */
+  hash_map *children;
 };
 
 static int rtx_equal_for_memref_p (const_rtx, const_rtx);
Index: gcc/cfgloop.h
===
--- gcc/cfgloop.h   (revision 246082)
+++ gcc/cfgloop.h   (working copy)
@@ -167,21 +167,6 @@ struct GTY ((chain_next ("%h.next"))) lo
  nb_iterations.  */
   widest_int nb_iterations_estimate;
 
-  bool any_upper_bound;
-  bool any_estimate;
-  bool any_likely_upper_bound;
-
-  /* True if the loop can be parallel.  */
-  bool can_be_parallel;
-
-  /* True if -Waggressive-loop-optimizations warned about this loop
- already.  */
-  bool warned_aggressive_loop_optimizations;
-
-  /* An integer estimation of the number of iterations.  Estimate_state
- describes what is the state of the estimation.  */
-  enum loop_estimation estimate_state;
-
   /* If > 0, an integer, where the user asserted that for any
  I in [ 0, nb_iterations ) and for any J in
  [ I, min ( I + safelen, nb_iterations ) ), the Ith and Jth iterations
@@ -211,14 +196,29 @@ struct GTY ((chain_next ("%h.next"))) lo
  that might result in hard to track down bugs in niter/scev consumers.  */
   unsigned constraints;
 
+  /* An integer estimation of the number of iterations.  Estimate_state
+ describes what is the state of the estimation.  */
+  ENUM_BITFIELD(loop_estimation) estimate_state : 8;
+
+  unsigned any_upper_bound : 1;
+  unsigned any_estimate : 1;
+  unsigned any_likely_upper_bound : 1;
+
+  /* True if the loop can be parallel.  */
+  unsigned can_be_parallel : 1;
+
+  /* True if -Waggressive-loop-optimizations warned about this loop
+ already.  */
+  unsigned warned_aggressive_loop_optimizations : 1;
+
   /* True if this loop should never be vectorized.  */
-  bool dont_vectorize;
+  unsigned dont_vectorize : 1;
 
   /* True if we should try harder to vectorize this loop.  */
-  bool force_vectorize;
+  unsigned force_vectorize : 1;
 
   /* True if the loop is part of an oacc kernels region.  */
-  bool in_oacc_kernels_region;
+  unsigned in_oacc_kernels_region : 1;
 
   /* For SIMD loops, this is a unique identifier of the loop, referenced
  by IFN_GOMP_SIMD_VF, IFN_GOMP_SIMD_LANE and IFN_GOMP_SIMD_LAST_LANE
Index: gcc/cse.c
===
--- gcc/cse.c   (revision 246082)
+++ gcc/cse.c   (working copy)
@@ -4154,10 +4154,10 @@ struct set
  The 

[PATCH 2] Fix multiple target clones nodes (PR lto/66295).

[Martin Liška]

Hello.

This is a small follow-up patch, where local.local flag should be also dropped
for a default implementation.

Patch can bootstrap on x86_64-linux-gnu and survives regression tests.

Ready to be installed?
Martin
>From 0d7b793b23e6dad738abaee32a9e0fbf0f4c70c5 Mon Sep 17 00:00:00 2001
From: marxin 
Date: Mon, 13 Mar 2017 09:55:40 +0100
Subject: [PATCH] Fix multiple target clones nodes (PR lto/66295).

gcc/ChangeLog:

2017-03-13  Martin Liska  

	PR lto/66295
	* multiple_target.c (expand_target_clones): Drop local.local
	flag for default implementation.

gcc/testsuite/ChangeLog:

2017-03-13  Martin Liska  

	PR lto/66295
	* gcc.dg/tree-prof/pr66295.c: New test.
---
 gcc/multiple_target.c|  1 +
 gcc/testsuite/gcc.dg/tree-prof/pr66295.c | 34 
 2 files changed, 35 insertions(+)
 create mode 100644 gcc/testsuite/gcc.dg/tree-prof/pr66295.c

diff --git a/gcc/multiple_target.c b/gcc/multiple_target.c
index 7b735ae81ae..4a835bbcc17 100644
--- a/gcc/multiple_target.c
+++ b/gcc/multiple_target.c
@@ -327,6 +327,7 @@ expand_target_clones (struct cgraph_node *node, bool definition)
   tree attributes = make_attribute ("target", "default",
 DECL_ATTRIBUTES (node->decl));
   DECL_ATTRIBUTES (node->decl) = attributes;
+  node->local.local = false;
   location_t saved_loc = input_location;
   input_location = DECL_SOURCE_LOCATION (node->decl);
   bool ret
diff --git a/gcc/testsuite/gcc.dg/tree-prof/pr66295.c b/gcc/testsuite/gcc.dg/tree-prof/pr66295.c
new file mode 100644
index 000..1ab7e6c8f64
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-prof/pr66295.c
@@ -0,0 +1,34 @@
+/* { dg-require-ifunc "" } */
+/* { dg-options "-O2" } */
+
+static double bar (double *__restrict, double *__restrict, int)
+__attribute__ ((target_clones("avx,avx2,avx512f,default")));
+
+double
+foo (double *__restrict a, double *__restrict b, int n)
+{
+  return bar (a,b,n);
+}
+
+double
+bar (double *__restrict a, double *__restrict b, int n)	/* { dg-error "attribute\[^\n\r]*foo\[^\n\r]* is unknown" } */
+{
+  double s;
+  int i;
+  s = 0.0;
+  for (i=0; i

Re: [PATCH] gcov: Mark BBs that do not correspond to a line in source code (PR gcov-profile/79891).

[Richard Biener]

On Mon, 13 Mar 2017, Martin Liška wrote:

> On 03/13/2017 02:53 PM, Richard Biener wrote:
> > On Mon, 13 Mar 2017, Martin Liška wrote:
> > 
> >> On 03/13/2017 02:01 PM, Richard Biener wrote:
> >>> On Mon, 13 Mar 2017, Richard Biener wrote:
> >>>
>  On Fri, 10 Mar 2017, Martin Liška wrote:
> 
> > Hello.
> >
> > As briefly discussed in the PR, there are BB that do not correspond to 
> > a real
> > line in source
> > code. profile.c emits locations for all BBs that have a gimple statement
> > belonging to a line.
> > I hope these should be marked in gcov utility and not added in 
> > --all-block
> > mode to counts of lines.
> >
> > Patch survives make check RUNTESTFLAGS="gcov.exp".
> >
> > Thanks for review and feedback.
> 
>  Humm, the patch doesn't seem to change the BBs associated with a line
>  but rather somehow changes how we compute counts (the patch lacks a
>  description of how you arrived at it).  I expected the line-to-BB
>  assignment process to be changed (whereever that is...).
> >>
> >> Currently, each basic block must belong to a source line. It's how gcov
> >> iterates all blocks (via lines).
> >>
> >>>
> >>> Ah, ok, looking at where output_location is called on I see we do not
> >>> assign any line to that block.  But still why does
> >>> line->has_block (arc->src) return true?
> >>
> >> Good objection! Problematic that  4->5 edge really comes from the same 
> >> line.
> >>
> >>[0.00%]:
> >>   ret_7 = 111;
> >>   PROF_edge_counter_10 = __gcov0.UuT[0];
> >>   PROF_edge_counter_11 = PROF_edge_counter_10 + 1;
> >>   __gcov0.UuT[0] = PROF_edge_counter_11;
> >>
> >>[0.00%]:
> >>   # ret_1 = PHI 
> >>   goto ; [0.00%]
> > 
> > Yes, but that's basically meaningless, unless not all edges come from the
> > same line?  I see nowhere where we'd explicitely assign lines to
> > edges so it must be gcov "reconstructing" this somewhere.
> 
> That's why I added the another flag. We stream locations for basic blocks via
> 'output_location' function. And assignment blocks to lines happens here:
> 
> static void
> add_line_counts (coverage_t *coverage, function_t *fn)
> {
> ...
>   if (!ix || ix + 1 == fn->num_blocks)
>   /* Entry or exit block */;
>   else if (flag_all_blocks)
>   {
> line_t *block_line = line;
> 
> if (!block_line)
>   block_line = [fn->src].lines[fn->line];
> 
> block->chain = block_line->u.blocks;
> block_line->u.blocks = block;
>   }
> 
> where line is always changes when we reach a BB that has a source line 
> assigned. Thus it's changed
> for BB 4 and that's why BB 5 is added to same line.

Ah, so this means we should "clear" the current line for BB 5 in
output_location?  At least I don't see how your patch may not regress
some cases where the line wasn't output as an optimization?

OTOH I don't know much about gcov format.

Richard.

> Martin
> 
> > 
> > Richard.
> > 
> >> Martin
> >>
> >>>
> >>> Richard.
> >>>
> >>
> >>
> > 
> 
> 

-- 
Richard Biener 
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 
21284 (AG Nuernberg)

Re: [PATCH] gcov: Mark BBs that do not correspond to a line in source code (PR gcov-profile/79891).

[Martin Liška]

On 03/13/2017 02:53 PM, Richard Biener wrote:
> On Mon, 13 Mar 2017, Martin Liška wrote:
> 
>> On 03/13/2017 02:01 PM, Richard Biener wrote:
>>> On Mon, 13 Mar 2017, Richard Biener wrote:
>>>
 On Fri, 10 Mar 2017, Martin Liška wrote:

> Hello.
>
> As briefly discussed in the PR, there are BB that do not correspond to a 
> real
> line in source
> code. profile.c emits locations for all BBs that have a gimple statement
> belonging to a line.
> I hope these should be marked in gcov utility and not added in --all-block
> mode to counts of lines.
>
> Patch survives make check RUNTESTFLAGS="gcov.exp".
>
> Thanks for review and feedback.

 Humm, the patch doesn't seem to change the BBs associated with a line
 but rather somehow changes how we compute counts (the patch lacks a
 description of how you arrived at it).  I expected the line-to-BB
 assignment process to be changed (whereever that is...).
>>
>> Currently, each basic block must belong to a source line. It's how gcov
>> iterates all blocks (via lines).
>>
>>>
>>> Ah, ok, looking at where output_location is called on I see we do not
>>> assign any line to that block.  But still why does
>>> line->has_block (arc->src) return true?
>>
>> Good objection! Problematic that  4->5 edge really comes from the same line.
>>
>>[0.00%]:
>>   ret_7 = 111;
>>   PROF_edge_counter_10 = __gcov0.UuT[0];
>>   PROF_edge_counter_11 = PROF_edge_counter_10 + 1;
>>   __gcov0.UuT[0] = PROF_edge_counter_11;
>>
>>[0.00%]:
>>   # ret_1 = PHI 
>>   goto ; [0.00%]
> 
> Yes, but that's basically meaningless, unless not all edges come from the
> same line?  I see nowhere where we'd explicitely assign lines to
> edges so it must be gcov "reconstructing" this somewhere.

That's why I added the another flag. We stream locations for basic blocks via
'output_location' function. And assignment blocks to lines happens here:

static void
add_line_counts (coverage_t *coverage, function_t *fn)
{
...
  if (!ix || ix + 1 == fn->num_blocks)
/* Entry or exit block */;
  else if (flag_all_blocks)
{
  line_t *block_line = line;

  if (!block_line)
block_line = [fn->src].lines[fn->line];

  block->chain = block_line->u.blocks;
  block_line->u.blocks = block;
}

where line is always changes when we reach a BB that has a source line 
assigned. Thus it's changed
for BB 4 and that's why BB 5 is added to same line.

Martin

> 
> Richard.
> 
>> Martin
>>
>>>
>>> Richard.
>>>
>>
>>
> 

Re: [PATCH] gcov: Mark BBs that do not correspond to a line in source code (PR gcov-profile/79891).

[Richard Biener]

On Mon, 13 Mar 2017, Martin Liška wrote:

> On 03/13/2017 02:01 PM, Richard Biener wrote:
> > On Mon, 13 Mar 2017, Richard Biener wrote:
> > 
> >> On Fri, 10 Mar 2017, Martin Liška wrote:
> >>
> >>> Hello.
> >>>
> >>> As briefly discussed in the PR, there are BB that do not correspond to a 
> >>> real
> >>> line in source
> >>> code. profile.c emits locations for all BBs that have a gimple statement
> >>> belonging to a line.
> >>> I hope these should be marked in gcov utility and not added in --all-block
> >>> mode to counts of lines.
> >>>
> >>> Patch survives make check RUNTESTFLAGS="gcov.exp".
> >>>
> >>> Thanks for review and feedback.
> >>
> >> Humm, the patch doesn't seem to change the BBs associated with a line
> >> but rather somehow changes how we compute counts (the patch lacks a
> >> description of how you arrived at it).  I expected the line-to-BB
> >> assignment process to be changed (whereever that is...).
> 
> Currently, each basic block must belong to a source line. It's how gcov
> iterates all blocks (via lines).
> 
> > 
> > Ah, ok, looking at where output_location is called on I see we do not
> > assign any line to that block.  But still why does
> > line->has_block (arc->src) return true?
> 
> Good objection! Problematic that  4->5 edge really comes from the same line.
> 
>[0.00%]:
>   ret_7 = 111;
>   PROF_edge_counter_10 = __gcov0.UuT[0];
>   PROF_edge_counter_11 = PROF_edge_counter_10 + 1;
>   __gcov0.UuT[0] = PROF_edge_counter_11;
> 
>[0.00%]:
>   # ret_1 = PHI 
>   goto ; [0.00%]

Yes, but that's basically meaningless, unless not all edges come from the
same line?  I see nowhere where we'd explicitely assign lines to
edges so it must be gcov "reconstructing" this somewhere.

Richard.

> Martin
> 
> > 
> > Richard.
> > 
> 
> 

-- 
Richard Biener 
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 
21284 (AG Nuernberg)

Re: [PATCH 1/5] Fix *_CST ICEs connected to MPX.

[Martin Liška]

On 03/13/2017 02:07 PM, Richard Biener wrote:
> No, that can't happen.  I said that for example for
> 
> struct S { ... } s;
> foo (s);
> 
> pass_by_reference may be true but on gimple you see a struct s as
> actual argument.  I'm not sure
> what chkp_find_bounds does to 's' in this case.  Like if floats are
> passed by reference you might
> see a REAL_CST passed to chkp_find_bounds but in reality it will get a
> pointer (with bounds
> according to the argument slot that was used).

Currently constants have invalid bounds assigned. Thus I guess it can't cause a 
trouble
when such constant is used as a pointer. Anyhow, the discrepancy should be 
handled better.

Last question related to the patch. May I at least install the part which adds 
{COMPLEX,VECTOR}_CSTs
handling as it can happen with -mabi=ms (where formal and actual args do 
match)? Or using -mabi=ms + CHKP
does not make sense at all?

Martin

Re: [PATCH] gcov: Mark BBs that do not correspond to a line in source code (PR gcov-profile/79891).

[Martin Liška]

On 03/13/2017 02:01 PM, Richard Biener wrote:
> On Mon, 13 Mar 2017, Richard Biener wrote:
> 
>> On Fri, 10 Mar 2017, Martin Liška wrote:
>>
>>> Hello.
>>>
>>> As briefly discussed in the PR, there are BB that do not correspond to a 
>>> real
>>> line in source
>>> code. profile.c emits locations for all BBs that have a gimple statement
>>> belonging to a line.
>>> I hope these should be marked in gcov utility and not added in --all-block
>>> mode to counts of lines.
>>>
>>> Patch survives make check RUNTESTFLAGS="gcov.exp".
>>>
>>> Thanks for review and feedback.
>>
>> Humm, the patch doesn't seem to change the BBs associated with a line
>> but rather somehow changes how we compute counts (the patch lacks a
>> description of how you arrived at it).  I expected the line-to-BB
>> assignment process to be changed (whereever that is...).

Currently, each basic block must belong to a source line. It's how gcov
iterates all blocks (via lines).

> 
> Ah, ok, looking at where output_location is called on I see we do not
> assign any line to that block.  But still why does
> line->has_block (arc->src) return true?

Good objection! Problematic that  4->5 edge really comes from the same line.

   [0.00%]:
  ret_7 = 111;
  PROF_edge_counter_10 = __gcov0.UuT[0];
  PROF_edge_counter_11 = PROF_edge_counter_10 + 1;
  __gcov0.UuT[0] = PROF_edge_counter_11;

   [0.00%]:
  # ret_1 = PHI 
  goto ; [0.00%]

Martin

> 
> Richard.
> 

Re: [PATCH 1/5] Fix *_CST ICEs connected to MPX.

[Richard Biener]

On Mon, Mar 13, 2017 at 2:02 PM, Martin Liška  wrote:
> On 03/13/2017 01:28 PM, Richard Biener wrote:
>> On Thu, Mar 9, 2017 at 12:40 PM, Martin Liška  wrote:
>>> On 03/08/2017 12:00 PM, Richard Biener wrote:
 On Tue, Mar 7, 2017 at 5:01 PM, Martin Liška  wrote:
> On 03/07/2017 03:53 PM, Richard Biener wrote:
>> On Tue, Mar 7, 2017 at 3:48 PM, Martin Liška  wrote:
>>> On 03/07/2017 11:17 AM, Rainer Orth wrote:
 marxin  writes:

> diff --git a/gcc/testsuite/g++.dg/pr79769.C 
> b/gcc/testsuite/g++.dg/pr79769.C
> new file mode 100644
> index 000..f9223db1b2d
> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/pr79769.C
> @@ -0,0 +1,4 @@
> +/* { dg-do compile { target { ! x32 } } } */
> +/* { dg-options "-fcheck-pointer-bounds -mmpx -mabi=ms" } */

 ... and again: make this x86-only.

   Rainer

>>>
>>> Thanks. I'm sending v2 of the patch.
>>
>> Hmm, not sure why we should handle REAL_CST here explicitely for example.
>>
>> Why not, instead of internal_error in the default: case do
>>
>>   bounds = chkp_get_invalid_op_bounds ();
>
> Because chkp_get_invalid_op_bounds() returns bounds that are always valid 
> and as it's
> security extension, I would be strict here in order to not handle 
> something that can bypass
> the checking.
>
>>
>> there?  For the testcase why do we invoke chkp_find_bounds_1 on sth that 
>> is
>> a REAL_CST for example?
>
> It's called when setting bounds in a call expr:
>
> #0  chkp_find_bounds_1 (ptr=0x76a03720, ptr_src=0x76a03720, 
> iter=0x7fffd5d0) at ../../gcc/tree-chkp.c:3734
> #1  0x00ec7c7d in chkp_find_bounds (ptr=0x76a03720, 
> iter=0x7fffd5d0) at ../../gcc/tree-chkp.c:3768
> #2  0x00ec22e1 in chkp_add_bounds_to_call_stmt 
> (gsi=0x7fffd5d0) at ../../gcc/tree-chkp.c:1901
> #3  0x00ec9a1a in chkp_instrument_function () at 
> ../../gcc/tree-chkp.c:4344
> #4  0x00eca4cb in chkp_execute () at ../../gcc/tree-chkp.c:4528
>>>
>>> Yes, as you pointed out, we've got 2 issues here:
>>>

 So this happens for calls with mismatched arguments?  I believe that

   if (BOUNDED_TYPE_P (type)
   || pass_by_reference (NULL, TYPE_MODE (type), type, true))
 new_args.safe_push (chkp_find_bounds (call_arg, gsi));

 may be misguided given pass_by_reference is not exposed at GIMPLE and thus
 for the pass_by_reference case it should fall back to
 "chkp_get_invalid_op_bounds"
 and thus eventually pass this down as a flag to chkp_find_bounds (or check
 on call_arg again).
>>>
>>> Let's consider a VLA, we then call chkp_find_bounds for call_arg equal to
>>>
>>> (gdb) p debug_tree(call_arg)
>>>  >> type >> type >> int>
>>> sizes-gimplified type_1 BLK size >> D.1836> unit size 
>>> align 32 symtab 0 alias set -1 structural equality domain 
>>> 
>>> pointer_to_this >
>>> unsigned DI
>>> size 
>>> unit size 
>>> align 64 symtab 0 alias set -1 structural equality>
>>> visited
>>> def_stmt x.2_7 = x.1_20;
>>> version 7>
>>>
>>> where bounds result in:
>>>   _18 = _6 * 4;
>>>   x.1_20 = __builtin_alloca_with_align (_18, 32);
>>>   __bound_tmp.5_24 = __builtin_ia32_bndmk (x.1_20, _18);
>>>
>>> which is consider fine. I don't understand how can be that broken on gimple 
>>> as it's not exposed
>>> by GIMPLE?
>>
>> Not sure how this relates to my question.
>
> Hi.
>
> You mentioned that GIMPLE does not properly represent passing arguments by 
> reference. And I'm asking
> whether it can happen that pass_by_reference returns true (in tree-chkp) and 
> eventually a call is not
> going to be a pass by reference?

No, that can't happen.  I said that for example for

struct S { ... } s;
foo (s);

pass_by_reference may be true but on gimple you see a struct s as
actual argument.  I'm not sure
what chkp_find_bounds does to 's' in this case.  Like if floats are
passed by reference you might
see a REAL_CST passed to chkp_find_bounds but in reality it will get a
pointer (with bounds
according to the argument slot that was used).

>>

 Note that here 'type' and call_arg may not match (asking for trouble).  
 Plus
 'fntype' is computed bogously (should use gimple_call_fntype).

 It later does sth like

   /* For direct calls fndecl is replaced with instrumented version.  */
   if (fndecl)
 {
   tree new_decl = chkp_maybe_create_clone (fndecl)->decl;
   gimple_call_set_fndecl (new_call, new_decl);
   /* In case of a type cast we should modify used function
  type instead of using type of 

Re: [PATCH 1/5] Fix *_CST ICEs connected to MPX.

[Martin Liška]

On 03/13/2017 01:28 PM, Richard Biener wrote:
> On Thu, Mar 9, 2017 at 12:40 PM, Martin Liška  wrote:
>> On 03/08/2017 12:00 PM, Richard Biener wrote:
>>> On Tue, Mar 7, 2017 at 5:01 PM, Martin Liška  wrote:
 On 03/07/2017 03:53 PM, Richard Biener wrote:
> On Tue, Mar 7, 2017 at 3:48 PM, Martin Liška  wrote:
>> On 03/07/2017 11:17 AM, Rainer Orth wrote:
>>> marxin  writes:
>>>
 diff --git a/gcc/testsuite/g++.dg/pr79769.C 
 b/gcc/testsuite/g++.dg/pr79769.C
 new file mode 100644
 index 000..f9223db1b2d
 --- /dev/null
 +++ b/gcc/testsuite/g++.dg/pr79769.C
 @@ -0,0 +1,4 @@
 +/* { dg-do compile { target { ! x32 } } } */
 +/* { dg-options "-fcheck-pointer-bounds -mmpx -mabi=ms" } */
>>>
>>> ... and again: make this x86-only.
>>>
>>>   Rainer
>>>
>>
>> Thanks. I'm sending v2 of the patch.
>
> Hmm, not sure why we should handle REAL_CST here explicitely for example.
>
> Why not, instead of internal_error in the default: case do
>
>   bounds = chkp_get_invalid_op_bounds ();

 Because chkp_get_invalid_op_bounds() returns bounds that are always valid 
 and as it's
 security extension, I would be strict here in order to not handle 
 something that can bypass
 the checking.

>
> there?  For the testcase why do we invoke chkp_find_bounds_1 on sth that 
> is
> a REAL_CST for example?

 It's called when setting bounds in a call expr:

 #0  chkp_find_bounds_1 (ptr=0x76a03720, ptr_src=0x76a03720, 
 iter=0x7fffd5d0) at ../../gcc/tree-chkp.c:3734
 #1  0x00ec7c7d in chkp_find_bounds (ptr=0x76a03720, 
 iter=0x7fffd5d0) at ../../gcc/tree-chkp.c:3768
 #2  0x00ec22e1 in chkp_add_bounds_to_call_stmt 
 (gsi=0x7fffd5d0) at ../../gcc/tree-chkp.c:1901
 #3  0x00ec9a1a in chkp_instrument_function () at 
 ../../gcc/tree-chkp.c:4344
 #4  0x00eca4cb in chkp_execute () at ../../gcc/tree-chkp.c:4528
>>
>> Yes, as you pointed out, we've got 2 issues here:
>>
>>>
>>> So this happens for calls with mismatched arguments?  I believe that
>>>
>>>   if (BOUNDED_TYPE_P (type)
>>>   || pass_by_reference (NULL, TYPE_MODE (type), type, true))
>>> new_args.safe_push (chkp_find_bounds (call_arg, gsi));
>>>
>>> may be misguided given pass_by_reference is not exposed at GIMPLE and thus
>>> for the pass_by_reference case it should fall back to
>>> "chkp_get_invalid_op_bounds"
>>> and thus eventually pass this down as a flag to chkp_find_bounds (or check
>>> on call_arg again).
>>
>> Let's consider a VLA, we then call chkp_find_bounds for call_arg equal to
>>
>> (gdb) p debug_tree(call_arg)
>>  > type > type > int>
>> sizes-gimplified type_1 BLK size > D.1836> unit size 
>> align 32 symtab 0 alias set -1 structural equality domain 
>> 
>> pointer_to_this >
>> unsigned DI
>> size 
>> unit size 
>> align 64 symtab 0 alias set -1 structural equality>
>> visited
>> def_stmt x.2_7 = x.1_20;
>> version 7>
>>
>> where bounds result in:
>>   _18 = _6 * 4;
>>   x.1_20 = __builtin_alloca_with_align (_18, 32);
>>   __bound_tmp.5_24 = __builtin_ia32_bndmk (x.1_20, _18);
>>
>> which is consider fine. I don't understand how can be that broken on gimple 
>> as it's not exposed
>> by GIMPLE?
> 
> Not sure how this relates to my question.

Hi.

You mentioned that GIMPLE does not properly represent passing arguments by 
reference. And I'm asking
whether it can happen that pass_by_reference returns true (in tree-chkp) and 
eventually a call is not
going to be a pass by reference?

> 
>>>
>>> Note that here 'type' and call_arg may not match (asking for trouble).  Plus
>>> 'fntype' is computed bogously (should use gimple_call_fntype).
>>>
>>> It later does sth like
>>>
>>>   /* For direct calls fndecl is replaced with instrumented version.  */
>>>   if (fndecl)
>>> {
>>>   tree new_decl = chkp_maybe_create_clone (fndecl)->decl;
>>>   gimple_call_set_fndecl (new_call, new_decl);
>>>   /* In case of a type cast we should modify used function
>>>  type instead of using type of new fndecl.  */
>>>   if (gimple_call_fntype (call) != TREE_TYPE (fndecl))
>>> {
>>>   tree type = gimple_call_fntype (call);
>>>   type = chkp_copy_function_type_adding_bounds (type);
>>>   gimple_call_set_fntype (new_call, type);
>>> }
>>>   else
>>> gimple_call_set_fntype (new_call, TREE_TYPE (new_decl));
>>>
>>> but obviously if gimple_call_fntype and fndecl don't match cloning
>>> the mismatched decl isn't of very much help ... (it may just generate
>>> more mismatches with mismatching bounds...).
>>
>> That second issue should be probably fixed by 

RE: [PATCH 0/2] [ARC] Two small patches to fix faulty instruction patterns.

[Claudiu Zissulescu]

Hi
> 
> Sorry for the delay, both of these look fine.
> 

No issue here :) All the last patches were successfully committed with the 
specified mods.

Thank you for your review,
Claudiu

Re: [PATCH] gcov: Mark BBs that do not correspond to a line in source code (PR gcov-profile/79891).

[Richard Biener]

On Mon, 13 Mar 2017, Richard Biener wrote:

> On Fri, 10 Mar 2017, Martin Liška wrote:
> 
> > Hello.
> > 
> > As briefly discussed in the PR, there are BB that do not correspond to a 
> > real
> > line in source
> > code. profile.c emits locations for all BBs that have a gimple statement
> > belonging to a line.
> > I hope these should be marked in gcov utility and not added in --all-block
> > mode to counts of lines.
> > 
> > Patch survives make check RUNTESTFLAGS="gcov.exp".
> > 
> > Thanks for review and feedback.
> 
> Humm, the patch doesn't seem to change the BBs associated with a line
> but rather somehow changes how we compute counts (the patch lacks a
> description of how you arrived at it).  I expected the line-to-BB
> assignment process to be changed (whereever that is...).

Ah, ok, looking at where output_location is called on I see we do not
assign any line to that block.  But still why does
line->has_block (arc->src) return true?

Richard.

Re: [PATCH] gcov: Mark BBs that do not correspond to a line in source code (PR gcov-profile/79891).

[Richard Biener]

On Fri, 10 Mar 2017, Martin Liška wrote:

> Hello.
> 
> As briefly discussed in the PR, there are BB that do not correspond to a real
> line in source
> code. profile.c emits locations for all BBs that have a gimple statement
> belonging to a line.
> I hope these should be marked in gcov utility and not added in --all-block
> mode to counts of lines.
> 
> Patch survives make check RUNTESTFLAGS="gcov.exp".
> 
> Thanks for review and feedback.

Humm, the patch doesn't seem to change the BBs associated with a line
but rather somehow changes how we compute counts (the patch lacks a
description of how you arrived at it).  I expected the line-to-BB
assignment process to be changed (whereever that is...).

Richard.

> Martin
> 
> 

-- 
Richard Biener 
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 
21284 (AG Nuernberg)

Re: [PR 77333] Fix fntypes of calls calling clones

[Richard Biener]

On Fri, 10 Mar 2017, Martin Jambor wrote:

> Hi,
> 
> PR 77333 is a i686-windows target bug, which however has its root in
> our general mechanism of adjusting gimple statements when redirecting
> call graph edge.  Basically, these three things trigger it:
> 
> 1) IPA-CP figures out that the this parameter of a C++ class method is
>unused and because the class is in an anonymous namespace, it can
>be removed and all calls adjusted.  That effectively changes a
>normal method into a static method and so internally, its type
>changes from METHOD_TYPE to FUNCTION_TYPE.
> 
> 2) Since the fix of PR 57330, we do not update gimple_call_fntype to
>match the new type, in fact we explicitely set it to the old, now
>invalid, type (see redirect_call_stmt_to_callee in cgraph.c).
> 
> 3) Function ix86_get_callcvt which decides on call ABI, ends with the
>following condition:
> 
>  if (ret != 0
>  || is_stdarg
>  || TREE_CODE (type) != METHOD_TYPE
>  || ix86_function_type_abi (type) != MS_ABI)
>return IX86_CALLCVT_CDECL | ret;
> 
>  return IX86_CALLCVT_THISCALL;
> 
>...and since now the callee is no longer a METHOD_TYPE but callers
>still think that they are, leading to calling convention mismatches
>and subsequent crashes.  It took me quite a lot of time to come up
>with a small testcase (reproducible using wine) but eventually I
>managed.
> 
> The fix is not to do 2) above, but doing so without re-introducing PR
> 57330, of course.  There are two options.  One is to use the
> call_stmt_cannot_inline_p flag of call-graph edges and not do any
> IPA-CP accross those edges.  That is done in the patch below.  The (so
> far a bit hypothetical) problem with that approach is that the call
> graph edge flag may not be 100% reliable in LTO, because incompatible
> decls might get merged and then we wold re-introduce PR 57330 again -
> only with on invalid code and with LTO but an ICE nevertheless.

So you mean replacing a matching decl with a non-matching and thus
during symtab merge introduce the issue.  You could detect whenever
merging incompatible symbols and set ->cannot_change_signature on
the prevailing node though?

But how do we deal with devirt here?  That is propagation itself
may introduce (knowledge of) the incompatibility...

In general I am sympathetic with not doing any IPA propagation
across call stmt signature incompatibilties.  Of course we may
be still too strict in those compatibility check...

> So the alternative would be to re-check when doing the gimple
> statement adjustment and if the types match, then set the correct new
> gimple_fntype and if they don't... then we can either leave it be or
> just run the same type transformation on it as we did on the callee,
> though they would be bogus either way.  That is implemented in the
> attached patch.

As we _do_ adjust the call (apply the transform to its actual
arguments) we should apply the same transform to
gimple_call_fntype.  We can avoid doing duplicate work in case
the old fndecl (do we still have that around?) matched fntype.

I think the common case of "mismatches" is having them with
respect to the "extern" declaration but then the implementation
is actually ok (otherwise people would run into runtime issues).

I wonder what we do to IPA-SRA-kind of transforms ... (as it's early
it's much easier to just not do anything about those at this point).

> I have successfully bootstrapped both patches on x86_64-linux and I
> have also tested them both on a windows cross-compiler and wine (with
> some noise but I believe it is just noise).
> 
> Honza, Richi, do you prefer any one approach over the other?
> Actually, we can have both, would that be desirable?

I think I'd like to see statistics for say, SPEC, how many
cgraph edges we disable transforms for.  For correctness I'd simply
do the same transform to fntype as to the actual stmt (which of course
has some cost).

Richard.

> Thanks,
> 
> Martin
> 
> 
> 2017-03-02  Martin Jambor  
> 
>   PR ipa/77333
>   * ipa-prop.h (ipa_node_params): New field call_stmt_type_mismatch.
>   (ipa_node_params::ipa_node_params): Initialize it to zero.
>   * cgraph.c (redirect_call_stmt_to_callee): Set gimple fntype to
>   the type of the new target.
>   * ipa-cp.c (propagate_constants_across_call): Set variable flag of
>   lattices and call_stmt_type_mismatch of the callee when
>   encountering an edge with mismatched types.
>   (estimate_local_effects): Do not clone for all contexts when
>   call_stmt_type_mismatch is set.
> 
> testsuite/
>   * g++.dg/ipa/pr77333.C: New test.
> ---
>  gcc/cgraph.c   |  2 +-
>  gcc/ipa-cp.c   | 11 ---
>  gcc/ipa-prop.h |  4 ++-
>  gcc/testsuite/g++.dg/ipa/pr77333.C | 65 
> ++
>  4 files changed, 76 insertions(+), 6 deletions(-)
>  create 

Re: [PATCH 6/N] Do not warn -Wsuggest-attribute=noreturn for main.chkp (PR, middle-end/78339).

[Richard Biener]

On Thu, Mar 9, 2017 at 3:19 PM, Martin Liška  wrote:
> Hello.
>
> Following patch fixes issue by checking original declaration instead
> of instrumentation clone.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed?

Ok.

RIchard.

> Martin

Re: [PATCH 1/5] Fix *_CST ICEs connected to MPX.

[Richard Biener]

On Thu, Mar 9, 2017 at 12:40 PM, Martin Liška  wrote:
> On 03/08/2017 12:00 PM, Richard Biener wrote:
>> On Tue, Mar 7, 2017 at 5:01 PM, Martin Liška  wrote:
>>> On 03/07/2017 03:53 PM, Richard Biener wrote:
 On Tue, Mar 7, 2017 at 3:48 PM, Martin Liška  wrote:
> On 03/07/2017 11:17 AM, Rainer Orth wrote:
>> marxin  writes:
>>
>>> diff --git a/gcc/testsuite/g++.dg/pr79769.C 
>>> b/gcc/testsuite/g++.dg/pr79769.C
>>> new file mode 100644
>>> index 000..f9223db1b2d
>>> --- /dev/null
>>> +++ b/gcc/testsuite/g++.dg/pr79769.C
>>> @@ -0,0 +1,4 @@
>>> +/* { dg-do compile { target { ! x32 } } } */
>>> +/* { dg-options "-fcheck-pointer-bounds -mmpx -mabi=ms" } */
>>
>> ... and again: make this x86-only.
>>
>>   Rainer
>>
>
> Thanks. I'm sending v2 of the patch.

 Hmm, not sure why we should handle REAL_CST here explicitely for example.

 Why not, instead of internal_error in the default: case do

   bounds = chkp_get_invalid_op_bounds ();
>>>
>>> Because chkp_get_invalid_op_bounds() returns bounds that are always valid 
>>> and as it's
>>> security extension, I would be strict here in order to not handle something 
>>> that can bypass
>>> the checking.
>>>

 there?  For the testcase why do we invoke chkp_find_bounds_1 on sth that is
 a REAL_CST for example?
>>>
>>> It's called when setting bounds in a call expr:
>>>
>>> #0  chkp_find_bounds_1 (ptr=0x76a03720, ptr_src=0x76a03720, 
>>> iter=0x7fffd5d0) at ../../gcc/tree-chkp.c:3734
>>> #1  0x00ec7c7d in chkp_find_bounds (ptr=0x76a03720, 
>>> iter=0x7fffd5d0) at ../../gcc/tree-chkp.c:3768
>>> #2  0x00ec22e1 in chkp_add_bounds_to_call_stmt (gsi=0x7fffd5d0) 
>>> at ../../gcc/tree-chkp.c:1901
>>> #3  0x00ec9a1a in chkp_instrument_function () at 
>>> ../../gcc/tree-chkp.c:4344
>>> #4  0x00eca4cb in chkp_execute () at ../../gcc/tree-chkp.c:4528
>
> Yes, as you pointed out, we've got 2 issues here:
>
>>
>> So this happens for calls with mismatched arguments?  I believe that
>>
>>   if (BOUNDED_TYPE_P (type)
>>   || pass_by_reference (NULL, TYPE_MODE (type), type, true))
>> new_args.safe_push (chkp_find_bounds (call_arg, gsi));
>>
>> may be misguided given pass_by_reference is not exposed at GIMPLE and thus
>> for the pass_by_reference case it should fall back to
>> "chkp_get_invalid_op_bounds"
>> and thus eventually pass this down as a flag to chkp_find_bounds (or check
>> on call_arg again).
>
> Let's consider a VLA, we then call chkp_find_bounds for call_arg equal to
>
> (gdb) p debug_tree(call_arg)
>   type  type 
> sizes-gimplified type_1 BLK size  
> unit size 
> align 32 symtab 0 alias set -1 structural equality domain 
> 
> pointer_to_this >
> unsigned DI
> size 
> unit size 
> align 64 symtab 0 alias set -1 structural equality>
> visited
> def_stmt x.2_7 = x.1_20;
> version 7>
>
> where bounds result in:
>   _18 = _6 * 4;
>   x.1_20 = __builtin_alloca_with_align (_18, 32);
>   __bound_tmp.5_24 = __builtin_ia32_bndmk (x.1_20, _18);
>
> which is consider fine. I don't understand how can be that broken on gimple 
> as it's not exposed
> by GIMPLE?

Not sure how this relates to my question.

>>
>> Note that here 'type' and call_arg may not match (asking for trouble).  Plus
>> 'fntype' is computed bogously (should use gimple_call_fntype).
>>
>> It later does sth like
>>
>>   /* For direct calls fndecl is replaced with instrumented version.  */
>>   if (fndecl)
>> {
>>   tree new_decl = chkp_maybe_create_clone (fndecl)->decl;
>>   gimple_call_set_fndecl (new_call, new_decl);
>>   /* In case of a type cast we should modify used function
>>  type instead of using type of new fndecl.  */
>>   if (gimple_call_fntype (call) != TREE_TYPE (fndecl))
>> {
>>   tree type = gimple_call_fntype (call);
>>   type = chkp_copy_function_type_adding_bounds (type);
>>   gimple_call_set_fntype (new_call, type);
>> }
>>   else
>> gimple_call_set_fntype (new_call, TREE_TYPE (new_decl));
>>
>> but obviously if gimple_call_fntype and fndecl don't match cloning
>> the mismatched decl isn't of very much help ... (it may just generate
>> more mismatches with mismatching bounds...).
>
> That second issue should be probably fixed by comparing each formal and 
> actual arguments,
> where for a mismatch an invalid bounds should be returned? Am I right?

It's hard to say what to do for calls through incompatible tyes.  I'd
say it should use
the not instrumented copy (which there may be none if the function was
static and we
didn't need a clone?).  After all we're likely passing garbage to the
function anyway.

Richard.

> Martin
>
>>
>>> ...
>>>
>>> Martin
>>>

 

[C++ PATCH] 79393 fix

[Nathan Sidwell]

The resolution to DR 1658 causes vbases of abstract classes to be 
ignored when building the cdtors.  That made sense for ctors, when there 
might be no default ctor available.  But for dtors, there is only oe 
dtor and they can be virtual.  That can break virtual overriding, as 
79393 discovered.


I've reported this as a DR, but so GCC 7 doesn't break currently working 
code, I've committed this patch to skip that part of 1658's resolution.


The inhibiting of access checks was needed of pr66443-cxx14-3.C to 
continue passing.  That's a case where the vbase's dtor is inaccessible 
from the abstract base.  That seemed like the most conservative way to 
inhibit 1658's impact by allowing the most code to be compiled, but of 
course is speculative.


nathan
--
Nathan Sidwell
2017-03-13  Nathan Sidwell  

	PR c++/79393 DR 1658 workaround
	* method.c (synthesized_method_walk): Check vbases of abstract
	classes for dtor walk.

Index: cp/method.c
===
--- cp/method.c	(revision 246084)
+++ cp/method.c	(working copy)
@@ -1664,12 +1664,26 @@ synthesized_method_walk (tree ctype, spe
 /* Already examined vbases above.  */;
   else if (vec_safe_is_empty (vbases))
 /* No virtual bases to worry about.  */;
-  else if (ABSTRACT_CLASS_TYPE_P (ctype) && cxx_dialect >= cxx14)
+  else if (ABSTRACT_CLASS_TYPE_P (ctype) && cxx_dialect >= cxx14
+	   /* DR 1658 specifies that vbases of abstract classes are
+	  ignored for both ctors and dtors.  However, that breaks
+	  virtual dtor overriding when the ignored base has a
+	  throwing destructor.  So, ignore that piece of 1658.  A
+	  defect has been filed (no number yet).  */
+	   && sfk != sfk_destructor)
 /* Vbase cdtors are not relevant.  */;
   else
 {
   if (constexpr_p)
 	*constexpr_p = false;
+
+  /* To be conservative, ignore access to the base dtor that
+	 DR1658 instructs us to ignore.  */
+  bool no_access_check = (cxx_dialect >= cxx14
+			  && ABSTRACT_CLASS_TYPE_P (ctype));
+
+  if (no_access_check)
+	push_deferring_access_checks (dk_no_check);
   FOR_EACH_VEC_ELT (*vbases, i, base_binfo)
 	synthesized_method_base_walk (binfo, base_binfo, quals,
   copy_arg_p, move_p, ctor_p,
@@ -1677,6 +1691,8 @@ synthesized_method_walk (tree ctype, spe
   fnname, flags, diag,
   spec_p, trivial_p,
   deleted_p, constexpr_p);
+  if (no_access_check)
+	pop_deferring_access_checks ();
 }
 
   /* Now handle the non-static data members.  */
Index: testsuite/g++.dg/cpp1y/pr79393.C
===
--- testsuite/g++.dg/cpp1y/pr79393.C	(revision 0)
+++ testsuite/g++.dg/cpp1y/pr79393.C	(working copy)
@@ -0,0 +1,21 @@
+// { dg-do compile { target c++14 } }
+// PR c++/79393 deduced eh spec, deleted dtors and vbases
+
+struct A3;
+
+struct VDT {
+  virtual ~VDT () noexcept (false);
+};
+
+struct A1 : virtual VDT {
+  virtual void abstract () = 0;
+};
+
+struct A2 : A1 {  };
+
+struct A3 : A2 
+{
+  virtual void abstract ();
+};
+
+A3 a3;

Re: install.texi and arm

[Nick Clifton]

Hi Guys,

>>> References to dependencies on really, really old versions of
>>> binutils (talking 10+ years here) which I think we can remove.

>>ARM-family processors.  Subtargets that use the ELF object format
>>require GNU binutils 2.13 or newer.  Such subtargets include:

>> Okay to yank this?
> 
> Fine by me.

Me too.

> Nick, do you have any objections to this?

None.  Are you intending to replace the requirement with a more recent
version of the binutils, or just remove the requirement entirely ?

Cheers
  Nick

Re: [PATCH][ARM] PR target/79911: Invalid vec_select arguments

[Richard Earnshaw (lists)]

On 08/03/17 10:34, Kyrill Tkachov wrote:
> Hi all,
> 
> This patch fixes the NEON patterns with Jakub's genrecog verification
> improvements:
> ../../gcc/config/arm/neon.md:1338:1: element mode mismatch between
> vec_select HImode and its operand QImode
> ../../gcc/config/arm/neon.md:1338:1: element mode mismatch between
> vec_select SImode and its operand QImode
> ../../gcc/config/arm/neon.md:1338:1: element mode mismatch between
> vec_select QImode and its operand HImode
> ../../gcc/config/arm/neon.md:1338:1: element mode mismatch between
> vec_select SImode and its operand HImode
> ../../gcc/config/arm/neon.md:1338:1: element mode mismatch between
> vec_select QImode and its operand SImode
> ../../gcc/config/arm/neon.md:1338:1: element mode mismatch between
> vec_select HImode and its operand SImode
> ../../gcc/config/arm/neon.md:1353:1: element mode mismatch between
> vec_select HImode and its operand QImode
> ../../gcc/config/arm/neon.md:1353:1: element mode mismatch between
> vec_select SImode and its operand QImode
> ../../gcc/config/arm/neon.md:1353:1: element mode mismatch between
> vec_select QImode and its operand HImode
> ../../gcc/config/arm/neon.md:1353:1: element mode mismatch between
> vec_select SImode and its operand HImode
> ../../gcc/config/arm/neon.md:1353:1: element mode mismatch between
> vec_select QImode and its operand SImode
> ../../gcc/config/arm/neon.md:1353:1: element mode mismatch between
> vec_select HImode and its operand SImode
> ../../gcc/config/arm/neon.md:1407:1: element mode mismatch between
> vec_select HImode and its operand QImode
> ../../gcc/config/arm/neon.md:1407:1: element mode mismatch between
> vec_select SImode and its operand QImode
> ../../gcc/config/arm/neon.md:1407:1: element mode mismatch between
> vec_select QImode and its operand HImode
> ../../gcc/config/arm/neon.md:1407:1: element mode mismatch between
> vec_select SImode and its operand HImode
> ../../gcc/config/arm/neon.md:1407:1: element mode mismatch between
> vec_select QImode and its operand SImode
> ../../gcc/config/arm/neon.md:1407:1: element mode mismatch between
> vec_select HImode and its operand SImode
> ../../gcc/config/arm/neon.md:1422:1: element mode mismatch between
> vec_select HImode and its operand QImode
> ../../gcc/config/arm/neon.md:1422:1: element mode mismatch between
> vec_select SImode and its operand QImode
> ../../gcc/config/arm/neon.md:1422:1: element mode mismatch between
> vec_select QImode and its operand HImode
> ../../gcc/config/arm/neon.md:1422:1: element mode mismatch between
> vec_select SImode and its operand HImode
> ../../gcc/config/arm/neon.md:1422:1: element mode mismatch between
> vec_select QImode and its operand SImode
> ../../gcc/config/arm/neon.md:1422:1: element mode mismatch between
> vec_select HImode and its operand SImode
> 
> The problem is that the affected patterns use both the VQI iterator
> [V16QI V8HI V4SI] and the
> VW iterator [V8QI V4HI V2SI]. The intent was to use V8QI when VQI
> returned V16QI, V4HI when VQI returned V8HI etc.
> But using both iterators at the same time creates a cartesian product of
> combinations, so the iterators expanded
> to some patterns that are not valid that is, the inner mode of the
> vec_select mode being not the same as the
> inner mode of its vector argument.
> 
> This patch fixes that by using the appropriate V_HALF mode attribute
> instead of the VW iterator, so VQI is the only
> real mode iterator used in these patterns. I took care to leave the
> expanded name of each pattern the same so that
> their gen_* invocations from widen_ssum3 and widen_usum3
> remain the same.
> 
> With this patch the arm backend passes the genrecog validations.
> 
> Bootstrapped and tested on arm-none-linux-gnueabihf.
> 
> Ok for trunk?
> 
> Thanks,
> Kyrill
> 
> 
> 2017-03-08  Kyrylo Tkachov  
> 
> PR target/79911
> * config/arm/neon.md (vec_sel_widen_ssum_lo3):
> Rename to...
> (vec_sel_widen_ssum_lo3): ... This. Avoid mismatch
> between vec_select and vector argument.
> (vec_sel_widen_ssum_hi3): Rename to...
> (vec_sel_widen_ssum_hi3): ... This. Likewise.
> (vec_sel_widen_usum_lo3): Rename to...
> (vec_sel_widen_usum_lo3): ... This.
> (vec_sel_widen_usum_hi3): Rename to...
> (vec_sel_widen_usum_hi3): ... This.
> 

OK.

R.

> arm-vec-select.patch
> 
> 
> diff --git a/gcc/config/arm/neon.md b/gcc/config/arm/neon.md
> index cf281df..50d89eb 100644
> --- a/gcc/config/arm/neon.md
> +++ b/gcc/config/arm/neon.md
> @@ -1335,14 +1335,14 @@ (define_expand "widen_ssum3"
>}
>  )
>  
> -(define_insn "vec_sel_widen_ssum_lo3"
> -  [(set (match_operand: 0 "s_register_operand" "=w")
> - (plus:
> -  (sign_extend:
> -   (vec_select:VW
> +(define_insn "vec_sel_widen_ssum_lo3"
> +  [(set (match_operand: 0 "s_register_operand" "=w")
> + (plus:
> +  (sign_extend:
> +   (vec_select:
>  (match_operand:VQI 1 "s_register_operand" "%w")
>  

Re: install.texi and avr (was: Target maintainers: doc/install.texi love and care)

[Denis Chertykov]

2017-03-12 15:32 GMT+04:00 Gerald Pfeifer :
> On Sun, 12 Mar 2017, Gerald Pfeifer wrote:
>> Also, I'm offering help around one particular aspect I noticed:
>>
>> References to dependencies on really, really old versions of
>> binutils (talking 10+ years here) which I think we can remove.
>> Let me follow-up with some of you with concrete suggestions
>> around that.
>
> The avr section currently has this:
>
>   We @emph{strongly} recommend using binutils 2.13 or newer.
>
> Okay to yank it?

We can remove this line.

Denis

Re: install.texi and arm

[Kyrill Tkachov]

On 12/03/17 11:31, Gerald Pfeifer wrote:

On Sun, 12 Mar 2017, Gerald Pfeifer wrote:

Also, I'm offering help around one particular aspect I noticed:

References to dependencies on really, really old versions of
binutils (talking 10+ years here) which I think we can remove.
Let me follow-up with some of you with concrete suggestions
around that.

The arm-*-eabi section currently has this:

   ARM-family processors.  Subtargets that use the ELF object format
   require GNU binutils 2.13 or newer.  Such subtargets include:
   @code{arm-*-netbsdelf}, @code{arm-*-*linux-*}
   and @code{arm-*-rtemseabi}.

Okay to yank this?


Fine by me. Nick is much more involved in binutils development and so might have
a better view of how much older binutils are used in the wild though.
Nick, do you have any objections to this?

Thanks,
Kyrill


Gerald

[PATCH] Fix PR79991

[Richard Biener]

Built on x86_64-unknown-linux-gnu, applied.

Richard

2017-03-13  Richard Biener  

PR other/79991
* params.def (vect-max-peeling-for-alignment): Fix typo.

Index: gcc/params.def
===
--- gcc/params.def  (revision 246082)
+++ gcc/params.def  (working copy)
@@ -565,7 +565,7 @@ DEFPARAM(PARAM_VECT_MAX_VERSION_FOR_ALIA
 
 DEFPARAM(PARAM_VECT_MAX_PEELING_FOR_ALIGNMENT,
  "vect-max-peeling-for-alignment",
- "Max number of loop peels to enhancement alignment of data references 
in a loop.",
+ "Maximum number of loop peels to enhance alignment of data references 
in a loop.",
  -1, -1, 64)
 
 DEFPARAM(PARAM_MAX_CSELIB_MEMORY_LOCATIONS,

Re: [PATCH 3/7] Remove trailing period from various diagnostic messages (PR translation/79923)

[Kyrill Tkachov]

On 10/03/17 23:36, David Malcolm wrote:

On Fri, 2017-03-10 at 09:24 +, Kyrill Tkachov wrote:

On 10/03/17 06:24, Jakub Jelinek wrote:

On Thu, Mar 09, 2017 at 12:45:25PM -0500, David Malcolm wrote:

gcc/ChangeLog:
PR translation/79923
* auto-profile.c (get_combined_location): Convert leading
character of diagnostics to lower case and remove trailing
period.
(read_profile): Likewise for various diagnostics.
* config/arm/arm-builtins.c (arm_expand_builtin): Remove
trailing
period from various diagnostics.
* config/arm/arm.c (arm_option_override): Likewise.
* config/msp430/msp430.c (msp430_expand_delay_cycles):
Likewise.
(msp430_expand_delay_cycles): Likewise.

Mostly ok, but for


--- a/gcc/config/arm/arm-builtins.c
+++ b/gcc/config/arm/arm-builtins.c
@@ -2990,60 +2990,60 @@ arm_expand_builtin (tree exp,
  && (imm < 0 || imm > 32))
{
  if (fcode == ARM_BUILTIN_WRORHI)
-   error ("the range of count should be in 0 to 32.
   please check the intrinsic _mm_rori_pi16 in code.");
+   error ("the range of count should be in 0 to 32.
   please check the intrinsic _mm_rori_pi16 in code");

I wonder if this shouldn't use a semicolon space in the middle
instead of dot space space (many times in the same file).

Is there a convention in GCC to use semicolons?
I'm okay with changing it to a semicolon (it's slightly better IMO)
as long as it's consistent
with the style GCC uses.


Also, for the benefit of translators, this might be better done as
error ("the range of count should be in 0 to 32; please
check the intrinsic %s in code",
   "_mm_rori_pi16");
so that there are fewer of these messages.
Adding some ARM folks on this.

These iWMMXt builtins haven't been touched in ages and could do with
some TLC in general.
For example, I'm not a fan of having all these "please check the
intrinsic ..." messages.
If we've got a reference to the tree we're expanding, isn't there
some kind of error function
that will point to the location in the source that's causing the
error? I'd rather use that than
hardcoding the intrinsic names. This would also allow us to collapse
all these
if (fcode == <...>)
error (...);
else if (fcode == <...>)
error (...);
else if ...

constructs.

While we're at it:

  if (fcode == ARM_BUILTIN_WSRLHI)
-   error ("the count should be no less than 0.  please
check the intrinsic _mm_srli_pi16 in code.");
+   error ("the count should be no less than 0.  please
check the intrinsic _mm_srli_pi16 in code");


Let's use "the count should be a non-negative integer" to be
consistent with the error reporting
for UInteger error messages.


Perhaps commit everything except arm-builtins.c separately and deal
with
this part with the ARM folks?

I agree. David, if you want to clean up the error reporting in these
intrinsics as a separate patch I'd be grateful.
Otherwise, could you please open a bugzilla ticket so we can track
this?

I started looking at this, but realized I don't have the arm ISA
expertise to touch this code (sorry), so I filed
   https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79995
instead.


No worries, thanks for looking at this in the first place.

Kyrill

Re: [Patch, libgfortran, committed] Don't use rand_s on CYGWIN

[Janne Blomqvist]

On Sun, Mar 12, 2017 at 10:46 PM, Janne Blomqvist
 wrote:
> On Sun, Mar 12, 2017 at 7:26 PM, NightStrike  wrote:
>> On Mon, Feb 27, 2017 at 6:15 AM, Janne Blomqvist
>>  wrote:
>>> Don't try to use rand_s on CYGWIN
>>>
>>> CYGWIN seems to include _mingw.h and thus __MINGW64_VERSION_MAJOR is
>>> defined even though rand_s is not available. Thus add an extra check
>>> for __CYGWIN__.
>>>
>>> Thanks to Tim Prince and Nightstrike for bringing this issue to my 
>>> attention.
>>>
>>> Committed as r245755.
>>>
>>> 2017-02-27  Janne Blomqvist  
>>>
>>> * intrinsics/random.c (getosrandom): Don't try to use rand_s on
>>> CYGWIN.
>>
>> 1) There was no patch attached to the email.
>
> Oh, sorry. Well, you can see it at
> https://gcc.gnu.org/viewcvs/gcc?view=revision=245755
>
>> 2) As mentioned on IRC, I don't think this is the right fix.  The real
>> problem is that time_1.h includes windows.h on CYGWIN, which it
>> shouldn't be doing.  This then pollutes the translation unit with all
>> sorts of MINGW-isms that aren't exactly appropriate for cygwin.
>> Removing the include in time_1.h and then adjusting a few ifdefs in
>> system_clock.c that also had the same bug fixes the problem.  The
>> testsuite is running right now on this.
>
> It used to be something like that, but IIRC there were some complaints
> about SYSTEM_CLOCK on cygwin that were due to the cygwin
> clock_gettime() or something like that, and after some discussion with
> someone who knows something about cygwin/mingw (since you apparently
> have no memory of it, I guess it was Kai), it was decided to use
> GetTickCount & QPC also on cygwin.

I searched a bit, and it seems the culprit is the thread starting at

https://gcc.gnu.org/ml/fortran/2013-04/msg00033.html

So it turned out that clock_gettime(CLOCK_MONOTONIC, ...) always
returned 0 on cygwin, hence the code was changed to use the windows
API functions GetTickCount and QPC also on cygwin at

https://gcc.gnu.org/ml/fortran/2013-04/msg00124.html

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

-- 
Janne Blomqvist

Re: stabilize store merging

[Richard Biener]

On Fri, Mar 10, 2017 at 11:34 PM, Alexandre Oliva  wrote:
> On Mar 10, 2017, Alexandre Oliva  wrote:
>
>> Now, if there's something you dislike about maps, we could make it a
>> doubly-linked list, or maybe even a singly-linked list.

I indeed mis-matched std::map for hash_map but I also think we should
use GCCs own interfaces and STL uses are generally discouraged.

> Scratch that, there's a use that may remove after a lookup by base_addr,
> so a singly-linked list would require a linear walk of the list in this
> case.  So, doubly-linked it is, which means...
>
>> it costs just a pointer vs an int in the chains and an additional
>> pointer over your suggestion, but it saves the shuffling and sorting.
>
> ... make it two pointers instead.
>
>
> How's this?  Regstrapping now...  Ok if it passes?

Ok.

[now C++-ish the next/pnxp could be abstracted as a (templated) base class]

Thanks,
Richard.

> Don't let pointer randomization change the order in which we process
> store chains.  This may cause SSA_NAMEs to be released in different
> order, and if they're reused later, they may cause differences in SSA
> partitioning, leading to differences in expand, and ultimately to
> different code.
>
> bootstrap-debug-lean (-fcompare-debug) on i686-linux-gnu has failed in
> haifa-sched.c since r245196 exposed the latent ordering problem in
> store merging.  In this case, the IR differences (different SSA names
> selected for copies in out-of-SSA, resulting in some off-by-one
> differences in pseudos) were not significant enough to be visible in
> the compiler output.
>
>
> for  gcc/ChangeLog
>
> * gimple-ssa-store-merging.c (struct imm_store_chain_info):
> Add linked-list forward and backlinks.  Insert on
> construction, remove on destruction.
> (class pass_store_merging): Add m_stores_head field.
> (pass_store_merging::terminate_and_process_all_chains):
> Iterate over m_stores_head list.
> (pass_store_merging::terminate_all_aliasing_chains):
> Likewise.
> (pass_store_merging::execute): Check for debug stmts first.
> Push new chains onto the m_stores_head stack.
> ---
>  gcc/gimple-ssa-store-merging.c |   65 
> ++--
>  1 file changed, 49 insertions(+), 16 deletions(-)
>
> diff --git a/gcc/gimple-ssa-store-merging.c b/gcc/gimple-ssa-store-merging.c
> index 17ac94a..5bdb459 100644
> --- a/gcc/gimple-ssa-store-merging.c
> +++ b/gcc/gimple-ssa-store-merging.c
> @@ -675,11 +675,34 @@ merged_store_group::apply_stores ()
>
>  struct imm_store_chain_info
>  {
> +  /* Doubly-linked list that imposes an order on chain processing.
> + PNXP (prev's next pointer) points to the head of a list, or to
> + the next field in the previous chain in the list.
> + See pass_store_merging::m_stores_head for more rationale.  */
> +  imm_store_chain_info *next, **pnxp;
>tree base_addr;
>auto_vec m_store_info;
>auto_vec m_merged_store_groups;
>
> -  imm_store_chain_info (tree b_a) : base_addr (b_a) {}
> +  imm_store_chain_info (imm_store_chain_info *, tree b_a)
> +  : next (inspt), pnxp (), base_addr (b_a)
> +  {
> +inspt = this;
> +if (next)
> +  {
> +   gcc_checking_assert (pnxp == next->pnxp);
> +   next->pnxp = 
> +  }
> +  }
> +  ~imm_store_chain_info ()
> +  {
> +*pnxp = next;
> +if (next)
> +  {
> +   gcc_checking_assert ( == next->pnxp);
> +   next->pnxp = pnxp;
> +  }
> +  }
>bool terminate_and_process_chain ();
>bool coalesce_immediate_stores ();
>bool output_merged_store (merged_store_group *);
> @@ -718,6 +741,17 @@ public:
>  private:
>hash_map m_stores;
>
> +  /* Form a doubly-linked stack of the elements of m_stores, so that
> + we can iterate over them in a predictable way.  Using this order
> + avoids extraneous differences in the compiler output just because
> + of tree pointer variations (e.g. different chains end up in
> + different positions of m_stores, so they are handled in different
> + orders, so they allocate or release SSA names in different
> + orders, and when they get reused, subsequent passes end up
> + getting different SSA names, which may ultimately change
> + decisions when going out of SSA).  */
> +  imm_store_chain_info *m_stores_head;
> +
>bool terminate_and_process_all_chains ();
>bool terminate_all_aliasing_chains (imm_store_chain_info **,
>   bool, gimple *);
> @@ -730,11 +764,11 @@ private:
>  bool
>  pass_store_merging::terminate_and_process_all_chains ()
>  {
> -  hash_map::iterator iter
> -= m_stores.begin ();
>bool ret = false;
> -  for (; iter != m_stores.end (); ++iter)
> -ret |= terminate_and_release_chain ((*iter).second);
> +  while (m_stores_head)
> +ret |= 

Re: [PATCH] correct aligned_alloc argument order (PR 80020)

[Richard Biener]

On Mon, Mar 13, 2017 at 2:13 AM, Martin Sebor  wrote:
> r243470 decorates standard allocation functions like alloca
> and malloc with attribute alloc_size.  However, in applying
> the attribute to aligned_alloc I had overlooked that the size
> argument is the second one and not the first.  That oversight
> has led to __builtin_object_size() reporting the wrong size
> for aligned_alloc-allocated objects and, consequently, to
> checking functions like __memset_chk calling abort for buffer
> bogus overflows.
>
> The attached patch corrects this mistake by decorating the
> function with the correct alloc_size attribute.

Ok.

Richard.

> Martin

Re: PATCH for Re: Release notes for GCC 7?

[Richard Biener]

On Sun, Mar 12, 2017 at 11:45 PM, Gerald Pfeifer  wrote:
> On Wed, 24 Aug 2016, Richard Biener wrote:
>> We've been creating those lazily over the last decade.  We can change
>> that, an entry for releasing.html is appreciated then so we don't forget.
>
> And here we go, in time for the release of GCC 7 / branching of GCC 8.
>
> (Except, this time I went ahead and already created gcc-8/changes.html
> so that you guys don't have to worry about that. ;-)
>
> Note, I added this to branching.html, not releasing.html, not the least
> since branching.html already had the creation of other web pages for the
> new release series and that also seems the more appropriate point time-
> wise.  Agreed?

Yes.

Thanks,
Richard.

> Gerald
>
>
> Index: branching.html
> ===
> RCS file: /cvs/gcc/wwwdocs/htdocs/branching.html,v
> retrieving revision 1.32
> diff -u -r1.32 branching.html
> --- branching.html  28 Jun 2014 10:34:16 -  1.32
> +++ branching.html  12 Mar 2017 22:37:59 -
> @@ -7,6 +7,8 @@
>  
>  This page documents the procedure for making a new release branch.
>
> +Preparations
> +
>  
>  Execute the following commands, substituting appropriate version
>  numbers:
> @@ -38,15 +40,25 @@
>  for the next major release in the wwwdocs repository and
>  populate it with initial copies of changes.html and
>  criteria.html.
> +
>
> -Add index.html and buildstat.html pages
> -to the directory corresponding to the newly created release branch.
> -Update the toplevel buildstat.html accordingly.
> +Web Site Updates
> +
> +
> +Add index.html and changes.html pages
> +based on the previous release branch to the directory corresponding to
> +the newly created release branch.
> +
> +Add buildstat.html and update the toplevel
> +buildstat.html accordingly.
>
>  Update the toplevel index.html page to show the new active
>  release branch, the current release series, and active development
>  (mainline).  Update the version and development stage for mainline.
> +
>
> +
>  Update maintainer-scripts/crontab on the mainline by
>  adding an entry to make snapshots of the new branch and adjusting the
>  version number of the mainline snapshots.
> @@ -67,7 +79,11 @@
>  Send them
>  to the translation project if no snapshot of this version was sent
>  during development stage 3 or 4.
> +
>
> +Bugzilla Updates
> +
> +
>  Create new versions in Bugzilla corresponding to the new mainline
>  version.  This can be accomplished by choosing "products", choosing "gcc",
>  and editing the versions.  Please do not delete old
> @@ -85,7 +101,6 @@
>  Ask Daniel Berlin to adjust all PRs with the just-branched version
>  in their summary to also contain the new version corresponding to
>  mainline.
> -
>  
>
>