[Bug c++/79318] conversion member function preceded with & is not marked as error

[gcc at mailinator dot com]

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

--- Comment #1 from John Simon  ---
Full example:

#include 

using namespace std;


class Foo
{
  private:
int a;
  public:
Foo():a(0){};
 int() {return a;};  // this fails with Clang
};


int main()
{
  Foo foo;

  int x = foo;

  cout << x << endl;  

}

[Bug c++/79318] New: conversion member function preceded with & is not marked as error

[gcc at mailinator dot com]

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

Bug ID: 79318
   Summary: conversion member function preceded with & is not
marked as error
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc at mailinator dot com
  Target Milestone: ---

See example and discussion on
https://stackoverflow.com/questions/41954449/what-does-gccs-conversion-function-operator-int-do

Conversion member function declaration like

 int ();

does not produce a warning or error and is interpreted as

operator int& ();

by GCC. It fails on e.g. CLANG. 
Usage of & in front of operator seems not to be covered by the language
definition.

Verified up to gcc 6.3.

[Bug libquadmath/79317] New: logq is returning double precision results

[ggoeckel at presby dot edu]

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

Bug ID: 79317
   Summary: logq is returning double precision results
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libquadmath
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ggoeckel at presby dot edu
  Target Milestone: ---

While comparing my quad-precision calculations of ln(x) with logq(x), I noticed
that the two numbers agreed only at 17 digits, leading me to assume that logq
must have a double precision bug within it.

Here is my program:

#include 
#include 
#include 
#include 
#include 
#include 
#include 

using namespace std;

__float128 serieslog(__float128 x)
{
 if(x==1.) return 0.; 
 x=1-x;
 __float128 sum=0.,xp=1.,t=1.;
 int n=0;
 while(fabsq(t)>1.e-33&<100)
 {
  n++;
  xp*=x;
  t=xp/n;
  sum+=t;
  t=fabsq(t/sum);
 }
 return -sum;
}
__float128 natlog(__float128 x)
{
 __float128
lntwo=6.9314718055994530941723212145817446e-01,fourthirds=4.,twothirds=2.;
 fourthirds/=3.;
 twothirds/=3.;
 __float128  mantissa=x;
 int exponent=0;
 while(mantissa>fourthirds)
 {
  mantissa/=1024.;
  exponent+=10;
 }
 while(mantissafourthirds)
 {
  mantissa/=256.;
  exponent+=8;
 }
 while(mantissafourthirds)
 {
  mantissa/=64.;
  exponent+=6;
 }
 while(mantissafourthirds)
 {
  mantissa/=16.;
  exponent+=4;
 }
 while(mantissafourthirds)
 {
  mantissa/=4.;
  exponent+=2;
 }
 while(mantissa0.)
  {
   y=log10q(y);
   z=floorq(y);
   y=y-z;
   y=expq(logq(10.)*y);
   if(y<5.)
z=-z;
   else
z=-z-1.;
  }
  else
   z=34;
  quadmath_snprintf (buf, sizeof buf, "%#*.0Qf", 2, z);
  bout << buf << endl;
 }
 return 0;
}

I am using cygwin. \cygwin64\lib\gcc\x86_64-w64-mingw32\5.4.0

My compiling commands are
g++ quadlogtest.cpp -lquadmath -o quadlogtest.exe

[Bug c++/79316] New: Default parameter values in explicit deduction guides do not work

[mike at spertus dot com]

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

Bug ID: 79316
   Summary: Default parameter values in explicit deduction guides
do not work
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mike at spertus dot com
  Target Milestone: ---

When I compile the following code with gcc-7-20170122,

  template struct S { S(T t) {} };
  template S(T, int = 7) -> S;

I get the following error

  error: default arguments are only permitted for function parameters
[-fpermissive]

I believe that the above code should be correct as deduction-guides accept a
parameter-declaration-clause, which can have default argument values. In
addition, P0433R0 contains examples of deduction guides with default arguments
(e.g., for deque).

[Bug fortran/79313] associate statement inside openmp loop breaks OMP intrinisics

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #3 from Steve Kargl  ---
On Wed, Feb 01, 2017 at 04:37:52AM +, kargl at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79313
> 
> --- Comment #2 from kargl at gcc dot gnu.org ---
> Your code looks bogus.  If you add 
> 
>   use omp_lib 
> 
> to the code.  It compiles and works.
> 

An alternative is to add the line

include 'omp_lib.h'

after the 'implicit none' statement in lieu of the module.

A 3rd alternative is change your declaration in the subroutine to

integer, external :: omp_get_thread_num, omp_get_num_threads

[Bug fortran/79313] associate statement inside openmp loop breaks OMP intrinisics

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #2 from kargl at gcc dot gnu.org ---
Your code looks bogus.  If you add 

  use omp_lib 

to the code.  It compiles and works.

[Bug libstdc++/77704] Data race on std::ctype

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed|2016-09-23 00:00:00 |2017-2-1

--- Comment #3 from Jonathan Wakely  ---
Yes that's why the bug report is still open.

[Bug tree-optimization/79315] ICE while building SPEC CPU 2006 FP with -Ofast -ftree-parallelize-loops

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
gamess also fails the same way.

[Bug tree-optimization/38170] diff failure in cactusADM benchmark when -ftree-parallelize-loops=4 is enabled

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #2 from Andrew Pinski  ---
No feedback in a year and this works for me so closing as such.

[Bug tree-optimization/38168] failure in gamess benchmark when -ftree-parallelize-loops=4 is enabled

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

--- Comment #2 from Andrew Pinski  ---
No feedback in a year so closing.

[Bug middle-end/37951] -ftree-parallelize-loops=2 fails

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |4.5.0
  Known to fail||

--- Comment #14 from Andrew Pinski  ---
Closing as fixed.

[Bug tree-optimization/79315] New: ICE while building SPEC CPU 2006 FP with -Ofast -ftree-parallelize-loops

[pinskia at gcc dot gnu.org]

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

Bug ID: 79315
   Summary: ICE while building SPEC CPU 2006 FP with -Ofast
-ftree-parallelize-loops
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64-linux-gnu

I don't know if this is a GCC 7 regression or not.
Compiling wrf in SPEC CPU 2006 FP  with -Ofast -ftree-parallelize-loops
produces an ICE about location references block not in block tree.

Reduced example:
SUBROUTINE wsm32D(t, &
   w, &
   den, &
   p, &
   delz, &
 its,&
   ite, &
   kts, &
   kte  &
  )
  REAL, DIMENSION( its:ite , kts:kte ),   &
INTENT(INOUT) ::  &
   t
  REAL, DIMENSION( ims:ime , kms:kme ),   &
INTENT(IN   ) ::   w, &
 den, &
   p, &
delz
  REAL, DIMENSION( its:ite , kts:kte ) :: &
qs, &
xl, &
work1, &
work2, &
qs0, &
n0sfac
  diffus(x,y) = 8.794e-5*x**1.81/y
  diffac(a,b,c,d,e) = d*a*a/(xka(c,d)*rv*c*c)+1./(e*diffus(c,b))
  venfac(a,b,c) = (viscos(b,c)/diffus(b,a))**(.333)   &
 /viscos(b,c)**(.5)*(den0/c)**0.25
  do loop = 1,loops
  xa=-dldt/rv
  do k = kts, kte
do i = its, ite
  tr=ttp/t(i,k)
  if(t(i,k).lt.ttp) then
qs(i,k) =psat*(tr**xa)*exp(xb*(1.-tr))
  endif
  qs0(i,k)  =psat*(tr**xa)*exp(xb*(1.-tr))
enddo
do i = its, ite
  if(t(i,k).ge.t0c) then
work1(i,k) = diffac(xl(i,k),p(i,k),t(i,k),den(i,k),qs(i,k))
  endif
  work2(i,k) = venfac(p(i,k),t(i,k),den(i,k))
enddo
  enddo
  enddo  ! big loops
END SUBROUTINE wsm32D

This produces:

t.f90:1:0:

 SUBROUTINE wsm32D(t, &

Error: location references block not in block tree
__builtin_powf
_224 = __builtin_powf (_38, 1.80942779541015625e+0);
t.f90:1:0: Error: location references block not in block tree
__builtin_powf
_229 = __builtin_powf (pretmp_227, 1.80942779541015625e+0);
t.f90:1:0: internal compiler error: verify_gimple failed
0xc37737 verify_gimple_in_cfg(function*, bool)
../../gcc/gcc/tree-cfg.c:5266
0xb14063 execute_function_todo
../../gcc/gcc/passes.c:1966
0xb151d3 execute_todo
../../gcc/gcc/passes.c:2016
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug libstdc++/77704] Data race on std::ctype

[lz96 at foxmail dot com]

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

htfy96  changed:

   What|Removed |Added

 CC||lz96 at foxmail dot com

--- Comment #2 from htfy96  ---
Still exist on 6.3.1.

[Bug c++/79314] New: friend function with qualified name definition

[litteras at ukr dot net]

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

Bug ID: 79314
   Summary: friend function with qualified name definition
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: litteras at ukr dot net
  Target Milestone: ---

http://eel.is/c++draft/class.friend#6 :
A function can be defined in a friend declaration of a class if and only if the
class is a non-local class ([class.local]), the function name is unqualified,
and the function has namespace scope.

note : can be defined if the function name is unqualified
however, following is acceptable with the compiler :
[ 
   namespace M { void f() ; }   
   namespace G { struct B { friend void M::f() { } } ; }
]
icc output :
"friend_qualified_definition.cxx(10): error: a qualified name is not allowed
for a friend declaration that is a function definition
  namespace G { struct B { friend void M::f() { } } ; }"

[Bug fortran/79313] associate statement inside openmp loop breaks OMP intrinisics

[mlevy at ucar dot edu]

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

--- Comment #1 from Michael Levy  ---
It looks like I accidentally attached the toy problem with the offending lines
commented out... uncomment lines 27 & 29 to create build issue. Sorry!

[Bug fortran/79313] New: associate statement inside openmp loop breaks OMP intrinisics

[mlevy at ucar dot edu]

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

Bug ID: 79313
   Summary: associate statement inside openmp loop breaks OMP
intrinisics
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mlevy at ucar dot edu
  Target Milestone: ---

Created attachment 40642
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40642=edit
Toy problem highlighting the issue

I get the following build-time errors if I try to access omp_get_thread_num()
and omp_get_num_threads() in an associate block [which has nothing to do with
those functions] while inside an OpenMP loop:

$ gfortran -fopenmp omptest.F90 
omptest.F90:28:18:

   write(*,100) omp_get_thread_num(), omp_get_num_threads()
  1
Error: 'omp_get_thread_num' at (1) is not a function
omptest.F90:28:40:

   write(*,100) omp_get_thread_num(), omp_get_num_threads()
1
Error: 'omp_get_num_threads' at (1) is not a function

If I remove the associate block (comment out lines 27 & 29) then the code
compiles and runs as expected*

I have verified that this error occurs with gfortran 4.6.4, 4.7.4, 4.8.5,
4.9.3, 5.0.1, 5.1.0, 5.2.0, 5.3.0, 5.4.0, 6.0.1, 6.1.0, and 6.3.0; 4.4.7 does
not support associate statements and I do not have easy access to a machine
with 4.5.Z or 6.2.Z (4.5 may predate associates as well).

* Expected output with 2 threads:

$ export OMP_NUM_THREADS=2
$ ./a.out 
thread 0 / 2
thread 1 / 2
thread 0 / 1
thread 0 / 1

[Bug debug/59319] gcc does not emit DW_AT_friend or DW_TAG_friend

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

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

--- Comment #2 from Alexandre Oliva  ---
Revised patch 
https://gcc.gnu.org/ml/gcc-patches/2016-08/msg02092.html
last refreshed and pinged at
https://gcc.gnu.org/ml/gcc-patches/2017-01/msg02112.html

[Bug target/79268] [6/7 Regression] Wrong code generation for vec_xl and vec_xst intrinsics

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Bill Schmidt  ---
Fixed.

[Bug target/79268] [6/7 Regression] Wrong code generation for vec_xl and vec_xst intrinsics

[wschmidt at gcc dot gnu.org]

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

--- Comment #2 from Bill Schmidt  ---
Author: wschmidt
Date: Tue Jan 31 22:57:55 2017
New Revision: 245075

URL: https://gcc.gnu.org/viewcvs?rev=245075=gcc=rev
Log:
[gcc]

2017-01-31  Bill Schmidt  

Backport from mainline
2017-01-29  Bill Schmidt  

PR target/79268
* config/rs6000/altivec.h (vec_xl): Revise #define.
(vec_xst): Likewise.

[gcc/testsuite]

2017-01-31  Bill Schmidt  

Backport from mainline
2017-01-29  Bill Schmidt  

PR target/79268
* gcc.target/powerpc/pr79268.c: New file.
* gcc.target/powerpc/vsx-elemrev-1.c: Delete file.
* gcc.target/powerpc/vsx-elemrev-2.c: Likewise.
* gcc.target/powerpc/vsx-elemrev-3.c: Likewise.
* gcc.target/powerpc/vsx-elemrev-4.c: Likewise.


Added:
branches/gcc-6-branch/gcc/testsuite/gcc.target/powerpc/pr79268.c
Removed:
branches/gcc-6-branch/gcc/testsuite/gcc.target/powerpc/vsx-elemrev-1.c
branches/gcc-6-branch/gcc/testsuite/gcc.target/powerpc/vsx-elemrev-2.c
branches/gcc-6-branch/gcc/testsuite/gcc.target/powerpc/vsx-elemrev-3.c
branches/gcc-6-branch/gcc/testsuite/gcc.target/powerpc/vsx-elemrev-4.c
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/config/rs6000/altivec.h
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug target/79295] [7 regression] gcc.target/powerpc/bcd-3.c fails starting with r244942

[segher at gcc dot gnu.org]

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

--- Comment #1 from Segher Boessenkool  ---
So operands[0] is wrong (should be an AltiVec reg, is an FP reg).

[Bug debug/63238] DWARF does not represent _Alignas

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-01-31
 CC||aoliva at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |aoliva at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Alexandre Oliva  ---
The patch that was already installed largely implements the feature, but
there's a complement that's still pending review, so I'm keeping this open.
https://gcc.gnu.org/ml/gcc-patches/2017-01/msg02337.html

[Bug fortran/79312] New: Empty array in assignment not correctly type-checked

[john.harper at vuw dot ac.nz]

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

Bug ID: 79312
   Summary: Empty array in assignment not correctly type-checked
   Product: gcc
   Version: 6.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: john.harper at vuw dot ac.nz
  Target Milestone: ---

This program violates f2008 syntax rule 7.2.1.2(4) but gfortran 6.1.1 on an
x86-64 system compiles and runs it, printing 0

   program emptyarray5
implicit none
real a(0)
a = [logical::]
print *,size(a)
  end program emptyarray5

! f2008 7.2.1.2 (4) if the variable is polymorphic it shall be type
! compatible with expr ; otherwise the declared types of the variable and
! expr shall conform as specified in Table 7.8,
!
! Table 7.8: Type conformance for the intrinsic assignment statement
!
! Type of the variable | Type of expr
!---+
!   integer|   integer, real, complex   |
! real |   integer, real, complex   |
!   complex|   integer, real, complex   |
!  character   |  character |
!   logical|   logical  |
!  derived type|  same derived type as the variable |
!---+

[Bug fortran/79311] New: internal compiler error: generate_finalization_wrapper

[liakhdi at ornl dot gov]

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

Bug ID: 79311
   Summary: internal compiler error: generate_finalization_wrapper
   Product: gcc
   Version: 6.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: liakhdi at ornl dot gov
  Target Milestone: ---

Created attachment 40641
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40641=edit
Source reproducer

Below is the GFORTRAN internal compiler error backtrace I encountered. There
are four source files in the attachment and a simple make script. Files
dil_basic.F90, tensor_algebra.F90, and stsubs.F90 are just auxiliary utilities.
The problematic source file is tensor_recursive.F90. There are three classes
defined there: tens_signature_t, tens_shape_t, and tens_header_t. The latter
class contains two components of the former types (tens_signature_t and
tens_shape_t). While Final subroutines in the tens_signature_t and tens_shape_t
compile fine, the Final subroutine in the composite class fails to compile with
an internal compiler error (below). If you comment it in the type declaration
(tens_header_t), it will compile. Please help fixing this issue:

f951: internal compiler error: in generate_finalization_wrapper, at
fortran/class.c:1972
0x63e92a generate_finalization_wrapper
../../cray-gcc-6.2.0/gcc/fortran/class.c:1972
0x63e92a gfc_find_derived_vtab(gfc_symbol*)
../../cray-gcc-6.2.0/gcc/fortran/class.c:2404
0x63fcf5 finalize_component
../../cray-gcc-6.2.0/gcc/fortran/class.c:995
0x63ed9e generate_finalization_wrapper
../../cray-gcc-6.2.0/gcc/fortran/class.c:2128
0x63ed9e gfc_find_derived_vtab(gfc_symbol*)
../../cray-gcc-6.2.0/gcc/fortran/class.c:2404
0x6b02e0 gfc_resolve_finalizers
../../cray-gcc-6.2.0/gcc/fortran/resolve.c:12198
0x6c5573 resolve_fl_derived
../../cray-gcc-6.2.0/gcc/fortran/resolve.c:13463
0x6c0476 resolve_symbol
../../cray-gcc-6.2.0/gcc/fortran/resolve.c:13762
0x6d9dbb do_traverse_symtree
../../cray-gcc-6.2.0/gcc/fortran/symbol.c:3926
0x6c36aa resolve_types
../../cray-gcc-6.2.0/gcc/fortran/resolve.c:1
0x6bf0df gfc_resolve(gfc_namespace*)
../../cray-gcc-6.2.0/gcc/fortran/resolve.c:15665
0x6aaaf4 gfc_parse_file()
../../cray-gcc-6.2.0/gcc/fortran/parse.c:6059
0x6ebed2 gfc_be_parse_file
../../cray-gcc-6.2.0/gcc/fortran/f95-lang.c:201

[Bug fortran/79305] real128 - undefined reference to cexpl

[kargl at gcc dot gnu.org]

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

--- Comment #7 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Tue Jan 31 21:42:01 2017
New Revision: 245074

URL: https://gcc.gnu.org/viewcvs?rev=245074=gcc=rev
Log:
2017-01-31  Steven G. Kargl  

PR fortran/79305
* c99_protos.h: Spell HAVE_EXPL correctly.
* intrinsics/c99_functions.c: Ditto.

Modified:
branches/gcc-5-branch/libgfortran/ChangeLog
branches/gcc-5-branch/libgfortran/c99_protos.h
branches/gcc-5-branch/libgfortran/intrinsics/c99_functions.c

[Bug middle-end/79310] -Wnonnull false positive on strlen after strstr

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||missed-optimization

--- Comment #1 from Martin Sebor  ---
A similar case and optimization opportunity (and also a possible source of
false positives) exists with strchr.

$ cat t.c && gcc -O2 -S -Wall -fdump-tree-optimized=/dev/stdout t.c
void foo (const char *s, int x)
{
  if (!__builtin_strchr (s, '\0'))
__builtin_abort ();
}

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

foo (const char * s, int x)
{
  char * _1;
  long unsigned int _4;

   [100.00%]:
  _4 = __builtin_strlen (s_3(D));
  _1 = s_3(D) + _4;
  if (_1 == 0B)
goto ; [0.04%]
  else
goto ; [99.96%]

   [0.04%]:
  __builtin_abort ();

   [99.96%]:
  return;

}

[Bug fortran/79305] real128 - undefined reference to cexpl

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |kargl at gcc dot gnu.org
   Target Milestone|--- |5.5

--- Comment #8 from kargl at gcc dot gnu.org ---
Fixed on 5 and 6 branches and trunk.

[Bug c++/79304] [7 Regression] diagnostic shows bogus expression ((X*)this)->.c

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #4 from Jakub Jelinek  ---
Fixed.

[Bug c++/79304] [7 Regression] diagnostic shows bogus expression ((X*)this)->.c

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Tue Jan 31 21:38:00 2017
New Revision: 245073

URL: https://gcc.gnu.org/viewcvs?rev=245073=gcc=rev
Log:
PR c++/79304
* error.c (dump_expr) : Don't print .
after ARROW_EXPR.

* g++.dg/diagnostic/pr79304.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/diagnostic/pr79304.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/error.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/61520] False warning: array subscript is below array bounds (-Warray-bounds -O -ftree-vrp -funroll-loops)

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||law at redhat dot com
 Resolution|--- |WORKSFORME

--- Comment #2 from Jeffrey A. Law  ---
I went back to a gcc-4.8 based compiler, but could not reproduce this failure.  

If you can trigger the problem, don't hestitate to re-open and I'll be happy to
iterate with you to help track down why it fails for you, but not me.

[Bug c++/79298] [7 Regression] ICE on invalid C++ code on x86_64-linux-gnu: Segmentation fault

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #5 from David Malcolm  ---
Should be fixed by r245072; marking as resolved.

[Bug c++/79298] [7 Regression] ICE on invalid C++ code on x86_64-linux-gnu: Segmentation fault

[dmalcolm at gcc dot gnu.org]

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

--- Comment #4 from David Malcolm  ---
Author: dmalcolm
Date: Tue Jan 31 21:30:42 2017
New Revision: 245072

URL: https://gcc.gnu.org/viewcvs?rev=245072=gcc=rev
Log:
Fix ICE with spelling hints within explicit namespace aliases (PR c++/79298)

gcc/cp/ChangeLog:
PR c++/79298
* name-lookup.c (suggest_alternative_in_explicit_scope): Resolve
any namespace aliases.

gcc/testsuite/ChangeLog:
PR c++/79298
* g++.dg/spellcheck-pr79298.C: New test case.

Added:
trunk/gcc/testsuite/g++.dg/spellcheck-pr79298.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/name-lookup.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/79310] New: -Wnonnull false positive on strlen after strstr

[msebor at gcc dot gnu.org]

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

Bug ID: 79310
   Summary: -Wnonnull false positive on strlen after strstr
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

The following test case reduced from bootstrap-ubsan warnings seen in adaint.c
(see bug 79309) shows that GCC makes the assumption that if strstr(s, "")
returns null it must be because s is null.  But since calling strstr with a
null argument is undefined (and the function is appropriately declared with
attribute nonnull), the argument can be assumed to be non-null, the if
statement not reachable, and the -Wnonnull warning therefore viewed as a false
positive (or at least confusing).

I think it would be better if GCC removed the whole if statement as unreachable
in this case and other like it (perhaps also issuing a warning pointing it out
when doing so).

$ cat t.c && gcc -O2 -S -Wall -fdump-tree-post_ipa_warn=/dev/stdout t.c
int g (const char *s)
{
  if (!__builtin_strstr (s, ""))
return __builtin_strlen (s);

  return 0;
}


;; Function g (g, funcdef_no=0, decl_uid=1795, cgraph_uid=0, symbol_order=0)

t.c: In function ‘g’:
t.c:4:12: warning: argument 1 null where non-null expected [-Wnonnull]
 return __builtin_strlen (s);
^~~~
t.c:4:12: note: in a call to built-in function ‘__builtin_strlen’
g (const char * s)
{
  long unsigned int _1;
  int _2;
  int _5;

   [100.00%]:
  if (s_3(D) == 0B)
goto ; [33.47%]
  else
goto ; [66.53%]

   [33.47%]:
  _1 = __builtin_strlen (0B);
  _5 = (int) _1;

   [100.00%]:
  # _2 = PHI <_5(3), 0(2)>
  return _2;

}

[Bug fortran/79305] real128 - undefined reference to cexpl

[kargl at gcc dot gnu.org]

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

--- Comment #6 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Tue Jan 31 21:20:10 2017
New Revision: 245071

URL: https://gcc.gnu.org/viewcvs?rev=245071=gcc=rev
Log:
2017-01-31  Steven G. Kargl  

PR fortran/79305
* c99_protos.h: Spell HAVE_EXPL correctly.
* intrinsics/c99_functions.c: Ditto.

Modified:
branches/gcc-6-branch/libgfortran/ChangeLog
branches/gcc-6-branch/libgfortran/c99_protos.h
branches/gcc-6-branch/libgfortran/intrinsics/c99_functions.c

