[Bug fortran/78661] [OOP] Namelist output missing object designator under DTIO

[jvdelisle at gcc dot gnu.org]

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

--- Comment #27 from Jerry DeLisle  ---
With the patch applied and the following test case:

MODULE m
  IMPLICIT NONE
  TYPE :: t
integer :: j
CHARACTER :: c
integer :: k
  CONTAINS
PROCEDURE :: write_formatted
GENERIC :: WRITE(FORMATTED) => write_formatted
PROCEDURE :: read_formatted
GENERIC :: READ(FORMATTED) => read_formatted
  END TYPE
CONTAINS
  SUBROUTINE write_formatted(dtv, unit, iotype, v_list, iostat, iomsg)
CLASS(t), INTENT(IN) :: dtv
INTEGER, INTENT(IN) :: unit
CHARACTER(*), INTENT(IN) :: iotype
INTEGER, INTENT(IN) :: v_list(:)
INTEGER, INTENT(OUT) :: iostat
CHARACTER(*), INTENT(INOUT) :: iomsg
WRITE (unit, "(i10,3x,A,3x,i10)", IOSTAT=iostat, IOMSG=iomsg) dtv%j, dtv%c,
dtv%k
  END SUBROUTINE
  SUBROUTINE read_formatted(dtv, unit, iotype, v_list, iostat, iomsg)
CLASS(t), INTENT(INOUT) :: dtv
INTEGER, INTENT(IN) :: unit
CHARACTER(*), INTENT(IN) :: iotype
INTEGER, INTENT(IN) :: v_list(:)
INTEGER, INTENT(OUT) :: iostat
CHARACTER(*), INTENT(INOUT) :: iomsg
READ (unit, "(i10,3x,A,3x,i10)", IOSTAT=iostat, IOMSG=iomsg) dtv%j, dtv%c,
dtv%k
  END SUBROUTINE read_formatted
END MODULE

PROGRAM p
  USE m
  IMPLICIT NONE
  class(t), allocatable :: x
  NAMELIST /nml/ x
  x = t(55,'a',42)
  WRITE (10, nml)
  REWIND(10)
  READ(10, nml)
END

On the write I see what I expect, but we need to adjust list_read.c to handle
the parsing of input correctly.

$ ./a.out 
At line 42 of file 1test.f03 (unit = 10, file = 'fort.10')
Fortran runtime error: namelist read: misplaced = sign
$ cat fort.10 

 X=55   a   42
 /

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!

[Bug target/80017] [5/6/7 Regression] ICE: Max. number of generated reload insns per insn is achieved (90)

[vmakarov at gcc dot gnu.org]

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

--- Comment #1 from Vladimir Makarov  ---
Thank you for the report.  I've reproduced and started to work on it.  The fix
will be probably ready on Wednesday.

[Bug target/79912] [7 regression] LRA unable to generate reloads after r245655

[palmer at dabbelt dot com]

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

--- Comment #15 from Palmer Dabbelt  ---
Created attachment 40968
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40968=edit
glibc file that loops

The suggested patch causes an infinate loop while building glibc for RISC-V. 
The preprocessed source is attached, but I think the right way to fix this
might be to actually fix the int-in-FP problem in our backend.  If I understand
correctly we don't actually need riscv_preferred_reload_class() but I can
instead remove all the integer->FP modes from the mov{q,h,s,d} patterns.

With just

static reg_class_t
riscv_preferred_reload_class (rtx x ATTRIBUTE_UNUSED, reg_class_t rclass)
{
  return rclass;
}

(which I assume is the same as removing preferred_reload_class()) everything
builds, but I haven't even bothered running the test suite yet.  Looking at the
mov patterns I can't actually find any that are illegal.  I'm looking for
something like

  [(set (match_operand:QI 0 "nonimmediate_operand" "=f")
(match_operand:QI 1 "move_operand" " r"))]

which would allow an integer to end up in a FP register, as opposed to


  [(set (match_operand:QI 0 "nonimmediate_operand" "=r")
(match_operand:QI 1 "move_operand" " f"))]

which from my understanding is legal, since we can store floats in GPRs.  I can
understand how the f-operand versions of movqi and movhi don't make any sense,
so I'll get rid of those, but I think the all our others are OK?

What am I missing?

[Bug target/79905] ICE in canonical types differ for identical types __vector(4) int and V4i {aka __vector(4) int}

[wschmidt at gcc dot gnu.org]

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

--- Comment #3 from Bill Schmidt  ---
So, is the desired behavior that the front end produce an error message
instead?  Or is the front end supposed to unify these two types and accept the
code?

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

[Bug tree-optimization/79800] [7 Regression] wrong snprintf result range with precision in a narrow negative-positive range

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #2 from Martin Sebor  ---
Patch posted for review:
https://gcc.gnu.org/ml/gcc-patches/2017-03/msg00687.html

