Re: Ping: Re: [PATCH 1/2] gcc: Remove unneeded global flag.

[Andrew Burgess]

* Bernd Schmidt  [2016-11-03 13:01:32 +0100]:

> On 09/14/2016 03:00 PM, Andrew Burgess wrote:
> > In an attempt to get this patch merged (as I still think that its
> > correct) I've investigated, and documented a little more about how I
> > think things currently work.  I'm sure most people reading this will
> > already know this, but hopefully, if my understanding is wrong someone
> > can point it out.
> > gcc/ChangeLog:
> > 
> > * gcc/bb-reorder.c: Remove 'toplev.h' include.
> > (pass_partition_blocks::gate): No longer check
> > user_defined_section_attribute, instead check the function decl
> > for a section attribute.
> > * gcc/c-family/c-common.c (handle_section_attribute): No longer
> > set user_defined_section_attribute.
> > * gcc/final.c (rest_of_handle_final): Likewise.
> > * gcc/toplev.c: Remove definition of user_defined_section_attribute.
> > * gcc/toplev.h: Remove declaration of
> > user_defined_section_attribute.
> > 
> > gcc/testsuiteChangeLog:
> > 
> > * gcc.dg/tree-prof/section-attr-1.c: New file.
> > * gcc.dg/tree-prof/section-attr-2.c: New file.
> > * gcc.dg/tree-prof/section-attr-3.c: New file.
> 
> I think the explanation is perfectly reasonable and the patch looks good,
> except:
> 
> > +__attribute__((noinline))
> 
> Add noclone to all of these as well.

Thanks.  Considering Jeff said, I'm thinking about it, and you've said
yes, and given Jeff's not got back, I'm considering this patch
approved (with the fix you suggest).

My only remaining concern is the new tests, I've tried to restrict
them to targets that I suspect they'll pass on with:

/* { dg-final-use { scan-assembler "\.section\[\t 
\]*\.text\.unlikely\[\\n\\r\]+\[\t \]*\.size\[\t \]*foo\.cold\.0" { target 
*-*-linux* *-*-gnu* } } } */

but I'm still nervous that I'm going to introduce test failures.  Is
there any advice / guidance I should follow before I commit, or are
folk pretty relaxed so long as I've made a reasonable effort?

Thanks,
Andrew

Re: [PATCH] Handle --enable-checking={yes,assert,release} in libcpp (PR bootstrap/72823)

[Richard Biener]

On November 16, 2016 7:22:51 PM GMT+01:00, Jakub Jelinek  
wrote:
>Hi!
>
>As mentioned in the PR, libcpp uses gcc_assert in a couple of places,
>but guards it with ENABLE_ASSERT_CHECKING macro that is never defined
>in libcpp.
>
>This patch arranges for it to be defined if ENABLE_ASSERT_CHECKING
>is going to be defined in gcc subdir.
>
>Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

OK.

Richard.

>2016-11-16  Jakub Jelinek  
>
>   PR bootstrap/72823
>   * configure.ac (ENABLE_ASSERT_CHECKING): Define if gcc configure
>   would define that macro.
>   * configure: Regenerated.
>   * config.in: Regenerated.
>
>--- libcpp/configure.ac.jj 2016-05-20 12:44:36.0 +0200
>+++ libcpp/configure.ac2016-11-15 16:40:16.753842880 +0100
>@@ -152,9 +152,11 @@ for check in release $ac_checking_flags
> do
>   case $check in
>   # these set all the flags to specific states
>-  yes|all) ac_checking=1 ; ac_valgrind_checking= ;;
>-  no|none|release) ac_checking= ; ac_valgrind_checking= ;;
>+  yes|all) ac_checking=1 ; ac_assert_checking=1 ; ac_valgrind_checking=
>;;
>+  no|none) ac_checking= ; ac_assert_checking= ; ac_valgrind_checking=
>;;
>+  release) ac_checking= ; ac_assert_checking=1 ; ac_valgrind_checking=
>;;
>   # these enable particular checks
>+  assert) ac_assert_checking=1 ;;
>   misc) ac_checking=1 ;;
>   valgrind) ac_valgrind_checking=1 ;;
>   # accept
>@@ -170,6 +172,11 @@ else
>   AC_DEFINE(CHECKING_P, 0)
> fi
> 
>+if test x$ac_assert_checking != x ; then
>+  AC_DEFINE(ENABLE_ASSERT_CHECKING, 1,
>+[Define if you want assertions enabled.  This is a cheap check.])
>+fi
>+
> if test x$ac_valgrind_checking != x ; then
>   AC_DEFINE(ENABLE_VALGRIND_CHECKING, 1,
>[Define if you want to workaround valgrind (a memory checker) warnings
>about
>--- libcpp/configure.jj2016-05-20 12:44:36.0 +0200
>+++ libcpp/configure   2016-11-15 16:40:35.331607679 +0100
>@@ -7288,9 +7288,11 @@ for check in release $ac_checking_flags
> do
>   case $check in
>   # these set all the flags to specific states
>-  yes|all) ac_checking=1 ; ac_valgrind_checking= ;;
>-  no|none|release) ac_checking= ; ac_valgrind_checking= ;;
>+  yes|all) ac_checking=1 ; ac_assert_checking=1 ; ac_valgrind_checking=
>;;
>+  no|none) ac_checking= ; ac_assert_checking= ; ac_valgrind_checking=
>;;
>+  release) ac_checking= ; ac_assert_checking=1 ; ac_valgrind_checking=
>;;
>   # these enable particular checks
>+  assert) ac_assert_checking=1 ;;
>   misc) ac_checking=1 ;;
>   valgrind) ac_valgrind_checking=1 ;;
>   # accept
>@@ -7308,6 +7310,12 @@ else
> 
> fi
> 
>+if test x$ac_assert_checking != x ; then
>+
>+$as_echo "#define ENABLE_ASSERT_CHECKING 1" >>confdefs.h
>+
>+fi
>+
> if test x$ac_valgrind_checking != x ; then
> 
> $as_echo "#define ENABLE_VALGRIND_CHECKING 1" >>confdefs.h
>--- libcpp/config.in.jj2016-05-20 12:44:36.0 +0200
>+++ libcpp/config.in   2016-11-15 16:40:38.0 +0100
>@@ -14,6 +14,9 @@
> /* Define to 1 if using `alloca.c'. */
> #undef C_ALLOCA
> 
>+/* Define if you want assertions enabled. This is a cheap check. */
>+#undef ENABLE_ASSERT_CHECKING
>+
> /* Define to enable system headers canonicalization. */
> #undef ENABLE_CANONICAL_SYSTEM_HEADERS
> 
>
>   Jakub

[Bug fortran/78299] [6 Regression] ICE in expand_omp_for_static_nochunk, at omp-low.c:9622

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[6/7 Regression] ICE in |[6 Regression] ICE in
   |expand_omp_for_static_nochu |expand_omp_for_static_nochu
   |nk, at omp-low.c:9622   |nk, at omp-low.c:9622

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

[Bug middle-end/61409] [5/6/7 regression] -Wmaybe-uninitialized false-positive with -O2

[law at redhat dot com]

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

--- Comment #24 from Jeffrey A. Law  ---
OK.  It's coming back to me now.  And yes, Aldy, it was the edge 9->6 :-)

So we have a PHI argument that references an uninitialized variable.  There is
a control predicate for that PHI argument, call it p.

The use of the result of the PHI is also guarded.  In this particular case the
guard is !p.

Thus there is no path through the CFG which uses the uninitialized variable. 
We ought to be able to look at the guard of the PHI argument as well as the
guard for the use, at least that's the theory.  Now onward to look at your
patch...

[PING^2][PATCH][aarch64] Improve Logical And Immediate Expressions

[Michael Collison]

Ping^2. Link to original post:

https://gcc.gnu.org/ml/gcc-patches/2016-10/msg02305.html

[Bug fortran/69298] [OOP] Array finalisers seem to be given the wrong array when the array is a member variable

[janus at gcc dot gnu.org]

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

--- Comment #6 from janus at gcc dot gnu.org ---
Here is a further reduced test case, based on Dominique's variant in comment
#2, which (I think) runs into the same runtime-segfault when calling
stuff_1d_finaliser ...



module stuff_mod

  implicit none

  type :: stuff_type
integer :: junk
  contains
final :: stuff_1d_finaliser
  end type

contains

  subroutine stuff_1d_finaliser( this )
type(stuff_type), intent(inout) :: this(:)
integer :: i
write( 6, '("Finalising stuff_type array")', advance='no' )
do i = lbound( this, 1 ), ubound( this, 1 )
  write(6, '(" ", I0)', advance='no' ) this(i)%junk
end do
write( 6, '()' )
  end subroutine

end module stuff_mod


program test

  use stuff_mod

  implicit none

  integer, parameter :: n = 2

  type test_type
type(stuff_type) :: things(n)
  end type

  call sub()

contains

  subroutine sub()
type(test_type) :: tt
integer :: i
write( 6, '("Initialising")' )
do i = 1, n
  tt%things(i) = stuff_type( i )
end do
write( 6, '("Done")' )
  end subroutine

end

[Bug bootstrap/78385] New: Build of libgcc2 for target arm-eabi fails, if configuration --with-abi=apcs-gnu is used (in GCC-Build)

[meisenmann....@fh-salzburg.ac.at]

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

Bug ID: 78385
   Summary: Build of libgcc2 for target arm-eabi fails, if
configuration --with-abi=apcs-gnu is used (in
GCC-Build)
   Product: gcc
   Version: 6.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: meisenmann@fh-salzburg.ac.at
  Target Milestone: ---

If I build a Cross-GCC (on/with i686-w64-mingw32 fromm msys2) for
--target=arm-eabi and use additionally the option --with-abi=apcs-gnu (to
compile to OABI as default), the build of libgcc2 (a nearby last phase) will
fail with:

/x/GCC5/.temp/gcc/./gcc/xgcc -B/x/GCC5/.temp/gcc/./gcc/
-B/x/GCC5/V5.X.0/arm-eabi/bin/ -B/x/GCC5/V5.X.0/arm-eabi/lib/ -isystem
/x/GCC5/V5.X.0/arm-eabi/include -isystem /x/GCC5/V5.X.0/arm-eabi/sys-include   
-Os @X:/GCC5/.temp/arm-eabi.opt -O2  -Os @X:/GCC5/.temp/arm-eabi.opt -DIN_GCC 
-DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition 
-isystem ./include   -fno-inline -g -DIN_LIBGCC2 -fbuilding-libgcc
-fno-stack-protector -Dinhibit_libc  -fno-inline -I. -I. -I../.././gcc
-I../../../../src/gcc-5.X.0/libgcc -I../../../../src/gcc-5.X.0/libgcc/.
-I../../../../src/gcc-5.X.0/libgcc/../gcc
-I../../../../src/gcc-5.X.0/libgcc/../include-o _fixsfdi.o -MT _fixsfdi.o
-MD -MP -MF _fixsfdi.dep -DL_fixsfdi -c
../../../../src/gcc-5.X.0/libgcc/libgcc2.c -fvisibility=hidden -DHIDE_EXPORTS
In file included from ../../../../src/gcc-5.X.0/libgcc/libgcc2.c:56:0:
../../../../src/gcc-5.X.0/libgcc/libgcc2.c: In function '__fixsfdi':
x:\gcc5\src\gcc-5.x.0\libgcc\libgcc2.h:209:20: sorry, unimplemented: PCS
variant
 #define __NDW(a,b) __ ## a ## di ## b
^
x:\gcc5\src\gcc-5.x.0\libgcc\libgcc2.h:282:19: note: in expansion of macro
'__NDW'
 #define __fixsfdi __NDW(fixsf,)
   ^
../../../../src/gcc-5.X.0/libgcc/libgcc2.c:1497:1: note: in expansion of macro
'__fixsfdi'
 __fixsfdi (SFtype a)
 ^
make[2]: *** [Makefile:467: _fixsfdi.o] Error 1


Configuration of the previously build Cross-GCC:
>arm-eabi-gcc -v
Using built-in specs.
COLLECT_GCC=\GCC5\V5.X.0\bin\arm-eabi-gcc
COLLECT_LTO_WRAPPER=x:/gcc5/v5.x.0/bin/../libexec/gcc/arm-eabi/6.2.0/lto-wrapper.exe
Target: arm-eabi
Configured with: ../../src/gcc-5.X.0/configure --prefix=/x/GCC5/V5.X.0
--build=i686-w64-mingw32 --target=arm-eabi --disable-nls --disable-shared
--disable-multilib --disable-threads --with-pkgversion='Built by ME, rev.
20161114' --enable-languages=c,c++ --with-gnu-as --with-gnu-ld
--disable-win32-registry --with-arch=armv7-a --with-abi=apcs-gnu
--with-float=softfp --with-fpu=vfpv3 --disable-tls --with-stabs
--disable-__cxa_atexit --disable-decimal-float --disable-libgomp
--disable-libquadmath --disable-libstdcxx-verbose --with-newlib
--with-headers=../../src/newlib-2.3.0/newlib/libc/include
--with-gxx-include-dir=/x/GCC5/V5.X.0/include/c++/5.X.0
--disable-libstdcxx-visibility --enable-fully-dynamic-string
--with-gmp=C:/msys32/mingw32 --with-mpfr=C:/msys32/mingw32
--with-mpc=C:/msys32/mingw32
Thread model: single
gcc version 6.2.0 (Built by ME, rev. 20161114)

Additional information:
Same failure occurs, If I build an GCC 5.4.0 (an same configuration).
IMHO - It seems, that the -mabi-Option apcs-gnu (default) causes this issue on
building of the function '__fixsfdi'; But no fail on e.g. __fixunsdfsi ...

Best regards from Austria,
Markus

[Bug fortran/78351] comma not terminating READ of formatted input field - ok in 4.1.7, not 4.4.7- maybe related to 25419?

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #16 from Steve Kargl  ---
On Wed, Nov 16, 2016 at 06:36:58PM +, kevin.b.beard at nasa dot gov wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78351
> 
> --- Comment #13 from Dr. Kevin B. Beard  ---
> Hi,
> 
> Thanks for looking at this.  I'm sorry to say I don't have access
>  to the official F77 standards, perhaps you could send me a copy
> of the whole?

google "F77 standard"

