[Bug fortran/84120] New: Syntax for used for PDT constructors is incorrect

[neil.n.carlson at gmail dot com]

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

Bug ID: 84120
   Summary: Syntax for used for PDT constructors is incorrect
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: neil.n.carlson at gmail dot com
  Target Milestone: ---

Consider the PDT

type foo(dim)
  integer,len :: dim
  integer :: array(dim)
end type

While investigating how other compilers do on the gfortran testsuite programs,
I discovered that gfortran would use the following syntax for a constructor for
the PDT:

type(foo(2)) :: x
x = foo(2,[1,2])

This is absolutely wrong.  The correct constructor syntax is

x = foo(2)([1,2])

The PDT implementation appears to have the misconception that type parameters
are (in part) regular components, but that is not so, they are two separate
things. See PR84119 for some related references to the standard.  In particular
here, see R455 for the constructor syntax (F08 standard), and R453 for the
derived-type-spec (e.g. "foo(2)"). Note that 1.3.33 defines what a "component"
is, and it does not include type parameters.

To summarize, gfortran works with this invalid example (Intel and NAG properly
reject it)

type foo(dim)
  integer,len :: dim
  integer :: array(dim)
end type
type(foo(:)), allocatable :: x
x = foo(2,[1,2])
if (size(x%array) /= 2) stop 1
if (any(x%array /= [1,2])) stop 2
end

But gfortran rejects this corrected valid example (works with Intel and NAG):

type foo(dim)
  integer,len :: dim
  integer :: array(dim)
end type
type(foo(:)), allocatable :: x
x = foo(2)([1,2])
if (size(x%array) /= 2) stop 1
if (any(x%array /= [1,2])) stop 2
end

 x = foo(2)([1,2])
 1
Error: Invalid character in name at (1)

Re: [PATCH] PR 80867: ICE during -O3 compile of libgnat

[Richard Biener]

On Mon, 29 Jan 2018, Kelvin Nilsen wrote:

> It was determined that the reported ICE occurs because a NULL value is
> passed from vectorizable_call () to
> 
>targetm.vectorize.builtin_md_vectorized_function (
>   callee, vectype_out, vectype_in).
> 
> This patch avoids making this call if callee equals NULL.
> 
> After successful bootstrap and regression testing, with preapproval,
> this patch has been committed to the trunk.
> 
> It it ok to backport to GCC 7 and GCC 6 (after testing on those
> platforms)?

OK.

Thanks,
Richard.

> Thanks.
> 
> 
> gcc/ChangeLog:
> 
> 2018-01-29  Richard Biener 
>   Kelvin Nilsen  
> 
>   PR bootstrap/80867
>   * tree-vect-stmts.c (vectorizable_call): Don't call
>   targetm.vectorize_builtin_md_vectorized_function if callee is
>   NULL.
> 
> Index: gcc/tree-vect-stmts.c
> ===
> --- gcc/tree-vect-stmts.c (revision 257105)
> +++ gcc/tree-vect-stmts.c (working copy)
> @@ -3159,7 +3159,7 @@
>if (cfn != CFN_LAST)
>   fndecl = targetm.vectorize.builtin_vectorized_function
> (cfn, vectype_out, vectype_in);
> -  else
> +  else if (callee)
>   fndecl = targetm.vectorize.builtin_md_vectorized_function
> (callee, vectype_out, vectype_in);
>  }
> 
> 

-- 
Richard Biener 
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 
21284 (AG Nuernberg)

[Bug tree-optimization/65968] Failure to remove casts, cause poor code generation

[lesliezhai at llvm dot org.cn]

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

Leslie Zhai  changed:

   What|Removed |Added

 CC||lesliezhai at llvm dot org.cn

--- Comment #2 from Leslie Zhai  ---
not generated poor code for Mips target:


.file   1 "t.c"
.section .mdebug.abi64
.previous
.nanlegacy
.module fp=64
.module oddspreg
.abicalls
.text
.align  2
.align  3
.globl  f
.setnomips16
.setnomicromips
.entf
.type   f, @function
f:
.frame  $sp,0,$31   # vars= 0, regs= 0/0, args= 0, gp= 0
.mask   0x,0
.fmask  0x,0
.setnoreorder
.setnomacro
li  $3,8388608  # 0x80
daddu   $3,$4,$3
.align  3
.L2:
lh  $2,0($4)
daddiu  $4,$4,2
mul $2,$2,$2
bne $3,$4,.L2
sh  $2,-2($4)

j   $31
nop

.setmacro
.setreorder
.endf
.size   f, .-f
.ident  "GCC: (GNU) 5.5.0 20171010 (LLVM China GCC 5.5-2018.01)"

Re: [PATCH][PR target/84064] Fix assertion with -fstack-clash-protection

[Uros Bizjak]

On Tue, Jan 30, 2018 at 5:48 AM, Jeff Law  wrote:
>
>
>
> stack-clash-protection will sometimes force a prologue to use pushes to
> save registers.  We try to limit how often that happens as it constrains
> options for generating efficient prologue sequences for common cases.
>
> We check the value of TO_ALLOCATE in ix86_compute_frame_layout and if
> it's greater than the probing interval, then we force the prologue to
> use pushes to save integer registers.  That is conservatively correct
> and allows freedom in the most common cases.  This is good.
>
> In expand_prologue we assert that the integer registers were saved via a
> push anytime we *might* generate a probe, even if the size of the
> allocated frame is too small to require explicit probing.  Naturally,
> this conflicts with the code in ix86_compute_frame_layout that tries to
> avoid forcing pushes instead of moves.
>
> This patch moves the assertion inside expand_prologue down to the points
> where it actually needs to be true.  Specifically when we're generating
> probes in a loop for -fstack-check or -fstack-clash-protection.
>
> [ Probing via calls to chkstk_ms is not affected by this change. ]
>
> Sorry to have to change this stuff for the 3rd time!

Now you see how many paths stack frame formation code has ;)

> Bootstrapped and regression tested on x86_64 and i686.  Also verified
> that if stack-clash checking is enabled by default that both compilers
> will bootstrap.
>
> OK for the trunk?

LGTM.

Thanks,
Uros.