[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 

[Bug target/80007] --disable-bootstrap with gnat-5 leads to failed gnat-7 build on aarch64

[tulipawn at gmail dot com]

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

--- Comment #9 from PeteVine  ---
Correction, it was about -fomit-frame-pointer period! Setting the environment
C(XX)FLAGS to that flag alone triggers the bug.

[Bug fortran/79382] DTIO ICE

[jvdelisle at gcc dot gnu.org]

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

--- Comment #9 from Jerry DeLisle  ---
Can this be closed?

[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

[Bug tree-optimization/80006] loss of range information due to spurious widening conversion

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-03-13
Summary|loss of range information   |loss of range information
   |after widening conversion   |due to spurious widening
   ||conversion
 Ever confirmed|0   |1

--- Comment #3 from Martin Sebor  ---
I see.  I agree that transforming ~[-3, 7] to [SCHAR_MIN, SCHAR_MAX] when
converting a signed char to a wider type makes sense.  I was so focused on
preserving the anti-range that I hadn't thought of that.

Let me use this bug to track the spurious conversion from signed char to int
(thanks for the pointer, Joseph).  I'm not sure what Component to assign it to:
target?

[Bug fortran/78661] [OOP] Namelist output missing object designator under DTIO

[jvdelisle at gcc dot gnu.org]

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

--- Comment #26 from Jerry DeLisle  ---
(In reply to janus from comment #25)
> (In reply to Jerry DeLisle from comment #24)
> > I dont think the parent is suppose to emit the Object name. What if there
> > are multiple components?
> 
> Huh, I'm not sure. But your statement contradicts Ian's claim in comment #0:
> 
> > UDDTIO procedures are responsible for writing/reading the value part of the
> > name-value subsequence, the processor still has responsibility for the name=
> > part.

yes I am contradicting, but really asking the question.  Suppose a derived type
has 10 components.  If the parent is to emit the object names there are two
choices for the parent:


1) Only emit the parent name and do not emit the component names, allowing the
child procedure to emit all component values with one procedure call from the
parent. User could emit the child object names in some manner if they choose.

2) Emit parent and component names and call the user defined procedure once per
component, in other words 10 calls to get the whole thing. This makes no sense
at all.

Under option 1) we could do something like this:

! parent emits this line
 X= ! parent emits this line
 !child emits whatever they want component names or no component names
 !entirely up to the users definition
 x%data1 = value1
 x%data2 = value2
 x%data3 = value3
 Y=! parent emits this line
 !ditto on child


 /

 snip 
> "When the designator in the input record represents an array variable or a
> variable of derived type, the effect is as if the variable represented were
> expanded into a sequence of scalar list items, in the same way that
> formatted input/output list items are expanded (9.6.3)."
> 


> None of them makes a clear statement about DTIO namelist output. Apparently
> two forms are possible: Either having the whole DT variable, or its
> components separately.
> 
> To me it sounds like we should print the variable name (and not the
> component names) if the namelist contains a full DT variable (and not just
> some components).
> 

I agree with your last statement here in the case where there is a user defined
procedure.  Where there is not a user defined procedure, we do exactly what we
have done all along with gfortran, and print the component qualifier.

Let me apply you latest patch, I will prepare the two cases with and without
user defined I/O and show results here.

[Bug fortran/80009] Printing/writing a structure with a real edit descriptor.

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #9 from Jerry DeLisle  ---
9.6.4.8.4 Resolving defined input/output procedure references

In paragraph 2, there are two conditions that BOTH must be satisfied for a user
defined procedure to be used:

Condition 1:

 a) list directed, namelist, or unformatted
 or
 b) formatted and the edit descriptor corresponds to the effective item and is
DT

Condition 2:

 a) effective item as a suitable type bound procedure
 or
 b) a generic interface is accessible

With the specific case given in this PR:

write (unit=*, fmt="(f4.1)") B_type(20.0)

The "effective item" is key here. My interpretation is that it is the kind=real
number 20.0 and that th B_type(20.0) needs to be further resolved in io.c

Confirming this bug.

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.

[Bug libstdc++/79820] std::ifstream sets errno to zero

[i.nixman at autistici dot org]

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