https://www.fortran.com/F77_std/rjcnf0001.html
https://gcc.gnu.org/wiki/GFortranStandards

> The section you quoted doesn't seems too exclude the comma-terminated
> behavior I've always seen, and it has been widely used
> by many many programmers throughout the community over the years.


I cited the entire relevant passage.  Now, edited to its essences.

   13.5.9.1 Integer Editing

   The Iw and Iw.m edit descriptors indicate that the field to be
   edited occupies w positions.

   On input, an Iw.m edit descriptor is treated identically to an
   Iw edit descriptor.

   In the input field, the character string must be in the form
   of an optionally signed integer constant, except for the
   interpretation of blanks (13.5.9, item (1)).

In your code, you have

   character*80 s
   s= '1,2,3'
   READ(s,'(2i10)') i,j

The format request a field width of 10 for 'i'.  So, 10 positions
in 's' are '1,2,3 ' (where I had to add a space because 
technically 's' does not have 10 positions).  A signed integer
constant does not contain 5 commas.

> I've always been told and believed that a comma terminated a
> numeric field;

For list-directed input (i.e., FMT=*), yes, a comma is a 
value separator.

> but w/o > access to the standards I can't point to the line that
> says it must.

You won't find a line.  I cited the entire relevant text from
Fortran 77 that applies to the above code.  You either need to
change the code to

   character*80 s
!  12345678901234567890
   s= '1 2 '
   READ(s,'(2i10)') i,j

where '1' can appear anywhere within the first 10 positions, or

   character*80 s
!  12345678901234567890
   s= '1,2,3'
   READ(s,*) i,j

> What I'd like to see is that newer gfortran versions support
> its previous (and every other FORTRAN compiler I've tested)
> behavior.

So, no bugs should ever be fixed?  Have you filed bug reports
with all the other vendors?  I suspect that if you use an
option with those vendors' compiler to request Standard
conformance, you'll find that the code is invalid.  If not, 
file a bug report with those vendors.

> The flag "-std=legacy" does not restore the previous behavior,
> and I've found no option in the newer gfortrans that does.

That's because no one has implemented the patch to (un)fix gfortran
to handle invalid code.  jerryd has indicated that he'll look into
the issue.  

I do find it ironic that you refuse to fix broken code,
but expect those that strive to provide a quality tool
like gfortran to break its conformance to the standard.

[Bug fortran/78351] comma not terminating READ of formatted input field - ok in 4.1.7, not 4.4.7- maybe related to 25419?

[jvdelisle at gcc dot gnu.org]

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

--- Comment #15 from Jerry DeLisle  ---
Well, on further investigation I see that we do have a flag in read_sf to
signal a comma. It does not have this flag in read_sf_internal, So definitely
does not work on strings. My bet is that when we/I split the function, way way
back, I did not carry over the comma checks in order to get performance with
internal units.

I plan to test on a file and make sure this is working then I will see if I can
do something on internal units that does not penalize too much.

Re: [PATCH] Fix NetBSD bootstrap

[Krister Walfridsson]

On Wed, 16 Nov 2016, Mike Stump wrote:

Looks reasonable.  The biggest issue would be if any of those values 
changed through time, and the current version works for older netbsd 
releases, the patch could break them.  Of course, I don't have any 
visibility into how any of those values might have changed through time.


This should not be an issue in this case, so I'll commit the patch. 
Thanks!


   /Krister

[PATCH v2 1/2, i386] cmpstrnsi needs string length

[Aaron Sawdey]

This patch adds a test to the cmpstrnsi pattern in i386.md so that it
will bail out (FAIL) if neither of the strings is a constant string. It
can only work as a proper strncmp if the length is not longer than both
of the strings. This change is required if expand_builtin_strncmp is
going to try expansion of strncmp when neither string argument is
constant. I've also changed the pattern to indicate that operand 3 may
be clobbered (if it happens to be in cx already).

2016-11-16  Aaron Sawdey  

* config/i386/i386.md (cmpstrnsi): New test to bail out if neither
string input is a string constant.  Clobber length argument.


-- 
Aaron Sawdey, Ph.D.  acsaw...@linux.vnet.ibm.com
050-2/C113  (507) 253-7520 home: 507/263-0782
IBM Linux Technology Center - PPC ToolchainIndex: gcc/config/i386/i386.md
===
--- gcc/config/i386/i386.md	(revision 242428)
+++ gcc/config/i386/i386.md	(working copy)
@@ -16898,7 +16898,7 @@
   [(set (match_operand:SI 0 "register_operand")
 	(compare:SI (match_operand:BLK 1 "general_operand")
 		(match_operand:BLK 2 "general_operand")))
-   (use (match_operand 3 "general_operand"))
+   (clobber (match_operand 3 "general_operand"))
(use (match_operand 4 "immediate_operand"))]
   ""
 {
@@ -16911,6 +16911,21 @@
   if (fixed_regs[CX_REG] || fixed_regs[SI_REG] || fixed_regs[DI_REG])
 FAIL;
 
+  /* One of the strings must be a constant.  If so, expand_builtin_strncmp()
+ will have rewritten the length arg to be the minimum of the const string
+ length and the actual length arg.  If both strings are the same and
+ shorter than the length arg, repz cmpsb will not stop at the 0 byte and
+ will incorrectly base the results on chars past the 0 byte.  */
+  tree t1 = MEM_EXPR (operands[1]);
+  tree t2 = MEM_EXPR (operands[2]);
+  if (!((t1 && TREE_CODE (t1) == MEM_REF
+ && TREE_CODE (TREE_OPERAND (t1, 0)) == ADDR_EXPR
+ && TREE_CODE (TREE_OPERAND (TREE_OPERAND (t1, 0), 0)) == STRING_CST)
+  || (t2 && TREE_CODE (t2) == MEM_REF
+  && TREE_CODE (TREE_OPERAND (t2, 0)) == ADDR_EXPR
+  && TREE_CODE (TREE_OPERAND (TREE_OPERAND (t2, 0), 0)) == STRING_CST)))
+FAIL;
+
   out = operands[0];
   if (!REG_P (out))
 out = gen_reg_rtx (SImode);

[PATCH v2 2/2, expand] make expand_builtin_strncmp more general

[Aaron Sawdey]

This patch makes expand_builtin_strncmp attempt to expand via cmpstrnsi
even if neither of the string arguments are string constants.

2016-11-16  Aaron Sawdey  

* builtins.c (expand_builtin_strncmp): Attempt expansion of strncmp
via cmpstrnsi even if neither string is constant.

-- 
Aaron Sawdey, Ph.D.  acsaw...@linux.vnet.ibm.com
050-2/C113  (507) 253-7520 home: 507/263-0782
IBM Linux Technology Center - PPC ToolchainIndex: gcc/builtins.c
===
--- gcc/builtins.c	(revision 242428)
+++ gcc/builtins.c	(working copy)
@@ -3918,7 +3918,7 @@
   insn_code cmpstrn_icode = direct_optab_handler (cmpstrn_optab, SImode);
   if (cmpstrn_icode != CODE_FOR_nothing)
   {
-tree len, len1, len2;
+tree len, len1, len2, len3;
 rtx arg1_rtx, arg2_rtx, arg3_rtx;
 rtx result;
 tree fndecl, fn;
@@ -3937,14 +3937,19 @@
 if (len2)
   len2 = size_binop_loc (loc, PLUS_EXPR, ssize_int (1), len2);
 
+len3 = fold_convert_loc (loc, sizetype, arg3);
+
 /* If we don't have a constant length for the first, use the length
-   of the second, if we know it.  We don't require a constant for
+   of the second, if we know it.  If neither string is constant length,
+   use the given length argument.  We don't require a constant for
this case; some cost analysis could be done if both are available
but neither is constant.  For now, assume they're equally cheap,
unless one has side effects.  If both strings have constant lengths,
use the smaller.  */
 
-if (!len1)
+if (!len1 && !len2)
+  len = len3;
+else if (!len1)
   len = len2;
 else if (!len2)
   len = len1;
@@ -3961,23 +3966,10 @@
 else
   len = len2;
 
-/* If both arguments have side effects, we cannot optimize.  */
-if (!len || TREE_SIDE_EFFECTS (len))
-  return NULL_RTX;
-
-/* The actual new length parameter is MIN(len,arg3).  */
-len = fold_build2_loc (loc, MIN_EXPR, TREE_TYPE (len), len,
-		   fold_convert_loc (loc, TREE_TYPE (len), arg3));
-
-/* If we don't have POINTER_TYPE, call the function.  */
-if (arg1_align == 0 || arg2_align == 0)
-  return NULL_RTX;
-
-/* Stabilize the arguments in case gen_cmpstrnsi fails.  */
-arg1 = builtin_save_expr (arg1);
-arg2 = builtin_save_expr (arg2);
-len = builtin_save_expr (len);
-
+/* If we are not using the given length, we must incorporate it here.
+   The actual new length parameter will be MIN(len,arg3) in this case.  */
+if (len != len3)
+  len = fold_build2_loc (loc, MIN_EXPR, TREE_TYPE (len), len, len3);
 arg1_rtx = get_memory_rtx (arg1, len);
 arg2_rtx = get_memory_rtx (arg2, len);
 arg3_rtx = expand_normal (len);

[PATCH v2 0/2] strncmp builtin expansion improvement

[Aaron Sawdey]

Builtin expansion of strncmp currently only happens when at least one
of the string arguments is a constant string. Two pieces are needed to
enable this:

1) Fix i386.md cmpstrnsi pattern. It uses repzcmpsb which does not
actually test for the zero byte ending the string. So this is only a
valid pattern when the length of one of the strings is known. So this
adds a test for one of the string args being a string constant, in
which case expand_builtin_strncmp will have made sure the length arg is
no larger than this known length. Also I've changed the pattern to
reflect the fact that the generated code can clobber operand 3 if it
happens to be in cx.

2) If c_strlen () was unable to determine the length of either string,
expand_builtin_strncmp will now use only the length argument and will
proceed anyway. Also I've removed a couple pieces that Richard
indicated are not needed any more.

Bootstrap & regtest passed on x86_64 with svn 242454, ok for trunk?

-- 
Aaron Sawdey, Ph.D.  acsaw...@linux.vnet.ibm.com
050-2/C113  (507) 253-7520 home: 507/263-0782
IBM Linux Technology Center - PPC Toolchain

[Bug rtl-optimization/78374] Segfault in cc1 (arm-eabi) on -O1 (or better)

[meisenmann....@fh-salzburg.ac.at]

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

Markus Eisenmann  changed:

   What|Removed |Added

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

--- Comment #4 from Markus Eisenmann  ---
It seems to be a problem of the used msys2/mingw-environment:

After updating the i686-w64-mingw32 GCC (an libraries ...) from 4.9.2 to 6.2.0
and re-build of my Cross-GCC this issue does not occurs / is fixed.

Sorry; this is resolved (I.e, invalid/rejected).

[Bug tree-optimization/78384] New: [7 Regression] ICE: verify_flow_info failed (error: wrong outgoing edge flags at end of bb 15)

[asolokha at gmx dot com]

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

Bug ID: 78384
   Summary: [7 Regression] ICE: verify_flow_info failed (error:
wrong outgoing edge flags at end of bb 15)
   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: asolokha at gmx dot com
  Target Milestone: ---

gcc-7.0.0-alpha20161113 snapshot ICEs when compiling the following reduced
snippet at -O3 or -Ofast:

void
a2 (int wv, int yg, int r9)
{
  while (wv < 1)
{
  int vn = r9 % 0;

  while (yg < 1)
{
  int lz;

  for (r9 = 0; r9 < 17; ++r9)
{
}

 it:
  lz = (yg++ >= 0) ? 2 : 0;
  wv = vn < lz;
}
}
  goto it;
}

% x86_64-unknown-linux-gnu-gcc-7.0.0-alpha20161113 -O3 -w -c mohqqsmg.c
mohqqsmg.c: In function 'a2':
mohqqsmg.c:2:1: error: wrong outgoing edge flags at end of bb 15
 a2 (int wv, int yg, int r9)
 ^~
mohqqsmg.c:2:1: internal compiler error: verify_flow_info failed

Re: [PATCH] Fix NetBSD bootstrap

[Mike Stump]

> On Nov 16, 2016, at 9:12 AM, Krister Walfridsson 
>  wrote:
> 
> NetBSD fails bootstrap with
>  stdatomic.h:55:17: error: unknown type name '__INT_LEAST8_TYPE__'
> This is fixed by the following patch (only i386 and x86_64 for now. I'll
> do the other ports after fixing some more issues -- the NetBSD support is
> rather broken at the moment...)
> 
> I'm the NetBSD maintainer, so I belive I don't need approval to commit this. 
> But I have been absent for a long time, so it makes sense for someone to 
> review at least this first patch.

Looks reasonable.  The biggest issue would be if any of those values changed 
through time, and the current version works for older netbsd releases, the 
patch could break them.  Of course, I don't have any visibility into how any of 
those values might have changed through time.

[Bug fortran/78351] comma not terminating READ of formatted input field - ok in 4.1.7, not 4.4.7- maybe related to 25419?

[dominiq at lps dot ens.fr]

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

--- Comment #14 from Dominique d'Humieres  ---
Try to find what you want in http://www.fortran.com/F77_std/rjcnf0001.html.
Good luck!

[Bug rtl-optimization/78378] [5/6/7 Regression] wrong code when combining shift + mult + zero_extend

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.

[Bug middle-end/61409] [5/6/7 regression] -Wmaybe-uninitialized false-positive with -O2

[law at redhat dot com]

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

--- Comment #23 from Jeffrey A. Law  ---
Sorry, I can't remember if I meant 9->5 or 9->6 at this point :-)  I need to
refamiliarize myself with this stuff again to make sure I've got the basic
concepts before reviewing the patch.

But you can probably see now why I said there was some seriously powerful, but
dense code in here that I'd like to be able to re-use elsewhere to prune other
false positive may-be warnings.

Re: [PATCH][GCC/TESTSUITE] Make test for traditional-cpp depend on

[Mike Stump]

On Nov 16, 2016, at 10:58 AM, Mike Stump  wrote:
> 
> Yeah, I easily could have approved it as well, so no worries.

Oh.  I see I did approve the original patch, sorry for not catching it.  Thanks 
for all your work.

Re: [PATCH][GCC/TESTSUITE] Make test for traditional-cpp depend on

[Mike Stump]

On Nov 16, 2016, at 7:57 AM, Tamar Christina  wrote:
> 
> Forgot to include the committed patch.

>>> This is causing all test names to depend on $srcdir.  A test name
>>> should never include the value of $srcdir.
>> 
>> Sorry about that, committed a fix as r242500 under the obvious rule.

Yeah, I easily could have approved it as well, so no worries.

The patch is Ok.

The way I usually catch this would be in reviewing the output of 
./contrib/compare_tests, it would complain about a ton of new tests now not 
passing, which is a dead giveaway.

Re: Fix PR78154

[Jakub Jelinek]

On Thu, Nov 17, 2016 at 12:19:37AM +0530, Prathamesh Kulkarni wrote:
> --- a/gcc/tree-vrp.c
> +++ b/gcc/tree-vrp.c
> @@ -1069,6 +1069,34 @@ gimple_assign_nonzero_warnv_p (gimple *stmt, bool 
> *strict_overflow_p)
>  }
>  }
>  
> +/* Return true if STMT is known to contain call to a string-builtin function
> +   that is known to return nonnull.  */
> +
> +static bool
> +gimple_str_nonzero_warnv_p (gimple *stmt)
> +{
> +  if (!is_gimple_call (stmt))
> +return false;

Shouldn't this be:
  if (!gimple_call_builtin_p (stmt, BUILT_IN_NORMAL))
return false;

> +
> +  tree fndecl = gimple_call_fndecl (stmt);

> +  if (!fndecl || DECL_BUILT_IN_CLASS (fndecl) != BUILT_IN_NORMAL)
> +return false;

And drop the above 2 lines?

That we you also verify the arguments for sanity.

Otherwise I'll defer to Richard.

Jakub

Re: [RFC PATCH] avoid printing type suffix with %E

[Martin Sebor]

On 11/16/2016 11:34 AM, Jeff Law wrote:

On 10/26/2016 10:37 AM, Martin Sebor wrote:

When formatting an integer constant using the %E directive GCC
includes a suffix that indicates its type.  This can perhaps be
useful in some situations but in my experience it's distracting
and gets in the way when writing tests.

Here's an example:

  $ cat b.c && gcc b.c
  constexpr __SIZE_TYPE__ x = 2;

  enum E: bool { e = x };
  b.c:3:20: error: enumerator value 2ul is outside the range of
underlying type ‘bool’
   enum E: bool { e = x };
  ^

Notice the "2ul" in the error message.

As far as I can tell, Clang avoids printing the suffix and I think
it would be nice if the GCC pretty printer made it possible to avoid
it as well.

The attached patch implements one such approach by having the pretty
printer recognize the space format flag to suppress the type suffix,
so "%E" still prints the suffix but "% E" does not.  I did this to
preserve the existing output but I think it would be nicer to avoid
printing the suffix with %E and treat (for instance) the pound sign
as a request to add the suffix.  I have tested the attached patch
but not the alternative.

Does anyone have any comments/suggestions for which of the two
approaches would be preferable (or what I may have missed here)?
I CC David as the diagnostic maintainer.

I'm having a hard time seeing how this is a significant issue, even when
writing tests.

It also seems to me that relaying the type of the constant as a suffix
would help in cases that aren't so obvious.

What am I missing?


I don't think it's terribly important, more like nuisance.  Tests
that check the value printed by the %E directive (I've been writing
lots of those lately -- see for example (*)) have to consistently
use this pattern:

\[0-9\]+\[lu\]*

When the type of the %E argument is a type like size_t or similar
that can be an alias for unsigned long or unsigned int, it's easy
to make a mistake and hardcode either

\[0-9\]+lu

or

\[0-9\]+u

based on the target where the test is being developed and end
up with failures on targets where the actual type is the other.
Copying test cases exercising one type to those exercising the
other (say from int to long) is also more tedious than it would
be without the suffix.

Beyond tests, I have never found the suffix helpful in warnings
or errors, but I also haven't seen too many of them in released
versions of GCC.  With the work I've been doing on buffer
overflow where size expressions are routinely included in
the diagnostics, there are lots more of them.  In some (e.g.,
in all the -Wformat-length) I've taken care to avoid printing
the suffix by converting tree nodes to HOST_WIDE_INT.  But that's
cumbersome and error-prone, and leads to inconsistent output from
GCC for different diagnostics that don't do the same.

Martin

[*] https://gcc.gnu.org/ml/gcc-patches/2016-11/msg01672.html

Re: [PATCH v2] bb-reorder: Improve compgotos pass (PR71785)

[Jeff Law]

On 11/01/2016 10:27 AM, Segher Boessenkool wrote:

For code like the testcase in PR71785 GCC factors all the indirect branches
to a single dispatcher that then everything jumps to.  This is because
having many indirect branches with each many jump targets does not scale
in large parts of the compiler.  Very late in the pass pipeline (right
before peephole2) the indirect branches are then unfactored again, by
the duplicate_computed_gotos pass.

This pass works by replacing branches to such a common dispatcher by a
copy of the dispatcher.  For code like this testcase this does not work
so well: most cases do a single addition instruction right before the
dispatcher, but not all, and we end up with only two indirect jumps: the
one without the addition, and the one with the addition in its own basic
block, and now everything else jumps _there_.

This patch solves this problem by simply running the core of the
duplicate_computed_gotos pass again, as long as it does any work.  The
patch looks much bigger than it is, because I factored out two routines
to simplify the control flow.

Tested on powerpc64-linux {-m32,-m64}, and on the testcase, and on a version
of the testcase that has 2000 cases instead of 4.  Is this okay for trunk?


Segher


2016-10-30  Segher Boessenkool  

PR rtl-optimization/71785
* bb-reorder.c (duplicate_computed_gotos_find_candidates): New
function, factored out from pass_duplicate_computed_gotos::execute.
(duplicate_computed_gotos_do_duplicate): Ditto.  Don't use BB_VISITED.
(pass_duplicate_computed_gotos::execute): Rewrite.  Rerun the pass as
long as it makes changes.
OK.  I'm just going to note for the record here that while we iterate 
until nothing changes, the statement and block clamps should in practice 
ensure we hit a point where nothing changes.


Ideally I'd like to see testcases with this kind of change.  It should 
be standard operating procedure at this point.


Jeff

Fix PR78154

[Prathamesh Kulkarni]

Hi Richard,
Following your suggestion in PR78154, the patch checks if stmt
contains call to memmove (and friends) in gimple_stmt_nonzero_warnv_p
and returns true in that case.

Bootstrapped+tested on x86_64-unknown-linux-gnu.
Cross-testing on arm*-*-*, aarch64*-*-* in progress.
Would it be OK to commit this patch in stage-3 ?

Thanks,
Prathamesh
2016-11-17  Prathamesh Kulkarni  

* tree-vrp.c (gimple_str_nonzero_warnv_p): New function.
(gimple_stmt_nonzero_warnv_p): Call gimple_str_nonzero_warnv_p.

testsuite/
* gcc.dg/tree-ssa/pr78154.c: New test-case.

diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr78154.c 
b/gcc/testsuite/gcc.dg/tree-ssa/pr78154.c
new file mode 100644
index 000..d3463f4
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-ssa/pr78154.c
@@ -0,0 +1,28 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-evrp-slim" } */
+
+void f (void *d, const void *s, __SIZE_TYPE__ n)
+{
+  if (__builtin_memcpy (d, s, n) == 0)
+__builtin_abort ();
+
+  if (__builtin_memmove (d, s, n) == 0)
+__builtin_abort ();
+
+  if (__builtin_memset (d, 0, n) == 0)
+__builtin_abort ();
+
+  if (__builtin_strcpy (d, s) == 0)
+__builtin_abort ();
+
+  if (__builtin_strcat (d, s) == 0)
+__builtin_abort ();
+
+  if (__builtin_strncpy (d, s, n) == 0)
+__builtin_abort ();
+
+  if (__builtin_strncat (d, s, n) == 0)
+__builtin_abort ();
+}
+
+/* { dg-final { scan-tree-dump-not "__builtin_abort" "evrp" } } */
diff --git a/gcc/tree-vrp.c b/gcc/tree-vrp.c
index c2a4133..b563a7f 100644
--- a/gcc/tree-vrp.c
+++ b/gcc/tree-vrp.c
@@ -1069,6 +1069,34 @@ gimple_assign_nonzero_warnv_p (gimple *stmt, bool 
*strict_overflow_p)
 }
 }
 
