[Bug fortran/60913] [OOP] Memory leak with allocatable polymorphic function result (in type-bound operator)

[ian_harvey at bigpond dot com]

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

Ian Harvey  changed:

   What|Removed |Added

 CC||ian_harvey at bigpond dot com

--- Comment #10 from Ian Harvey  ---
The issue appears to be that code generated by the compiler does not deallocate
the polymorphic allocatable function result when the innermost executable
construct containing the function reference terminates (F2008 6.7.3.2p5).  This
only appears to be the case for when the function result is polymorphic.

Clarifying questions here and elsewhere - this is something that only the
compiler can arrange (it must be "automatic"), as the allocatable
characteristic of the function result is only accessible to the compiler in the
calling scope.  The user does not need to arrange anything - there is nothing
they can arrange.  The presence or absence of a finalizer is not relevant - a
finalizer cannot explicitly deallocate the object that it is finalizing, it can
only explicitly deallocate allocatable sub-objects of the object being
finalized.  The type declaration statements mentioned in #8 are not
particularly relevant, the issue is with the handling of function references.

This may be a simpler example:

MODULE m
  IMPLICIT NONE

  TYPE :: t
INTEGER :: comp
  END TYPE t
CONTAINS
  FUNCTION f(i)
INTEGER, INTENT(IN) :: i
CLASS(t), ALLOCATABLE :: f
ALLOCATE(f)
f%comp = i
  END FUNCTION f

  SUBROUTINE proc(arg)
CLASS(t), INTENT(IN) :: arg
PRINT *, arg%comp
  END SUBROUTINE proc
END MODULE m

PROGRAM p
  USE m
  IMPLICIT NONE
  INTEGER :: i
  DO i = 1, 100
CALL proc(f(i))
! The function result should be deallocated after 
! execution of the above statement completes.
  END DO
END PROGRAM p

~~~

$ gfortran -g -v 2017-01-28\ alloc2.f90 && valgrind --leak-check=full ./a.out
Driving: gfortran -g -v 2017-01-28 alloc2.f90 -l gfortran -l m -shared-libgcc
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/home/MEGMS2/ian/usr/gcc-7.0.1/libexec/gcc/x86_64-pc-linux-gnu/7.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: .././src/configure --prefix=/home/MEGMS2/ian/usr/gcc-7.0.1
--enable-languages=c,c++,fortran,lto --enable-libgomp --enable-checking=release
Thread model: posix
gcc version 7.0.1 20170120 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-g' '-v' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
 /home/MEGMS2/ian/usr/gcc-7.0.1/libexec/gcc/x86_64-pc-linux-gnu/7.0.1/f951
2017-01-28 alloc2.f90 -quiet -dumpbase 2017-01-28 alloc2.f90 -mtune=generic
-march=x86-64 -auxbase 2017-01-28 alloc2 -g -version -fintrinsic-modules-path
/home/MEGMS2/ian/usr/gcc-7.0.1/lib/gcc/x86_64-pc-linux-gnu/7.0.1/finclude -o
/tmp/ccRZA3YY.s
GNU Fortran (GCC) version 7.0.1 20170120 (experimental) (x86_64-pc-linux-gnu)
compiled by GNU C version 7.0.1 20170120 (experimental), GMP version
6.1.1, MPFR version 3.1.5, MPC version 1.0.2, isl version 0.15
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU Fortran2008 (GCC) version 7.0.1 20170120 (experimental)
(x86_64-pc-linux-gnu)
compiled by GNU C version 7.0.1 20170120 (experimental), GMP version
6.1.1, MPFR version 3.1.5, MPC version 1.0.2, isl version 0.15
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
COLLECT_GCC_OPTIONS='-g' '-v' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
 as -v --64 -o /tmp/ccXmIutE.o /tmp/ccRZA3YY.s
GNU assembler version 2.26.1 (x86_64-redhat-linux) using BFD version version
2.26.1-1.fc25
Reading specs from
/home/MEGMS2/ian/usr/gcc-7.0.1/lib/gcc/x86_64-pc-linux-gnu/7.0.1/../../../../lib64/libgfortran.spec
rename spec lib to liborig
COLLECT_GCC_OPTIONS='-g' '-v' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
COMPILER_PATH=/home/MEGMS2/ian/usr/gcc-7.0.1/libexec/gcc/x86_64-pc-linux-gnu/7.0.1/:/home/MEGMS2/ian/usr/gcc-7.0.1/libexec/gcc/x86_64-pc-linux-gnu/7.0.1/:/home/MEGMS2/ian/usr/gcc-7.0.1/libexec/gcc/x86_64-pc-linux-gnu/:/home/MEGMS2/ian/usr/gcc-7.0.1/lib/gcc/x86_64-pc-linux-gnu/7.0.1/:/home/MEGMS2/ian/usr/gcc-7.0.1/lib/gcc/x86_64-pc-linux-gnu/
LIBRARY_PATH=/home/MEGMS2/ian/usr/gcc-7.0.1/lib/gcc/x86_64-pc-linux-gnu/7.0.1/:/home/MEGMS2/ian/usr/gcc-7.0.1/lib/gcc/x86_64-pc-linux-gnu/7.0.1/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/home/MEGMS2/ian/usr/gcc-7.0.1/lib/gcc/x86_64-pc-linux-gnu/7.0.1/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-g' '-v' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
 /home/MEGMS2/ian/usr/gcc-7.0.1/libexec/gcc/x86_64-pc-linux-gnu/7.0.1/collect2
-plugin
/home/MEGMS2/ian/usr/gcc-7.0.1/libexec/gcc/x86_64-pc-linux-gnu/7.0.1/liblto_plugin.so
-plugin-opt=/home/MEGMS2/ian/usr/gcc-7.0.1/libexec/gcc/x86_64-pc-linux-gnu/7.0.1/lto-wrapper
-plugin-opt=-fresolution=/tmp/ccMep7Yj.res -plugin-opt=-pass-through=-lgcc_s
-plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lquadmath

[Bug middle-end/79257] spurious -Wformat-overflow=1 warning with -O2 and sanitizer

[msebor at gcc dot gnu.org]

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

--- Comment #2 from Martin Sebor  ---
The null pointer instrumentation added by the sanitizer causes GCC trouble. 
We've seen it with the original implementation of the -Wnonnull warning, it
still causes null warnings out of builtin-ssa-sprintf.c in bootstrap-ubsan, and
it looks like it's also (indirectly) behind this warning.  In this case I see
no reason why the sanitizer adds the null pointer check for buffer when there's
no way for it to be null.  There should be a way to avoid it in the basic case,
though I suspect the problem might be more general in nature (and why Richard
argues for merging some of these passes with VRP).

   [0.00%]:
  if ( == 0B)
goto ; [0.04%]
  else
goto ; [99.96%]

   [0.00%]:
  __builtin___ubsan_handle_nonnull_arg (&*.Lubsan_data0);

I think the sprintf-return-value pass is before vrp2 because it sets range info
that vrp2 then makes use of.  The test below (extracted from the test suite)
fails when the pass is moved after vrp2.

void f (const char *s)
{
  int n = __builtin_snprintf (0, 0, "%.*s%08x", 1, s, 1);
  if (7 < n && n < 10) return;
  __builtin_abort ();
}

[Bug ada/25844] [5/6/7 regression] ICE on overloaded renames

[simon at pushface dot org]

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

simon at pushface dot org changed:

   What|Removed |Added

 CC||simon at pushface dot org

--- Comment #19 from simon at pushface dot org ---
The reduced testcase compiles OK (with a slight modification, to fix missing
body for X.G.F) with gcc version 7.0.0 20170110 (experimental) (GCC).

GCC 6.1.0 fails to compile, but without a bugbox.

I can’t decode the first attachment; gunzip does *not* produce any sort of
text!

