[doc] doc/frontends.texi - remove references to Java

[Gerald Pfeifer]

Somehow removal of the Java frontend is a little more involved than
the original pass apparently has aimed for.

Applied.

Gerald

2017-01-14  Gerald Pfeifer  

* doc/frontends.texi (G++ and GCC): Remove references to Java.

Index: doc/frontends.texi
===
--- doc/frontends.texi  (revision 244462)
+++ doc/frontends.texi  (working copy)
@@ -11,12 +11,11 @@
 @cindex Ada
 @cindex Fortran
 @cindex Go
-@cindex Java
 @cindex Objective-C
 @cindex Objective-C++
 GCC stands for ``GNU Compiler Collection''.  GCC is an integrated
 distribution of compilers for several major programming languages.  These
-languages currently include C, C++, Objective-C, Objective-C++, Java,
+languages currently include C, C++, Objective-C, Objective-C++,
 Fortran, Ada, and Go.
 
 The abbreviation @dfn{GCC} has multiple meanings in common use.  The

Re: [PATCH] PR 78534 Change character length from int to size_t

[Janne Blomqvist]

On Sun, Jan 8, 2017 at 4:29 PM, Dominique d'Humières  wrote:
>> r244027 reverts r244011. Sorry for the breakage. It seems to affect
>> all i686 as well in addition to power, maybe all 32-bit hosts.
>
> For the record, I see the following failures with an instrumented r244026 (as 
> in pr78672)
>
> FAIL: gfortran.dg/char_length_20.f90   -O*  execution test
> FAIL: gfortran.dg/char_length_21.f90   -O*  execution test
> FAIL: gfortran.dg/repeat_2.f90   -O1  execution test
> …
> FAIL: gfortran.dg/repeat_2.f90   -Os  execution test
> FAIL: gfortran.dg/widechar_6.f90   -O1  execution test
> …
> FAIL: gfortran.dg/widechar_6.f90   -Os  execution test
> FAIL: gfortran.dg/widechar_intrinsics_6.f90   -O*  execution test
>
> The run time failures are all of the kind

Sorry, I missed that I had to use an instrumented build to catch
these, and assumed everything was Ok once I managed to regtest cleanly
on i686.

The following patch fixes these issues for me, does it work for you?