+/* Return true if STMT is known to contain call to a string-builtin function
+   that is known to return nonnull.  */
+
+static bool
+gimple_str_nonzero_warnv_p (gimple *stmt)
+{
+  if (!is_gimple_call (stmt))
+return false;
+
+  tree fndecl = gimple_call_fndecl (stmt);
+  if (!fndecl || DECL_BUILT_IN_CLASS (fndecl) != BUILT_IN_NORMAL)
+return false;
+
+  switch (DECL_FUNCTION_CODE (fndecl))
+{
+  case BUILT_IN_MEMMOVE:
+  case BUILT_IN_MEMCPY:
+  case BUILT_IN_MEMSET:
+  case BUILT_IN_STRCPY:
+  case BUILT_IN_STRNCPY:
+  case BUILT_IN_STRCAT:
+  case BUILT_IN_STRNCAT:
+   return true;
+  default:
+   return false;
+}
+}
+
 /* Return true if STMT is known to compute a non-zero value.
If the return value is based on the assumption that signed overflow is
undefined, set *STRICT_OVERFLOW_P to true; otherwise, don't change
@@ -1097,7 +1125,7 @@ gimple_stmt_nonzero_warnv_p (gimple *stmt, bool 
*strict_overflow_p)
lookup_attribute ("returns_nonnull",
  TYPE_ATTRIBUTES (gimple_call_fntype (stmt
  return true;
-   return gimple_alloca_call_p (stmt);
+   return gimple_alloca_call_p (stmt) || gimple_str_nonzero_warnv_p (stmt);
   }
 default:
   gcc_unreachable ();

Re: [PATCH][2/2] GIMPLE Frontend, middle-end changes

[Jeff Law]

On 10/28/2016 05:51 AM, Richard Biener wrote:


These are the middle-end changes and additions to the testsuite.

They are pretty self-contained, I've organized the changelog
entries below in areas of changes:

 1) dump changes - we add a -gimple dump modifier that allows most
 function dumps to be directy fed back into the GIMPLE FE

 2) pass manager changes to implement the startwith("pass-name")
 feature which implements unit-testing for GIMPLE passes

 3) support for "SSA" input, a __PHI stmt that is lowered once the
 CFG is built, a facility to allow a specific SSA name to be allocated
 plus a small required change in the SSA rewriter to allow for
 pre-existing PHI arguments

Bootstrapped and tested on x86_64-unknown-linux-gnu (together with [1/2]).

I can approve all these changes myself but any comments are welcome.
My only worry would be ensuring that in the case where we're asking for 
a particular SSA_NAME in make_ssa_name_fn that we assert the requested 
name is available.


ISTM that if it's > the highest current version or in the freelist, then 
we ought to be safe.   If it isn't safe then we should either issue an 
error, or renumber the preexisting SSA_NAME (and determining if it's 
safe to renumber the preexisting SSA_NAME may require more context than 
we have).


jeff

RE: RFA: PATCH to gengtype to avoid putting tree_node support in front end objects

[Moore, Catherine]

> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Jakub Jelinek
> Sent: Thursday, November 10, 2016 7:53 AM
> To: Jason Merrill 
> Cc: gcc-patches List 
> Subject: Re: RFA: PATCH to gengtype to avoid putting tree_node
> support in front end objects
> 
> On Thu, Oct 27, 2016 at 09:36:09AM -0400, Jason Merrill wrote:
> > Currently, the way gengtype works it scans the list of source files
> > with front end files at the end, and pushes data structures onto a
> > stack.  It then processes the stack in LIFO order, so that data
> > structures from front ends are handled first.  As a result, if a GTY
> > data structure in a front end depends on tree_node, gengtype
> happily
> > puts gt_ggc_mx(tree_node*&) in a front end file, leading to link
> > errors on all other front ends.
> >
> > This patch avoids this problem by appending to the list of data
> > structures so that they are processed in FIFO order, and so
> tree_node
> > gets handled in gtype-desc.o.
> >
> > Tested x86_64-pc-linux-gnu, OK for trunk?
> 
> > commit 487a1c95c0d3169b2041942ff4f8d71c9ff689eb
> > Author: Jason Merrill 
> > Date:   Wed Oct 26 23:12:23 2016 -0400
> >
> > * gengtype.c (new_structure): Append to structures list.
> >
> > (find_structure): Likewise.
> 
> Please remove the blank line in the ChangeLog.
> 
> When looking at the differences it creates, it is hard, because
> all the generated files have all the functions emitted in reverse order
> now
> from what it used to be, so I only looked at files where the size
> changed,
> and that is beyond gtype.state only in my case gt-tree-phinodes.h
> which lost
> void
> gt_ggc_mx (struct gimple *& x)
> {
>   if (x)
> gt_ggc_mx_gimple ((void *) x);
> }
> and
> void
> gt_pch_nx (struct gimple *& x)
> {
>   if (x)
> gt_pch_nx_gimple ((void *) x);
> }
> and gtype-desc.c which didn't contain those but now it does (for
> gtype-desc.c it is hard to find out due to the reordering what else
> has changed, but as gt-tree-phinodes.h shrunk by 170 characters and
> gtype-desc.c grew by 170 characters, I'd think it is all that changed).
> I believe those routines belong to gtype-desc.c, that is where similar
> ones for tree_node, etc. are, tree-phinodes.h certainly isn't the header
> that defines gimple.
> 
> So I think this patch is ok for trunk.  Thanks.
> 

Hi -- This patch caused breakage for the MIPS port while compiling 
gcc/config/mips.c:

In file included from 
/scratch/cmoore/mips-sde-elf-upstream/src/gcc-trunk-6/gcc/hash-table.h:561:0,
 from 
/scratch/cmoore/mips-sde-elf-upstream/src/gcc-trunk-6/gcc/coretypes.h:351,
 from 
/scratch/cmoore/mips-sde-elf-upstream/src/gcc-trunk-6/gcc/config/mips/mips.c:26:
/scratch/cmoore/mips-sde-elf-upstream/src/gcc-trunk-6/gcc/hash-map.h: In 
instantiation of 'static void hash_map< , 
,  
>::hash_entry::ggc_mx(hash_map< , 
,  >::hash_entry&) [with KeyId 
= nofree_string_hash; Value = rtx_def*; Traits = 
simple_hashmap_traits]':
/scratch/cmoore/mips-sde-elf-upstream/src/gcc-trunk-6/gcc/hash-table.h:1029:17: 
  required from 'void gt_ggc_mx(hash_table*) [with E = 
hash_map::hash_entry]'
/scratch/cmoore/mips-sde-elf-upstream/src/gcc-trunk-6/gcc/hash-map.h:251:13:   
required from 'void gt_ggc_mx(hash_map*) [with K = nofree_string_hash; 
V = rtx_def*; H = 
simple_hashmap_traits]'
./gt-mips.h:38:19:   required from here
/scratch/cmoore/mips-sde-elf-upstream/src/gcc-trunk-6/gcc/hash-map.h:62:12: 
error: no matching function for call to 'gt_ggc_mx(rtx_def*&)'
  gt_ggc_mx (e.m_value);
^
... etc

I configured with --target=mips-sde-elf, but I do have some local multilib 
definitions for that target.  This ought to reproduce with mti-elf as well.
Will you please fix or revert?

Thanks,
Catherine

[Bug fortran/78351] comma not terminating READ of formatted input field - ok in 4.1.7, not 4.4.7- maybe related to 25419?

[kevin.b.beard at nasa dot gov]

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

--- Comment #13 from Dr. Kevin B. Beard  ---
Hi,

Thanks for looking at this.  I'm sorry to say I don't have access to the
official F77 standards,
perhaps you could send me a copy of the whole?   The section you quoted doesn't
seems to
to exclude the comma-terminated behavior I've always seen, and it has been
widely used
by many many programmers throughout the community over the years.

I've always been told and believed that a comma terminated a numeric field; but
w/o
access to the standards I can't point to the line that says it must.

What I'd like to see is that is that newer gfortran versions support its
previous (and every
other FORTRAN compiler I've tested) behavior.

The flag "-std=legacy" does not restore the previous behavior, and I've found
no option
in the newer gfortrans that does.

$> cat x1.f
  character*80 s
   s= '1,2,3'
   READ(s,'(2i10)') i,j
   write(6,'(2i10)') i,j
   end

$> gfortran --version
GNU Fortran (GCC) 4.4.7 20120313 (Red Hat 4.4.7-16)
Copyright (C) 2010 Free Software Foundation, Inc.

$> gfortran -std=legacy -o x1 x1.f
$> ./x1
At line 3 of file x1.f
Fortran runtime error: Bad value during integer read

vs:

$> gfortran ---version
GNU Fortran (GCC) 4.1.2 20080704 (Red Hat 4.1.2-55)
Copyright (C) 2007 Free Software Foundation, Inc.

$> gfortran -o x1 x1.f
$> ./x1
  1 2

$> g77 --version
GNU Fortran (GCC) 3.4.6 20060404 (Red Hat 3.4.6-4.1)
Copyright (C) 2006 Free Software Foundation, Inc.

$> g77 -o x1_g77 x1.f
$> ./x1_g77
1   2

$> ifort --version
ifort (IFORT) 16.0.3 20160415
Copyright (C) 1985-2016 Intel Corporation.  All rights reserved.

$> ifort -o x1_ifort x1.f
$> ./x1_ifort
 1 2

What I'd like to see is to restore gfortran's previous behavior that
it's had since it came out.

Thanks again for looking into this,
Kevin

--
Dr. Kevin B. Beard, Lockheed Martin Corporation
kevin.b.be...@nasa.gov
281-244-8534
room 548C, building 45, NASA Johnson Space Center
US Mail: Kevin B. Beard, bldg 45, mail code Wyle/OPS/45, P.O.Box 58487,
Houston, TX 77258


From: sgk at troutmask dot apl.washington.edu [gcc-bugzi...@gcc.gnu.org]
Sent: Tuesday, November 15, 2016 6:06 PM
To: Beard, Kevin B. (JSC-SD2)[WYLE LABORATORIES, INC.]
Subject: [Bug fortran/78351] comma not terminating READ of formatted input
field - ok in 4.1.7, not 4.4.7- maybe related to 25419?

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

--- Comment #7 from Steve Kargl  ---
On Tue, Nov 15, 2016 at 10:51:41PM +, kevin.b.beard at nasa dot gov wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78351
>
> --- Comment #5 from Dr. Kevin B. Beard  ---
> I've always understood that a comma will terminate a FORTRAN field - for
> example:
>
> https://docs.oracle.com/cd/E19957-01/805-4939/z4000743a36d/index.html
>
> Am I misunderstanding the F77 standard?

Yes. If you read the text at the above URL, you find "The I/O system
is just being more lenient than described in the FORTRAN Standard."
The Fortran 77 standard contains

13.2.1 Edit Descriptors

An edit descriptor is either a repeatable edit descriptor or
a nonrepeatable edit descriptor.

The forms of a repeatable edit descriptor are:
Iw
Iw.m
...
where:
I, F, E, D, G, L, and A indicate the manner of editing

w and e are nonzero, unsigned, integer constants

d and m are unsigned integer constants

13.5 Editing

A field is a part of a record that is read on input or written
on output when format control processes one I, F, E, D, G, L,
A, H, or apostrophe edit descriptor. The field width is the
size in characters of the field.


13.5.9 Numeric Editing

The I, F, E, D, and G edit descriptors are used to specify
input/output of integer, real, double precision, and complex
data.

The following general rules apply:

(1) On input, leading blanks are not significant. The
interpretation of blanks, other than leading blanks, is
determined by a combination of any BLANK= specifier and any
BN or BZ blank control that is currently in effect for the
unit (13.5.8). Plus signs may be omitted. A field of all
blanks is considered to be zero.

(2) On input, with F, E, D, and G editing, a decimal point
appearing in the input field overrides the portion of an edit
descriptor that specifies the decimal point location. The input
field may have more digits than the processor uses to approximate
the value of the datum.

(3) On output, ...

(4) On output, ...

(5) On output, ...

13.5.9.1 Integer Editing

The Iw and Iw.m edit descriptors indicate that the field to be
edited occupies w positions. The specified input/output list item
must be of type integer. On input, the specified list item will
become defined with an integer datum. On output, the specified list
item must be defined with an integer datum.

On input, an Iw.m edit descriptor is treated identically to an Iw

libgo patch committed: remove runtime1.goc

[Ian Lance Taylor]

This patch to libgo replaces runtime/runtime1.goc with Go and C code.
This is a step toward eliminating goc2c.

This drops the exported parfor code; it was needed for tests in the
past, but no longer is. The Go 1.7 runtime no longer uses parfor.

Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu.  Committed
to mainline.

Ian
Index: gcc/go/gofrontend/MERGE
===
--- gcc/go/gofrontend/MERGE (revision 242494)
+++ gcc/go/gofrontend/MERGE (working copy)
@@ -1,4 +1,4 @@
-31ff8c31d33c3e77cae4fd55445f12825eb92af5
+d9189ebc139ff739af956094626ccc5eb92c3091
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
Index: libgo/Makefile.am
===
--- libgo/Makefile.am   (revision 242060)
+++ libgo/Makefile.am   (working copy)
@@ -485,7 +485,6 @@ runtime_files = \
runtime/yield.c \
$(rtems_task_variable_add_file) \
malloc.c \
-   runtime1.c \
$(runtime_getncpu_file)
 
 goc2c.$(OBJEXT): runtime/goc2c.c
@@ -498,10 +497,6 @@ malloc.c: $(srcdir)/runtime/malloc.goc g
./goc2c $< > $@.tmp
mv -f $@.tmp $@
 
-runtime1.c: $(srcdir)/runtime/runtime1.goc goc2c
-   ./goc2c $< > $@.tmp
-   mv -f $@.tmp $@
-
 %.c: $(srcdir)/runtime/%.goc goc2c
./goc2c $< > $@.tmp
mv -f $@.tmp $@
Index: libgo/go/runtime/debug.go
===
--- libgo/go/runtime/debug.go   (revision 241341)
+++ libgo/go/runtime/debug.go   (working copy)
@@ -4,6 +4,11 @@
 
 package runtime
 
+import (
+   "runtime/internal/atomic"
+   "unsafe"
+)
+
 // GOMAXPROCS sets the maximum number of CPUs that can be executing
 // simultaneously and returns the previous setting. If n < 1, it does not
 // change the current setting.
@@ -19,10 +24,18 @@ func GOMAXPROCS(n int) int
 func NumCPU() int
 
 // NumCgoCall returns the number of cgo calls made by the current process.
-func NumCgoCall() int64
+func NumCgoCall() int64 {
+   var n int64
+   for mp := (*m)(atomic.Loadp(unsafe.Pointer(allm(; mp != nil; mp = 
mp.alllink {
+   n += int64(mp.ncgocall)
+   }
+   return n
+}
 
 // NumGoroutine returns the number of goroutines that currently exist.
-func NumGoroutine() int
+func NumGoroutine() int {
+   return int(gcount())
+}
 
 // Get field tracking information.  Only fields with a tag go:"track"
 // are tracked.  This function will add every such field that is
Index: libgo/go/runtime/error.go
===
--- libgo/go/runtime/error.go   (revision 241341)
+++ libgo/go/runtime/error.go   (working copy)
@@ -133,7 +133,10 @@ type stringer interface {
String() string
 }
 
-func typestring(interface{}) string
+func typestring(x interface{}) string {
+   e := efaceOf()
+   return *e._type.string
+}
 
 // For calling from C.
 // Prints an argument passed to panic.
Index: libgo/go/runtime/export_test.go
===
--- libgo/go/runtime/export_test.go (revision 241427)
+++ libgo/go/runtime/export_test.go (working copy)
@@ -21,11 +21,10 @@ import (
 //var F64toint = f64toint
 //var Sqrt = sqrt
 
-func golockedOSThread() bool
-
 var Entersyscall = entersyscall
 var Exitsyscall = exitsyscall
-var LockedOSThread = golockedOSThread
+
+// var LockedOSThread = lockedOSThread
 
 // var Xadduintptr = xadduintptr
 
@@ -44,29 +43,6 @@ func LFStackPop(head *uint64) *LFNode {
return (*LFNode)(unsafe.Pointer(lfstackpop(head)))
 }
 
-type ParFor struct {
-   body   func(*ParFor, uint32)
-   done   uint32
-   Nthr   uint32
-   thrseq uint32
-   Cntuint32
-   wait   bool
-}
-
-func newParFor(nthrmax uint32) *ParFor
-func parForSetup(desc *ParFor, nthr, n uint32, wait bool, body func(*ParFor, 
uint32))
-func parForDo(desc *ParFor)
-func parForIters(desc *ParFor, tid uintptr) (uintptr, uintptr)
-
-var NewParFor = newParFor
-var ParForSetup = parForSetup
-var ParForDo = parForDo
-
-func ParForIters(desc *ParFor, tid uint32) (uint32, uint32) {
-   begin, end := parForIters(desc, uintptr(tid))
-   return uint32(begin), uint32(end)
-}
-
 func GCMask(x interface{}) (ret []byte) {
return nil
 }
Index: libgo/go/runtime/extern.go
===
--- libgo/go/runtime/extern.go  (revision 241341)
+++ libgo/go/runtime/extern.go  (working copy)
@@ -274,13 +274,11 @@ func SetFinalizer(obj interface{}, final
 // the actual system call.
 func KeepAlive(interface{})
 
-func getgoroot() string
-
 // GOROOT returns the root of the Go tree.
 // It uses the GOROOT environment variable, if set,
 // or else the root used during the Go build.
 func GOROOT() string {
-   s := getgoroot()
+   s := gogetenv("GOROOT")
if 

Re: [RFC PATCH] avoid printing type suffix with %E

[Jeff Law]

On 10/26/2016 10:37 AM, Martin Sebor wrote:

When formatting an integer constant using the %E directive GCC
includes a suffix that indicates its type.  This can perhaps be
useful in some situations but in my experience it's distracting
and gets in the way when writing tests.

Here's an example:

  $ cat b.c && gcc b.c
  constexpr __SIZE_TYPE__ x = 2;

  enum E: bool { e = x };
  b.c:3:20: error: enumerator value 2ul is outside the range of
underlying type ‘bool’
   enum E: bool { e = x };
  ^

Notice the "2ul" in the error message.

As far as I can tell, Clang avoids printing the suffix and I think
it would be nice if the GCC pretty printer made it possible to avoid
it as well.

The attached patch implements one such approach by having the pretty
printer recognize the space format flag to suppress the type suffix,
so "%E" still prints the suffix but "% E" does not.  I did this to
preserve the existing output but I think it would be nicer to avoid
printing the suffix with %E and treat (for instance) the pound sign
as a request to add the suffix.  I have tested the attached patch
but not the alternative.

Does anyone have any comments/suggestions for which of the two
approaches would be preferable (or what I may have missed here)?
I CC David as the diagnostic maintainer.
I'm having a hard time seeing how this is a significant issue, even when 
writing tests.


It also seems to me that relaying the type of the constant as a suffix 
would help in cases that aren't so obvious.


What am I missing?

Jeff

[Bug preprocessor/78324] Valgrind issues seen with gcc.dg/tree-ssa/builtin-sprintf-2.c

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

Re: New option -flimit-function-alignment

[Jeff Law]

On 10/14/2016 12:28 PM, Bernd Schmidt wrote:

On 10/12/2016 09:27 PM, Denys Vlasenko wrote:

Yes, something like "if max_skip >= func_size, temporarily lower
max_skip to func_size-1" (because otherwise we can create padding
bigger-or-equal to the entire function in size, which is stupid
- it's better to just put the function in that space).

This would be a nice.


That would be this patch. Bootstrapped and tested on x86_64-linux, ok?


Bernd

limit-align-v2b.diff


gcc/
* common.opt (flimit-function-alignment): New.
* doc/invoke.texi (-flimit-function-alignment): Document.
* emit-rtl.h (struct rtl_data): Add max_insn_address field.
* final.c (shorten_branches): Set it.
* varasm.c (assemble_start_function): Limit alignment if
requested.

gcc/testsuite/
* gcc.target/i386/align-limit.c: New test.

OK.  Sorry for the long delay.

jeff

[Bug rtl-optimization/50217] combine pass generated wrong code for unsigned char comparison on MIPS

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
No feedback in over 4 years closing.

[PATCH] Handle --enable-checking={yes,assert,release} in libcpp (PR bootstrap/72823)

[Jakub Jelinek]

Hi!

As mentioned in the PR, libcpp uses gcc_assert in a couple of places,
but guards it with ENABLE_ASSERT_CHECKING macro that is never defined
in libcpp.

This patch arranges for it to be defined if ENABLE_ASSERT_CHECKING
is going to be defined in gcc subdir.

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

2016-11-16  Jakub Jelinek  

PR bootstrap/72823
* configure.ac (ENABLE_ASSERT_CHECKING): Define if gcc configure
would define that macro.
* configure: Regenerated.
* config.in: Regenerated.

--- libcpp/configure.ac.jj  2016-05-20 12:44:36.0 +0200
+++ libcpp/configure.ac 2016-11-15 16:40:16.753842880 +0100
@@ -152,9 +152,11 @@ for check in release $ac_checking_flags
 do
case $check in
# these set all the flags to specific states
-   yes|all) ac_checking=1 ; ac_valgrind_checking= ;;
-   no|none|release) ac_checking= ; ac_valgrind_checking= ;;
+   yes|all) ac_checking=1 ; ac_assert_checking=1 ; ac_valgrind_checking= ;;
+   no|none) ac_checking= ; ac_assert_checking= ; ac_valgrind_checking= ;;
+   release) ac_checking= ; ac_assert_checking=1 ; ac_valgrind_checking= ;;
# these enable particular checks
+   assert) ac_assert_checking=1 ;;
misc) ac_checking=1 ;;
valgrind) ac_valgrind_checking=1 ;;
# accept
@@ -170,6 +172,11 @@ else
   AC_DEFINE(CHECKING_P, 0)
 fi
 
+if test x$ac_assert_checking != x ; then
+  AC_DEFINE(ENABLE_ASSERT_CHECKING, 1,
+[Define if you want assertions enabled.  This is a cheap check.])
+fi
+
 if test x$ac_valgrind_checking != x ; then
   AC_DEFINE(ENABLE_VALGRIND_CHECKING, 1,
 [Define if you want to workaround valgrind (a memory checker) warnings about
--- libcpp/configure.jj 2016-05-20 12:44:36.0 +0200
+++ libcpp/configure2016-11-15 16:40:35.331607679 +0100
@@ -7288,9 +7288,11 @@ for check in release $ac_checking_flags
 do
case $check in
# these set all the flags to specific states
-   yes|all) ac_checking=1 ; ac_valgrind_checking= ;;
-   no|none|release) ac_checking= ; ac_valgrind_checking= ;;
+   yes|all) ac_checking=1 ; ac_assert_checking=1 ; ac_valgrind_checking= ;;
+   no|none) ac_checking= ; ac_assert_checking= ; ac_valgrind_checking= ;;
+   release) ac_checking= ; ac_assert_checking=1 ; ac_valgrind_checking= ;;
# these enable particular checks
+   assert) ac_assert_checking=1 ;;
misc) ac_checking=1 ;;
valgrind) ac_valgrind_checking=1 ;;
# accept
@@ -7308,6 +7310,12 @@ else
 
 fi
 
+if test x$ac_assert_checking != x ; then
+
+$as_echo "#define ENABLE_ASSERT_CHECKING 1" >>confdefs.h
+
+fi
+
 if test x$ac_valgrind_checking != x ; then
 
 $as_echo "#define ENABLE_VALGRIND_CHECKING 1" >>confdefs.h
--- libcpp/config.in.jj 2016-05-20 12:44:36.0 +0200
+++ libcpp/config.in2016-11-15 16:40:38.0 +0100
@@ -14,6 +14,9 @@
 /* Define to 1 if using `alloca.c'. */
 #undef C_ALLOCA
 