[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 #1 from Michael Meissner  ---
Created attachment 40611
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40611=edit
Proposed patch to fix the problem.

This patch is believed to fix the following PRs
  * target/79038 (__float128/integer conversions)
  * target/79202 (consider using vupkhsw/xxpermdi to sign extend an int)
  * target/79203 (rework fp conversions to know about -mvsx-small-integer)

[Bug target/79203] Update PowerPC double->int conversions to know about -mvsx-small-integer

[meissner at gcc dot gnu.org]

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

--- Comment #1 from Michael Meissner  ---
Created attachment 40610
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40610=edit
Proposed patch to fix the problem.

This patch is believed to fix the following PRs
  * target/79038 (__float128/integer conversions)
  * target/79202 (consider using vupkhsw/xxpermdi to sign extend an int)
  * target/79203 (rework fp conversions to know about -mvsx-small-integer)

[Bug target/79202] On Power8, consider using vupkhsw/xxpermdi to sign extend an int in a vector register instead of mfvsrwz/mtvsrwa

[meissner at gcc dot gnu.org]

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

--- Comment #4 from Michael Meissner  ---
Created attachment 40609
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40609=edit
Proposed patch to fix the problem.

This patch is believed to fix the following PRs
  * target/79038 (__float128/integer conversions)
  * target/79202 (consider using vupkhsw/xxpermdi to sign extend an int)
  * target/79203 (rework fp conversions to know about -mvsx-small-integer)

[Bug testsuite/63256] [5/6/7 regression] FAIL: gcc.dg/sms-8.c scan-rtl-dump-times sms "SMS succeeded" 0

[acsawdey at gcc dot gnu.org]

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

--- Comment #11 from acsawdey at gcc dot gnu.org ---
Here is my patch to clean this one up:

https://gcc.gnu.org/ml/gcc-patches/2017-01/msg01524.html

Basically this reverses the patches to sms-8 that were posted for 47013 here:

https://gcc.gnu.org/ml/gcc-patches/2011-05/msg01175.html

[Bug target/77333] Incorrect stack adjust in epilogue when targeting i686-w64-mingw32

[tony at kelman dot net]

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

--- Comment #15 from Tony Kelman  ---
Created attachment 40608
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40608=edit
smaller copy of SLPVectorizer.cpp that reproduces issue

[Bug target/77333] Incorrect stack adjust in epilogue when targeting i686-w64-mingw32

[tony at kelman dot net]

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

--- Comment #14 from Tony Kelman  ---
I'll look into whether the same flag changes the behavior in the same way on
gcc 5.

Using the opensuse repo's current cross compiler version, I reduced
SLPVectorizer.cpp down to the attached version. It's maybe so small that
there's UB making it useless to look at, but replacing SLPVectorizer.cpp with
this copy reproduces the known-good behavior with -fno-ipa-cp and the segfault
without.

[Bug target/79261] New: vec_xxpermdi appears to have endian issues

[wschmidt at gcc dot gnu.org]

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

Bug ID: 79261
   Summary: vec_xxpermdi appears to have endian issues
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wschmidt at gcc dot gnu.org
  Target Milestone: ---

Use of the vec_xxpermdi built-in appears to work incorrectly on little endian;
it seems to be using big-endian semantics.  This may be working as designed
(direct access to the instruction), but if so it is a confusing implementation.
 Note that this is not an official API function as defined in the ELFv2 ABI
appendices, so the semantics are not well-defined.

This should either be fixed to use little-endian semantics, or documented
carefully in the GCC user manual.  Since it has not been previously
well-documented, we probably have the flexibility to change the implementation.

[Bug c++/79232] [7 Regression] error: invalid rhs for gimple memory store

[jakub at gcc dot gnu.org]

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

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

This patch (totally untested) implements it and fixes the ICE with both the
original reduced testcase and the one with the visible side-effects.  If that
is the way to go, I'll need to add more testcases.

[Bug fortran/79230] [7 Regression] Run time error: malloc on valid code

[juergen.reuter at desy dot de]

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

--- Comment #6 from Jürgen Reuter  ---
Created attachment 40606
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40606=edit
Reduced test case

[Bug fortran/79230] [7 Regression] Run time error: malloc on valid code

[juergen.reuter at desy dot de]

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

--- Comment #5 from Jürgen Reuter  ---
Here is the promised reduced test case, 80 lines, and I do believe that this is
most likely causing the issues of all our 250 failing tests (hopefully).
Attached and plain:

module module1
  implicit none
  private

  public :: data_t
  public :: t1_t
  public :: t2_t

  type :: string_t
 private
 character(LEN=1), dimension(:), allocatable :: chars
  end type string_t

  type, abstract :: data_t
 type(string_t) :: name
  end type data_t

  type, extends (data_t) :: real_t
 real :: value
  end type real_t

  type :: t1_t
 character, dimension(:), allocatable :: name
 real, pointer :: width_val => null ()
 class(data_t), pointer :: width_data => null ()
   contains
 procedure :: set => t1_set
  end type t1_t

  type :: t2_t
 type(real_t), dimension(:), pointer :: par_real => null ()
 type(t1_t), dimension(:), allocatable :: field
   contains
 procedure :: get_par_real_ptr => t2_get_par_real_ptr_index
  end type t2_t


contains

  subroutine t1_set (prt, width_data)
class(t1_t), intent(inout) :: prt
class(data_t), intent(in), pointer :: width_data
real, pointer :: ptr
prt%width_data => width_data
if (associated (width_data)) then
   select type (width_data)
   type is (real_t)
  prt%width_val => width_data%value
   class default
  prt%width_val => null ()
   end select
end if
  end subroutine t1_set

  function t2_get_par_real_ptr_index (model, i) result (ptr)
class(t2_t), intent(inout) :: model
integer, intent(in) :: i
class(data_t), pointer :: ptr
ptr => model%par_real(i)
  end function t2_get_par_real_ptr_index

end module module1

!

program main_ut
  use module1
  implicit none
  call evaluator_1 ()  
contains
  subroutine evaluator_1 ()
type(t2_t), target :: model
type(t1_t), pointer :: field
allocate (model%par_real (1))
allocate (model%field (1))
field => model%field(1)
call field%set (width_data=model%get_par_real_ptr (7))
deallocate (model%par_real)
  end subroutine evaluator_1
end program main_ut

[Bug c++/79232] [7 Regression] error: invalid rhs for gimple memory store

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Though the #c1 testcase actually tests something even different (the #c5
questions apply otherwise), because there is the [d], therefore it really
should be evaluated in the order: side-effects in e, side-effects in 0,
side-effects in b, side-effects in  or in a, then side-effects in d and then
actually the value storing.

Looking at
char fn1 ();
int fn2 ();
int fn3 ();
char  ();
char  ();
int fn6 ();
void fna() { (fn3 () ? fn4 () : fn5 ()) = fn1 (); }
void fnb() { (fn2 (), fn3 () ? fn4 () : fn5 ()) = fn1 (); }
where the side-effects are more observable (and it still ICEs on fnb), it seems
COND_EXPR is actually handled properly:
  TARGET_EXPR ;, if (fn3 () != 0)
{
  (void) (*fn4 () = D.2051);
}
  else
{
  (void) (*fn5 () = D.2051);
}

So, perhaps at least for the case where after
  tree lhs1 = lhs;
  while (TREE_CODE (lhs1) == COMPOUND_EXPR)
lhs1 = TREE_OPERAND (lhs1, 1);
  if (TREE_CODE (lhs1) == COND_EXPR)
we need to handle it like the normal COND_EXPR in there, except that instead of
lhs it would use this lhs1, and instead of TREE_OPERAND (lhs1, 0) it would
replace the COND_EXPR at the end of the COMPOUND_EXPR with just its condition
(likely would have to unshare the COMPOUND_EXPRs or recreate them).
Now the question is if COMPOUND_EXPR(s) with PRE{DEC,INC}REMENT_EXPR,
MODIFY_EXPR, {MIN,MAX}_EXPR shouldn't be treated similarly.

[Bug fortran/79229] [7 Regression] ICE in gfc_trans_assignment_1 with -fcheck=mem

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 CC||janus at gcc dot gnu.org

--- Comment #3 from janus at gcc dot gnu.org ---
Further reduced test case:


implicit none

type :: t
  integer, pointer :: data => null ()
end type

class(t), dimension(:), allocatable :: sf
allocate (t :: sf (1))

end

[Bug plugins/79260] New: missing header files for plugins: arm-isa.h, arm-flags.h

[arnd at linaro dot org]

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

Bug ID: 79260
   Summary: missing header files for plugins: arm-isa.h,
arm-flags.h
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: plugins
  Assignee: unassigned at gcc dot gnu.org
  Reporter: arnd at linaro dot org
  Target Milestone: ---

Building the Linux kernel with gcc-plugins enabled currently fails for ARM:

In file included from
/home/arnd/cross-gcc/lib/gcc/arm-linux-gnueabi/7.0.1/plugin/include/options.h:8:0,
 from
/home/arnd/cross-gcc/lib/gcc/arm-linux-gnueabi/7.0.1/plugin/include/tm.h:23,
 from
/home/arnd/cross-gcc/lib/gcc/arm-linux-gnueabi/7.0.1/plugin/include/backend.h:28,
 from
/home/arnd/cross-gcc/lib/gcc/arm-linux-gnueabi/7.0.1/plugin/include/gcc-plugin.h:30,
 from /git/arm-soc/scripts/gcc-plugins/gcc-common.h:6,
 from :1:
/home/arnd/cross-gcc/lib/gcc/arm-linux-gnueabi/7.0.1/plugin/include/config/arm/arm-opts.h:28:23:
fatal error: arm-flags.h: No such file or directory
compilation terminated.
Cannot use CONFIG_GCC_PLUGINS: your gcc installation does not support plugins,
perhaps the necessary headers are missing?

Manually copying arm-isa.h and arm-flags.h into the installation directory
solved the problem for me.

[Bug target/78516] [7 Regression] ICE in lra_assign for e500v2

[bergner at gcc dot gnu.org]

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

--- Comment #28 from Peter Bergner  ---
I totally agree, especially since the work in progress patch we did have to fix
the glibc build had so much fallout.

[Bug c++/79232] [7 Regression] error: invalid rhs for gimple memory store

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
On the C++, the question really is what C++17 wants with comma expression on
the lhs used as lvalue and what should be done for C++14 and earlier. 
Shouldn't COMPOUND_EXPR be handled like before for
-fstrong-eval-order={none,some}?
For
(a ? b : c) = d;
and -fstrong-eval-order=all, if all of a, b, c, d have side-effects, in what
order they should be evaluated?  Right now g++ will turn that into
a ? (b = d) : (c = d); and thus evaluate a's side-effects first, then d's and
then either b's or c's.  Shouldn't it be evaluated by taking address of b and d
and evaluating a only after d's side-effects?  And then similar question about
COMPOUND_EXPR:
(e, (a ? b : c)) = d;
Or can it be (e, a) ? (b = d) : (c = d); ?
Jason?

[Bug target/78516] [7 Regression] ICE in lra_assign for e500v2

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #27 from Jeffrey A. Law  ---
Joseph's last comment indicates glibc is building, which means the issue in c#6
is no longer a problem.

I think if we find further problems we ought to open a new BZ.

[Bug rtl-optimization/71374] [5/6/7 Regression] ICE on valid code at -O1 and above on x86_64-linux-gnu: in extract_constrain_insn, at recog.c:2190

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #7 from Jeffrey A. Law  ---
Confirmed that Vlad's patch fixes the failure.

[Bug target/71910] ICE on valid OpenMP code

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug rtl-optimization/79194] [7 Regression] ICE in rtl_verify_bb_insns, at cfgrtl.c:2661 (error: flow control insn inside a basic block)

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #4 from Jeffrey A. Law  ---
Fixed on the trunk.  Hopefully the last of these for cprop...

[Bug rtl-optimization/79194] [7 Regression] ICE in rtl_verify_bb_insns, at cfgrtl.c:2661 (error: flow control insn inside a basic block)