--- Comment #4 from niXman  ---
(In reply to Jonathan Wakely from comment #3)

> and it also needs to be done on line 275.

why?
line 275:
https://gcc.gnu.org/viewcvs/gcc/trunk/libstdc%2B%2B-v3/config/io/basic_file_stdio.cc?view=markup#l275

[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

[Bug rtl-optimization/79856] rtl_verify_edges: use internal_error instead of error

[marxin at gcc dot gnu.org]

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

--- Comment #7 from Martin Liška  ---
(In reply to Roland Illig from comment #6)
> I would define the rules as follows, the first matching rule wins:
> 
> 1. do not translate messages that contain names of GCC implementation
> functions
> 
> 2. do not translate messages that contain the words GIMPLE, BB (meaning
> basic block), insn (unsuitable abbreviation for instruction), RTL, SSA
> 
> 3. do not translate messages from gfc_internal_error, internal_error
> 
> 4. translate messages that use only terminology from the user's programming
> language (C, C++, Fortran)
> 
> 5. decide on your own (this should only occur rarely)

I like your rules. My question was more about how practically do you
distinguish between such strings? My plan is to create a new DK_INTERNAL_ERROR
type, which I would like to ignore in the translations.

[Bug fortran/80009] Printing/writing a structure with a real edit descriptor.

[jvdelisle at gcc dot gnu.org]

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

--- Comment #8 from Jerry DeLisle  ---
(In reply to Walt Brainerd from comment #7)
> I took "not processed by" to mean that there is no DT edit descriptor
> corresponding to it.
> 
> But I see how this might be interpreted otherwise.
> 
> Intel agrees with me FWIW.
> 
> Maybe this is a question for J3 (or perhaps first, c.l.f?).
> 
> Thanks for thinking about this.
> 

Thanks for helping me see the other side.  If list formatted (fmt=*), the I/O
operations are driven by the I/O list, so this is clear as the user defined
procedures are used if present.

Generally, formatted I/O is driven by the format string. This gets interesting
with something like '(i5, a4, DT)' where the IO list contains two derived
types. If the first derived type contains two components, then it would be
expanded to its components and these would fulfill i5 and a4. Then the DT would
process the second derived type in the list.  

If the first derived type has three components, there is a mismatch to the IO
list. gfortran does the expansion of the components at compile time because it
can not always know the format string until run time so the decision is based
off the existence of user defined procedures.

Example:

type a
  integer  :: num
  character(5) :: str
end type a

type b
  some stuff
end type b

type(a) :: data1
type(b) :: data2
sfmt = "(i5,1x,a5,1x,DT)"
write(10, fmt=sfmt) data1, data2

Interesting question

[Bug libgcc/80037] Bad .eh_frame data in crtend.o

[rth at gcc dot gnu.org]

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

Richard Henderson  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-03-13
   Assignee|unassigned at gcc dot gnu.org  |rth at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Richard Henderson  ---
Created attachment 40967
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40967=edit
proposed patch

Testing this as a fix.

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

[Bug libgcc/80037] New: Bad .eh_frame data in crtend.o

[rth at gcc dot gnu.org]

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

Bug ID: 80037
   Summary: Bad .eh_frame data in crtend.o
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rth at gcc dot gnu.org
  Target Milestone: ---

Looks similar to PR40332, but targeting alpha.

The cause is gcc writing gas directives for unwind for
__do_global_ctors_aux, and also writing the terminator
for the .eh_frame section via the static variable __FRAME_END__.

This results in one CIE entry after the terminator, causing
ld to complain.

For normal applications, the program still runs ok, although
the lack of .eh_frame_hdr is much less than ideal if c++
exceptions are involved.

However, dejagnu treats this extra output as an error.
So test results for alpha are unusable at present.

[Bug c/80036] New: Source line not printed for diagnostic if expanded from a macro

[joriswu at gmail dot com]

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

Bug ID: 80036
   Summary: Source line not printed for diagnostic if expanded
from a macro
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: joriswu at gmail dot com
  Target Milestone: ---

If a diagnostic is printed for code that expands from a macro, and the macro is
defined in a header file, the source line is not shown. Only the include stack
is :

macros.h:

extern void print_it(const char *fmt, int i);
#define print_int(x) print_it("%d",(x))


code.c:

#include "macros.h"


void test(void)

{

  int unint;

  print_int(uninit);

}

gcc  -c -Wall test.c

In file included from test.c:1:0:
test.c: In function 'test':
macros.h:1:22: warning: 'uninit' is used uninitialized in this function
[-Wuninitialized]
 #define print_int(x) print_it("%d",(x))
  ^~~~
test.c:7:7: note: 'uninit' was declared here
   int uninit;
   ^~

so the offending line print_int() is not shown.

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
> 

[Bug tree-optimization/79908] ICE in gimplify_expr (gimplify.c:12155) gimplification failed

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |wschmidt at gcc dot 
gnu.org

--- Comment #2 from Bill Schmidt  ---
Patch under test:

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;

[Bug ada/80033] style suggestions for gcc/ada/gcc-interface/Makefile.in

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-03-13
 CC||ebotcazou at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Eric Botcazou  ---
> Please consider the attached changes improving a bit the readability of the
> Ada main Makefile.

I'd suggest separating the removal of obsolete stuff with the rest, which is
more controversial, in particular the substitutions of variables.

[Bug libstdc++/79820] std::ifstream sets errno to zero

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
Comment on attachment 40966
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40966
patch

It's quite possible that "errno" is a macro for something called "__errno" on
some systems, so this would fail to compile. I suggest something like
__save_errno instead, and it also needs to be done on line 275.

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

[Bug middle-end/79538] missing -Wformat-overflow with %s and non-member array arguments

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-03-13
Summary|missing -Wformat-overflow   |missing -Wformat-overflow
   |with %s and global array|with %s and non-member
   |arguments   |array arguments
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
Confirming my own bug and adjusting the Summary to make it clear that the
problem isn't specific to global arrays and affects local arrays as well.  The
following test case shows that.

$ cat z.c && gcc -O2 -S -Wall -Wextra -Wpedantic
-fdump-tree-printf-return-value=/dev/stdout z.c
int main ()
{
  char d[3];
  char s[] = "abcd";

  __builtin_sprintf (d, "%-s", s);
  __builtin_printf ("%s\n", d);
}


;; Function main (main, funcdef_no=0, decl_uid=1794, cgraph_uid=0,
symbol_order=0) (executed once)

z.c:6: __builtin_sprintf: objsize = 3, fmtstr = "%-s"
  Directive 1 at offset 0: "%-s"
Result: 0, 0, -1, 9223372036854775807 (0, 0, -1, -1)
  Directive 2 at offset 3: "", length = 1

main ()
{
  char s[5];
  char d[3];

   [100.00%]:
  s = "abcd";
  __builtin_sprintf (, "%-s", );
  __builtin_puts ();
  d ={v} {CLOBBER};
  s ={v} {CLOBBER};
  return 0;

}

[Bug libstdc++/79820] std::ifstream sets errno to zero

[i.nixman at autistici dot org]

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

--- Comment #2 from niXman  ---
Created attachment 40966
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40966=edit
patch

[Bug target/80035] [nvptx] non-returning function call causes ptxas sigsegv

[vries at gcc dot gnu.org]

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

Tom de Vries  changed:

   What|Removed |Added

 CC||tschwinge at gcc dot gnu.org

--- Comment #2 from Tom de Vries  ---
>   {
>   .param.u32 %out_arg1;
>   st.param.u32 [%out_arg1], %r31;
>   call exit, (%out_arg1);
>   trap; // (noreturn)
>   }

At nvptx_output_call_insn, we see:
...
  if (find_reg_note (insn, REG_NORETURN, NULL))
/* No return functions confuse the PTX JIT, as it doesn't realize   
   the flow control barrier they imply.  It can seg fault if it 
   encounters what looks like an unexitable loop.  Emit a trailing  
   trap, which it does grok.  */
fprintf (asm_out_file, "\t\ttrap; // (noreturn)\n");
...

Replacing trap with exit or ret (or adding it after trap), makes the sigsegv go
away.

[Bug target/80035] [nvptx] non-returning function call causes ptxas sigsegv

[vries at gcc dot gnu.org]

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

--- Comment #1 from Tom de Vries  ---
Created attachment 40965
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40965=edit
pr58640.s

[Bug target/80035] New: [nvptx] non-returning function call causes ptxas sigsegv

[vries at gcc dot gnu.org]

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

Bug ID: 80035
   Summary: [nvptx] non-returning function call causes ptxas
sigsegv
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

between r245929 and r246078 I observed this regression:
...
PASS -> FAIL: default/gcc.sum:gcc.c-torture/execute/pr58640.c   -O1  execution
test
...

In more detail:
...
$ gcc src/gcc-mainline/gcc/testsuite/gcc.c-torture/execute/pr58640.c 
-fno-diagnostics-show-caret -fdiagnostics-color=never -O2 -w -DSTACK_SIZE=8192
-DNO_TRAMPOLINES -DNO_LABEL_VALUES -DSIGNAL_SUPPRESS   -mmainkernel  -lm -o
./pr58640.exe 
nvptx-as: ptxas terminated with signal 11 [Segmentation fault], core dumped
...

[Bug target/79793] Incorrect stack alignment for interrupt handler in 64-bit

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
   Last reconfirmed||2017-03-13
 Resolution|FIXED   |---
 Ever confirmed|0   |1

--- Comment #5 from H.J. Lu  ---
In 64-bit mode, stack is 16-byte aligned when entering handler.  But if
there is error code

SS
RSP
FLAGS
CS
RIP
Error Code

the stack alignment is off by 8 bytes.  That is %rsp + 8 isn't multiple
of 16 at the start of handler.

[Bug fortran/78661] [OOP] Namelist output missing object designator under DTIO

[janus at gcc dot gnu.org]

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

--- Comment #25 from janus at gcc dot gnu.org ---
(In reply to Jerry DeLisle from comment #24)
> I dont think the parent is suppose to emit the Object name. What if there
> are multiple components?

Huh, I'm not sure. But your statement contradicts Ian's claim in comment #0:

> UDDTIO procedures are responsible for writing/reading the value part of the
> name-value subsequence, the processor still has responsibility for the name=
> part.

I hope one should be able to settle this by having a deeper look in the
standard?!?

I found the following in F08 section 10.11.2:

"If the namelist group object is of derived type, the designator in the input
record may be either the name of the variable or the designator of one of its
components, indicated by qualifying the variable name with the appropriate
component name."

And then in section 10.11.3.2:

"When the designator in the input record represents an array variable or a
variable of derived type, the effect is as if the variable represented were
expanded into a sequence of scalar list items, in the same way that formatted
input/output list items are expanded (9.6.3)."

None of them makes a clear statement about DTIO namelist output. Apparently two
forms are possible: Either having the whole DT variable, or its components
separately.

To me it sounds like we should print the variable name (and not the component
names) if the namelist contains a full DT variable (and not just some
components).

What do other compilers do?

[Bug libstdc++/80034] [5/6 Regression] unqualified calls to std::distance in std::list::sort

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from Ville Voutilainen  ---
Fixed.

[Bug libstdc++/80034] [5/6 Regression] unqualified calls to std::distance in std::list::sort

[ville at gcc dot gnu.org]

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

--- Comment #4 from ville at gcc dot gnu.org ---
Author: ville
Date: Mon Mar 13 19:44:42 2017
New Revision: 246109

URL: https://gcc.gnu.org/viewcvs?rev=246109=gcc=rev
Log:
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.

Added:
   
branches/gcc-5-branch/libstdc++-v3/testsuite/23_containers/list/operations/80034.cc
Modified:
branches/gcc-5-branch/libstdc++-v3/ChangeLog
branches/gcc-5-branch/libstdc++-v3/include/bits/list.tcc

[Bug libstdc++/80034] [5/6 Regression] unqualified calls to std::distance in std::list::sort

[ville at gcc dot gnu.org]

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

--- Comment #3 from ville at gcc dot gnu.org ---
Author: ville
Date: Mon Mar 13 19:43:27 2017
New Revision: 246108

URL: https://gcc.gnu.org/viewcvs?rev=246108=gcc=rev
Log:
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.

Added:
   
branches/gcc-6-branch/libstdc++-v3/testsuite/23_containers/list/operations/80034.cc
Modified:
branches/gcc-6-branch/libstdc++-v3/ChangeLog
branches/gcc-6-branch/libstdc++-v3/include/bits/list.tcc

[Bug libstdc++/80034] [5/6 Regression] unqualified calls to std::distance in std::list::sort

[ville at gcc dot gnu.org]

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

--- Comment #2 from ville at gcc dot gnu.org ---
Author: ville
Date: Mon Mar 13 19:41:50 2017
New Revision: 246107

URL: https://gcc.gnu.org/viewcvs?rev=246107=gcc=rev
Log:
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.

Added:
trunk/libstdc++-v3/testsuite/23_containers/list/operations/80034.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/list.tcc

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
+}
+

[Bug c/79855] params.def: missing period in PARAM_MAX_STORES_TO_MERGE

[roland.illig at gmx dot de]

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

--- Comment #5 from Roland Illig  ---
Here is a simple program to check the help strings for consistency:

#include 
#include 

static void assert_trailing_dot(const char *help)
{
size_t len = strlen(help);
if (len > 0 && help[len-1] != '.') {
fprintf(stderr, "missing trailing period in \"%s\".\n", help);
}
}

int main(void)
{
#define DEFPARAM(enumval, name, help, defval, min, max)
assert_trailing_dot(help);
#define DEFPARAMENUM5(...)
#include "params.def"
}

Compile it with "gcc -Wall -Wextra -std=c99".

[Bug c/79855] params.def: missing period in PARAM_MAX_STORES_TO_MERGE

[roland.illig at gmx dot de]

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

Roland Illig  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #4 from Roland Illig  ---
It's not yet fixed. The one message may now have the trailing period, but in
the second paragraph I said that "all messages in params.def should use
consistent grammar".

There are still messages without a trailing period.

[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

[Bug libstdc++/70893] codecvt incorrectly decodes UTF-16be

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #8 from Jonathan Wakely  ---
The little_endian flag only affects the "external representation" not the
in-memory representation. Because the external representation for
codecvt_utf8_utf16 is UTF-8 it ignores the little_endian flag.

If you want to convert UTF-16BE to UTF-8 I think you need to treat UTF-16BE as
the external representation, so you need to use std::codecvt_utf16 to convert
it to some internal representation, and then convert that to UTF-8. So the
right way to write that function would be:

template inline std::string std_utf16_to_utf8(const char *s, size_t
sz)
{
  using namespace std; sz &= ~1;
  // Convert UTF-16BE to UCS4 (with native endianness):
  wstring_convert conv1("");
  std::u32string u32str = conv1.from_bytes(s, s+sz);
  // Convert UCS4 (with native endianness) to UTF-8:
  wstring_convert conv2("");
  return conv2.to_bytes(u32str);
}

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

[Bug fortran/39239] Reject SAVEd variables EQUIVALENCEd to a COMMON

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #10 from Steve Kargl  ---
On Mon, Mar 13, 2017 at 05:38:57PM +, koenigni at student dot ethz.ch
wrote:
> 
> (In reply to kargl from comment #7)
> > 
> > Do you have a copyright assignment on file with the FSF
> > for GCC?  Your first patch probably falls under "small
> > enough to not require an assignment" but combining the
> > patches is approaching needing an assignment on file.
> 
> I've already done all the legal stuff :). I hope to contribute more in the
> future.
> 

Ah, good!  One more item of note.  When you have a patch can you
also email it to gcc-patc...@gcc.gnu.org and fort...@gcc.gnu.org
(along with a a pointer to PR and/or ChangeLog entry).  This may
help with getting the patch reviewed and committed.

[Bug tree-optimization/80006] loss of range information after widening conversion

[joseph at codesourcery dot com]

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

--- Comment #2 from joseph at codesourcery dot com  ---
The premature promotion probably comes from 
targetm.calls.promote_prototypes, which currently takes effect in the 
front ends (affecting the IR generated for both caller and callee).

I think such a promotion should preferably take place as a lowering step 
somewhere after the front end, and the IR produced by the front ends 
should not have this particular dependence on the target architecture, but 
don't know how hard it would be to move this out of the front ends.

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

[Bug translation/80001] diagnostics: untranslateable %s placeholders in omp-offload.c

[joseph at codesourcery dot com]

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

--- Comment #2 from joseph at codesourcery dot com  ---
On Sat, 11 Mar 2017, roland.illig at gmx dot de wrote:

> error_at (loop->loc, loop->routine
>   ? "routine call uses same OpenACC parallelism as containing loop"
>   : "inner loop uses same OpenACC parallelism as containing loop");

With G_() around each diagnostic string so both get extracted for 
translation.

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: 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: Target maintainers: doc/install.texi love and care

[Joseph Myers]

On Sun, 12 Mar 2017, Gerald Pfeifer wrote:

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

I think we should set a global minimum binutils version (for all targets 
using GNU binutils) and give an error at configure time for too-old 
binutils.  But not at the present development stage.

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

Re: Obsolete powerpc*-*-*spe*

[Andrew Jenner]

On 21/02/2017 16:14, David Edelsohn wrote:

On Mon, Feb 20, 2017 at 11:02 AM, Olivier Hainque  wrote:

On Feb 17, 2017, at 01:10 , David Edelsohn  wrote:

This is not a new issue.  The maintainer did not suddenly resign last
week.  There have been numerous efforts to reach out to the SPE
community for over a *decade*, cajoling them to step up with
maintenance for the port.  I am glad that this notice of obsolescence
has focused more attention on the long-standing problem.


Would there be a minimum level of commitment you'd like
to get to accept leaving the port in (if not this, at least
that ...) ?


[...]

There are three main areas that require attention:

1) Regular builds of the SPE configuration and regular GCC testsuite
runs that are reported to the gcc-testsuite mailing list.

2) Timely reports of any regressions.

3) An active GCC developer who is the point of contact for the SPE
port and submits patches for the port.

None of us within IBM are experts on the SPE port.  Someone from the
SPE community is needed to help triage issues, debug problems and test
patches that may affect the SPE port.

With evidence of pro-active involvement from an SPE developer, the
port does not have to be deprecated. The effort needs to be more that
activity at GCC release cycle boundaries or an accelerated deprecation
process will be proposed.


I volunteer to be the point of contact for the SPE port.

Over here at CodeSourcery/Mentor Embedded, we have a strong interest in 
SPE *not* being deprecated (we actively ship toolchain products with SPE 
multilibs, and have customers for which these are important). We are 
therefore volunteering resources (specifically, me) to maintain SPE 
upstream as well.


I am in the process of developing some patches to add VLE support 
upstream (and expect to be maintainer of those once they are committed) 
so it would be a good fit for me to be the SPE maintainer as well.


We have been regularly running tests on the SPE multilibs (on our 
internal branches) and they are in better shape than the test results 
Segher found from 2015. We may have some (not yet upstreamed) patches 
that improve the test results - I will be tracking these down and 
upstreaming them ASAP. I will be expanding our regular build and test 
runs to cover trunk as well, and will send test results to gcc-testsuite 
and report regressions.


If there is no objection, I will submit patches tomorrow to un-obsolete 
SPE and add myself to the appropriate section of the MAINTAINERS file. 
The other changes will come once stage 1 opens.


Thanks,

Andrew

[Bug c++/79919] Warning specifies end of method rather than the correct line

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #1 from Martin Sebor  ---
There also is no option to control this warning, and outside of pr16302.{C,c}
no tests for it.  It seems that a good option to put this warning under might
be -Wlogical-op.  The text of the warning could also be made consistent with
that issued by the option, i.e., like so (copied from c-family/c-warn.c):

  if (or_op)
warning_at (location, OPT_Wlogical_op,
"logical % of collectively exhaustive tests is "
"always true");
  else
warning_at (location, OPT_Wlogical_op,
"logical % of mutually exclusive tests is "
"always false");

The implementation of the warning issued for the test case is in fold-const.c:

  /* Handle the case of comparisons with constants.  If there is something in
 common between the masks, those bits of the constants must be the same.
 If not, the condition is always false.  Test for this to avoid generating
 incorrect code below.  */
  result = const_binop (BIT_AND_EXPR, ll_mask, rl_mask);
  if (! integer_zerop (result)
  && simple_cst_equal (const_binop (BIT_AND_EXPR, result, l_const),
   const_binop (BIT_AND_EXPR, result, r_const)) != 1)
{
  if (wanted_code == NE_EXPR)
{
  warning (0, "% of unmatched not-equal tests is always 1");
  return constant_boolean_node (true, truth_type);
}
  else
{
  warning (0, "% of mutually exclusive equal-tests is always 0");
  return constant_boolean_node (false, truth_type);
}
}

[PATCH] RISC-V documentation cleanups

[Palmer Dabbelt]

A recent mailing list post about install.texi cleanup suggested I take a
look at ours, and there were a few problems:

 * No table of contents entries
 * Not alphabetically ordered
 * Missing a note about requiring binutils-2.28

gcc/ChangeLog:

2017-03-13  Palmer Dabbelt  : Add table of contents
link.
: Likewise.
: Likewise
: Likewise.
: Re-arrange section
: Add a note about requiring binutils-2.28.
: Likewise.
: Likewise
: Likewise.
---
 gcc/ChangeLog| 13 +
 gcc/doc/install.texi | 30 +++---
 2 files changed, 36 insertions(+), 7 deletions(-)

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index a4cd56f..9493330 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,16 @@
+2017-03-13  Palmer Dabbelt  : Add table of contents
+   link.
+   : Likewise.
+   : Likewise
+   : Likewise.
+   : Re-arrange section
+   : Add a note about requiring binutils-2.28.
+   : Likewise.
+   : Likewise
+   : Likewise.
+
 2017-03-13  Martin Liska  
 
PR middle-end/78339
diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
index dced17d..e7cb30c 100644
--- a/gcc/doc/install.texi
+++ b/gcc/doc/install.texi
@@ -3211,6 +3211,14 @@ information have to.
 @item
 @uref{#powerpcle-x-eabi,,powerpcle-*-eabi}
 @item
+@uref{#riscv32-x-elf,,riscv32-*-elf}
+@item
+@uref{#riscv32-x-linux,,riscv32-*-linux}
+@item
+@uref{#riscv64-x-elf,,riscv64-*-elf}
+@item
+@uref{#riscv64-x-linux,,riscv64-*-linux}
+@item
 @uref{#s390-x-linux,,s390-*-linux*}
 @item
 @uref{#s390x-x-linux,,s390x-*-linux*}
@@ -4288,21 +4296,27 @@ This configuration is intended for embedded systems.
 @heading riscv32-*-elf
 The RISC-V RV32 instruction set.
 This configuration is intended for embedded systems.
+This (and all other RISC-V) targets are supported upstream as of the
+binutils-2.28 release.
 
 @html
 
 @end html
-@anchor{riscv64-x-elf}
-@heading riscv64-*-elf
-The RISC-V RV64 instruction set.
-This configuration is intended for embedded systems.
+@anchor{riscv32-x-linux}
+@heading riscv32-*-linux
+The RISC-V RV32 instruction set running GNU/Linux.
+This (and all other RISC-V) targets are supported upstream as of the
+binutils-2.28 release.
 
 @html
 
 @end html
-@anchor{riscv32-x-linux}
-@heading riscv32-*-linux
-The RISC-V RV32 instruction set running GNU/Linux.
+@anchor{riscv64-x-elf}
+@heading riscv64-*-elf
+The RISC-V RV64 instruction set.
+This configuration is intended for embedded systems.
+This (and all other RISC-V) targets are supported upstream as of the
+binutils-2.28 release.
 
 @html
 
@@ -4310,6 +4324,8 @@ The RISC-V RV32 instruction set running GNU/Linux.
 @anchor{riscv64-x-linux}
 @heading riscv64-*-linux
 The RISC-V RV64 instruction set running GNU/Linux.
+This (and all other RISC-V) targets are supported upstream as of the
+binutils-2.28 release.
 
 @html
 
-- 
2.10.2

Re: Target maintainers: doc/install.texi love and care

[Palmer Dabbelt]

On Mon, 13 Mar 2017 01:59:28 PDT (-0700), ger...@pfeifer.com wrote:
> On Sun, 12 Mar 2017, Palmer Dabbelt wrote:
>> I looked at our stuff (RISC-V) and there's almost nothing in there.
>> Is there something I should add?  I looked at the aarch64 stuff in the
>> "host/target specific issues start here" section and there's some notes
>> about binutils-2.24. We'll require binutils-2.28 (the first version that
>> we're upstream in), I can add a note in that section about RISC-V as
>> well if you think it's appropriate.
>
> I am generally a fan of keeping documentation short (lest it is
> skipped or skimmed), but as long as necessary.
>
> In your case I don't think artificially blowing up the section on RISC-V
> to match others would be helpful.  However, given that binutils 2.28 is
> so brand new, that I'd definitely mention.
>
> (My proposals/patches yesterday are about removing references to ten
> year old versions of binutils from install.texi, quite the other end
> of the spectrum.)

Makes sense.  I think I found a few other problems in ours as well.  How does
this look?

[PATCH] RISC-V documentation cleanups

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);
 }")
 
 

[Bug libstdc++/80034] [5/6 Regression] unqualified calls to std::distance in std::list::sort

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-03-13
 CC||ville.voutilainen at gmail dot 
com
   Assignee|unassigned at gcc dot gnu.org  |ville.voutilainen at 
gmail dot com
 Ever confirmed|0   |1

--- Comment #1 from Ville Voutilainen  ---
Oops, mine.

[Bug fortran/39239] Reject SAVEd variables EQUIVALENCEd to a COMMON

[koenigni at student dot ethz.ch]

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

--- Comment #9 from Nicolas Koenig  ---
(In reply to kargl from comment #7)
> (In reply to Nicolas Koenig from comment #6)
> > Created attachment 40962 [details]
> > Proposed patch for EQUIVALENCE / VOLATILE
> > 
> > This patch should cover the case of one EQUIVALENCE object being VOLATILE
> > (In this case every object should be volatile according to the standard). It
> > also fixes a testcase (gfortran.dg/volatile11.90) related to this.
> 
> Nicolas,
> 
> Thanks for the patch.
> 
> Do you have a copyright assignment on file with the FSF
> for GCC?  Your first patch probably falls under "small
> enough to not require an assignment" but combining the
> patches is approaching needing an assignment on file.

I've already done all the legal stuff :). I hope to contribute more in the
future.

[Bug fortran/39239] Reject SAVEd variables EQUIVALENCEd to a COMMON

[koenigni at student dot ethz.ch]

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

Nicolas Koenig  changed:

   What|Removed |Added

  Attachment #40962|0   |1
is obsolete||

--- Comment #8 from Nicolas Koenig  ---
Created attachment 40964
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40964=edit
Proposed patch for EQUIVALENCE / VOLATILE 2

I'm sorry, I misread the standard (not really experienced in reading official
things :)), it reads:
" All members of an EQUIVALENCE group should have the VOLATILE attribute if
any member has the VOLATILE attribute." (5.3.19).
This patch leads to an error being thrown if this not the case (instead of
giving them the volatile attribute as in the patch before).

This breaks the gfortran.dg/volatile11.f90 test case, but the optimizations
tested for in it can no longer be legally performed anyway. I would suggest
replacing it with something in line with the standard.

[Bug sanitizer/77631] no symbols in backtrace shown by ASan when debug info is split

[d.khalikov at partner dot samsung.com]

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

Denis Khalikov  changed:

   What|Removed |Added

 CC||d.khalikov at partner dot 
samsung.
   ||com

--- Comment #5 from Denis Khalikov  ---
Yes,i sent to gcc-patc...@gcc.gnu.org.

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

Re: Design question LWG 2861: basic_string should require that charT match traits::char_type

[Jonathan Wakely]

On 13 March 2017 at 11:33, Daniel Krügler  wrote:
> 2017-03-13 11:56 GMT+01:00 Jonathan Wakely :
>> On 12 March 2017 at 13:21, Daniel Krügler  wrote:
>>> I'm now working on
>>>
>>> http://cplusplus.github.io/LWG/lwg-defects.html#2861
>>>
>>> The new wording state is now equivalent to basic_string_view, whose
>>> current implementation doesn't bother verifying the requirement, so
>>> this code (which as UB) currently compiles just fine:
>>>
>>> #include 
>>> #include 
>>>
>>> struct MyTraits : std::char_traits
>>> {
>>>   typedef unsigned char char_type;
>>> };
>>>
>>> int main()
>>> {
>>>   std::basic_string my_string;
>>>   std::basic_string_view my_string_view;
>>> }
>>>
>>> So the least I could do is just - nothing. But it seems to me that we
>>> could protect users from doing such silly things by adding a
>>> static_assert to both basic_string and basic_string_view, the former
>>> being equivalent to
>>>
>>> #if __cplusplus >= 201103L
>>>   static_assert(__are_same::value,
>>> "traits_type::char_type must be equal to _CharT");
>>> #endif
>>>
>>> and the latter an unconditional
>>>
>>>   static_assert(is_same::value,
>>> "traits_type::char_type must be equal to _CharT");
>>>
>>> Would you agree with that course of action?
>>
>> Not at this stage of gcc7 development. If the silly code compile fine
>> then we risk breaking working code, and we're too close to a release
>> to do that.
>
> Is there a way to mark a patch suggestion for gcc8 and is so, how?

Just mention it in the email. Ideally ping the patch after gcc7 is
released so someone (probably me) can apply it once we're back in
Stage 1.

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.

[Bug fortran/39239] Reject SAVEd variables EQUIVALENCEd to a COMMON

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #7 from kargl at gcc dot gnu.org ---
(In reply to Nicolas Koenig from comment #6)
> Created attachment 40962 [details]
> Proposed patch for EQUIVALENCE / VOLATILE
> 
> This patch should cover the case of one EQUIVALENCE object being VOLATILE
> (In this case every object should be volatile according to the standard). It
> also fixes a testcase (gfortran.dg/volatile11.90) related to this.

Nicolas,

Thanks for the patch.

Do you have a copyright assignment on file with the FSF
for GCC?  Your first patch probably falls under "small
enough to not require an assignment" but combining the
patches is approaching needing an assignment on file.

[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 

RFC: Treat plugins as first class citizens

[Nick Clifton]

Hi Guys,

 I was thinking that it would be nice to make plugins a "first-class
 citizen" in the gcc world by having a proper directory structure and
 integration into the rest of gcc.  For example:

gcc/plugins   <-- Everything plugin-y starts here
gcc/plugins/Make-lang.in  <-- Makefile fragment.
gcc/plugins/src   <-- Maybe move gcc/plugins.[c|h|def] here ?
gcc/plugins/doc   <-- Actual documentation, wow!
gcc/plugins/testsuite <-- Tests for the plugins and their integration 
into gcc
gcc/plugins/config<-- Subdirectories of this directory contain each 
real plugin
gcc/plugins/config/annobin  <-- For example, this is where my pet plugin 
would go

  Plus there could be an official plugins maintainer.  (I am willing to
  volunteer, so is Aldy Hernandez).  The documentation would be compiled
  along with the rest of gcc's documentation and the testsuite would be
  run as part of gcc's normal testing process.  Ideally I would also
  like to see plugin test failures be considered as blockers for new
  releases, but that is something for the future.

  So, what do you think ?  Should I create a patch and submit it for
  official review ?
  
Cheers
  Nick

[Bug sanitizer/77631] no symbols in backtrace shown by ASan when debug info is split

[ian at airs dot com]

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

Ian Lance Taylor  changed:

   What|Removed |Added

 CC||ian at airs dot com

--- Comment #4 from Ian Lance Taylor  ---
Thanks!  Can you send your patch to the mailing list gcc-patc...@gcc.gnu.org
for review?

[Bug sanitizer/77631] no symbols in backtrace shown by ASan when debug info is split

[d.khalikov at partner dot samsung.com]

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

--- Comment #3 from Denis Khalikov  ---
Created attachment 40963
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40963=edit
patch for PR sanitizer/77631

Hello everyone, i have a patch for this issue.
(see attachment PR_sanitizer_77631)

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

Re: Right way to represent flag-setting arithmetic instructions in MD files

[Segher Boessenkool]

On Mon, Mar 13, 2017 at 09:53:11AM +, Kyrill Tkachov wrote:
> >combine doesn't try to combine all producer-consumer pairs, only
> >producer with first consumer, because it would not often help and
> >could easily take much more time.  On the other hand I'd love to get
> >rid of the LOG_LINKS and use DF directly.
> 
> Are there any significant barriers to moving to DF?
> I heard some other passes (e.g. LRA) are reluctant to use
> DF because it's too slow.

Updating DF info can be slow.  I'm not sure how bad it really would be
for combine.  But, we do not even need to do a "full" update inside
combine.

Looking at all producer-consumer pairs is just as linear as only
looking at the first consumer for every producer.  It is more work
of course, and it does not generally help all that much.

combine has quite a few problems caused by not working with DF (both
correctness bugs and missed optimisations).

> >Note that combining the first and third insns in your example requires
> >to put the combined insns in the place of the first insn, where
> >normally it would put it at the third insn.  Maybe we could treat
> >compares specially?
> 
> We'd also need to do a SELECT_CC_MODE if we're replacing the operands of 
> the comparison
> and update the users of the CC reg from that comparison I believe.

Yeah probably.

> >Do such cases happen a lot, btw?
> 
> I hacked together an extension to the cmpelim pass that merges such 
> comparisons
> (that previous passes like combine don't catch) and on aarch64 for SPEC2006 
> it merged
> about 480 compares. If combine were extended as you described above I think 
> it could catch
> it, but it's a more complex and fragile pass than I feel comfortable 
> hacking for this :)

Some people call it brave, some people call it foolish.


Segher

[Bug libstdc++/80034] New: [5/6 Regression] unqualified calls to std::distance in std::list::sort

[redi at gcc dot gnu.org]

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

Bug ID: 80034
   Summary: [5/6 Regression] unqualified calls to std::distance in
std::list::sort
   Product: gcc
   Version: 6.3.1
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
CC: ville at gcc dot gnu.org
  Target Milestone: ---

This no longer compiles on the gcc-5 or gcc-6 branches:

#include 

namespace X {
  struct Y { };
  bool operator<(Y, Y) { return false; }
  template
void distance(T, T) { }
}

int main()
{
  std::list l;
  l.sort();
}

Caused by r244475 and r244474

[Bug rtl-optimization/79856] rtl_verify_edges: use internal_error instead of error

[roland.illig at gmx dot de]

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

--- Comment #6 from Roland Illig  ---
I would define the rules as follows, the first matching rule wins:

1. do not translate messages that contain names of GCC implementation functions

2. do not translate messages that contain the words GIMPLE, BB (meaning basic
block), insn (unsuitable abbreviation for instruction), RTL, SSA

3. do not translate messages from gfc_internal_error, internal_error

4. translate messages that use only terminology from the user's programming
language (C, C++, Fortran)

5. decide on your own (this should only occur rarely)

[Bug libstdc++/67578] std::random_device::entropy() always returns 0

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-03-13
 Ever confirmed|0   |1

--- Comment #3 from Jonathan Wakely  ---
Right, it's better to add it to the DSO as your first patch does. This will
have to wait for gcc8 though. In the meantime I'll email you separately about
completing a copyright assignment for GCC.

[Bug tree-optimization/79920] [6 Regression] Incorrect floating point results when compiling with -O3

[andrey.y.guskov at intel dot com]

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

Andrey Guskov  changed:

   What|Removed |Added

 CC||andrey.y.guskov at intel dot 
com

--- Comment #5 from Andrey Guskov  ---
The revision 245968 breaks compilation of 465.tonto from SPEC2006 with these
options:

-m32 -Ofast -flto -march=core-avx2

Stack trace:

crystal.fppized.f90: In function 'put_fcalc_plots':
crystal.fppized.f90:3604:0: internal compiler error: in vect_get_slp_vect_defs,
at tree-vect-slp.c:3272
subroutine put_fcalc_plots(self)

0xd4e35f vect_get_slp_vect_defs
source/gcc/tree-vect-slp.c:3272
0xd4e35f vect_get_slp_defs(vec, _slp_tree*,
vec, va_heap, vl_ptr>*, int)
source/gcc/tree-vect-slp.c:3366
0xd12d64 vect_get_vec_defs(tree_node*, tree_node*, gimple*, vec*, vec*, _slp_tree*, int)
source/gcc/tree-vect-stmts.c:1558
0xd18461 vectorizable_operation
source/gcc/tree-vect-stmts.c:5484
0xd2b9f3 vect_transform_stmt(gimple*, gimple_stmt_iterator*, bool*, _slp_tree*,
_slp_instance*)
source/gcc/tree-vect-stmts.c:8654
0xd4b48e vect_schedule_slp_instance
source/gcc/tree-vect-slp.c:3703
0xd4b20f vect_schedule_slp_instance
source/gcc/tree-vect-slp.c:3581
0xd4b20f vect_schedule_slp_instance
source/gcc/tree-vect-slp.c:3581
0xd4bb66 vect_schedule_slp(vec_info*)
source/gcc/tree-vect-slp.c:3775
0xd32da4 vect_transform_loop(_loop_vec_info*)
source/gcc/tree-vect-loop.c:7054
0xd51524 vectorize_loops()
source/gcc/tree-vectorizer.c:687
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
lto-wrapper: fatal error: gfortran returned 1 exit status
compilation terminated.
ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status
specmake: *** [tonto] Error 1

[Bug fortran/39239] Reject SAVEd variables EQUIVALENCEd to a COMMON

[koenigni at student dot ethz.ch]

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

--- Comment #6 from Nicolas Koenig  ---
Created attachment 40962
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40962=edit
Proposed patch for EQUIVALENCE / VOLATILE

This patch should cover the case of one EQUIVALENCE object being VOLATILE (In
this case every object should be volatile according to the standard). It also
fixes a testcase (gfortran.dg/volatile11.90) related to this.

[Bug ada/80033] New: style suggestions for gcc/ada/gcc-interface/Makefile.in

[nicolas.boulenguez at free dot fr]

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

Bug ID: 80033
   Summary: style suggestions for
gcc/ada/gcc-interface/Makefile.in
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nicolas.boulenguez at free dot fr
  Target Milestone: ---

Created attachment 40961
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40961=edit
This diff contains the suggestions.

Hello.
Please consider the attached changes improving a bit the readability of the Ada
main Makefile.
Thanks.

[Bug tree-optimization/80032] [6/7 Regression] C++ excessive stack usage (no stack reuse)

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
cddce1 removes them for -fno-exceptions case.

[Bug target/80019] ICE in ix86_vector_duplicate_value, at config/i386/i386.c:42584

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-03-13
   Assignee|unassigned at gcc dot gnu.org  |ubizjak at gmail dot com
 Ever confirmed|0   |1

--- Comment #1 from Uroš Bizjak  ---
Created attachment 40960
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40960=edit
Patch in testing

[Bug tree-optimization/80032] [6/7 Regression] C++ excessive stack usage (no stack reuse)

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
(In reply to Richard Biener from comment #1) 
> For trunk ehcleanup1 removes them.

Though with -fno-exceptions, they are gone before hand.

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

[Bug middle-end/78339] -fsuggest-attribute=noreturn should not warn on -fcheck-pointer-bounds clones

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

  Known to work||7.0

--- Comment #3 from Martin Liška  ---
Fixed on trunk so far.

[Bug middle-end/78339] -fsuggest-attribute=noreturn should not warn on -fcheck-pointer-bounds clones

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
Author: marxin
Date: Mon Mar 13 15:30:17 2017
New Revision: 246098

URL: https://gcc.gnu.org/viewcvs?rev=246098=gcc=rev
Log:
Do not warn -Wsuggest-attribute=noreturn for main.chkp (PR middle-end/78339).

2017-03-13  Martin Liska  

PR middle-end/78339
* ipa-pure-const.c (warn_function_noreturn): If the declarations
is a CHKP clone, use original declaration.
2017-03-13  Martin Liska  

PR middle-end/78339
* gcc.target/i386/mpx/pr78339.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/mpx/pr78339.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-pure-const.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/80032] [6/7 Regression] C++ excessive stack usage (no stack reuse)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-03-13
   Target Milestone|--- |6.4
Summary|C++ excessive stack usage   |[6/7 Regression] C++
   |(no stack reuse)|excessive stack usage (no
   ||stack reuse)
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
  test::db::ManagedObjectConst::ManagedObjectConst (, _1);
  test::db::FieldInfo::FieldInfo (, , 11, 0);

D.2393 (and other temporaries from other uses) live throughout the whole
function (no clobbers).  With GCC 5 we have

  _64 = test::db::ManagedObjectConst::getFieldDefault (_59, 11, 0);
  test::db::ManagedObjectConst::ManagedObjectConst (, _59);
  test::db::FieldInfo::FieldInfo (, , 11, 0);
  _68 = test::db::compare (, _64);
  D.2188 ={v} {CLOBBER};
  D.2187 ={v} {CLOBBER};
  if (_68 != 0)
goto ;

so they have clobbers.

For trunk ehcleanup1 removes them.

[Bug sanitizer/80028] Failure to build allyesconfig arm64 kernel using aarch64-none-linux-gnu

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
This smells like the code got too big for the current memory model.

[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

[Bug c++/80029] [6/7 Regression] valgrind error in new_omp_context(omp_region_type) (gimplify.c:400)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.4