+/* Define if you want assertions enabled. This is a cheap check. */
+#undef ENABLE_ASSERT_CHECKING
+
 /* Define to enable system headers canonicalization. */
 #undef ENABLE_CANONICAL_SYSTEM_HEADERS
 

Jakub

[committed] Fix ICE with omp for broken_loop (PR fortran/78299)

[Jakub Jelinek]

Hi!

When broken_loop is true (i.e. the OMP_FOR body doesn't return),
loop->header doesn't have to be equal to body_bb, but it makes no sense to
verify it.  We aren't adding any loop in that case anyway.

Bootstrapped/regtested on x86_64-linux and i686-linux, committed to trunk.

2016-11-16  Jakub Jelinek  

PR fortran/78299
* omp-low.c (expand_omp_for_static_nochunk): Don't assert
that loop->header == body_bb if broken_loop.

* gfortran.dg/gomp/pr78299.f90: New test.

--- gcc/omp-low.c.jj2016-11-10 12:34:12.0 +0100
+++ gcc/omp-low.c   2016-11-16 09:10:18.938969535 +0100
@@ -9685,7 +9685,7 @@ expand_omp_for_static_nochunk (struct om
   struct loop *loop = body_bb->loop_father;
   if (loop != entry_bb->loop_father)
 {
-  gcc_assert (loop->header == body_bb);
+  gcc_assert (broken_loop || loop->header == body_bb);
   gcc_assert (broken_loop
  || loop->latch == region->cont
  || single_pred (loop->latch) == region->cont);
--- gcc/testsuite/gfortran.dg/gomp/pr78299.f90.jj   2016-11-16 
09:15:46.282848093 +0100
+++ gcc/testsuite/gfortran.dg/gomp/pr78299.f90  2016-11-16 09:15:15.0 
+0100
@@ -0,0 +1,55 @@
+! PR fortran/78299
+! { dg-do compile }
+! { dg-additional-options "-fcheck=bounds" }
+
+program pr78299
+  integer, parameter :: n = 8
+  integer :: i, j
+  real :: x(n), y(n)
+  x = 1.0
+  y = 2.0
+  do j = 1, 9
+!$omp parallel workshare
+!$omp parallel default(shared)
+!$omp do
+do i = 1, n
+  x(i) = x(i) * y(9)   ! { dg-warning "is out of bounds" }
+end do
+!$omp end do
+!$omp end parallel
+!$omp end parallel workshare
+  end do
+  do j = 1, 9
+!$omp parallel workshare
+!$omp parallel default(shared)
+!$omp do schedule(static)
+do i = 1, n
+  x(i) = x(i) * y(9)   ! { dg-warning "is out of bounds" }
+end do
+!$omp end do
+!$omp end parallel
+!$omp end parallel workshare
+  end do
+  do j = 1, 9
+!$omp parallel workshare
+!$omp parallel default(shared)
+!$omp do schedule(static, 2)
+do i = 1, n
+  x(i) = x(i) * y(9)   ! { dg-warning "is out of bounds" }
+end do
+!$omp end do
+!$omp end parallel
+!$omp end parallel workshare
+  end do
+  do j = 1, 9
+!$omp parallel workshare
+!$omp parallel default(shared)
+!$omp do schedule(dynamic, 3)
+do i = 1, n
+  x(i) = x(i) * y(9)   ! { dg-warning "is out of bounds" }
+end do
+!$omp end do
+!$omp end parallel
+!$omp end parallel workshare
+  end do
+end

Jakub

[Bug fortran/78299] [6/7 Regression] ICE in expand_omp_for_static_nochunk, at omp-low.c:9622

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Wed Nov 16 18:19:09 2016
New Revision: 242507

URL: https://gcc.gnu.org/viewcvs?rev=242507=gcc=rev
Log:
PR fortran/78299
* omp-low.c (expand_omp_for_static_nochunk): Don't assert
that loop->header == body_bb if broken_loop.

* gfortran.dg/gomp/pr78299.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/gomp/pr78299.f90
Modified:
trunk/gcc/ChangeLog
trunk/gcc/omp-low.c
trunk/gcc/testsuite/ChangeLog

Re: [PATCH, GCC/ARM] Make arm_feature_set agree with type of FL_* macros

[Thomas Preudhomme]

Hi,

I've rebased the patch to make arm_feature_set agree with type of FL_* macros on 
top of trunk rather than on top of the optional -mthumb patch. That involved 
doing the changes to gcc/config/arm/arm-protos.h rather than 
gcc/config/arm/arm-flags.h. I also took advantage of the fact that each line is 
changed to change the indentation to tabs and add dots in comments missing one.


For reference, please find below the original patch description:

Currently arm_feature_set is defined in gcc/config/arm/arm-flags as an array of 
2 unsigned long. However, the flags stored in these two entries are (signed) 
int, being combinations of bits set via expression of the form 1 << bitno. This 
creates 3 issues:


1) undefined behavior when setting the msb (1 << 31)
2) undefined behavior when storing a flag with msb set (negative int) into one 
of the unsigned array entries (positive int)

3) waste of space since the top 32 bits of each entry is not used