[law at gcc dot gnu.org]

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

--- Comment #3 from Jeffrey A. Law  ---
Author: law
Date: Fri Jan 27 19:40:44 2017
New Revision: 244993

URL: https://gcc.gnu.org/viewcvs?rev=244993=gcc=rev
Log:
2017-01-27  Bernd Schmidt  

PR rtl-optimization/79194
* cprop.c (one_cprop_pass): Move deletion of code after unconditional
traps before call to bypass_conditional_jumps.

PR rtl-optimization/79194
* gcc.dg/torture/pr79194.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr79194.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cprop.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/71014] associate statement inside omp parallel do appears to disable default private attribute for inner loop indices

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

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

[Bug fortran/72744] ICE in verify_ssa, at tree-ssa.c:1039

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug fortran/69281] gfortran ICE on temporary array in function call with -fstack-arrays -fopenmp

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug fortran/67496] trans-array.c sanitizer runtime error: load of value 124, which is not a valid value for type 'bool'

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug libstdc++/70530] [DR2468] You should probably add addressof (a) != addressof (b) check to std::swap

[safinaskar at mail dot ru]

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

Askar Safin  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |INVALID

--- Comment #8 from Askar Safin  ---
Okey, I understand

[Bug middle-end/79257] spurious -Wformat-overflow=1 warning with -O2 and sanitizer

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||msebor at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
I think the reason is that the printf-return-length2 pass is scheduled very
long after vrp1 and shortly before vrp2, optimizations in between those usually
(ok, ccp is exception if it figured out something from non-zero bits) just
preserve or invalidate the range info, but don't really create it.  Here in
particular ivopts pass creates new IVs which don't really have range info then.
What is the reason for not putting the printf-return-length2 pass right after
vrp2 or shortly after it, instead of shortly before it?
Otherwise, we'd need to have some lightweight VRP pass (without assertion
expression handling, without looping or only with limited looping, without
other expensive stuff) scheduled in more places.

[Bug target/79131] [7 Regression] ICE: in extract_constrain_insn, at recog.c:2213, big-endian ARM

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #10 from Jeffrey A. Law  ---
Per c#8 and c#9.

[Bug target/79131] [7 Regression] ICE: in extract_constrain_insn, at recog.c:2213, big-endian ARM

[arnd at linaro dot org]

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

--- Comment #9 from Arnd Bergmann  ---
I successfully rebuilt all the (now seven) previously failing kernel
configurations, no more ICE.

Thanks a lot!

[Bug c++/79258] -Wduplicated-branches false positive?

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
The problem is that even before any kind of folding calls to static member
functions have the object on which it is called removed.  So, if we'd want to
consider those still be different by -Wduplicated-branches, we'd need to
preserve that object somewhere (say in some IFN/stmt kind that would consume
the object address, perhaps added only if -Wduplicated-branches is used, and
then make sure to throw it away during gimplification).

[Bug target/77333] Incorrect stack adjust in epilogue when targeting i686-w64-mingw32

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

 Target||i686-w64-mingw32
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-01-27
   Host||x86_64-linux
 Ever confirmed|0   |1

--- Comment #13 from Martin Jambor  ---
So although I have not gone as far building my own cross-compiler and
just used the gcc 6 based one from OpenSUSE, I managed to reproduce
the issue myself and can confirm that just marking method
SLPVectorizer::tryToVectorizeList with noclone attribute avoids the
issue.

But, from the logs I gather that the only reason why IPA-CP did that
was to remove the unused this pointer.  This makes me wonder whether
this somehow could push its callers and the callee out of sync
regarding what ABI they use for the call?

Apart from that, I have no idea what else could be wrong.  I have
quickly skimmed through the diff of the gimple dumps of the function
before and after cloning and did not see any meaningful difference
(lot's of UIDs were different so something might have escaped me but
since this confirmed my observations from the IPA-CP dump, I doubt
it).

One more thing, IPA-CP does this (clone to remove a parameter when
there are no real constants coming from all callers) only since
r231540 (i.e. gcc 6), so you should not really see the issue with gcc
5, at least not because of this.

[Bug rtl-optimization/71374] [5/6/7 Regression] ICE on valid code at -O1 and above on x86_64-linux-gnu: in extract_constrain_insn, at recog.c:2190

[vmakarov at gcc dot gnu.org]

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

--- Comment #6 from Vladimir Makarov  ---
Author: vmakarov
Date: Fri Jan 27 18:08:14 2017
New Revision: 244991

URL: https://gcc.gnu.org/viewcvs?rev=244991=gcc=rev
Log:
2017-01-27  Vladimir Makarov  

PR tree-optimization/71374
* lra-constraints.c (check_conflict_input_operands): New.
(match_reload): Use it.

2017-01-27  Vladimir Makarov  

PR tree-optimization/71374
* testsuite/gcc.target/i386/pr71374.c: New.


Added:
trunk/gcc/testsuite/gcc.target/i386/pr71374.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/lra-constraints.c
trunk/gcc/testsuite/ChangeLog

[Bug libstdc++/70530] [DR2468] You should probably add addressof (a) != addressof (b) check to std::swap

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely  ---
If you think there's still a problem please show a concrete example where our
current implementation of std::swap causes a problem.

[Bug libstdc++/70530] [DR2468] You should probably add addressof (a) != addressof (b) check to std::swap

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
(In reply to Askar Safin from comment #5)
> 4. But (as it seems for me) the standard nowhere says that std::swap (a, a)
> is unspecified. So, it should be specified

It's specified to do:

  T tmp = std::move(a);
  a = std::move(a);
  a = std::move(tmp);

Before DR2468 this whole thing had undefined behaviour, due to the "a =
std::move(a)" statement. Now that statement leaves 'a' in an unspecified state,
but then the next statement puts it back into a specified state. So there's no
undefined behaviour.

In your original comment you said "But there are other variants, of course. For
example, remove rvalue ref uniqueness assumption from the standard." And that's
what happened.

I still don't see any change needed to std::swap.

[Bug gcov-profile/79259] [7 Regression] Corrupted profile when one uses -O1

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2017-1-27
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
   Target Milestone|--- |7.0
  Known to fail||7.0

[Bug gcov-profile/79259] New: [7 Regression] Corrupted profile when one uses -O1

[marxin at gcc dot gnu.org]

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

Bug ID: 79259
   Summary: [7 Regression] Corrupted profile when one uses -O1
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
  Target Milestone: ---

Following test-case can't properly use PGO:

gcc auto-profile.ii -fprofile-generate -O1 && ./a.out  && gcc auto-profile.ii
-fprofile-use  -O1

auto-profile.ii:17:1: error: the control flow of function ‘_Z3fn2v’ does not
match its profile data (counter ‘arcs’) [-Werror=coverage-mismatch]
 }
 ^
auto-profile.ii:17:1: error: the control flow of function ‘_Z3fn2v’ does not
match its profile data (counter ‘time_profiler’) [-Werror=coverage-mismatch]
cc1plus: some warnings being treated as errors

Started with r239769. Problem is that flag_ipa_bit_cp is enabled with
-fprofile-use. That triggers ccp1 to find nonzero bits as it's guarded with:

  if (ccp_finalize (nonzero_p || flag_ipa_bit_cp))
{
  todo = (TODO_cleanup_cfg | TODO_update_ssa);

  /* ccp_finalize does not preserve loop-closed ssa.  */
  loops_state_clear (LOOP_CLOSED_SSA);
}

I've got patch for that.

[Bug tree-optimization/79245] [7 Regression] Inefficient loop distribution to memcpy

[jgreenhalgh at gcc dot gnu.org]

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

--- Comment #9 from James Greenhalgh  ---
> I'm curious how that benchmarks for you (with -ftree-loop-distribution vs.
> without).

Taking trunk as 100%, I see a 2% gain on trunk with
-fno-tree-loop-distribution-patterns , and 1% gain with your patch applied.

I'm not sure where the other 1% is going. There are a few more examples of new
memcpy calls in MAIN_ and inital_ , but they don't look hot so it may just be a
second-order effect.

Thanks for the fix.

[Bug libstdc++/70530] [DR2468] You should probably add addressof (a) != addressof (b) check to std::swap

[safinaskar at mail dot ru]

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

Askar Safin  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |---

--- Comment #5 from Askar Safin  ---
I will try to repeat.

1. DR 2468 says that after "a = std::move (a)" state of a is unspecified
2. libstdc++'s current std::swap is just 3 moves without any checks
3. From 1 and 2 current libstdc++'s std::swap (a, a) leave a in unspecified
state
4. But (as it seems for me) the standard nowhere says that std::swap (a, a) is
unspecified. So, it should be specified
5. Moreover, you just said "self-swap is not undefined", i. e. "self-swap is
defined" (I assume there is no typo here). This acknowledges 4.

So, we see clear contradiction between 3 and 4. So, something should be fixed.
Either libstdc++, either c++ standard. One solution is to fix libstdc++'s
std::swap. Other is to write to standard that std::swap (a, a) is unspecified.
There may be other solutions.

I reopen this bug

[Bug target/79131] [7 Regression] ICE: in extract_constrain_insn, at recog.c:2213, big-endian ARM

[vmakarov at gcc dot gnu.org]

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

--- Comment #8 from Vladimir Makarov  ---
I provided the final patch solving all the test cases for the PR.  We should
wait for an ACK from Arnd or Dominik to close it.

[Bug c++/71290] [6 Regression] Flexible array member is not diagnosed with -pedantic

[msebor at gcc dot gnu.org]

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

--- Comment #9 from Martin Sebor  ---
Author: msebor
Date: Fri Jan 27 16:51:54 2017
New Revision: 244990

URL: https://gcc.gnu.org/viewcvs?rev=244990=gcc=rev
Log:
PR c++/71290

gcc/testsuite/ChangeLog:
* obj-c++.dg/property/at-property-23.mm: Remove an escaped newline from
a dg-error directive.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/obj-c++.dg/property/at-property-23.mm