> THanks,
> Jeff
>
> * i386.c (ix86_adjust_stack_and_probe_stack_clash): New argument
> INT_REGISTERS_SAVED.  Check it prior to calling
> get_scratch_register_on_entry.
> (ix86_adjust_stack_and_probe): Similarly.
> (ix86_emit_probe_stack_range): Similarly.
> (ix86_expand_prologue): Corresponding changes.
>
> * gcc.target/i386/pr84064: New test.
>
> diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
> index 3653ddd..fef34a1 100644
> --- a/gcc/config/i386/i386.c
> +++ b/gcc/config/i386/i386.c
> @@ -12591,10 +12591,14 @@ release_scratch_register_on_entry (struct 
> scratch_reg *sr)
> This differs from the next routine in that it tries hard to prevent
> attacks that jump the stack guard.  Thus it is never allowed to allocate
> more than PROBE_INTERVAL bytes of stack space without a suitable
> -   probe.  */
> +   probe.
> +
> +   INT_REGISTERS_SAVED is true if integer registers have already been
> +   pushed on the stack.  */
>
>  static void
> -ix86_adjust_stack_and_probe_stack_clash (const HOST_WIDE_INT size)
> +ix86_adjust_stack_and_probe_stack_clash (const HOST_WIDE_INT size,
> +const bool int_registers_saved)
>  {
>struct machine_function *m = cfun->machine;
>
> @@ -12700,6 +12704,12 @@ ix86_adjust_stack_and_probe_stack_clash (const 
> HOST_WIDE_INT size)
>  }
>else
>  {
> +  /* We expect the GP registers to be saved when probes are used
> +as the probing sequences might need a scratch register and
> +the routine to allocate one assumes the integer registers
> +have already been saved.  */
> +  gcc_assert (int_registers_saved);
> +
>struct scratch_reg sr;
>get_scratch_register_on_entry ();
>
> @@ -12758,10 +12768,14 @@ ix86_adjust_stack_and_probe_stack_clash (const 
> HOST_WIDE_INT size)
>emit_insn (gen_blockage ());
>  }
>
> -/* Emit code to adjust the stack pointer by SIZE bytes while probing it.  */
> +/* Emit code to adjust the stack pointer by SIZE bytes while probing it.
> +
> +   INT_REGISTERS_SAVED is true if integer registers have already been
> +   pushed on the stack.  */
>
>  static void
> -ix86_adjust_stack_and_probe (const HOST_WIDE_INT size)
> +ix86_adjust_stack_and_probe (const HOST_WIDE_INT size,
> +const bool int_registers_saved)
>  {
>/* We skip the probe for the first interval + a small dope of 4 words and
>   probe that many bytes past the specified size to maintain a protection
> @@ -12822,6 +12836,12 @@ ix86_adjust_stack_and_probe (const HOST_WIDE_INT 
> size)
>   equality test for the loop condition.  */
>else
>  {
> +  /* We expect the GP registers to be saved when probes are used
> +as the probing sequences might need a scratch register and
> +the routine to allocate one assumes the integer registers
> +have already been saved.  */
> +  gcc_assert (int_registers_saved);
> +
>HOST_WIDE_INT rounded_size;
>struct scratch_reg sr;
>
> @@ -12949,10 +12969,14 @@ output_adjust_stack_and_probe (rtx reg)
>  }
>
>  /* Emit code to probe a range of stack addresses from FIRST to FIRST+SIZE,
> -   inclusive.  These are offsets from the current stack pointer.  */
> +   inclusive.  These are offsets from the current stack pointer.
> +
> +   INT_REGISTERS_SAVED is true if integer registers have already been
> +   pushed on the 

Re: [AARCH64]Bug in fix for branch offsets over 1 MiB?

[Sameera Deshpande]

On 30 January 2018 at 09:28, Sameera Deshpande
 wrote:
> On 30-Jan-2018 2:37 AM, "Richard Sandiford" 
> wrote:
>
> Sameera Deshpande  writes:
>> Hi!
>>
>> I am seeing multiple assembler errors with error message "Error:
>> conditional branch out of range" for customer code.
>>
>> The root cause of the bug is that conditional branches are generated
>> whose branch target ends up being too far away to be encoded in the
>> instruction.  It appears that there was an attempt to fix this issue
>> in the below change:
>>
>> commit 050af05b9761f1979f11c151519e7244d5becd7c
>> Author: thopre01 
>> Date:   Thu Aug 27 10:08:54 2015 +
>>
>> 2015-08-27  Ramana Radhakrishnan
>> <[ramana.radhakrish...@arm.com|mailto:ramana.radhakrish...@arm.com]>
>> Andre Vieira
>> <[andre.simoesdiasvie...@arm.com|mailto:andre.simoesdiasvie...@arm.com]>
>>
>> gcc/
>> * config/aarch64/[aarch64.md|http://aarch64.md/] (*condjump):
>> Handle functions > 1 MiB.
>> (*cb1): Likewise.
>> (*tb1): Likewise.
>> (*cb1): Likewise.
>> * config/aarch64/[iterators.md|http://iterators.md/] (inv_cb):
>> New code attribute.
>> (inv_tb): Likewise.
>> * config/aarch64/aarch64.c (aarch64_gen_far_branch): New.
>> * config/aarch64/aarch64-protos.h (aarch64_gen_far_branch): New.
>>
>> gcc/testsuite/
>> * gcc.target/aarch64/long_branch_1.c: New test.
>>
>> However, as per GCC Internal documentation, only special attribute
>> "length" should use PC and match_dup while defining an attribute. I
>> verified by looking at code in final pass, and realised that
>> get_attribute_length does not map directly to the functions generated
>> from the definition of attribute length in RTL patterns, but computes
>> the lengths in shorten_branches and uses insn_current_length as
>> intermediate function.
>>
>> The far_branch attribute defined similar to attribute length expects
>> same values to be returned by (minus (match_dup 2) (pc)) which is
>> incorrect.
>>
>> I am looking at TARGET_MACHINE_DEPENDENT_REORG macro instead like few
>> other architectures, to emit far branches.
>>
>> Is that approach acceptable?
>
> I don't think we need to go that far.  The INSN_ADDRESSES should be
> correct when outputting the instructions, so does it work if we use
> those instead of get_attr_far_branch?
>
> Thanks,
> Richard
>
>> PS: I am waiting for customer's approval for attaching the test case.
>
>
> Hi Richard,
>
> Thanks for your reply. I will try using INSN_ADDRESSES and will get back to
> you.
>
> - Thanks and regards,
>   Sameera D.
>

Hi Richard,

I verified that it works. Thanks a lot! Will do the testing, and
update the patch.

-- 
- Thanks and regards,
  Sameera D.

Re: [PING^3] [PATCH] Remove CANADIAN, that break compilation for foreign target

[Petr Ovtchenkov]

On Tue, 19 Dec 2017 11:37:43 +0300
Petr Ovtchenkov  wrote:

ping^3

> On Thu, 16 Nov 2017 20:55:37 +0300
> Petr Ovtchenkov  wrote:
> 
> > On Wed, 20 Sep 2017 13:44:59 +0300
> > Petr Ovtchenkov  wrote:
> > 
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71212
> > > 
> > > On Fri, 20 May 2016 16:10:50 +0300
> > > Petr Ovtchenkov  wrote:
> > > 
> > > > Some old ad-hoc (adding -I/usr/include to compiler
> > > > flags) break compilation of libstdc++ for foreign
> > > > target architecture (due to compiler see includes
> > > > of native).
> > 
> > Reference for terms:
> > 
> > https://gcc.gnu.org/onlinedocs/gccint/Configure-Terms.html
> > 
> > Present of "CANADIAN=yes" lead to inclusion of
> > headers from build (-I/usr/include). "CANADIAN=yes" used _only_
> > to set "-I/usr/include".
> > 
> > Inclusion of build headers in cross-compilation
> > process is not a mistake only in case of native (i.e. it is mistake
> > for cross, for canadian, for crossed native and for crossback),
> > but sometimes give "success".
> > 
> > Note, that build/host/target may be different not only due to
> > different architectures, but due to different sysroots
> > (libc, kernel, binutils, etc.).
> > 
> > CANADIAN is set to "yes" by code
> > 
> > -  # If Canadian cross, then don't pick up tools from the build directory.
> > -  # Used only in GLIBCXX_EXPORT_INCLUDES.
> > -  if test -n "$with_cross_host" &&
> > - test x"$build_alias" != x"$with_cross_host" &&
> > - test x"$build" != x"$target";
> > -  then
> > -CANADIAN=yes
> > -  else
> > -CANADIAN=no
> > -  fi
> > 
> > and it add "-I/usr/include" to compiler flags for building libstdc++.
> > This is wrong.
> > 
> > Reference to patch:
> > https://gcc.gnu.org/ml/gcc-patches/2017-09/msg01332.html

New Spanish PO file for 'gcc' (version 8.1-b20180128)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

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

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

(This file, 'gcc-8.1-b20180128.es.po', has just now been sent to you in
a separate email.)

All other PO files for your package are available in:

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

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

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

The following HTML page has been updated:

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

If any question arises, please contact the translation coordinator.

Thank you for all your work,

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

Re: [PATCH] Fix SCEV ICE during cunroll (PR tree-optimization/84111)

[Jeff Law]

On 01/29/2018 04:37 PM, Jakub Jelinek wrote:
> Hi!
> 
> As mentioned in the PR, cunroll sometimes registers some SSA_NAMEs for
> renaming and then invokes some SCEV using functions before finally updating
> the SSA form.  On the testcase we end up with 3 degenerate PHIs pointing at
> each other, so follow_copies_to_constant loops forever.
I'm at a loss to understand how we could get in that situation.  Was it
edge removal (if so for which PHI) or the duplicate process that created
the loop?

We've seen one case where this happened inside DOM, but it was only
because we ignored an unexecutable edge which then caused a PHI to
become a degenerate.One or more of the PHI args in the degenerate
was marked as EDGE_DFS_BACK on its associated edge.

Are any of the PHI args in pr84111 marked in a similar manner?

> 
> The following patch has 2 different fixes for this, one is to avoid looking
> at SSA_NAMEs registered for update (in theory all we care are the old ssa
> names, but we don't have an API to query just those), the other is to put
> some upper bound on how many times we follow SSA_NAMEs (either single defs
> or degenerate phis).  Either of those changes is sufficient to fix this.
Interestingly enough I was looking at a bug several weeks ago where the
ability to query one of the sets (I can't remember if it was old or new)
of names for rewriting would have been useful.


> 
> During x86_64-linux and i686-linux bootstraps/regtests 
> follow_copies_to_constant
> actually never returned anything useful, so the patch doesn't regress at
> least on these targets anything, there are quite a few cases where SSA_NAME
> is name_registered_for_update_p but the function would never return anything
> but var in those cases.  And the highest depth ever seen was 3, except for
> the newly added testcase if the && !name_registered_for_update_p (res) part
> is commented out.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
> 
> 2018-01-29  Jakub Jelinek  
> 
>   PR tree-optimization/84111
>   * tree-scalar-evolution.c: Include tree-into-ssa.h.
>   (follow_copies_to_constant): Stop on SSA_NAMEs registered for update,
>   loop at most 128 times.
> 
>   * gcc.c-torture/compile/pr84111.c: New test.
Probably reasonable.  Though I would like to better understand how we
got the degenerates forming a loop before final ack.

jeff

[Bug fortran/84119] New: Type parameter inquiry for PDT returns array instead of scalar

[neil.n.carlson at gmail dot com]

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

Bug ID: 84119
   Summary: Type parameter inquiry for PDT returns array instead
of scalar
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: neil.n.carlson at gmail dot com
  Target Milestone: ---

There seems to be a misconception in the implementation of PDT that the type
parameters are (in part) just regular components of the type, so that for

type foo(a)
  integer, len :: a
end type
type(foo(a)) :: array(9)

the type inquiry array%a should give a rank-1 array of size 9. This is
incorrect. Type parameters are not components of the type. The F08 standard
clearly distinguishes between type parameter definition statements and
component definition statements. See R425, R431, R435, and in particular see
Note 6.7 which says "It [array%a, for example] is scalar even if designator is
an array."

Here's a test case that should pass.  GFortran will bail on both stop lines.

type :: vector(dim,kind)
  integer, len :: dim
  integer, kind :: kind
end type
type(vector(3,1)) :: a(10)
if (size(shape(a%dim)) /= 0) stop 1
if (size(shape(a%kind)) /= 0) stop 2
end

Re: Ping: Expand vec_perm_indices::series_p comment

[Jeff Law]

On 01/29/2018 01:38 PM, Richard Sandiford wrote:
> Ping
> 
> Richard Sandiford  writes:
>> James Greenhalgh  writes:
>>> On Thu, Jan 04, 2018 at 11:27:56AM +, Richard Sandiford wrote:
 Ping**2
>>>
>>> This is OK.
>>
>> Thanks.
>>
>>> It took me a while to get the hang of the interface - a worked example
>>> in the comment in vec-perm-indices.c would probably have been helpful.
>>> It took until your code for REV for this to really make sense to me; so
>>> perhaps that make for a good example.
>>
>> Yeah, good idea.
>>
>> Is the following OK?  Tested on aarch64-linux-gnu.
>>
>> Thanks,
>> Richard
>>
>>
>> 2018-01-09  Richard Sandiford  
>>
>> gcc/
>>  * vec-perm-indices.c (vec_perm_indices::series_p): Give examples
>>  of usage.
OK
jeff

[Bug target/83828] FAIL: gcc.target/i386/avx512vpopcntdqvl-vpopcntq-1.c execution test

[kyukhin at gcc dot gnu.org]

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

--- Comment #7 from Kirill Yukhin  ---
On the other hand, if masked variant of vpopcnt[w,q] is being issued: there's
no way for reload to put 32/64 bit mask into mask register, since kmov[d,q] are
only available  under -mavx512bw switch.

We can insist user to issue -mavx512bw along w/ -mavx512bitalg if she is going
to use masked variants of corresponding intrinsics. Then only tests need to be
fixed.

Re: [PATCH] Document --dynamic-list-data option for --coverage usage.

[Jeff Law]

On 01/26/2018 07:10 AM, Martin Liška wrote:
> Hi.
> 
> This explains why the option in $subject is needed when one uses dlopen
> API of a shared library.
> 
> Ready for trunk?
> Martin
> 
> gcc/ChangeLog:
> 
> 2018-01-26  Martin Liska  
> 
>   PR gcov-profile/83879
>   * doc/gcov.texi: Document necessity of --dynamic-list-data when
>   using dlopen functionality.
OK.
jeff

Re: Fix LRA subreg calculation for big-endian targets

[Jeff Law]

On 01/26/2018 06:25 AM, Richard Sandiford wrote:
> LRA was using a subreg offset of 0 whenever constraints matched
> two operands with different modes.  That leads to an invalid offset
> (and ICE) on big-endian targets if one of the modes is narrower
> than a word.  E.g. if a (reg:SI X) is matched to a (reg:QI Y),
> the big-endian subreg should be (subreg:QI (reg:SI X) 3) rather
> than (subreg:QI (reg:SI X) 0).
Yup.  That can't be right on big endian.

> 
> But this raises the issue of what the behaviour should be when the
> matched operands occupy different numbers of registers.  Should the
> register numbers match, or should the locations of the lsbs match?
> Although the documentation isn't clear, reload went for the second
> interpretation (which seems the most natural to me):
I can even recall seeing that interpretation in local-alloc.c and/or
global.c from eons ago in the context of register tying.  Both
essentially punted doing anything smart in that case anyway leading to
occasionally dreadful code for simple extensions.


> 
>   /* On a REG_WORDS_BIG_ENDIAN machine, point to the last register of a
>  multiple hard register group of scalar integer registers, so that
>  for example (reg:DI 0) and (reg:SI 1) will be considered the same
>  register.  */
> 
> So I think this means that we can/must use the lowpart offset
> unconditionally, rather than trying to separate out the multi-register
> case.  This also matches the LRA handling of constant integers, which
> already uses lowpart subregs.
> 
> The patch fixes gcc.target/aarch64/sve/extract_[34].c for aarch64_be.
> 
> Tested on aarch64_be-none-elf, aarch64-linux-gnu and x86_64-linux-gnu.
> OK to install?
> 
> 
> 2018-01-26  Richard Sandiford  
> 
> gcc/
>   * lra-constraints.c (match_reload): Use subreg_lowpart_offset
>   rather than 0 when creating partial subregs.
OK.  Makes me wonder how many big endian LRA targets are getting
significant use.

jeff

Re: [PATCH][testsuite] XFAIL gcc.dg/tree-ssa/ssa-dom-cse-2.c on non-NEON arm targets

[Jeff Law]

On 01/24/2018 04:31 AM, Kyrill Tkachov wrote:
> Hi all,
> 
> This test fails to optimise away the PLUS reduction in the loop on arm
> targets when vectorisation
> is not enabled due to absence of SIMD instructions.
> From reading the logs and the PR I gather that the presence or absence
> of SIMD affects the passing of this test
> on other targets as well, as evidenced by the long list of xfail targets.
> This list looks quite unwieldy to me, but here is a patch adding
> non-NEON arm to that list.
> Is this ok?
> 
> Or should we always force -mfpu=neon for arm targets instead? That's
> what we do for System Z,
> but from a purist perspective the loop has nothing vector-specific in it
> so a compiler should be
> able to reduce it regardless...
> 
> Thanks,
> Kyrill
> 
> 2018-01-24  Kyrylo Tkachov  
> 
>     * gcc.dg/tree-ssa/ssa-dom-cse-2.c: XFAIL on !arm_neon arm targets.
It does look rather unwieldy.  I wonder if we would be better off
manually unrolling the loop and conditionalizing it on some kind of
vector support.

But in the immediate term, adding another xfailed target is fine.

jeff

[Bug target/82666] [7/8 regression]: sum += (x>128 ? x : 0) puts the cmov on the critical path (at -O2)

[law at redhat dot com]

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

--- Comment #5 from Jeffrey A. Law  ---
Aldy,

It's less about whether or not there is a cmov (I get one with and without
PRE), but more about what part of the loop we're using the cmov for.

Consider what we get in the .optimized dump at -O3 correct.  But the target
*assembly* we want is what you'd get with -O3 -fno-tree-pre.  ie, PRE is making
it harder for us to generate the cmov we want.

[Bug target/83828] FAIL: gcc.target/i386/avx512vpopcntdqvl-vpopcntq-1.c execution test

[kyukhin at gcc dot gnu.org]

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

Kirill Yukhin  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||kyukhin at gcc dot gnu.org

--- Comment #6 from Kirill Yukhin  ---
Looks like avx512bw demand is excessive in avx512bitalgintrin.h

[Bug testsuite/81010] [8 regression] test case gcc.target/powerpc/pr56605.c fails starting with r248958

[law at gcc dot gnu.org]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com
  Component|tree-optimization   |testsuite

--- Comment #6 from Jeffrey A. Law  ---
Author: law
Date: Tue Jan 30 05:30:40 2018
New Revision: 257172

URL: https://gcc.gnu.org/viewcvs?rev=257172=gcc=rev
Log:
PR testsuite/81010
* gcc.target/powerpc/pr56605.c: Update various dg- directives to
better match other tests which require vsx.  Verify the zero
extension is part of the test in the combiner dump.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/powerpc/pr56605.c

[Bug testsuite/81010] [8 regression] test case gcc.target/powerpc/pr56605.c fails starting with r248958

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #7 from Jeffrey A. Law  ---
Fixed on the trunk.

Re: [PATCH] [PR testsuite/81010] Fix PPC test

[Jeff Law]

On 01/07/2018 10:09 AM, Segher Boessenkool wrote:
> Hi!
> 
> On Sun, Jan 07, 2018 at 12:58:25AM -0700, Jeff Law wrote:
>> As you note in the comments, the code we generate now is actually more
>> efficient so the test needs to be tweaked.
>>
>> Rather than checking the form in doloop, I check the form in .combine
>> and look for
>>
>> (compare:CC (zero_extend:DI (reg:SI
>>
>> The test is also twiddled to run on ppc64le.
>>
>> OK for the trunk?
>>
>> Jeff
> 
>>  PR testsuite/81010
>>  * gcc.target/powerpc/pr56605.c: Run on ppc64le too.  Verify
>>  the zero extension is part of the test in the combiner dump.
>>
>>
>>
>> diff --git a/gcc/testsuite/gcc.target/powerpc/pr56605.c 
>> b/gcc/testsuite/gcc.target/powerpc/pr56605.c
>> index 3bc335f..be6456c 100644
>> --- a/gcc/testsuite/gcc.target/powerpc/pr56605.c
>> +++ b/gcc/testsuite/gcc.target/powerpc/pr56605.c
>> @@ -1,7 +1,7 @@
>>  /* PR rtl-optimization/56605 */
>> -/* { dg-do compile { target { powerpc64-*-* && lp64 } } } */
>> +/* { dg-do compile { target { powerpc64*-*-* && lp64 } } } */
> 
> You could as well do powerpc*-*-* afaics?
> 
>>  /* { dg-skip-if "do not override -mcpu" { powerpc*-*-* } { "-mcpu=*" } { 
>> "-mcpu=power7" } } */
> 
> And you could delete this line, since nothing in the testcase _needs_ the
> -mcpu=power7.
> 
>> -/* { dg-options "-O3 -mvsx -mcpu=power7 -fno-unroll-loops 
>> -fdump-rtl-loop2_doloop" } */
>> +/* { dg-options "-O3 -mvsx -mcpu=power7 -fno-unroll-loops 
>> -fdump-rtl-combine" } */
> 
> Something should check powerpc_vsx_ok, hrm.  Or just remove -mvsx?
> 
>>  
>>  void foo (short* __restrict sb, int* __restrict ia)
>>  {
>> @@ -10,4 +10,4 @@ void foo (short* __restrict sb, int* __restrict ia)
>>  ia[i] = (int) sb[i];
>>  }
>>  
>> -/* { dg-final { scan-rtl-dump-times "\\\(compare:CC \\\(subreg:SI 
>> \\\(reg:DI" 1 "loop2_doloop" } } */
>> +/* { dg-final { scan-rtl-dump-times "\\\(compare:CC \\\(zero_extend:DI 
>> \\\(reg:SI" 1 "combine" } } */
> 
> Yay, toothpickeritus ;-)
> 
> But none of that is new, so okay with or without those extra cleanups.
I've implemented most of the cleanups suggested.  Essentially bringing
the dg selectors/options in line with other vsx tests.

As expected this is still unsupported on ppc32.  Also as expected if I
force it to run, it would fail because we don't have the problematical
conversions between SImode and DImode.

And (of course) we pass the updated test on ppc64 and ppc64le.  Attached
is the final version of the patch that I've installed.

Jeff
PR testsuite/81010
* gcc.target/powerpc/pr56605.c: Update various dg- directives to
better match other tests which require vsx.  Verify the zero
extension is part of the test in the combiner dump.

diff --git a/gcc/testsuite/gcc.target/powerpc/pr56605.c 
b/gcc/testsuite/gcc.target/powerpc/pr56605.c
index 3bc335f..dc87640 100644
--- a/gcc/testsuite/gcc.target/powerpc/pr56605.c
+++ b/gcc/testsuite/gcc.target/powerpc/pr56605.c
@@ -1,7 +1,9 @@
 /* PR rtl-optimization/56605 */
-/* { dg-do compile { target { powerpc64-*-* && lp64 } } } */
+/* { dg-do compile { target { powerpc*-*-* && lp64 } } } */
+/* { dg-skip-if "" { powerpc*-*-darwin* } } */
+/* { dg-require-effective-target powerpc_vsx_ok } */
 /* { dg-skip-if "do not override -mcpu" { powerpc*-*-* } { "-mcpu=*" } { 
"-mcpu=power7" } } */
-/* { dg-options "-O3 -mvsx -mcpu=power7 -fno-unroll-loops 
-fdump-rtl-loop2_doloop" } */
+/* { dg-options "-O3 -mvsx -mcpu=power7 -fno-unroll-loops -fdump-rtl-combine" 
} */
 
 void foo (short* __restrict sb, int* __restrict ia)
 {
@@ -10,4 +12,5 @@ void foo (short* __restrict sb, int* __restrict ia)
 ia[i] = (int) sb[i];
 }
 
-/* { dg-final { scan-rtl-dump-times "\\\(compare:CC \\\(subreg:SI \\\(reg:DI" 
1 "loop2_doloop" } } */
+/* { dg-final { scan-rtl-dump-times "\\\(compare:CC \\\(zero_extend:DI 
\\\(reg:SI" 1 "combine" } } */
+

[PATCH][PR target/84064] Fix assertion with -fstack-clash-protection

[Jeff Law]

stack-clash-protection will sometimes force a prologue to use pushes to
save registers.  We try to limit how often that happens as it constrains
options for generating efficient prologue sequences for common cases.

We check the value of TO_ALLOCATE in ix86_compute_frame_layout and if
it's greater than the probing interval, then we force the prologue to
use pushes to save integer registers.  That is conservatively correct
and allows freedom in the most common cases.  This is good.

In expand_prologue we assert that the integer registers were saved via a
push anytime we *might* generate a probe, even if the size of the
allocated frame is too small to require explicit probing.  Naturally,
this conflicts with the code in ix86_compute_frame_layout that tries to
avoid forcing pushes instead of moves.

This patch moves the assertion inside expand_prologue down to the points
where it actually needs to be true.  Specifically when we're generating
probes in a loop for -fstack-check or -fstack-clash-protection.

[ Probing via calls to chkstk_ms is not affected by this change. ]

Sorry to have to change this stuff for the 3rd time!

Bootstrapped and regression tested on x86_64 and i686.  Also verified
that if stack-clash checking is enabled by default that both compilers
will bootstrap.

OK for the trunk?

THanks,
Jeff
* i386.c (ix86_adjust_stack_and_probe_stack_clash): New argument
INT_REGISTERS_SAVED.  Check it prior to calling
get_scratch_register_on_entry.
(ix86_adjust_stack_and_probe): Similarly.
(ix86_emit_probe_stack_range): Similarly.
(ix86_expand_prologue): Corresponding changes.

* gcc.target/i386/pr84064: New test.

diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 3653ddd..fef34a1 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -12591,10 +12591,14 @@ release_scratch_register_on_entry (struct scratch_reg 
*sr)
This differs from the next routine in that it tries hard to prevent
attacks that jump the stack guard.  Thus it is never allowed to allocate
more than PROBE_INTERVAL bytes of stack space without a suitable
-   probe.  */
+   probe.
+
+   INT_REGISTERS_SAVED is true if integer registers have already been
+   pushed on the stack.  */
 
 static void
-ix86_adjust_stack_and_probe_stack_clash (const HOST_WIDE_INT size)
+ix86_adjust_stack_and_probe_stack_clash (const HOST_WIDE_INT size,
+const bool int_registers_saved)
 {
   struct machine_function *m = cfun->machine;
 
@@ -12700,6 +12704,12 @@ ix86_adjust_stack_and_probe_stack_clash (const 
HOST_WIDE_INT size)
 }
   else
 {
+  /* We expect the GP registers to be saved when probes are used
+as the probing sequences might need a scratch register and
+the routine to allocate one assumes the integer registers
+have already been saved.  */
+  gcc_assert (int_registers_saved);
+
   struct scratch_reg sr;
   get_scratch_register_on_entry ();
 
@@ -12758,10 +12768,14 @@ ix86_adjust_stack_and_probe_stack_clash (const 
HOST_WIDE_INT size)
   emit_insn (gen_blockage ());
 }
 
-/* Emit code to adjust the stack pointer by SIZE bytes while probing it.  */
+/* Emit code to adjust the stack pointer by SIZE bytes while probing it.
+
+   INT_REGISTERS_SAVED is true if integer registers have already been
+   pushed on the stack.  */
 
 static void
-ix86_adjust_stack_and_probe (const HOST_WIDE_INT size)
+ix86_adjust_stack_and_probe (const HOST_WIDE_INT size,
+const bool int_registers_saved)
 {
   /* We skip the probe for the first interval + a small dope of 4 words and
  probe that many bytes past the specified size to maintain a protection
@@ -12822,6 +12836,12 @@ ix86_adjust_stack_and_probe (const HOST_WIDE_INT size)
  equality test for the loop condition.  */
   else
 {
+  /* We expect the GP registers to be saved when probes are used
+as the probing sequences might need a scratch register and
+the routine to allocate one assumes the integer registers
+have already been saved.  */
+  gcc_assert (int_registers_saved);
+
   HOST_WIDE_INT rounded_size;
   struct scratch_reg sr;
 
@@ -12949,10 +12969,14 @@ output_adjust_stack_and_probe (rtx reg)
 }
 
 /* Emit code to probe a range of stack addresses from FIRST to FIRST+SIZE,
-   inclusive.  These are offsets from the current stack pointer.  */
+   inclusive.  These are offsets from the current stack pointer.
+
+   INT_REGISTERS_SAVED is true if integer registers have already been
+   pushed on the stack.  */
 
 static void
-ix86_emit_probe_stack_range (HOST_WIDE_INT first, HOST_WIDE_INT size)
+ix86_emit_probe_stack_range (HOST_WIDE_INT first, HOST_WIDE_INT size,
+const bool int_registers_saved)
 {
   /* See if we have a constant small number of probes to generate.  If so,
  that's the easy case.  The run-time loop is made 

libgo patch committed: Add getrandom syscall number for SH

[Ian Lance Taylor]

This patch by Tobias Klauser adds the GNU/Linux syscall number for SH.
Bootstrapped on x86_64-pc-linux-gnu.  Committed to mainline.

Ian
Index: gcc/go/gofrontend/MERGE
===
--- gcc/go/gofrontend/MERGE (revision 257163)
+++ gcc/go/gofrontend/MERGE (working copy)
@@ -1,4 +1,4 @@
-6517e6731aeb4512d12c341c7111959a44547ba0
+bbce8a9af264b25c5f70bafb2ce95d4fed158d68
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
Index: libgo/go/internal/syscall/unix/getrandom_linux_shx.go
===
--- libgo/go/internal/syscall/unix/getrandom_linux_shx.go   (nonexistent)
+++ libgo/go/internal/syscall/unix/getrandom_linux_shx.go   (working copy)
@@ -0,0 +1,11 @@
+// Copyright 2018 The Go Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style
+// license that can be found in the LICENSE file.
+
+// +build sh shbe
+
+package unix
+
+// Linux getrandom system call number.
+// See GetRandom in getrandom_linux.go.
+const randomTrap uintptr = 373

Re: [PATCH] [PR testsuite/81010] Fix PPC test

[Jeff Law]

On 01/07/2018 10:09 AM, Segher Boessenkool wrote:
> Hi!
> 
> On Sun, Jan 07, 2018 at 12:58:25AM -0700, Jeff Law wrote:
>> As you note in the comments, the code we generate now is actually more
>> efficient so the test needs to be tweaked.
>>
>> Rather than checking the form in doloop, I check the form in .combine
>> and look for
>>
>> (compare:CC (zero_extend:DI (reg:SI
>>
>> The test is also twiddled to run on ppc64le.
>>
>> OK for the trunk?
>>
>> Jeff
> 
>>  PR testsuite/81010
>>  * gcc.target/powerpc/pr56605.c: Run on ppc64le too.  Verify
>>  the zero extension is part of the test in the combiner dump.
>>
>>
>>
>> diff --git a/gcc/testsuite/gcc.target/powerpc/pr56605.c 
>> b/gcc/testsuite/gcc.target/powerpc/pr56605.c
>> index 3bc335f..be6456c 100644
>> --- a/gcc/testsuite/gcc.target/powerpc/pr56605.c
>> +++ b/gcc/testsuite/gcc.target/powerpc/pr56605.c
>> @@ -1,7 +1,7 @@
>>  /* PR rtl-optimization/56605 */
>> -/* { dg-do compile { target { powerpc64-*-* && lp64 } } } */
>> +/* { dg-do compile { target { powerpc64*-*-* && lp64 } } } */
> 
> You could as well do powerpc*-*-* afaics?
I guess, but I suspect the lp64 test would prevent it from running on
the 32bit configurations anyway.  And we probably are reliant on 64bits
to expose the problematical conversions that we weren't handling well
which led to 56605.

> 
>>  /* { dg-skip-if "do not override -mcpu" { powerpc*-*-* } { "-mcpu=*" } { 
>> "-mcpu=power7" } } */
> 
> And you could delete this line, since nothing in the testcase _needs_ the
> -mcpu=power7.
Your later message indicates we should leave this as-is.  So that's my
plan here.

> 
>> -/* { dg-options "-O3 -mvsx -mcpu=power7 -fno-unroll-loops 
>> -fdump-rtl-loop2_doloop" } */
>> +/* { dg-options "-O3 -mvsx -mcpu=power7 -fno-unroll-loops 
>> -fdump-rtl-combine" } */
> 
> Something should check powerpc_vsx_ok, hrm.  Or just remove -mvsx?
I think we should check powerpc_vsx_ok -- If I understand 56605
correctly ivopts/vectorization created the problematical gimple that
when converted to RTL wasn't handled well.  So we probably want to run
the test on any 64bit ppc with VSX capabilities.

WRT whether or not the test has any value, it still seems to be testing
for whether or not we're able to simplify stuff appropriately, so I
think keeping it probably makes the most sense.  RTL testing/scanning is
painful.

I'll do a bit of sniff testing around the suggestions you've made and
commit something reasonable :-)

Jeff

Re: [AARCH64]Bug in fix for branch offsets over 1 MiB?

[Sameera Deshpande]

On 30-Jan-2018 2:37 AM, "Richard Sandiford" 
wrote:

Sameera Deshpande  writes:
> Hi!
>
> I am seeing multiple assembler errors with error message "Error:
> conditional branch out of range" for customer code.
>
> The root cause of the bug is that conditional branches are generated
> whose branch target ends up being too far away to be encoded in the
> instruction.  It appears that there was an attempt to fix this issue
> in the below change:
>
> commit 050af05b9761f1979f11c151519e7244d5becd7c
> Author: thopre01 
> Date:   Thu Aug 27 10:08:54 2015 +
>
> 2015-08-27  Ramana Radhakrishnan
> <[ramana.radhakrish...@arm.com|mailto:ramana.radhakrish...@arm.com]>
> Andre Vieira
> <[andre.simoesdiasvie...@arm.com|mailto:andre.simoesdiasvie...@arm.com]>
>
> gcc/
> * config/aarch64/[aarch64.md|http://aarch64.md/] (*condjump):
> Handle functions > 1 MiB.
> (*cb1): Likewise.
> (*tb1): Likewise.
> (*cb1): Likewise.
> * config/aarch64/[iterators.md|http://iterators.md/] (inv_cb):
> New code attribute.
> (inv_tb): Likewise.
> * config/aarch64/aarch64.c (aarch64_gen_far_branch): New.
> * config/aarch64/aarch64-protos.h (aarch64_gen_far_branch): New.
>
> gcc/testsuite/
> * gcc.target/aarch64/long_branch_1.c: New test.
>
> However, as per GCC Internal documentation, only special attribute
> "length" should use PC and match_dup while defining an attribute. I
> verified by looking at code in final pass, and realised that
> get_attribute_length does not map directly to the functions generated
> from the definition of attribute length in RTL patterns, but computes
> the lengths in shorten_branches and uses insn_current_length as
> intermediate function.
>
> The far_branch attribute defined similar to attribute length expects
> same values to be returned by (minus (match_dup 2) (pc)) which is
> incorrect.
>
> I am looking at TARGET_MACHINE_DEPENDENT_REORG macro instead like few
> other architectures, to emit far branches.
>
> Is that approach acceptable?

I don't think we need to go that far.  The INSN_ADDRESSES should be
correct when outputting the instructions, so does it work if we use
those instead of get_attr_far_branch?

Thanks,
Richard

> PS: I am waiting for customer's approval for attaching the test case.


Hi Richard,

Thanks for your reply. I will try using INSN_ADDRESSES and will get back to
you.

- Thanks and regards,
  Sameera D.

[Bug rtl-optimization/83530] [8 Regression] ICE in reset_sched_cycles_in_current_ebb, at sel-sched.c:7150

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

 CC||pthaugen at gcc dot gnu.org

--- Comment #6 from Aldy Hernandez  ---
Started with r243866.

commit 11082703aaa77f9d9587937d006a572cd7a1066a
Author: pthaugen 
Date:   Wed Dec 21 19:15:32 2016 +

PR rtl-optimization/11488
* common/config/rs6000/rs6000-common.c
(rs6000_option_optimization_table): Enable -fsched-pressure.
* config/rs6000/rs6000.c (TARGET_COMPUTE_PRESSURE_CLASSES): Define
target hook.
(rs6000_option_override_internal): Set default -fsched-pressure
algorithm.
(rs6000_compute_pressure_classes): Implement target hook.

[Bug rtl-optimization/83147] LRA inheritance undo on multiple sets problem

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

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

Re: [patches] Re: [PATCH] RISC-V: Support for FreeBSD

[Kito Cheng]

Hi Bernhard:

Thanks your comment, I'll update that :)

Hi Jim:

> I don't see a copyright assigment for Ruslan.  This patch is big enough that 
> it requires one.

I'll ask him for that.

> The config.gcc patch is including dbxelf.h.  Stabs support is obsolete and 
> unmaintained.  Do you really need this?  If you include this, it will 
> probably just be dropped soon after the gcc-8 release anyways, so it is 
> probably better to not include it in the first place.

I'll try to remove that, thanks :)

> The libgcc/config.host patch is including files that weren't included in the 
> patch.

Oh, okay, I guess it's something port from older freebsd riscv-gcc, I
should update that, thanks.

On Tue, Jan 30, 2018 at 4:28 AM, Jim Wilson  wrote:
> On 01/28/2018 07:26 PM, Kito Cheng wrote:
>>
>> gcc/ChangeLog
>>
>> 2018-01-29  Ruslan Bukin  
>>  Kito Cheng  
>>
>>  * config.gcc (riscv*-*-freebsd*): New.
>>  * config/riscv/freebsd.h: New.
>>
>> libgcc/ChangeLog
>>
>> 2018-01-29  Ruslan Bukin  
>>
>>  * libgcc/config.host: Support RISC-V FreeBSD.
>
>
> I don't see a copyright assigment for Ruslan.  This patch is big enough that
> it requires one.
>
> The config.gcc patch is including dbxelf.h.  Stabs support is obsolete and
> unmaintained.  Do you really need this?  If you include this, it will
> probably just be dropped soon after the gcc-8 release anyways, so it is
> probably better to not include it in the first place.
>
> The libgcc/config.host patch is including files that weren't included in the
> patch.
>
> Jim
>
> --
> You received this message because you are subscribed to the Google Groups
> "RISC-V Patches" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to patches+unsubscr...@groups.riscv.org.
> To post to this group, send email to patc...@groups.riscv.org.
> Visit this group at
> https://groups.google.com/a/groups.riscv.org/group/patches/.
> To view this discussion on the web visit
> https://groups.google.com/a/groups.riscv.org/d/msgid/patches/b9b59f94-7699-b3f3-0eb8-b06c033c0423%40sifive.com.
>
> For more options, visit
> https://groups.google.com/a/groups.riscv.org/d/optout.

Re: [PATCH, rs6000] Fix PR56010 and PR83743, -mcpu=native use wrong names

[Peter Bergner]

On 1/29/18 6:15 PM, Segher Boessenkool wrote:
>> The current version of that code looks like the following, which I should
>> copy instead.  Unless you have a different suggestion?
> 
> Looks better yeah :-)  Probably candidates_list_and_hint does similar
> nasty character counting, but we don't have to look at it ;-)

It does, but as I mention in the other reply, I don't think we want this,
since the user used a valid option argument (ie, "native") and we don't
want to give a "hint" as a valid option, since their option was valid.
Like I said in the other reply, I think we do want the code the patch
showed.

Either that, or I could still call candidates_list_and_hint() and just
throw the hint away, since it's meaningless.

Peter

[Bug tree-optimization/82604] [8 Regression] SPEC CPU2006 410.bwaves ~50% performance regression with trunk@253679 when ftree-parallelize-loops is used

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

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

[Bug rtl-optimization/83530] [8 Regression] ICE in reset_sched_cycles_in_current_ebb, at sel-sched.c:7150

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

 Status|REOPENED|NEW

--- Comment #5 from Aldy Hernandez  ---
Ok, cpu makes a difference.  Thanks.

Confirmed with a cross to --target=powerpc-linux-gnu and:

./cc1 ~/a.c -quiet -O2 -fmodulo-sched -fselective-scheduling2 -I./ -mcpu=power7

Plus the following to make up for the missing assembler:

diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index 145ac86..0a8fa6a 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c   
@@ -4132,6 +4132,7 @@ rs6000_option_override_internal (bool global_init_p)
default:
  break;
}
+  unavailable_cpu=0;
   if (unavailable_cpu)
{
  cpu_index = -1;

[Bug rtl-optimization/84068] [8 Regression] ICE: qsort checking failed: qsort comparator non-negative on sorted output: 1 with -fno-sched-critical-path-heuristic --param=max-sched-extend-regions-iters

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

 CC||wdijkstr at arm dot com,
   ||wilco at gcc dot gnu.org

--- Comment #2 from Aldy Hernandez  ---
This may be a latent bug when the scheduling pressure model was changed, but
FWIW, this started with r254378.

Re: [PATCH, rs6000] Fix PR56010 and PR83743, -mcpu=native use wrong names

[Peter Bergner]

On 1/29/18 6:30 PM, Segher Boessenkool wrote:
> On Mon, Jan 29, 2018 at 02:54:15PM -0600, Peter Bergner wrote:
> Why don't you want that?  It let's the compiler say "hey silly human who
> can hardly type his own name correctly(*), you meant -mcpu-power8 where
> you said -mcpu=poewr8".  It's a quite useful feature.  Also amusing in
> the cases where it fails spectacularly :-)>
> Plus, removing support for that would be a regression.

We don't want it, because we're only in this code if the user typed
-mcpu=native (a valid option) and the kernel gave us something we don't
know/understand.  If instead the user typed -mcpu=, then they
will go thru the opts-common.c code I showed and get the same error they've
always gotten, so it's not a regression.

For example, the new error when using -mcpu=native gives:

gcc -S -O1 -mcpu=native simple.c
xgcc: fatal error: Unsupported cpu name returned from kernel for -mcpu=native: 
power9
Please use an explicit cpu name.  Valid cpu names are: 401 403 405 405fp 440 
440fp 464 464fp 476 476fp 505 601 602 603 603e 604 604e 620 630 740 7400 7450 
750 801 821 823 8540 8548 a2 e300c2 e300c3 e500mc e500mc64 e5500 e6500 860 970 
cell ec603e G3 G4 G5 titan power3 power4 power5 power5+ power6 power6x power7 
power8 powerpc powerpc64 powerpc64le rs64
compilation terminated.

While -mcpu=, you get the old error:

gcc -S -O1 -mcpu=foobar simple.c
xgcc: error: unrecognized argument in option ‘-mcpu=foobar’
xgcc: note: valid arguments to ‘-mcpu=’ are: 401 403 405 405fp 440 440fp 464 
464fp 476 476fp 505 601 602 603 603e 604 604e 620 630 740 7400 7450 750 801 821 
823 8540 8548 860 970 G3 G4 G5 a2 cell e300c2 e300c3 e500mc e500mc64 e5500 
e6500 ec603e native power3 power4 power5 power5+ power6 power6x power7 power8 
powerpc powerpc64 powerpc64le rs64 titan


Peter

[Bug rtl-optimization/83530] [8 Regression] ICE in reset_sched_cycles_in_current_ebb, at sel-sched.c:7150

[asolokha at gmx dot com]

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

Arseny Solokha  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|WORKSFORME  |---

--- Comment #4 from Arseny Solokha  ---
gcc/sel-sched.c:7150 in r255766 became sel-sched.c:7155 in 257131, which is

7149if (sched_verbose >= 2)
7150  {
7151sel_print ("scheduled insn %d, clock %d\n", INSN_UID (insn),
7152   haifa_clock + 1);
7153debug_state (curr_state);
7154  }
7155gcc_assert (cost < 0);
7156  }
7157
7158  if (targetm.sched.variable_issue)
7159targetm.sched.variable_issue (sched_dump, sched_verbose, insn, 0);

(In reply to Aldy Hernandez from comment #3)
> I tried again with latest trunk but still can't reproduce.  I even tried on
> a native PPC big endian box running in 32 bit mode (setarch).

% for cpu in 401 403 405 405fp 440 440fp 464 464fp 476 476fp 505 601 602 603
603e 604 604e 620 630 740 7400 7450 750 801 821 823 8540 8548 860 970 G3 G4 G5
a2 cell e300c2 e300c3 e500mc e500mc64 e5500 e6500 ec603e power3 power4 power5
power5+ power6 power6x power7 power8 power9 powerpc powerpc64 powerpc64le rs64
titan; do powerpc-e300c3-linux-gnu-gcc-8.0.0-alpha20180128 -mcpu=$cpu -O2
-fmodulo-sched -fselective-scheduling2 -c tt.c || echo $cpu; done
during RTL pass: sched2
tt.c: In function 'ny':
tt.c:13:1: internal compiler error: in reset_sched_cycles_in_current_ebb, at
sel-sched.c:7155
 }
 ^
0xc08418 reset_sched_cycles_in_current_ebb
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180128/work/gcc-8-20180128/gcc/sel-sched.c:7155
0xc08418 sel_region_target_finish
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180128/work/gcc-8-20180128/gcc/sel-sched.c:7228
0xc08418 sel_region_finish
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180128/work/gcc-8-20180128/gcc/sel-sched.c:7284
0xc08418 sel_sched_region(int)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180128/work/gcc-8-20180128/gcc/sel-sched.c:7647
0xc08641 run_selective_scheduling()
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180128/work/gcc-8-20180128/gcc/sel-sched.c:7718
0xbdf4bd rest_of_handle_sched2
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180128/work/gcc-8-20180128/gcc/sched-rgn.c:3729
0xbdf4bd execute
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-8.0.0_alpha20180128/work/gcc-8-20180128/gcc/sched-rgn.c:3873
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
zsh: exit 1 powerpc-e300c3-linux-gnu-gcc-8.0.0-alpha20180128 -mcpu=$cpu -O2
-fmodulo-sche
power7

So apparently the processor-specific scheduling parameters play a role here.

(In reply to Aldy Hernandez from comment #3)
> Reporter also
> filed PR84090, which also can't be reproduced by at least two people.

I wonder what exactly this is supposed to mean. The ICE reported in PR84090 had
indeed gone between r256935 and r257131 and that would be sorted out by me
later this week anyway.

[Bug fortran/82086] namelist read with repeat count fails when item is member of array of structures

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

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

--- Comment #9 from Jerry DeLisle  ---
OK, will see what I can do.

[Bug middle-end/84089] [8 Regression] FAIL: g++.dg/cpp1y/lambda-generic-x.C -std=gnu++14 (internal compiler error)

[dave.anglin at bell dot net]

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

--- Comment #2 from dave.anglin at bell dot net ---
Attached.

[Bug rtl-optimization/84068] [8 Regression] ICE: qsort checking failed: qsort comparator non-negative on sorted output: 1 with -fno-sched-critical-path-heuristic --param=max-sched-extend-regions-iters

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-01-30
 CC||aldyh at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Aldy Hernandez  ---
Confirmed.

[Bug middle-end/84089] [8 Regression] FAIL: g++.dg/cpp1y/lambda-generic-x.C -std=gnu++14 (internal compiler error)

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2018-01-30
 CC||aldyh at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Aldy Hernandez  ---
Would you mind attaching a preprocessed testcase so this can be reproduced with
a cross compiler?  The failing testcase includes , and I don't have
hpux headers :).

[Bug lto/84105] [8 regression] Segmentation fault in pp_tree_identifier() during LTO

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

  Attachment #43282|0   |1
is obsolete||

--- Comment #6 from Aldy Hernandez  ---
Created attachment 43283
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43283=edit
untested patch

Actual untested patch :).

[Bug lto/84105] [8 regression] Segmentation fault in pp_tree_identifier() during LTO

[aldyh at gcc dot gnu.org]

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

--- Comment #5 from Aldy Hernandez  ---
Created attachment 43282
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43282=edit
untested patch

Proposed patch in testing.

[Bug lto/84105] [8 regression] Segmentation fault in pp_tree_identifier() during LTO

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #4 from Aldy Hernandez  ---
Started with r256685.

The problem is in dump_generic_node:

case FUNCTION_TYPE:
case METHOD_TYPE:
...
  if (TYPE_NAME (node) && DECL_NAME (TYPE_NAME (node)))
dump_decl_name (pp, TYPE_NAME (node), flags);

(gdb) print node
$21 = 
(gdb) print node.type_common.name
$22 = 

TYPE_NAME is an IDENTIFIER_NODE, whereas we're expecting a DECL_P, and we ICE.

Contents of PO file 'cpplib-8.1-b20180128.de.po'

[Translation Project Robot]

cpplib-8.1-b20180128.de.po.gz
Description: Binary data
The Translation Project robot, in the
name of your translation coordinator.

New German PO file for 'cpplib' (version 8.1-b20180128)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

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

http://translationproject.org/latest/cpplib/de.po

(This file, 'cpplib-8.1-b20180128.de.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/cpplib/

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

[Bug libstdc++/84118] New: filesystem::path concat does not accept value_type

[ethan at ethanhs dot me]

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

Bug ID: 84118
   Summary: filesystem::path concat does not accept value_type
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ethan at ethanhs dot me
  Target Milestone: ---

As I have read the filesystem TS, I believe concat on path items should have an
overload following:

path& operator+=(value_type x);

However, on trying to use 7.2.0 this overload seems not to work correctly.

https://wandbox.org/permlink/S4DZ3witD15xz0lT

TL;DR it would allow for constructs such as
.concat(fs::path::preferred_separator)

Re: [PATCH, rs6000] Fix PR56010 and PR83743, -mcpu=native use wrong names

[Segher Boessenkool]

On Mon, Jan 29, 2018 at 02:54:15PM -0600, Peter Bergner wrote:
> On 1/29/18 2:33 PM, Peter Bergner wrote:
> > The current version of that code looks like the following, which I should
> > copy instead.  Unless you have a different suggestion?
> > 
> >   char *s;
> > 
> >   if (e->unknown_error)
> > error_at (loc, e->unknown_error, arg);
> >   else
> > error_at (loc, "unrecognized argument in option %qs", opt);
> > 
> >   auto_vec  candidates;
> >   for (i = 0; e->values[i].arg != NULL; i++)
> > {
> >   if (!enum_arg_ok_for_language (>values[i], lang_mask))
> > continue;
> >   candidates.safe_push (e->values[i].arg);
> > }
> >   const char *hint = candidates_list_and_hint (arg, s, candidates);
> >   if (hint)
> > inform (loc, "valid arguments to %qs are: %s; did you mean %qs?",
> > option->opt_text, s, hint);
> >   else
> > inform (loc, "valid arguments to %qs are: %s", option->opt_text, s);
> >   XDELETEVEC (s);
> 
> Actually, all the "macic" of this code happens in candidates_list_and_hint()
> and that looks much like the GCC 5 code I showed, plus a call to
> find_closest_string() which we don't want, so I think just sticking with
> the original code in the last patch is probably best.

Why don't you want that?  It let's the compiler say "hey silly human who
can hardly type his own name correctly(*), you meant -mcpu-power8 where
you said -mcpu=poewr8".  It's a quite useful feature.  Also amusing in
the cases where it fails spectacularly :-)

Plus, removing support for that would be a regression.

(*) not talking about myself here, oh no.


Segher

Re: [PATCH, rs6000] Fix PR56010 and PR83743, -mcpu=native use wrong names

[Segher Boessenkool]

Hi!

On Mon, Jan 29, 2018 at 02:33:50PM -0600, Peter Bergner wrote:
> On 1/29/18 1:23 PM, Segher Boessenkool wrote:
> >> +#ifdef __linux__
> >> +/* Canonical GCC cpu name table.  */
> >> +static const char *rs6000_supported_cpu_names[] =
> >> +{
> >> +#define RS6000_CPU(NAME, CPU, FLAGS) NAME,
> >> +#include "rs6000-cpus.def"
> >> +#undef RS6000_CPU
> >> +};
> > 
> > Can't you just use processor_target_table here?  Seems like a waste to
> > duplicate all that.  (Need to make the table non-static then of course).
> 
> Changing it to static won't help, because we don't link rs6000.o into
> xgcc.  That file is linked into cc1, etc, so we don't have access to it.

Oh ah, tricky.  Fine as is then.

> Well, this isn't fprintf that I can call multiple times to emit my entire
> error message.  Once you call fatal_error(), it never returns, so I copied
> the way opts-common.c:cmdline_handle_error() emits its error message which
> is to build it up and then emit it altogether like thishowever, I now
> see I copied GCC 5's version of this code.  Doh! :-)
> 
> The current version of that code looks like the following, which I should
> copy instead.  Unless you have a different suggestion?

Looks better yeah :-)  Probably candidates_list_and_hint does similar
nasty character counting, but we don't have to look at it ;-)


Segher


>   char *s;
> 
>   if (e->unknown_error)
> error_at (loc, e->unknown_error, arg);
>   else
> error_at (loc, "unrecognized argument in option %qs", opt);
> 
>   auto_vec  candidates;
>   for (i = 0; e->values[i].arg != NULL; i++)
> {
>   if (!enum_arg_ok_for_language (>values[i], lang_mask))
> continue;
>   candidates.safe_push (e->values[i].arg);
> }
>   const char *hint = candidates_list_and_hint (arg, s, candidates);
>   if (hint)
> inform (loc, "valid arguments to %qs are: %s; did you mean %qs?",
> option->opt_text, s, hint);
>   else
> inform (loc, "valid arguments to %qs are: %s", option->opt_text, s);
>   XDELETEVEC (s);

[Bug c++/83503] [8 Regression] bogus -Wattributes for const and pure on function template specialization

[msebor at gcc dot gnu.org]

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

--- Comment #14 from Martin Sebor  ---
Yes, the attribute affects all callers in the same translation unit and so it
needs to match across both the declarations and the definition.

I (and others) tested Glibc with this patch and if this had been an idiom there
I would have seen it or heard about it.  AFAIK, Glibc uses private symbols for
internal calls and those are aliases for the external symbols.  An alias can be
declared with one attribute even though its target is declared with another,
and GCC silently accepts it.  This, however, is a potential bug that Joseph
requested a warning for in pr81824.  I promised I'd work on it after I was done
with pr81544 but didn't get to it.

You seem to be making the argument that this warning is valuable only if it
points out bona fide bugs and that it is unacceptable when it, even in rare
instances, is issued for strictly safe/correct code, no matter how contrived or
esoteric the instances are and even if the code is questionable.

That's not a realistic expectation to have.  For every warning that points out
a meaningless or ambiguous construct there will always be examples where the
construct is safe.  If we held all warnings to this standard then we'd have to
cut the number of warnings GCC issues in half.  Have you ever did an analysis
of the rate of true vs false positives for -Wimplicit-fallthrough for instance?
 Or -Wignored-qualifiers, or -Wmissing-braces, or -Wparentheses, etc.  For all
of these one can come up with a more or less of an unusual use case that's not
strictly incorrect but that GCC warns for regardless.  In the cases of all
these warning options we've accepted that the gains of the true positives
outweigh the costs of false positives.  And in some cases, the costs have been
quite considerable.

But the fact aside that this report is not an example of a false positive due
to the use case you've contrived, I've seen no evidence that there are any
cases like it in the wild at all.  Even if there were some there aren't enough
of them to be a concern since no bugs have been filed.  If such examples come
to light I'll certainly do my best to deal with them.  But until then, I'd
prefer to focus on fixing real bugs that have been reported for existing code
to debating hypothetical problems.

[Bug lto/84105] [8 regression] Segmentation fault in pp_tree_identifier() during LTO

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-01-29
 CC||aldyh at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Aldy Hernandez  ---
Confirmed with last step of:

gcc -fdump-ipa-inline-details   -m32 -o sctp.ko lto-test.o -rdynamic

(-rdynamic instead of -r).

[Bug c++/83937] [7/8 Regression] C++17 binds braced init of a type T to default arg of a ctor instead of using T's own default ctor

[mpolacek at gcc dot gnu.org]

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

--- Comment #7 from Marek Polacek  ---
Actually this might be just a missing TARGET_EXPR_DIRECT_INIT_P check in
build_special_member_call:

--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -8824,7 +8824,8 @@ build_special_member_call (tree instance, tree name,
vec **args,
arg = perform_implicit_conversion_flags (class_type, arg,
 sub_complain,
 flags);
-  if ((TREE_CODE (arg) == TARGET_EXPR
+  if (((TREE_CODE (arg) == TARGET_EXPR
+   && TARGET_EXPR_DIRECT_INIT_P (arg))
   || TREE_CODE (arg) == CONSTRUCTOR)
  && (same_type_ignoring_top_level_qualifiers_p
  (class_type, TREE_TYPE (arg

[committed] Fix omp_init_nest_lock_with_hint prototype (PR libgomp/84096)

[Jakub Jelinek]

Hi!

I've committed following fix to the omp_init_nest_lock_with_hint
prototype.  I've found that I've actually forgot to add those
symbols to libgomp.so*, so that will need to be done next (at that
point I've been wondering whether we change omp_lock_t/omp_nest_lock_t
to something larger or what kind of hacks we use to actually
implement the hinting; perhaps for now we'll just ignore the hint).

2018-01-29  Christoph Spiel  
Jakub Jelinek  

PR libgomp/84096
* omp.h.in (omp_init_nest_lock_with_hint): Use omp_nest_lock_t
instead of omp_lock_t.

--- libgomp/omp.h.in.jj 2018-01-03 10:42:58.454763907 +0100
+++ libgomp/omp.h.in2018-01-29 21:14:18.611499982 +0100
@@ -101,7 +101,7 @@ extern void omp_unset_lock (omp_lock_t *
 extern int omp_test_lock (omp_lock_t *) __GOMP_NOTHROW;
 
 extern void omp_init_nest_lock (omp_nest_lock_t *) __GOMP_NOTHROW;
-extern void omp_init_nest_lock_with_hint (omp_lock_t *, omp_lock_hint_t)
+extern void omp_init_nest_lock_with_hint (omp_nest_lock_t *, omp_lock_hint_t)
   __GOMP_NOTHROW;
 extern void omp_destroy_nest_lock (omp_nest_lock_t *) __GOMP_NOTHROW;
 extern void omp_set_nest_lock (omp_nest_lock_t *) __GOMP_NOTHROW;

Jakub

[Bug tree-optimization/84111] [8 Regression] Compile time hog w/ -O2

[matz at gcc dot gnu.org]

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

--- Comment #7 from Michael Matz  ---
(In reply to Jakub Jelinek from comment #6)
> Sure, but some of the mentioned SSA_NAMEs are registered for update and SCEV
> code is called before that happens.

Yes, sure.  That still doesn't necessarily mean that they have to be generally
aware of this as long as the not-yet-updated SSA form is "reasonably"
reflecting
the original code.  An cycle in SSA name definition quite clearly is
not reasonable, so a better approach is to not generate that situation.

(It might of course be the case that we can't easily avoid creating that
situation, in that case we have to change follow_copies_to_constant()
or friends.  But I don't think we have established that yet).

[Bug libgomp/84096] Wrong prototype for omp_init_nest_lock_with_hint() in "omp.h.in"

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  ---
Author: jakub
Date: Mon Jan 29 23:38:01 2018
New Revision: 257167

URL: https://gcc.gnu.org/viewcvs?rev=257167=gcc=rev
Log:
PR libgomp/84096
* omp.h.in (omp_init_nest_lock_with_hint): Use omp_nest_lock_t
instead of omp_lock_t.

Modified:
trunk/libgomp/ChangeLog
trunk/libgomp/omp.h.in

[PATCH] Fix SCEV ICE during cunroll (PR tree-optimization/84111)

[Jakub Jelinek]

Hi!

As mentioned in the PR, cunroll sometimes registers some SSA_NAMEs for
renaming and then invokes some SCEV using functions before finally updating
the SSA form.  On the testcase we end up with 3 degenerate PHIs pointing at
each other, so follow_copies_to_constant loops forever.

The following patch has 2 different fixes for this, one is to avoid looking
at SSA_NAMEs registered for update (in theory all we care are the old ssa
names, but we don't have an API to query just those), the other is to put
some upper bound on how many times we follow SSA_NAMEs (either single defs
or degenerate phis).  Either of those changes is sufficient to fix this.

During x86_64-linux and i686-linux bootstraps/regtests follow_copies_to_constant
actually never returned anything useful, so the patch doesn't regress at
least on these targets anything, there are quite a few cases where SSA_NAME
is name_registered_for_update_p but the function would never return anything
but var in those cases.  And the highest depth ever seen was 3, except for
the newly added testcase if the && !name_registered_for_update_p (res) part
is commented out.

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

2018-01-29  Jakub Jelinek  

PR tree-optimization/84111
* tree-scalar-evolution.c: Include tree-into-ssa.h.
(follow_copies_to_constant): Stop on SSA_NAMEs registered for update,
loop at most 128 times.

* gcc.c-torture/compile/pr84111.c: New test.

--- gcc/tree-scalar-evolution.c.jj  2018-01-03 10:19:54.735533890 +0100
+++ gcc/tree-scalar-evolution.c 2018-01-29 20:36:34.648494334 +0100
@@ -280,6 +280,7 @@ along with GCC; see the file COPYING3.
 #include "params.h"
 #include "tree-ssa-propagate.h"
 #include "gimple-fold.h"
+#include "tree-into-ssa.h"
 
 static tree analyze_scalar_evolution_1 (struct loop *, tree);
 static tree analyze_scalar_evolution_for_address_of (struct loop *loop,
@@ -1540,7 +1541,10 @@ static tree
 follow_copies_to_constant (tree var)
 {
   tree res = var;
-  while (TREE_CODE (res) == SSA_NAME)
+  int depth = 0;
+  while (TREE_CODE (res) == SSA_NAME
+&& !name_registered_for_update_p (res)
+&& ++depth < 128)
 {
   gimple *def = SSA_NAME_DEF_STMT (res);
   if (gphi *phi = dyn_cast  (def))
--- gcc/testsuite/gcc.c-torture/compile/pr84111.c.jj2018-01-29 
20:38:10.236528914 +0100
+++ gcc/testsuite/gcc.c-torture/compile/pr84111.c   2018-01-29 
20:37:53.227522763 +0100
@@ -0,0 +1,31 @@
+/* PR tree-optimization/84111 */
+
+void
+foo (int x, int y, int z)
+{
+  int a = 0;
+  int *b = 
+
+  while (a < 1)
+{
+  int c = y;
+  *b = x;
+ lab:
+  for (a = 0; a < 36; ++a)
+{
+  *b = 0;
+  if (x != 0)
+y = 0;
+  while (c < 1)
+   ;
+}
+}
+  if (z < 33)
+{
+  b = (int *) 0;
+  ++y;
+  ++z;
+  if (x / *b != 0)
+goto lab;
+}
+}

Jakub

[C++ PATCH] Fix ICEs due to cp_parser_postfix_dot_deref_expression workaround (PR c++/84082)

[Jakub Jelinek]

Hi!

In r245223 cp_parser_postfix_dot_deref_expression has been changed to
workaround some buggy template code with a pedwarn instead of error,
in r245440 Marek tweaked that by adding the && EXPR_P (postfix_expression)
because we really don't want to clear TREE_TYPE on OVERLOADs or on DECLs
that have incomplete type.

There are some expression types where we don't want to clear TREE_TYPE
either, like *CAST_EXPR, or VIEW_CONVERT_EXPR, these in various spots
assume they have non-NULL TREE_TYPE.

So, the following patch extends it by looking at the various
postfix_expression kinds and deciding what to do by tweaking kind.
Changing kind from DK_PEDWARN where it pedwarns + clears TREE_TYPE and scope
to DK_ERROR will result in an error + what we used to do before r245223,
i.e. scope = error_mark_node and postfix_expression = error_mark_node too.
Changing kind to DK_IGNORED will do what Marek's patch did, not diagnose
anything at that point, let other code diagnose incomplete type later on
or diagnose some other error.  For OVERLOAD that seems like a better
choice, not really sure about other cases.  For now the patch uses DK_ERROR
and thus what we used to do before r245223 for non-OVERLOAD.  At least
when not processing_template_decl I'd say it is better to error right away.

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

Or should I change the switch body to do other kind = overrides?

2018-01-29  Jakub Jelinek  

PR c++/84082
* parser.c (cp_parser_postfix_dot_deref_expression): Don't clear
TREE_TYPE in templates on expressions that don't allow NULL TREE_TYPE,
use error instead of pedwarn in that case and set scope and
postfix_expression to error_mark_node.

* g++.dg/template/incomplete11.C: New test.
* g++.dg/parse/crash67.C: Expect an incomplete type diagnostics too.

--- gcc/cp/parser.c.jj  2018-01-18 00:42:02.287016215 +0100
+++ gcc/cp/parser.c 2018-01-29 16:07:06.381822967 +0100
@@ -7450,9 +7450,7 @@ cp_parser_postfix_dot_deref_expression (
   (scope, current_class_type
{
  scope = complete_type (scope);
- if (!COMPLETE_TYPE_P (scope)
- /* Avoid clobbering e.g. OVERLOADs or DECLs.  */
- && EXPR_P (postfix_expression))
+ if (!COMPLETE_TYPE_P (scope))
{
  /* In a template, be permissive by treating an object expression
 of incomplete type as dependent (after a pedwarn).  */
@@ -7460,15 +7458,45 @@ cp_parser_postfix_dot_deref_expression (
   && MAYBE_CLASS_TYPE_P (scope)
   ? DK_PEDWARN
   : DK_ERROR);
- cxx_incomplete_type_diagnostic
-   (location_of (postfix_expression),
-postfix_expression, scope, kind);
- if (!MAYBE_CLASS_TYPE_P (scope))
-   return error_mark_node;
- if (processing_template_decl)
+
+ switch (TREE_CODE (postfix_expression))
{
- dependent_p = true;
- scope = TREE_TYPE (postfix_expression) = NULL_TREE;
+   case CAST_EXPR:
+   case REINTERPRET_CAST_EXPR:
+   case CONST_CAST_EXPR:
+   case STATIC_CAST_EXPR:
+   case DYNAMIC_CAST_EXPR:
+   case IMPLICIT_CONV_EXPR:
+   case VIEW_CONVERT_EXPR:
+ kind = DK_ERROR;
+ break;
+   case OVERLOAD:
+ /* Don't emit any diagnostic for OVERLOADs.  */
+ kind = DK_IGNORED;
+ break;
+   default:
+ /* Avoid clobbering e.g. DECLs.  */
+ if (!EXPR_P (postfix_expression))
+   kind = DK_ERROR;
+ break;
+   }
+ if (kind != DK_IGNORED)
+   {
+ location_t exploc = location_of (postfix_expression);
+ cxx_incomplete_type_diagnostic (exploc, postfix_expression,
+ scope, kind);
+ if (!MAYBE_CLASS_TYPE_P (scope))
+   return error_mark_node;
+ if (kind == DK_ERROR)
+   {
+ scope = error_mark_node;
+ postfix_expression = error_mark_node;
+   }
+ else if (processing_template_decl)
+   {
+ dependent_p = true;
+ scope = TREE_TYPE (postfix_expression) = NULL_TREE;
+   }
}
}
}
--- gcc/testsuite/g++.dg/template/incomplete11.C.jj 2018-01-29 
16:01:32.762637830 +0100
+++ gcc/testsuite/g++.dg/template/incomplete11.C2018-01-29 
16:00:34.066605257 +0100
@@ -0,0 +1,10 @@
+// PR c++/84082
+// { dg-do compile }
+// { dg-options "" }
+

[Bug tree-optimization/84111] [8 Regression] Compile time hog w/ -O2

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Sure, but some of the mentioned SSA_NAMEs are registered for update and SCEV
code is called before that happens.

[Bug tree-optimization/84111] [8 Regression] Compile time hog w/ -O2

[matz at gcc dot gnu.org]

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

Michael Matz  changed:

   What|Removed |Added

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

--- Comment #5 from Michael Matz  ---
(In reply to Jakub Jelinek from comment #3)
> Seems during cunroll we end up with:
> y_8 = PHI 
> ...
> y_29 = PHI 
> ...
> y_37 = PHI 
> 
> where all 3 PHIs are degenerate and thus:

This is invalid SSA form.  PHI operand definitions must dominate their use, but
the above forms a cycle.  Probably a result of unroll-jam not carefully dealing
with unreachable code after the infinite loops; but we shouldn't generate such
code.  Adding hacks to follow_copies_to_constant doesn't seem a good idea;
that one is supposed to be able to rely on correct SSA form.

I'll take a look.

[Bug c++/84091] [8 Regression] ICE on valid C++ code: Segmentation fault

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

Re: [PATCH][PR debug/83758] look more carefully for internal_arg_pointer in vt_add_function_parameter()

[Segher Boessenkool]

On Mon, Jan 29, 2018 at 11:41:32PM +0100, Jakub Jelinek wrote:
> On Mon, Jan 29, 2018 at 04:26:50PM -0600, Segher Boessenkool wrote:
> > > The code actually meant pointer comparison, the question is what is
> > > different on powerpc* that you end up with a different REG.
> > > >From what I can see, function.c uses crtl->args.internal_arg_pointer
> > > directly rather than a REG with the same REGNO.
> > > Where does it become something different and why?
> > 
> > There is a lot of code that copies any RTX that isn't obviously unique.
> > Here we have a PLUS of some things, which always needs copying, can
> > never be shared.
> 
> Yes, PLUS needs to be unshared.
> So it ought to be handled by the PLUS handling code.
>   || (GET_CODE (XEXP (incoming, 0)) == PLUS
>   && XEXP (XEXP (incoming, 0), 0)
>  == crtl->args.internal_arg_pointer
>   && CONST_INT_P (XEXP (XEXP (incoming, 0), 1)
> Here we are talking about MEMs on the PARM_DECL DECL_RTLs, those are not
> instantiated as normal IL in the RTL stream is.

This is a PLUS of something with the internal_arg_pointer.  Our
internal_arg_pointer _itself_ is a PLUS, so it should be copy_rtx'd
everywhere it is used (or risk RTL sharing).

> I'm not saying the var-tracking.c change is wrong, but I'd like to see
> analysis on what is going on.

The rtx_equal_p is equal to the == for anything that uses just a single
register.  For us it makes the compiler bootstrap again (with Go enabled),
not unnice to have in stage4 ;-)

I agree the code does not seem to be set up for PLUS to work here.

> Is the patch for -fsplit-stack where rs6000_internal_arg_pointer
> returns a PLUS of some pseudo and some offset?

Yeah.

> In that case I wonder how does the patch with rtx_equal_p actually work,
> because function.c then uses plus_constant on this result, and if there are

Not everywhere, in places it does

  gen_rtx_PLUS (Pmode, stack_parm, offset_rtx);

(so we end up with non-canonical RTL).

> 2 non-zero offsets added, the result is a PLUS with a single offset based
> on that pseudo.  That would mean var-tracking.c would need special code to
> handle crtl->args.internal_arg_pointer that is a PLUS, and handle it
> differently from crtl->args.internal_arg_pointer that is a pseudo REG.

Yeah.  Not entirely pleasant.  Not super hard for just reg+off, but for
general expressions it isn't very funny.

If we want to force internal_arg_pointer to be just one reg the doc in
target.def should be updated:

/* ??? Documenting this hook requires a GFDL license grant.  */
DEFHOOK_UNDOC
(internal_arg_pointer,
"Return an rtx for the argument pointer incoming to the\
 current function.",
 rtx, (void),
 default_internal_arg_pointer)


Segher

[Bug target/65871] bzhi builtin/intrinsic wrongly assumes bzhi instruction doesn't set the ZF flag

[yann.collet.73 at gmail dot com]

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

Yann Collet  changed:

   What|Removed |Added

 CC||yann.collet.73 at gmail dot com

--- Comment #14 from Yann Collet  ---
Is gcc -mbmi2 currently able to generate automatically a bzhi instruction when
it detects a "X & ((1 << Y) - 1)" sequence, as suggested by James Almer ?
If yes, are there some available examples ?

[Bug libstdc++/84087] string::assign problem with two arguments

[bseifert at gmx dot at]

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

Berni  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #3 from Berni  ---

thank you. I confirm, the patch is working properly.

hope this will go into gcc 8.0 release!? the current snapshot (some days ago)
does not seem to be fixed yet.

Re: [PATCH][PR debug/83758] look more carefully for internal_arg_pointer in vt_add_function_parameter()

[Jakub Jelinek]

On Mon, Jan 29, 2018 at 04:26:50PM -0600, Segher Boessenkool wrote:
> > The code actually meant pointer comparison, the question is what is
> > different on powerpc* that you end up with a different REG.
> > >From what I can see, function.c uses crtl->args.internal_arg_pointer
> > directly rather than a REG with the same REGNO.
> > Where does it become something different and why?
> 
> There is a lot of code that copies any RTX that isn't obviously unique.
> Here we have a PLUS of some things, which always needs copying, can
> never be shared.

Yes, PLUS needs to be unshared.
So it ought to be handled by the PLUS handling code.
  || (GET_CODE (XEXP (incoming, 0)) == PLUS
  && XEXP (XEXP (incoming, 0), 0)
 == crtl->args.internal_arg_pointer
  && CONST_INT_P (XEXP (XEXP (incoming, 0), 1)
Here we are talking about MEMs on the PARM_DECL DECL_RTLs, those are not
instantiated as normal IL in the RTL stream is.

I'm not saying the var-tracking.c change is wrong, but I'd like to see
analysis on what is going on.

Is the patch for -fsplit-stack where rs6000_internal_arg_pointer
returns a PLUS of some pseudo and some offset?
In that case I wonder how does the patch with rtx_equal_p actually work,
because function.c then uses plus_constant on this result, and if there are
2 non-zero offsets added, the result is a PLUS with a single offset based
on that pseudo.  That would mean var-tracking.c would need special code to
handle crtl->args.internal_arg_pointer that is a PLUS, and handle it
differently from crtl->args.internal_arg_pointer that is a pseudo REG.

Jakub

[Bug tree-optimization/84042] IVOPTS doesn't optimize int indexes on some PowerPC code starting with svn id 250482

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-01-29
 Ever confirmed|0   |1

--- Comment #1 from Michael Meissner  ---
This shows up if we allow PRE_{INC,DEC,MODIFY} of DFmode and SFmode values if
those values can go in Altivec registers.

To reproduce this, compile the following code with either -O2 -mcpu=power6 or
-O2 -mcpu=power7 -mno-vsx:

void f(double *a, double *b, double *c, int n) {
  int i;
  for (i=0; i < n; i++)
a[i] = b[i] + c[i];
}

The code generated is:

f:
cmpwi 7,6,0
blelr 7
addi 6,6,-1
addi 9,4,-8
rldic 6,6,3,29
addi 5,5,-8
add 4,4,6
addi 3,3,-8
.p2align 4,,15
.L3:
lfdu 0,8(9)
lfdu 12,8(5)
cmpld 7,9,4
fadd 0,0,12
stfdu 0,8(3)
beqlr 7
lfdu 0,8(9)
lfdu 12,8(5)
cmpld 7,9,4
fadd 0,0,12
stfdu 0,8(3)
bne 7,.L3
blr

Subversion id 257166 disallowed PRE_{INC,DEC,MODIFY} for the floating point
scalars could go in Altivec registers and -O2 -mcpu=power7 generates:

f:
cmpwi 7,6,0
blelr 7
addi 6,6,-1
li 9,0
rldicl 6,6,0,32
addi 10,6,1
mtctr 10
.p2align 5,,31
.L3:
lfdx 0,4,9
lfdx 12,5,9
fadd 0,0,12
stfdx 0,3,9
addi 9,9,8
bdnz .L3
blr


Or alternatively compile the following code with -O2 -mcpu=power7:

void f(float *a, float *b, float *c, int n) {
  int i;
  for (i=0; i < n; i++)
a[i] = b[i] + c[i];
}

[PATCH] PR 80867: ICE during -O3 compile of libgnat

[Kelvin Nilsen]

It was determined that the reported ICE occurs because a NULL value is
passed from vectorizable_call () to

   targetm.vectorize.builtin_md_vectorized_function (
callee, vectype_out, vectype_in).

This patch avoids making this call if callee equals NULL.

After successful bootstrap and regression testing, with preapproval,
this patch has been committed to the trunk.

It it ok to backport to GCC 7 and GCC 6 (after testing on those
platforms)?

Thanks.


gcc/ChangeLog:

2018-01-29  Richard Biener 
Kelvin Nilsen  

PR bootstrap/80867
* tree-vect-stmts.c (vectorizable_call): Don't call
targetm.vectorize_builtin_md_vectorized_function if callee is
NULL.

Index: gcc/tree-vect-stmts.c
===
--- gcc/tree-vect-stmts.c   (revision 257105)
+++ gcc/tree-vect-stmts.c   (working copy)
@@ -3159,7 +3159,7 @@
   if (cfn != CFN_LAST)
fndecl = targetm.vectorize.builtin_vectorized_function
  (cfn, vectype_out, vectype_in);
-  else
+  else if (callee)
fndecl = targetm.vectorize.builtin_md_vectorized_function
  (callee, vectype_out, vectype_in);
 }

New Ukrainian PO file for 'gcc' (version 8.1-b20180128)

[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 Ukrainian team of translators.  The file is available at:

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

(This file, 'gcc-8.1-b20180128.uk.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.

[Bug target/81550] [8 regression] gcc.target/powerpc/loop_align.c fails starting with r250482

[meissner at gcc dot gnu.org]

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

--- Comment #11 from Michael Meissner  ---
Author: meissner
Date: Mon Jan 29 22:30:34 2018
New Revision: 257166

URL: https://gcc.gnu.org/viewcvs?rev=257166=gcc=rev
Log:
2018-01-29  Michael Meissner  

PR target/81550
* config/rs6000/rs6000.c (rs6000_setup_reg_addr_masks): If DFmode
and SFmode can go in Altivec registers (-mcpu=power7 for DFmode,
-mcpu=power8 for SFmode) don't set the PRE_INCDEC or PRE_MODIFY
flags.  This restores the settings used before the 2017-07-24.
Turning off pre increment/decrement/modify allows IVOPTS to
optimize DF/SF loops where the index is an int.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000.c

Re: [PATCH, rev2], PR target/81550, Disable PRE_{INC,DEC,MODIFY} for VSX floating point

[Michael Meissner]

On Mon, Jan 29, 2018 at 04:00:59PM -0600, Segher Boessenkool wrote:
> (Maybe add a comment?)
> 
> This is okay for trunk.  Thanks!

This is the patch I applied:

2018-01-29  Michael Meissner  

PR target/81550
* config/rs6000/rs6000.c (rs6000_setup_reg_addr_masks): If DFmode
and SFmode can go in Altivec registers (-mcpu=power7 for DFmode,
-mcpu=power8 for SFmode) don't set the PRE_INCDEC or PRE_MODIFY
flags.  This restores the settings used before the 2017-07-24.
Turning off pre increment/decrement/modify allows IVOPTS to
optimize DF/SF loops where the index is an int.

Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c  (revision 257165)
+++ gcc/config/rs6000/rs6000.c  (working copy)
@@ -2982,7 +2982,15 @@ rs6000_setup_reg_addr_masks (void)
 
  /* Figure out if we can do PRE_INC, PRE_DEC, or PRE_MODIFY
 addressing.  If we allow scalars into Altivec registers,
-don't allow PRE_INC, PRE_DEC, or PRE_MODIFY.  */
+don't allow PRE_INC, PRE_DEC, or PRE_MODIFY.
+
+For VSX systems, we don't allow update addressing for
+DFmode/SFmode if those registers can go in both the
+traditional floating point registers and Altivec registers.
+The load/store instructions for the Altivec registers do not
+have update forms.  If we allowed update addressing, it seems
+to break IV-OPT code using floating point if the index type is
+int instead of long (PR target/81550 and target/84042).  */
 
  if (TARGET_UPDATE
  && (rc == RELOAD_REG_GPR || rc == RELOAD_REG_FPR)
@@ -2990,6 +2998,8 @@ rs6000_setup_reg_addr_masks (void)
  && !VECTOR_MODE_P (m2)
  && !FLOAT128_VECTOR_P (m2)
  && !complex_p
+ && (m != E_DFmode || !TARGET_VSX)
+ && (m != E_SFmode || !TARGET_P8_VECTOR)
  && !small_int_vsx_p)
{
  addr_mask |= RELOAD_REG_PRE_INCDEC;

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

[Bug c++/83503] [8 Regression] bogus -Wattributes for const and pure on function template specialization

[jakub at gcc dot gnu.org]

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

--- Comment #13 from Jakub Jelinek  ---
(In reply to Martin Sebor from comment #12)
> AFAIK, specifying attribute const and pure on a function definition has no
> effect on the code emitted for the function itself or on its callers in
> other translation units, so what you describe doesn't sound meaningful.

The attribute on function definition affects all code in that TU.
Or, look at e.g. glibc external vs. internal headers, external headers are
something that is for users outside of glibc, internal headers include the
external ones and can tweak stuff for the internal users.  External header
could use pure attribute, internal could use const attribute (or just one
internal header for a particular sysdep etc.).  Many other projects use similar
header schemes.

[Bug rtl-optimization/83530] [8 Regression] ICE in reset_sched_cycles_in_current_ebb, at sel-sched.c:7150

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

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

--- Comment #3 from Aldy Hernandez  ---
I tried again with latest trunk but still can't reproduce.  I even tried on a
native PPC big endian box running in 32 bit mode (setarch).  Reporter also
filed PR84090, which also can't be reproduced by at least two people.

Re: [PATCH][PR debug/83758] look more carefully for internal_arg_pointer in vt_add_function_parameter()

[Segher Boessenkool]

On Mon, Jan 29, 2018 at 11:05:29PM +0100, Jakub Jelinek wrote:
> On Mon, Jan 29, 2018 at 03:01:10PM -0600, Aaron Sawdey wrote:
> >   /* If there is a DRAP register or a pseudo in internal_arg_pointer,
> >  rewrite the incoming location of parameters passed on the stack
> >  into MEMs based on the argument pointer, so that incoming doesn't
> >  depend on a pseudo.  */
> >   if (MEM_P (incoming)
> >   && (XEXP (incoming, 0) == crtl->args.internal_arg_pointer
> >   || (GET_CODE (XEXP (incoming, 0)) == PLUS
> >   && XEXP (XEXP (incoming, 0), 0)
> >  == crtl->args.internal_arg_pointer
> >   && CONST_INT_P (XEXP (XEXP (incoming, 0), 1)
> > {
> >   HOST_WIDE_INT off = -FIRST_PARM_OFFSET (current_function_decl);
> >   if (GET_CODE (XEXP (incoming, 0)) == PLUS)
> > off += INTVAL (XEXP (XEXP (incoming, 0), 1));
> >   incoming
> > = replace_equiv_address_nv (incoming,
> > plus_constant (Pmode,
> >arg_pointer_rtx, off));
> > }
> 
> The code actually meant pointer comparison, the question is what is
> different on powerpc* that you end up with a different REG.
> >From what I can see, function.c uses crtl->args.internal_arg_pointer
> directly rather than a REG with the same REGNO.
> Where does it become something different and why?

There is a lot of code that copies any RTX that isn't obviously unique.
Here we have a PLUS of some things, which always needs copying, can
never be shared.

I agree internal_arg_pointer should be a register: documentation says so.
(Well actually it doesn't, there is no documentation for it, but the
next best thing, the header file where it is declared, says so).

But rs6000's implementation worked for years, maybe we shouldn't break
it now?  Or maybe it is easy to fix.  Or, does that restriction ("has
to be a pseudo or hard reg") actually buy us anything?


Segher

[Bug c++/83503] [8 Regression] bogus -Wattributes for const and pure on function template specialization

[msebor at gcc dot gnu.org]

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

--- Comment #12 from Martin Sebor  ---
AFAIK, specifying attribute const and pure on a function definition has no
effect on the code emitted for the function itself or on its callers in other
translation units, so what you describe doesn't sound meaningful.

It's fine, though pointless, to declare a function pure and define it so that
it meets stricter requirements under some conditions, just as long as the
attributes don't clash.

[Bug fortran/84109] ICE in adjustl on allocatable array of strings

[anlauf at gmx dot de]

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

Harald Anlauf  changed:

   What|Removed |Added

 CC||anlauf at gmx dot de

--- Comment #2 from Harald Anlauf  ---
The ICE vanishes with -fno-realloc-lhs.

Re: [PATCH][PR debug/83758] look more carefully for internal_arg_pointer in vt_add_function_parameter()

[Jakub Jelinek]

On Mon, Jan 29, 2018 at 03:01:10PM -0600, Aaron Sawdey wrote:
>   /* If there is a DRAP register or a pseudo in internal_arg_pointer,
>  rewrite the incoming location of parameters passed on the stack
>  into MEMs based on the argument pointer, so that incoming doesn't
>  depend on a pseudo.  */
>   if (MEM_P (incoming)
>   && (XEXP (incoming, 0) == crtl->args.internal_arg_pointer
> || (GET_CODE (XEXP (incoming, 0)) == PLUS
> && XEXP (XEXP (incoming, 0), 0)
>== crtl->args.internal_arg_pointer
> && CONST_INT_P (XEXP (XEXP (incoming, 0), 1)
> {
>   HOST_WIDE_INT off = -FIRST_PARM_OFFSET (current_function_decl);
>   if (GET_CODE (XEXP (incoming, 0)) == PLUS)
>   off += INTVAL (XEXP (XEXP (incoming, 0), 1));
>   incoming
>   = replace_equiv_address_nv (incoming,
>   plus_constant (Pmode,
>  arg_pointer_rtx, off));
> }

The code actually meant pointer comparison, the question is what is
different on powerpc* that you end up with a different REG.
>From what I can see, function.c uses crtl->args.internal_arg_pointer
directly rather than a REG with the same REGNO.
Where does it become something different and why?

Jakub

Re: [C++ Patch] PR 84092 ("[8 Regression] ICE on C++14 code with variable template: in build_qualified_name, at cp/tree.c:2043")

[Paolo Carlini]

Hi,

On 29/01/2018 21:41, Jason Merrill wrote:

On Mon, Jan 29, 2018 at 10:45 AM, Paolo Carlini
 wrote:

the fix for c++/81236 removed some special code for dependent_p from
finish_id_expression, and now finish_qualified_id_expr is used for this
snippet too. Then special code at the beginning of the latter takes care of
calling build_qualified_name to create the relevant SCOPE_REF. Therefore it
seems to me that - unless we really want to return an OFFSET_REF - at that
point we are done, we don't want to get to the end of the following long
conditional and call again build_qualified_name on the SCOPE_REF and ICE. We
don't need convert_from_reference either because build_qualified_name is
passed a null type. Finishing testing (in the library) on x86_64-linux.

Hmm, it seems to me that the later code would handle this case fine
if, instead of calling build_qualified_name here, we do

qualifying_class = TYPE_CONTEXT (expr);
expr = TYPE_IDENTIFIER (expr);

Does that work?
Indeed it appears to work great and would make for a nice 
simplification, thanks! Testing the below is already past the C++ 
testsuite. Ok if it fully passes?


Thanks again,
Paolo.

//
Index: cp/semantics.c
===
--- cp/semantics.c  (revision 257159)
+++ cp/semantics.c  (working copy)
@@ -2001,12 +2001,12 @@ finish_qualified_id_expr (tree qualifying_class,
   if (template_p)
 {
   if (TREE_CODE (expr) == UNBOUND_CLASS_TEMPLATE)
-   /* cp_parser_lookup_name thought we were looking for a type,
-  but we're actually looking for a declaration.  */
-   expr = build_qualified_name (/*type*/NULL_TREE,
-TYPE_CONTEXT (expr),
-TYPE_IDENTIFIER (expr),
-/*template_p*/true);
+   {
+ /* cp_parser_lookup_name thought we were looking for a type,
+but we're actually looking for a declaration.  */
+ qualifying_class = TYPE_CONTEXT (expr);
+ expr = TYPE_IDENTIFIER (expr);
+   }
   else
check_template_keyword (expr);
 }
Index: testsuite/g++.dg/cpp1y/var-templ57.C
===
--- testsuite/g++.dg/cpp1y/var-templ57.C(nonexistent)
+++ testsuite/g++.dg/cpp1y/var-templ57.C(working copy)
@@ -0,0 +1,4 @@
+// PR c++/84092
+// { dg-do compile { target c++14 } }
+
+template < typename T > int a (T::template b);

Re: [PATCH, rev2], PR target/81550, Disable PRE_{INC,DEC,MODIFY} for VSX floating point

[Segher Boessenkool]

Hi!

On Sat, Jan 27, 2018 at 11:16:00AM -0500, Michael Meissner wrote:
> By allowing the ++/-- support for int indexes, it causes IV-OPTS to not
> properly optimize the loop.
> 
> This patch restores the 240841 behavior of not allowing ++/-- for scalar
> floating point types.  The loop looks like:
> 
> .L3:
> lfdx 0,4,9
> lfdx 12,5,9
> fadd 0,0,12
> stfdx 0,3,9
> addi 9,9,8
> bdnz .L3
> 
> Which is small enough to align the loop to 32 bytes.

More importantly ;-), this is better than doing three increments in the
loop (as the other case does).  Which then as a bonus makes an IV choice
that allows bdnz win.

> However, it does cause slight changes in running Spec 2006 on a little endian
> power8 system:
> 
>   471.omnetpp:1.3% faster
>   434.zeusmp: 1.9% slower
>   435.gromacs:2.0% faster
>   482.sphinx3:1.4% faster

That looks good.  Would be nice to figure out what causes the zeusmp
regression.

Also, with or without this patch, it seems we give pretty wrong costs
to ivopts.  We should investigate that, too (for GCC 9, unless there
is some obvious and simple thing we do wrong currently).

>   PR target/81550
>   * config/rs6000/rs6000.c (rs6000_setup_reg_addr_masks): If
>   floating point scalars are allowed in traditional Altivec
>   registers, don't allow PRE_{INC,DEC,MODIFY} on those floating
>   point types.

> Index: gcc/config/rs6000/rs6000.c
> ===
> --- gcc/config/rs6000/rs6000.c(revision 257024)
> +++ gcc/config/rs6000/rs6000.c(working copy)
> @@ -2990,6 +2990,8 @@ rs6000_setup_reg_addr_masks (void)
> && !VECTOR_MODE_P (m2)
> && !FLOAT128_VECTOR_P (m2)
> && !complex_p
> +   && (m != E_DFmode || !TARGET_VSX)
> +   && (m != E_SFmode || !TARGET_P8_VECTOR)
> && !small_int_vsx_p)
>   {
> addr_mask |= RELOAD_REG_PRE_INCDEC;

(Maybe add a comment?)

This is okay for trunk.  Thanks!


Segher

[Bug debug/83758] ICE building gccgo on powerpc64le --with-cpu=power8

[acsawdey at gcc dot gnu.org]

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

--- Comment #31 from acsawdey at gcc dot gnu.org ---
I'm not sure where the copy happens, I am just surmising that it must have been
added because the code clearly assumes it won't be copied.

Mac now fails to build because of libiconv

[Paul Koning]

It's been a few months since I tried to build GCC on my Mac, and in earlier 
tries it worked fine.  I have a log from 20-Sep-2017 that shows success.

But currently when I do the same configs as before, I get failures about _iconv 
being undefined.  This is in spite of the fact that I have libiconv installed, 
and just to be sure, told configure where to find it 
(--with-libiconv=/usr/local)

g++-g -O2 -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE  -fno-strict-aliasing 
-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing 
-Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual 
-pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings 
-fno-common  -DHAVE_CONFIG_H -Wl,-no_pie  -o cc1 c/c-lang.o 
c-family/stub-objc.o attribs.o c/c-errors.o c/c-decl.o c/c-typeck.o 
c/c-convert.o c/c-aux-info.o c/c-objc-common.o c/c-parser.o c/c-fold.o 
c/gimple-parser.o c-family/c-common.o c-family/c-cppbuiltin.o c-family/c-dump.o 
c-family/c-format.o c-family/c-gimplify.o c-family/c-indentation.o 
c-family/c-lex.o c-family/c-omp.o c-family/c-opts.o c-family/c-pch.o 
c-family/c-ppoutput.o c-family/c-pragma.o c-family/c-pretty-print.o 
c-family/c-semantics.o c-family/c-ada-spec.o c-family/c-ubsan.o 
c-family/known-headers.o c-family/c-attribs.o c-family/c-warn.o 
c-family/c-spellcheck.o default-c.o \
  cc1-checksum.o libbackend.a main.o libcommon-target.a libcommon.a 
../libcpp/libcpp.a ../libdecnumber/libdecnumber.a libcommon.a 
../libcpp/libcpp.a ./../intl/libintl.a -liconv  
../libbacktrace/.libs/libbacktrace.a ../libiberty/libiberty.a 
../libdecnumber/libdecnumber.a   -L/usr/local/lib -L/usr/local/lib 
-L/usr/local/lib -lmpc -lmpfr -lgmp   -L./../zlib -lz
Undefined symbols for architecture x86_64:
  "_iconv", referenced from:
  convert_using_iconv(void*, unsigned char const*, unsigned long, 
_cpp_strbuf*) in libcpp.a(charset.o)
  __nl_find_msg in libintl.a(dcigettext.o)
 (maybe you meant: __Z14cpp_init_iconvP10cpp_reader, __cpp_destroy_iconv )
  "_iconv_close", referenced from:
  __cpp_destroy_iconv in libcpp.a(charset.o)
  __cpp_convert_input in libcpp.a(charset.o)
  __nl_free_domain_conv in libintl.a(loadmsgcat.o)
  "_iconv_open", referenced from:
  init_iconv_desc(cpp_reader*, char const*, char const*) in 
libcpp.a(charset.o)
  __nl_init_domain_conv in libintl.a(loadmsgcat.o)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

Not only that, but if I configure --without-libiconv, I get the exact same 
error, i.e., that configure switch has no effect.

Any suggestions?

paul

[patch, libfortran] Adapt handling of derived types to new dtype

[Thomas Koenig]

Hello world,

this patch fixes the library issues left over from Paul's rank-15 patch
by removing the GFC_DTYPE_DERIVED_* macros and (mostly) handling these
cases separately.

The problem was with folding the type and size into a single word. For
all normal data types, this is perfectly fine, because the sizes are
known to fit. For derived types or characters, there could be a problem
if a user specified a very large size.

Regression-tested. OK for trunk?

Regards

Thomas

2018-01-29  Thomas Koenig  

PR fortran/37577
* libgfortran.h: Remove GFC_DTYPE_DERIVED_1, GFC_DTYPE_DERIVED_2,
GFC_DTYPE_DERIVED_4, GFC_DTYPE_DERIVED_8 and GFC_DTYPE_DERIVED_16.
* m4/cshift1.m4: Remove GFC_DTYPE_DERIVED_1.
* generated/cshift1_16.c: Regenerated.
* generated/cshift1_4.c: Regenerated.
* generated/cshift1_8.c: Regenerated.
* intrinsics/cshift0.c: Remove GFC_DTYPE_DERIVED_1.
* intrinsics/pack_generic.c (pack): Move handling of other types
into separate switch statement.
* intrinsics/spread_generic.c (spread): Likewise.
(spread_scalar): Likewise.
* intrinsics/unpack_generic.c (unpack1): Likewise.
(unpack0): Likewise.
* runtime/in_pack_generic.c (internal_pack): Likewise.
* runtime/in_unpack_generic.c (internal_unpack): Likewise.
Index: libgfortran.h
===
--- libgfortran.h	(Revision 257131)
+++ libgfortran.h	(Arbeitskopie)
@@ -490,19 +490,6 @@ typedef gfc_array_i4 gfc_array_s4;
| (sizeof(GFC_COMPLEX_16) << GFC_DTYPE_SIZE_SHIFT))
 #endif
 
-#define GFC_DTYPE_DERIVED_1 ((BT_DERIVED << GFC_DTYPE_TYPE_SHIFT) \
-   | (sizeof(GFC_INTEGER_1) << GFC_DTYPE_SIZE_SHIFT))
-#define GFC_DTYPE_DERIVED_2 ((BT_DERIVED << GFC_DTYPE_TYPE_SHIFT) \
-   | (sizeof(GFC_INTEGER_2) << GFC_DTYPE_SIZE_SHIFT))
-#define GFC_DTYPE_DERIVED_4 ((BT_DERIVED << GFC_DTYPE_TYPE_SHIFT) \
-   | (sizeof(GFC_INTEGER_4) << GFC_DTYPE_SIZE_SHIFT))
-#define GFC_DTYPE_DERIVED_8 ((BT_DERIVED << GFC_DTYPE_TYPE_SHIFT) \
-   | (sizeof(GFC_INTEGER_8) << GFC_DTYPE_SIZE_SHIFT))
-#ifdef HAVE_GFC_INTEGER_16
-#define GFC_DTYPE_DERIVED_16 ((BT_DERIVED << GFC_DTYPE_TYPE_SHIFT) \
-   | (sizeof(GFC_INTEGER_16) << GFC_DTYPE_SIZE_SHIFT))
-#endif
-
 /* Macros to determine the alignment of pointers.  */
 
 #define GFC_UNALIGNED_2(x) (((uintptr_t)(x)) & \
Index: m4/cshift1.m4
===
--- m4/cshift1.m4	(Revision 257131)
+++ m4/cshift1.m4	(Arbeitskopie)
@@ -121,7 +121,6 @@ cshift1 (gfc_array_char * const restrict ret,
   {
 case GFC_DTYPE_LOGICAL_1:
 case GFC_DTYPE_INTEGER_1:
-case GFC_DTYPE_DERIVED_1:
   cshift1_'atype_kind`_i1 ((gfc_array_i1 *)ret, (gfc_array_i1 *) array,
   			h, pwhich);
   return;
Index: generated/cshift1_16.c
===
--- generated/cshift1_16.c	(Revision 257131)
+++ generated/cshift1_16.c	(Arbeitskopie)
@@ -120,7 +120,6 @@ cshift1 (gfc_array_char * const restrict ret,
   {
 case GFC_DTYPE_LOGICAL_1:
 case GFC_DTYPE_INTEGER_1:
-case GFC_DTYPE_DERIVED_1:
   cshift1_16_i1 ((gfc_array_i1 *)ret, (gfc_array_i1 *) array,
   			h, pwhich);
   return;
Index: generated/cshift1_4.c
===
--- generated/cshift1_4.c	(Revision 257131)
+++ generated/cshift1_4.c	(Arbeitskopie)
@@ -120,7 +120,6 @@ cshift1 (gfc_array_char * const restrict ret,
   {
 case GFC_DTYPE_LOGICAL_1:
 case GFC_DTYPE_INTEGER_1:
-case GFC_DTYPE_DERIVED_1:
   cshift1_4_i1 ((gfc_array_i1 *)ret, (gfc_array_i1 *) array,
   			h, pwhich);
   return;
Index: generated/cshift1_8.c
===
--- generated/cshift1_8.c	(Revision 257131)
+++ generated/cshift1_8.c	(Arbeitskopie)
@@ -120,7 +120,6 @@ cshift1 (gfc_array_char * const restrict ret,
   {
 case GFC_DTYPE_LOGICAL_1:
 case GFC_DTYPE_INTEGER_1:
-case GFC_DTYPE_DERIVED_1:
   cshift1_8_i1 ((gfc_array_i1 *)ret, (gfc_array_i1 *) array,
   			h, pwhich);
   return;
Index: intrinsics/cshift0.c
===
--- intrinsics/cshift0.c	(Revision 257131)
+++ intrinsics/cshift0.c	(Arbeitskopie)
@@ -95,7 +95,6 @@ cshift0 (gfc_array_char * ret, const gfc_array_cha
 {
 case GFC_DTYPE_LOGICAL_1:
 case GFC_DTYPE_INTEGER_1:
-case GFC_DTYPE_DERIVED_1:
   cshift0_i1 ((gfc_array_i1 *)ret, (gfc_array_i1 *) array, shift, which);
   return;
 
Index: intrinsics/pack_generic.c
===
--- intrinsics/pack_generic.c	(Revision 257131)
+++ intrinsics/pack_generic.c	(Arbeitskopie)
@@ -255,7 +255,6 @@ pack (gfc_array_char *ret, const gfc_array_char *a
 {
 case GFC_DTYPE_LOGICAL_1:
 case 

[Bug c++/84098] [8 Regression] ICE when using a lambda in a in-class static member initialization

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug debug/83758] ICE building gccgo on powerpc64le --with-cpu=power8

[rsandifo at gcc dot gnu.org]

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

--- Comment #30 from rsandifo at gcc dot gnu.org  
---
(In reply to acsawdey from comment #29)
> The problematic expression was:
> 
> (mem/c:QI (plus:DI (plus:DI (reg/f:DI 187) (const_int 32 [0x20])) (const_int
> 72 [0x48]))
> 
> and internal_arg_pointer was (plus:DI (reg/f:DI 187) (const_int 32 [0x20]))
> ... just not the same rtx object in both places.

Where does it get copied?

> It seems like the +32 is FIRST_PARM_OFFSET for ppc64le. 187 is in fact just
> a copy of the stack pointer (r12).
> 
> It seems like there is something that decomposed the whole offset of 104,
> which is seen elsewhere after expand into 32+72.
> 
> If I understand correctly, you are saying that if the rtx with splitstack on
> was just reg+104, we would not recognize that because we are looking for
> this particular reg+32 pattern?

Yeah.  I'm not sure how we end up with the nested pluses
(which would normally be folded into one) but don't end up with
equal addresses for the inner plus.  It seems like a weird half
measure.

[Bug c++/83503] [8 Regression] bogus -Wattributes for const and pure on function template specialization

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek  ---
There is a valid use case, you have some public interface which you only want
to guarantee to be pure, the result depends on the arguments and e.g. on some
OSes or in some specific cases needs read-only access to global variables.
So you add __attribute__((pure)) to the public header for the function, that is
what you guarantee to outside users.
Then, for a specific configuration/OS/specific case you actually don't need the
access to global variables, so e.g. within the library or just with the TU with
the definition or something similar you make the guarantee stronger and use
__attribute__((const)).  Uses that see just the pure attribute optimize based
on that attribute, uses that see the const attribute or both optimize further.

[Bug fortran/82086] namelist read with repeat count fails when item is member of array of structures

[anlauf at gmx dot de]

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

--- Comment #8 from Harald Anlauf  ---
(In reply to jsberg from comment #7)
> As to why I think this is a bug (and why I think Intel's compiler is doing
> the right thing), referencing the 2008 standard (N1830):

In the F2018 DIS (N2146) the corresponding section is 13.11.  It appears
to have been heavily reorganized, but AFAICT from a first glance it is
quite similar.

E.g.

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

is now 13.11.3.2, paragraph 2.

> 10.11.3.3, paragraph 1:
> 
> ... The r*c form is equivalent to r successive appearances of the constant c

There's some change in wording here in 13.11.3.3, paragraph 1, explaining
the r* form for multiple null values.

New Ukrainian PO file for 'cpplib' (version 8.1-b20180128)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

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

http://translationproject.org/latest/cpplib/uk.po

(This file, 'cpplib-8.1-b20180128.uk.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/cpplib/

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

Contents of PO file 'cpplib-8.1-b20180128.uk.po'

[Translation Project Robot]

cpplib-8.1-b20180128.uk.po.gz
Description: Binary data
The Translation Project robot, in the
name of your translation coordinator.

Re: [PATCH] RL78 new "vector" function attribute

[DJ Delorie]

If the RX and RL78 now share interrupt/vector semantics, can we combine
the docs?  I.e. instead of a new section for RL78, can we change the RX
section to say something like "For RX and RL78..." ?

Re: [AARCH64]Bug in fix for branch offsets over 1 MiB?

[Richard Sandiford]

Sameera Deshpande  writes:
> Hi!
>
> I am seeing multiple assembler errors with error message "Error:
> conditional branch out of range" for customer code.
>
> The root cause of the bug is that conditional branches are generated
> whose branch target ends up being too far away to be encoded in the
> instruction.  It appears that there was an attempt to fix this issue
> in the below change:
>
> commit 050af05b9761f1979f11c151519e7244d5becd7c
> Author: thopre01 
> Date:   Thu Aug 27 10:08:54 2015 +
>
> 2015-08-27  Ramana Radhakrishnan
> <[ramana.radhakrish...@arm.com|mailto:ramana.radhakrish...@arm.com]>
> Andre Vieira
> <[andre.simoesdiasvie...@arm.com|mailto:andre.simoesdiasvie...@arm.com]>
>
> gcc/
> * config/aarch64/[aarch64.md|http://aarch64.md/] (*condjump):
> Handle functions > 1 MiB.
> (*cb1): Likewise.
> (*tb1): Likewise.
> (*cb1): Likewise.
> * config/aarch64/[iterators.md|http://iterators.md/] (inv_cb):
> New code attribute.
> (inv_tb): Likewise.
> * config/aarch64/aarch64.c (aarch64_gen_far_branch): New.
> * config/aarch64/aarch64-protos.h (aarch64_gen_far_branch): New.
>
> gcc/testsuite/
> * gcc.target/aarch64/long_branch_1.c: New test.
>
> However, as per GCC Internal documentation, only special attribute
> "length" should use PC and match_dup while defining an attribute. I
> verified by looking at code in final pass, and realised that
> get_attribute_length does not map directly to the functions generated
> from the definition of attribute length in RTL patterns, but computes
> the lengths in shorten_branches and uses insn_current_length as
> intermediate function.
>
> The far_branch attribute defined similar to attribute length expects
> same values to be returned by (minus (match_dup 2) (pc)) which is
> incorrect.
>
> I am looking at TARGET_MACHINE_DEPENDENT_REORG macro instead like few
> other architectures, to emit far branches.
>
> Is that approach acceptable?

I don't think we need to go that far.  The INSN_ADDRESSES should be
correct when outputting the instructions, so does it work if we use
those instead of get_attr_far_branch?

Thanks,
Richard

> PS: I am waiting for customer's approval for attaching the test case.

[Bug middle-end/84095] [8 Regression] false-positive -Wrestrict warnings for memcpy within array

[arnd at linaro dot org]

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

--- Comment #5 from Arnd Bergmann  ---
Here are some additional instances in the kernel. I'm currently trying to get a
reliable build first and haven't got a log of all the messages, but there are a
number of changes I did that are related, shutting up the -Wrestrict warning
(some may be -Warray-bounds).

Here are some false-positives:

--- a/arch/x86/oprofile/nmi_int.c
+++ b/arch/x86/oprofile/nmi_int.c
@@ -282,9 +282,7 @@ static void mux_clone(int cpu)
if (!has_mux())
return;

-   memcpy(per_cpu(cpu_msrs, cpu).multiplex,
-  per_cpu(cpu_msrs, 0).multiplex,
-  sizeof(struct op_msr) * model->num_virt_counters);
+   per_cpu(cpu_msrs, cpu).multiplex = per_cpu(cpu_msrs, 0).multiplex;
 }

 #else
@@ -463,6 +461,7 @@ static int nmi_setup(void)
if (!cpu)
continue;

+#ifdef CONFIG_SMP
memcpy(per_cpu(cpu_msrs, cpu).counters,
   per_cpu(cpu_msrs, 0).counters,
   sizeof(struct op_msr) * model->num_counters);
@@ -470,7 +469,7 @@ static int nmi_setup(void)
memcpy(per_cpu(cpu_msrs, cpu).controls,
   per_cpu(cpu_msrs, 0).controls,
   sizeof(struct op_msr) * model->num_controls);
-
+#endif
mux_clone(cpu);
}
--- a/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
+++ b/drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c
@@ -1643,7 +1643,7 @@ static int cfg80211_rtw_scan(struct wiphy *wiphy
spin_lock_bh(>lock);
if (request->n_channels == 1) {
for (i = 1;in_channels <= 4) {
for (j =request->n_channels-1;j>= 0;j--)


This one was weird, I suspect my change is incorrect:

diff --git a/drivers/fmc/fmc-fakedev.c b/drivers/fmc/fmc-fakedev.c
index 941d0930969a..0d322380d952 100644
--- a/drivers/fmc/fmc-fakedev.c
+++ b/drivers/fmc/fmc-fakedev.c
@@ -305,7 +305,7 @@ static int ff_init(void)

/* Replicate the default eeprom for the max number of mezzanines */
for (i = 1; i < FF_MAX_MEZZANINES; i++)
-   memcpy(ff_eeimg[i], ff_eeimg[0], sizeof(ff_eeimg[0]));
+   memcpy(_eeimg[i][0], _eeimg[0][0], sizeof(ff_eeimg[0]));

if (ff_nr_eeprom > ff_nr_dev)
ff_nr_dev = ff_nr_eeprom;

This one seems to be a kernel bug:

--- a/kernel/debug/kdb/kdb_support.c
+++ b/kernel/debug/kdb/kdb_support.c
@@ -129,13 +129,13 @@ int kdbnearsym(unsigned long addr, kdb_symtab_t *symtab)
}
if (i >= ARRAY_SIZE(kdb_name_table)) {
debug_kfree(kdb_name_table[0]);
-   memcpy(kdb_name_table, kdb_name_table+1,
+   memmove(kdb_name_table, kdb_name_table+1,
   sizeof(kdb_name_table[0]) *
   (ARRAY_SIZE(kdb_name_table)-1));
} else {
debug_kfree(knt1);
knt1 = kdb_name_table[i];
-   memcpy(kdb_name_table+i, kdb_name_table+i+1,
+   memmove(kdb_name_table+i, kdb_name_table+i+1,
   sizeof(kdb_name_table[0]) *
   (ARRAY_SIZE(kdb_name_table)-i-1));
}

[Bug c++/83835] [7/8 Regression] constexpr constructor rejected in c++17 mode (regression WRT c++14)

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
Perhaps we also want to set TARGET_EXPR_DIRECT_INIT_P here:

 6785 /* If this is a constructor or a function returning an aggr type,
 6786we need to build up a TARGET_EXPR.  */
 6787 if (DECL_CONSTRUCTOR_P (convfn))
 6788   {
 6789 expr = build_cplus_new (totype, expr, complain);
 6790 
 6791 /* Remember that this was list-initialization.  */
 6792 if (convs->check_narrowing && expr != error_mark_node)
 6793   TARGET_EXPR_LIST_INIT_P (expr) = true;
 6794   }

[Bug c++/82461] [7 Regression] Temporary required for brace-initializing (non-literal-type) member variable

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #8 from Jason Merrill  ---
Fixed for 7.4 as well.

[Bug target/68467] libgcc, compilation for target m68k-linux breaks in linux_atomic.c

[jsm28 at gcc dot gnu.org]

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

Joseph S. Myers  changed:

   What|Removed |Added

   Target Milestone|8.0 |7.4

--- Comment #25 from Joseph S. Myers  ---
Also now fixed for GCC 7.4.

[Bug target/68467] libgcc, compilation for target m68k-linux breaks in linux_atomic.c

[jsm28 at gcc dot gnu.org]

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

--- Comment #24 from Joseph S. Myers  ---
Author: jsm28
Date: Mon Jan 29 21:00:52 2018
New Revision: 257165

URL: https://gcc.gnu.org/viewcvs?rev=257165=gcc=rev
Log:
Fix m68k-linux-gnu libgcc build for ColdFire (PR target/68467).

PR target/68467 is libgcc failing to build for m68k-linux-gnu
configured for ColdFire.

Jeff has an analysis in the PR identifying the problem as resulting
from the callers of libcalls with 1-byte or 2-byte arguments wanting
to push just 1 or 2 bytes on the stack, while the libcall
implementations have the normal C ABI and expect 4-byte arguments.
For normal C functions, I believe the TARGET_PROMOTE_PROTOTYPES
definition would ensure such arguments get passed as 4-byte, but that
does not apply for libcalls.

This patch fixes the issue by defining TARGET_PROMOTE_FUNCTION_MODE
for m68k.  The definition is conservative, only applying promotions in
the case of arguments to libcalls; otherwise it returns the unpromoted
type, which I believe matches what the default implementation of the
hook would have done on m68k.

I have tested that this fixes the libgcc build for ColdFire, and, in
conjunction with one glibc patch, this enables glibc to build cleanly
for ColdFire and to pass the compilation parts of the glibc testsuite
except for one test unrelated to this patch (while glibc and the
compilation parts of the testsuite continue to build OK for
non-ColdFire m68k, as expected).  I have *not* run any GCC tests for
this patch, or any execution tests for m68k.

Backport from mainline
2018-01-24  Joseph Myers  

PR target/68467
* config/m68k/m68k.c (m68k_promote_function_mode): New function.
(TARGET_PROMOTE_FUNCTION_MODE): New macro.

Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/config/m68k/m68k.c

[PATCH][PR debug/83758] look more carefully for internal_arg_pointer in vt_add_function_parameter()

[Aaron Sawdey]

This bug appears to revolve around whether there is a canonical rtx for
internal_arg_pointer in var-tracking. In vt_add_function_parameter() we
 currently have:

static void
vt_add_function_parameter (tree parm)
{
  rtx decl_rtl = DECL_RTL_IF_SET (parm);
  rtx incoming = DECL_INCOMING_RTL (parm);
  tree decl;
  machine_mode mode;
  poly_int64 offset;
  dataflow_set *out;
  decl_or_value dv;

  if (TREE_CODE (parm) != PARM_DECL)
return;

  if (!decl_rtl || !incoming)
return;

  if (GET_MODE (decl_rtl) == BLKmode || GET_MODE (incoming) == BLKmode)
return;

  /* If there is a DRAP register or a pseudo in internal_arg_pointer,
 rewrite the incoming location of parameters passed on the stack
 into MEMs based on the argument pointer, so that incoming doesn't
 depend on a pseudo.  */
  if (MEM_P (incoming)
  && (XEXP (incoming, 0) == crtl->args.internal_arg_pointer
  || (GET_CODE (XEXP (incoming, 0)) == PLUS
  && XEXP (XEXP (incoming, 0), 0)
 == crtl->args.internal_arg_pointer
  && CONST_INT_P (XEXP (XEXP (incoming, 0), 1)
{
  HOST_WIDE_INT off = -FIRST_PARM_OFFSET (current_function_decl);
  if (GET_CODE (XEXP (incoming, 0)) == PLUS)
off += INTVAL (XEXP (XEXP (incoming, 0), 1));
  incoming
= replace_equiv_address_nv (incoming,
plus_constant (Pmode,
   arg_pointer_rtx, off));
}


This is looking for crtl->args.internal_arg_pointer within rtx
incoming. The problem I am seeing is that the same rtx is there, just
not as a pointer to the identical rtx objects, so is not found by the
== comparison in the current code. So hence my patch below to switch
from == to rtx_equal_p(). If the expression is not rewritten, then the
pseudo created for the stack pointer is not preserved and later we run
into the assert near the beginning of vt_expand_var_loc_chain().

Bootstrap now passes for languages=c,c++,go on ppc64le. If
bootstrap/regtest is ok on ppc64le and x86_64, ok for trunk?


2018-01-29  Aaron Sawdey  

* var-tracking.c (vt_add_function_parameter): Fix comparison of rtx.


Index: gcc/var-tracking.c
===
--- gcc/var-tracking.c  (revision 257159)
+++ gcc/var-tracking.c  (working copy)
@@ -9668,10 +9668,10 @@
  into MEMs based on the argument pointer, so that incoming doesn't
  depend on a pseudo.  */
   if (MEM_P (incoming)
-  && (XEXP (incoming, 0) == crtl->args.internal_arg_pointer
+  && (rtx_equal_p (XEXP (incoming, 0), crtl-
>args.internal_arg_pointer)
  || (GET_CODE (XEXP (incoming, 0)) == PLUS
- && XEXP (XEXP (incoming, 0), 0)
-== crtl->args.internal_arg_pointer
+ && rtx_equal_p (XEXP (XEXP (incoming, 0), 0),
+ crtl->args.internal_arg_pointer)
  && CONST_INT_P (XEXP (XEXP (incoming, 0), 1)
 {
   HOST_WIDE_INT off = -FIRST_PARM_OFFSET (current_function_decl);


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

Go patch committed: Don't run write barrier pass if there have been errors

[Ian Lance Taylor]

The write barrier pass depends on the escape analysis pass, and we
don't run the escape analysis pass if we've seen any errors.  Running
the write barrier pass without the escape analysis pass can produce
incorrect errors.  So skip it.  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 257126)
+++ gcc/go/gofrontend/MERGE (working copy)
@@ -1,4 +1,4 @@
-4164071703c531b5234b790b76df4931c37a8d9c
+6517e6731aeb4512d12c341c7111959a44547ba0
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
Index: gcc/go/gofrontend/wb.cc
===
--- gcc/go/gofrontend/wb.cc (revision 257113)
+++ gcc/go/gofrontend/wb.cc (working copy)
@@ -410,6 +410,9 @@ Write_barriers::statement(Block* block,
 void
 Gogo::add_write_barriers()
 {
+  if (saw_errors())
+return;
+
   Mark_address_taken mat(this);
   this->traverse();
 

[Bug c++/82461] [7 Regression] Temporary required for brace-initializing (non-literal-type) member variable

[jason at gcc dot gnu.org]

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

--- Comment #7 from Jason Merrill  ---
Author: jason
Date: Mon Jan 29 20:58:36 2018
New Revision: 257164

URL: https://gcc.gnu.org/viewcvs?rev=257164=gcc=rev
Log:
PR c++/82461 - constexpr list-initialized member

* constexpr.c (potential_constant_expression_1): Check
TARGET_EXPR_DIRECT_INIT_P.

Added:
branches/gcc-7-branch/gcc/testsuite/g++.dg/cpp0x/constexpr-list2.C
Modified:
branches/gcc-7-branch/gcc/cp/ChangeLog
branches/gcc-7-branch/gcc/cp/constexpr.c

[Bug c++/83996] [6/7] Regression] ICE with zero-sized array

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

Summary|[6/7/8] Regression] ICE |[6/7] Regression] ICE with
   |with zero-sized array   |zero-sized array

--- Comment #3 from Marek Polacek  ---
Fixed for 8 so far.

[Bug c++/68810] [8 regression] FAIL: g++.dg/cpp0x/constexpr-reinterpret1.C -- test for errors -- -m32

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #20 from Jason Merrill  ---
Fixed, though we're still folding too many things.

[Bug c++/68810] [8 regression] FAIL: g++.dg/cpp0x/constexpr-reinterpret1.C -- test for errors -- -m32

[jason at gcc dot gnu.org]

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

--- Comment #19 from Jason Merrill  ---
Author: jason
Date: Mon Jan 29 20:56:00 2018
New Revision: 257161

URL: https://gcc.gnu.org/viewcvs?rev=257161=gcc=rev
Log:
PR c++/68810 - wrong location for reinterpret_cast error.

* cvt.c (cp_convert_to_pointer): Always build a CONVERT_EXPR when
!dofold.

Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cvt.c
trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-reinterpret1.C

C++ PATCH for c++/68810, wrong diagnostic location with reinterpret_cast

[Jason Merrill]

Here, the problem was that convert_to_pointer_maybe_fold doesn't
entirely respect the dofold argument, and folds anyway if the argument
is constant.  In this case we really don't want folding.

Tested x86_64-pc-linux-gnu, applying to trunk.
commit ea38396630703879e5416265cd66db87845f3684
Author: Jason Merrill 
Date:   Mon Jan 29 15:52:09 2018 -0500

PR c++/68810 - wrong location for reinterpret_cast error.

* cvt.c (cp_convert_to_pointer): Always build a CONVERT_EXPR when
!dofold.

diff --git a/gcc/cp/cvt.c b/gcc/cp/cvt.c
index 3ab3e2e2b40..f5da08bbee2 100644
--- a/gcc/cp/cvt.c
+++ b/gcc/cp/cvt.c
@@ -239,6 +239,11 @@ cp_convert_to_pointer (tree type, tree expr, bool dofold,
   gcc_assert (GET_MODE_SIZE (SCALAR_INT_TYPE_MODE (TREE_TYPE (expr)))
  == GET_MODE_SIZE (SCALAR_INT_TYPE_MODE (type)));
 
+  /* FIXME needed because convert_to_pointer_maybe_fold still folds
+conversion of constants.  */
+  if (!dofold)
+   return build1 (CONVERT_EXPR, type, expr);
+
   return convert_to_pointer_maybe_fold (type, expr, dofold);
 }
 
diff --git a/gcc/testsuite/g++.dg/cpp0x/constexpr-reinterpret1.C 
b/gcc/testsuite/g++.dg/cpp0x/constexpr-reinterpret1.C
index d2ee2bac223..d7d244f752d 100644
--- a/gcc/testsuite/g++.dg/cpp0x/constexpr-reinterpret1.C
+++ b/gcc/testsuite/g++.dg/cpp0x/constexpr-reinterpret1.C
@@ -16,7 +16,9 @@ public:
 
   constexpr static Inner & getInner()
   /* I am surprised this is considered a constexpr */
-  { return *((Inner *)4); } // { dg-error "reinterpret_cast" }
+  {
+return *((Inner *)4); // { dg-error "reinterpret_cast" }
+  }
 };
 
 B B::instance;

[Bug c++/83996] [6/7/8] Regression] ICE with zero-sized array

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
Author: mpolacek
Date: Mon Jan 29 20:54:12 2018
New Revision: 257160

URL: https://gcc.gnu.org/viewcvs?rev=257160=gcc=rev
Log:
PR c++/83996
* constexpr.c (cxx_fold_indirect_ref): Compute ((foo *))[1]
=> fooarray[1] in offset_int.

* g++.dg/ext/pr83996.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/ext/pr83996.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/constexpr.c
trunk/gcc/testsuite/ChangeLog

Re: [PATCH, rs6000] Fix PR56010 and PR83743, -mcpu=native use wrong names

[Peter Bergner]

On 1/29/18 2:33 PM, Peter Bergner wrote:
> The current version of that code looks like the following, which I should
> copy instead.  Unless you have a different suggestion?
> 
>   char *s;
> 
>   if (e->unknown_error)
> error_at (loc, e->unknown_error, arg);
>   else
> error_at (loc, "unrecognized argument in option %qs", opt);
> 
>   auto_vec  candidates;
>   for (i = 0; e->values[i].arg != NULL; i++)
> {
>   if (!enum_arg_ok_for_language (>values[i], lang_mask))
> continue;
>   candidates.safe_push (e->values[i].arg);
> }
>   const char *hint = candidates_list_and_hint (arg, s, candidates);
>   if (hint)
> inform (loc, "valid arguments to %qs are: %s; did you mean %qs?",
> option->opt_text, s, hint);
>   else
> inform (loc, "valid arguments to %qs are: %s", option->opt_text, s);
>   XDELETEVEC (s);

Actually, all the "macic" of this code happens in candidates_list_and_hint()
and that looks much like the GCC 5 code I showed, plus a call to
find_closest_string() which we don't want, so I think just sticking with
the original code in the last patch is probably best.

Peter

[Bug lto/84105] [8 regression] Segmentation fault in pp_tree_identifier() during LTO

[arnd at linaro dot org]

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

--- Comment #2 from Arnd Bergmann  ---
Created attachment 43281
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43281=edit
preprocessed simplified sm_sideeffect.c, compressed

I managed to get a standalone testcase now, manually reduced the original
source and then preprocessed. Further automated reduction should be easy now if
necessary.

x86_64-linux-gcc-8.0.1 -c -m32 -o lto-test.o lto-test.i -O2 -flto
-Wno-pointer-sign -fno-strict-aliasing
x86_64-linux-gcc-8.0.1  -fdump-ipa-inline-details   -m32 -r-o sctp.ko
lto-test.o

The part that goes wrong is apparently the '-fdump-ipa-inline-details'.

/git/arm-soc/net/sctp/lto-test.c: In function 'sctp_do_sm':
/git/arm-soc/net/sctp/lto-test.c:120:5: internal compiler error: Segmentation
fault
 int sctp_do_sm(struct net *net, enum sctp_event event_type,
 ^
0xa42b7f crash_signal
/home/arnd/git/gcc/gcc/toplev.c:325
0xaf0659 pp_tree_identifier(pretty_printer*, tree_node*)
/home/arnd/git/gcc/gcc/tree-pretty-print.c:4006
0xaf0966 dump_decl_name
/home/arnd/git/gcc/gcc/tree-pretty-print.c:261
0xaf42ea dump_generic_node(pretty_printer*, tree_node*, int, unsigned long,
bool)
/home/arnd/git/gcc/gcc/tree-pretty-print.c:1826
0xaf769a print_declaration(pretty_printer*, tree_node*, int, unsigned long)
/home/arnd/git/gcc/gcc/tree-pretty-print.c:
0xaf7997 print_generic_decl(_IO_FILE*, tree_node*, unsigned long)
/home/arnd/git/gcc/gcc/tree-pretty-print.c:122
0xb4603a dump_scope_block
/home/arnd/git/gcc/gcc/tree-ssa-live.c:647
0xb471b9 dump_scope_blocks(_IO_FILE*, unsigned long)
/home/arnd/git/gcc/gcc/tree-ssa-live.c:678
0xb471b9 remove_unused_locals()
/home/arnd/git/gcc/gcc/tree-ssa-live.c:870
0x97af44 execute_function_todo
/home/arnd/git/gcc/gcc/passes.c:1972
0x97b8b9 execute_todo
/home/arnd/git/gcc/gcc/passes.c:2048
0x97dac5 execute_one_ipa_transform_pass
/home/arnd/git/gcc/gcc/passes.c:2245
0x97dac5 execute_all_ipa_transforms()
/home/arnd/git/gcc/gcc/passes.c:2281
0x6d681c cgraph_node::expand()
/home/arnd/git/gcc/gcc/cgraphunit.c:2132
0x6d7b38 expand_all_functions
/home/arnd/git/gcc/gcc/cgraphunit.c:2275
0x6d7b38 symbol_table::compile()
/home/arnd/git/gcc/gcc/cgraphunit.c:2624
0x656c51 lto_main()
/home/arnd/git/gcc/gcc/lto/lto.c:3349
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
lto-wrapper: fatal error: /home/arnd/cross-gcc/bin/x86_64-linux-gcc-8.0.1
returned 1 exit status
compilation terminated.
/home/arnd/cross-gcc/lib/gcc/x86_64-linux/8.0.1/../../../../x86_64-linux/bin/ld:
error: lto-wrapper failed

Re: [PATCH] PR libgcc/59714 complex division is surprising on aarch64

[Joseph Myers]

On Mon, 29 Jan 2018, vladimir.mezent...@oracle.com wrote:

> > What about powerpc __divkc3?
> >
> > What was the rationale for using soft-fp rather than adding appropriate 
> > built-in functions as suggested in a comment?
> 
> I had a version with built-in functions and I can restore it.
> 
> Let's design what we want to use soft-fp or built-in function.
> I'd prefer to use built-in functions but performance is in two times worse.
> 
> The test below demonstrates performance degradation:

So, this is comparing __builtin_frexp (extracting both exponent and 
mantissa, including appropriate handling of exponents of subnormal values) 
with just extracting the exponent and with no special handling of zero / 
infinity / NaN / subnormal values.

We need to consider what functionality is actually needed for this 
scaling, if we do wish to use such scaling based on integer exponents.  If 
what's needed corresponds exactly to some standard functions such as ilogb 
and scalbn with all their special cases, then built-in versions of those 
standard functions may make sense.  If what's needed does not correspond 
to standard functions and does not need to handle such special cases, 
that's more of an indication for examining the representation in libgcc - 
but it's still necessary to handle the many different variant 
floating-point formats supported, or to safely avoid using the new code 
for formats it can't handle.

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

[Bug c++/83503] [8 Regression] bogus -Wattributes for const and pure on function template specialization

[msebor at gcc dot gnu.org]

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

--- Comment #10 from Martin Sebor  ---
(In reply to Jakub Jelinek from comment #9)

This is not a style warning.  Because there is no valid use case for having
both attribute const and pure on two declarations of the same function, in the
absence of access to its definition there also is no one correct choice to make
as to which one to honor and which one to ignore.  Honoring const when the
definition is, in fact, pure, is a bug.  Honoring pure when the definition is
const results in less than optimal code.

In cases where there is no one correct/safe/optimal choice the best response is
to point out the conflict/ambiguity and let the user resolve it based on the
definition of the function.

The difference the patch introduces is that rather than always honoring const
as before, GCC 8 honors the attribute on the first declaration.  (My preference
would have been to honor pure to be on the safe side but I didn't think there
would have been sufficient support for the change and, with a warning, it also
didn't seem like as big a risk anymore, while a consistent treatment of all
conflicts seems like a more important goal).

But this bug is not the right place to discuss the merits of the warning itself
or the handling of conflicts.