This patch changes the definition of FL_* macro to be unsigned int by using the 
form 1U << bitno instead and changes the definition of arm_feature_set to be an 
array of 2 unsigned (int) entries.


*** gcc/ChangeLog ***

2016-10-15  Thomas Preud'homme  

* config/arm/arm-protos.h (FL_NONE, FL_ANY, FL_CO_PROC, FL_ARCH3M,
FL_MODE26, FL_MODE32, FL_ARCH4, FL_ARCH5, FL_THUMB, FL_LDSCHED,
FL_STRONG, FL_ARCH5E, FL_XSCALE, FL_ARCH6, FL_VFPV2, FL_WBUF,
FL_ARCH6K, FL_THUMB2, FL_NOTM, FL_THUMB_DIV, FL_VFPV3, FL_NEON,
FL_ARCH7EM, FL_ARCH7, FL_ARM_DIV, FL_ARCH8, FL_CRC32, FL_SMALLMUL,
FL_NO_VOLATILE_CE, FL_IWMMXT, FL_IWMMXT2, FL_ARCH6KZ, FL2_ARCH8_1,
FL2_ARCH8_2, FL2_FP16INST): Reindent comment, add final dot when
missing and make value unsigned.
(arm_feature_set): Use unsigned entries instead of unsigned long.


Bootstrapped on arm-linux-gnueabihf targeting Thumb-2 state.

Is this ok for trunk?

Best regards,

Thomas

On 14/11/16 18:56, Thomas Preudhomme wrote:

My apologize, I realized when trying to apply the patch that I wrote it on top
of the optional -mthumb patch instead of the reverse. I'll rebase it to not
screw up bisect.

Best regards,

Thomas

On 14/11/16 14:47, Kyrill Tkachov wrote:


On 14/11/16 14:07, Thomas Preudhomme wrote:

Hi,

Currently arm_feature_set is defined in gcc/config/arm/arm-flags as an array
of 2 unsigned long. However, the flags stored in these two entries are
(signed) int, being combinations of bits set via expression of the form 1 <<
bitno. This creates 3 issues:

1) undefined behavior when setting the msb (1 << 31)
2) undefined behavior when storing a flag with msb set (negative int) into one
of the unsigned array entries (positive int)
3) waste of space since the top 32 bits of each entry is not used

This patch changes the definition of FL_* macro to be unsigned int by using
the form 1U << bitno instead and changes the definition of arm_feature_set to
be an array of 2 unsigned (int) entries.

Bootstrapped on arm-linux-gnueabihf targeting Thumb-2 state.

Is this ok for trunk?



Ok.
Thanks,
Kyrill


Best regards,

Thomas


diff --git a/gcc/config/arm/arm-protos.h b/gcc/config/arm/arm-protos.h
index 95bae5ef57ba4c433c0cce8e0c197959abdf887b..5cee7718554886982f535da2e9baa5015da609e4 100644
--- a/gcc/config/arm/arm-protos.h
+++ b/gcc/config/arm/arm-protos.h
@@ -351,50 +351,51 @@ extern bool arm_is_constant_pool_ref (rtx);
 /* Flags used to identify the presence of processor capabilities.  */
 
 /* Bit values used to identify processor capabilities.  */
-#define FL_NONE	  (0)	  /* No flags.  */
-#define FL_ANY	  (0x)/* All flags.  */
-#define FL_CO_PROC(1 << 0)/* Has external co-processor bus */
-#define FL_ARCH3M (1 << 1)/* Extended multiply */
-#define FL_MODE26 (1 << 2)/* 26-bit mode support */
-#define FL_MODE32 (1 << 3)/* 32-bit mode support */
-#define FL_ARCH4  (1 << 4)/* Architecture rel 4 */
-#define FL_ARCH5  (1 << 5)/* Architecture rel 5 */
-#define FL_THUMB  (1 << 6)/* Thumb aware */
-#define FL_LDSCHED(1 << 7)	  /* Load scheduling necessary */
-#define FL_STRONG (1 << 8)	  /* StrongARM */
-#define FL_ARCH5E (1 << 9)/* DSP extensions to v5 */
-#define FL_XSCALE (1 << 10)	  /* XScale */
-/* spare	  (1 << 11)	*/
-#define FL_ARCH6  (1 << 12)   /* Architecture rel 6.  Adds
-	 media instructions.  */
-#define FL_VFPV2  (1 << 13)   /* Vector Floating Point V2.  */
-#define FL_WBUF	  (1 << 14)	  /* Schedule for write buffer ops.
-	 Note: ARM6 & 7 derivatives only.  */
-#define FL_ARCH6K (1 << 15)   /* Architecture rel 6 K extensions.  */
-#define FL_THUMB2 (1 << 16)	  /* Thumb-2.  */
-#define FL_NOTM	  (1 << 17)	  /* Instructions not present in the 'M'
-	 profile.  */
-#define FL_THUMB_DIV  (1 << 18)	  /* Hardware divide (Thumb 

Re: [PATCH] Enable Intel AVX512_4FMAPS and AVX512_4VNNIW instructions

[Andrew Senkevich]

2016-11-16 19:21 GMT+03:00 Bernd Schmidt :
> On 11/15/2016 05:31 PM, Andrew Senkevich wrote:
>>
>> 2016-11-15 17:56 GMT+03:00 Jeff Law :
>>>
>>> On 11/15/2016 05:55 AM, Andrew Senkevich wrote:


 2016-11-11 14:16 GMT+03:00 Uros Bizjak :