[Bug target/79131] [7 Regression] ICE: in extract_constrain_insn, at recog.c:2213, big-endian ARM

[vmakarov at gcc dot gnu.org]

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

--- Comment #7 from Vladimir Makarov  ---
Author: vmakarov
Date: Fri Jan 27 16:50:11 2017
New Revision: 244989

URL: https://gcc.gnu.org/viewcvs?rev=244989=gcc=rev
Log:
2017-01-27  Vladimir Makarov  

PR target/79131
* lra-assigns.c (find_hard_regno_for_1): Take endianess for into
account to calculate conflict_set.

2017-01-27  Vladimir Makarov  

PR target/79131
* gcc.target/arm/pr79131.c: Rename to gcc.target/arm/pr79131-1.c.
* gcc.target/arm/pr79131-2.c: New.


Added:
trunk/gcc/testsuite/gcc.target/arm/pr79131-1.c
  - copied unchanged from r244942,
trunk/gcc/testsuite/gcc.target/arm/pr79131.c
trunk/gcc/testsuite/gcc.target/arm/pr79131-2.c
Removed:
trunk/gcc/testsuite/gcc.target/arm/pr79131.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/lra-assigns.c
trunk/gcc/testsuite/ChangeLog

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

[jason at gcc dot gnu.org]

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

--- Comment #3 from Jason Merrill  ---
Author: jason
Date: Fri Jan 27 16:48:34 2017
New Revision: 244988

URL: https://gcc.gnu.org/viewcvs?rev=244988=gcc=rev
Log:
PR c++/78771 - ICE with inherited constructor.

* call.c (build_over_call): Call deduce_inheriting_ctor here.
* pt.c (tsubst_decl): Not here.
* class.c (add_method): Or here.
* method.c (deduce_inheriting_ctor): Handle clones.
(implicitly_declare_fn): Don't deduce inheriting ctors yet.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/pr78771-new.C
trunk/gcc/testsuite/g++.dg/cpp0x/pr78771-old.C
trunk/gcc/testsuite/g++.dg/cpp1z/pr78771.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c
trunk/gcc/cp/class.c
trunk/gcc/cp/method.c
trunk/gcc/cp/pt.c

[Bug rtl-optimization/78559] [7 Regression] wrong code due to tree if-conversion?

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #14 from Jeffrey A. Law  ---
Fixed by Bin's patch on the trunk.

[Bug c++/79258] -Wduplicated-branches false positive?

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
I'm not sure.  By the time we get into the warning we have
return  = Base::state ()
in both of the branches and that is deemed equal.

We probably shouldn't warn, but I don't know yet how to prevent it.

[Bug libstdc++/79254] [5/6/7 Regression] basic_string::operator= isn't exception safe

[redi at gcc dot gnu.org]

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

--- Comment #10 from Jonathan Wakely  ---
Fixed on trunk so far.

[Bug libstdc++/79254] [5/6/7 Regression] basic_string::operator= isn't exception safe

[redi at gcc dot gnu.org]

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

--- Comment #9 from Jonathan Wakely  ---
Author: redi
Date: Fri Jan 27 16:17:04 2017
New Revision: 244986

URL: https://gcc.gnu.org/viewcvs?rev=244986=gcc=rev
Log:
PR libstdc++/79254 fix exception-safety in std::string::operator=

PR libstdc++/79254
* config/abi/pre/gnu.ver: Add new symbols.
* include/bits/basic_string.h [_GLIBCXX_USE_CXX11_ABI]
(basic_string::_M_copy_assign): New overloaded functions to perform
copy assignment.
(basic_string::operator=(const basic_string&)): Dispatch to
_M_copy_assign.
* include/bits/basic_string.tcc [_GLIBCXX_USE_CXX11_ABI]
(basic_string::_M_copy_assign(const basic_string&, true_type)):
Define, performing rollback on exception.
* testsuite/21_strings/basic_string/allocator/char/copy_assign.cc:
Test exception-safety guarantee.
* testsuite/21_strings/basic_string/allocator/wchar_t/copy_assign.cc:
Likewise.
* testsuite/util/testsuite_allocator.h (uneq_allocator::swap): Make
std::swap visible.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/config/abi/pre/gnu.ver
trunk/libstdc++-v3/include/bits/basic_string.h
trunk/libstdc++-v3/include/bits/basic_string.tcc
   
trunk/libstdc++-v3/testsuite/21_strings/basic_string/allocator/char/copy_assign.cc
   
trunk/libstdc++-v3/testsuite/21_strings/basic_string/allocator/wchar_t/copy_assign.cc
trunk/libstdc++-v3/testsuite/util/testsuite_allocator.h

[Bug testsuite/65484] FAIL: g++.dg/vect/pr36648.cc on powerpc64

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

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

--- Comment #3 from Bill Schmidt  ---
Fixed on trunk so far.  Will backport to 5 and 6 if approved after a week or
so.

[Bug testsuite/65484] FAIL: g++.dg/vect/pr36648.cc on powerpc64

[wschmidt at gcc dot gnu.org]

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

--- Comment #2 from Bill Schmidt  ---
Author: wschmidt
Date: Fri Jan 27 15:59:02 2017
New Revision: 244985

URL: https://gcc.gnu.org/viewcvs?rev=244985=gcc=rev
Log:
2017-01-27  Bill Schmidt  

PR target/65484
* g++.dg/vect/pr36648.cc: Modify to reflect that the loop is not
vectorized on POWER unless hardware misaligned loads are
available.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/vect/pr36648.cc

[Bug c++/79258] New: -Wduplicated-branches false positive?

[sirl at gcc dot gnu.org]

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

Bug ID: 79258
   Summary: -Wduplicated-branches false positive?
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sirl at gcc dot gnu.org
  Target Milestone: ---

This code:

class Base
{
public:
  static bool state();
};

class Derived : public Base
{
};


class MyClass
{
public:
  Derived *m_Derived;
  Base *m_Base;
  bool state();
};

bool MyClass::state() 
{
  if (m_Derived != (void *) 0)
return m_Derived->state();
  else 
return m_Base->state();
}


results in this warning:
# g++-trunk -c -Wduplicated-branches -O2 test.c
test.c: In member function 'bool MyClass::state()':
test.c:22:2: warning: this condition has identical branches
[-Wduplicated-branches]
  if (m_Derived != (void *) 0)
  ^~

Should the compiler really warn here?

[Bug middle-end/79257] New: spurious -Wformat-overflow=1 warning with -O2 and sanitizer

[vincent-gcc at vinc17 dot net]

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

Bug ID: 79257
   Summary: spurious -Wformat-overflow=1 warning with -O2 and
sanitizer
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vincent-gcc at vinc17 dot net
  Target Milestone: ---

With r244974, on the following C code:

#include 

void a (void);

int main (void)
{
  char buffer[2];
  int i;

  for (i = 0; i < 2; i++)
{
  if (i == 0)
a ();
  sprintf (buffer, "%d", i);
}
  return 0;
}

I get:

cventin:~> =gcc -O2 -Wformat-overflow=1 -fsanitize=undefined -c tst.c
tst.c: In function ‘main’:
tst.c:14:25: warning: ‘%d’ directive writing between 1 and 10 bytes into a
region of size 2 [-Wformat-overflow=]
   sprintf (buffer, "%d", i);
 ^~
tst.c:14:24: note: directive argument in the range [0, 2147483646]
   sprintf (buffer, "%d", i);
^~~~
tst.c:14:7: note: ‘sprintf’ output between 2 and 11 bytes into a destination of
size 2
   sprintf (buffer, "%d", i);
   ^
tst.c:14:25: warning: ‘%d’ directive writing between 1 and 10 bytes into a
region of size 2 [-Wformat-overflow=]
   sprintf (buffer, "%d", i);
 ^~
tst.c:14:24: note: directive argument in the range [0, 2147483646]
   sprintf (buffer, "%d", i);
^~~~
tst.c:14:7: note: ‘sprintf’ output between 2 and 11 bytes into a destination of
size 2
   sprintf (buffer, "%d", i);
   ^

If I remove any of -O2, -Wformat-overflow=1 or -fsanitize=undefined, I no
longer get a warning. Ditto if I remove the test on i or the call to a().

Note: I've found this bug when building the MPFR tests (tl2b.c).

[Bug other/79250] brig/brigfrontend/brig-to-generic.cc: two small problems

[pekka.jaaskelainen at parmance dot com]

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

Pekka Jääskeläinen  changed:

   What|Removed |Added

 CC||pekka.jaaskelainen@parmance
   ||.com

--- Comment #1 from Pekka Jääskeläinen  
---
Created attachment 40605
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40605=edit
patch for the issues

[Bug tree-optimization/79256] [7 Regression] FAIL: gcc.dg/vect/pr25413a.c execution test

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
So there's ADJUST_FIELD_ALIGN (x86_field_alignment) but the interface is not
usable from within get_object_alignment_2 at

  /* When EXP is an actual memory reference then we can use
 TYPE_ALIGN of a pointer indirection to derive alignment.
 Do so only if get_pointer_alignment_1 did not reveal absolute
 alignment knowledge and if using that alignment would
 improve the situation.  */
  if (!addr_p
  && TYPE_ALIGN (TREE_TYPE (exp)) > align)
align = TYPE_ALIGN (TREE_TYPE (exp));

of course there's min_align_of_type () that just builds a FIELD_DECL for
this purpose (ugh).  But it would mean that the above needs to use
min_align_of_type ().  Ugh.