[Bug tree-optimization/43965] Missed VRP and/or jump-threading

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||law at redhat dot com
 Resolution|--- |FIXED

--- Comment #4 from Jeffrey A. Law  ---
Fixed by the combination of a variety of commits through the last few years. 
Now we get:

movl4(%esp), %eax
movl(%eax), %edx
movl8(%esp), %eax
testl   %edx, %edx
movl(%eax), %eax
je  .L2
movl(%edx), %ecx
xorl%edx, %edx
testl   %eax, %eax
je  .L3
.L5:
movl(%eax), %edx
.L3:
movl%ecx, %eax
subl%edx, %eax
cmpl%ecx, %edx
movl$0, %edx
cmove   %edx, %eax
ret
.p2align 4,,7
.p2align 3
.L2:
xorl%ecx, %ecx
testl   %eax, %eax
jne .L5
ret

[Bug ada/79309] incorrectly bounded calls to strncat in adaint.c

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||build, patch

--- Comment #1 from Martin Sebor  ---
The following patch fixes the problem:

diff --git a/gcc/ada/adaint.c b/gcc/ada/adaint.c
index 54a1d6e..483997f 100644
--- a/gcc/ada/adaint.c
+++ b/gcc/ada/adaint.c
@@ -3401,9 +3401,8 @@ void __gnat_killprocesstree (int pid, int sig_num)

   /* read /proc//stat */

-  strncpy (statfile, "/proc/", sizeof(statfile));
-  strncat (statfile, d->d_name, sizeof(statfile));
-  strncat (statfile, "/stat", sizeof(statfile));
+  sprintf (statfile, "/proc/%.*s/stat",
+  (int)(sizeof statfile - 12), d->d_name);

   FILE *fd = fopen (statfile, "r");

[Bug ada/79309] New: incorrectly bounded calls to strncat in adaint.c

[msebor at gcc dot gnu.org]

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

Bug ID: 79309
   Summary: incorrectly bounded calls to strncat in adaint.c
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

A profiled-bootstrap reveals a few warnings in gcc/ada/adaint.c.  The Wnonnull
instance look like false positives but the -Wstringop-overflow warning points
out an incorrect use of the strncat function.

In file included from /src/gcc/git-svn/gcc/system.h:691:0,
 from /src/gcc/git-svn/gcc/ada/adaint.c:107:
/src/gcc/git-svn/gcc/ada/adaint.c: In function ‘char* __gnat_locate_exec(char*,
char*)’:
/src/gcc/git-svn/gcc/ada/adaint.c:2837:12: warning: argument 1 null where
non-null expected [-Wnonnull]
(strlen (exec_name) + strlen (HOST_EXECUTABLE_SUFFIX) + 1);
 ~~~^~~
/src/gcc/git-svn/gcc/../include/libiberty.h:722:37: note: in definition of
macro ‘alloca’
 # define alloca(x) __builtin_alloca(x)
 ^
In file included from
/ssd/build/gcc-git-svn-ubsan/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/cstring:42:0,
 from /src/gcc/git-svn/gcc/system.h:235,
 from /src/gcc/git-svn/gcc/ada/adaint.c:107:
/usr/include/string.h:398:15: note: in a call to function ‘size_t strlen(const
char*)’ declared here
 extern size_t strlen (const char *__s)
   ^~
/src/gcc/git-svn/gcc/ada/adaint.c:2839:14: warning: argument 2 null where
non-null expected [-Wnonnull]
   strcpy (full_exec_name, exec_name);
   ~~~^~~
In file included from
/ssd/build/gcc-git-svn-ubsan/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/cstring:42:0,
 from /src/gcc/git-svn/gcc/system.h:235,
 from /src/gcc/git-svn/gcc/ada/adaint.c:107:
/usr/include/string.h:129:14: note: in a call to function ‘char* strcpy(char*,
const char*)’ declared here
 extern char *strcpy (char *__restrict __dest, const char *__restrict __src)
  ^~
/src/gcc/git-svn/gcc/ada/adaint.c: In function ‘void
__gnat_killprocesstree(int, int)’:
/src/gcc/git-svn/gcc/ada/adaint.c:3405:19: warning: specified bound 64 equals
the size of the destination [-Wstringop-overflow=]
   strncat (statfile, d->d_name, sizeof(statfile));
   ^~~

[Bug preprocessor/79210] [7 Regression] "internal compiler error: in get_substring_ranges_for_loc" processing -Wformat-signedness warning

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #14 from David Malcolm  ---
Should be fixed as of r245070.  I don't intend to fix the location of
stringized tokens at this time, so I'm going to mark this as resolved/fixed.

[Bug preprocessor/79210] [7 Regression] "internal compiler error: in get_substring_ranges_for_loc" processing -Wformat-signedness warning

[dmalcolm at gcc dot gnu.org]

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

--- Comment #13 from David Malcolm  ---
Author: dmalcolm
Date: Tue Jan 31 20:22:43 2017
New Revision: 245070

URL: https://gcc.gnu.org/viewcvs?rev=245070=gcc=rev
Log:
Prevent ICEs due to bogus substring locations (PR preprocessor/79210)

gcc/ChangeLog:
PR preprocessor/79210
* input.c (get_substring_ranges_for_loc): Replace line_width
assertion with error-handling.

gcc/testsuite/ChangeLog:
PR preprocessor/79210
* gcc.dg/format/pr79210.c: New test case.
* gcc.dg/plugin/diagnostic-test-string-literals-2.c (test_pr79210):
New function.


Added:
trunk/gcc/testsuite/gcc.dg/format/pr79210.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/input.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/plugin/diagnostic-test-string-literals-2.c

[Bug preprocessor/79210] [7 Regression] "internal compiler error: in get_substring_ranges_for_loc" processing -Wformat-signedness warning

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

Summary|"internal compiler error:   |[7 Regression] "internal
   |in  |compiler error: in
   |get_substring_ranges_for_lo |get_substring_ranges_for_lo
   |c" processing   |c" processing
   |-Wformat-signedness warning |-Wformat-signedness warning

--- Comment #12 from David Malcolm  ---
This is a regression: the ICE can be triggered with just -Wformat by changing
the "%d" to "%s"; this case worked with gcc 6 and earlier.

[Bug fortran/78640] [F2015] gfortran accepts invalid allocatable polymorphic result in pure function

[vehre at gcc dot gnu.org]

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

vehre at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
 CC||vehre at gcc dot gnu.org

[Bug c++/79290] [7 Regression] forming pointer to member function tries to access "__pfn"

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #4 from Nathan Sidwell  ---
Fixed r245069.

[Bug c++/79290] [7 Regression] forming pointer to member function tries to access "__pfn"

[nathan at gcc dot gnu.org]

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

--- Comment #3 from Nathan Sidwell  ---
Author: nathan
Date: Tue Jan 31 19:37:11 2017
New Revision: 245069

URL: https://gcc.gnu.org/viewcvs?rev=245069=gcc=rev
Log:
PR c++/79290
* typeck.c (build_ptrmemfunc_access_expr): Set TREE_NO_WARNING.

PR c++/79290
* g++.dg/warn/pr79290.C: New.

Added:
trunk/gcc/testsuite/g++.dg/warn/pr79290.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/typeck.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/79298] [7 Regression] ICE on invalid C++ code on x86_64-linux-gnu: Segmentation fault

[dmalcolm at gcc dot gnu.org]

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

--- Comment #3 from David Malcolm  ---
Candidate patch: https://gcc.gnu.org/ml/gcc-patches/2017-01/msg02418.html

[Bug c++/79143] [7 Regression][new inheriting constructors] inheriting constructor fails with brace initialization

[lucdanton at free dot fr]

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

lucdanton at free dot fr changed:

   What|Removed |Added

 CC||lucdanton at free dot fr

--- Comment #1 from lucdanton at free dot fr ---
If it's any help in solving this, the regression only manifests when derived
publicly inherits from its base.

[Bug fortran/79305] real128 - undefined reference to cexpl

[kargl at gcc dot gnu.org]

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

--- Comment #5 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Tue Jan 31 18:50:31 2017
New Revision: 245068

URL: https://gcc.gnu.org/viewcvs?rev=245068=gcc=rev
Log:
2017-01-31  Steven G. Kargl  