>
>
> --- a/gcc/genmodes.c
> +++ b/gcc/genmodes.c
> --- a/gcc/init-regs.c
> +++ b/gcc/init-regs.c
> --- a/gcc/machmode.h
> +++ b/gcc/machmode.h
>
> These are middle-end changes, you will need a separate review for
> these.



 Who could review these changes?
>>>
>>>
>>> I can.  I likely dropped the message because it looked x86 specific, so
>>> if
>>> you could resend it'd be appreciated.
>>
>>
>> Attached (diff with previous only in fixed comments typos).
>
>
> Next time please split middle-end changes out from target-related stuff and
> send them separately.

Ok.

> These ones are OK.
>
>
> Bernd

Thanks!

Who could commit it?


--
WBR,
Andrew

Re: [PATCH] enhance buffer overflow warnings (and c/53562)

[Jeff Law]

[ I'm catching up on a variety of things...  So apologies if y'all
  have settled these issues. ]

On 11/02/2016 01:32 PM, Jakub Jelinek wrote:

But obviously not all levels of the warning can/should be enabled
with -Wall/-Werror.  There are cases which are worth warning by default
(the case where we want to inform the user if you reach this stmt,
you'll get your program killed (will call __chk_fail)) is something
that ought like before be enabled by default; can have a warning
switch users can disable.
Then there is the case where there is a sure buffer overflow (not using
-D_FORTIFY_SOURCE, but still __bos (, 0) tells the buffer is too short,
and it is unconditional (no tricks with PHIs where one path has short
and another part has long size).  This is something that is useful
in -Wall.
The rest I'm very doubtful about even for -Wextra.
I would hesitate on distinguishing between something that flows via a 
PHI vs something that is explicit in the IL.


It is entirely possible that an unrelated path isolation might take a 
PHI where one path is short and one long and split it into two paths. 
At that point they're both going to be explicit in the IL.  You'd then 
have to use something like global anticipability analysis to determine 
if they're executed unconditionally.


Jeff

Re: [PATCH] Fix NetBSD bootstrap

[Bernd Schmidt]

On 11/16/2016 06:12 PM, Krister Walfridsson wrote:

I'm the NetBSD maintainer, so I belive I don't need approval to commit
this. But I have been absent for a long time, so it makes sense for
someone to review at least this first patch.

Bootstrapped and tested on i386-unknown-netbsdelf6.1 and
x86_64-unknown-netbsd6.1.

OK to commit?


I'll take the position that you know best and do not need approval from 
someone else.



Bernd

[Bug libfortran/51119] MATMUL slow for large matrices

[tkoenig at gcc dot gnu.org]

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

--- Comment #46 from Thomas Koenig  ---
(In reply to Jerry DeLisle from comment #44)

> Yes I am aware of these. I was willing to live with them, but if it is a
> problem, we can remove those options easy enough.

I think it is no big deal, but on the whole I would prefer
not to have the warnings.

So, please go ahead and remove these options. The patch to do so
is either pre-approved or obvious and simple; it is your choice :-)

Re: [2/9] Encoding support for AArch64 DWARF operations

[Jason Merrill]

On Fri, Nov 11, 2016 at 1:33 PM, Jiong Wang  wrote:
> The encoding for new added AARCH64 DWARF operations.

This patch seems rather incomplete; I only see a change to
dwarf2out.c, which won't compile since the opcodes aren't defined
anywhere.

Jason

[Bug rtl-optimization/78378] [5/6/7 Regression] wrong code when combining shift + mult + zero_extend

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Scratch that, I've missed there the 8 SUBREG_BYTE.  That one is fine.
What is wrong is combine_simplify_rtx turning
(set (reg:SI 99 [ x ])
(and:SI (subreg:SI (truncate:HI (lshiftrt:TI (mult:TI (zero_extend:TI
(reg:DI 96))
(zero_extend:TI (reg:DI 98)))
(const_int 64 [0x40]))) 0)
(const_int 65535 [0x])))
into
(set (reg:SI 99 [ x ])
(zero_extend:SI (mult:HI (subreg:HI (reg:DI 96) 0)
(subreg:HI (reg:DI 98) 0

Re: Add SET_DECL_MODE

[Jeff Law]

On 11/16/2016 09:44 AM, Richard Sandiford wrote:

This may no longer be necessary with the current version
of the SVE patches, but it does at least make things consistent
with the TYPE_MODE/SET_TYPE_MODE split.

Tested on aarch64-linux-gnu and x86_64-linux-gnu.  OK to install?

Thanks,
Richard


[ This patch is part of the SVE series posted here:
  https://gcc.gnu.org/ml/gcc/2016-11/msg00030.html ]

gcc/ada/
2016-11-16  Richard Sandiford  
Alan Hayward  
David Sherwood  

* gcc-interface/utils.c (create_label_decl): Use SET_DECL_MODE.

gcc/c/
2016-11-16  Richard Sandiford  
Alan Hayward  
David Sherwood  

* c-decl.c (merge_decls): Use SET_DECL_MODE.
(make_label, finish_struct): Likewise.

gcc/cp/
2016-11-16  Richard Sandiford  
Alan Hayward  
David Sherwood  

* class.c (finish_struct_bits): Use SET_DECL_MODE.
(build_base_field_1, layout_class_type, finish_struct_1): Likewise.
* decl.c (make_label_decl): Likewise.
* pt.c (tsubst_decl): Likewise.

gcc/fortran/
2016-11-16  Richard Sandiford  
Alan Hayward  
David Sherwood  

* trans-common.c (build_common_decl): Use SET_DECL_MODE.
* trans-decl.c (gfc_build_label_decl): Likewise.
* trans-types.c (gfc_get_array_descr_info): Likewise.

gcc/lto/
2016-11-16  Richard Sandiford  
Alan Hayward  
David Sherwood  

* lto.c (offload_handle_link_vars): Use SET_DECL_MODE.

gcc/
2016-11-16  Richard Sandiford  
Alan Hayward  
David Sherwood  

* tree.h (SET_DECL_MODE): New macro.
* cfgexpand.c (avoid_deep_ter_for_debug): Use SET_DECL_MODE.
(expand_gimple_basic_block): Likewise.
* function.c (split_complex_args): Likeise.
* ipa-prop.c (ipa_modify_call_arguments): Likewise.
* omp-simd-clone.c (ipa_simd_modify_stmt_ops): Likewise.
* stor-layout.c (layout_decl, relayout_decl): Likewise.
(finish_bitfield_representative): Likewise.
* tree.c (make_node_stat): Likewise.
* tree-inline.c (remap_ssa_name): Likewise.
(tree_function_versioning): Likewise.
* tree-into-ssa.c (rewrite_debug_stmt_uses): Likewise.
* tree-sra.c (sra_ipa_reset_debug_stmts): Likewise.
* tree-ssa-ccp.c (optimize_atomic_bit_test_and): Likewise.
* tree-ssa-loop-ivopts.c (remove_unused_ivs): Likewise.
* tree-ssa.c (insert_debug_temp_for_var_def): Likewise.
* tree-streamer-in.c (unpack_ts_decl_common_value_fields): Likewise.
* varasm.c (make_debug_expr_from_rtl): Likewise.

libcc1/
2016-11-16  Richard Sandiford  
Alan Hayward  
David Sherwood  

* plugin.cc (plugin_build_add_field): Use SET_DECL_MODE.
I just lightly spot-checked this.  Seems like it should fit under hte 
obvious rule.  Ok for the trunk.


jeff

[Bug fortran/41539] [OOP] Calling function which takes CLASS: Rank comparison does not work

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|--- |4.7.0

[Bug fortran/44131] [OOP] Using polymorphism in modules unware of derived types fails at run-time

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 CC||janus at gcc dot gnu.org
   Target Milestone|--- |4.6.0

[Bug fortran/44863] [OOP] Fortran runtime error: internal error: bad hash value in dynamic dispatch

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|--- |4.6.0

[Bug fortran/44864] [OOP] ICE: Segmentation fault

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|--- |4.6.0

[Bug fortran/45795] [OOP] ICE in in gfc_add_component_ref plus bogus error message

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 CC||janus at gcc dot gnu.org
   Target Milestone|--- |4.6.0

[Bug fortran/49961] [OOP] type-bound function can not return a pointer of a array

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|--- |4.6.0

Re: [PATCH] Fix PR78305

[Richard Biener]

On November 16, 2016 5:22:17 PM GMT+01:00, Marc Glisse  
wrote:
>On Wed, 16 Nov 2016, Michael Matz wrote:
>
>> Hi,
>>
>> On Wed, 16 Nov 2016, Marc Glisse wrote:
>>
> The first sentence about ORing the sign bit sounds strange (except
>for a
> sign-magnitude representation). With 2's complement, INT_MIN is
>-2^31, the
> divisors are the 2^k and -(2^k). -2 * 2^30 yields INT_MIN, but
>your test
> misses -2 as a possible divisor. On the other hand, 0b100...001
>(aka
> -INT_MAX)
> is not a divisor of INT_MIN but your test says the reverse.

 Yeah, but it handled the testcase ;)  So I guess the easiest would
>be
 to check integer_pow2p (abs (TREE_OPERAND (t, 0)) then, thus
 wi::popcount (wi::abs (TREE_OPERAND (t, 0))) == 1?
>>>
>>> Looks good to me, thanks.
>>
>> An integer X is a power of two if and only if
>>  X & -X == 0  (&& X != 0 if you want to exclude zero)
>> which also nicely handles positive and negative numbers at the same
>time.
>> No need for popcounts or abs.
>
>There are bit tricks to test for powers of 2, but X & -X == 0 doesn't 
>quite work (X & -X == X is closer, but needs a tweak for negative 
>numbers). We could use
>wi::pow2_p (wi::abs (TREE_OPERAND (t, 0)))
>adding a new function pow2_p so it remains readable and we reduce the
>risk 
>of using the wrong bit trick...

Tree_pow2p uses wi::popcount 

Richard.

[Bug fortran/51791] [OOP] Failure to resolve typebound function call with base object in parentheses.

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 CC||janus at gcc dot gnu.org
   Target Milestone|--- |4.7.0

[Bug fortran/51207] [OOP] Mark __def_init_... as FL_PARAMETER

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|--- |4.7.0

[Bug fortran/51943] [OOP] ICE in conv_function_val

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 CC||janus at gcc dot gnu.org
   Target Milestone|--- |4.7.0

[Bug fortran/55935] [OOP] Fortran fronted has ADDR_EXPRs of FUNCTION_DECLs with bogus BLOCK

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|--- |4.8.0

[Bug fortran/56929] [OOP] [F08] ICE on dummy argument child class with coarray inside parent

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|--- |4.9.0

[Bug fortran/56845] [OOP] _vptr not set to declared type for CLASS + SAVE

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|--- |4.9.0

[Bug fortran/57145] [OOP] Faulty "Actual argument must be polymorphic" error

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 CC||janus at gcc dot gnu.org
   Target Milestone|--- |4.8.0

[Bug fortran/57456] [OOP] CLASS + CHARACTER ALLOCATE with typespec: For arrays, the typespec is ignored

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 CC||janus at gcc dot gnu.org
   Target Milestone|--- |5.0

[Bug fortran/57922] [OOP] Memory leak with allocatable polymorphics

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|--- |4.9.0

[Bug tree-optimization/78383] New: label as values ICE with C++ lambda

[SztfG at yandex dot ru]

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

Bug ID: 78383
   Summary: label as values ICE with C++ lambda
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: SztfG at yandex dot ru
  Target Milestone: ---

testcase:

int main()
{
auto f = [](void* ptr) { goto *ptr; };

f(&);

label:
return 0;
}

$ g++ -std=c++11 -O2 test.cpp 
test.cpp: In function ‘main()::’:
test.cpp:3:23: internal compiler error: Segmentation fault
  auto f = [](void* ptr) { goto *ptr; };
   ^

[Bug fortran/58947] [OOP] ICE on select type with non-polymorphic selector

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|--- |4.8.1

[Bug fortran/58658] [OOP] Pointer assignment to allocatable unlimited polymorphic accepted

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 CC||janus at gcc dot gnu.org
   Target Milestone|--- |4.9.0

[Bug fortran/60834] [OOP] ICE with ASSOCIATE construct (gimplify_var_or_parm_decl, at gimplify.c:1721)

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 CC||janus at gcc dot gnu.org
   Target Milestone|--- |4.9.1

PING [PATCH] enable -Wformat-length for dynamically allocated buffers (pr 78245)

[Martin Sebor]

I'm looking for a review of the patch below:

  https://gcc.gnu.org/ml/gcc-patches/2016-11/msg00779.html

Thanks

On 11/08/2016 05:09 PM, Martin Sebor wrote:

The -Wformat-length checker relies on the compute_builtin_object_size
function to determine the size of the buffer it checks for overflow.
The function returns either a size computed by the tree-object-size
pass for objects referenced by the __builtin_object_size intrinsic
(if it's used in the program) or it tries to compute it for a small
subset of expressions otherwise.  This subset doesn't include objects
allocated by either malloc or alloca, and so for those the function
returns "unknown" or (size_t)-1 in the case of -Wformat-length.  As
a consequence, -Wformat-length is unable to detect overflows
involving such objects.

The attached patch adds a new function, compute_object_size, that
uses the existing algorithms to compute and return the sizes of
allocated objects as well, as if they were referenced by
__builtin_object_size in the program source, enabling the
-Wformat-length checker to detect more buffer overflows.

Martin

PS The function makes use of the init_function_sizes API that is
otherwise unused outside the tree-object-size pass to initialize
the internal structures, but then calls fini_object_sizes to
release them before returning.  That seems wasteful because
the size of the same object or one related to it might need
to computed again in the context of the same function.  I
experimented with allocating and releasing the structures only
when current_function_decl changes but that led to crashes.
I suspect I'm missing something about the management of memory
allocated for these structures.  Does anyone have any suggestions
how to make this work?  (Do I perhaps need to allocate them using
a special allocator so they don't get garbage collected?)

[Bug fortran/60255] [OOP] Deferred character length variable at (1) cannot yet be associated with unlimited polymorphic entities

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|--- |4.9.3

[Bug fortran/60322] [OOP] Incorrect bounds on polymorphic dummy array

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|--- |6.0

[Bug fortran/60550] [OOP] ICE on factory design pattern

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|--- |4.9.1

[Bug fortran/63553] [OOP] Wrong code when assigning a CLASS to a TYPE

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 CC||janus at gcc dot gnu.org
   Target Milestone|--- |5.0

[Bug libfortran/78314] [aarch64] ieee_support_halting does not report unsupported fpu traps correctly

[nsz at gcc dot gnu.org]

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

nsz at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|--- |7.0
  Known to fail||5.4.0, 6.2.0

[Bug fortran/64589] [OOP] Linking error due to undefined integer symbol with unlimited polymorphism

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|--- |6.0

[Bug fortran/64674] [OOP] ICE in ASSOCIATE with class array

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|--- |6.0

[Bug fortran/67091] [OOP] Bad result for type-bound procedures returning pointers to the intrinsic function ASSOCIATED

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|--- |6.0

[PING] [PATCH, ARM] Further improve stack usage on sha512 (PR 77308)

[Bernd Edlinger]

Hi,

I'd like to ping for these two patches:

[PATCH, ARM] Further improve stack usage on sha512 (PR 77308)
https://gcc.gnu.org/ml/gcc-patches/2016-11/msg00523.html

[PATCH, ARM] Enable ldrd/strd peephole rules unconditionally
https://gcc.gnu.org/ml/gcc-patches/2016-11/msg00830.html


Thanks
Bernd.

[Bug libfortran/78314] [aarch64] ieee_support_halting does not report unsupported fpu traps correctly

[nsz at gcc dot gnu.org]

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

--- Comment #3 from nsz at gcc dot gnu.org ---
Author: nsz
Date: Wed Nov 16 17:27:04 2016
New Revision: 242505

URL: https://gcc.gnu.org/viewcvs?rev=242505=gcc=rev
Log:
[PR libgfortran/78314] Fix ieee_support_halting

ieee_support_halting only checked the availability of status
flags, not trapping support.  On some targets the later can
only be checked at runtime: feenableexcept reports if
enabling traps failed.

So check trapping support by enabling/disabling it.

Updated the test that enabled trapping to check if it is
supported.

gcc/testsuite/

PR libgfortran/78314
* gfortran.dg/ieee/ieee_6.f90: Use ieee_support_halting.

libgfortran/

PR libgfortran/78314
* config/fpu-glibc.h (support_fpu_trap): Use feenableexcept.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/ieee/ieee_6.f90
trunk/libgfortran/ChangeLog
trunk/libgfortran/config/fpu-glibc.h

[Bug fortran/64209] [OOP] runtime segfault with CLASS(*), INTENT(OUT) dummy argument

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|--- |5.0

[Bug fortran/60359] [OOP] symbol `__io_MOD___copy_character_1' is already defined

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|--- |4.9.0

[Bug fortran/59547] [OOP] Problem with using tbp specification function in multiple class procedures

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|--- |4.9.0

[Bug fortran/55855] [OOP] incorrect warning with procedure pointer component on pointer-valued base object

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|--- |4.8.0

[Bug fortran/49962] [OOP] ICE when using type-bound function returning vector

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|--- |4.5.4

[PATCH PR78114]Refine gfortran.dg/vect/fast-math-mgrid-resid.f

[Bin Cheng]

Hi,
Currently test gfortran.dg/vect/fast-math-mgrid-resid.f checks all predictive 
commoning opportunities for all possible loops.  This makes it fragile because 
vectorizer may peel the loop differently, as well as may choose different 
vector factors.  For example, on x86-solaris, vectorizer doesn't peel for 
prologue loop; for -march=haswell, the case is long time failed because vector 
factor is 4, while iteration distance of predictive commoning opportunity is 
smaller than 4.  This patch refines it by only checking if predictive commoning 
variable is created when vector factor is 2; or vectorization variable is 
created when factor is 4.  This works since we have only one main loop, and 
only one vector factor can be used.
Test result checked for various x64 targets.  Is it OK?

Thanks,
bin

gcc/testsuite/ChangeLog
2016-11-16  Bin Cheng  

PR testsuite/78114
* gfortran.dg/vect/fast-math-mgrid-resid.f: Refine test by
checking predictive commining variables in vectorized loop
wrto vector factor.diff --git a/gcc/testsuite/gfortran.dg/vect/fast-math-mgrid-resid.f 
b/gcc/testsuite/gfortran.dg/vect/fast-math-mgrid-resid.f
index 88238f9..3e5c4a4 100644
--- a/gcc/testsuite/gfortran.dg/vect/fast-math-mgrid-resid.f
+++ b/gcc/testsuite/gfortran.dg/vect/fast-math-mgrid-resid.f
@@ -1,6 +1,6 @@
 ! { dg-do compile }
 ! { dg-require-effective-target vect_double }
-! { dg-options "-O3 -fpredictive-commoning -fdump-tree-pcom-details" }
+! { dg-options "-O3 -fpredictive-commoning -fdump-tree-pcom" }
 
 
 *** RESID COMPUTES THE RESIDUAL:  R = V - AU
@@ -38,8 +38,9 @@ C
   RETURN
   END
 ! we want to check that predictive commoning did something on the
-! vectorized loop.
-! { dg-final { scan-tree-dump-times "Executing predictive commoning without 
unrolling" 1 "pcom" { target lp64 } } }
-! { dg-final { scan-tree-dump-times "Executing predictive commoning without 
unrolling" 2 "pcom" { target ia32 } } }
-! { dg-final { scan-tree-dump-times "Predictive commoning failed: no suitable 
chains" 0 "pcom" } }
-! { dg-final { scan-tree-dump-times "Loop iterates only 1 time, nothing to do" 
1 "pcom" } }
+! vectorized loop.  If vector factor is 2, the vectorized loop can
+! be predictive commoned, we check if predictive commoning variable
+! is created with vector(2) type;  if vector factor is 4, there is
+! no predictive commoning opportunity, we check if vector(4) variable
+! is created.  This works because only one vector factor can be used.
+! { dg-final { scan-tree-dump-times "vector\\(2\\) real\\(.*\\) 
vectp_u.*__lsm|vector\\(4\\) real\\(.*\\)" 1 "pcom" } }

[Bug fortran/46662] [OOP] gfortran accepts "CALL polymorphic%abstract_type%ppc()"

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|--- |4.6.0

Re: [PATCH] warn on overflow in calls to allocation functions (bugs 77531 and 78284)

[Martin Sebor]

Attached is an updated version of the patch that also adds attribute
alloc_size to the standard allocation built-ins (aligned_alloc,
alloca, malloc, calloc, and realloc) and handles alloca.

Besides that, I've renamed the option to -Walloc-size-larger-than
to make it less similar to -Walloca-larger-than.  It think the new
name works because the option works with the alloc_size attribute.
 Other suggestions are of course welcome.

I've left the alloc_max_size function in place until I receive some
feedback on it.

I've regression-tested the patch on x86_64 with a few issues.  The
biggest is that the -Walloc-zero option enabled by -Wextra causes
a number of errors during bootstrap due to invoking the XALLOCAVEC
macro with a zero argument.  The errors look valid to me (and I
got past them by temporarily changing the XALLOCAVEC macro to
always allocate at least one byte) but I haven't fixed the errors
yet.  I'll post a separate patch for those.   The other open issue
is that the new warning duplicates a small subset of the
-Walloca-larger-than warnings.  I expect removing the duplicates
to be straightforward.  I post this updated patch for review while
I work on the remaining issues.

Martin

On 11/13/2016 08:19 PM, Martin Sebor wrote:

Bug 77531 requests a new warning for calls to allocation functions
(those declared with attribute alloc_size(X, Y)) that overflow the
computation X * Z of the size of the allocated object.

Bug 78284 suggests that detecting and diagnosing other common errors
in calls to allocation functions, such as allocating more space than
SIZE_MAX / 2 bytes, would help prevent subsequent buffer overflows.

The attached patch adds two new warning options, -Walloc-zero and
-Walloc-larger-than=bytes that implement these two enhancements.
The patch is not 100% finished because, as it turns out, the GCC
allocation built-ins (malloc et al.) do not make use of the
attribute and so don't benefit from the warnings.  The tests are
also incomplete, and there's at least one bug in the implementation
I know about.

I'm posting the patch while stage 1 is still open and to give
a heads up on it and to get early feedback.  I expect completing
it will be straightforward.

Martin

PS The alloc_max_size function added in the patch handles sizes
specified using suffixes like KB, MB, etc.  I added that to make
it possible to specify sizes in excess of the maximum of INT_MAX
that (AFAIK) options that take integer arguments handle out of
the box.  It only belatedly occurred to me that the suffixes
are unnecessary if the option argument is handled using strtoull.
I can remove the suffix (as I suspect it will raise objections)
but I think that a general solution along these lines would be
useful to let users specify large byte sizes in other options
as well (such -Walloca-larger-than, -Wvla-larger-then).  Are
there any suggestions or preferences?



PR c/77531 - __attribute__((alloc_size(1,2))) could also warn on multiplication overflow
PR c/78284 - warn on malloc with very large arguments

include/ChangeLog:
	* libiberty.h (XALLOCAVEC): Make sure alloca argument is non-zero.

gcc/c-family/ChangeLog:

	PR c/77531
	PR c/78284
	* c.opt (-Walloc-zero, -Walloc-larger-than): New options.

gcc/ChangeLog:

	PR c/77531
	PR c/78284
	* builtin-attrs.def (ATTR_ALLOC_SIZE): New identifier tree.
	(ATTR_MALLOC_SIZE_1_NOTHROW_LIST): New attribute list.
	(ATTR_MALLOC_SIZE_1_NOTHROW_LEAF_LIST): Same.
	(ATTR_MALLOC_SIZE_1_2_NOTHROW_LEAF_LIST): Same.
	(ATTR_ALLOC_SIZE_2_NOTHROW_LEAF_LIST): Same.
	* builtins.c (expand_builtin_alloca): Call
	maybe_warn_alloc_args_overflow.
	* builtins.def (akigned_alloc, alloca, calloc, malloc, realloc):
	Add attribute alloc_size.
	* calls.h (maybe_warn_alloc_args_overflow): Declare.
	* calls.c (alloc_max_size): New function.
	(maybe_warn_alloc_args_overflow): Define.
	(initialize_argument_information): Diagnose overflow in functions
	declared with attaribute alloc_size.
	* doc/invoke.texi (Warning Options): Document -Walloc-zero and
	-Walloc-larger-than.

gcc/testsuite/ChangeLog:

	PR c/77531
	PR c/78284
	* gcc.dg/attr-alloc_size-3.c: New test.
	* gcc.dg/attr-alloc_size-4.c: New test.
	* gcc.dg/attr-alloc_size-5.c: New test.
	* gcc.dg/attr-alloc_size-6.c: New test.
	* gcc.dg/attr-alloc_size-7.c: New test.

diff --git a/gcc/builtin-attrs.def b/gcc/builtin-attrs.def
index 8dc59c9..2a58b31 100644
--- a/gcc/builtin-attrs.def
+++ b/gcc/builtin-attrs.def
@@ -83,6 +83,7 @@ DEF_LIST_INT_INT (5,6)
 #undef DEF_LIST_INT_INT
 
 /* Construct trees for identifiers.  */
+DEF_ATTR_IDENT (ATTR_ALLOC_SIZE, "alloc_size")
 DEF_ATTR_IDENT (ATTR_COLD, "cold")
 DEF_ATTR_IDENT (ATTR_CONST, "const")
 DEF_ATTR_IDENT (ATTR_FORMAT, "format")
@@ -150,6 +151,23 @@ DEF_ATTR_TREE_LIST (ATTR_SENTINEL_NOTHROW_LEAF_LIST, ATTR_SENTINEL,	\
 DEF_ATTR_TREE_LIST (ATTR_COLD_CONST_NORETURN_NOTHROW_LEAF_LIST, ATTR_CONST,\
 			ATTR_NULL, ATTR_COLD_NORETURN_NOTHROW_LEAF_LIST)
 
+/* Allocation functions like alloca and malloc whose first 

[PATCH Obvious]Adjust test string wrto update dump info for gcc.target/arm/ivopts-orig_biv-inc.c

[Bin Cheng]

Hi,
Dump information of IVOPT has been updated while test string 
gcc.target/arm/ivopts-orig_biv-inc.c is not.  This patch does this.  Test 
result checked on arm-none-eabi.  Commit as obvious?

Thanks,
bin

gcc/testsuite/ChangeLog
2016-11-16  Bin Cheng  

* gcc.target/arm/ivopts-orig_biv-inc.c: Adjust test string
according to updated dump info.diff --git a/gcc/testsuite/gcc.target/arm/ivopts-orig_biv-inc.c 
b/gcc/testsuite/gcc.target/arm/ivopts-orig_biv-inc.c
index f7129d3..94c7e5f 100644
--- a/gcc/testsuite/gcc.target/arm/ivopts-orig_biv-inc.c
+++ b/gcc/testsuite/gcc.target/arm/ivopts-orig_biv-inc.c
@@ -15,4 +15,4 @@ unsigned char * foo(unsigned char *ReadPtr)
  return ReadPtr;
 }
 
-/* { dg-final { scan-tree-dump-times "original biv" 2 "ivopts"} } */
+/* { dg-final { scan-tree-dump-times "Incr POS: orig biv" 2 "ivopts"} } */

[Bug fortran/69011] [6 Regression] [OOP] ICE in gfc_advance_chain for ALLOCATE with SOURCE

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 CC||janus at gcc dot gnu.org
   Target Milestone|--- |6.0

Re: [PATCH v2][PR libgfortran/78314] Fix ieee_support_halting

[FX]

> gcc/testsuite/
> 2016-11-16  Szabolcs Nagy  
> 
>   PR libgfortran/78314
>   * gfortran.dg/ieee/ieee_6.f90: Use ieee_support_halting.
> 
> libgfortran/
> 2016-11-16  Szabolcs Nagy  
> 
>   PR libgfortran/78314
>   * config/fpu-glibc.h (support_fpu_trap): Use feenableexcept.

OK to commit.

FX

[Bug fortran/60234] [4.9 Regression] [OOP] ICE in generate_finalization_wrapper at fortran/class.c:1883

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|--- |4.9.0

[Bug fortran/59941] [4.7 Regression] [OOP] ICE with polymorphic types

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|--- |4.7.4

[Bug fortran/58436] [4.9 Regression][OOP] ICE (segfault) in generate_finalization_wrapper for CLASS(*)

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 CC||janus at gcc dot gnu.org
   Target Milestone|--- |4.9.0

[Bug fortran/56385] [4.6/4.7/4.8 Regression] [OOP] ICE with allocatable function result in a procedure-pointer component

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|--- |4.6.4

RE: [PATCH] MIPS/GCC: Mark text contents as code or data

[Maciej W. Rozycki]

On Tue, 15 Nov 2016, Matthew Fortune wrote:

> I'm a little concerned the expected output tests may be fragile over
> time but let's wait and see.

 Indeed, but I'd rather see false negatives than false positives or no 
coverage at all.  And I hope the pieces of expected assembly quoted will 
help telling any false negatives and actual regressions apart very easily.

> OK to commit.

 Applied now, thanks for your review.

  Maciej

[PATCH] Fix NetBSD bootstrap

[Krister Walfridsson]

NetBSD fails bootstrap with
  stdatomic.h:55:17: error: unknown type name '__INT_LEAST8_TYPE__'
This is fixed by the following patch (only i386 and x86_64 for now. I'll
do the other ports after fixing some more issues -- the NetBSD support is
rather broken at the moment...)

I'm the NetBSD maintainer, so I belive I don't need approval to commit 
this. But I have been absent for a long time, so it makes sense for 
someone to review at least this first patch.


Bootstrapped and tested on i386-unknown-netbsdelf6.1 and
x86_64-unknown-netbsd6.1.

OK to commit?

   /Krister


2016-11-16  Krister Walfridsson  

* config/netbsd-stdint.h: New.
* config.gcc (i[34567]86-*-netbsd): Add netbsd-stdint.h to tm_file.
(x86_64-*-netbsd*): Likewise.Index: gcc/config/netbsd-stdint.h
===
--- gcc/config/netbsd-stdint.h  (nonexistent)
+++ gcc/config/netbsd-stdint.h  (working copy)
@@ -0,0 +1,55 @@
+/* Definitions for  types for NetBSD systems.
+   Copyright (C) 2016 Free Software Foundation, Inc.
+
+This file is part of GCC.
+
+GCC is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 3, or (at your option)
+any later version.
+
+GCC is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+GNU General Public License for more details.
+
+Under Section 7 of GPL version 3, you are granted additional
+permissions described in the GCC Runtime Library Exception, version
+3.1, as published by the Free Software Foundation.
+
+You should have received a copy of the GNU General Public License and
+a copy of the GCC Runtime Library Exception along with this program;
+see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
+.  */
+
+#define SIG_ATOMIC_TYPE   "int"
+
+#define INT8_TYPE "signed char"
+#define INT16_TYPE"short int"
+#define INT32_TYPE"int"
+#define INT64_TYPE(LONG_TYPE_SIZE == 64 ? "long int" : "long long int")
+#define UINT8_TYPE"unsigned char"
+#define UINT16_TYPE   "short unsigned int"
+#define UINT32_TYPE   "unsigned int"
+#define UINT64_TYPE   (LONG_TYPE_SIZE == 64 ? "long unsigned int" : "long 
long unsigned int")
+
+#define INT_LEAST8_TYPE   INT8_TYPE
+#define INT_LEAST16_TYPE  INT16_TYPE
+#define INT_LEAST32_TYPE  INT32_TYPE
+#define INT_LEAST64_TYPE  INT64_TYPE
+#define UINT_LEAST8_TYPE  UINT8_TYPE
+#define UINT_LEAST16_TYPE UINT16_TYPE
+#define UINT_LEAST32_TYPE UINT32_TYPE
+#define UINT_LEAST64_TYPE UINT64_TYPE
+
+#define INT_FAST8_TYPEINT32_TYPE
+#define INT_FAST16_TYPE   INT32_TYPE
+#define INT_FAST32_TYPE   INT32_TYPE
+#define INT_FAST64_TYPE   INT64_TYPE
+#define UINT_FAST8_TYPE   UINT32_TYPE
+#define UINT_FAST16_TYPE  UINT32_TYPE
+#define UINT_FAST32_TYPE  UINT32_TYPE
+#define UINT_FAST64_TYPE  UINT64_TYPE
+
+#define INTPTR_TYPE   (LONG_TYPE_SIZE == 64 ?  INT64_TYPE :  INT32_TYPE)
+#define UINTPTR_TYPE  (LONG_TYPE_SIZE == 64 ? UINT64_TYPE : UINT32_TYPE)
Index: gcc/config.gcc
===
--- gcc/config.gcc  (revision 242350)
+++ gcc/config.gcc  (working copy)
@@ -1455,11 +1455,11 @@
tm_file="${tm_file} i386/unix.h i386/att.h dbxelf.h elfos.h 
${fbsd_tm_file} i386/x86-64.h i386/freebsd.h i386/freebsd64.h"
;;
 i[34567]86-*-netbsdelf*)
-   tm_file="${tm_file} i386/unix.h i386/att.h dbxelf.h elfos.h netbsd.h 
netbsd-elf.h i386/netbsd-elf.h"
+   tm_file="${tm_file} i386/unix.h i386/att.h dbxelf.h elfos.h netbsd.h 
netbsd-stdint.h netbsd-elf.h i386/netbsd-elf.h"
extra_options="${extra_options} netbsd.opt netbsd-elf.opt"
;;
 x86_64-*-netbsd*)
-   tm_file="${tm_file} i386/unix.h i386/att.h dbxelf.h elfos.h netbsd.h 
netbsd-elf.h i386/x86-64.h i386/netbsd64.h"
+   tm_file="${tm_file} i386/unix.h i386/att.h dbxelf.h elfos.h netbsd.h 
netbsd-stdint.h netbsd-elf.h i386/x86-64.h i386/netbsd64.h"
extra_options="${extra_options} netbsd.opt netbsd-elf.opt"
;;
 i[34567]86-*-openbsd*)

[Bug fortran/52531] [OOP] Compilation fails with polymorphic dummy argument and OpenMP

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|--- |4.8.5

[Bug fortran/55905] [OOP] [F08] ICE for polymorphic dummy argument with an allocatable coarray component

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|--- |4.9.3

Re: [PATCH] warn on overflow in calls to allocation functions (bugs 77531 and 78284)

[Martin Sebor]

On 11/14/2016 01:34 PM, Eric Gallager wrote:

On 11/13/16, Martin Sebor  wrote:

Bug 77531 requests a new warning for calls to allocation functions
(those declared with attribute alloc_size(X, Y)) that overflow the
computation X * Z of the size of the allocated object.

Bug 78284 suggests that detecting and diagnosing other common errors
in calls to allocation functions, such as allocating more space than
SIZE_MAX / 2 bytes, would help prevent subsequent buffer overflows.

The attached patch adds two new warning options, -Walloc-zero and
-Walloc-larger-than=bytes that implement these two enhancements.
The patch is not 100% finished because, as it turns out, the GCC
allocation built-ins (malloc et al.) do not make use of the
attribute and so don't benefit from the warnings.  The tests are
also incomplete, and there's at least one bug in the implementation
I know about.

I'm posting the patch while stage 1 is still open and to give
a heads up on it and to get early feedback.  I expect completing
it will be straightforward.

Martin

PS The alloc_max_size function added in the patch handles sizes
specified using suffixes like KB, MB, etc.  I added that to make
it possible to specify sizes in excess of the maximum of INT_MAX
that (AFAIK) options that take integer arguments handle out of
the box.  It only belatedly occurred to me that the suffixes
are unnecessary if the option argument is handled using strtoull.
I can remove the suffix (as I suspect it will raise objections)
but I think that a general solution along these lines would be
useful to let users specify large byte sizes in other options
as well (such -Walloca-larger-than, -Wvla-larger-then).  Are
there any suggestions or preferences?




-Walloc-larger-than looks way too similar to -Walloca-larger-than; at
first I was confused as to why you were adding the same flag again
until I spotted the one letter difference. Maybe come up with a name
that looks more distinct? Just something to bikeshed about.


I agree.  I've renamed the option to -Walloc-size-larger-than.
I think that works because it goes along with attribute alloc_size.
I'm about to post an updated patch with that change (among others).

Thanks
Martin

[Bug target/78382] ICE when compiling on aarch64 in ILP32 mode with traditional thread local storage and pic

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-11-16
 CC||ktkachov at gcc dot gnu.org
   Target Milestone|--- |5.5
 Ever confirmed|0   |1
  Known to fail||4.9.4, 5.4.1, 6.2.1, 7.0

--- Comment #1 from ktkachov at gcc dot gnu.org ---
Confirmed on all versions that support -mabi=ilp32.

Re: [PATCH][PPC] Fix ICE using power9 with soft-float

[Michael Meissner]

On Wed, Nov 16, 2016 at 04:15:10PM +, Andrew Stubbs wrote:
> On 16/11/16 13:10, Michael Meissner wrote:
> >Yeah, SFmode and DFmode should not have the TARGET_{S,D}F_FPR checks.
> 
> So, I can safely resolve my initial problem by simply removing them?
> And that wouldn't break the other use of that predicate?
> 
> >But a secondary problem is the early clobber in the match_scratch.
> 
> So, the FPR_FUSION insn works because operands 1 and 2 cannot
> conflict, which means the early-clobber is not necessary, but the
> GPR_FUSION insn cannot work because there's no way to ensure that
> operands 1 and 2 don't conflict without also specifying that
> operands 0 and 2 don't conflict, which they commonly do.
> 
> We could fix it, for now, by adding new patterns that fit both cases
> (given that the register numbers are known at peephole time).
> 
> Or, we could disable the peephole in the case where this would occur
> (as my original patch does, albeit bluntly).

I'm starting to test this patch right now (it's on LE power8 stage3 right now,
and I need to build BE power8 and BE power7 versions when I get into the office
shortly, and build spec 2017 with it for PR 78101):

[gcc]
2016-11-16  Michael Meissner  

PR target/78101
* config/rs6000/predicates.md (fusion_addis_mem_combo_load): Add
the appropriate checks for SFmode/DFmode load/stores in GPR
registers.
(fusion_addis_mem_combo_store): Likewise.
* config/rs6000/rs6000.c (rs6000_init_hard_regno_mode_ok): Rename
fusion_fpr_* to fusion_vsx_* and add in support for ISA 3.0 scalar
d-form instructions for traditional Altivec registers.
(emit_fusion_p9_load): Likewise.
(emit_fusion_p9_store): Likewise.
* config/rs6000/rs6000.md (p9 fusion store peephole2): Remove
early clobber from scratch register.  Do not match if the register
being stored is the scratch register.
(fusion_vsx___load): Rename fusion_fpr_*
to fusion_vsx_* and add in support for ISA 3.0 scalar d-form
instructions for traditional Altivec registers.
(fusion_fpr___load): Likewise.
(fusion_vsx___store): Likewise.
(fusion_fpr___store): Likewise.

[gcc/testsuite]
2016-11-16  Michael Meissner  

PR target/78101
* gcc.target/powerpc/fusion4.c: New test.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797
Index: gcc/config/rs6000/predicates.md
===
--- gcc/config/rs6000/predicates.md 
(.../svn+ssh://meiss...@gcc.gnu.org/svn/gcc/trunk/gcc/config/rs6000)
(revision 242456)
+++ gcc/config/rs6000/predicates.md (.../gcc/config/rs6000) (working copy)
@@ -1844,7 +1844,7 @@ (define_predicate "fusion_gpr_mem_load"
 ;; Match a GPR load (lbz, lhz, lwz, ld) that uses a combined address in the
 ;; memory field with both the addis and the memory offset.  Sign extension
 ;; is not handled here, since lha and lwa are not fused.
-;; With extended fusion, also match a FPR load (lfd, lfs) and float_extend
+;; With P9 fusion, also match a fpr/vector load and float_extend
 (define_predicate "fusion_addis_mem_combo_load"
   (match_code "mem,zero_extend,float_extend")
 {
@@ -1873,11 +1873,15 @@ (define_predicate "fusion_addis_mem_comb
   break;
 
 case SFmode:
-case DFmode:
   if (!TARGET_P9_FUSION)
return 0;
   break;
 
+case DFmode:
+  if ((!TARGET_POWERPC64 && !TARGET_DF_FPR) || !TARGET_P9_FUSION)
+   return 0;
+  break;
+
 default:
   return 0;
 }
@@ -1920,6 +1924,7 @@ (define_predicate "fusion_addis_mem_comb
 case QImode:
 case HImode:
 case SImode:
+case SFmode:
   break;
 
 case DImode:
@@ -1927,13 +1932,8 @@ (define_predicate "fusion_addis_mem_comb
return 0;
   break;
 
-case SFmode:
-  if (!TARGET_SF_FPR)
-   return 0;
-  break;
-
 case DFmode:
-  if (!TARGET_DF_FPR)
+  if (!TARGET_POWERPC64 && !TARGET_DF_FPR)
return 0;
   break;
 
Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c  
(.../svn+ssh://meiss...@gcc.gnu.org/svn/gcc/trunk/gcc/config/rs6000)
(revision 242456)
+++ gcc/config/rs6000/rs6000.c  (.../gcc/config/rs6000) (working copy)
@@ -3441,28 +3441,28 @@ rs6000_init_hard_regno_mode_ok (bool glo
 
   static const struct fuse_insns addis_insns[] = {
{ SFmode, DImode, RELOAD_REG_FPR,
- CODE_FOR_fusion_fpr_di_sf_load,
- CODE_FOR_fusion_fpr_di_sf_store },
+ CODE_FOR_fusion_vsx_di_sf_load,
+ CODE_FOR_fusion_vsx_di_sf_store },
 
{ SFmode, SImode, RELOAD_REG_FPR,
- CODE_FOR_fusion_fpr_si_sf_load,
- CODE_FOR_fusion_fpr_si_sf_store },
+ 

[Bug fortran/54756] [OOP] [F08] Should reject CLASS, intent(out) in PURE procedures

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|--- |5.0

Re: Use rtx_mode_t instead of std::make_pair

[Bernd Schmidt]

On 11/16/2016 05:52 PM, Richard Sandiford wrote:


Using rtx_mode_t also abstracts away the representation.  The fact that
it's a std::pair rather than a custom class isn't important to users of
the interface.


Looks borderline obvious to me. OK.


Bernd

[Bug fortran/51947] [OOP] [F08] Polymorphic coarrays: Bogus errors for dummy arguments

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|--- |4.9.0