Index: gcc/builtins.c
===
--- gcc/builtins.c  (revision 244974)
+++ gcc/builtins.c  (working copy)
@@ -334,9 +334,11 @@ get_object_alignment_2 (tree exp, unsign
 Do so only if get_pointer_alignment_1 did not reveal absolute
 alignment knowledge and if using that alignment would
 improve the situation.  */
+  unsigned int talign;
   if (!addr_p && !known_alignment
- && TYPE_ALIGN (TREE_TYPE (exp)) > align)
-   align = TYPE_ALIGN (TREE_TYPE (exp));
+ && (talign = min_align_of_type (TREE_TYPE (exp)) * BITS_PER_UNIT)
+ && talign > align)
+   align = talign;
   else
{
  /* Else adjust bitpos accordingly.  */

[Bug rtl-optimization/78559] [7 Regression] wrong code due to tree if-conversion?

[amker at gcc dot gnu.org]

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

--- Comment #13 from amker at gcc dot gnu.org ---
Author: amker
Date: Fri Jan 27 14:42:23 2017
New Revision: 244979

URL: https://gcc.gnu.org/viewcvs?rev=244979=gcc=rev
Log:
PR rtl-optimization/78559
* combine.c (try_combine): Discard REG_EQUAL and REG_EQUIV for
other_insn in combine.

gcc/testsuite
PR rtl-optimization/78559
* gcc.c-torture/execute/pr78559.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/execute/pr78559.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/combine.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/71433] [7 Regression] -Warray-bounds false positive with -O2

[vincent-gcc at vinc17 dot net]

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

--- Comment #16 from Vincent Lefèvre  ---
Thanks, I confirm that for r244974, there is no longer any issue on the MPFR
code.

[Bug tree-optimization/79256] [7 Regression] FAIL: gcc.dg/vect/pr25413a.c execution test

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
(gdb) p debug_tree (exp)
 
unit size 
align 64 symtab 0 alias set -1 canonical type 0x768c2540 precision
64 context 
pointer_to_this >

so the MEM is marked aligned but somehow it is not in the end.

(gdb) p get_mode_alignment (DFmode)
$2 = 64

Hmm, so it's only 32bit aligned in structures but we use double_type_node
everywhere?  That makes all pointer accesses generate wrong MEM_REFs...

[Bug tree-optimization/79256] [7 Regression] FAIL: gcc.dg/vect/pr25413a.c execution test

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug tree-optimization/79256] [7 Regression] FAIL: gcc.dg/vect/pr25413a.c execution test

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #4 from Richard Biener  ---
Bah, not sure how that escaped my testing...

[Bug tree-optimization/79256] [7 Regression] FAIL: gcc.dg/vect/pr25413a.c execution test

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška  ---
valgrind tells:

==2361== Process terminating with default action of signal 11 (SIGSEGV)
==2361==  General Protection Fault
==2361==at 0x8048668: octfapg_universe (pr25413a.c:111)
==2361==by 0x804839F: main (pr25413a.c:122)

[Bug bootstrap/79255] [7 Regression] PGO bootstrap fails on x86_64/ppc64le building Ada

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Richard Biener  ---
One of the affected DIEs look like the following, thus the assert trips over
the DW_AT_GNU_all_call_sites attribute.

[ 8875s] DIE0: DW_TAG_subprogram (0x7f2de962e5f0)
[ 8875s]   abbrev id: 0 offset: 0 mark: 0
[ 8875s]   DW_AT_name: "uintp__ui_div_rem__B_27__ui_div_vector"
[ 8875s]   DW_AT_decl_file: "../../gcc/ada/uintp.adb" (3)
[ 8875s]   DW_AT_decl_line: 1072
[ 8875s]   DW_AT_type: die -> 0 (0x7f2de9e81960)
[ 8875s]   DW_AT_inline: 2
[ 8875s]   DW_AT_ranges: range list
[ 8875s]   DW_AT_frame_base: location descriptor:
[ 8875s] (0x7f2de8acf0a0) DW_OP_call_frame_cfa 0, 0
[ 8875s] 
[ 8875s]   DW_AT_GNU_all_call_sites: 1
[ 8875s] DIE0: DW_TAG_formal_parameter (0x7f2de96350f0)
[ 8875s]   abbrev id: 0 offset: 0 mark: 0
[ 8875s]   DW_AT_name: "l_vec"
[ 8875s]   DW_AT_decl_file: "../../gcc/ada/uintp.adb" (3)
[ 8875s]   DW_AT_decl_line: 1065
[ 8875s]   DW_AT_type: die -> 0 (0x7f2de960f960)
[ 8875s]   DW_AT_location: location list -> label:*.LLST809
[ 8875s] DIE0: DW_TAG_formal_parameter (0x7f2de9635140)
[ 8875s]   abbrev id: 0 offset: 0 mark: 0
[ 8875s]   DW_AT_name: "r_int"
[ 8875s]   DW_AT_decl_file: "../../gcc/ada/uintp.adb" (3)
[ 8875s]   DW_AT_decl_line: 1066
[ 8875s]   DW_AT_type: die -> 0 (0x7f2de9831550)
[ 8875s]   DW_AT_location: location list -> label:*.LLST810
[ 8875s] DIE0: DW_TAG_formal_parameter (0x7f2de9635190)
[ 8875s]   abbrev id: 0 offset: 0 mark: 0
[ 8875s]   DW_AT_name: "quotient"
[ 8875s]   DW_AT_decl_file: "../../gcc/ada/uintp.adb" (3)
[ 8875s]   DW_AT_decl_line: 1067
[ 8875s]   DW_AT_type: die -> 0 (0x7f2de960f960)
[ 8875s]   DW_AT_location: location list -> label:*.LLST811
[ 8875s] DIE0: DW_TAG_variable (0x7f2de96351e0)
[ 8875s]   abbrev id: 0 offset: 0 mark: 0
[ 8875s]   DW_AT_name: "remainder"
[ 8875s]   DW_AT_decl_file: "../../gcc/ada/uintp.adb" (3)
[ 8875s]   DW_AT_decl_line: 1068
[ 8875s]   DW_AT_type: die -> 0 (0x7f2de9e81960)
[ 8875s]   DW_AT_location: location list -> label:*.LLST812
[ 8875s] DIE0: DW_TAG_lexical_block (0x7f2de9635230)
[ 8875s]   abbrev id: 0 offset: 0 mark: 0
[ 8875s]   DW_AT_ranges: range list
[ 8875s] DIE0: DW_TAG_variable (0x7f2de9635280)
[ 8875s]   abbrev id: 0 offset: 0 mark: 0
[ 8875s]   DW_AT_name: "tmp_int"
[ 8875s]   DW_AT_decl_file: "../../gcc/ada/uintp.adb" (3)
[ 8875s]   DW_AT_decl_line: 1078
[ 8875s]   DW_AT_type: die -> 0 (0x7f2de9e81960)
[ 8875s]   DW_AT_location: location list -> label:*.LLST813
[ 8875s] DIE0: DW_TAG_variable (0x7f2de96352d0)
[ 8875s]   abbrev id: 0 offset: 0 mark: 0
[ 8875s]   DW_AT_name:
"uintp__ui_div_rem__B_27__ui_div_vector__L_28__T93b___L"
[ 8875s]   DW_AT_type: die -> 0 (0x7f2de9635320)
[ 8875s]   DW_AT_artificial: 1
[ 8875s]   DW_AT_location: location list -> label:*.LLST814
[ 8875s] DIE0: DW_TAG_variable (0x7f2de9635370)
[ 8875s]   abbrev id: 0 offset: 0 mark: 0
[ 8875s]   DW_AT_name:
"uintp__ui_div_rem__B_27__ui_div_vector__L_28__T93b___U"
[ 8875s]   DW_AT_type: die -> 0 (0x7f2de96353c0)
[ 8875s]   DW_AT_artificial: 1
[ 8875s]   DW_AT_location: location descriptor:
[ 8875s] (0x7f2de8b086e0) DW_OP_reg9 0, 0
[ 8875s] 
[ 8875s] DIE0: DW_TAG_lexical_block (0x7f2de9635410)
[ 8875s]   abbrev id: 0 offset: 0 mark: 0
[ 8875s]   DW_AT_ranges: range list
[ 8875s] DIE0: DW_TAG_variable (0x7f2de9635460)
[ 8875s]   abbrev id: 0 offset: 0 mark: 0
[ 8875s]   DW_AT_name: "j"
[ 8875s]   DW_AT_decl_file: "../../gcc/ada/uintp.adb" (3)
[ 8875s]   DW_AT_decl_line: 1082
[ 8875s]   DW_AT_type: die -> 0 (0x7f2de9e819b0)
[ 8875s]   DW_AT_location: location list -> label:*.LLST815

[Bug tree-optimization/79245] [7 Regression] Inefficient loop distribution to memcpy

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener  ---
Author: rguenth
Date: Fri Jan 27 13:56:59 2017
New Revision: 244976

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

PR tree-optimization/79245
* tree-loop-distribution.c (distribute_loop): Apply cost
modeling also to detected patterns.

* gcc.dg/tree-ssa/ldist-23.c: XFAIL.
* gcc.dg/tree-ssa/ldist-25.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/ldist-25.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/tree-ssa/ldist-23.c
trunk/gcc/tree-loop-distribution.c

[Bug tree-optimization/79245] [7 Regression] Inefficient loop distribution to memcpy

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/79256] [7 Regression] FAIL: gcc.dg/vect/pr25413a.c execution test

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-01-27
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Martin Liška  ---
Started with your r244897.

[Bug middle-end/79236] [7 Regression] Many libgomp tests fail if configured with --enable-offload-targets=nvptx-none but NVidia HW or libcuda.so.1 unavailable

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

 CC||tschwinge at gcc dot gnu.org

--- Comment #5 from Thomas Schwinge  ---
For the record: ever since the OpenMP nvptx offloading patches got committed
(specifically, probably after "OpenMP loop cloning for SIMT execution"), I had
seen for -m32 multilib testing of a x86_64-linux-gnu configuration the same set
of FAILs described in comment0.  Confirming that this is now also resolved in
r244924, thanks.

[Bug preprocessor/79210] "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|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-01-27
   Assignee|unassigned at gcc dot gnu.org  |dmalcolm at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #6 from David Malcolm  ---