PR fortran/79305
* c99_protos.h: Spell HAVE_EXPL correctly.
* intrinsics/c99_functions.c: Ditto.

Modified:
trunk/libgfortran/ChangeLog
trunk/libgfortran/c99_protos.h
trunk/libgfortran/intrinsics/c99_functions.c

[Bug c++/79307] g++ misses warning for reference on temporary that invokes undefined behaviour

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Note -fsanitize=address complains about this (though
==3971==ERROR: AddressSanitizer: stack-buffer-underflow on address
0x7ffef8cabe50 at pc 0x004011db bp 0x7ffef8cabe10 sp 0x7ffef8cabe08
rather than use after scope I was expecting.  CCing Martin.

[Bug c++/79307] g++ misses warning for reference on temporary that invokes undefined behaviour

[glisse at gcc dot gnu.org]

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

--- Comment #2 from Marc Glisse  ---
If I remove the first one, I do get a warning

x.c: In function 'int main()':
x.c:5:47: warning: '' is used uninitialized in this function
[-Wuninitialized]
 void DoSomething() {cout << "int:" << a_ << endl;  }
   ^~
x.c:13:22: note: '' was declared here
 TestRefInt ltfi(8);
  ^

what prevents the warning otherwise:
- several calls -> not inlined
- static initializers are opaque to gcc's optimizers (even with LTO)

[Bug fortran/79305] real128 - undefined reference to cexpl

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #4 from Steve Kargl  ---
On Tue, Jan 31, 2017 at 06:27:06PM +, mexas at bristol dot ac.uk wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79305
> 
> --- Comment #2 from Anton Shterenlikht  ---
> I think the program is standard conforming.
> So strictly speaking the compiler is not standard conforming here, right?
> 

The compiler is standard conforming.  Simply a bug in spelling
HAVE_EXPL as EXPL.  With a patch to 7.0, I have

troutmask:sgk[211] ./z
(1.46869393991588515717,-2.28735528717884239124)

with your program.

[Bug fortran/79305] real128 - undefined reference to cexpl

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #3 from Steve Kargl  ---
On Tue, Jan 31, 2017 at 06:00:43PM +, kargl at gcc dot gnu.org wrote:
> 
> The above will clearly never be built. In fact, a causal perusal
> of c99_protos.h shows that none of the fallback functions in
> c99_functions.c are built.
> 

Ugh.  I retract this part of the analysis.  c99_protos.h is
not used within c99_functions.c.  The issue is an incorrect
spelling of HAVE_EXPL as EXPL.

[Bug fortran/79305] real128 - undefined reference to cexpl

[mexas at bristol dot ac.uk]

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

--- Comment #2 from Anton Shterenlikht  ---
I think the program is standard conforming.
So strictly speaking the compiler is not standard conforming here, right?

I have some tests for complex intrinsics, which I want
to test on real32, real64 and real128.

[Bug c++/79308] Internal compilation error on specialization of nested template classes

[bjh...@sags-per-mail.de]

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

--- Comment #1 from bjhend  ---
Created attachment 40640
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40640=edit
Complete compiler output

[Bug target/78597] test case gcc.dg/torture/fp-int-convert-float128-ieee.c (and others) fail starting with r242780

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

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

--- Comment #4 from Michael Meissner  ---
Fixed in subversion id 245059.

[Bug c++/79308] New: Internal compilation error on specialization of nested template classes

[bjh...@sags-per-mail.de]

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

Bug ID: 79308
   Summary: Internal compilation error on specialization of nested
template classes
   Product: gcc
   Version: 6.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bjh...@sags-per-mail.de
  Target Milestone: ---

Created attachment 40639
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40639=edit
Source code

The following code (attached as element.cpp) causes the error

internal compiler error: in finish_member_declaration, at
cp/semantics.c:2966

when compiled by calling

gcc -v -save-temps -Wall -Wextra -std=c++11  element.cpp

with GCC 6.3.0. The nearly same error is caused by GCC 5.4.1 and GCC 4.8.


---
template 
struct Element
{
Element(void)
{
WriteOutput();
}

template 
struct WriteOutput
{
};
};


template <>
template 
struct Element::WriteOutput
{   // line mentioned in error message
void foo(void)
{
}

virtual void bar(void)
{
}
};


Element e;
---


The error disappears on each of the following changes:

* Remove one of the element functions in the specialization.

* Remove the "virtual" of all element functions.

* Make the specialized type-argument of the outer template different from the
unspecialized template type-argument of the nested template. As long as they
are the same, no matter which actually, the error is triggered.

In these case the compiler complains correctly about the missing main function.

If I find out how to attach another file I will attach the whole compiler
output.

[Bug c++/79253] [7 Regression] ICE in tsubst_copy starting with r243723

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #2 from Nathan Sidwell  ---
Fixed r245067.

[Bug c++/67273] Incorrect -Wshadow warning with generic lambdas

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #5 from Nathan Sidwell  ---
Fixed r245067.

[Bug c++/79253] [7 Regression] ICE in tsubst_copy starting with r243723

[nathan at gcc dot gnu.org]

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

--- Comment #1 from Nathan Sidwell  ---
Author: nathan
Date: Tue Jan 31 18:05:37 2017
New Revision: 245067

URL: https://gcc.gnu.org/viewcvs?rev=245067=gcc=rev
Log:
PR c++/67273
PR c++/79253
* pt.c: (instantiate_decl): Push to top level when current
function scope doesn't match.  Only push lmabda scope stack when
pushing to top.

PR c++/67273
PR c++/79253
* g++.dg/cpp1y/pr67273.C: New.
* g++.dg/cpp1y/pr79253.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/pr67273.C
trunk/gcc/testsuite/g++.dg/cpp1y/pr79253.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/67273] Incorrect -Wshadow warning with generic lambdas

[nathan at gcc dot gnu.org]

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

--- Comment #4 from Nathan Sidwell  ---
Author: nathan
Date: Tue Jan 31 18:05:37 2017
New Revision: 245067

URL: https://gcc.gnu.org/viewcvs?rev=245067=gcc=rev
Log:
PR c++/67273
PR c++/79253
* pt.c: (instantiate_decl): Push to top level when current
function scope doesn't match.  Only push lmabda scope stack when
pushing to top.