diff --git a/libgfortran/intrinsics/string_intrinsics_inc.c
b/libgfortran/intrinsics/string_intrinsics_inc.c
index 0da5130..74a994b 100644
--- a/libgfortran/intrinsics/string_intrinsics_inc.c
+++ b/libgfortran/intrinsics/string_intrinsics_inc.c
@@ -177,23 +177,25 @@ string_trim (gfc_charlen_type *len, CHARTYPE
**dest, gfc_charlen_type slen,
 gfc_charlen_type
 string_len_trim (gfc_charlen_type len, const CHARTYPE *s)
 {
-  const gfc_charlen_type long_len = (gfc_charlen_type) sizeof (unsigned long);
-  gfc_charlen_type i;
+  if (len <= 0)
+return 0;
+
+  const size_t long_len = sizeof (unsigned long);

-  i = len - 1;
+  size_t i = len - 1;

   /* If we've got the standard (KIND=1) character type, we scan the string in
  long word chunks to speed it up (until a long word is hit that does not
  consist of ' 's).  */
   if (sizeof (CHARTYPE) == 1 && i >= long_len)
 {
-  int starting;
+  size_t starting;
   unsigned long blank_longword;

   /* Handle the first characters until we're aligned on a long word
 boundary.  Actually, s + i + 1 must be properly aligned, because
 s + i will be the last byte of a long word read.  */
-  starting = ((unsigned long)
+  starting = (
 #ifdef __INTPTR_TYPE__
  (__INTPTR_TYPE__)
 #endif





-- 
Janne Blomqvist

Re: [PATCH] PR 78534 Change character length from int to size_t

[Janne Blomqvist]

On Sat, Jan 14, 2017 at 1:13 AM, Jerry DeLisle  wrote:
> On 01/13/2017 11:46 AM, David Edelsohn wrote:
>> On Fri, Jan 13, 2017 at 12:09 PM, Janne Blomqvist
>>  wrote:
>>> On Thu, Jan 12, 2017 at 10:46 AM, FX  wrote:
> I was finally able to get a 32-bit i686 compiler going (my attempts to
> do this on a x86_64-pc-linux-gnu host failed, in the end I resorted to
> running 32-bit builds/tests on a i686 container). At least on i686,
> the patch below on top of the big charlen->size_t patch fixes the
> failures

 Patch approved. The old code used gfc_extract_int, which bails out if a 
 non-constant expression is passed, so this is the right thing to do.

 FX
>>>
>>> Committed as r28.
>>>
>>> David, can you verify that it works alright on ppc?
>>
>> Unfortunately, no.  This patch broke bootstrap again with the same
>> failure as earlier.
>>
>> - David
>>
>
> Janne, can you access gcc112 on the compile farm? If not, I can, maybe I can
> test the patch.
>
> Jerry

No, I don't have such access. I'd appreciate it very much if you'd
have a go at it.  Attached is the r28 patch combined with the
patch to fix the sanitizer bugs found by Dominique.

-- 
Janne Blomqvist


0001-PR-78534-Change-character-length-from-int-to-size_t.patch.gz
Description: GNU Zip compressed data

Re: [PATCH] BRIG frontend: request for a global review

[Pekka Jääskeläinen]

On Fri, Jan 13, 2017 at 11:36 PM, Richard Biener
 wrote:
> Ah, with fibers fixed there's only the fp16.c part left.  Presumably LGPL 
> overall is OK as well (but I'm not a lawyer either).

Seems fp16.c has the GPL3 runtime exception in place, so I believe we
are good here license-wise:

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

BR,
Pekka

Re: PR79066, non-PIC code generated for powerpc glibc with -fpic

[Segher Boessenkool]

On Fri, Jan 13, 2017 at 10:10:12PM +1030, Alan Modra wrote:
> Bootstrapped and regression tested powerpc64-linux biarch.  elf_high
> has said "Elf specific ways of loading addresses for non-PIC code"
>  ^^^
> right from the inital V4 support in 1995.
> 
> OK for mainline?

Have you checked if/what this changes for some bigger code?

Okay for trunk if there is nothing unexpected.  Thanks!

Vladimir: Why does LRA attempt to manually construct high/lo_sum at all?
The next thing it tries is using lra_emit_move; this will also do it (on
all targets I checked), but only after appropriate (target-specific) checks.

It is way too late in stage 3 to attempt to change this now, of course ;-)


Segher


>   PR target/79066
>   * config/rs6000/rs6000.md (elf_high, elf_low): Disable when pic.
> testsuite/
>   * gcc.target/powerpc/pr79066.c: New.

Re: Avoid PR72749 by not using unspecs

[Segher Boessenkool]

On Fri, Jan 13, 2017 at 10:20:58PM +1030, Alan Modra wrote:
> Rather than using unspecs in doloop insns to stop combine creating
> these insns, use legitimate_combined_insn.
> 
> I'm not sure why the original patch implementing
> legitimate_combined_insn did not store the result of recog to the insn
> but it seems good to me, and would allow the recog call in
> ix86_legitimate_combined_insn to be omitted.  (I tested that too, not
> shown here.)

It is always restored after the hook call, so this change is fine.

> +  /* Reject creating doloop insns.  Combine should not be allowed
> +  to create these for a number of reasons:

It also prevents combine from combining any instruction into an existing
doloop insn (resulting in a doloop insn again).  This isn't too serious,
almost always this is just a register copy that will be optimised away
some other way.  The unspec hack has more significant problems.

> +  3) Faced with not being able to allocate ctr for ctrsi/crtdi
> +  insns, the register allocator sometimes uses floating point
> +  or vector registers for the pseudo.  Since ctrsi/ctrdi is a
> +  jump insn and output reloads are not implemented for jumps,
> +  the ctrsi/ctrdi splitters need to handle all possible cases.
> +  That's a pain, and it gets to be seriously difficult when a
> +  splitter that runs after reload needs memory to transfer from
> +  a gpr to fpr.  See PR70098 and PR71763 which are not fixed
> +  for the difficult case.  It's better to not create problems
> +  in the first place.  */

Yeah :-)  Note that the problems still can happen, just much less frequently.

> @@ -12751,9 +12749,8 @@ (define_expand "ctr"
>  ;; JUMP_INSNs.
>  ;; For the length attribute to be calculated correctly, the
>  ;; label MUST be operand 0.
> -;; The UNSPEC is present to prevent combine creating this pattern.

Maybe add a note here that rs6000_legitimate_combined_insn will refuse
to combine to this?

Okay for trunk.  Thanks!


Segher

Re: [PATCH 2/6] RISC-V Port: gcc

[Karsten Merker]

Palmer Dabbelt wrote:

> diff --git a/gcc/config/riscv/linux.h b/gcc/config/riscv/linux.h
> new file mode 100644
> index 000..045f6cc
> --- /dev/null
> +++ b/gcc/config/riscv/linux.h
> [...]
>  +#define GLIBC_DYNAMIC_LINKER "/lib" XLEN_SPEC "/" ABI_SPEC "/ld.so.1"

[with XLEN_SPEC being either 32 or 64 and ABI_SPEC being one of
 ilp32, ilp32f, ilp32d, lp64, lp64f, lp64d]

Hello everybody,

I am not fully happy with the way the dynamic linker path (which
gets embedded into every Linux executable built by gcc and
therefore cannot be changed later) is defined here.  The dynamic
linker path must be unique over all platforms for which a Linux
port exists to make multiarch installations (i.e. having
dynamically linked binaries for multiple architectures/ABIs in
the same root filesystem) possible.  The path specifier as cited
above contains nothing that makes the linker path inherently
specific to RISC-V.  While there is AFAIK no other architecture
that currently uses exactly this specific linker path model with
the ABI specifier as a separate subdirectory (instead of encoding
it into the filename), so that there technically isn't a naming
conflict, I think that we should follow the convention of the
other "modern" Linux architectures, which all include the
architecture name in their linker path:

  * arm64:/lib/ld-linux-aarch64.so.1
  * armhf:/lib/ld-linux-armhf.so.3
  * ia64: /lib/ld-linux-ia64.so.2
  * mips n64: /lib64/ld-linux-mipsn8.so.1
  * nios2:/lib/ld-linux-nios2.so.1
  * x86_64:   /lib64/ld-linux-x86-64.so.2 

So the actual ld.so binary should be called something like
"ld-linux-rv.so.1" instead of just "ld.so.1". With everything
else staying the same, that would give us a dynamic linker path
along the lines of "/lib64/lp64f/ld-linux-rv.so.1" for an RV64G
system.

Changing the linker path is of course an incompatible change, but
RISC-V gcc support as submitted upstream now already incoporates
a number of incompatible changes to the previous development
versions (including a different dynamic linker path than older
riscv-gcc versions), so moving from the previous development
versions to upstream results in incompatible binaries anyway,
therefore IMHO now is the time to get these things sorted out
once for all.

Regards,
Karsten
-- 
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.

Re: [PATCH, rs6000] Fix swap optimization to handle __builtin_vsx_xxspltd

[Segher Boessenkool]

Hi Bill,

On Fri, Jan 13, 2017 at 10:28:33AM -0600, Bill Schmidt wrote:
> There is a gap in swap optimization that does not properly handle code
> generated by __builtin_vsx_xxspltd.  This is expanded into an 
> UNSPEC_VSX_XXSPLTD, which is currently treated as ok to swap.  It should
> instead be treated as ok to swap, with special handling to modify the lane
> used as the source of the splat.  We have existing code to do this for
> other splat forms, so the patch is quite simple.
> 
> Bootstrapped and tested on powerpc64le-unknown-linux-gnu with no regressions.
> Is this ok for trunk?  We also require backports for 5 and 6.

This is okay, thanks.  Backports are fine as well (after the usual delay).


Segher


> 2017-01-13  Bill Schmidt  
> 
>   * config/rs6000/rs6000.c (rtx_is_swappable_p): Change
>   UNSPEC_VSX__XXSPLTD to require special splat handling.
> 
> [gcc/testsuite]
> 
> 2017-01-13  Bill Schmidt  
> 
>   * gcc.target/powerpc/swaps-p8-27.c: New.

Re: Avoid PR72749 by not using unspecs

[Uros Bizjak]

On Fri, Jan 13, 2017 at 4:58 PM, Uros Bizjak  wrote:
> On Fri, Jan 13, 2017 at 12:50 PM, Alan Modra  wrote:
>> Rather than using unspecs in doloop insns to stop combine creating
>> these insns, use legitimate_combined_insn.
>>
>> I'm not sure why the original patch implementing
>> legitimate_combined_insn did not store the result of recog to the insn
>> but it seems good to me, and would allow the recog call in
>> ix86_legitimate_combined_insn to be omitted.  (I tested that too, not
>> shown here.)
>
> IIRC, I copied operand scanning loop from recog.c (around line 2580)
> and the function was later enhanced with preferred alternatives
> handling. The function worked well, and not being an expert in this
> area, I didn't try to "optimize" the code that worked...
>
> So, there is no particular reason for the current implementation.

FYI, the following patch immediately crashed build:

--cut here--
Index: i386.c
===
--- i386.c  (revision 244463)
+++ i386.c  (working copy)
@@ -8130,7 +8130,7 @@ ix86_legitimate_combined_insn (rtx_insn *insn)
  generating insn patterns with invalid hard register operands.
  These invalid insns can eventually confuse reload to error out
  with a spill failure.  See also PRs 46829 and 46843.  */
-  if ((INSN_CODE (insn) = recog (PATTERN (insn), insn, 0)) >= 0)
+  if (INSN_CODE (insn) >= 0)
 {
   int i;

--cut here--

/home/uros/gcc-svn/trunk/libgcc/libgcc2.c:557:1: internal compiler
error: Segmentation fault
 }
 ^
0xe82bcc crash_signal
/home/uros/gcc-svn/trunk/gcc/toplev.c:333
0x1621444 insn_extract(rtx_insn*)
/ssd/uros/gcc-build/gcc/insn-extract.c:7453
0xd9e345 extract_insn(rtx_insn*)
/home/uros/gcc-svn/trunk/gcc/recog.c:2317
0x126e662 ix86_legitimate_combined_insn
/home/uros/gcc-svn/trunk/gcc/config/i386/i386.c:8137
0x1814568 recog_for_combine_1
/home/uros/gcc-svn/trunk/gcc/combine.c:11206
0x1814d73 recog_for_combine
/home/uros/gcc-svn/trunk/gcc/combine.c:11363
0x17ffb69 try_combine
/home/uros/gcc-svn/trunk/gcc/combine.c:3824
0x17f8d7e combine_instructions
/home/uros/gcc-svn/trunk/gcc/combine.c:1372
0x181cb67 rest_of_handle_combine
/home/uros/gcc-svn/trunk/gcc/combine.c:14607
0x181cc28 execute
/home/uros/gcc-svn/trunk/gcc/combine.c:14652

It looks that recog_for_combine doesn't do everything recog does.

Uros.

Re: Avoid PR72749 by not using unspecs

[Uros Bizjak]

On Sat, Jan 14, 2017 at 11:19 AM, Uros Bizjak  wrote:
> On Fri, Jan 13, 2017 at 4:58 PM, Uros Bizjak  wrote:
>> On Fri, Jan 13, 2017 at 12:50 PM, Alan Modra  wrote:
>>> Rather than using unspecs in doloop insns to stop combine creating
>>> these insns, use legitimate_combined_insn.
>>>
>>> I'm not sure why the original patch implementing
>>> legitimate_combined_insn did not store the result of recog to the insn
>>> but it seems good to me, and would allow the recog call in
>>> ix86_legitimate_combined_insn to be omitted.  (I tested that too, not
>>> shown here.)
>>
>> IIRC, I copied operand scanning loop from recog.c (around line 2580)
>> and the function was later enhanced with preferred alternatives
>> handling. The function worked well, and not being an expert in this
>> area, I didn't try to "optimize" the code that worked...
>>
>> So, there is no particular reason for the current implementation.
>
> FYI, the following patch immediately crashed build:

Bah, it would help if I actually saved source with proposed combine.c change.

Testing the patch...

Uros.

Re: [PATCH, rs6000] Add vec_nabs builtin support

[Segher Boessenkool]

Hi Carl,

On Fri, Jan 13, 2017 at 10:27:59AM -0800, Carl E. Love wrote:
>   * config/rs6000/altivec.md: Add define to expand nabs2 types

* config/rs6000/altivec.md (nabs2): New define_expand.

>   * doc/extend.texi (section 6.60.22 PowerPC AltiVec Built-in Functions):
>   Update the documentation file for the new built-in functions.

Section numbers aren't stable (or in the source file at all), just remove
it here.

> 2017-01-08  Carl Love  
> 
>   * gcc.target/powerpc/builtins-3.c: Add tests for the new built-ins
>   to the test suite file.
>   * gcc.target/powerpc/builtins-3-p8.c: Add tests for the new built-ins
>   to the test suite file.

Just say "New.", "New testcase.", or "New file.".  New  is much
easier to write changelog entries for than modified  ;-)

Okay for trunk with those changes.  Thanks!


Segher

Re: [PATCH, rs6000] Fix for test_ne_int() built-in test case.

[Segher Boessenkool]

On Fri, Jan 13, 2017 at 02:58:23PM -0800, Carl E. Love wrote:
> The following patch fixes an issue with the builtin test test_ne_long().
> The issue is the arguments need to be "bool long long" not "bool long"
> to get the correct 64-bit value when running in 32-bit mode.
> 
> The patch has been tested on:
> powerpc64-unknown-linux-gnu (Power 7 64-bit, 32-bit) with no
> regressions.
> 
> Is this OK for trunk?

> 2017-01-13 Carl Love  
> 
>   * gcc.target/powerpc/builtins-3-p9.c (test_ne_long()):
>   Test fails in 32-bit mode because the arguments are of type
>   "bool long" not "bool long long".  The arguments need to be
>   "bool long long" to get a correct 64-bit value in 32-bit mode.

Just "Change argument and return types to bool long long."?

Okay for trunk with that (you didn't mention the return type before; the
rest is fine if overly verbose, a changelog entry does not usually say
"why", just "what").


Segher

[PATCH] Skip tests that are incompatible with Profile Mode

[Jonathan Wakely]

This fixes all failures for 'make check-profile', which are either due
to tests that use Debug Mode (which can't be combined with Profile
Mode) or which rely on new C++17 features that the Profile Mode
containers don't support. As Profile Mode has been deprecated for GCC
7 we're unlikely to add those new features, and can just skip the
tests.

* testsuite/23_containers/array/specialized_algorithms/swap_cxx17.cc:
Skip test when -D_GLIBCXX_PROFILE mode is included in options.
* testsuite/23_containers/map/modifiers/extract.cc: Likewise.
* testsuite/23_containers/map/modifiers/insert_or_assign/1.cc:
Likewise.
* testsuite/23_containers/map/modifiers/try_emplace/1.cc: Likewise.
* testsuite/23_containers/multimap/modifiers/extract.cc: Likewise.
* testsuite/23_containers/multiset/modifiers/extract.cc: Likewise.
* testsuite/23_containers/set/modifiers/extract.cc: Likewise.
* testsuite/23_containers/unordered_map/modifiers/extract.cc:
Likewise.
* testsuite/23_containers/unordered_multimap/modifiers/extract.cc::
Likewise.
* testsuite/23_containers/unordered_multiset/modifiers/extract.cc::
Likewise.
* testsuite/23_containers/unordered_set/modifiers/extract.cc:
Likewise.
* testsuite/23_containers/vector/modifiers/insert_vs_emplace.cc:
Likewise.
* testsuite/25_algorithms/binary_search/partitioned.cc: Likewise.
* testsuite/25_algorithms/equal_range/partitioned.cc: Likewise.
* testsuite/25_algorithms/lexicographical_compare/71545.cc: Likewise.
* testsuite/25_algorithms/lower_bound/partitioned.cc: Likewise.
* testsuite/25_algorithms/upper_bound/partitioned.cc: Likewise.
* testsuite/libstdc++-prettyprinters/cxx11.cc: Likewise.
* testsuite/libstdc++-prettyprinters/cxx17.cc: Likewise.
* testsuite/libstdc++-prettyprinters/debug.cc: Likewise.
* testsuite/libstdc++-prettyprinters/debug_cxx11.cc: Likewise.
* testsuite/libstdc++-prettyprinters/libfundts.cc: Likewise.
* testsuite/libstdc++-prettyprinters/simple.cc: Likewise.
* testsuite/libstdc++-prettyprinters/simple11.cc: Likewise.
* testsuite/libstdc++-prettyprinters/whatis.cc: Likewise.

Tested powerpc64le-linux, commmitted to trunk.

commit 4c1ae763901fcd7197ff5379c1272e3281c1
Author: Jonathan Wakely 
Date:   Fri Jan 13 18:55:43 2017 +

Skip tests that are incompatible with Profile Mode

* testsuite/23_containers/array/specialized_algorithms/swap_cxx17.cc:
Skip test when -D_GLIBCXX_PROFILE mode is included in options.
* testsuite/23_containers/map/modifiers/extract.cc: Likewise.
* testsuite/23_containers/map/modifiers/insert_or_assign/1.cc:
Likewise.
* testsuite/23_containers/map/modifiers/try_emplace/1.cc: Likewise.
* testsuite/23_containers/multimap/modifiers/extract.cc: Likewise.
* testsuite/23_containers/multiset/modifiers/extract.cc: Likewise.
* testsuite/23_containers/set/modifiers/extract.cc: Likewise.
* testsuite/23_containers/unordered_map/modifiers/extract.cc:
Likewise.
* testsuite/23_containers/unordered_multimap/modifiers/extract.cc::
Likewise.
* testsuite/23_containers/unordered_multiset/modifiers/extract.cc::
Likewise.
* testsuite/23_containers/unordered_set/modifiers/extract.cc:
Likewise.
* testsuite/23_containers/vector/modifiers/insert_vs_emplace.cc:
Likewise.
* testsuite/25_algorithms/binary_search/partitioned.cc: Likewise.
* testsuite/25_algorithms/equal_range/partitioned.cc: Likewise.
* testsuite/25_algorithms/lexicographical_compare/71545.cc: Likewise.
* testsuite/25_algorithms/lower_bound/partitioned.cc: Likewise.
* testsuite/25_algorithms/upper_bound/partitioned.cc: Likewise.
* testsuite/libstdc++-prettyprinters/cxx11.cc: Likewise.
* testsuite/libstdc++-prettyprinters/cxx17.cc: Likewise.
* testsuite/libstdc++-prettyprinters/debug.cc: Likewise.
* testsuite/libstdc++-prettyprinters/debug_cxx11.cc: Likewise.
* testsuite/libstdc++-prettyprinters/libfundts.cc: Likewise.
* testsuite/libstdc++-prettyprinters/simple.cc: Likewise.
* testsuite/libstdc++-prettyprinters/simple11.cc: Likewise.
* testsuite/libstdc++-prettyprinters/whatis.cc: Likewise.

diff --git 
a/libstdc++-v3/testsuite/23_containers/array/specialized_algorithms/swap_cxx17.cc
 
b/libstdc++-v3/testsuite/23_containers/array/specialized_algorithms/swap_cxx17.cc
index 746e69f..60d7d4c 100644
--- 
a/libstdc++-v3/testsuite/23_containers/array/specialized_algorithms/swap_cxx17.cc
+++ 
b/libstdc++-v3/testsuite/23_containers/array/specialized_algorithms/swap_cxx17.cc
@@ -1,5 +1,6 @@
 // { dg-options "-std=gnu++17" }
 // { dg-do compile }
+// { dg-skip-if "" { *-*-* } { "-D_GLIBCXX_PROFILE

Re: Avoid PR72749 by not using unspecs

[Alan Modra]

On Sat, Jan 14, 2017 at 03:51:27AM -0600, Segher Boessenkool wrote:
> It also prevents combine from combining any instruction into an existing
> doloop insn (resulting in a doloop insn again).  This isn't too serious,
> almost always this is just a register copy that will be optimised away
> some other way.

Right.  I forgot to mention, I looked at all of gcc/*.o before/after
the patch and saw no occurrences of any missed combines.  Just the
expected changes in rs6000.o, various insn-*.o from twiddling
rs6000.md, and one constant change in read-rtl-function.o.

-- 
Alan Modra
Australia Development Lab, IBM

[PATCH] Fix RTL sharing bug in loop-doloop.c (PR target/79080)

[Jakub Jelinek]

Hi!

The force_operand on complex count expression in doloop_modify can invoke
various expander routines that are assuming there is rtl unsharing after
them (which is the case for expansion).  When later optimizations invoke
the expander (e.g. expand_mult in this case), they use
unshare_all_rtl_in_chain on the sequence.  The following patch does that for
doloop.  The count expression is already known not to be shared with
anything else (we do copy_rtx on it first and then create new rtls around it
if needed), so for that if it occurs just once in the sequence, we don't
need to unshare it.  For subexpression of condition I'm not sure, which is
why I've forced unsharing even if it occurs just once and is not shareable
part of the condition like REG.

Bootstrapped/regtested on powerpc64-linux, ok for trunk?

2017-01-14  Jakub Jelinek  

PR target/79080
* loop-doloop.c (doloop_modify): Call unshare_all_rtl_in_chain on
sequence.  Formatting fixes.
(doloop_optimize): Formatting fixes.

* gcc.dg/pr79080.c: New test.

--- gcc/loop-doloop.c.jj2017-01-01 12:45:37.0 +0100
+++ gcc/loop-doloop.c   2017-01-13 09:55:36.918702356 +0100
@@ -479,9 +479,13 @@ doloop_modify (struct loop *loop, struct
 
   /* Insert initialization of the count register into the loop header.  */
   start_sequence ();
+  /* count has been already copied through copy_rtx.  */
+  reset_used_flags (count);
+  set_used_flags (condition);
   tmp = force_operand (count, counter_reg);
   convert_move (counter_reg, tmp, 1);
   sequence = get_insns ();
+  unshare_all_rtl_in_chain (sequence);
   end_sequence ();
   emit_insn_after (sequence, BB_END (loop_preheader_edge (loop)->src));
 
@@ -489,10 +493,8 @@ doloop_modify (struct loop *loop, struct
 {
   rtx ass = copy_rtx (desc->noloop_assumptions);
   basic_block preheader = loop_preheader_edge (loop)->src;
-  basic_block set_zero
- = split_edge (loop_preheader_edge (loop));
-  basic_block new_preheader
- = split_edge (loop_preheader_edge (loop));
+  basic_block set_zero = split_edge (loop_preheader_edge (loop));
+  basic_block new_preheader = split_edge (loop_preheader_edge (loop));
   edge te;
 
   /* Expand the condition testing the assumptions and if it does not pass,
@@ -688,8 +690,7 @@ doloop_optimize (struct loop *loop)
   rtx_insn *doloop_seq = targetm.gen_doloop_end (doloop_reg, start_label);
 
   word_mode_size = GET_MODE_PRECISION (word_mode);
-  word_mode_max
- = (HOST_WIDE_INT_1U << (word_mode_size - 1) << 1) - 1;
+  word_mode_max = (HOST_WIDE_INT_1U << (word_mode_size - 1) << 1) - 1;
   if (! doloop_seq
   && mode != word_mode
   /* Before trying mode different from the one in that # of iterations is
--- gcc/testsuite/gcc.dg/pr79080.c.jj   2017-01-13 10:03:54.518423577 +0100
+++ gcc/testsuite/gcc.dg/pr79080.c  2017-01-13 10:07:37.610608570 +0100
@@ -0,0 +1,19 @@
+/* PR target/79080 */
+/* { dg-do compile } */
+/* { dg-options "-O1" } */
+/* { dg-additional-options "-mcpu=8548" { target { powerpc*-*-* && ilp32 } } } 
*/
+
+int
+foo (char x)
+{
+  int a;
+
+  for (;;)
+{
+  x += 59;
+  if (x != 0)
+a = 0;
+  else
+return 0;
+}
+}

Jakub

Re: PR79066, non-PIC code generated for powerpc glibc with -fpic

[Alan Modra]

On Sat, Jan 14, 2017 at 03:28:51AM -0600, Segher Boessenkool wrote:
> On Fri, Jan 13, 2017 at 10:10:12PM +1030, Alan Modra wrote:
> > Bootstrapped and regression tested powerpc64-linux biarch.  elf_high
> > has said "Elf specific ways of loading addresses for non-PIC code"
> >  ^^^
> > right from the inital V4 support in 1995.
> > 
> > OK for mainline?
> 
> Have you checked if/what this changes for some bigger code?

Well, the bootstrap was all langs (minus ada due to not having ada
installed) and ppc32 multilibs were built.  Plus the testsuite run
with RUNTESTFLAGS="--target_board=unix'{-m32,-m64}{-mlra,-mno-lra}'"

I would have bootstrapped -m32 except the machine I used lacked 32-bit
gmp, mpfr, mpc and I was lazy.

> Okay for trunk if there is nothing unexpected.  Thanks!

I guess I should at least build glibc.

-- 
Alan Modra
Australia Development Lab, IBM

Re: PR79066, non-PIC code generated for powerpc glibc with -fpic

[Jakub Jelinek]

On Sun, Jan 15, 2017 at 12:08:39AM +1030, Alan Modra wrote:
> On Sat, Jan 14, 2017 at 03:28:51AM -0600, Segher Boessenkool wrote:
> > On Fri, Jan 13, 2017 at 10:10:12PM +1030, Alan Modra wrote:
> > > Bootstrapped and regression tested powerpc64-linux biarch.  elf_high
> > > has said "Elf specific ways of loading addresses for non-PIC code"
> > >  ^^^
> > > right from the inital V4 support in 1995.
> > > 
> > > OK for mainline?
> > 
> > Have you checked if/what this changes for some bigger code?
> 
> Well, the bootstrap was all langs (minus ada due to not having ada
> installed) and ppc32 multilibs were built.  Plus the testsuite run
> with RUNTESTFLAGS="--target_board=unix'{-m32,-m64}{-mlra,-mno-lra}'"
> 
> I would have bootstrapped -m32 except the machine I used lacked 32-bit
> gmp, mpfr, mpc and I was lazy.
> 
> > Okay for trunk if there is nothing unexpected.  Thanks!
> 
> I guess I should at least build glibc.

See Uros' comment about the INSN_CODE (insn) = insn_code_number;.
Also, I'm worried about it for another reason, after the
if (!targetm.legitimate_combined_insn (insn))
call the PATTERN is reverted to something different, so keeping INSN_CODE
equal to insn_code_number (which we sometimes even change to -1)
looks wrong, if it is the right thing to do it for the
legitimate_combined_insn call, it should be reverted afterwards when the
PATTERN changes again.
Or, perhaps instead of setting INSN_CODE, pass insn_code_number to the
target hook as another argument?

Jakub

Re: Avoid PR72749 by not using unspecs

[Alan Modra]

On Sat, Jan 14, 2017 at 02:46:11PM +0100, Jakub Jelinek wrote:
> See Uros' comment about the INSN_CODE (insn) = insn_code_number;.

Later email retracted the one about a crash.

> Also, I'm worried about it for another reason, after the
> if (!targetm.legitimate_combined_insn (insn))
> call the PATTERN is reverted to something different, so keeping INSN_CODE
> equal to insn_code_number (which we sometimes even change to -1)
> looks wrong, if it is the right thing to do it for the
> legitimate_combined_insn call, it should be reverted afterwards when the
> PATTERN changes again.

It is reverted afterwards.

  PATTERN (insn) = old_pat;
  REG_NOTES (insn) = old_notes;
  INSN_CODE (insn) = old_icode;

-- 
Alan Modra
Australia Development Lab, IBM

Re: Avoid PR72749 by not using unspecs

[Jakub Jelinek]

On Sun, Jan 15, 2017 at 12:37:19AM +1030, Alan Modra wrote:
> On Sat, Jan 14, 2017 at 02:46:11PM +0100, Jakub Jelinek wrote:
> > See Uros' comment about the INSN_CODE (insn) = insn_code_number;.
> 
> Later email retracted the one about a crash.
> 
> > Also, I'm worried about it for another reason, after the
> > if (!targetm.legitimate_combined_insn (insn))
> > call the PATTERN is reverted to something different, so keeping INSN_CODE
> > equal to insn_code_number (which we sometimes even change to -1)
> > looks wrong, if it is the right thing to do it for the
> > legitimate_combined_insn call, it should be reverted afterwards when the
> > PATTERN changes again.
> 
> It is reverted afterwards.
> 
>   PATTERN (insn) = old_pat;
>   REG_NOTES (insn) = old_notes;
>   INSN_CODE (insn) = old_icode;

Ah, you're right, I've missed that.  Also sorry for posting it in a wrong 
thread.

Jakub

Re: [C++ Patch] PR 71737

[Jason Merrill]

OK.

On Fri, Jan 13, 2017 at 5:58 PM, Paolo Carlini  wrote:
> Hi,
>
> On 13/01/2017 18:33, Jason Merrill wrote:
>>
>> On Fri, Jan 13, 2017 at 11:42 AM, Paolo Carlini
>>  wrote:
>>>
>>> Hi,
>>>
>>> On 13/01/2017 15:51, Nathan Sidwell wrote:

 On 01/13/2017 09:45 AM, Paolo Carlini wrote:
>
> Hi,
>
> in this error recovery issue get_underlying_template crashes when
> TYPE_TEMPLATE_INFO_MAYBE_ALIAS is applied to a null orig_type. Simply
> checking for that condition appears to solve the issue in a
> straightforward way. Tested x86_64-linux.


 Wouldn't it be better if a scrogged alias got error_mark_node as the
 underlying type?  (I have no idea whether that's an easy thing to
 accomplish)
>>>
>>> Your reply, Nathan, led me to investigate where exactly
>>> DECL_ORIGINAL_TYPE
>>> becomes null, and turns out that in tsubst_decl we have code actively
>>> doing
>>> that. That same code, a few lines below, only sets TYPE_DEPENDENT_P_VALID
>>> to
>>> false if type != error_mark_node. I cannot say to fully understand yet
>>> all
>>> the details, but certainly the patchlet below also passes testing. Do you
>>> have comments about this too?
>>
>> The clearing of DECL_ORIGINAL_TYPE is to allow set_underlying_type to
>> then set it to something more appropriate.  That function currently
>> avoids setting DECL_ORIGINAL_TYPE to error_mark_node, perhaps that
>> should be changed.
>
> I see, thanks a lot. The below passes testing on x86_64-linux.
>
> Paolo.
>
> ///

Re: [PATCH] C++: fix fix-it hints for misspellings within explicit namespaces

[Jason Merrill]

On Fri, Jan 13, 2017 at 5:05 PM, David Malcolm  wrote:
> On Wed, 2017-01-04 at 14:58 -0500, Jason Merrill wrote:
>> On Tue, Jan 3, 2017 at 8:28 PM, David Malcolm 
>> wrote:
>> > PR c++/77829 and PR c++/78656 identify an issue within the C++
>> > frontend
>> > where it issues nonsensical fix-it hints for misspelled name
>> > lookups
>> > within an explicitly given namespace: it finds the closest name
>> > within
>> > all namespaces, and uses the location of the namespace for the
>> > replacement,
>> > rather than the name.
>> >
>> > For example, for this error:
>> >
>> >   #include 
>> >   void* allocate(std::size_t n)
>> >   {
>> > return std::alocator().allocate(n);
>> >   }
>> >
>> > we currently emit an erroneous fix-it hint that would generate this
>> > nonsensical patch:
>> >
>> >{
>> >   -  return std::alocator().allocate(n);
>> >   +  return allocate::alocator().allocate(n);
>> >}
>> >
>> > whereas we ought to emit a fix-it hint that would generate this
>> > patch:
>> >
>> >{
>> >   -  return std::alocator().allocate(n);
>> >   +  return std::allocator().allocate(n);
>> >}
>> >
>> > This patch fixes the suggestions, in two parts:
>> >
>> > The incorrect name in the suggestion is fixed by introducing a
>> > new function "suggest_alternative_in_explicit_scope"
>> > for use by qualified_name_lookup_error when handling failures
>> > in explicitly-given namespaces, looking for hint candidates within
>> > just that namespace.  The function suggest_alternatives_for gains a
>> > "suggest_misspellings" bool param, so that we can disable fuzzy
>> > name
>> > lookup for the case where we've ruled out hint candidates in the
>> > explicitly-given namespace.
>> >
>> > This lets us suggest "allocator" (found in "std") rather "allocate"
>> > (found in the global ns).
>>
>> This looks good.
>>
>> > The patch fixes the location for the replacement by updating
>> > local "unqualified_id" in cp_parser_id_expression from tree to
>> > cp_expr to avoid implicitly dropping location information, and
>> > passing this location to a new param of finish_id_expression.
>> > There are multiple users of finish_id_expression, and it wasn't
>> > possible to provide location information for the id for all of them
>> > so the new location information is assumed to be optional there.
>>
>> > This fixes the underlined location, and ensures that the fix-it
>> > hint
>> > replaces "alocator", rather than "std".
>>
>> I'm dubious about this approach, as I think this will fix some cases
>> and not others.  The general problem is that we aren't sure what to
>> do
>> with the location of a qualified-id: sometimes we use the location of
>> the unqualified-id, sometimes we use the beginning of the first
>> nested-name-specifier.  I think the right answer is probably to use a
>> rich location with the caret on the unqualified-id.  Then the fix-it
>> hint can use the caret location for the fix-it.  Does that make
>> sense?
>
> Sorry, I'm not sure I follow you.
>
> By "rich location" do you mean providing multiple ranges (e.g. one for
> the nested-name-specifier, another for the unqualified-id)?
>
> e.g.
>
>   ::foo::bar
> ~~~  ^~~
>  ||
>  |`-(primary location and range)
>  `-(secondary range)
>
> or:
>
>   ::foo::bar
>   ~  ^~~
>  ||
>  |`-(primary location and
> range)
>  `-(secondary range)
>
> (if that ASCII art makes sense)
>
> Note that such a rich location (with more than one range) can only
> exist during the emission of a diagnostic; it's not something we can
> use as the location of a tree node.
>
> Or do you mean that we should supply a range for the unqualified-id,
> with the caret at the start of the unqualified-id, e.g.:
>
>::foo::bar
>   ^~~
>
> (a tree node code can have such a location).
>
> It seems to me that we ought to have
>
>::foo::bar
>^~
>
> as the location of such a tree node, and only use the range of just
> "bar" as the location when handling name lookup errors (such as when
> emitting fix-it hints).

Yes, sorry, I meant range.  I was thinking

::foo::bar
~~~^~~

And then the fix-it would know to replace from the caret to the end of
the range?

Jason

Re: PR79066, non-PIC code generated for powerpc glibc with -fpic

[Segher Boessenkool]

On Sun, Jan 15, 2017 at 12:08:39AM +1030, Alan Modra wrote:
> > Have you checked if/what this changes for some bigger code?
> 
> Well, the bootstrap was all langs (minus ada due to not having ada
> installed) and ppc32 multilibs were built.  Plus the testsuite run
> with RUNTESTFLAGS="--target_board=unix'{-m32,-m64}{-mlra,-mno-lra}'"
> 
> I would have bootstrapped -m32 except the machine I used lacked 32-bit
> gmp, mpfr, mpc and I was lazy.
> 
> > Okay for trunk if there is nothing unexpected.  Thanks!
> 
> I guess I should at least build glibc.

Yes exactly, something big that uses pic -- it is pretty obvious it won't
change anything for non-pic.

For gmp etc. you can use download_prequisites fwiw -- even lazier than
using the distro-provided binaries ;-)


Segher

Re: Fix ppc64le bootstrap comparison failure

[David Edelsohn]

Jeff,

The ppc64le bootstrap comparison may have been fixed, but I continue
to see the additional testsuite failures on AIX, all of the form:

internal compiler error: in fill_vec_av_set, at sel-sched.c:3712

I rolled back the earlier version of DSE patch and the failures were
resolved, so it definitely seems to be caused by the DSE patch.

Thanks, David

New French PO file for 'gcc' (version 7.1-b20170101)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

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

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

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

All other PO files for your package are available in:

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

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

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

The following HTML page has been updated:

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

If any question arises, please contact the translation coordinator.

Thank you for all your work,

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

Re: Fix ppc64le bootstrap comparison failure

[Jeff Law]

On 01/14/2017 08:49 AM, David Edelsohn wrote:

Jeff,

The ppc64le bootstrap comparison may have been fixed, but I continue
to see the additional testsuite failures on AIX, all of the form:

internal compiler error: in fill_vec_av_set, at sel-sched.c:3712

I rolled back the earlier version of DSE patch and the failures were
resolved, so it definitely seems to be caused by the DSE patch.
I'm not seeing any new failures on ppc64le-linux.  I've got a big-endian 
ppc system provisioning for testing just in case its an endianness issue.


jeff

Re: cprop fix for PR78626

[Jeff Law]

On 12/14/2016 08:46 AM, Bernd Schmidt wrote:

On 12/12/2016 03:21 PM, Bernd Schmidt wrote:

On 12/10/2016 08:58 PM, Segher Boessenkool wrote:

On Thu, Dec 08, 2016 at 01:21:04PM +0100, Bernd Schmidt wrote:

This is another case where an optimization turns a trap_if
unconditional. We have to defer changing the CFG, since the rest of
cprop seems to blow up when we modify things while scanning.



The problem for PR78727 is that we also need to do this for insns that
already are the last insn in the block:


+  while (!uncond_traps.is_empty ())
+{
+  rtx_insn *insn = uncond_traps.pop ();
+  basic_block to_split = BLOCK_FOR_INSN (insn);
+  remove_edge (split_block (to_split, insn));
+  emit_barrier_after_bb (to_split);
+}


We need that barrier, and we also need the successor edges removed
(which split_block+remove_edge does).

(PR78727 works fine with just that BB_END test deleted).


Ah, ok. In that case I'll probably also add a test to make sure this is
only done for insns that weren't an unconditional trap before.
Retesting...


That would be this patch. Tested as before. The two new testcases seem
to pass with a ppc cross (but I would appreciate if someone were to run
full tests on ppc).


Bernd


cprop-v2.diff


PR rtl-optimization/78626
PR rtl-optimization/78727
* cprop.c (one_cprop_pass): Collect unconditional traps in the middle
of a block, and split such blocks after everything else is finished.

PR rtl-optimization/78626
PR rtl-optimization/78727
* gcc.dg/torture/pr78626.c: New test.
* gcc.dg/torture/pr78727.c: New test.
This is OK.  I also re-tested ppc64le-linux since it's been about 3 
weeks since this patch was submitted.


I went ahead and committed the patch since you're on PTO and it kills 
stuff on the regression hit list.


jeff

Re: [PATCH] PR 78534 Change character length from int to size_t

[Dominique d'Humières]

> The following patch fixes these issues for me, does it work for you?

Yes, it does!

Dominique

> Janne Blomqvist

Re: Fix ppc64le bootstrap comparison failure

[David Edelsohn]

On Sat, Jan 14, 2017 at 11:46 AM, Jeff Law  wrote:
> On 01/14/2017 08:49 AM, David Edelsohn wrote:
>>
>> Jeff,
>>
>> The ppc64le bootstrap comparison may have been fixed, but I continue
>> to see the additional testsuite failures on AIX, all of the form:
>>
>> internal compiler error: in fill_vec_av_set, at sel-sched.c:3712
>>
>> I rolled back the earlier version of DSE patch and the failures were
>> resolved, so it definitely seems to be caused by the DSE patch.
>
> I'm not seeing any new failures on ppc64le-linux.  I've got a big-endian ppc
> system provisioning for testing just in case its an endianness issue.

powerpc64-unknown-linux-gnu (POWER7 BE) at r244463 (after your fix)
shows many failures:

https://gcc.gnu.org/ml/gcc-testresults/2017-01/msg01419.html

Thanks, David

Re: Fix ppc64le bootstrap comparison failure

[Jeff Law]

On 01/14/2017 10:03 AM, David Edelsohn wrote:

On Sat, Jan 14, 2017 at 11:46 AM, Jeff Law  wrote:

On 01/14/2017 08:49 AM, David Edelsohn wrote:


Jeff,

The ppc64le bootstrap comparison may have been fixed, but I continue
to see the additional testsuite failures on AIX, all of the form:

internal compiler error: in fill_vec_av_set, at sel-sched.c:3712

I rolled back the earlier version of DSE patch and the failures were
resolved, so it definitely seems to be caused by the DSE patch.


I'm not seeing any new failures on ppc64le-linux.  I've got a big-endian ppc
system provisioning for testing just in case its an endianness issue.


powerpc64-unknown-linux-gnu (POWER7 BE) at r244463 (after your fix)
shows many failures:

https://gcc.gnu.org/ml/gcc-testresults/2017-01/msg01419.html
THanks.  I'll start debugging from that list rather than waiting on my 
own bootstrap & test cycle to speed things up.


jeff

[PATCH] Make rtl_split_edge work for jumps that fall through (PR72749)

[Segher Boessenkool]

If a jump always falls through but that cannot be optimised away, like
is the case with the PowerPC bdnz insn if its jump target is the same as
the fallthrough, sched gets confused if it schedules some instructions
from before that jump instruction to behind it: it splits the
fallthrough branch, but the jump target isn't updated, and things fall
apart as in the PR.  This patch fixes it.

The second patch fragment makes -fsched-verbose=N work for N>=4; the
currently scheduled fragment can now contain a label.  Everything else
seems to work fine with that.

Tested on powerpc*-linux (with the testcase Alan checked in earlier
today); also bootstrapped on powerpc64-linux.  Is this okay for trunk?


Segher


2017-01-14  Segher Boessenkool  

PR target/72749
* cfgrtl.c (rtl_split_edge): Also patch jump insns that jump to the
fallthrough.
* haifa-sched.c (dump_insn_stream): Don't crash if there is a label
in the currently scheduled RTL fragment.

---
 gcc/cfgrtl.c  | 2 +-
 gcc/haifa-sched.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/gcc/cfgrtl.c b/gcc/cfgrtl.c
index 7604346..dbbba59 100644
--- a/gcc/cfgrtl.c
+++ b/gcc/cfgrtl.c
@@ -1931,7 +1931,7 @@ rtl_split_edge (edge edge_in)
  if (last
  && JUMP_P (last)
  && edge_in->dest != EXIT_BLOCK_PTR_FOR_FN (cfun)
- && extract_asm_operands (PATTERN (last)) != NULL_RTX
+ && (extract_asm_operands (last) || JUMP_LABEL (last) == before)
  && patch_jump_insn (last, before, bb))
df_set_bb_dirty (edge_in->src);
}
diff --git a/gcc/haifa-sched.c b/gcc/haifa-sched.c
index 1b13e32..07de1bb 100644
--- a/gcc/haifa-sched.c
+++ b/gcc/haifa-sched.c
@@ -6495,7 +6495,7 @@ dump_insn_stream (rtx_insn *head, rtx_insn *tail)
 
   if (sched_verbose >= 4)
{
- if (NOTE_P (insn) || recog_memoized (insn) < 0)
+ if (NOTE_P (insn) || LABEL_P (insn) || recog_memoized (insn) < 0)
fprintf (sched_dump, "nothing");
  else
print_reservation (sched_dump, insn);
-- 
1.9.3

Re: [PATCH] Make rtl_split_edge work for jumps that fall through (PR72749)

[Segher Boessenkool]

On Sat, Jan 14, 2017 at 05:55:48PM +, Segher Boessenkool wrote:
> -   && extract_asm_operands (PATTERN (last)) != NULL_RTX
> +   && (extract_asm_operands (last) || JUMP_LABEL (last) == before)

Somehow I removed the PATTERN there; retesting with it.  I'll test it
on x86 as well, maybe it triggers there (it doesn't on PowerPC obviously).


Segher

Re: [PATCH] PR 78534 Change character length from int to size_t

[Janne Blomqvist]

On Sat, Jan 14, 2017 at 10:46 AM, Janne Blomqvist
 wrote:
> On Sat, Jan 14, 2017 at 1:13 AM, Jerry DeLisle  wrote:
>> On 01/13/2017 11:46 AM, David Edelsohn wrote:
>>> On Fri, Jan 13, 2017 at 12:09 PM, Janne Blomqvist
>>>  wrote:
 On Thu, Jan 12, 2017 at 10:46 AM, FX  wrote:
>> I was finally able to get a 32-bit i686 compiler going (my attempts to
>> do this on a x86_64-pc-linux-gnu host failed, in the end I resorted to
>> running 32-bit builds/tests on a i686 container). At least on i686,
>> the patch below on top of the big charlen->size_t patch fixes the
>> failures
>
> Patch approved. The old code used gfc_extract_int, which bails out if a 
> non-constant expression is passed, so this is the right thing to do.
>
> FX

 Committed as r28.

 David, can you verify that it works alright on ppc?
>>>
>>> Unfortunately, no.  This patch broke bootstrap again with the same
>>> failure as earlier.
>>>
>>> - David
>>>
>>
>> Janne, can you access gcc112 on the compile farm? If not, I can, maybe I can
>> test the patch.
>>
>> Jerry
>
> No, I don't have such access. I'd appreciate it very much if you'd
> have a go at it.  Attached is the r28 patch combined with the
> patch to fix the sanitizer bugs found by Dominique.
>
> --
> Janne Blomqvist

Since David had problems with module generation, I took a look at the
parts of the patch that changes module.c, and found a few places for
improvements. module.c is a collection of all the ugly type punning
tricks one can think of, in particular wrongly punning to a wider type
might cause a different result on a big endian machine, whereas on a
little endian it would apparently just work.. So could you also try
the attached small patch on top of the previous one?

(I also sent Laurent Guerby an email requesting an account on the compile farm).

-- 
Janne Blomqvist
diff --git a/gcc/fortran/module.c b/gcc/fortran/module.c
index ca53016..90b77ca 100644
--- a/gcc/fortran/module.c
+++ b/gcc/fortran/module.c
@@ -143,7 +143,7 @@ enum gfc_wsym_state
 typedef struct pointer_info
 {
   BBT_HEADER (pointer_info);
-  int integer;
+  HOST_WIDE_INT integer;
   pointer_t type;
 
   /* The first component of each member of the union is the pointer
@@ -372,7 +372,7 @@ get_pointer (void *gp)
creating the node if not found.  */
 
 static pointer_info *
-get_integer (int integer)
+get_integer (HOST_WIDE_INT integer)
 {
   pointer_info *p, t;
   int c;
@@ -472,7 +472,7 @@ associate_integer_pointer (pointer_info *p, void *gp)
sometime later.  Returns the pointer_info structure.  */
 
 static pointer_info *
-add_fixup (int integer, void *gp)
+add_fixup (HOST_WIDE_INT integer, void *gp)
 {
   pointer_info *p;
   fixup_t *f;
@@ -2729,7 +2729,8 @@ mio_pointer_ref (void *gp)
   if (iomode == IO_OUTPUT)
 {
   p = get_pointer (*((char **) gp));
-  write_atom (ATOM_INTEGER, &p->integer);
+  HOST_WIDE_INT hwi = p->integer;
+  write_atom (ATOM_INTEGER, &hwi);
 }
   else
 {
@@ -2766,18 +2767,18 @@ static void
 mio_component (gfc_component *c, int vtype)
 {
   pointer_info *p;
-  int n;
 
   mio_lparen ();
 
   if (iomode == IO_OUTPUT)
 {
   p = get_pointer (c);
-  mio_integer (&p->integer);
+  mio_hwi (&p->integer);
 }
   else
 {
-  mio_integer (&n);
+  HOST_WIDE_INT n;
+  mio_hwi (&n);
   p = get_integer (n);
   associate_integer_pointer (p, c);
 }
@@ -5924,7 +5925,7 @@ write_symtree (gfc_symtree *st)
 
   mio_pool_string (&st->name);
   mio_integer (&st->ambiguous);
-  mio_integer (&p->integer);
+  mio_hwi (&p->integer);
 }
 
 

Re: [PATCH] PR 78534 Change character length from int to size_t

[Jerry DeLisle]

On 01/14/2017 12:46 AM, Janne Blomqvist wrote:
> On Sat, Jan 14, 2017 at 1:13 AM, Jerry DeLisle  wrote:
>> On 01/13/2017 11:46 AM, David Edelsohn wrote:
>>> On Fri, Jan 13, 2017 at 12:09 PM, Janne Blomqvist
>>>  wrote:
 On Thu, Jan 12, 2017 at 10:46 AM, FX  wrote:
>> I was finally able to get a 32-bit i686 compiler going (my attempts to
>> do this on a x86_64-pc-linux-gnu host failed, in the end I resorted to
>> running 32-bit builds/tests on a i686 container). At least on i686,
>> the patch below on top of the big charlen->size_t patch fixes the
>> failures
>
> Patch approved. The old code used gfc_extract_int, which bails out if a 
> non-constant expression is passed, so this is the right thing to do.
>
> FX

 Committed as r28.

 David, can you verify that it works alright on ppc?
>>>
>>> Unfortunately, no.  This patch broke bootstrap again with the same
>>> failure as earlier.
>>>
>>> - David
>>>
>>
>> Janne, can you access gcc112 on the compile farm? If not, I can, maybe I can
>> test the patch.
>>
>> Jerry
> 
> No, I don't have such access. I'd appreciate it very much if you'd
> have a go at it.  Attached is the r28 patch combined with the
> patch to fix the sanitizer bugs found by Dominique.
> 

I will try to do this tonight

Jerry

Re: [PATCH] Make rtl_split_edge work for jumps that fall through (PR72749)

[Segher Boessenkool]

On Sat, Jan 14, 2017 at 01:09:14PM -0600, Segher Boessenkool wrote:
> On Sat, Jan 14, 2017 at 05:55:48PM +, Segher Boessenkool wrote:
> > - && extract_asm_operands (PATTERN (last)) != NULL_RTX
> > + && (extract_asm_operands (last) || JUMP_LABEL (last) == before)
> 
> Somehow I removed the PATTERN there; retesting with it.  I'll test it
> on x86 as well, maybe it triggers there (it doesn't on PowerPC obviously).

Tested that on powerpc64-linux and x86_64-linux now; no failures.


Segher

Re: Fix ppc64le bootstrap comparison failure

[Andrew Pinski]

On Fri, Jan 13, 2017 at 10:24 PM, Jeff Law  wrote:
>
>
> Given a block with more than one dead store, one of which is the last
> statement in the block, the existence debugging statements can change the
> generated code which is of course bad.
>
> The problem is when I moved the code to delete the dead statement into its
> own function, I passed in the statement rather than the iterator. As a
> result  dse_dom_walker::before_dom_children would not see the iterator in
> the proper state and it would fail to walk all the statements if
> dse_optimize_stmt deleted the last statement in the block.
>
> In a debug build that scenario was much less likely to trigger because of
> the existence of debug statements.
>
> I'm installing this on the trunk now to fix the bootstrap issues.  I'll try
> to construct a testcase Monday.
>
> Bootstrapped and regression tested on x86_64-linux-gnu and ppc64-linux-gnu.
> Installing on the trunk.
>
> Sorry for the breakage.

This fixed the bootstrap issue I was seeing on aarch64-linux-gnu.

Thanks,
Andrew


>
> Jeff
>
> diff --git a/gcc/ChangeLog b/gcc/ChangeLog
> index 3c74b19..d07b1f5 100644
> --- a/gcc/ChangeLog
> +++ b/gcc/ChangeLog
> @@ -1,3 +1,14 @@
> +2017-01-13  Jeff Law  
> +
> +   PR tree-optimization/33562
> +   PR tree-optimization/61912
> +   PR tree-optimization/77485
> +   * tree-ssa-dse.c (delete_dead_call): Accept gsi rather than
> +   a statement.
> +   (delete_dead_assignment): Likewise.
> +   (dse_dom_walker::dse_optimize_stmt): Pass in the gsi rather than
> +   statement to delete_dead_call and delete_dead_assignment.
> +
>  2017-01-13  David Malcolm  
>
> PR c/78304
> diff --git a/gcc/tree-ssa-dse.c b/gcc/tree-ssa-dse.c
> index 20cf3b4..2e6f8ff 100644
> --- a/gcc/tree-ssa-dse.c
> +++ b/gcc/tree-ssa-dse.c
> @@ -600,10 +600,11 @@ private:
>void dse_optimize_stmt (gimple_stmt_iterator *);
>  };
>
> -/* Delete a dead call STMT, which is mem* call of some kind.  */
> +/* Delete a dead call at GSI, which is mem* call of some kind.  */
>  static void
> -delete_dead_call (gimple *stmt)
> +delete_dead_call (gimple_stmt_iterator *gsi)
>  {
> +  gimple *stmt = gsi_stmt (*gsi);
>if (dump_file && (dump_flags & TDF_DETAILS))
>  {
>fprintf (dump_file, "  Deleted dead call: ");
> @@ -612,13 +613,12 @@ delete_dead_call (gimple *stmt)
>  }
>
>tree lhs = gimple_call_lhs (stmt);
> -  gimple_stmt_iterator gsi = gsi_for_stmt (stmt);
>if (lhs)
>  {
>tree ptr = gimple_call_arg (stmt, 0);
>gimple *new_stmt = gimple_build_assign (lhs, ptr);
>unlink_stmt_vdef (stmt);
> -  if (gsi_replace (&gsi, new_stmt, true))
> +  if (gsi_replace (gsi, new_stmt, true))
>  bitmap_set_bit (need_eh_cleanup, gimple_bb (stmt)->index);
>  }
>else
> @@ -627,17 +627,18 @@ delete_dead_call (gimple *stmt)
>unlink_stmt_vdef (stmt);
>
>/* Remove the dead store.  */
> -  if (gsi_remove (&gsi, true))
> +  if (gsi_remove (gsi, true))
> bitmap_set_bit (need_eh_cleanup, gimple_bb (stmt)->index);
>release_defs (stmt);
>  }
>  }
>
> -/* Delete a dead store STMT, which is a gimple assignment. */
> +/* Delete a dead store at GSI, which is a gimple assignment. */
>
>  static void
> -delete_dead_assignment (gimple *stmt)
> +delete_dead_assignment (gimple_stmt_iterator *gsi)
>  {
> +  gimple *stmt = gsi_stmt (*gsi);
>if (dump_file && (dump_flags & TDF_DETAILS))
>  {
>fprintf (dump_file, "  Deleted dead store: ");
> @@ -649,9 +650,8 @@ delete_dead_assignment (gimple *stmt)
>unlink_stmt_vdef (stmt);
>
>/* Remove the dead store.  */
> -  gimple_stmt_iterator gsi = gsi_for_stmt (stmt);
>basic_block bb = gimple_bb (stmt);
> -  if (gsi_remove (&gsi, true))
> +  if (gsi_remove (gsi, true))
>  bitmap_set_bit (need_eh_cleanup, bb->index);
>
>/* And release any SSA_NAMEs set in this statement back to the
> @@ -717,7 +717,7 @@ dse_dom_walker::dse_optimize_stmt (gimple_stmt_iterator
> *gsi)
> }
>
>   if (store_status == DSE_STORE_DEAD)
> -   delete_dead_call (stmt);
> +   delete_dead_call (gsi);
>   return;
> }
>
> @@ -760,7 +760,7 @@ dse_dom_walker::dse_optimize_stmt (gimple_stmt_iterator
> *gsi)
>   && !gimple_clobber_p (use_stmt))
> return;
>
> -  delete_dead_assignment (stmt);
> +  delete_dead_assignment (gsi);
>  }
>  }
>
>

Re: [PATCH 2/6] RISC-V Port: gcc

[Joseph Myers]

On Sat, 14 Jan 2017, Karsten Merker wrote:

> So the actual ld.so binary should be called something like
> "ld-linux-rv.so.1" instead of just "ld.so.1". With everything
> else staying the same, that would give us a dynamic linker path
> along the lines of "/lib64/lp64f/ld-linux-rv.so.1" for an RV64G
> system.

For reference: a glibc port should include a proposed update to 
 listing all the supported ABI 
variants and corresponding dynamic linker paths.  (It should also include 
an update to glibc's build-many-glibcs.py to build at least one glibc 
configuration for each ABI variant.)

> Changing the linker path is of course an incompatible change, but
> RISC-V gcc support as submitted upstream now already incoporates
> a number of incompatible changes to the previous development
> versions (including a different dynamic linker path than older
> riscv-gcc versions), so moving from the previous development

And new glibc ports are expected to use the symbol version for the glibc 
release that actually gets the port (I'm supposing you might be aiming for 
2.26, although strictly the glibc release freeze needn't affect new ports 
that don't affect existing ports), not any older symbol version that might 
have been used in development.

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

[PATCH] ifcvt: Don't make invalid insns for a cond trap (PR78751)

[Segher Boessenkool]

As shown in the PR, ifcvt will happily make invalid insns when given the
chance.  This patch teaches it some manners.

Bootstrapped and tested on powerpc64-linux.  Is this okay for trunk?


Segher


2017-01-15  Segher Boessenkool  

PR rtl-optimization/78751
* ifcvt.c (find_cond_trap): If we generated a non-existing insn,
give up.

---
 gcc/ifcvt.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/gcc/ifcvt.c b/gcc/ifcvt.c
index 68c1a1d..6d30639 100644
--- a/gcc/ifcvt.c
+++ b/gcc/ifcvt.c
@@ -4686,6 +4686,11 @@ find_cond_trap (basic_block test_bb, edge then_edge, 
edge else_edge)
   if (seq == NULL)
 return FALSE;
 
+  /* If that results in an invalid insn, back out.  */
+  for (rtx_insn *x = seq; x; x = NEXT_INSN (x))
+if (recog_memoized (x) < 0)
+  return FALSE;
+
   /* Emit the new insns before cond_earliest.  */
   emit_insn_before_setloc (seq, cond_earliest, INSN_LOCATION (trap));
 
-- 
1.9.3

Re: Fix ppc64le bootstrap comparison failure

[Jeff Law]

On 01/14/2017 10:03 AM, David Edelsohn wrote:

On Sat, Jan 14, 2017 at 11:46 AM, Jeff Law  wrote:

On 01/14/2017 08:49 AM, David Edelsohn wrote:


Jeff,

The ppc64le bootstrap comparison may have been fixed, but I continue
to see the additional testsuite failures on AIX, all of the form:

internal compiler error: in fill_vec_av_set, at sel-sched.c:3712

I rolled back the earlier version of DSE patch and the failures were
resolved, so it definitely seems to be caused by the DSE patch.


I'm not seeing any new failures on ppc64le-linux.  I've got a big-endian ppc
system provisioning for testing just in case its an endianness issue.


powerpc64-unknown-linux-gnu (POWER7 BE) at r244463 (after your fix)
shows many failures:

https://gcc.gnu.org/ml/gcc-testresults/2017-01/msg01419.html
Found one bug; I'm not sure if it accounts for everything, but it 
probably covers anything involving sel-sched.  Bootstrapping and testing 
now to see if there's other stuff that needs investigation.


jeff

Re: [PATCH] Fix RTL sharing bug in loop-doloop.c (PR target/79080)

[Jeff Law]

On 01/14/2017 06:36 AM, Jakub Jelinek wrote:

Hi!

The force_operand on complex count expression in doloop_modify can invoke
various expander routines that are assuming there is rtl unsharing after
them (which is the case for expansion).  When later optimizations invoke
the expander (e.g. expand_mult in this case), they use
unshare_all_rtl_in_chain on the sequence.  The following patch does that for
doloop.  The count expression is already known not to be shared with
anything else (we do copy_rtx on it first and then create new rtls around it
if needed), so for that if it occurs just once in the sequence, we don't
need to unshare it.  For subexpression of condition I'm not sure, which is
why I've forced unsharing even if it occurs just once and is not shareable
part of the condition like REG.

Bootstrapped/regtested on powerpc64-linux, ok for trunk?

2017-01-14  Jakub Jelinek  

PR target/79080
* loop-doloop.c (doloop_modify): Call unshare_all_rtl_in_chain on
sequence.  Formatting fixes.
(doloop_optimize): Formatting fixes.

* gcc.dg/pr79080.c: New test.
So do we have a more general problem here -- we use force_operand in all 
kinds of contexts, particularly in the RTL loop optimizers.  If 
force_operand can introduce undesirable sharing, then isn't more code 
prone to this problem?


So just to be clear, I'm OK with this change as-is, I just worry we have 
other places that are structure sharing assumption problems waiting to 
happen.


jeff

Re: [PATCH] ifcvt: Don't make invalid insns for a cond trap (PR78751)

[Jeff Law]

On 01/14/2017 06:55 PM, Segher Boessenkool wrote:

As shown in the PR, ifcvt will happily make invalid insns when given the
chance.  This patch teaches it some manners.

Bootstrapped and tested on powerpc64-linux.  Is this okay for trunk?


Segher


2017-01-15  Segher Boessenkool  

PR rtl-optimization/78751
* ifcvt.c (find_cond_trap): If we generated a non-existing insn,
give up.
But isn't this a backend failing?  ISTM that gen_cond_trap just calls 
standard expansion routines and they should either have generated a 
valid sequence or NULL.


What in particular generated insn 64 and shouldn't it instead have 
indicated a failure?



Jeff

Re: [PATCH] Make rtl_split_edge work for jumps that fall through (PR72749)

[Jeff Law]

On 01/14/2017 10:55 AM, Segher Boessenkool wrote:

If a jump always falls through but that cannot be optimised away, like
is the case with the PowerPC bdnz insn if its jump target is the same as
the fallthrough, sched gets confused if it schedules some instructions
from before that jump instruction to behind it: it splits the
fallthrough branch, but the jump target isn't updated, and things fall
apart as in the PR.  This patch fixes it.

The second patch fragment makes -fsched-verbose=N work for N>=4; the
currently scheduled fragment can now contain a label.  Everything else
seems to work fine with that.

Tested on powerpc*-linux (with the testcase Alan checked in earlier
today); also bootstrapped on powerpc64-linux.  Is this okay for trunk?


Segher


2017-01-14  Segher Boessenkool  

PR target/72749
* cfgrtl.c (rtl_split_edge): Also patch jump insns that jump to the
fallthrough.
* haifa-sched.c (dump_insn_stream): Don't crash if there is a label
in the currently scheduled RTL fragment.
So presumably the semantics in this case can only mean one thing -- both 
the fallthru and the jump have to go to the same place after splitting. 
Right?  ISTM that ought to be documented in rtl_split_edge somewhere.


In this case is the edge a fallthru or branch edge?

And, no we don't make any guarantee about degenerate jumps -- a jump 
with a side effect in particular can easily survive.  I wouldn't be 
surprised if there's various bugs lurking for cases where we have a 
degenerate jump like that.  It's just not common enough to have been 
heavily exercised.


Patch with PATTERN fix is OK.

jeff

Re: [PATCH] ifcvt: Don't make invalid insns for a cond trap (PR78751)

[Segher Boessenkool]

On Sat, Jan 14, 2017 at 09:23:45PM -0700, Jeff Law wrote:
> But isn't this a backend failing?  ISTM that gen_cond_trap just calls 
> standard expansion routines and they should either have generated a 
> valid sequence or NULL.
> 
> What in particular generated insn 64 and shouldn't it instead have 
> indicated a failure?

ifcvt calls gen_cond_trap which then calls prepare_cmp_insn, which then
calls prepare_operand on the two arms, which ends up as copy_to_mode_reg
IIRC.  The instructions copy_to_mode_reg comes up with are *not* valid
machine insns; their RHS is ultimately given by what ifcvt called
gen_cond_trap with (the comparison of the *two* RHS together is a valid
instruction! -- well, a splitter; but there is no such trap insn).

I have tried to handle things in expand, but it is a) ugly and b) caused
problems all over the place.  I wonder if anyone can still modify any of
the expander code, sigh -- lots of rope there, and it's a maze.

ifcvt already has a lot of that "if we made a bad insn, back out", so it
fits well here.  This patch also is much less risky.


Segher

Re: [PATCH] Make rtl_split_edge work for jumps that fall through (PR72749)

[Segher Boessenkool]

On Sat, Jan 14, 2017 at 09:47:41PM -0700, Jeff Law wrote:
> > PR target/72749
> > * cfgrtl.c (rtl_split_edge): Also patch jump insns that jump to the
> > fallthrough.
> > * haifa-sched.c (dump_insn_stream): Don't crash if there is a label
> > in the currently scheduled RTL fragment.
> So presumably the semantics in this case can only mean one thing -- both 
> the fallthru and the jump have to go to the same place after splitting. 
> Right?  ISTM that ought to be documented in rtl_split_edge somewhere.

We could call patch_jump_insn in *all* cases, except for simple jumps
it does

  gcc_assert (JUMP_LABEL (insn) == old_label);

which is a useful check (for the other callers), and patch_jump_insn
isn't a very cheap routine to call anyway, better not do it too often.

> In this case is the edge a fallthru or branch edge?

Both!  You get only one edge if both jump targets are the same.

> And, no we don't make any guarantee about degenerate jumps -- a jump 
> with a side effect in particular can easily survive.  I wouldn't be 
> surprised if there's various bugs lurking for cases where we have a 
> degenerate jump like that.  It's just not common enough to have been 
> heavily exercised.
> 
> Patch with PATTERN fix is OK.

Thanks, I'll commit it tomorrow.


Segher

Re: [PATCH] Make rtl_split_edge work for jumps that fall through (PR72749)

[Jeff Law]

On 01/14/2017 10:27 PM, Segher Boessenkool wrote:

On Sat, Jan 14, 2017 at 09:47:41PM -0700, Jeff Law wrote:

PR target/72749
* cfgrtl.c (rtl_split_edge): Also patch jump insns that jump to the
fallthrough.
* haifa-sched.c (dump_insn_stream): Don't crash if there is a label
in the currently scheduled RTL fragment.

So presumably the semantics in this case can only mean one thing -- both
the fallthru and the jump have to go to the same place after splitting.
Right?  ISTM that ought to be documented in rtl_split_edge somewhere.


We could call patch_jump_insn in *all* cases, except for simple jumps
it does

  gcc_assert (JUMP_LABEL (insn) == old_label);

which is a useful check (for the other callers), and patch_jump_insn
isn't a very cheap routine to call anyway, better not do it too often.


In this case is the edge a fallthru or branch edge?


Both!  You get only one edge if both jump targets are the same.
Right.  To be more precise, my question was does it  have EDGE_FALLTHRU 
set?


Jeff

Re: [PATCH] ifcvt: Don't make invalid insns for a cond trap (PR78751)

[Jeff Law]

On 01/14/2017 10:11 PM, Segher Boessenkool wrote:

On Sat, Jan 14, 2017 at 09:23:45PM -0700, Jeff Law wrote:

But isn't this a backend failing?  ISTM that gen_cond_trap just calls
standard expansion routines and they should either have generated a
valid sequence or NULL.

What in particular generated insn 64 and shouldn't it instead have
indicated a failure?


ifcvt calls gen_cond_trap which then calls prepare_cmp_insn, which then
calls prepare_operand on the two arms, which ends up as copy_to_mode_reg
IIRC.  The instructions copy_to_mode_reg comes up with are *not* valid
machine insns; their RHS is ultimately given by what ifcvt called
gen_cond_trap with (the comparison of the *two* RHS together is a valid
instruction! -- well, a splitter; but there is no such trap insn).
So it's the  setup bits done by prepare_cmp_insn that are the problem 
and thus the test in gen_cond_trap isn't going to help.  Ugh.  AFAICT 
prepare_cmp_insn, through a series of calls, ends up in emit_move_insn 
which is just going to blindly emit the move and we've lost.  Sigh.


OK.  Let's go with your patch.

Thanks,
jeff

Re: [PATCH] Make rtl_split_edge work for jumps that fall through (PR72749)

[Segher Boessenkool]

On Sat, Jan 14, 2017 at 10:52:04PM -0700, Jeff Law wrote:
> >>In this case is the edge a fallthru or branch edge?
> >
> >Both!  You get only one edge if both jump targets are the same.
> Right.  To be more precise, my question was does it  have EDGE_FALLTHRU 
> set?

Yes:

 succ:   6 [92.5%]  (FALLTHRU,DFS_BACK,CAN_FALLTHRU)

Just after doloop created it it was two edges.  After fwprop it is just
one.  outof_cfglayout makes it two again (to different targets).  bbro
makes it one yet again.


Segher