(In reply to Arnd Bergmann from comment #5)
> Created attachment 40596 [details]
> test case with correct whitespace

Thanks.   I'm seeing the assertion failure with that source file.  Am
investigating.

[Bug c/79199] [7 Regression] ICE with -Wduplicated-branches

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Fri Jan 27 13:25:28 2017
New Revision: 244975

URL: https://gcc.gnu.org/viewcvs?rev=244975=gcc=rev
Log:
PR c/79199
* c-c++-common/Wduplicated-branches-13.c: Require int32plus effective
target.  Use 4294967293U instead of 4294967293.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/c-c++-common/Wduplicated-branches-13.c

[Bug debug/72828] ICE in clone_tree_partial when compiling with -fdebug-types-section

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #8 from Nathan Sidwell  ---
This no longer reproduces.

[Bug tree-optimization/71433] [7 Regression] -Warray-bounds false positive with -O2

[rguenth at gcc dot gnu.org]

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

--- Comment #15 from Richard Biener  ---
Author: rguenth
Date: Fri Jan 27 12:30:43 2017
New Revision: 244974

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

PR tree-optimization/71433
* tree-vrp.c (register_new_assert_for): Revert earlier changes.
(compare_assert_loc): New function.
(process_assert_insertions): Sort and optimize assert locations
to remove duplicates and push down identical assertions on
edges to their destination block.

* gcc.dg/Warray-bounds-21.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/Warray-bounds-21.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vrp.c

[Bug tree-optimization/71433] [7 Regression] -Warray-bounds false positive with -O2

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #14 from Richard Biener  ---
Fixed again.  Thanks for the new testcase.

[Bug tree-optimization/79256] [7 Regression] FAIL: gcc.dg/vect/pr25413a.c execution test

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |7.0

--- Comment #1 from Richard Biener  ---
> ./pr25413a.exe
Segmentation fault (core dumped)

   0x08048647 <+119>:   add$0x10,%ecx
=> 0x0804864a <+122>:   movaps %xmm0,-0x10(%ecx)
(gdb) p/x $ecx
$2 = 0x804b064

[Bug tree-optimization/79256] New: [7 Regression] FAIL: gcc.dg/vect/pr25413a.c execution test

[rguenth at gcc dot gnu.org]

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

Bug ID: 79256
   Summary: [7 Regression] FAIL: gcc.dg/vect/pr25413a.c execution
test
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---
Target: i?86-*-*

FAILs on x86_64 with -m32.

[Bug tree-optimization/79244] [7 Regression] ice in replace_uses_by, at tree-cfg.c:1866

[rguenth at gcc dot gnu.org]

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

--- Comment #10 from Richard Biener  ---
Author: rguenth
Date: Fri Jan 27 12:24:54 2017
New Revision: 244973

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

PR tree-optimization/79244
* tree-vrp.c (remove_range_assertions): Forcefully propagate
out SSA names even if abnormal.

* gcc.dg/torture/pr79244.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr79244.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vrp.c

[Bug tree-optimization/79244] [7 Regression] ice in replace_uses_by, at tree-cfg.c:1866

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[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|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-01-27
 CC||nathan at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |nathan at gcc dot 
gnu.org
 Ever confirmed|0   |1

[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|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |nathan at gcc dot 
gnu.org

[Bug target/79239] [7 regression] ICE in extract_insn, at recog.c:2311 (error: unrecognizable insn)

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||ramana at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #10 from Ramana Radhakrishnan  ---
I've committed the fix for Richard. If there are more issues, lets take them up
as new bug reports.

[Bug target/79239] [7 regression] ICE in extract_insn, at recog.c:2311 (error: unrecognizable insn)

[ramana at gcc dot gnu.org]

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

--- Comment #9 from Ramana Radhakrishnan  ---
Author: ramana
Date: Fri Jan 27 11:22:30 2017
New Revision: 244965

URL: https://gcc.gnu.org/viewcvs?rev=244965=gcc=rev
Log:
[ARM] Fix PR target/79239 - unrecognized insn after pragma gcc pop_options

{committed for rearnsha}

It turns out that because the compiler uses a hash table to save the
cl_target_option structures it is unsafe to modify the result of
build_target_option_node() (doing so will cause the hash lookup to
fail).  This PR was due to not properly understanding this limitation.

The fix is to create temporary copies of the cl_target_option nodes for
use during target option processing and then only creating the tree node
once the options have been suitably modified.

gcc:
PR target/79239
* arm.c (arm_option_override): Don't call build_target_option_node
until after doing all option overrides.
(arm_valid_target_attribute_tree): Likewise.

gcc/testsuite:
* gcc.target/arm/pr79239.c: New test.



Added:
trunk/gcc/testsuite/gcc.target/arm/pr79239.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm.c
trunk/gcc/testsuite/ChangeLog

[Bug target/79211] ICE in extract_insn, at recog.c:2311

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

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

[Bug tree-optimization/79245] [7 Regression] Inefficient loop distribution to memcpy

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
(In reply to rguent...@suse.de from comment #5)
> On Fri, 27 Jan 2017, jgreenhalgh at gcc dot gnu.org wrote:
> 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79245
> > 
> > --- Comment #4 from James Greenhalgh  ---
> > (In reply to Richard Biener from comment #3)
> > > Note the trivial fix will FAIL gcc.dg/tree-ssa/ldist-23.c which looks like
> > > 
> > >   int i;
> > >   for (i = 0; i < 128; ++i)
> > > {
> > >   a[i] = a[i] + 1;
> > >   b[i] = d[i];
> > >   c[i] = a[i] / d[i];
> > > }
> > > 
> > > where the testcase expects b[i] = d[i] to be split out as memcpy but
> > > the other two partitions to be fused.
> > > 
> > > Generally the cost model lacks computing the number of input/output 
> > > streams
> > > of a partition and a target interface to query it about limits.  Usually
> > > store bandwidth is not equal to load bandwidth and not re-used store 
> > > streams
> > > can benefit from non-temporal stores being used by libc.
> > > 
> > > In your testcase I wonder whether distributing to
> > > 
> > > for (int j = 0; j < x; j++)
> > >   {
> > > for (int i = 0; i < y; i++)
> > > {
> > >   c[j][i] = b[j][i] - a[j][i];
> > >   }
> > >   }
> > > memcpy (a, b, ...);
> > > 
> > > would be faster in the end (or even doing the memcpy first in this case).
> > > 
> > > Well, for now let's be more conservative given the cost model really is
> > > lacking.
> > 
> > The testcase is reduced from CALC3 in 171.swim. I've been seeing a 3%
> > regression for Cortex-A72 after r242038, and I can fix that with
> > -fno-tree-loop-distribute-patterns.
> > 
> > In that benchmark you've got 3 instances of the above pattern, so you end up
> > with 3 memcpy calls after:
> > 
> >   DO 300 J=1,N
> >   DO 300 I=1,M
> >   UOLD(I,J) = U(I,J)+ALPHA*(UNEW(I,J)-2.*U(I,J)+UOLD(I,J))
> >   VOLD(I,J) = V(I,J)+ALPHA*(VNEW(I,J)-2.*V(I,J)+VOLD(I,J))
> >   POLD(I,J) = P(I,J)+ALPHA*(PNEW(I,J)-2.*P(I,J)+POLD(I,J))
> >   U(I,J) = UNEW(I,J)
> >   V(I,J) = VNEW(I,J)
> >   P(I,J) = PNEW(I,J)
> >   300 CONTINUE
> > 
> > 3 memcpy calls compared to 3 vector store instructions doesn't seem the 
> > right
> > tradeoff to me. Sorry if I reduced the testcase too far to make the balance
> > clear.
> 
> Itanic seems to like it though:
> 
> http://gcc.opensuse.org/SPEC/CFP/sb-terbium-head-64/171_swim_big.png
> 
> For Haswell I don't see any ups/downs for AMD Fam15 I see a slowdown
> as well around that time.  I guess it depends if the CPU is already
> throttled by load/compute bandwith here.  What should be profitable
> is to distribute the above to three loops (w/o memcpy).  So after
> the patch doing -ftree-loop-distribution.  Patch being
> 
> Index: gcc/tree-loop-distribution.c
> ===
> --- gcc/tree-loop-distribution.c(revision 244963)
> +++ gcc/tree-loop-distribution.c(working copy)
> @@ -1548,8 +1548,7 @@ distribute_loop (struct loop *loop, vec<
>for (int j = i + 1;
>partitions.iterate (j, ); ++j)
> {
> - if (!partition_builtin_p (partition)
> - && similar_memory_accesses (rdg, into, partition))
> + if (similar_memory_accesses (rdg, into, partition))
> {
>   if (dump_file && (dump_flags & TDF_DETAILS))
> {

The distribution to three loops doesn't work because (fortran - eh) all
arrays are part of the same (unnamed) common block and thus the memory
accesses appear related -- in GIMPLE we see __BLNK__.uold[] and __BLNK__.unew[]
and thus they appear as part of the same structure.  The cost model
is really too simple (not considering dependence distance or considering
non-dependent accesses to be of infinite distance and thus unrelated - of
course
we compute dependence only after applying the cost model at the moment).
It works with some extra (partly redundant) dependence checking:

Index: gcc/tree-loop-distribution.c
===
--- gcc/tree-loop-distribution.c(revision 244963)
+++ gcc/tree-loop-distribution.c(working copy)
@@ -1199,8 +1199,8 @@ ref_base_address (data_reference_p dr)
accesses in RDG.  */

 static bool
-similar_memory_accesses (struct graph *rdg, partition *partition1,
-partition *partition2)
+similar_memory_accesses (struct graph *rdg, vec loops,
+partition *partition1, partition *partition2)
 {
   unsigned i, j, k, l;
   bitmap_iterator bi, bj;
@@ -1228,7 +1228,18 @@ similar_memory_accesses (struct graph *r
if (base1)
  FOR_EACH_VEC_ELT (RDG_DATAREFS (rdg, j), l, ref2)
if (base1 == ref_base_address (ref2))
- return true;
+ {
+   ddr_p ddr = 

[Bug target/79211] ICE in extract_insn, at recog.c:2311

[segher at gcc dot gnu.org]

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

--- Comment #4 from Segher Boessenkool  ---
Ah.  That  reg:SF 3  is not an fpr_reg_operand (3 is GPR 3).
Now how did that happen...

[Bug jit/64089] libgccjit.so.0.0.1 linkage failure on darwin

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

 Target|x86_64-apple-darwin14   |x86_64-apple-darwin16
 Status|UNCONFIRMED |NEW
   Keywords||build
   Last reconfirmed||2017-01-27
 CC||fxcoudert at gcc dot gnu.org
   Host|x86_64-apple-darwin14   |x86_64-apple-darwin16
 Ever confirmed|0   |1
  Build|x86_64-apple-darwin14   |x86_64-apple-darwin16

--- Comment #12 from Francois-Xavier Coudert  ---
Still present on all darwin versions, still broken on trunk, GCC 6 and GCC 5
branches.

[Bug tree-optimization/79245] [7 Regression] Inefficient loop distribution to memcpy

[rguenther at suse dot de]

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

--- Comment #5 from rguenther at suse dot de  ---
On Fri, 27 Jan 2017, jgreenhalgh at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79245
> 
> --- Comment #4 from James Greenhalgh  ---
> (In reply to Richard Biener from comment #3)
> > Note the trivial fix will FAIL gcc.dg/tree-ssa/ldist-23.c which looks like
> > 
> >   int i;
> >   for (i = 0; i < 128; ++i)
> > {
> >   a[i] = a[i] + 1;
> >   b[i] = d[i];
> >   c[i] = a[i] / d[i];
> > }
> > 
> > where the testcase expects b[i] = d[i] to be split out as memcpy but
> > the other two partitions to be fused.
> > 
> > Generally the cost model lacks computing the number of input/output streams
> > of a partition and a target interface to query it about limits.  Usually
> > store bandwidth is not equal to load bandwidth and not re-used store streams
> > can benefit from non-temporal stores being used by libc.
> > 
> > In your testcase I wonder whether distributing to
> > 
> > for (int j = 0; j < x; j++)
> >   {
> > for (int i = 0; i < y; i++)
> >   {
> > c[j][i] = b[j][i] - a[j][i];
> >   }
> >   }
> > memcpy (a, b, ...);
> > 
> > would be faster in the end (or even doing the memcpy first in this case).
> > 
> > Well, for now let's be more conservative given the cost model really is
> > lacking.
> 
> The testcase is reduced from CALC3 in 171.swim. I've been seeing a 3%
> regression for Cortex-A72 after r242038, and I can fix that with
> -fno-tree-loop-distribute-patterns.
> 
> In that benchmark you've got 3 instances of the above pattern, so you end up
> with 3 memcpy calls after:
> 
>   DO 300 J=1,N
>   DO 300 I=1,M
>   UOLD(I,J) = U(I,J)+ALPHA*(UNEW(I,J)-2.*U(I,J)+UOLD(I,J))
>   VOLD(I,J) = V(I,J)+ALPHA*(VNEW(I,J)-2.*V(I,J)+VOLD(I,J))
>   POLD(I,J) = P(I,J)+ALPHA*(PNEW(I,J)-2.*P(I,J)+POLD(I,J))
>   U(I,J) = UNEW(I,J)
>   V(I,J) = VNEW(I,J)
>   P(I,J) = PNEW(I,J)
>   300 CONTINUE
> 
> 3 memcpy calls compared to 3 vector store instructions doesn't seem the right
> tradeoff to me. Sorry if I reduced the testcase too far to make the balance
> clear.

Itanic seems to like it though:

http://gcc.opensuse.org/SPEC/CFP/sb-terbium-head-64/171_swim_big.png

For Haswell I don't see any ups/downs for AMD Fam15 I see a slowdown
as well around that time.  I guess it depends if the CPU is already
throttled by load/compute bandwith here.  What should be profitable
is to distribute the above to three loops (w/o memcpy).  So after
the patch doing -ftree-loop-distribution.  Patch being

Index: gcc/tree-loop-distribution.c
===
--- gcc/tree-loop-distribution.c(revision 244963)
+++ gcc/tree-loop-distribution.c(working copy)
@@ -1548,8 +1548,7 @@ distribute_loop (struct loop *loop, vec<
   for (int j = i + 1;
   partitions.iterate (j, ); ++j)
{
- if (!partition_builtin_p (partition)
- && similar_memory_accesses (rdg, into, partition))
+ if (similar_memory_accesses (rdg, into, partition))
{
  if (dump_file && (dump_flags & TDF_DETAILS))
{

[Bug middle-end/78142] Commit r241590 is more registers to be used for on gcc.target/aarch64/vector_initialization_nostack.c

[tnfchris at gcc dot gnu.org]

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

tnfchris at gcc dot gnu.org changed:

   What|Removed |Added

 Status|RESOLVED|ASSIGNED
   Last reconfirmed||2017-01-27
 Resolution|FIXED   |---
 Ever confirmed|0   |1

--- Comment #5 from tnfchris at gcc dot gnu.org ---
This seems to have only been temporarily passing on aarch64-none-linux-gnu.

I've submitted a new patch to change the test to make it more reliable.

[Bug c/79219] Feature request: double width/single width -> single width integer division and remainder

[ubizjak at gmail dot com]

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

--- Comment #9 from Uroš Bizjak  ---
(In reply to H. Peter Anvin from comment #8)
> (In reply to Richard Biener from comment #1)
> > So you mean DW/W -> W, but that can result in the result being not
> > representable?
> > What's the desired behavior in this case?  Invoking undefined behavior?
> 
> When the output is not representable, the expected behavior is whatever the
> platform does when an ordinary division divides by zero (which usually means
> some variant of raise(SIGFPE) is invoked through one path or another.)

If this is the case, we already have appropriate pattern (although
commented-out ATM) in i386.md (the example is for 32-bit target, but can be
trivially changed to fit TImode/DImode on 64-bit targets)

--cut here--
;; We cannot use div/idiv for double division, because it causes
;; "division by zero" on the overflow and that's not what we expect
;; from truncate.  Because true (non truncating) double division is
;; never generated, we can't create this insn anyway.
;
;(define_insn ""
;  [(set (match_operand:SI 0 "register_operand" "=a")
;   (truncate:SI
; (udiv:DI (match_operand:DI 1 "register_operand" "A")
;  (zero_extend:DI
;(match_operand:SI 2 "nonimmediate_operand" "rm")
;   (set (match_operand:SI 3 "register_operand" "=d")
;   (truncate:SI
; (umod:DI (match_dup 1) (zero_extend:DI (match_dup 2)
;   (clobber (reg:CC FLAGS_REG))]
;  ""
;  "div{l}\t{%2, %0|%0, %2}"
;  [(set_attr "type" "idiv")])
--cut here--

The comment suggests that middle-end has to be improved to detect and expand
TI/DI -> DI division in a similar generic way as DI/DI -> TI multiplication. 

OTOH, since the truncation of the result of the division doesn't trap, the
combined pattern also should not (combine pass can synthesize this pattern from
separate patterns). IMO, at least for x86, we need a builtin.

[Bug target/79211] ICE in extract_insn, at recog.c:2311

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-01-27
 Ever confirmed|0   |1

--- Comment #3 from Segher Boessenkool  ---
It does not crash with -mcpu=power7, but it crashes without it
(which means -mcpu=power4).  Power7 has VSX, and then xsmindp
is used (smin:SF); your crash is on an fsel insn, classic FP.

Confirmed.

[Bug tree-optimization/79245] [7 Regression] Inefficient loop distribution to memcpy

[jgreenhalgh at gcc dot gnu.org]

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

--- Comment #4 from James Greenhalgh  ---
(In reply to Richard Biener from comment #3)
> Note the trivial fix will FAIL gcc.dg/tree-ssa/ldist-23.c which looks like
> 
>   int i;
>   for (i = 0; i < 128; ++i)
> {
>   a[i] = a[i] + 1;
>   b[i] = d[i];
>   c[i] = a[i] / d[i];
> }
> 
> where the testcase expects b[i] = d[i] to be split out as memcpy but
> the other two partitions to be fused.
> 
> Generally the cost model lacks computing the number of input/output streams
> of a partition and a target interface to query it about limits.  Usually
> store bandwidth is not equal to load bandwidth and not re-used store streams
> can benefit from non-temporal stores being used by libc.
> 
> In your testcase I wonder whether distributing to
> 
> for (int j = 0; j < x; j++)
>   {
> for (int i = 0; i < y; i++)
> {
>   c[j][i] = b[j][i] - a[j][i];
>   }
>   }
> memcpy (a, b, ...);
> 
> would be faster in the end (or even doing the memcpy first in this case).
> 
> Well, for now let's be more conservative given the cost model really is
> lacking.

The testcase is reduced from CALC3 in 171.swim. I've been seeing a 3%
regression for Cortex-A72 after r242038, and I can fix that with
-fno-tree-loop-distribute-patterns.

In that benchmark you've got 3 instances of the above pattern, so you end up
with 3 memcpy calls after:

  DO 300 J=1,N
  DO 300 I=1,M
  UOLD(I,J) = U(I,J)+ALPHA*(UNEW(I,J)-2.*U(I,J)+UOLD(I,J))
  VOLD(I,J) = V(I,J)+ALPHA*(VNEW(I,J)-2.*V(I,J)+VOLD(I,J))
  POLD(I,J) = P(I,J)+ALPHA*(PNEW(I,J)-2.*P(I,J)+POLD(I,J))
  U(I,J) = UNEW(I,J)
  V(I,J) = VNEW(I,J)
  P(I,J) = PNEW(I,J)
  300 CONTINUE

3 memcpy calls compared to 3 vector store instructions doesn't seem the right
tradeoff to me. Sorry if I reduced the testcase too far to make the balance
clear.

[Bug c++/79232] [7 Regression] error: invalid rhs for gimple memory store

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||jsm28 at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
On the gimplifier side, this is caused by the PR17855 changes which look weird.
We have COND_EXPR  = whatever;
(of course the question is if the FE should emit that and not INDIRECT_REF
> = whatever), and there are 2
problems.  Before the
  /* C99 code may assign to an array in a structure value of a
 conditional expression, and this has undefined behavior
 only on execution, so create a temporary if an lvalue is
 required.  */
  if (fallback == fb_lvalue)
{
  *expr_p = get_initialized_tmp_var (*expr_p, pre_p, post_p,
false);
  mark_addressable (*expr_p);
  ret = GS_OK;
}
block for COND_EXPR we have *expr_p a MEM_REF with iftmp.0 as address, exactly
what we need.  Without the mark_addressable (not sure why that was ever needed)
we would actually end up writing to a temporary variable (first store there the
previous value of the MEM_REF, then again the value we want into the MEM_REF).
But the mark_addressable, if *expr_p has gimple ref type, actually causes also
invalid IL in addition to wrong-code.
I've tried the struct-non-lval-2.c testcase and this code is not reached in
that case (because fallback is just 0, not fb_lvalue).

That said, even if we fix the gimplifier, we probably want to change the FE so
that it actually makes it clear what the store does.  For COND_EXPR without the
COMPOUND_EXPR, the FE actually emits if (cond) { ()[d] = e; } else { a[d] =
e; }, so we probably want to emit that too.

[Bug bootstrap/79255] [7 Regression] PGO bootstrap fails on x86_64/ppc64le building Ada

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener  ---
Configured with

[   55s] + ../configure --prefix=/usr --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64
--enable-languages=c,c++,objc,fortran,obj-c++,ada,go
--enable-offload-targets=hsa,nvptx-none=/usr/nvptx-none, --without-cuda-driver
--disable-werror --with-gxx-include-dir=/usr/include/c++/7 --enable-ssp
--disable-libssp --disable-libvtv --disable-libcc1 --enable-plugin
--with-bugurl=http://bugs.opensuse.org/ '--with-pkgversion=SUSE Linux'
--with-slibdir=/lib64 --with-system-zlib --enable-__cxa_atexit
--enable-libstdcxx-allocator=new --disable-libstdcxx-pch
--enable-version-specific-runtime-libs --with-gcc-major-version-only
--enable-linker-build-id --enable-linux-futex --enable-gnu-indirect-function
--program-suffix=-7 --without-system-libunwind --enable-multilib
--with-arch-32=x86-64 --with-tune=generic --build=x86_64-suse-linux
--host=x86_64-suse-linux

and

[   52s] + ../configure --prefix=/usr --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64
--enable-languages=c,c++,objc,fortran,obj-c++,ada,go --disable-werror
--with-gxx-include-dir=/usr/include/c++/7 --enable-ssp --disable-libssp
--disable-libvtv --disable-libmpx --disable-libcc1 --enable-plugin
--with-bugurl=http://bugs.opensuse.org/ '--with-pkgversion=SUSE Linux'
--with-slibdir=/lib64 --with-system-zlib --enable-__cxa_atexit
--enable-libstdcxx-allocator=new --disable-libstdcxx-pch
--enable-version-specific-runtime-libs --with-gcc-major-version-only
--enable-linker-build-id --enable-linux-futex --enable-gnu-indirect-function
--program-suffix=-7 --without-system-libunwind --with-cpu=power8
--with-tune=power8 --enable-secureplt --with-long-double-128
--enable-targets=powerpcle-linux --disable-multilib
--build=powerpc64le-suse-linux --host=powerpc64le-suse-linux

[Bug bootstrap/79255] [7 Regression] PGO bootstrap fails on x86_64/ppc64le building Ada

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |7.0

[Bug bootstrap/79255] New: [7 Regression] PGO bootstrap fails on x86_64/ppc64le building Ada

[rguenth at gcc dot gnu.org]

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

Bug ID: 79255
   Summary: [7 Regression] PGO bootstrap fails on x86_64/ppc64le
building Ada
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: build
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---
Target: x86_64-*-*, powerpc64le-*-*

With r244934 and --disable-werror I see in stagefeedback

[ 7754s] +===GNAT BUG
DETECTED==+
[ 7754s] | 7 20170126 (experimental) [trunk revision 244934]
(x86_64-suse-linux) GCC error:|
[ 7754s] | in check_die, at dwarf2out.c:6162   
|
[ 7754s] | Error detected around ../../gcc/ada/uintp.adb:1091:14   
|
[ 7754s] | Please submit a bug report; see http://gcc.gnu.org/bugs.html.   
|
[ 7754s] | Use a subject line meaningful to you and us to track the bug.   
|
[ 7754s] | Include the entire contents of this bug box in the report.  
|
[ 7754s] | Include the exact command that you entered. 
|
[ 7754s] | Also include sources listed below.  
|
[ 7754s]
+==+
[ 7754s] 
[ 7754s] Please include these source files with error report
[ 7754s] Note that list may not be accurate in some cases,
...

similar for ppc64le:

[11867s] +===GNAT BUG
DETECTED==+
[11867s] | 7 20170126 (experimental) [trunk revision 244934]
(powerpc64le-suse-linux) GCC error:|
[11867s] | in check_die, at dwarf2out.c:6162   
|
[11867s] | Error detected around ../../gcc/ada/atree.adb:2595:8
|
[11867s] | Please submit a bug report; see http://gcc.gnu.org/bugs.html.   
|
[11867s] | Use a subject line meaningful to you and us to track the bug.   
|
[11867s] | Include the entire contents of this bug box in the report.  
|
[11867s] | Include the exact command that you entered. 
|
[11867s] | Also include sources listed below.  
|
[11867s]
+==+
[11867s] 
[11867s] Please include these source files with error report
[11867s] Note that list may not be accurate in some cases,

[Bug tree-optimization/79245] [7 Regression] Inefficient loop distribution to memcpy

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Note the trivial fix will FAIL gcc.dg/tree-ssa/ldist-23.c which looks like

  int i;
  for (i = 0; i < 128; ++i)
{
  a[i] = a[i] + 1;
  b[i] = d[i];
  c[i] = a[i] / d[i];
}

where the testcase expects b[i] = d[i] to be split out as memcpy but
the other two partitions to be fused.

Generally the cost model lacks computing the number of input/output streams
of a partition and a target interface to query it about limits.  Usually
store bandwidth is not equal to load bandwidth and not re-used store streams
can benefit from non-temporal stores being used by libc.

In your testcase I wonder whether distributing to

for (int j = 0; j < x; j++)
  {
for (int i = 0; i < y; i++)
  {
c[j][i] = b[j][i] - a[j][i];
  }
  }
memcpy (a, b, ...);

would be faster in the end (or even doing the memcpy first in this case).

Well, for now let's be more conservative given the cost model really is
lacking.

[Bug tree-optimization/79244] [7 Regression] ice in replace_uses_by, at tree-cfg.c:1866

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener  ---
On branches this is latent wrong-code as we simply do

/* Propagate the RHS into every use of the LHS.  */
FOR_EACH_IMM_USE_STMT (use_stmt, iter, lhs)
  FOR_EACH_IMM_USE_ON_STMT (use_p, iter)
SET_USE (use_p, var);

there.  OTOH we only see unpropagated vars there so we are restoring the
original
IL.  I changed it to replace_uses_by to get stmts folded properly to avoid
non-canonical operand order and non-canonical MEMs after propagation.

I'll conditionally restore the above.

[Bug target/79211] ICE in extract_insn, at recog.c:2311

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
My cross compiler for x86_64 is configured:

../configure --enable-languages=c,c++ --prefix=/home/marxin/bin/gcc2
--disable-multilib --disable-bootstrap --target=powerpc64-suse-linux

[Bug tree-optimization/79244] [7 Regression] ice in replace_uses_by, at tree-cfg.c:1866

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #7 from Richard Biener  ---
Mine.

[Bug tree-optimization/79245] [7 Regression] Inefficient loop distribution to memcpy

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-01-27
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Target Milestone|--- |7.0
 Ever confirmed|0   |1

--- Comment #2 from Richard Biener  ---
Probably needs enhancement here:

  /* Apply our simple cost model - fuse partitions with similar
 memory accesses.  */
  for (i = 0; partitions.iterate (i, ); ++i)
{
  bool changed = false;
  if (partition_builtin_p (into))
continue;
  for (int j = i + 1;
   partitions.iterate (j, ); ++j)
{
  if (!partition_builtin_p (partition)
  && similar_memory_accesses (rdg, into, partition))
{
  if (dump_file && (dump_flags & TDF_DETAILS))
{
  fprintf (dump_file, "fusing partitions\n");
  dump_bitmap (dump_file, into->stmts);

see how we do not let detected patterns participate in the cost modeling.

[Bug libstdc++/79254] [5/6/7 Regression] basic_string::operator= isn't exception safe

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
   Target Milestone|--- |5.5

[Bug libstdc++/79254] [5/6/7 Regression] basic_string::operator= isn't exception safe

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely  ---
(In reply to Daryl Haresign from comment #6)
> I guess you don't want _M_copy_assign to be public, either.

Nor inline :-)

Avoiding the try-catch like that is an improvement, I'll do that.

[Bug tree-optimization/71433] [7 Regression] -Warray-bounds false positive with -O2

[rguenth at gcc dot gnu.org]

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

--- Comment #13 from Richard Biener  ---
Ok, same reason but my "simple" two-predecessor "hack" doesn't get it because
we now have three...

[Bug fortran/79165] 100% compile-time increase for polyhedron aermod by r244581

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P1  |P3
   Target Milestone|7.0 |---
   Severity|normal  |enhancement

--- Comment #23 from Richard Biener  ---
As it's no longer a regression let's keep it open as enhancement.