PR c++/67273
PR c++/79253
* g++.dg/cpp1y/pr67273.C: New.
* g++.dg/cpp1y/pr79253.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/pr67273.C
trunk/gcc/testsuite/g++.dg/cpp1y/pr79253.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/79305] real128 - undefined reference to cexpl

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #1 from kargl at gcc dot gnu.org ---
(In reply to Anton Shterenlikht from comment #0)
> FreeBSD 11.0-RELEASE-p2
> 
> use, intrinsic :: iso_fortran_env, only: real128
> integer, parameter :: fk = real128
> complex( kind=fk ) :: z
> z = cmplx( 1.0_fk, -1.0_fk, kind=fk )
> write (*,*) exp( z )
> end
> 
> $ gfortran49 z.f90 
> /tmp//ccIF7kVE.o: In function `MAIN__':
> z.f90:(.text+0x79): undefined reference to `cexpl'
> collect2: error: ld returned 1 exit status
> 
> Have I missed something?
> 

Yes, probably a few things.  What are you trying to
accomplish with using REAL128?  This maps to REAL(10)
instead of REAL(16).  The end resutl is that z will
have a 64-bit significand whereas the name REAL128
suggests that it should have a 113-bit significand.

In additional, FreeBSD's libm does not have a cexpl
function.  You'll need to submit a bug report with
FreeBSD; although it won't help much as no one is 
actively working on FreeBSD's libm shortcomings.

config.h in obj7/x86_64-unknown-freebsd12.0/libgfortran
shows the expected

/* Define to 1 if you have the `cexpl' function. */
/* #undef HAVE_CEXPL */

This then gets you to gcc7/libgfortran/c99_protos.h

#if !defined(HAVE_CEXPL) && defined(HAVE_COSL) && defined(HAVE_SINL) &&
defined(EXPL)
#define HAVE_CEXPL 1
extern long double complex cexpl (long double complex);
#endif

so cexpl is exposed to libgfortran; howerver, one then find
in intrinsics/c99_functions.c

#if !defined(HAVE_CEXPL) && defined(HAVE_COSL) && defined(HAVE_SINL) &&
defined(EXPL)
#define HAVE_CEXPL 1
long double complex cexpl (long double complex z);

long double complex
cexpl (long double complex z)
{
  long double a, b;
  long double complex v;

  a = REALPART (z);
  b = IMAGPART (z);
  COMPLEX_ASSIGN (v, cosl (b), sinl (b));
  return expl (a) * v;
}
#endif

The above will clearly never be built. In fact, a causal perusal
of c99_protos.h shows that none of the fallback functions in
c99_functions.c are built.

[Bug c++/79307] g++ misses warning for reference on temporary that invokes undefined behaviour

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #1 from Jonathan Wakely  ---
(In reply to Szikra from comment #0)
> I thought (something like) this was fixed in bug 986
> 
> Code:
> struct TestRefInt {
> TestRefInt(const int& a) : a_(a) {};
> void DoSomething() {cout << "int:" << a_ << endl;  }
> protected:
> const int& a_;
> };

This is harder to diagnose than the 986 cases. There's nothing wrong with
binding the parameter 'a' to a temporary. And (in general) there's nothing
wrong with binding the reference member 'a_' to something that's already a
reference. The problem is indirect, and the two locations might not even be in
the same translation unit.

We still want a warning, but it's harder to do.


> struct TestRefIntDirect {
> TestRefIntDirect(int a) : a_(a) {};
> void DoSomething() {cout << "int:" << a_ << endl;  }
> protected:
> const int& a_;
> };

This is bug 44974.

> Possible duplicate of bug #44859 or bug #51270.

Looks more like bug 49974 to me.

*** This bug has been marked as a duplicate of bug 44974 ***

[Bug middle-end/44974] [4.6 Regression] Function with attribute noreturn omits a call to another function with noreturn

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||steven.spark at gmail dot com

--- Comment #8 from Jonathan Wakely  ---
*** Bug 79307 has been marked as a duplicate of this bug. ***

[Bug c++/79307] New: g++ misses warning for reference on temporary that invokes undefined behaviour

[steven.spark at gmail dot com]

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

Bug ID: 79307
   Summary: g++ misses warning for reference on temporary that
invokes undefined behaviour
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: steven.spark at gmail dot com
  Target Milestone: ---

I thought (something like) this was fixed in bug 986

Code:
struct TestRefInt {
TestRefInt(const int& a) : a_(a) {};
void DoSomething() {cout << "int:" << a_ << endl;  }
protected:
const int& a_;
};

TestRefInt tfi(55);

int main() {
TestRefInt ltfi(8);

tfi.DoSomething();
ltfi.DoSomething();
return 0;
}

The first one does not work, the second one happens to work (but only by
"accident"). 

Similar issue:

struct TestRefIntDirect {
TestRefIntDirect(int a) : a_(a) {};
void DoSomething() {cout << "int:" << a_ << endl;  }
protected:
const int& a_;
};

Lifetime of the temporary is not extended in neither case (as per C++11
standard 12.2 p5).

Tested with MinGW 5.3.0, avr-g++ 4.8.1, 4.9.2.

I would like if warning were produced for these. Any help would be appreciated.

I posted more details on stack overflow
http://stackoverflow.com/questions/41928634/c11-scoping-and-lifetime-of-temporary-bound-to-a-const-reference-gcc

Possible duplicate of bug #44859 or bug #51270.

[Bug bootstrap/78985] [7 Regression] profiledbootstrap failure by -Wuninitialized

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com

--- Comment #14 from Jeffrey A. Law  ---
I thought Andi Kleen had a fix for the issue in c#9.

[Bug target/79170] [7 regression] memcmp builtin expansion sequence can overflow

[acsawdey at gcc dot gnu.org]

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

--- Comment #4 from acsawdey at gcc dot gnu.org ---
Yes, should be fixed with 245041 -- different instruction sequence and a better
memcmp/strncmp regtest to catch this and other things.

[Bug target/79170] [7 regression] memcmp builtin expansion sequence can overflow

[acsawdey at gcc dot gnu.org]

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

acsawdey at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from acsawdey at gcc dot gnu.org ---
Fixed in 245041.

[Bug c++/78771] [5/6/7 Regression] ICE when using inherited constructors (instantiate_template_1 in gcc/cp/pt.c:17391)

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #4 from Nathan Sidwell  ---
jason fixed it

[Bug c++/67273] Incorrect -Wshadow warning with generic lambdas

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

 CC||jens.auer at cgi dot com

--- Comment #3 from Nathan Sidwell  ---
*** Bug 67951 has been marked as a duplicate of this bug. ***

[Bug c++/67951] Wshadow for variable with same name as generic (auto) lambda parameters

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #1 from Nathan Sidwell  ---
Essentially same as 67273, to which I added a clearer testcase

*** This bug has been marked as a duplicate of bug 67273 ***

[Bug c++/79267] [6 Regression] internal compiler error with -O3 or -O2 -finline-functions

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[6/7 Regression] internal   |[6 Regression] internal
   |compiler error with -O3 or  |compiler error with -O3 or
   |-O2 -finline-functions  |-O2 -finline-functions

--- Comment #7 from Jakub Jelinek  ---
Fixed on the trunk so far.

[Bug c++/79304] [7 Regression] diagnostic shows bogus expression ((X*)this)->.c

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Created attachment 40638
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40638=edit
gcc7-pr79304.patch

Untested fix.

[Bug pch/79306] New: ICE on valid code

[vi0oss at gmail dot com]

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

Bug ID: 79306
   Summary: ICE on valid code
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: pch
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vi0oss at gmail dot com
  Target Milestone: ---

I noticed this message on some build log:

(command line approximate)

cd .../WebRTC/webrtc && /usr/bin/c++ -D... -fPIC -msse2 -msse3 -m64 -std=c++11
-g -O0 -fno-inline -D_DEBUG -I... -I.../WebRTC/webrtc/video_coding_pch
-Winvalid-pch -include .../WebRTC/webrtc/video_coding_pch/stdafx.h -o o -c
.../WebRTC/webrtc/modules/video_coding/main/source/codec_database.cc
c++: internal compiler error: Segmentation fault (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Version is 4.8.x. If needed I may try to reproduce and minimize it, but it is
not simple. Turning off precompiled headers makes it build successfully.

[Bug tree-optimization/54810] VRP doesn't handle comparison of narrowing cast like comparison of BIT_AND_EXPR

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 CC||law at redhat dot com
 Resolution|--- |FIXED

--- Comment #3 from Jeffrey A. Law  ---
This was fixed long ago (2013) by improving VRP's ASSERT_EXPR insertion for
loop latches.

[Bug tree-optimization/77362] [6/7 Regression] [graphite] ICE in sese_build_liveouts_use w/ -O2 -floop-nest-optimize

[spop at gcc dot gnu.org]

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

--- Comment #10 from Sebastian Pop  ---
(In reply to Richard Biener from comment #9)
> Yeah, but the user can write such dependences himself so ideally we have
> a way to undo them, like by using local scratch memory?  So

You are right.  LLVM-Polly has a pass that undoes LIM, it is non trivial, and
furthermore we'd better catch the LIM once the loop transforms are done!

> 
>   x_0 = 1;
> 
> loop:
>   # x_1 = PHI 
>   ...
>   x_2 = ...;
>   goto loop;
> 
> turns into
> 
>   mem = 1;
>   
> loop:
>   x_1 = mem;
>   x_2 = ...;
>   mem = x_2;
>   goto loop;
> 
> plus replacement of exit PHIs with loads.  Would that help?

That's how we were handling reductions and end of loop values in the dependence
graph.  Today we can reason about scalars themselves and add the scalars to the
dependence graph instead of generating the loads that would need to be cleaned
up after graphite.

[Bug fortran/79305] New: real128 - undefined reference to cexpl

[mexas at bristol dot ac.uk]

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

Bug ID: 79305
   Summary: real128 - undefined reference to cexpl
   Product: gcc
   Version: 6.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mexas at bristol dot ac.uk
  Target Milestone: ---

FreeBSD 11.0-RELEASE-p2

use, intrinsic :: iso_fortran_env, only: real128
integer, parameter :: fk = real128
complex( kind=fk ) :: z
z = cmplx( 1.0_fk, -1.0_fk, kind=fk )
write (*,*) exp( z )
end

$ gfortran49 z.f90 
/tmp//ccIF7kVE.o: In function `MAIN__':
z.f90:(.text+0x79): undefined reference to `cexpl'
collect2: error: ld returned 1 exit status

$ gfortran6 z.f90 
/tmp//ccq1EOKO.o: In function `MAIN__':
z.f90:(.text+0x62): undefined reference to `cexpl'
collect2: error: ld returned 1 exit status

$ gfortran7 z.f90 
/tmp//ccgH1sQM.o: In function `MAIN__':
z.f90:(.text+0x62): undefined reference to `cexpl'
collect2: error: ld returned 1 exit status

Have I missed something?

Thanks

Anton

[Bug c++/79298] [7 Regression] ICE on invalid C++ code on x86_64-linux-gnu: Segmentation fault

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |dmalcolm at gcc dot 
gnu.org

--- Comment #2 from David Malcolm  ---
My bad, sorry.  Working on a fix.

[Bug tree-optimization/70729] Loop marked with omp simd pragma is not vectorized

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70729
Bug 70729 depends on bug 77318, which changed state.

Bug 77318 Summary: [7 regression] FAIL: gfortran.dg/graphite/pr68279.f90   -O  
(internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77318

   What|Removed |Added

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

[Bug tree-optimization/59859] [meta-bug] GRAPHITE issues

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59859
Bug 59859 depends on bug 77318, which changed state.

Bug 77318 Summary: [7 regression] FAIL: gfortran.dg/graphite/pr68279.f90   -O  
(internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77318

   What|Removed |Added

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

[Bug tree-optimization/77362] [6/7 Regression] [graphite] ICE in sese_build_liveouts_use w/ -O2 -floop-nest-optimize

[rguenth at gcc dot gnu.org]

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

--- Comment #9 from Richard Biener  ---
(In reply to Sebastian Pop from comment #8)
> LIM in general is bad for loop transforms: it introduces loop carried
> dependences. If we can move graphite before LIM that would solve some
> problems.

Yeah, but the user can write such dependences himself so ideally we have
a way to undo them, like by using local scratch memory?  So

  x_0 = 1;

loop:
  # x_1 = PHI 
  ...
  x_2 = ...;
  goto loop;

turns into

  mem = 1;

loop:
  x_1 = mem;
  x_2 = ...;
  mem = x_2;
  goto loop;

plus replacement of exit PHIs with loads.  Would that help?  Or does the
new (non-aliased, loop invariant) memory location complicate things as well?

[Bug tree-optimization/77318] [7 regression] FAIL: gfortran.dg/graphite/pr68279.f90 -O (internal compiler error)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #13 from Richard Biener  ---
Fixed.

[Bug c++/79264] [7 Regression] ICE verify_type failed

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #4 from Nathan Sidwell  ---
Fixed r245065.

[Bug tree-optimization/79284] [7 Regression] ICE on valid code at -O3 on x86_64-linux-gnu: verify_gimple failed

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
Created attachment 40637
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40637=edit
gcc7-pr79284.patch

Untested fix.

[Bug c++/79264] [7 Regression] ICE verify_type failed

[nathan at gcc dot gnu.org]

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

--- Comment #3 from Nathan Sidwell  ---
Author: nathan
Date: Tue Jan 31 15:10:41 2017
New Revision: 245065

URL: https://gcc.gnu.org/viewcvs?rev=245065=gcc=rev
Log:
PR c++/79264
* lambda.c (maybe_generic_this_capture): Deal with
template-id-exprs.
* semantics.c (finish_member_declaration): Assert class is being
defined.

PR c++/79264
* g++.dg/cpp1y/pr61636-1.C: Augment.

Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/lambda.c
trunk/gcc/cp/semantics.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/cpp1y/pr61636-1.C

[Bug tree-optimization/77362] [6/7 Regression] [graphite] ICE in sese_build_liveouts_use w/ -O2 -floop-nest-optimize

[spop at gcc dot gnu.org]

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

--- Comment #8 from Sebastian Pop  ---
LIM in general is bad for loop transforms: it introduces loop carried
dependences. If we can move graphite before LIM that would solve some problems.

[Bug tree-optimization/77362] [6/7 Regression] [graphite] ICE in sese_build_liveouts_use w/ -O2 -floop-nest-optimize

[spop at gcc dot gnu.org]

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

--- Comment #7 from Sebastian Pop  ---
The fix looks good.  Thanks!

[Bug tree-optimization/77318] [7 regression] FAIL: gfortran.dg/graphite/pr68279.f90 -O (internal compiler error)

[rguenth at gcc dot gnu.org]

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

--- Comment #12 from Richard Biener  ---
Author: rguenth
Date: Tue Jan 31 14:44:37 2017
New Revision: 245064

URL: https://gcc.gnu.org/viewcvs?rev=245064=gcc=rev
Log:
2017-01-31  Richard Biener  

PR tree-optimization/77318
* graphite-sese-to-poly.c (extract_affine): Fix assert.
(create_pw_aff_from_tree): Take loop parameter.
(add_condition_to_pbb): Pass loop of the condition to
create_pw_aff_from_tree.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/graphite-sese-to-poly.c

[Bug c++/79304] [7 Regression] diagnostic shows bogus expression ((X*)this)->.c

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #1 from Jonathan Wakely  ---
bisection suggests r236221

[Bug tree-optimization/79284] [7 Regression] ICE on valid code at -O3 on x86_64-linux-gnu: verify_gimple failed

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
So, the problem seems to be that useless_type_conversion_p considers
conversions between BOOLEAN_TYPE and INTEGER_TYPE with precision 1 as useless,
but the vectorizer handles BOOLEAN_TYPE and INTEGER_TYPE with precision 1 very
differently.  When some propagation propagates e.g. INTEGER_TYPE with precision
1 into one operand of a stmt and the other operand is still BOOLEAN_TYPE, we'll
use VECTOR_BOOLEAN_TYPE_P vectype for one of the operands, but a V*QI mode
vectype for the other operand and obviously very bad things happen.

So, shall we change all the places in the vectorizer that check for
BOOLEAN_TYPE to also allow INTEGRAL_TYPE_P that is TYPE_PRECISION == 1 and
TYPE_UNSIGNED?
grep -w BOOLEAN_TYPE tree-vect-[lps]*.c
tree-vect-loop.c: if (TREE_CODE (scalar_type) == BOOLEAN_TYPE
tree-vect-loop.c:!= BOOLEAN_TYPE)
tree-vect-loop.c: && TREE_CODE (TREE_TYPE (gimple_assign_rhs1 (stmt)))
!= BOOLEAN_TYPE)
tree-vect-patterns.c: && TREE_CODE (TREE_TYPE (rhs1)) != BOOLEAN_TYPE)
tree-vect-patterns.c:  && TREE_CODE (TREE_TYPE (var)) != BOOLEAN_TYPE)
tree-vect-patterns.c: if (TREE_CODE (TREE_TYPE (rhs1)) == BOOLEAN_TYPE)
tree-vect-patterns.c:  && TREE_CODE (TREE_TYPE (var)) != BOOLEAN_TYPE)
tree-vect-patterns.c:  if (TREE_CODE (TREE_TYPE (lhs)) != BOOLEAN_TYPE)
tree-vect-slp.c:  if (TREE_CODE (TREE_TYPE (op)) == BOOLEAN_TYPE
tree-vect-stmts.c:  else if (TREE_CODE (TREE_TYPE (op)) == BOOLEAN_TYPE
tree-vect-stmts.c:  if (TREE_CODE (TREE_TYPE (mask)) != BOOLEAN_TYPE)
tree-vect-stmts.c:  if (TREE_CODE (TREE_TYPE (op0)) == BOOLEAN_TYPE)
tree-vect-stmts.c:if (TREE_CODE (TREE_TYPE (scalar_dest)) !=
BOOLEAN_TYPE)
tree-vect-stmts.c:  && TREE_CODE (TREE_TYPE (cond)) == BOOLEAN_TYPE)
tree-vect-stmts.c:  if (TREE_CODE (scalar_type) == BOOLEAN_TYPE)

[Bug middle-end/68664] [6/7 Regression] Speculative sqrt in c-ray main loop causes large slow down

[jgreenhalgh at gcc dot gnu.org]

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

--- Comment #17 from James Greenhalgh  ---
(In reply to David Edelsohn from comment #16)
> > That isn't an argument for -fno-sched-spec, it is an argument for a cost 
> > model which better matches the cost of the transformation, using the 
> > information available, without bloating the automaton.
> 
> And that's what Segher proposed with the patch for the hook on the mailing
> list.

I totally missed the proposal!
https://gcc.gnu.org/ml/gcc-patches/2017-01/msg02101.html for others following
this thread.

[Bug middle-end/68664] [6/7 Regression] Speculative sqrt in c-ray main loop causes large slow down

[dje at gcc dot gnu.org]

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

--- Comment #16 from David Edelsohn  ---
> That isn't an argument for -fno-sched-spec, it is an argument for a cost 
> model which better matches the cost of the transformation, using the 
> information available, without bloating the automaton.

And that's what Segher proposed with the patch for the hook on the mailing
list.

[Bug middle-end/68664] [6/7 Regression] Speculative sqrt in c-ray main loop causes large slow down

[jgreenhalgh at gcc dot gnu.org]

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

--- Comment #15 from James Greenhalgh  ---
(In reply to Segher Boessenkool from comment #14)
> I'm not sure how to read your remark.  An insn where the result is
> not used is not on the critical path by definition; and you seem to
> be arguing for -fno-sched-spec by default?

For cores with in-order execution, a long-running instruction like a
square-root stalls execution until it completes. Even as you move to partially
out-of-order and fully out-of-order execution the cost of executing a useless
instruction is increased demand for limited system resources. For example, even
an insn with an unused result can prevent retire of subsequent instructions
until it completes, and at the very least it holds sqrt/divide resource.

Modelling this resource usage in terms of unit reservations increases the size
of the automaton in a way that quickly makes it unfeasible (see pr70473 and
pr60743 for recent ARM examples).

"Latency" may not be a great name for the cost we're looking for, but it is a
reasonable approximation. If an instruction causes significant resource usage
we ought not to make it speculative.

That isn't an argument for -fno-sched-spec, it is an argument for a cost model
which better matches the cost of the transformation, using the information
available, without bloating the automaton.

[Bug c++/79304] [7 Regression] diagnostic shows bogus expression ((X*)this)->.c

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |7.0

[Bug tree-optimization/79303] ICE: Segmentation fault from apply_schedule_map_to_scop, graphite-optimize-isl.c:429 building 464.h264ref

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener  ---
segfault occurs within ISL with isl 0.14 but not with isl 0.16.1 so not sure if
worth pursuing (well, I guess not).

[Bug tree-optimization/79303] ICE: Segmentation fault from apply_schedule_map_to_scop, graphite-optimize-isl.c:429 building 464.h264ref

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #2 from Richard Biener  ---
Works with new ISL -> ISL bug.

[Bug middle-end/79297] [7 Regression] ICE (segfault) in main_block_label

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Even from the same package...

[Bug tree-optimization/71824] [6/7 Regression] ICE when compiling libiberty with Graphite loop optimizations

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org

--- Comment #10 from Richard Biener  ---
I have a patch.

[Bug target/79038] Improve PowerPC ISA 3.0 conversion between integers and hardware _Float128

[meissner at gcc dot gnu.org]

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

--- Comment #3 from Michael Meissner  ---
Subversion id 245059 fixes the majority of the issues.  However, there are some
enhancements that should be added for GCC 8:

1) Add support for converting IEEE 128-bit floating point to/from char/short
data types that is similar to the support that when in for normal 32-bit and
64-bit floating point types.

2) Add a combiner pattern for converting IEEE 128-bit floating point to 32-bit
integer and storing it in memory so that the register allocator can do the
store directly from the Altivec register instead of using direct move to save
it as a GPR (since the GPR side allows more address forms for int).

3) Similarly, add a combiner pattern when converting from a 32-bit integer in
memory to IEEE 128-bit floating point to avoid having to move it through a GPR.

[Bug middle-end/79297] [7 Regression] ICE (segfault) in main_block_label

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||jakub at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #3 from Jakub Jelinek  ---
This is a clear dup.

*** This bug has been marked as a duplicate of bug 78689 ***

[Bug c++/78689] [7 Regression] ICE (segfault) within cleanup_dead_labels

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
*** Bug 79297 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/79302] [6/7 Regression] ICE in add_loop_constraints, at graphite-sese-to-poly.c:933 building 445.gobmk

[marxin at gcc dot gnu.org]

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

--- Comment #8 from Martin Liška  ---
ICEs with:

./cc1 -fpreprocessed pr79302.i -march=haswell -mmmx -mno-3dnow -msse -msse2
-msse3 -mssse3 -mno-sse4a -mcx16 -msahf -mmovbe -maes -mno-sha -mpclmul
-mpopcnt -mabm -mno-lwp -mfma -mno-fma4 -mno-xop -mbmi -mno-sgx -mbmi2 -mno-tbm
-mavx -mavx2 -msse4.2 -msse4.1 -mlzcnt -mno-rtm -mno-hle -mrdrnd -mf16c
-mfsgsbase -mno-rdseed -mno-prfchw -mno-adx -mfxsr -mxsave -mxsaveopt
-mno-avx512f -mno-avx512er -mno-avx512cd -mno-avx512pf -mno-prefetchwt1
-mno-clflushopt -mno-xsavec -mno-xsaves -mno-avx512dq -mno-avx512bw
-mno-avx512vl -mno-avx512ifma -mno-avx512vbmi -mno-avx5124fmaps
-mno-avx5124vnniw -mno-clwb -mno-mwaitx -mno-clzero -mno-pku --param
l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=8192
-mtune=haswell -quiet -dumpbase pr79302.c -auxbase pr79302 -Ofast -version
-floop-nest-optimize -o pr79302.s

[Bug target/79170] [7 regression] memcmp builtin expansion sequence can overflow

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
So fixed?

[Bug target/78597] test case gcc.dg/torture/fp-int-convert-float128-ieee.c (and others) fail starting with r242780

[meissner at gcc dot gnu.org]

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

--- Comment #3 from Michael Meissner  ---
Author: meissner
Date: Tue Jan 31 13:38:35 2017
New Revision: 245059

URL: https://gcc.gnu.org/viewcvs?rev=245059=gcc=rev
Log:
2017-01-31  Michael Meissner  

PR target/78597
PR target/79038
* config/rs6000/rs6000-protos.h (convert_float128_to_int): Delete,
no longer used.
(convert_int_to_float128): Likewise.
* config/rs6000/rs6000.c (convert_float128_to_int): Likewise.
(convert_int_to_float128): Likewise.
* config/rs6000/rs6000.md (UNSPEC_IEEE128_MOVE): Likewise.
(UNSPEC_IEEE128_CONVERT): Likewise.
(floatsi2, FLOAT128 iterator): Bypass calling
rs6000_expand_float128_convert if we have IEEE 128-bit hardware.
Use local variables for IBM extended format.
(fix_truncsi2, FLOAT128 iterator): Likewise.
(fix_truncsi2_fprs): Likewise.
(fixuns_trunc2): Likewise.
(floatuns2, IEEE128 iterator): Likewise.
(fix_si2_hw): Rework the IEEE 128-bt hardware support
to know that we can now have integers of all sizes in vector
registers.
(fix_di2_hw): Likewise.
(float_si2_hw): Likewise.
(fix_si2_hw): Likewise.
(fixuns_si2_hw): Likewise.
(float_di2_hw): Likewise.
(float_di2_hw): Likewise.
(float_si2_hw): Likewise.
(floatuns_di2_hw): Likewise.
(floatuns_si2_hw): Likewise.
(xscvqpwz_): Delete, no longer used.
(xscvqpdz_): Likewise.
(xscvdqp_): Likewise.
(ieee128_mfvsrd_64bit): Likewise.
(ieee128_mfvsrd_32bit): Likewise.
(ieee128_mfvsrwz): Likewise.
(ieee128_mtvsrw): Likewise.
(ieee128_mtvsrd_64bit): Likewise.
(ieee128_mtvsrd_32bit): Likewise.



Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000-protos.h
trunk/gcc/config/rs6000/rs6000.c
trunk/gcc/config/rs6000/rs6000.md