MAINTAINERS: add myself

[Jiufu Guo]

2019-01-21  Jiufu Guo  

* MAINTAINERS (Write After Approval): Add myself.

Index: MAINTAINERS
===
--- MAINTAINERS (revision 268134)
+++ MAINTAINERS (working copy)
@@ -400,6 +400,7 @@ Matthew Gretton-Dann

 Jon Grimm  
 Laurent Guerby 
+Jiufu Guo  
 Xuepeng Guo
 Wei Guozhi 
 Mostafa Hagog  

Re: [PATCH] x86-64: Use TI->SF and TI->DF conversions in soft-fp

[Joseph Myers]

On Mon, 21 Jan 2019, H.J. Lu wrote:

> The testcase at
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88931
> 
> with -frounding-math.  __floattisf and __floattidf from libgcc2.c give
> the wrong results for FE_UPWARD and FE_TOWARDZERO.

I suggest writing a test that looks something like 
gcc.dg/torture/fp-int-convert-float128-timode-3.c - one that verifies the 
conversion of a single value, in a single rounding mode (four such tests 
if you want to verify conversions for each of SFmode and DFmode, in each 
of two rounding modes).  Of course that test wouldn't have any of the dg-* 
related to __float128, because this isn't a float128 issue.  Given such a 
test that uses volatile as appropriate and just does and checks one 
conversion, we can be confident we have a real issue (not something about 
code movement).

If such a test shows a bug, it will be somewhere in the libgcc2.c code, 
with the appropriate fix being in that code.  Since that code has lots of 
conditionals in it, it would help to identify exactly which cases in that 
code are used; that is, which of the

#if FSSIZE >= W_TYPE_SIZE

#elif (LIBGCC2_HAS_DF_MODE && F_MODE_OK (__LIBGCC_DF_MANT_DIG__))   \
 || (LIBGCC2_HAS_XF_MODE && F_MODE_OK (__LIBGCC_XF_MANT_DIG__)) \
 || (LIBGCC2_HAS_TF_MODE && F_MODE_OK (__LIBGCC_TF_MANT_DIG__))

or

#else

cases is being used (and, in the second case, what FSIZE and FTYPE are).  
The bug could either be in the code in the selected case, or in the logic 
that selects which case to use.

Based on code inspection, it's possible the issue is with

  /* No leading bits means u == minimum.  */
  if (count == 0)
return -(Wtype_MAXp1_F * (Wtype_MAXp1_F / 2));

in the third case (where actually count == 0 only means the high part is 
minimum).  In which case something like

return Wtype_MAXp1_F * (FSTYPE) (hi | ((UWtype) u != 0));

for the (count == 0) case would address the problem.

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

Re: [PATCH] x86-64: Use TI->SF and TI->DF conversions in soft-fp

[H.J. Lu]

On Mon, Jan 21, 2019 at 4:58 PM Joseph Myers  wrote:
>
> On Tue, 22 Jan 2019, Terry Guo wrote:
>
> > Hi Joseph,
> >
> > I believe HJ is proposing patch to fix bug
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88931. In the test case
> > of the bug, the "#pragma STDC FENV_ACCESS ON" is used and there are
>
> Which isn't supported by GCC.  Any test involving rounding modes should
> ensure inputs and results are volatile (or use asm, etc., but volatile is
> simpler for tests) to make sure that computations aren't moved across
> rounding mode changes (which can happen even with -frounding-math,
> -frounding-math only affects a few things like constant folding, without
> preventing such code movement).
>
> > The current _floattisf from libgcc2 doesn't support those four rounding 
> > modes.
>
> It doesn't need to mention rounding modes anywhere.  The basic design of
> all those conversion functions is that, given the input, they determine
> other inputs to other conversions with the property that only a single
> floating-point rounding occurs in the sequence of operations and that the
> input to that rounding is similar enough to the input to the original
> operation (through careful use of sticky bits etc.) that the result of
> that rounding will always be the correct result of the original operation,
> independent of the rounding mode.
>
> For example, it's always valid, in any rounding mode, to convert TImode to
> SFmode by changing the TImode input to a nicer one (at most top 64 bits
> nonzero, say, so that conversions from DImode can be used as an
> intermediate step) such that the top 25 bits (starting with the first
> nonzero bit, for positive or unsigned arguments) of the two values agree,
> and the two values also agree in whether any lower-order bits are nonzero.
> That sort of thing is what the code in libgcc2.c is trying to do.
>
> Some of that logic is complex, and it's entirely possible it has bugs.
> But the correct fix must be an architecture-independent one in libgcc2.c;
> any architecture-specific version is just a subsequent optimization on top
> of that.  In general, for any bug, you need to work out where the buggy
> code is (meaning understanding the intended interfaces between bits of the
> compiler that are involved in this question), and fix it there rather than
> doing a target-specific workaround.  If you want to do a target-specific
> workaround (like this patch is), you need to call out up front that your
> patch is just a workaround and give strong justification for that approach
> (e.g. some way in which the proper general fix would be destabilizing at
> the current development stage).
>
> The current description of the bug "Wrong __floattisf and __floattidf are
> selected in libgcc" is completely inappropriate unless the assertion is
> that one of the #if conditionals in libgcc2.c is wrong (in which case that
> #if conditional, or the code it guards, should be corrected).

The testcase at

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

with -frounding-math.  __floattisf and __floattidf from libgcc2.c give
the wrong results for FE_UPWARD and FE_TOWARDZERO.

-- 
H.J.

Re: [PATCH] x86-64: Use TI->SF and TI->DF conversions in soft-fp

[Joseph Myers]

On Tue, 22 Jan 2019, Terry Guo wrote:

> Hi Joseph,
> 
> I believe HJ is proposing patch to fix bug
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88931. In the test case
> of the bug, the "#pragma STDC FENV_ACCESS ON" is used and there are

Which isn't supported by GCC.  Any test involving rounding modes should 
ensure inputs and results are volatile (or use asm, etc., but volatile is 
simpler for tests) to make sure that computations aren't moved across 
rounding mode changes (which can happen even with -frounding-math, 
-frounding-math only affects a few things like constant folding, without 
preventing such code movement).

> The current _floattisf from libgcc2 doesn't support those four rounding modes.

It doesn't need to mention rounding modes anywhere.  The basic design of 
all those conversion functions is that, given the input, they determine 
other inputs to other conversions with the property that only a single 
floating-point rounding occurs in the sequence of operations and that the 
input to that rounding is similar enough to the input to the original 
operation (through careful use of sticky bits etc.) that the result of 
that rounding will always be the correct result of the original operation, 
independent of the rounding mode.

For example, it's always valid, in any rounding mode, to convert TImode to 
SFmode by changing the TImode input to a nicer one (at most top 64 bits 
nonzero, say, so that conversions from DImode can be used as an 
intermediate step) such that the top 25 bits (starting with the first 
nonzero bit, for positive or unsigned arguments) of the two values agree, 
and the two values also agree in whether any lower-order bits are nonzero.  
That sort of thing is what the code in libgcc2.c is trying to do.

Some of that logic is complex, and it's entirely possible it has bugs.  
But the correct fix must be an architecture-independent one in libgcc2.c; 
any architecture-specific version is just a subsequent optimization on top 
of that.  In general, for any bug, you need to work out where the buggy 
code is (meaning understanding the intended interfaces between bits of the 
compiler that are involved in this question), and fix it there rather than 
doing a target-specific workaround.  If you want to do a target-specific 
workaround (like this patch is), you need to call out up front that your 
patch is just a workaround and give strong justification for that approach 
(e.g. some way in which the proper general fix would be destabilizing at 
the current development stage).

The current description of the bug "Wrong __floattisf and __floattidf are 
selected in libgcc" is completely inappropriate unless the assertion is 
that one of the #if conditionals in libgcc2.c is wrong (in which case that 
#if conditional, or the code it guards, should be corrected).

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

Re: [PATCH] x86-64: Use TI->SF and TI->DF conversions in soft-fp

[Terry Guo]

On Tue, Jan 22, 2019 at 7:48 AM Joseph Myers  wrote:
>
> On Mon, 21 Jan 2019, H.J. Lu wrote:
>
> > TI->SF and TI->DF conversions in libgcc2.c:
> >
> > FSTYPE
> > FUNC (DWtype u)
> > {
> >   ...
> > }
> >
> > have no rounding mode support.  We should replace __floattisf, __floattidf,
> > __floatuntisf and __floatuntidf in libgcc2.c with these from soft-fp.
>
> Please explain what you mean by "have no rounding mode support" (i.e., the
> exact flow through a function that is incorrect in a non-default rounding
> mode).  This patch is missing testcases - which of course should be
> architecture-independent.  (Any bug in libgcc2.c should first have an
> architecture-independent fix - it can't be considered fixed based on a fix
> for one architecture.  Then, if some other approach is optimal on
> particular architectures, they can get optimized variants.)
>
> I believe all those function implementations are designed so that only a
> single rounding occurs, which is for the final result, so no explicit
> handling of rounding modes is ever needed (the integer code before then
> may set up sticky bits appropriately to ensure the floating-point parts of
> the code only need a single rounding, which works in all modes), but maybe
> there are bugs in certain cases.  To identify the correct fix, we need
> details of the exact code path being used (the exact values of the various
> macros, choices for the various conditional parts of the function, values
> each variable has at each point) and where the existing,
> rounding-mode-independent logic goes wrong.
>
> --
> Joseph S. Myers
> jos...@codesourcery.com

Hi Joseph,

I believe HJ is proposing patch to fix bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88931. In the test case
of the bug, the "#pragma STDC FENV_ACCESS ON" is used and there are
four rounding modes:

  {
ROUNDING (FE_DOWNWARD),
ROUNDING (FE_UPWARD),
ROUNDING (FE_TOWARDZERO),
ROUNDING (FE_TONEAREST)
  }

The current _floattisf from libgcc2 doesn't support those four rounding modes.

BR,
Terry

Re: [RS6000] PR88614, output_operand: invalid %z value

[Segher Boessenkool]

On Tue, Jan 22, 2019 at 10:59:57AM +1030, Alan Modra wrote:
> > I think this would be nicer if you still used insn alternatives here.
> > What is needed for that?
> 
> A new symbol constraint especially for __tls_get_addr?  Actually two
> new constraints for ppc64, one for small model, the other for
> medium/large!  No way.

You don't need new constraints I think; you can use the "enabled" attribute
for it.  Not a stage4 thing I guess.

> > The patch is okay for trunk (if it survives on at least all three linux
> > targets).  Thanks!
> 
> Happily it did, even with -mno-tls-markers.

:-)


Segher

Re: [RS6000] PR88614, output_operand: invalid %z value

[Alan Modra]

On Mon, Jan 21, 2019 at 08:22:58AM -0600, Segher Boessenkool wrote:
> On Mon, Jan 21, 2019 at 10:48:57PM +1030, Alan Modra wrote:
> > Here's what the revised approach looks like, but without using new
> > unspecs.  Bootstrap and regression test on powerpc64le-linux and
> > powerpc64-linux biarch completed, and testing on powerpc64le-linux
> > with -mno-tls-markers.  powerpc64-linux -mno-tls-markers testing still
> > in progress.  OK?
> 
> This is easier to grok, thanks.

Yes, and not having to edit __tls_get_addr call patterns is good too.

> I think this would be nicer if you still used insn alternatives here.
> What is needed for that?

A new symbol constraint especially for __tls_get_addr?  Actually two
new constraints for ppc64, one for small model, the other for
medium/large!  No way.

> The patch is okay for trunk (if it survives on at least all three linux
> targets).  Thanks!

Happily it did, even with -mno-tls-markers.

-- 
Alan Modra
Australia Development Lab, IBM

libgo patch committed: Fix build for ARM GNU/Linux

[Ian Lance Taylor]

This patch to libgo fixes the build for ARM GNU/Linux.

It was failing with

../../../libgo/go/internal/cpu/cpu.go:138:2: error: reference to
undefined name 'doinit'
  138 |  doinit()
  |  ^

This patch fixes it by adding in Go 1.12 internal/cpu/cpu_arm.go, and
the code in runtime that initializes the values.

This fixes GCC PR 88927.

Ian
Index: gcc/go/gofrontend/MERGE
===
--- gcc/go/gofrontend/MERGE (revision 268130)
+++ gcc/go/gofrontend/MERGE (working copy)
@@ -1,4 +1,4 @@
-0c870ba6b3b43e0e56231f40c56b58dad0e36d9e
+fb44f62e7c01ebc987dad78875f593da1817
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
Index: libgo/go/internal/cpu/cpu_arm.go
===
--- libgo/go/internal/cpu/cpu_arm.go(nonexistent)
+++ libgo/go/internal/cpu/cpu_arm.go(working copy)
@@ -0,0 +1,33 @@
+// Copyright 2017 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.
+
+package cpu
+
+// arm doesn't have a 'cpuid' equivalent, so we rely on HWCAP/HWCAP2.
+// These are linknamed in runtime/os_(linux|freebsd)_arm.go and are
+// initialized by archauxv().
+// These should not be changed after they are initialized.
+var HWCap uint
+var HWCap2 uint
+
+// HWCAP/HWCAP2 bits. These are exposed by Linux and FreeBSD.
+const (
+   hwcap_VFPv4 = 1 << 16
+   hwcap_IDIVA = 1 << 17
+)
+
+func doinit() {
+   options = []option{
+   {Name: "vfpv4", Feature: },
+   {Name: "idiva", Feature: },
+   }
+
+   // HWCAP feature bits
+   ARM.HasVFPv4 = isSet(HWCap, hwcap_VFPv4)
+   ARM.HasIDIVA = isSet(HWCap, hwcap_IDIVA)
+}
+
+func isSet(hwc uint, value uint) bool {
+   return hwc != 0
+}
Index: libgo/go/runtime/os_linux_arm.go
===
--- libgo/go/runtime/os_linux_arm.go(revision 268078)
+++ libgo/go/runtime/os_linux_arm.go(working copy)
@@ -4,6 +4,8 @@
 
 package runtime
 
+import "internal/cpu"
+
 var randomNumber uint32
 
 func archauxv(tag, val uintptr) {
@@ -14,5 +16,9 @@ func archauxv(tag, val uintptr) {
// it as a byte array.
randomNumber = uint32(startupRandomData[4]) | 
uint32(startupRandomData[5])<<8 |
uint32(startupRandomData[6])<<16 | 
uint32(startupRandomData[7])<<24
+   case _AT_HWCAP:
+   cpu.HWCap = uint(val)
+   case _AT_HWCAP2:
+   cpu.HWCap2 = uint(val)
}
 }

Re: [PATCH] x86-64: Use TI->SF and TI->DF conversions in soft-fp

[Joseph Myers]

On Mon, 21 Jan 2019, H.J. Lu wrote:

> TI->SF and TI->DF conversions in libgcc2.c:
> 
> FSTYPE
> FUNC (DWtype u)
> {
>   ...
> }
> 
> have no rounding mode support.  We should replace __floattisf, __floattidf,
> __floatuntisf and __floatuntidf in libgcc2.c with these from soft-fp.

Please explain what you mean by "have no rounding mode support" (i.e., the 
exact flow through a function that is incorrect in a non-default rounding 
mode).  This patch is missing testcases - which of course should be 
architecture-independent.  (Any bug in libgcc2.c should first have an 
architecture-independent fix - it can't be considered fixed based on a fix 
for one architecture.  Then, if some other approach is optimal on 
particular architectures, they can get optimized variants.)

I believe all those function implementations are designed so that only a 
single rounding occurs, which is for the final result, so no explicit 
handling of rounding modes is ever needed (the integer code before then 
may set up sticky bits appropriately to ensure the floating-point parts of 
the code only need a single rounding, which works in all modes), but maybe 
there are bugs in certain cases.  To identify the correct fix, we need 
details of the exact code path being used (the exact values of the various 
macros, choices for the various conditional parts of the function, values 
each variable has at each point) and where the existing, 
rounding-mode-independent logic goes wrong.

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

libgo patch committed: Solaris fixes

[Ian Lance Taylor]

This libgo patch fixes the build and some tests for Solaris after the
recent update to 1.12beta2.  It also changes c-archive mode to fetch
argc/argv/env from /proc, which fixes it to work instead of crashing
as it did before.  Bootstrapped and ran Go testsuite on
x86_64-pc-linux-gnu and x86_64-sun-solaris2.11.  Committed to
mainline.

Ian
Index: gcc/go/gofrontend/MERGE
===
--- gcc/go/gofrontend/MERGE (revision 268129)
+++ gcc/go/gofrontend/MERGE (working copy)
@@ -1,4 +1,4 @@
-e7427654f3af83e1feea727a62a97172d7721403
+0c870ba6b3b43e0e56231f40c56b58dad0e36d9e
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
Index: libgo/Makefile.am
===
--- libgo/Makefile.am   (revision 268084)
+++ libgo/Makefile.am   (working copy)
@@ -1082,7 +1082,7 @@ $(eval $(call PACKAGE_template,internal/
 internal_x_net_lif_lo = \
internal/x/net/lif.lo
 internal_x_net_lif_check = \
-   internal_org/x/net/lif/check
+   internal/x/net/lif/check
 
 endif
 
Index: libgo/Makefile.in
===
--- libgo/Makefile.in   (revision 268084)
+++ libgo/Makefile.in   (working copy)
@@ -1131,7 +1131,7 @@ extra_check_libs_cmd_vet_internal_cfg =
 @LIBGO_IS_SOLARIS_TRUE@internal/x/net/lif.lo
 
 @LIBGO_IS_SOLARIS_TRUE@internal_x_net_lif_check = \
-@LIBGO_IS_SOLARIS_TRUE@internal_org/x/net/lif/check
+@LIBGO_IS_SOLARIS_TRUE@internal/x/net/lif/check
 
 TPACKAGES = $(shell cat $(srcdir)/check-packages.txt)
 TEST_PACKAGES = $(addsuffix /check,$(TPACKAGES)) \
Index: libgo/go/internal/x/net/lif/syscall.go
===
--- libgo/go/internal/x/net/lif/syscall.go  (revision 268084)
+++ libgo/go/internal/x/net/lif/syscall.go  (working copy)
@@ -11,18 +11,12 @@ import (
"unsafe"
 )
 
-//go:cgo_import_dynamic libc_ioctl ioctl "libc.so"
-
-//go:linkname procIoctl libc_ioctl
-
-var procIoctl uintptr
-
-func sysvicall6(trap, nargs, a1, a2, a3, a4, a5, a6 uintptr) (uintptr, 
uintptr, syscall.Errno)
+//extern __go_ioctl_ptr
+func libc_ioctl(int32, int32, unsafe.Pointer) int32
 
 func ioctl(s, ioc uintptr, arg unsafe.Pointer) error {
-   _, _, errno := sysvicall6(uintptr(unsafe.Pointer()), 3, s, 
ioc, uintptr(arg), 0, 0, 0)
-   if errno != 0 {
-   return error(errno)
+   if libc_ioctl(int32(s), int32(ioc), arg) < 0 {
+   return syscall.GetErrno()
}
return nil
 }
Index: libgo/go/internal/x/net/lif/zsys_solaris.go
===
--- libgo/go/internal/x/net/lif/zsys_solaris.go (nonexistent)
+++ libgo/go/internal/x/net/lif/zsys_solaris.go (working copy)
@@ -0,0 +1,101 @@
+// Created by cgo -godefs - DO NOT EDIT
+// cgo -godefs defs_solaris.go
+
+package lif
+
+import "unsafe"
+
+const (
+   sysAF_UNSPEC = 0x0
+   sysAF_INET   = 0x2
+   sysAF_INET6  = 0x1a
+
+   sysSOCK_DGRAM = 0x1
+)
+
+type sockaddrStorage struct {
+   Family uint16
+   X_ss_pad1  [6]int8
+   X_ss_align float64
+   X_ss_pad2  [240]int8
+}
+
+const (
+   sysLIFC_NOXMIT  = 0x1
+   sysLIFC_EXTERNAL_SOURCE = 0x2
+   sysLIFC_TEMPORARY   = 0x4
+   sysLIFC_ALLZONES= 0x8
+   sysLIFC_UNDER_IPMP  = 0x10
+   sysLIFC_ENABLED = 0x20
+
+   sysSIOCGLIFADDR= -0x3f87968f
+   sysSIOCGLIFDSTADDR = -0x3f87968d
+   sysSIOCGLIFFLAGS   = -0x3f87968b
+   sysSIOCGLIFMTU = -0x3f879686
+   sysSIOCGLIFNETMASK = -0x3f879683
+   sysSIOCGLIFMETRIC  = -0x3f879681
+   sysSIOCGLIFNUM = -0x3ff3967e
+   sysSIOCGLIFINDEX   = -0x3f87967b
+   sysSIOCGLIFSUBNET  = -0x3f879676
+   sysSIOCGLIFLNKINFO = -0x3f879674
+   sysSIOCGLIFCONF= -0x3fef965b
+   sysSIOCGLIFHWADDR  = -0x3f879640
+)
+
+const (
+   sysIFF_UP  = 0x1
+   sysIFF_BROADCAST   = 0x2
+   sysIFF_DEBUG   = 0x4
+   sysIFF_LOOPBACK= 0x8
+   sysIFF_POINTOPOINT = 0x10
+   sysIFF_NOTRAILERS  = 0x20
+   sysIFF_RUNNING = 0x40
+   sysIFF_NOARP   = 0x80
+   sysIFF_PROMISC = 0x100
+   sysIFF_ALLMULTI= 0x200
+   sysIFF_INTELLIGENT = 0x400
+   sysIFF_MULTICAST   = 0x800
+   sysIFF_MULTI_BCAST = 0x1000
+   sysIFF_UNNUMBERED  = 0x2000
+   sysIFF_PRIVATE = 0x8000
+)
+
+const (
+   sizeofLifnum   = 0xc
+   sizeofLifreq   = 0x178
+   sizeofLifconf  = 0x18
+   sizeofLifIfinfoReq = 0x10
+)
+
+type lifnum struct {
+   Familyuint16
+   Flags int32
+   Count int32
+}
+
+type lifreq struct {
+   Name   [32]int8
+   Lifru1 [4]byte
+   Type   uint32
+   Lifru  [336]byte
+}
+
+type lifconf struct {
+   Familyuint16
+   

Go patch committed: Stop archive iterator on error

[Ian Lance Taylor]

In the Go frontend, if there is an error reading or parsing an archive
header, the Archive_iterator code would return a dummy header but
would not mark itself as done.  The effect is that an invalid archive
leads to an endless loop reading and re-reading the same archive
header.  Avoid that by setting the offset to the end of the file,
which will cause the iterator to == archive_end.  No test since it
doesn't seem worth constructing an invalid archive.  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 268084)
+++ gcc/go/gofrontend/MERGE (working copy)
@@ -1,4 +1,4 @@
-c76ba3014e42cc6adc3d43709bba28c5ad7a6ba2
+e7427654f3af83e1feea727a62a97172d7721403
 
 The first line of this file holds the git revision number of the last
 merge done from the gofrontend repository.
Index: gcc/go/gofrontend/import-archive.cc
===
--- gcc/go/gofrontend/import-archive.cc (revision 268078)
+++ gcc/go/gofrontend/import-archive.cc (working copy)
@@ -780,6 +780,7 @@ Archive_iterator::read_next_header()
  >next_off_))
{
  this->header_.off = filesize;
+ this->off_ = filesize;
  return;
}
   this->header_.off = this->off_;

[committed] Fix DECL_OMP_PRIVATE_MEMBER copying in C++ cdtors (PR c++/88949)

[Jakub Jelinek]

Hi!

For DECL_OMP_PRIVATIZED_MEMBER vars, we can't really share the
DECL_VALUE_EXPR between the abstract cdtor and base/complete etc. cdtors,
it contains the this PARM_DECL and we need to adjust it to whatever the
particular variant has.

Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux,
committed to trunk.  Queued for backports.

2019-01-21  Jakub Jelinek  

PR c++/88949
* optimize.c (cxx_copy_decl): New function.
(clone_body): Use it instead of copy_decl_no_change.

* g++.dg/gomp/pr88949.C: New test.

--- gcc/cp/optimize.c.jj2019-01-01 12:37:47.359479419 +0100
+++ gcc/cp/optimize.c   2019-01-21 20:05:41.544921807 +0100
@@ -61,6 +61,25 @@ update_cloned_parm (tree parm, tree clon
   DECL_GIMPLE_REG_P (cloned_parm) = DECL_GIMPLE_REG_P (parm);
 }
 
+/* Like copy_decl_no_change, but handle DECL_OMP_PRIVATIZED_MEMBER
+   properly.  */
+
+static tree
+cxx_copy_decl (tree decl, copy_body_data *id)
+{
+  tree copy = copy_decl_no_change (decl, id);
+  if (VAR_P (decl)
+  && DECL_HAS_VALUE_EXPR_P (decl)
+  && DECL_ARTIFICIAL (decl)
+  && DECL_LANG_SPECIFIC (decl)
+  && DECL_OMP_PRIVATIZED_MEMBER (decl))
+{
+  tree expr = DECL_VALUE_EXPR (copy);
+  walk_tree (, copy_tree_body_r, id, NULL);
+  SET_DECL_VALUE_EXPR (copy, expr);
+}
+  return copy;
+}
 
 /* FN is a function in High GIMPLE form that has a complete body and no
CFG.  CLONE is a function whose body is to be set to a copy of FN,
@@ -80,7 +99,7 @@ clone_body (tree clone, tree fn, void *a
   id.src_cfun = DECL_STRUCT_FUNCTION (fn);
   id.decl_map = static_cast *> (arg_map);
 
-  id.copy_decl = copy_decl_no_change;
+  id.copy_decl = cxx_copy_decl;
   id.transform_call_graph_edges = CB_CGE_DUPLICATE;
   id.transform_new_cfg = true;
   id.transform_return_to_modify = false;
--- gcc/testsuite/g++.dg/gomp/pr88949.C.jj  2019-01-21 20:08:34.078099398 
+0100
+++ gcc/testsuite/g++.dg/gomp/pr88949.C 2019-01-21 20:08:12.437453419 +0100
@@ -0,0 +1,23 @@
+// PR c++/88949
+// { dg-do compile }
+
+struct A {
+  int a;
+  A (int x) : a (x) {
+#pragma omp parallel firstprivate (a)
+--a;
+  }
+  void foo () {
+#pragma omp parallel firstprivate (a)
+--a;
+  }
+};
+
+int c;
+
+int
+main ()
+{
+  A d(c);
+  d.foo ();
+}

Jakub

[PATCH] Fix up thread_jump handling of jumps with clobbers (PR rtl-optimization/88904)

[Jakub Jelinek]

Hi!

The following patch is miscompiled on arm thumb1, where there is
(jump_insn 32 31 33 4 (parallel [
(set (pc)
(if_then_else (ne (zero_extract:SI (reg:SI 3 r3 [orig:127 ret+8 
] [127])
(const_int 1 [0x1])
(const_int 0 [0]))
(const_int 0 [0]))
(label_ref 40)
(pc)))
(clobber (reg:SI 3 r3 [137]))
]) "pr88904.c":19:3 843 {*tbit_cbranch}
 (int_list:REG_BR_PROB 719407028 (nil))
 -> 40)
instruction as BB_END (b).  thread_jump sees the same condition in 2 of
these jumps, originally each one is comparing a different value in r3.
It processes with cselib's help first the bb containing the first jump and
then goes through all the instructions in b, computing the nonequal bitmap
which registers contain different values from the earlier bb.
After going through the entire b, it checks that the cond2 in BB_END (b)
doesn't use any of the registers that are different (in nonequal bitmap)
and later on that there aren't any other differences.
The problem is that when a register has CLOBBER, it is cleared from the
nonequal bitmap, so, if we check cond2 after processing the above JUMP_INSN,
we don't actually see any differences; but the condition uses the registers
from before that JUMP_INSN, where there is a difference.

The following patch fixes it by moving the cond2 verification right before
we process the last insn in b; we still need to process it for the decision
if there are any real differences later.

Bootstrapped/regtested on x86_64-linux and i686-linux, will
bootstrap/regtest on armv7hl-linux too, ok for trunk?

2019-01-21  Jakub Jelinek  

PR rtl-optimization/88904
* cfgcleanup.c (thread_jump): Verify cond2 doesn't mention
any nonequal registers before processing BB_END (b).

* gcc.c-torture/execute/pr88904.c: New test.

--- gcc/cfgcleanup.c.jj 2019-01-01 12:37:19.147942300 +0100
+++ gcc/cfgcleanup.c2019-01-21 16:45:52.576636305 +0100
@@ -338,6 +338,13 @@ thread_jump (edge e, basic_block b)
insn != NEXT_INSN (BB_END (b)) && !failed;
insn = NEXT_INSN (insn))
 {
+  /* cond2 must not mention any register that is not equal to the
+former block.  Check this before processing that instruction,
+as BB_END (b) could contain also clobbers.  */
+  if (insn == BB_END (b)
+ && mentions_nonequal_regs (cond2, nonequal))
+   goto failed_exit;
+
   if (INSN_P (insn))
{
  rtx pat = PATTERN (insn);
@@ -362,11 +369,6 @@ thread_jump (edge e, basic_block b)
   goto failed_exit;
 }
 
-  /* cond2 must not mention any register that is not equal to the
- former block.  */
-  if (mentions_nonequal_regs (cond2, nonequal))
-goto failed_exit;
-
   EXECUTE_IF_SET_IN_REG_SET (nonequal, 0, i, rsi)
 goto failed_exit;
 
--- gcc/testsuite/gcc.c-torture/execute/pr88904.c.jj2019-01-21 
16:47:16.194265770 +0100
+++ gcc/testsuite/gcc.c-torture/execute/pr88904.c   2019-01-21 
16:46:59.278543027 +0100
@@ -0,0 +1,38 @@
+/* PR rtl-optimization/88904 */
+
+volatile int v;
+
+__attribute__((noipa)) void
+bar (const char *x, const char *y, int z)
+{
+  if (!v)
+__builtin_abort ();
+  asm volatile ("" : "+g" (x));
+  asm volatile ("" : "+g" (y));
+  asm volatile ("" : "+g" (z));
+}
+
+#define my_assert(e) ((e) ? (void) 0 : bar (#e, __FILE__, __LINE__))
+
+typedef struct {
+  unsigned M1;
+  unsigned M2 : 1;
+  int : 0;
+  unsigned M3 : 1;
+} S;
+
+S
+foo ()
+{
+  S result = {0, 0, 1};
+  return result;
+}
+
+int
+main ()
+{
+  S ret = foo ();
+  my_assert (ret.M2 == 0);
+  my_assert (ret.M3 == 1);
+  return 0;
+}

Jakub

[PATCH] Fix REG_EQUAL notes for doubleword POPCOUNT etc. unops (PR target/88905)

[Jakub Jelinek]

Hi!

add_equal_note has special code to handle properly doubleword POPCOUNT and
similar builtins, e.g. for POPCOUNT if we don't have DImode POPCOUNT, it can
be expanded as 2 SImode POPCOUNTs added together, but for the REG_EQUAL note
we want lowpart SImode SUBREG of DImode POPCOUNT.

Unfortunately, this doesn't really work if the operand is constant and we
are unlucky enough that it hasn't been folded during GIMPLE optimizations
- we still need to use DImode POPCOUNT and take subreg of it.

The following patch fixes it by padding the op0's mode to the function too
and use it everywhere instead of GET_MODE (op0).  For op1 we don't really
need that, that is for binary operations where both arguments have the same
mode or we don't really care about the mode of the last operand (shifts).

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

2019-01-21  Jakub Jelinek  

PR target/88905
* optabs.c (add_equal_note): Add op0_mode argument, use it instead of
GET_MODE (op0).
(expand_binop_directly, expand_doubleword_clz,
expand_doubleword_popcount, expand_ctz, expand_ffs,
expand_unop_direct, maybe_emit_unop_insn): Adjust callers.

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

--- gcc/optabs.c.jj 2019-01-01 12:37:17.711965861 +0100
+++ gcc/optabs.c2019-01-21 13:56:18.263446049 +0100
@@ -55,7 +55,7 @@ void debug_optab_libfuncs (void);
 
 /* Add a REG_EQUAL note to the last insn in INSNS.  TARGET is being set to
the result of operation CODE applied to OP0 (and OP1 if it is a binary
-   operation).
+   operation).  OP0_MODE is OP0's mode.
 
If the last insn does not set TARGET, don't do anything, but return 1.
 
@@ -64,7 +64,8 @@ void debug_optab_libfuncs (void);
try again, ensuring that TARGET is not one of the operands.  */
 
 static int
-add_equal_note (rtx_insn *insns, rtx target, enum rtx_code code, rtx op0, rtx 
op1)
+add_equal_note (rtx_insn *insns, rtx target, enum rtx_code code, rtx op0,
+   rtx op1, machine_mode op0_mode)
 {
   rtx_insn *last_insn;
   rtx set;
@@ -136,16 +137,16 @@ add_equal_note (rtx_insn *insns, rtx tar
   case POPCOUNT:
   case PARITY:
   case BSWAP:
-   if (GET_MODE (op0) != VOIDmode && GET_MODE (target) != GET_MODE (op0))
+   if (op0_mode != VOIDmode && GET_MODE (target) != op0_mode)
  {
-   note = gen_rtx_fmt_e (code, GET_MODE (op0), copy_rtx (op0));
-   if (GET_MODE_UNIT_SIZE (GET_MODE (op0))
+   note = gen_rtx_fmt_e (code, op0_mode, copy_rtx (op0));
+   if (GET_MODE_UNIT_SIZE (op0_mode)
> GET_MODE_UNIT_SIZE (GET_MODE (target)))
  note = simplify_gen_unary (TRUNCATE, GET_MODE (target),
-note, GET_MODE (op0));
+note, op0_mode);
else
  note = simplify_gen_unary (ZERO_EXTEND, GET_MODE (target),
-note, GET_MODE (op0));
+note, op0_mode);
break;
  }
/* FALLTHRU */
@@ -1127,7 +1128,7 @@ expand_binop_directly (enum insn_code ic
   if (INSN_P (pat) && NEXT_INSN (pat) != NULL_RTX
  && ! add_equal_note (pat, ops[0].value,
   optab_to_code (binoptab),
-  ops[1].value, ops[2].value))
+  ops[1].value, ops[2].value, mode0))
{
  delete_insns_since (last);
  return expand_binop (mode, binoptab, op0, op1, NULL_RTX,
@@ -2298,7 +2299,7 @@ expand_doubleword_clz (scalar_int_mode m
   seq = get_insns ();
   end_sequence ();
 
-  add_equal_note (seq, target, CLZ, xop0, 0);
+  add_equal_note (seq, target, CLZ, xop0, NULL_RTX, mode);
   emit_insn (seq);
   return target;
 
@@ -2340,7 +2341,7 @@ expand_doubleword_popcount (scalar_int_m
   seq = get_insns ();
   end_sequence ();
 
-  add_equal_note (seq, t, POPCOUNT, op0, 0);
+  add_equal_note (seq, t, POPCOUNT, op0, NULL_RTX, mode);
   emit_insn (seq);
   return t;
 }
@@ -2511,7 +2512,7 @@ expand_ctz (scalar_int_mode mode, rtx op
   seq = get_insns ();
   end_sequence ();
 
-  add_equal_note (seq, temp, CTZ, op0, 0);
+  add_equal_note (seq, temp, CTZ, op0, NULL_RTX, mode);
   emit_insn (seq);
   return temp;
 }
@@ -2589,7 +2590,7 @@ expand_ffs (scalar_int_mode mode, rtx op
   seq = get_insns ();
   end_sequence ();
 
-  add_equal_note (seq, temp, FFS, op0, 0);
+  add_equal_note (seq, temp, FFS, op0, NULL_RTX, mode);
   emit_insn (seq);
   return temp;
 
@@ -2736,7 +2737,7 @@ expand_unop_direct (machine_mode mode, o
  if (INSN_P (pat) && NEXT_INSN (pat) != NULL_RTX
  && ! add_equal_note (pat, ops[0].value,
   optab_to_code (unoptab),
-  ops[1].value, NULL_RTX))
+  ops[1].value, NULL_RTX, mode))
{
  delete_insns_since 

[PATCH] Fix block copy/move/compare expansion (PR rtl-optimization/86334, PR target/88906)

[Jakub Jelinek]

Hi!

Apparently RTL DSE doesn't perform any kind of escape analysis for e.g.
frame pointer related addresses, instead relies on TREE_ADDRESSABLE being
set on MEM_EXPR VAR_DECLs if the address could leak to other functions.

Since PR49454 expr.c contains code to force those to be addressable
if they weren't addressable in GIMPLE, but it does so only before one of the
5 indirect emit_block_op_via_libcall callers, so it is done for memcpy, but
not for memmove, or memcmp, or for memcpy expanded from within the i386
backend's movmem etc.

Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trunk?

2019-01-21  Jakub Jelinek  

PR rtl-optimization/49429
PR target/49454
PR rtl-optimization/86334
PR target/88906
* expr.c (emit_block_move_hints): Move marking of MEM_EXPRs
addressable from here...
(emit_block_op_via_libcall): ... to here.

* gcc.target/i386/pr86334.c: New test.
* gcc.target/i386/pr88906.c: New test.

--- gcc/expr.c.jj   2019-01-10 11:43:08.958466880 +0100
+++ gcc/expr.c  2019-01-21 12:06:41.782406169 +0100
@@ -1631,14 +1631,6 @@ emit_block_move_hints (rtx x, rtx y, rtx
   if (may_use_call < 0)
return pc_rtx;
 
-  /* Since x and y are passed to a libcall, mark the corresponding
-tree EXPR as addressable.  */
-  tree y_expr = MEM_EXPR (y);
-  tree x_expr = MEM_EXPR (x);
-  if (y_expr)
-   mark_addressable (y_expr);
-  if (x_expr)
-   mark_addressable (x_expr);
   retval = emit_block_copy_via_libcall (x, y, size,
method == BLOCK_OP_TAILCALL);
 }
@@ -1884,6 +1876,15 @@ emit_block_op_via_libcall (enum built_in
   tree call_expr, dst_tree, src_tree, size_tree;
   machine_mode size_mode;
 
+  /* Since dst and src are passed to a libcall, mark the corresponding
+ tree EXPR as addressable.  */
+  tree dst_expr = MEM_EXPR (dst);
+  tree src_expr = MEM_EXPR (src);
+  if (dst_expr)
+mark_addressable (dst_expr);
+  if (src_expr)
+mark_addressable (src_expr);
+
   dst_addr = copy_addr_to_reg (XEXP (dst, 0));
   dst_addr = convert_memory_address (ptr_mode, dst_addr);
   dst_tree = make_tree (ptr_type_node, dst_addr);
--- gcc/testsuite/gcc.target/i386/pr86334.c.jj  2019-01-21 17:52:04.408370956 
+0100
+++ gcc/testsuite/gcc.target/i386/pr86334.c 2019-01-21 17:52:58.504482908 
+0100
@@ -0,0 +1,21 @@
+/* PR rtl-optimization/86334 */
+/* { dg-do run { target ia32 } } */
+/* { dg-options "-O -march=i386 -mtune=athlon -minline-all-stringops 
-minline-stringops-dynamically -mmemcpy-strategy=libcall:-1:align -Wno-psabi" } 
*/
+
+typedef int V __attribute__ ((vector_size (64)));
+
+static inline V
+foo (V g)
+{
+  g[0] = 4;
+  return g;
+}
+
+int
+main ()
+{
+  V x = foo ((V) { });
+  if (x[0] != 4 || x[1] || x[2] || x[3] || x[4] || x[5] || x[6] || x[7])
+__builtin_abort ();
+  return 0;
+}
--- gcc/testsuite/gcc.target/i386/pr88906.c.jj  2019-01-21 12:08:53.110252030 
+0100
+++ gcc/testsuite/gcc.target/i386/pr88906.c 2019-01-21 17:53:08.082325657 
+0100
@@ -0,0 +1,21 @@
+/* PR target/88906 */
+/* { dg-do run { target ia32 } } */
+/* { dg-options "-O -march=i386 -mtune=k6 -minline-all-stringops 
-minline-stringops-dynamically -mmemcpy-strategy=libcall:-1:align -Wno-psabi" } 
*/
+
+typedef unsigned V __attribute__ ((vector_size (16)));
+
+static inline V
+foo (V v)
+{
+  __builtin_sub_overflow (0, 0, [0]);
+  return v;
+}
+
+int
+main ()
+{
+  V v = foo ((V) { ~0 });
+  if (v[0] || v[1] || v[2] || v[3])
+__builtin_abort ();
+  return 0;
+}

Jakub

Re: [PATCH] Fix latent SLP bugs and a memleak

[Richard Sandiford]

Richard Biener  writes:
> @@ -5742,8 +5740,14 @@ vectorize_fold_left_reduction (stmt_vec_info stmt_info,
>auto_vec vec_oprnds0;
>if (slp_node)
>  {
> -  vect_get_vec_defs (op0, NULL_TREE, stmt_info, _oprnds0, NULL,
> -  slp_node);
> +  auto_vec > vec_defs (2);
> +  auto_vec sops(2);
> +  sops.quick_push (ops[0]);
> +  sops.quick_push (ops[1]);
> +  vect_get_slp_defs (sops, slp_node, _defs);
> +  vec_oprnds0.safe_splice (vec_defs[1 - reduc_index]);
> +  vec_defs[0].release ();
> +  vec_defs[1].release ();
>group_size = SLP_TREE_SCALAR_STMTS (slp_node).length ();
>scalar_dest_def_info = SLP_TREE_SCALAR_STMTS (slp_node)[group_size - 
> 1];
>  }

Ewww. :-)  Would be nice if it was easier to do the right thing.

But are you sure we want this for fold-left reductions?  The other
operand isn't supposed to be vectorised -- it stays a scalar even
in the vector loop.

Thanks,
Richard

Re: testsuite dg-directives glitches

[Dominique d'Humières]

Hi Manfred,

> could someone please check and commit?

Tested and committed as obvious at r268125.

Thanks for the patch.

Dominique

Re: V3 [PATCH] i386: Add pass_remove_partial_avx_dependency

[H.J. Lu]

On Mon, Jan 21, 2019 at 10:54 AM Jeff Law  wrote:
>
> On 1/7/19 6:55 AM, H.J. Lu wrote:
> > On Sun, Dec 30, 2018 at 8:40 AM H.J. Lu  wrote:
> >> On Wed, Nov 28, 2018 at 12:17 PM Jeff Law  wrote:
> >>> On 11/28/18 12:48 PM, H.J. Lu wrote:
>  On Mon, Nov 5, 2018 at 7:29 AM Jan Hubicka  wrote:
> >> On 11/5/18 7:21 AM, Jan Hubicka wrote:
>  Did you mean "the nearest common dominator"?
> >>> If the nearest common dominator appears in the loop while all uses are
> >>> out of loops, this will result in suboptimal xor placement.
> >>> In this case you want to split edges out of the loop.
> >>>
> >>> In general this is what the LCM framework will do for you if the 
> >>> problem
> >>> is modelled siimlar way as in mode_swtiching.  At entry function mode 
> >>> is
> >>> "no zero register needed" and all conversions need mode "zero register
> >>> needed".  Mode switching should then do the correct placement 
> >>> decisions
> >>> (reaching minimal number of executions of xor).
> >>>
> >>> Jeff, whan is your optinion on the approach taken by the patch?
> >>> It seems like a special case of more general issue, but I do not see
> >>> very elegant way to solve it at least in the GCC 9 horisont, so if
> >>> the placement is correct we can probalby go either with new pass or
> >>> making this part of mode swithcing (which is anyway run by x86 
> >>> backend)
> >> So I haven't followed this discussion at all, but did touch on this
> >> issue with some patch a month or two ago with a target patch that was
> >> trying to avoid the partial stalls.
> >>
> >> My assumption is that we're trying to find one or more places to
> >> initialize the upper half of an avx register so as to avoid partial
> >> register stall at existing sites that set the upper half.
> >>
> >> This sounds like a classic PRE/LCM style problem (of which mode
> >> switching is just another variant).   A common-dominator approach is
> >> closer to a classic GCSE and is going to result is more initializations
> >> at sub-optimal points than a PRE/LCM style.
> > yes, it is usual code placement problem. It is special case because the
> > zero register is not modified by the conversion (just we need to have
> > zero somewhere).  So basically we do not have kills to the zero except
> > for entry block.
> >
>  Do you have  testcase to show thatf the nearest common dominator
>  in the loop, while all uses areout of loops, leads to suboptimal xor
>  placement?
> >>> I don't have a testcase, but it's all but certain nearest common
> >>> dominator is going to be a suboptimal placement.  That's going to create
> >>> paths where you're going to emit the xor when it's not used.
> >>>
> >>> The whole point of the LCM algorithms is they are optimal in terms of
> >>> expression evaluations.
> >> We tried LCM and it didn't work well for this case.  LCM places a single
> >> VXOR close to the location where it is needed, which can be inside a
> >> loop.  There is nothing wrong with the LCM algorithms.   But this doesn't
> >> solve
> >>
> >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87007
> >>
> >> where VXOR is executed multiple times inside of a function, instead of
> >> just once.   We are investigating to generate a single VXOR at entry of the
> >> nearest dominator for basic blocks with SF/DF conversions, which is in
> >> the the fake loop that contains the whole function:
> >>
> >>   bb = nearest_common_dominator_for_set (CDI_DOMINATORS,
> >>  convert_bbs);
> >>   while (bb->loop_father->latch
> >>  != EXIT_BLOCK_PTR_FOR_FN (cfun))
> >> bb = get_immediate_dominator (CDI_DOMINATORS,
> >>   bb->loop_father->header);
> >>
> >>   insn = BB_HEAD (bb);
> >>   if (!NONDEBUG_INSN_P (insn))
> >> insn = next_nonnote_nondebug_insn (insn);
> >>   set = gen_rtx_SET (v4sf_const0, CONST0_RTX (V4SFmode));
> >>   set_insn = emit_insn_before (set, insn);
> >>
> > Here is the updated patch.  OK for trunk?
> >
> > Thanks.
> >
> > -- H.J.
> >
> >
> > 0001-i386-Add-pass_remove_partial_avx_dependency.patch
> >
> > From 6eca7dbf282d7e2a5cde41bffeca66195d72d48e Mon Sep 17 00:00:00 2001
> > From: "H.J. Lu" 
> > Date: Mon, 7 Jan 2019 05:44:59 -0800
> > Subject: [PATCH] i386: Add pass_remove_partial_avx_dependency
> >
> > With -mavx, for
> >
> > $ cat foo.i
> > extern float f;
> > extern double d;
> > extern int i;
> >
> > void
> > foo (void)
> > {
> >   d = f;
> >   f = i;
> > }
> >
> > we need to generate
> >
> >   vxorp[ds]   %xmmN, %xmmN, %xmmN
> >   ...
> >   vcvtss2sd   f(%rip), %xmmN, %xmmX
> >   ...
> >   vcvtsi2ss   i(%rip), %xmmN, %xmmY
> >
> > to avoid partial XMM register stall.  This patch adds a pass to generate
> > a single
> >
> >   vxorps  

[PATCH, d] Committed merge with upstream dmd

[Iain Buclaw]

Hi,

This patch merges the D front-end implementation with dmd upstream 180465274.

Main bulk of it reduces the memory footprint of the CTFE interpreter
by replacing new with emplacement new in many places.

Bootstrapped and regression tested on x86_64-linux-gnu.

Committed to trunk as r268124.

-- 
Iain
---
gcc/d/ChangeLog:

2019-01-21  Iain Buclaw  

* d-frontend.cc (Compiler::paintAsType): Update for new signature.
---
diff --git a/gcc/d/d-frontend.cc b/gcc/d/d-frontend.cc
index a1c0d53d1ca..d1d3c78ec86 100644
--- a/gcc/d/d-frontend.cc
+++ b/gcc/d/d-frontend.cc
@@ -446,7 +446,7 @@ Compiler::genCmain (Scope *sc)
so we just lower the value to GCC and return the converted CST.  */
 
 Expression *
-Compiler::paintAsType (Expression *expr, Type *type)
+Compiler::paintAsType (UnionExp *, Expression *expr, Type *type)
 {
   /* We support up to 512-bit values.  */
   unsigned char buffer[64];
diff --git a/gcc/d/dmd/MERGE b/gcc/d/dmd/MERGE
index a3b2db74af4..e8ab8df4f7b 100644
--- a/gcc/d/dmd/MERGE
+++ b/gcc/d/dmd/MERGE
@@ -1,4 +1,4 @@
-cd2034cd7b157dd8f3e94c684061bb1aa630b2b6
+180465274b72a2ff218449f6793af0fbaabbcaa3
 
 The first line of this file holds the git revision number of the last
 merge done from the dlang/dmd repository.
diff --git a/gcc/d/dmd/compiler.h b/gcc/d/dmd/compiler.h
index e8ab9925c5a..a8520788f98 100644
--- a/gcc/d/dmd/compiler.h
+++ b/gcc/d/dmd/compiler.h
@@ -19,6 +19,7 @@ class Expression;
 class Module;
 class Type;
 struct Scope;
+struct UnionExp;
 
 // DMD-generated module `__entrypoint` where the C main resides
 extern Module *entrypoint;
@@ -28,7 +29,7 @@ extern Module *rootHasMain;
 struct Compiler
 {
 // CTFE support for cross-compilation.
-static Expression *paintAsType(Expression *, Type *);
+static Expression *paintAsType(UnionExp *, Expression *, Type *);
 // Backend
 static void loadModule(Module *);
 static void genCmain(Scope *);
diff --git a/gcc/d/dmd/constfold.c b/gcc/d/dmd/constfold.c
index 83f0f3ef14f..ddd356bb966 100644
--- a/gcc/d/dmd/constfold.c
+++ b/gcc/d/dmd/constfold.c
@@ -1457,8 +1457,7 @@ UnionExp Slice(Type *type, Expression *e1, Expression *lwr, Expression *upr)
 memcpy(elements->tdata(),
es1->elements->tdata() + ilwr,
(size_t)(iupr - ilwr) * sizeof((*es1->elements)[0]));
-new() ArrayLiteralExp(e1->loc, elements);
-ue.exp()->type = type;
+new() ArrayLiteralExp(e1->loc, type, elements);
 }
 }
 else
@@ -1606,6 +1605,7 @@ UnionExp Cat(Type *type, Expression *e1, Expression *e2)
 
 new() StringExp(loc, s, len);
 StringExp *es = (StringExp *)ue.exp();
+es->type = type;
 es->sz = sz;
 es->committed = 1;
 }
@@ -1614,9 +1614,8 @@ UnionExp Cat(Type *type, Expression *e1, Expression *e2)
 // Create an ArrayLiteralExp
 Expressions *elements = new Expressions();
 elements->push(e);
-new() ArrayLiteralExp(e->loc, elements);
+new() ArrayLiteralExp(e->loc, type, elements);
 }
-ue.exp()->type = type;
 assert(ue.exp()->type);
 return ue;
 }
@@ -1627,8 +1626,7 @@ UnionExp Cat(Type *type, Expression *e1, Expression *e2)
 // Handle null ~= null
 if (t1->ty == Tarray && t2 == t1->nextOf())
 {
-new() ArrayLiteralExp(e1->loc, e2);
-ue.exp()->type = type;
+new() ArrayLiteralExp(e1->loc, type, e2);
 assert(ue.exp()->type);
 return ue;
 }
@@ -1695,9 +1693,8 @@ UnionExp Cat(Type *type, Expression *e1, Expression *e2)
 {
 (*elems)[i] = ea->getElement(i);
 }
-new() ArrayLiteralExp(e1->loc, elems);
+new() ArrayLiteralExp(e1->loc, type, elems);
 ArrayLiteralExp *dest = (ArrayLiteralExp *)ue.exp();
-dest->type = type;
 sliceAssignArrayLiteralFromString(dest, es, ea->elements->dim);
 assert(ue.exp()->type);
 return ue;
@@ -1715,9 +1712,8 @@ UnionExp Cat(Type *type, Expression *e1, Expression *e2)
 {
 (*elems)[es->len + i] = ea->getElement(i);
 }
-new() ArrayLiteralExp(e1->loc, elems);
+new() ArrayLiteralExp(e1->loc, type, elems);
 ArrayLiteralExp *dest = (ArrayLiteralExp *)ue.exp();
-dest->type = type;
 sliceAssignArrayLiteralFromString(dest, es, 0);
 assert(ue.exp()->type);
 return ue;
@@ -1783,7 +1779,7 @@ UnionExp Cat(Type *type, Expression *e1, Expression *e2)
 // Concatenate the arrays
 Expressions *elems = ArrayLiteralExp::copyElements(e1, e2);
 
-new() ArrayLiteralExp(e1->loc, elems);
+new() ArrayLiteralExp(e1->loc, NULL, elems);
 
 e = ue.exp();
 if (type->toBasetype()->ty == Tsarray)
@@ -1809,7 +1805,7 @@ UnionExp Cat(Type *type, Expression *e1, 

Re: [PATCH] introduce effective-target fold_memcpy

[Martin Sebor]

On 1/21/19 1:18 AM, Richard Biener wrote:

On Sat, Jan 19, 2019 at 12:25 AM Martin Sebor  wrote:


Some of the -Warray-bounds and -Wrestrict tests are prone to failing
on targets like arm-eabi and others that use different parameters to
decide which memcpy calls should be folded to MEM_REF (those that do
are copies of small power-of-two sizes where the power tends to vary
from target to target and may be as little as 1).  The failures then
waste the time of those who maintain those secondary targets reporting
failures (see * below), as well as those who wrote the tests debugging
the problems and working around them.

To reduce this effort (and ideally avoid these regressions going
forward) the attached patch adds a new effective-target to the test
harness: fold_memcpy_N.  It detects the target's willingness to fold
memcpy call of the given size (N).  While testing this with the arm
cross-compiler I also tweaked the tests that #include standard
headers to only do so when __has_include says the header exists.
This lets the tests pass even when using a cross-compiler without
library headers installed (my default MO).  If/when the warnings
are improved to detect the problems regardless of the folding as
I'm hoping to eventually do, this new effective-target feature
can be removed.


But all the memcpy folding does is see whether the target can
access unaligned {2,4,8,} memory.  So
a effective target unaligned_move_{2,4,8...} would be better and
possibly useful in other contexts?  memcpy folding might be indeed
a nice vehicle to test this property.

Thus, I guess I'm only asking to rename the effective target keyword.


I did this but after some more reading I no longer think we need it.


Btw, new effective targets need documenting in sourcebuild.texi


Thanks for the reminder!  While adding the new keyword I came across
non_strict_align.  It looks like it's pretty much same thing as what
I'm trying to add.  It's used in gcc.dg/memmove-4.c and memcpy-3.c
(besides a few other tests) to test the folding whose absence
the warnings depend on.

So I've simplified the patch to make use of non_strict_align instead.
I've verified the tests pass with arm-eabi, sparc-solaris2.11, and
x86_64.

Martin



Richard.


Martin

[*] https://gcc.gnu.org/ml/gcc-patches/2019-01/msg01056.html


gcc/testsuite/ChangeLog:

	* c-c++-common/Warray-bounds-2.c: Include headers only if they exist.
	* c-c++-common/Warray-bounds-3.c: Make xfails conditional on target
	non_strict_align.
	* c-c++-common/Wrestrict-2.c: Include headers only if they exist.
	* c-c++-common/Wrestrict.c: Make xfails conditional on target
	non_strict_align.

Index: gcc/testsuite/c-c++-common/Warray-bounds-2.c
===
--- gcc/testsuite/c-c++-common/Warray-bounds-2.c	(revision 268086)
+++ gcc/testsuite/c-c++-common/Warray-bounds-2.c	(working copy)
@@ -8,13 +8,28 @@
{ dg-do compile }
{ dg-options "-O2 -Warray-bounds -Wno-stringop-overflow" } */
 
-#include 
-#include 
+#if __has_include ()
+#  include 
+#else
+/* For cross-compilers.  */
+typedef __PTRDIFF_TYPE__   ptrdiff_t;
+typedef __SIZE_TYPE__  size_t;
+#endif
 
-#undef memcpy
-#undef strcpy
-#undef strncpy
+#if __has_include ()
+#  include 
+#  undef memcpy
+#  undef strcat
+#  undef strcpy
+#  undef strncpy
+#else
+extern void* memcpy (void*, const void*, size_t);
+extern char* strcat (char*, const char*);
+extern char* strcpy (char*, const char*);
+extern char* strncpy (char*, const char*, size_t);
+#endif
 
+
 #define MAX  (__SIZE_MAX__ / 2)
 
 void sink (void*);
Index: gcc/testsuite/c-c++-common/Warray-bounds-3.c
===
--- gcc/testsuite/c-c++-common/Warray-bounds-3.c	(revision 268086)
+++ gcc/testsuite/c-c++-common/Warray-bounds-3.c	(working copy)
@@ -158,7 +158,7 @@ void test_memcpy_overflow (char *d, const char *s,
  but known access size is detected.  This works except with small
  sizes that are powers of 2 due to bug .  */
   T (char, 1, arr + SR (DIFF_MAX - 1, DIFF_MAX), s, 1);
-  T (char, 1, arr + SR (DIFF_MAX - 1, DIFF_MAX), s, 2);  /* { dg-warning "pointer overflow between offset \\\[\[0-9\]+, \[0-9\]+] and size 2 accessing array " "bug " { xfail *-*-* } } */
+  T (char, 1, arr + SR (DIFF_MAX - 1, DIFF_MAX), s, 2);  /* { dg-warning "pointer overflow between offset \\\[\[0-9\]+, \[0-9\]+] and size 2 accessing array " "bug " { xfail non_strict_align } } */
   T (char, 1, arr + SR (DIFF_MAX - 2, DIFF_MAX), s, 3);  /* { dg-warning "pointer overflow between offset \\\[\[0-9\]+, \[0-9\]+] and size 3 accessing array " "memcpy" } */
   T (char, 1, arr + SR (DIFF_MAX - 4, DIFF_MAX), s, 5);  /* { dg-warning "pointer overflow between offset \\\[\[0-9\]+, \[0-9\]+] and size 5 accessing array " "memcpy" } */
 }
Index: gcc/testsuite/c-c++-common/Wrestrict-2.c
===
--- gcc/testsuite/c-c++-common/Wrestrict-2.c	

[PATCH, i386]: Fix PR88938, ICE in extract_insn

[Uros Bizjak]

We need to sanitize operands to fit insn predicates.

2019-01-21  Uroš Bizjak  

PR target/88938
* config/i386/i386.c (ix86_expand_builtin) [case IX86_BUILTIN_BEXTRI32,
case IX86_BUILTIN_BEXTRI64]: Sanitize operands.

testsuite/ChangeLog:

2019-01-21  Uroš Bizjak  

PR target/88938
* gcc.target/i386/pr88938.c: New test.

Bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.

Committed to mainline, will be backported to release branches.

Uros.
Index: config/i386/i386.c
===
--- config/i386/i386.c  (revision 268116)
+++ config/i386/i386.c  (working copy)
@@ -37215,6 +37215,16 @@ ix86_expand_builtin (tree exp, rtx target, rtx sub
   unsigned char lsb_index = INTVAL (op1) & 0xFF;
   op1 = GEN_INT (length);
   op2 = GEN_INT (lsb_index);
+
+ mode1 = insn_data[icode].operand[1].mode;
+ if (!insn_data[icode].operand[1].predicate (op0, mode1))
+   op0 = copy_to_mode_reg (mode1, op0);
+
+ mode0 = insn_data[icode].operand[0].mode;
+ if (target == 0
+ || !register_operand (target, mode0))
+   target = gen_reg_rtx (mode0);
+
   pat = GEN_FCN (icode) (target, op0, op1, op2);
   if (pat)
 emit_insn (pat);
Index: testsuite/gcc.target/i386/pr88938.c
===
--- testsuite/gcc.target/i386/pr88938.c (nonexistent)
+++ testsuite/gcc.target/i386/pr88938.c (working copy)
@@ -0,0 +1,5 @@
+/* PR target/88938 */
+/* { dg-do compile } */
+/* { dg-options "-Og -fno-tree-ccp -fno-tree-fre -mtbm" } */
+
+#include "tbm-bextri-1.c"

Re: C++ PATCH for c++/78244 - narrowing conversion in template not detected, part 2

[Jason Merrill]

On 1/18/19 9:12 AM, Marek Polacek wrote:

On Thu, Jan 17, 2019 at 04:17:29PM -0500, Jason Merrill wrote:

On 1/17/19 2:09 PM, Marek Polacek wrote:

This patch ought to fix the rest of 78244, a missing narrowing warning in
decltype.

As I explained in Bugzilla, there can be three scenarios:

1) decltype is in a template and it has no dependent expressions, which
is the problematical case.  finish_compound_literal just returns the
compound literal without checking narrowing if processing_template_decl.


This is the sort of thing that we've been gradually fixing: if the compound
literal isn't dependent at all, we want to do the normal processing.  And
then usually return a result based on the original trees rather than the
result of processing.  For instance, finish_call_expr.  Something like that
ought to work here, too, and be more generally applicable; this shouldn't be
limited to casting to a scalar type, casting to a known class type can also
involve narrowing.


Great, that works just fine.  I also had to check if the type is
type-dependent, otherwise complete_type could fail.


The check in the other patch that changes instantiation_dependent_r should
be more similar to the one in finish_compound_literal.  Or perhaps you could
set a flag here in finish_compound_literal to indicate that it's
instantiation-dependent, and just check that in instantiation_dependent_r.


Done, but I feel bad about adding another flag.  But I guess it's cheaper
this way.  Thanks!

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

2019-01-18  Marek Polacek  

PR c++/88815 - narrowing conversion lost in decltype.
PR c++/78244 - narrowing conversion in template not detected.
* cp-tree.h (CONSTRUCTOR_IS_DEPENDENT): New.
* pt.c (instantiation_dependent_r): Consider a CONSTRUCTOR with
CONSTRUCTOR_IS_DEPENDENT instantiation-dependent.
* semantics.c (finish_compound_literal): When the compound literal
isn't instantiation-dependent and the type isn't type-dependent,
fall back to the normal processing.  Don't only call check_narrowing
for scalar types.  Set CONSTRUCTOR_IS_DEPENDENT.

* g++.dg/cpp0x/Wnarrowing15.C: New test.
* g++.dg/cpp0x/constexpr-decltype3.C: New test.
* g++.dg/cpp1y/Wnarrowing1.C: New test.

diff --git gcc/cp/cp-tree.h gcc/cp/cp-tree.h
index 5cc8f88d522..778874cccd6 100644
--- gcc/cp/cp-tree.h
+++ gcc/cp/cp-tree.h
@@ -424,6 +424,7 @@ extern GTY(()) tree cp_global_trees[CPTI_MAX];
DECL_FINAL_P (in FUNCTION_DECL)
QUALIFIED_NAME_IS_TEMPLATE (in SCOPE_REF)
DECLTYPE_FOR_INIT_CAPTURE (in DECLTYPE_TYPE)
+  CONSTRUCTOR_IS_DEPENDENT (in CONSTRUCTOR)
TINFO_USED_TEMPLATE_ID (in TEMPLATE_INFO)
PACK_EXPANSION_SIZEOF_P (in *_PACK_EXPANSION)
OVL_USING_P (in OVERLOAD)
@@ -4202,6 +4203,11 @@ more_aggr_init_expr_args_p (const 
aggr_init_expr_arg_iterator *iter)
 B b{1,2}, not B b({1,2}) or B b = {1,2}.  */
  #define CONSTRUCTOR_IS_DIRECT_INIT(NODE) (TREE_LANG_FLAG_0 (CONSTRUCTOR_CHECK 
(NODE)))
  
+/* True if this CONSTRUCTOR is instantiation-dependent and needs to be

+   substituted.  */
+#define CONSTRUCTOR_IS_DEPENDENT(NODE) \
+  (TREE_LANG_FLAG_1 (CONSTRUCTOR_CHECK (NODE)))
+
  /* True if this CONSTRUCTOR should not be used as a variable initializer
 because it was loaded from a constexpr variable with mutable fields.  */
  #define CONSTRUCTOR_MUTABLE_POISON(NODE) \
diff --git gcc/cp/pt.c gcc/cp/pt.c
index e4f76478f54..ae77bae6b29 100644
--- gcc/cp/pt.c
+++ gcc/cp/pt.c
@@ -25800,6 +25800,11 @@ instantiation_dependent_r (tree *tp, int 
*walk_subtrees,
return *tp;
break;
  
+case CONSTRUCTOR:

+  if (CONSTRUCTOR_IS_DEPENDENT (*tp))
+   return *tp;
+  break;
+
  default:
break;
  }
diff --git gcc/cp/semantics.c gcc/cp/semantics.c
index e654750d249..4ff09ad3fb7 100644
--- gcc/cp/semantics.c
+++ gcc/cp/semantics.c
@@ -2795,11 +2795,14 @@ finish_compound_literal (tree type, tree 
compound_literal,
  return error_mark_node;
}
  
-  if (processing_template_decl)

+  if (instantiation_dependent_expression_p (compound_literal)
+  || dependent_type_p (type))
  {
TREE_TYPE (compound_literal) = type;
/* Mark the expression as a compound literal.  */
TREE_HAS_CONSTRUCTOR (compound_literal) = 1;
+  /* And as instantiation-dependent.  */
+  CONSTRUCTOR_IS_DEPENDENT (compound_literal) = true;
if (fcl_context == fcl_c99)
CONSTRUCTOR_C99_COMPOUND_LITERAL (compound_literal) = 1;
return compound_literal;
@@ -2822,8 +2825,7 @@ finish_compound_literal (tree type, tree compound_literal,
&& check_array_initializer (NULL_TREE, type, compound_literal))
  return error_mark_node;
compound_literal = reshape_init (type, compound_literal, complain);
-  if (SCALAR_TYPE_P (type)
-  && !BRACE_ENCLOSED_INITIALIZER_P (compound_literal)
+  if 

Re: [C++ PATCH] Fix -fsanitize=pointer-compare,pointer-subtract ICEs in templates (PR sanitizer/88901)

[Jason Merrill]

On 1/18/19 5:38 PM, Jakub Jelinek wrote:

Hi!

When processing_template_decl, all we care about is diagnostics
and the return type if it is not dependent; other spots that add
sanitization do nothing if processing_template_decl and the following patch
does that for the two recently added ones.

Without it, save_expr is called on potentially dependent FE expressions the
middle-end doesn't handle.

Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trunk?

2019-01-18  Jakub Jelinek  

PR sanitizer/88901
* typeck.c (cp_build_binary_op): Don't instrument
SANITIZE_POINTER_COMPARE if processing_template_decl.
(pointer_diff): Similarly for SANITIZE_POINTER_SUBTRACT.


OK.

Jason

Re: V3 [PATCH] i386: Add pass_remove_partial_avx_dependency

[Jeff Law]

On 1/7/19 6:55 AM, H.J. Lu wrote:
> On Sun, Dec 30, 2018 at 8:40 AM H.J. Lu  wrote:
>> On Wed, Nov 28, 2018 at 12:17 PM Jeff Law  wrote:
>>> On 11/28/18 12:48 PM, H.J. Lu wrote:
 On Mon, Nov 5, 2018 at 7:29 AM Jan Hubicka  wrote:
>> On 11/5/18 7:21 AM, Jan Hubicka wrote:
 Did you mean "the nearest common dominator"?
>>> If the nearest common dominator appears in the loop while all uses are
>>> out of loops, this will result in suboptimal xor placement.
>>> In this case you want to split edges out of the loop.
>>>
>>> In general this is what the LCM framework will do for you if the problem
>>> is modelled siimlar way as in mode_swtiching.  At entry function mode is
>>> "no zero register needed" and all conversions need mode "zero register
>>> needed".  Mode switching should then do the correct placement decisions
>>> (reaching minimal number of executions of xor).
>>>
>>> Jeff, whan is your optinion on the approach taken by the patch?
>>> It seems like a special case of more general issue, but I do not see
>>> very elegant way to solve it at least in the GCC 9 horisont, so if
>>> the placement is correct we can probalby go either with new pass or
>>> making this part of mode swithcing (which is anyway run by x86 backend)
>> So I haven't followed this discussion at all, but did touch on this
>> issue with some patch a month or two ago with a target patch that was
>> trying to avoid the partial stalls.
>>
>> My assumption is that we're trying to find one or more places to
>> initialize the upper half of an avx register so as to avoid partial
>> register stall at existing sites that set the upper half.
>>
>> This sounds like a classic PRE/LCM style problem (of which mode
>> switching is just another variant).   A common-dominator approach is
>> closer to a classic GCSE and is going to result is more initializations
>> at sub-optimal points than a PRE/LCM style.
> yes, it is usual code placement problem. It is special case because the
> zero register is not modified by the conversion (just we need to have
> zero somewhere).  So basically we do not have kills to the zero except
> for entry block.
>
 Do you have  testcase to show thatf the nearest common dominator
 in the loop, while all uses areout of loops, leads to suboptimal xor
 placement?
>>> I don't have a testcase, but it's all but certain nearest common
>>> dominator is going to be a suboptimal placement.  That's going to create
>>> paths where you're going to emit the xor when it's not used.
>>>
>>> The whole point of the LCM algorithms is they are optimal in terms of
>>> expression evaluations.
>> We tried LCM and it didn't work well for this case.  LCM places a single
>> VXOR close to the location where it is needed, which can be inside a
>> loop.  There is nothing wrong with the LCM algorithms.   But this doesn't
>> solve
>>
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87007
>>
>> where VXOR is executed multiple times inside of a function, instead of
>> just once.   We are investigating to generate a single VXOR at entry of the
>> nearest dominator for basic blocks with SF/DF conversions, which is in
>> the the fake loop that contains the whole function:
>>
>>   bb = nearest_common_dominator_for_set (CDI_DOMINATORS,
>>  convert_bbs);
>>   while (bb->loop_father->latch
>>  != EXIT_BLOCK_PTR_FOR_FN (cfun))
>> bb = get_immediate_dominator (CDI_DOMINATORS,
>>   bb->loop_father->header);
>>
>>   insn = BB_HEAD (bb);
>>   if (!NONDEBUG_INSN_P (insn))
>> insn = next_nonnote_nondebug_insn (insn);
>>   set = gen_rtx_SET (v4sf_const0, CONST0_RTX (V4SFmode));
>>   set_insn = emit_insn_before (set, insn);
>>
> Here is the updated patch.  OK for trunk?
> 
> Thanks.
> 
> -- H.J.
> 
> 
> 0001-i386-Add-pass_remove_partial_avx_dependency.patch
> 
> From 6eca7dbf282d7e2a5cde41bffeca66195d72d48e Mon Sep 17 00:00:00 2001
> From: "H.J. Lu" 
> Date: Mon, 7 Jan 2019 05:44:59 -0800
> Subject: [PATCH] i386: Add pass_remove_partial_avx_dependency
> 
> With -mavx, for
> 
> $ cat foo.i
> extern float f;
> extern double d;
> extern int i;
> 
> void
> foo (void)
> {
>   d = f;
>   f = i;
> }
> 
> we need to generate
> 
>   vxorp[ds]   %xmmN, %xmmN, %xmmN
>   ...
>   vcvtss2sd   f(%rip), %xmmN, %xmmX
>   ...
>   vcvtsi2ss   i(%rip), %xmmN, %xmmY
> 
> to avoid partial XMM register stall.  This patch adds a pass to generate
> a single
> 
>   vxorps  %xmmN, %xmmN, %xmmN
> 
> at entry of the nearest dominator for basic blocks with SF/DF conversions,
> which is in the fake loop that contains the whole function, instead of
> generating one
> 
>   vxorp[ds]   %xmmN, %xmmN, %xmmN
> 
> for each SF/DF conversion.
> 
> NB: The LCM algorithm isn't 

Re: [PATCH] x86-64: Use TI->SF and TI->DF conversions in soft-fp

[H.J. Lu]

On Mon, Jan 21, 2019 at 9:09 AM H.J. Lu  wrote:
>
> On Mon, Jan 21, 2019 at 8:59 AM Uros Bizjak  wrote:
> >
> > On Mon, Jan 21, 2019 at 5:56 PM H.J. Lu  wrote:
> > >
> > > On Mon, Jan 21, 2019 at 8:43 AM Uros Bizjak  wrote:
> > > >
> > > > On Mon, Jan 21, 2019 at 5:15 PM H.J. Lu  wrote:
> > > > >
> > > > > TI->SF and TI->DF conversions in libgcc2.c:
> > > > >
> > > > > FSTYPE
> > > > > FUNC (DWtype u)
> > > > > {
> > > > >   ...
> > > > > }
> > > > >
> > > > > have no rounding mode support.  We should replace __floattisf, 
> > > > > __floattidf,
> > > > > __floatuntisf and __floatuntidf in libgcc2.c with these from soft-fp.
> > > > >
> > > > > PR libgcc/88931
> > > > > * config/i386/64/t-softfp-compat (libgcc2-ti-functions): New.
> > > > > (LIB2FUNCS_EXCLUDE): Likewise.
> > > > > (libgcc2-ti-softp): Likewise.
> > > > > (LIB2ADD): Likewise.
> > > > > ---
> > > > >  libgcc/config/i386/64/t-softfp-compat | 8 
> > > > >  1 file changed, 8 insertions(+)
> > > > >
> > > > > diff --git a/libgcc/config/i386/64/t-softfp-compat 
> > > > > b/libgcc/config/i386/64/t-softfp-compat
> > > > > index 0978695c3a4..abb78032bf5 100644
> > > > > --- a/libgcc/config/i386/64/t-softfp-compat
> > > > > +++ b/libgcc/config/i386/64/t-softfp-compat
> > > > > @@ -13,3 +13,11 @@ libgcc2-tf-functions = _divtc3 _multc3 _powitf2
> > > > >  LIB2FUNCS_EXCLUDE += $(libgcc2-tf-functions)
> > > > >  libgcc2-tf-compats = $(addsuffix .c, $(libgcc2-tf-functions))
> > > > >  LIB2ADD += $(addprefix $(srcdir)/config/i386/64/, 
> > > > > $(libgcc2-tf-compats))
> > > > > +
> > > > > +# Replace _floatdisf, _floatdidf, _floatundisf and _floatundidf in
> > > > > +# libgcc2.c, which have no rounding mode support, with floattisf.c,
> > > > > +# floattidf.c, floatundisf.c and floatundidf.c from soft-fp.
> > > > > +libgcc2-ti-functions = _floatdisf _floatdidf _floatundisf 
> > > > > _floatundidf
> > > > > +LIB2FUNCS_EXCLUDE += $(libgcc2-ti-functions)
> > > > > +libgcc2-ti-softp = floattisf.c floattidf.c floatuntisf.c 
> > > > > floatuntidf.c
> > > > > +LIB2ADD += $(addprefix $(srcdir)/soft-fp/, $(libgcc2-ti-softp))
> > > >
> > > > It is not that simple. Please note that libgcc2 functions use FP
> > > > instructions in narrower mode (so, in effect still use FPU), while
> > > > soft-fp functions don't even touch the FPU, and do everything using
> > > > bit twiddling. I think that your change would introduce qoute
> > > > noticeable runtime regressions.
> > > >
> > >
> > > By "run-time regressions", did you mean performance or correctness?
> >
> > Performance.
> >
>
> We will check performance change.
>

I created a micro benchmark on int128/double branch at

https://github.com/hjl-tools/microbenchmark

On Coffee Lake, I got

[hjl@gnu-cfl-2 microbenchmark]$ make
gcc -g -I. -O2   -c -o test.o test.c
gcc -g   -c -o libgcc2.o libgcc2.S
gcc -g   -c -o soft-fp.o soft-fp.S
gcc -g   -c -o floattidf-libgcc2.o floattidf-libgcc2.S
gcc -g   -c -o floattidf-soft-fp.o floattidf-soft-fp.S
gcc -o test test.o libgcc2.o soft-fp.o floattidf-libgcc2.o floattidf-soft-fp.o
./test
3 loops:
total  : 4.499767e+16
libgcc2: 2299371252
total  : 4.499767e+16
soft-fp: 3122038661 (135.78%)
[hjl@gnu-cfl-2 microbenchmark]$

We will collect SPEC CPU 2017 numbers.

-- 
H.J.

[PATCH] Add target-zlib to top-level configure, use zlib from libphobos

[Iain Buclaw]

Hi,

Following on from the last, this adds target-zlib to target_libraries
and updates libphobos build scripts to link to libz_convenience.a.
The D front-end already has target-zlib in d/config-lang.in.

Is the top-level part OK?  I considered disabling target-zlib if
libphobos is not being built, but decided against unless it's
requested.

-- 
Iain
---
ChangeLog:

2019-01-21  Iain Buclaw  

* configure.ac: configure.ac: Add target-zlib to target_libraries.
* configure: Regenerate.

libphobos/ChangeLog:

2019-01-21  Iain Buclaw  

* m4/druntime/libraries.m4 (DRUNTIME_LIBRARIES_ZLIB): Use
libz_convenience.a if not using system zlib.
* Makefile.in: Regenerate.
* configure: Regenerate.
* libdruntime/Makefile.in: Regenerate.
* src/Makefile.am: Remove ZLIB_CSOURCES and AM_CFLAGS.
* src/Makefile.in: Regenerate.
* testsuite/Makefile.in: Regenerate.

---
diff --git a/configure b/configure
index adf4fda0f69..1c5f9b502a8 100755
--- a/configure
+++ b/configure
@@ -2813,7 +2813,8 @@ target_libraries="target-libgcc \
 		target-libobjc \
 		target-libada \
 		target-libgo \
-		target-libphobos"
+		target-libphobos \
+		target-zlib"
 
 # these tools are built using the target libraries, and are intended to
 # run only in the target environment
diff --git a/configure.ac b/configure.ac
index 87f2aee0500..cffccd37805 100644
--- a/configure.ac
+++ b/configure.ac
@@ -163,7 +163,8 @@ target_libraries="target-libgcc \
 		target-libobjc \
 		target-libada \
 		target-libgo \
-		target-libphobos"
+		target-libphobos \
+		target-zlib"
 
 # these tools are built using the target libraries, and are intended to
 # run only in the target environment
diff --git a/libphobos/Makefile.in b/libphobos/Makefile.in
index 3059196d75a..6a7793a75e8 100644
--- a/libphobos/Makefile.in
+++ b/libphobos/Makefile.in
@@ -15,7 +15,7 @@
 @SET_MAKE@
 
 # Makefile for the toplevel directory of the D Standard library.
-# Copyright (C) 2006-2018 Free Software Foundation, Inc.
+# Copyright (C) 2006-2019 Free Software Foundation, Inc.
 #
 # GCC is free software; you can redistribute it and/or modify
 # it under the terms of the GNU General Public License as published by
@@ -240,6 +240,7 @@ LIBBACKTRACE = @LIBBACKTRACE@
 LIBOBJS = @LIBOBJS@
 LIBS = @LIBS@
 LIBTOOL = @LIBTOOL@
+LIBZ = @LIBZ@
 LIPO = @LIPO@
 LN_S = @LN_S@
 LTLIBOBJS = @LTLIBOBJS@
@@ -319,7 +320,6 @@ phobos_compiler_shared_flag = @phobos_compiler_shared_flag@
 prefix = @prefix@
 program_transform_name = @program_transform_name@
 psdir = @psdir@
-runstatedir = @runstatedir@
 sbindir = @sbindir@
 sharedstatedir = @sharedstatedir@
 srcdir = @srcdir@
diff --git a/libphobos/configure b/libphobos/configure
index d247d9adc1f..4828c4a7927 100755
--- a/libphobos/configure
+++ b/libphobos/configure
@@ -640,8 +640,7 @@ gdc_include_dir
 libphobos_toolexeclibdir
 libphobos_toolexecdir
 gcc_version
-DRUNTIME_ZLIB_SYSTEM_FALSE
-DRUNTIME_ZLIB_SYSTEM_TRUE
+LIBZ
 BACKTRACE_SUPPORTS_THREADS
 BACKTRACE_USES_MALLOC
 BACKTRACE_SUPPORTED
@@ -782,7 +781,6 @@ infodir
 docdir
 oldincludedir
 includedir
-runstatedir
 localstatedir
 sharedstatedir
 sysconfdir
@@ -821,7 +819,7 @@ enable_unix
 enable_thread_lib
 with_libatomic
 with_libbacktrace
-with_target_system_zlib
+with_system_zlib
 with_cross_host
 enable_version_specific_runtime_libs
 '
@@ -868,7 +866,6 @@ datadir='${datarootdir}'
 sysconfdir='${prefix}/etc'
 sharedstatedir='${prefix}/com'
 localstatedir='${prefix}/var'
-runstatedir='${localstatedir}/run'
 includedir='${prefix}/include'
 oldincludedir='/usr/include'
 docdir='${datarootdir}/doc/${PACKAGE_TARNAME}'
@@ -1121,15 +1118,6 @@ do
   | -silent | --silent | --silen | --sile | --sil)
 silent=yes ;;
 
-  -runstatedir | --runstatedir | --runstatedi | --runstated \
-  | --runstate | --runstat | --runsta | --runst | --runs \
-  | --run | --ru | --r)
-ac_prev=runstatedir ;;
-  -runstatedir=* | --runstatedir=* | --runstatedi=* | --runstated=* \
-  | --runstate=* | --runstat=* | --runsta=* | --runst=* | --runs=* \
-  | --run=* | --ru=* | --r=*)
-runstatedir=$ac_optarg ;;
-
   -sbindir | --sbindir | --sbindi | --sbind | --sbin | --sbi | --sb)
 ac_prev=sbindir ;;
   -sbindir=* | --sbindir=* | --sbindi=* | --sbind=* | --sbin=* \
@@ -1267,7 +1255,7 @@ fi
 for ac_var in	exec_prefix prefix bindir sbindir libexecdir datarootdir \
 		datadir sysconfdir sharedstatedir localstatedir includedir \
 		oldincludedir docdir infodir htmldir dvidir pdfdir psdir \
-		libdir localedir mandir runstatedir
+		libdir localedir mandir
 do
   eval ac_val=\$$ac_var
   # Remove trailing slashes.
@@ -1420,7 +1408,6 @@ Fine tuning of the installation directories:
   --sysconfdir=DIRread-only single-machine data [PREFIX/etc]
   --sharedstatedir=DIRmodifiable architecture-independent data [PREFIX/com]
   --localstatedir=DIR modifiable single-machine data [PREFIX/var]
-  --runstatedir=DIR   modifiable per-process data [LOCALSTATEDIR/run]
   --libdir=DIRobject code 

Re: [patch] Document AMD GCN features.

[Jeff Law]

On 1/18/19 4:42 AM, Andrew Stubbs wrote:
> Hi,
> 
> This patch adds the documentation needed for the newly-added AMD GCN
> back end.
> 
> OK to commit?
> 
> Andrew
> 
> 190118-gcc-gcn-docs.patch
> 
> Document AMD GCN.
> 
> 2019-01-18  Andrew Stubbs  
> 
>   gcc/
>   * doc/extend.tex (AMD GCN Function Attributes): New section.
>   * doc/install.texi (amdgcn-unknown-amdhsa): New instructions.
>   * doc/invoke.texi (AMD GCN Options): New section.
>   * doc/md.texi (Constraints for Particular Machines): Add AMD GCN.
OK
jeff

Re: [PATCH] sched-ebb.c: avoid moving table jumps (PR rtl-optimization/88423)

[Jeff Law]

On 1/18/19 10:32 AM, David Malcolm wrote:
> PR rtl-optimization/88423 reports an ICE within sched-ebb.c's
> begin_move_insn, failing the assertion at line 175, where there's
> no fall-through edge:
> 
> 171 rtx_insn *x = NEXT_INSN (insn);
> 172 if (e)
> 173   gcc_checking_assert (NOTE_P (x) || LABEL_P (x));
> 174 else
> 175   gcc_checking_assert (BARRIER_P (x));
> 
> "insn" is a jump_insn for a table jump, and its NEXT_INSN is the
> placeholder code_label, followed by the jump_table_data.
> 
> It's not clear to me if such a jump_insn can be repositioned within
> the insn stream, or if the scheduler is able to do so.  I believe a
> tablejump is always at the end of such a head/tail insn sub-stream.
> Is it a requirement that the placeholder code_label for the jump_insn
> is always its NEXT_INSN?
> 
> The loop at the start of schedule_ebb adjusts the head and tail
> of the insns to be scheduled so that it skips leading and trailing notes
> and debug insns.
> 
> This patch adjusts that loop to also skip trailing jump_insn instances
> that are table jumps, so that we don't attempt to move such table jumps.
> 
> This fixes the ICE, but I'm not very familiar with this part of the
> compiler - so I have two questions:
> 
> (1) What does GCC mean by "ebb" in this context?
> 
> My understanding is that the normal definition of an "extended basic
> block" (e.g. Muchnick's book pp175-177) is that it's a maximal grouping
> of basic blocks where only one BB in each group has multiple in-edges
> and all other BBs in the group have a single in-edge (and thus e.g.
> there's a tree-like structure of BBs within each EBB).
> 
> From what I can tell, schedule_ebbs is iterating over BBs, looking for
> runs of BBs joined by next_bb that are connected by fallthrough edges
> and don't have labels (and aren't flagged with BB_DISABLE_SCHEDULE).
> It uses this run of BBs to generate a run of instructions within the
> NEXT_INSN/PREV_INSN doubly-linked list, which it passes as "head"
> and "tail" to schedule_ebb.
> 
> This sounds like it will be a group of basic blocks with single in-edges
> internally, but it isn't a *maximal* group of such BBs - but perhaps
> it's "maximal" in the sense of what the NEXT_INSN/PREV_INSN
> representation can cope with?
> 
> There (presumably) can't be a fallthrough edge after a table jump, so
> a table jump could only ever be at the end of such a chain, never in the
> middle.
> 
> (2) Is it OK to omit "tail" from consideration here, from a dataflow
> and insn-dependency point-of-view?  Presumably the scheduler is written
> to ensure that data used by subsequent basic blocks will still be available
> after the insns within an "EBB" are reordered, so presumably any data
> uses *within* the jump_insn are still going to be available - but, as I
> said, I'm not very familiar with this part of the code.  (I think I'm also
> assuming that the jump_insn can't clobber data, just the PC)
> 
> Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
> 
> OK for trunk?
> 
> gcc/ChangeLog:
>   PR rtl-optimization/88423
>   * sched-ebb.c (schedule_ebb): Don't move the jump_insn for a table
>   jump.
> 
> gcc/testsuite/ChangeLog:
>   PR rtl-optimization/88423
>   * gcc.c-torture/compile/pr88423.c: New test.
I wonder if this should be generalized for SCHED_GROUP_P which is hte
standard mechanism we use to ensure two insns fire together.

Can you check if SCHED_GROUP_P is set on either the jump or the jump
table (I forget if it belongs on the first or the last insn).

It may make more sense to be checking for SCHED_GROUP_P in sched_ebb
rather than special casing tablejump_p.


I'm not likely to be able to dig further into this for a while.  Vlad
might be able to provide guidance.

jeff

[committed][PATCH][GCC][AArch64] Fix big-endian and ILP32 fail for simd-clone test

[Tamar Christina]

Hi All,

This fixes the failing testcase for simd-clone-7.cc for the ILP32
case and big-endian.  

Regtested on aarch64-none-linux-gnu and aarch6_be-none-elf and no issues.

Committed under the GCC obvious rule.

Thanks,
Tamar

gcc/testsuite/ChangeLog:

2019-01-21  Tamar Christina  

* g++.dg/vect/simd-clone-7.cc: Fix assembler scan.

-- 
diff --git a/gcc/testsuite/g++.dg/vect/simd-clone-7.cc b/gcc/testsuite/g++.dg/vect/simd-clone-7.cc
index c2a63cd5f8e2e7e3e37ccc2991c27e0cf72f99fa..527bbd94d30cb075d651cb7845a2fa320a2d12f2 100644
--- a/gcc/testsuite/g++.dg/vect/simd-clone-7.cc
+++ b/gcc/testsuite/g++.dg/vect/simd-clone-7.cc
@@ -8,4 +8,5 @@ bar (float x, float *y, int)
 {
   return y[0] + y[1] * x;
 }
-// { dg-warning "GCC does not currently support mixed size types for 'simd' functions" "" { target aarch64-*-* } .-4 }
+// { dg-warning "GCC does not currently support mixed size types for 'simd' functions" "" { target { { aarch64*-*-* } && lp64 } } .-4 }
+

RE: [EXT] Re: [Patch 2/4][Aarch64] v2: Implement Aarch64 SIMD ABI

[Tamar Christina]

Hi Richard,

> -Original Message-
> From: Richard Sandiford 
> Sent: Monday, January 21, 2019 16:42
> To: Tamar Christina 
> Cc: Steve Ellcey ; christophe.l...@linaro.org; gcc-
> patc...@gcc.gnu.org; nd 
> Subject: Re: [EXT] Re: [Patch 2/4][Aarch64] v2: Implement Aarch64 SIMD ABI
> 
> Tamar Christina  writes:
> > Hi All,
> >
> > The simd-clone-7.cc tests seem to fail on big-endian with
> >
> > testsuite/g++.dg/vect/simd-clone-7.cc:7:1: warning: GCC does not
> > currently support mixed size types for 'simd' functions
> >
> > The test probably miss an effective target check?
> 
> The current condition is:
> 
> // { dg-warning "GCC does not currently support mixed size types for 'simd'
> functions" "" { target aarch64-*-* } .-4 }
> 
> That would need to be aarch64*-*-* to include big-endian.  Fixing that here
> and in the other tests is OK under the obvious rule.

Ah, true, I didn't look at the testcase. I tested the ILP32 case and committed 
the fix for both.

Thanks,
Tamar

> 
> Adding && lp64 (as per Steve's patch below) is OK too if it works.
> 
> Thanks,
> Richard
> 
> >> -Original Message-
> >> From: gcc-patches-ow...@gcc.gnu.org 
> >> On Behalf Of Steve Ellcey
> >> Sent: Friday, January 18, 2019 17:58
> >> To: christophe.l...@linaro.org
> >> Cc: gcc-patches@gcc.gnu.org; Richard Sandiford
> >> 
> >> Subject: Re: [EXT] Re: [Patch 2/4][Aarch64] v2: Implement Aarch64
> >> SIMD ABI
> >>
> >> On Fri, 2019-01-18 at 15:35 +0100, Christophe Lyon wrote:
> >> >
> >> > Hi Steve,
> >> >
> >> > I've noticed that
> >> > FAIL: g++.dg/vect/simd-clone-7.cc  -std=c++14  (test for warnings,
> >> > line 7) (and for c++17 and c++98) when forcing -mabi=ilp32.
> >> >
> >> > I suspect you want to skip the test in this case?
> >> >
> >> > Christophe
> >>
> >> Actually, I think we can compile that test, it just would not
> >> generate a warning in ILP32 mode because int, floats and pointers
> >> would now all be the same size.  So I think the fix is:
> >>
> >>
> >> % git diff simd-clone-7.cc
> >> diff --git a/gcc/testsuite/g++.dg/vect/simd-clone-7.cc
> >> b/gcc/testsuite/g++.dg/vect/simd-clone-7.cc
> >> index c2a63cd5f8e..3617f0ab6a7 100644
> >> --- a/gcc/testsuite/g++.dg/vect/simd-clone-7.cc
> >> +++ b/gcc/testsuite/g++.dg/vect/simd-clone-7.cc
> >> @@ -8,4 +8,4 @@ bar (float x, float *y, int)  {
> >>return y[0] + y[1] * x;
> >>  }
> >> -// { dg-warning "GCC does not currently support mixed size types for
> 'simd'
> >> functions" "" { target aarch64-*-* } .-4 }
> >> +// { dg-warning "GCC does not currently support mixed size types for
> >> +'simd' functions" "" { target { { aarch64-*-* } && lp64 } } .-4 }
> >>
> >>
> >> I haven't tested this, I don't have an ILP32 build sitting around right 
> >> now.
> >> Does it work for you?  I can build a toolchain, test it, and submit a
> >> patch if you want.
> >>
> >>
> >> Steve Ellcey
> >> sell...@marvell.com

Re: [PATCH] doc: showcase a "union of vectors" pattern (PR 88698)

[Alexander Monakov]

On Mon, 21 Jan 2019, Richard Biener wrote:

> > Sorry, I don't see what you mean here; can you give an example or elaborate?
> 
> when you call a function with v4si signature but want to pass it a result
> from a __mm intrinsic you'd need a temporary union to do the marshalling.
> I think you can use a union argument in the function itself and you can
> elide the temporary then if you use transparent_union.  But I didn't try.

Ah, I see now.  I agree transparent_union ought to work, but today both GCC
and Clang will reject such attempt; I've filed PR 88955 for the GCC issue.

So unfortunately such code would still need a cast or an unnamed temporary,
which may be relatively obvious to the reader.

Alexander

Re: [C++ Patch] Locations related grokdeclarator tweak

[Paolo Carlini]

Hi,

On 21/01/19 18:22, Jason Merrill wrote:

On 1/18/19 6:13 AM, Paolo Carlini wrote:
a tweak to typespec_loc, where the existing conditional turns out to 
be just a special case of the full min_location that we want in order 
to do the right thing for testcases like diagnostic/trailing1.C. 
Tested x86_64-linux.


This is OK, but I don't think we want to keep messing with diagnostic 
locations now that we're in stage 4.  This isn't a regression fix, is it?


I agree, isn't a regression fix and probably we don't want to (further 
;) mess with locations in stage 4. In any case, I'm essentially done 
with most of the low hanging fruits, I continued for a while with what I 
had ready... Anyway, that said, what do you think, shall I schedule this 
one for next Stage 1?


Thanks! Paolo.

Re: [C++ PATCH] [PR87770] test partial specializations for type dependence

[Jason Merrill]

On 1/18/19 1:55 AM, Alexandre Oliva wrote:

When instantiating a partial specialization of a template member
function for a full specialization of a class template, we test
whether the context of variables local to the partial specialization,
i.e., the partial specialization itself, is dependent, and this ICEs
in type_dependent_expression_p, when checking that the function type
isn't type-dependent because it is not in a type-dependent scope.

We shouldn't have got that far: the previous block in
type_dependent_expression_p catches cases in which the function itself
takes template arguments of its own, but it only did so for primary
templates, not for partial specializations.  This patch fixes that.


I guess we need a different predicate than PRIMARY_TEMPLATE_P to mean 
"does this have its own template arguments, not just the ones from its 
enclosing class?".  There are several other places that will need to be 
adjusted as well.


I don't think that PRIMARY_TEMPLATE_P || DECL_TEMPLATE_SPECIALIZATION is 
the right test, as I would expect that the latter will also be true of 
specializations that have no template arguments of their own.


Perhaps compare the number of levels of template arguments of the 
function to that of its enclosing context?


Jason

Re: [C++ Patch] Locations related grokdeclarator tweak

[Jason Merrill]

On 1/18/19 6:13 AM, Paolo Carlini wrote:
a tweak to typespec_loc, where the existing conditional turns out to be 
just a special case of the full min_location that we want in order to do 
the right thing for testcases like diagnostic/trailing1.C. Tested 
x86_64-linux.


This is OK, but I don't think we want to keep messing with diagnostic 
locations now that we're in stage 4.  This isn't a regression fix, is it?


Jason

Re: Patch ping (Re: [wwwdocs] Add __cpp_* feature macros to C++20 entries + other changes that have those in projects/cxx_status.html)

[Jonathan Wakely]

On 21/01/19 17:36 +0100, Jakub Jelinek wrote:

On Mon, Jan 21, 2019 at 04:11:04PM +, Jonathan Wakely wrote:

> I'd like to ping this patch.

For P0941R2 I think we can just say it's supported. For the library
docs I said we support it since GCC 5.1 because that's when we started
defining feature test macros. The point of the paper is to define
macros for the features that are supported, and we've been doing that
for years. If a macro is missing, it's because we don't support the
feature yet, and that's a correct implementation of the macro!


So what about saying it is supported since e.g. 5 when __has_cpp_attribute
support has been added (or 4.9 when first __cpp_* predefined macros were
added)?  Like below.
What about the rest, ok for wwwdocs?


LGTM.

Re: [PATCH] x86-64: Use TI->SF and TI->DF conversions in soft-fp

[H.J. Lu]

On Mon, Jan 21, 2019 at 8:59 AM Uros Bizjak  wrote:
>
> On Mon, Jan 21, 2019 at 5:56 PM H.J. Lu  wrote:
> >
> > On Mon, Jan 21, 2019 at 8:43 AM Uros Bizjak  wrote:
> > >
> > > On Mon, Jan 21, 2019 at 5:15 PM H.J. Lu  wrote:
> > > >
> > > > TI->SF and TI->DF conversions in libgcc2.c:
> > > >
> > > > FSTYPE
> > > > FUNC (DWtype u)
> > > > {
> > > >   ...
> > > > }
> > > >
> > > > have no rounding mode support.  We should replace __floattisf, 
> > > > __floattidf,
> > > > __floatuntisf and __floatuntidf in libgcc2.c with these from soft-fp.
> > > >
> > > > PR libgcc/88931
> > > > * config/i386/64/t-softfp-compat (libgcc2-ti-functions): New.
> > > > (LIB2FUNCS_EXCLUDE): Likewise.
> > > > (libgcc2-ti-softp): Likewise.
> > > > (LIB2ADD): Likewise.
> > > > ---
> > > >  libgcc/config/i386/64/t-softfp-compat | 8 
> > > >  1 file changed, 8 insertions(+)
> > > >
> > > > diff --git a/libgcc/config/i386/64/t-softfp-compat 
> > > > b/libgcc/config/i386/64/t-softfp-compat
> > > > index 0978695c3a4..abb78032bf5 100644
> > > > --- a/libgcc/config/i386/64/t-softfp-compat
> > > > +++ b/libgcc/config/i386/64/t-softfp-compat
> > > > @@ -13,3 +13,11 @@ libgcc2-tf-functions = _divtc3 _multc3 _powitf2
> > > >  LIB2FUNCS_EXCLUDE += $(libgcc2-tf-functions)
> > > >  libgcc2-tf-compats = $(addsuffix .c, $(libgcc2-tf-functions))
> > > >  LIB2ADD += $(addprefix $(srcdir)/config/i386/64/, 
> > > > $(libgcc2-tf-compats))
> > > > +
> > > > +# Replace _floatdisf, _floatdidf, _floatundisf and _floatundidf in
> > > > +# libgcc2.c, which have no rounding mode support, with floattisf.c,
> > > > +# floattidf.c, floatundisf.c and floatundidf.c from soft-fp.
> > > > +libgcc2-ti-functions = _floatdisf _floatdidf _floatundisf _floatundidf
> > > > +LIB2FUNCS_EXCLUDE += $(libgcc2-ti-functions)
> > > > +libgcc2-ti-softp = floattisf.c floattidf.c floatuntisf.c floatuntidf.c
> > > > +LIB2ADD += $(addprefix $(srcdir)/soft-fp/, $(libgcc2-ti-softp))
> > >
> > > It is not that simple. Please note that libgcc2 functions use FP
> > > instructions in narrower mode (so, in effect still use FPU), while
> > > soft-fp functions don't even touch the FPU, and do everything using
> > > bit twiddling. I think that your change would introduce qoute
> > > noticeable runtime regressions.
> > >
> >
> > By "run-time regressions", did you mean performance or correctness?
>
> Performance.
>

We will check performance change.

-- 
H.J.

Re: libgo patch committed: Update to Go1.12beta2

[Ian Lance Taylor]

On Mon, Jan 21, 2019 at 4:22 AM Matthias Klose  wrote:
>
> On 18.01.19 20:04, Ian Lance Taylor wrote:
> > I have committed a patch to update libgo to the Go 1.12beta2 release.
> >
> > As usual this sort of update is too large to include all changes in
> > this e-mail.  I've included changes to gccgo-specific files below.
> >
> > Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu.  Committed
> > to mainline.
>
> this broke the ARM32 builds:
>
> libtool: compile:  /<>/build/./gcc/gccgo
> -B/<>/build/./gcc/ -B/usr/arm-linux-gnueabihf/bin/
> -B/usr/arm-linux-gnueabihf/lib/ -isystem /usr
> /arm-linux-gnueabihf/include -isystem /usr/arm-linux-gnueabihf/sys-include
> -isystem /<>/build/sys-include -fchecking=1 -O2 -g -I . -c
> -fgo-pkgpath=int
> ernal/cpu ../../../src/libgo/go/internal/cpu/cpu.go cpugen.go  -fPIC -o
> internal/.libs/cpu.o
> ../../../src/libgo/go/internal/cpu/cpu.go:138:2: error: reference to undefined
> name 'doinit'
>   138 |  doinit()
>   |  ^
> make[6]: *** [Makefile:2843: internal/cpu.lo] Error 1
> make[6]: Leaving directory '/<>/build/arm-linux-gnueabihf/libgo'
> make[5]: *** [Makefile:2241: all-recursive] Error 1

This is PR 88927.  There is a patch out for review.


> on the HURD (without any local patches):
>
> gccgo: fatal error: no input files
> compilation terminated.
> Makefile:2843: recipe for target 'runtime.lo' failed
> make[6]: *** [runtime.lo] Error 1
> make[6]: Leaving directory '/<>/build/i686-gnu/libgo'
> Makefile:2241: recipe for target 'all-recursive' failed
> make[5]: *** [all-recursive] Error 1

Last I heard Svante was going to send another set of Hurd patches.

Ian

Re: [PATCH] x86-64: Use TI->SF and TI->DF conversions in soft-fp

[Uros Bizjak]

On Mon, Jan 21, 2019 at 5:56 PM H.J. Lu  wrote:
>
> On Mon, Jan 21, 2019 at 8:43 AM Uros Bizjak  wrote:
> >
> > On Mon, Jan 21, 2019 at 5:15 PM H.J. Lu  wrote:
> > >
> > > TI->SF and TI->DF conversions in libgcc2.c:
> > >
> > > FSTYPE
> > > FUNC (DWtype u)
> > > {
> > >   ...
> > > }
> > >
> > > have no rounding mode support.  We should replace __floattisf, 
> > > __floattidf,
> > > __floatuntisf and __floatuntidf in libgcc2.c with these from soft-fp.
> > >
> > > PR libgcc/88931
> > > * config/i386/64/t-softfp-compat (libgcc2-ti-functions): New.
> > > (LIB2FUNCS_EXCLUDE): Likewise.
> > > (libgcc2-ti-softp): Likewise.
> > > (LIB2ADD): Likewise.
> > > ---
> > >  libgcc/config/i386/64/t-softfp-compat | 8 
> > >  1 file changed, 8 insertions(+)
> > >
> > > diff --git a/libgcc/config/i386/64/t-softfp-compat 
> > > b/libgcc/config/i386/64/t-softfp-compat
> > > index 0978695c3a4..abb78032bf5 100644
> > > --- a/libgcc/config/i386/64/t-softfp-compat
> > > +++ b/libgcc/config/i386/64/t-softfp-compat
> > > @@ -13,3 +13,11 @@ libgcc2-tf-functions = _divtc3 _multc3 _powitf2
> > >  LIB2FUNCS_EXCLUDE += $(libgcc2-tf-functions)
> > >  libgcc2-tf-compats = $(addsuffix .c, $(libgcc2-tf-functions))
> > >  LIB2ADD += $(addprefix $(srcdir)/config/i386/64/, $(libgcc2-tf-compats))
> > > +
> > > +# Replace _floatdisf, _floatdidf, _floatundisf and _floatundidf in
> > > +# libgcc2.c, which have no rounding mode support, with floattisf.c,
> > > +# floattidf.c, floatundisf.c and floatundidf.c from soft-fp.
> > > +libgcc2-ti-functions = _floatdisf _floatdidf _floatundisf _floatundidf
> > > +LIB2FUNCS_EXCLUDE += $(libgcc2-ti-functions)
> > > +libgcc2-ti-softp = floattisf.c floattidf.c floatuntisf.c floatuntidf.c
> > > +LIB2ADD += $(addprefix $(srcdir)/soft-fp/, $(libgcc2-ti-softp))
> >
> > It is not that simple. Please note that libgcc2 functions use FP
> > instructions in narrower mode (so, in effect still use FPU), while
> > soft-fp functions don't even touch the FPU, and do everything using
> > bit twiddling. I think that your change would introduce qoute
> > noticeable runtime regressions.
> >
>
> By "run-time regressions", did you mean performance or correctness?

Performance.

Uros.

> --
> H.J.

Re: [PATCH] Fix issues with -Waddress-of-packed-member

[Jeff Law]

On 1/20/19 10:10 AM, Bernd Edlinger wrote:
> On 1/20/19 4:40 PM, H.J. Lu wrote:
>> On Sun, Jan 20, 2019 at 5:29 AM Bernd Edlinger
>>  wrote:
>>> Hi,
>>>
>>>
>>> I tried to build linux yesterday, and became aware that there are a few
>>> false-positive warnings with -Waddress-of-packed-member:
>>>
>>> struct t {
>>>   char a;
>>>   int b;
>>>   int *c;
>>>   int d[10];
>>> } __attribute__((packed));
>>>
>>> struct t t0;
>>> struct t *t1;
>>> struct t **t2;
>>>
>>> t2 = 
>>> i1 = t0.c;
>>>
>>> I fixed them quickly with the attached patch, and added a new test case,
>>> which also revealed a few missing warnings:
>>>
>>> struct t t100[10][10];
>>> struct t (*baz())[10];
>>>
>>> t2 = (struct t**) t100;
>>> t2 = (struct t**) baz();
>>>
>>>
>>> Well I remembered that Joseph wanted me to use min_align_of_type instead
>>> of TYPE_ALIGN in the -Wcast-align warning, so I changed 
>>> -Waddress-of-packed-member
>>> to do that as well.
>>>
>>> Since I was not sure if the test coverage is good enough, I added a few more
>>> test cases, which just make sure the existing warning works properly.
>> You should also fix
>>
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88928
>>
> Yes, thanks.  I added a check for NULL from TYPE_STUB_DECL here:
> 
> + tree decl = TYPE_STUB_DECL (rhstype);
> + if (decl)
> +   inform (DECL_SOURCE_LOCATION (decl), "defined here");
> 
> and the test case from the PR.
> 
>>> I am however not sure of a warning that is as noisy as this one, should be
>>> default-enabled, because it might interfere with configure tests.  That 
>>> might
>> These codes can lead unaligned access which may be very hard to track
>> down or fix since  the codes in question may be in a library.  I think it is 
>> a
>> very useful warning.  Besides, these noisy warnings also reveal 
>> implementation
>> issues in GCC, which, otherwise, may not be known for a long time.
>>
> No doubt that is a useful warning there is no question about that.
> 
> Are you concerned about production code that gets built w/o at least -Wall ?
> 
> I am however not sure, why it is limited to packed structures.
> 
>>> be better to enable this warning, in -Wall or -Wextra, and, well maybe
>>> enable -Wcast-align=strict also at the same warning level, since it is 
>>> currently
>>> not enabled at all, unless explicitly requested, what do you think?
>>>
> I just see, your warning as being similar in spirit as -Wcast-align, since
> if type casts are involved, you don't need packed structures to get unaligned
> pointers.  So what I wonder now is, if it is a bit inconsistent to have
> -Wcast-align=strict not being enabled at least with -Wextra, while
> -Waddress-of-packed-member being default enabled.  I am just unsure if one day
> -Wcast-align should be enabled by -Wall/-Wextra or per default as well, or 
> being
> superseded by -Waddress-of-packed-member.  I mean, except for the limitation
> on requiring the packed keyword on structures, -Waddress-of-packed-member is 
> now
> a superset of -Wcast-align=strict, you know.
> 
> 
> Anyway, new patch version with fix for PR 88928 attached.
> 
> 
> Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
> Is it OK for trunk?
> 
> 
> Thanks
> Bernd.
> 
> 
> patch-fix-packed-warning-v2.diff
> 
> 2019-01-20  Bernd Edlinger  
> 
>   PR c/88928
>   * c-warn.c (check_alignment_of_packed_member): Add a boolean parameter
>   for rvalue context.  Handle rvalues correctly.  Use min_align_of_type
>   instead of TYPE_ALIGN.
>   (check_address_or_pointer_of_packed_member): Handle rvalues coorrectly.
>   Use min_align_of_type instead of TYPE_ALIGN_UNIT.  Check for NULL
>   pointer from TYPE_STUB_DECL.
> 
> testsuite:
> 2019-01-20  Bernd Edlinger  
> 
>   PR c/88928
>   * c-c++-common/Waddress-of-packed-member-1.c: New test case.
>   * gcc.dg/pr88928.c: New test case.
OK.  Thanks for digging into this.

jeff

Re: [PATCH] x86-64: Use TI->SF and TI->DF conversions in soft-fp

[H.J. Lu]

On Mon, Jan 21, 2019 at 8:43 AM Uros Bizjak  wrote:
>
> On Mon, Jan 21, 2019 at 5:15 PM H.J. Lu  wrote:
> >
> > TI->SF and TI->DF conversions in libgcc2.c:
> >
> > FSTYPE
> > FUNC (DWtype u)
> > {
> >   ...
> > }
> >
> > have no rounding mode support.  We should replace __floattisf, __floattidf,
> > __floatuntisf and __floatuntidf in libgcc2.c with these from soft-fp.
> >
> > PR libgcc/88931
> > * config/i386/64/t-softfp-compat (libgcc2-ti-functions): New.
> > (LIB2FUNCS_EXCLUDE): Likewise.
> > (libgcc2-ti-softp): Likewise.
> > (LIB2ADD): Likewise.
> > ---
> >  libgcc/config/i386/64/t-softfp-compat | 8 
> >  1 file changed, 8 insertions(+)
> >
> > diff --git a/libgcc/config/i386/64/t-softfp-compat 
> > b/libgcc/config/i386/64/t-softfp-compat
> > index 0978695c3a4..abb78032bf5 100644
> > --- a/libgcc/config/i386/64/t-softfp-compat
> > +++ b/libgcc/config/i386/64/t-softfp-compat
> > @@ -13,3 +13,11 @@ libgcc2-tf-functions = _divtc3 _multc3 _powitf2
> >  LIB2FUNCS_EXCLUDE += $(libgcc2-tf-functions)
> >  libgcc2-tf-compats = $(addsuffix .c, $(libgcc2-tf-functions))
> >  LIB2ADD += $(addprefix $(srcdir)/config/i386/64/, $(libgcc2-tf-compats))
> > +
> > +# Replace _floatdisf, _floatdidf, _floatundisf and _floatundidf in
> > +# libgcc2.c, which have no rounding mode support, with floattisf.c,
> > +# floattidf.c, floatundisf.c and floatundidf.c from soft-fp.
> > +libgcc2-ti-functions = _floatdisf _floatdidf _floatundisf _floatundidf
> > +LIB2FUNCS_EXCLUDE += $(libgcc2-ti-functions)
> > +libgcc2-ti-softp = floattisf.c floattidf.c floatuntisf.c floatuntidf.c
> > +LIB2ADD += $(addprefix $(srcdir)/soft-fp/, $(libgcc2-ti-softp))
>
> It is not that simple. Please note that libgcc2 functions use FP
> instructions in narrower mode (so, in effect still use FPU), while
> soft-fp functions don't even touch the FPU, and do everything using
> bit twiddling. I think that your change would introduce qoute
> noticeable runtime regressions.
>

By "run-time regressions", did you mean performance or correctness?

-- 
H.J.

Re: [PATCH] Fix issues with -Waddress-of-packed-member

[Jeff Law]

On 1/20/19 6:29 AM, Bernd Edlinger wrote:
> Hi,
> 
> 
> I tried to build linux yesterday, and became aware that there are a few
> false-positive warnings with -Waddress-of-packed-member:
> 
> struct t {
>   char a;
>   int b;
>   int *c;
>   int d[10];
> } __attribute__((packed));
> 
> struct t t0;
> struct t *t1;
> struct t **t2;
> 
> t2 = 
> i1 = t0.c;
> 
> I fixed them quickly with the attached patch, and added a new test case,
> which also revealed a few missing warnings:
> 
> struct t t100[10][10];
> struct t (*baz())[10];
> 
> t2 = (struct t**) t100;
> t2 = (struct t**) baz();
> 
> 
> Well I remembered that Joseph wanted me to use min_align_of_type instead
> of TYPE_ALIGN in the -Wcast-align warning, so I changed 
> -Waddress-of-packed-member
> to do that as well.
> 
> Since I was not sure if the test coverage is good enough, I added a few more
> test cases, which just make sure the existing warning works properly.
> 
> I am however not sure of a warning that is as noisy as this one, should be
> default-enabled, because it might interfere with configure tests.  That might
> be better to enable this warning, in -Wall or -Wextra, and, well maybe
> enable -Wcast-align=strict also at the same warning level, since it is 
> currently
> not enabled at all, unless explicitly requested, what do you think?
Across Fedora there's only around a dozen packages that tripped over
this.  That's a small enough set that I'm not terribly concerned about
the noise factor.

jeff

Re: [PATCH] Fix gcc.dg/utf-array.c testcase

[Jeff Law]

On 1/21/19 9:00 AM, Tamar Christina wrote:
> Forwarding to list.
> 
>> -Original Message-
>> From: Tamar Christina
>> Sent: Monday, January 21, 2019 15:25
>> To: 'Jakub Jelinek' ; Jason Merrill 
>> Cc: gcc-patches@gcc.gnu.org
>> Subject: RE: [PATCH] Fix gcc.dg/utf-array.c testcase
>>
>> Hi,
>>
>> These fail on aarch64*-*-* and arm*-*-* too, but this patch fixes it.
>>
>> So gentle ping? 
ACK.  Please install, a goodly number of my testers tripped over this.
I don't like lots of red dots in my jenkins builds :-)

jeff

Re: [PATCH] x86-64: Use TI->SF and TI->DF conversions in soft-fp

[Uros Bizjak]

On Mon, Jan 21, 2019 at 5:15 PM H.J. Lu  wrote:
>
> TI->SF and TI->DF conversions in libgcc2.c:
>
> FSTYPE
> FUNC (DWtype u)
> {
>   ...
> }
>
> have no rounding mode support.  We should replace __floattisf, __floattidf,
> __floatuntisf and __floatuntidf in libgcc2.c with these from soft-fp.
>
> PR libgcc/88931
> * config/i386/64/t-softfp-compat (libgcc2-ti-functions): New.
> (LIB2FUNCS_EXCLUDE): Likewise.
> (libgcc2-ti-softp): Likewise.
> (LIB2ADD): Likewise.
> ---
>  libgcc/config/i386/64/t-softfp-compat | 8 
>  1 file changed, 8 insertions(+)
>
> diff --git a/libgcc/config/i386/64/t-softfp-compat 
> b/libgcc/config/i386/64/t-softfp-compat
> index 0978695c3a4..abb78032bf5 100644
> --- a/libgcc/config/i386/64/t-softfp-compat
> +++ b/libgcc/config/i386/64/t-softfp-compat
> @@ -13,3 +13,11 @@ libgcc2-tf-functions = _divtc3 _multc3 _powitf2
>  LIB2FUNCS_EXCLUDE += $(libgcc2-tf-functions)
>  libgcc2-tf-compats = $(addsuffix .c, $(libgcc2-tf-functions))
>  LIB2ADD += $(addprefix $(srcdir)/config/i386/64/, $(libgcc2-tf-compats))
> +
> +# Replace _floatdisf, _floatdidf, _floatundisf and _floatundidf in
> +# libgcc2.c, which have no rounding mode support, with floattisf.c,
> +# floattidf.c, floatundisf.c and floatundidf.c from soft-fp.
> +libgcc2-ti-functions = _floatdisf _floatdidf _floatundisf _floatundidf
> +LIB2FUNCS_EXCLUDE += $(libgcc2-ti-functions)
> +libgcc2-ti-softp = floattisf.c floattidf.c floatuntisf.c floatuntidf.c
> +LIB2ADD += $(addprefix $(srcdir)/soft-fp/, $(libgcc2-ti-softp))

It is not that simple. Please note that libgcc2 functions use FP
instructions in narrower mode (so, in effect still use FPU), while
soft-fp functions don't even touch the FPU, and do everything using
bit twiddling. I think that your change would introduce qoute
noticeable runtime regressions.

Uros.

> --
> 2.20.1
>

Re: [EXT] Re: [Patch 2/4][Aarch64] v2: Implement Aarch64 SIMD ABI

[Richard Sandiford]

Tamar Christina  writes:
> Hi All,
>
> The simd-clone-7.cc tests seem to fail on big-endian with
>
> testsuite/g++.dg/vect/simd-clone-7.cc:7:1: warning: GCC does not currently 
> support mixed size types for 'simd' functions
>
> The test probably miss an effective target check?

The current condition is:

// { dg-warning "GCC does not currently support mixed size types for 'simd' 
functions" "" { target aarch64-*-* } .-4 }

That would need to be aarch64*-*-* to include big-endian.  Fixing that
here and in the other tests is OK under the obvious rule.

Adding && lp64 (as per Steve's patch below) is OK too if it works.

Thanks,
Richard

>> -Original Message-
>> From: gcc-patches-ow...@gcc.gnu.org 
>> On Behalf Of Steve Ellcey
>> Sent: Friday, January 18, 2019 17:58
>> To: christophe.l...@linaro.org
>> Cc: gcc-patches@gcc.gnu.org; Richard Sandiford
>> 
>> Subject: Re: [EXT] Re: [Patch 2/4][Aarch64] v2: Implement Aarch64 SIMD ABI
>> 
>> On Fri, 2019-01-18 at 15:35 +0100, Christophe Lyon wrote:
>> >
>> > Hi Steve,
>> >
>> > I've noticed that
>> > FAIL: g++.dg/vect/simd-clone-7.cc  -std=c++14  (test for warnings,
>> > line 7) (and for c++17 and c++98) when forcing -mabi=ilp32.
>> >
>> > I suspect you want to skip the test in this case?
>> >
>> > Christophe
>> 
>> Actually, I think we can compile that test, it just would not generate a
>> warning in ILP32 mode because int, floats and pointers would now all be the
>> same size.  So I think the fix is:
>> 
>> 
>> % git diff simd-clone-7.cc
>> diff --git a/gcc/testsuite/g++.dg/vect/simd-clone-7.cc
>> b/gcc/testsuite/g++.dg/vect/simd-clone-7.cc
>> index c2a63cd5f8e..3617f0ab6a7 100644
>> --- a/gcc/testsuite/g++.dg/vect/simd-clone-7.cc
>> +++ b/gcc/testsuite/g++.dg/vect/simd-clone-7.cc
>> @@ -8,4 +8,4 @@ bar (float x, float *y, int)  {
>>return y[0] + y[1] * x;
>>  }
>> -// { dg-warning "GCC does not currently support mixed size types for 'simd'
>> functions" "" { target aarch64-*-* } .-4 }
>> +// { dg-warning "GCC does not currently support mixed size types for
>> +'simd' functions" "" { target { { aarch64-*-* } && lp64 } } .-4 }
>> 
>> 
>> I haven't tested this, I don't have an ILP32 build sitting around right now.
>> Does it work for you?  I can build a toolchain, test it, and submit a patch 
>> if you
>> want.
>> 
>> 
>> Steve Ellcey
>> sell...@marvell.com

Re: Patch ping (Re: [wwwdocs] Add __cpp_* feature macros to C++20 entries + other changes that have those in projects/cxx_status.html)

[Jakub Jelinek]

On Mon, Jan 21, 2019 at 04:11:04PM +, Jonathan Wakely wrote:
> > I'd like to ping this patch.
> 
> For P0941R2 I think we can just say it's supported. For the library
> docs I said we support it since GCC 5.1 because that's when we started
> defining feature test macros. The point of the paper is to define
> macros for the features that are supported, and we've been doing that
> for years. If a macro is missing, it's because we don't support the
> feature yet, and that's a correct implementation of the macro!

So what about saying it is supported since e.g. 5 when __has_cpp_attribute
support has been added (or 4.9 when first __cpp_* predefined macros were
added)?  Like below.
What about the rest, ok for wwwdocs?

--- htdocs/projects/cxx-status.html.jj  2019-01-14 12:18:18.792043123 +0100
+++ htdocs/projects/cxx-status.html 2019-01-21 17:34:41.345489056 +0100
@@ -115,7 +115,7 @@
 
Range-based for statements with initializer 
   http://wg21.link/p0614r1;>P0614R1 
-   9 
+   9 

 
 
@@ -127,28 +127,28 @@
 
ADL and function templates that are not visible 
   http://wg21.link/p0846r0;>P0846R0 
-   9 
+   9 

 
 
const mismatch with defaulted copy constructor 
   http://wg21.link/p0641r2;>P0641R2 
-   9 
+   9 

 
 
Less eager instantiation of constexpr functions 
   http://wg21.link/p0859r0;>P0859R0
-   5.2 (mostly)9 (P0859R0) 
+   5.2 (mostly) 9 (P0859R0) 

 
 
Consistent comparison (operator=) 
   http://wg21.link/p0515r3;>P0515R3
-   http://wg21.link/P0905r1;>P0905R1
+   http://wg21.link/p0905r1;>P0905R1
http://wg21.link/p1120r0;>P1120R0
No 
-   
+   __cpp_impl_three_way_comparison = 201711 
 
 
Access checking on specializations 
@@ -159,19 +159,19 @@
 
Default constructible and assignable stateless lambdas 
   http://wg21.link/p0624r2;>P0624R2
-   9 
+   9 

 
 
Lambdas in unevaluated contexts 
   http://wg21.link/p0315r4;>P0315R4
-   9 
+   9 

 
 
Language support for empty objects 
   http://wg21.link/p0840r2;>P0840R2
-   9 
+   9 

 
 
@@ -195,32 +195,32 @@
 
Down with typename! 
   http://wg21.link/p0634r3;>P0634R3
-   9 
+   9 

 
 
Allow pack expansion in lambda init-capture 
   http://wg21.link/p0780r2;>P0780R2
-   9 
+   9 

 
 
Proposed wording for likely and unlikely attributes 
   http://wg21.link/p0479r5;>P0479R5
-   9 
+   9 

 
 
Deprecate implicit capture of this via [=] 
   http://wg21.link/p0806r2;>P0806R2
-   9 
+   9 

 
 
Class Types in Non-Type Template Parameters 
   http://wg21.link/p0732r2;>P0732R2
-   9 
-   
+   9 
+   __cpp_nontype_template_parameter_class = 201806 
 
 
Atomic Compare-and-Exchange with Padding Bits 
@@ -231,19 +231,19 @@
 
Efficient sized delete for variable sized classes 
   http://wg21.link/p0722r3;>P0722R3
-   9 
-   
+   9 
+   __cpp_impl_destroying_delete = 201806 
 
 
Allowing Virtual Function Calls in Constant Expressions 
   http://wg21.link/p1064r0;>P1064R0
-   9 
+   9 

 
 
Prohibit aggregates with user-declared constructors 
   http://wg21.link/p1008r1;>P1008R1
-   9 
+   9 

 
 
@@ -256,20 +256,20 @@
 
explicit(bool) 
   http://wg21.link/p0892r2;>P0892R2
-   9 
-   
+   9 
+   __cpp_conditional_explicit = 201806 
 
 
Signed integers are two's complement 
   http://wg21.link/p1236r1;>P1236R1
-   9 
+   9 

 
 
char8_t 
   http://wg21.link/p0482r6;>P0482R6
No 
-   
+   __cpp_char8_t = 201811 
 
 
Immediate functions (consteval) 
@@ -280,23 +280,30 @@
 
std::is_constant_evaluated 
   http://wg21.link/p0595r2;>P0595R2
-   9 
+   9 

 
 
Nested inline namespaces 
   http://wg21.link/p1094r2;>P1094R2
-   9 
+   9 

 
 
-   Relaxations of constexpr restrictions
+   Relaxations of constexpr restrictions 
   http://wg21.link/p1002r1;>P1002R1
   http://wg21.link/p1327r1;>P1327R1
   http://wg21.link/p1330r0;>P1330R0
No 

 
+
+   Feature test macros 
+  http://wg21.link/p0941r2;>P0941R2
+   4.9 
(__cpp_ macros) 
+5 
(__has_cpp_attribute) 
+   
+
   
 
   C++17 Support in GCC


Jakub

Re: [PATCH] Fix -Wattribute-alias option

[Martin Sebor]

On 1/21/19 8:55 AM, Bernd Edlinger wrote:



On 1/21/19 4:42 PM, Arnd Bergmann wrote:

On Sat, Jan 19, 2019 at 11:06 AM Bernd Edlinger
 wrote:


Hi,

the command line option -Wattribute-alias (w/o the "=1") is currently broken,
and only -Wno-attribute-alias is still working, but what is worse, is that
the #pragma GCC diagnostic fails to recognize the string "-Wattribute-alias",
as it used to do in gcc-8, which breaks the linux warning suppression macro
because it relies on a _Pragma to work.


I'm surprised by this, since I have not seen the warning in a while. I am
however still using gcc-8.1 locally. Did this change later during the
gcc-8 branch?



Yes.

The -Wattribute-alias was split up in -Wattribute-alias=1 an -Wattribute-alias=2
and -Wmissing-attributes on gcc-trunk (but not in the gcc-8 branch as far as I 
know).

The -Wmissing-attribute also triggers in include/linux/module.h but for that 
one,
I will probably have to send a patch to the linux-kernel list.


Miguel Ojeda has been working with me on the kernel changes.

Martin




$ svn log -r265980

r265980 | msebor | 2018-11-09 18:32:52 +0100 (Fri, 09 Nov 2018) | 39 lines

PR middle-end/81824 - Warn for missing attributes with function aliases

gcc/c-family/ChangeLog:

PR middle-end/81824
* c-attribs.c (handle_copy_attribute): New function.

gcc/cp/ChangeLog:

PR middle-end/81824
* pt.c (warn_spec_missing_attributes): Move code to attribs.c.
Call decls_mismatched_attributes.

gcc/ChangeLog:

PR middle-end/81824
* attribs.c (has_attribute): New helper function.
(decls_mismatched_attributes, maybe_diag_alias_attributes): Same.
* attribs.h (decls_mismatched_attributes): Declare.
* cgraphunit.c (handle_alias_pairs): Call maybe_diag_alias_attributes.
(maybe_diag_incompatible_alias): Use OPT_Wattribute_alias_.
* common.opt (-Wattribute-alias): Take an argument.
(-Wno-attribute-alias): New option.
* doc/extend.texi (Common Function Attributes): Document copy.
(Common Variable Attributes): Same.
* doc/invoke.texi (-Wmissing-attributes): Document enhancement.
(-Wattribute-alias): Document new option argument.

gcc/testsuite/ChangeLog:

PR middle-end/81824
* gcc.dg/Wattribute-alias.c: New test.
* gcc.dg/Wmissing-attributes.c: New test.
* gcc.dg/attr-copy.c: New test.
* gcc.dg/attr-copy-2.c: New test.
* gcc.dg/attr-copy-3.c: New test.
* gcc.dg/attr-copy-4.c: New test.



Bernd.

[PATCH] x86-64: Use TI->SF and TI->DF conversions in soft-fp

[H.J. Lu]

TI->SF and TI->DF conversions in libgcc2.c:

FSTYPE
FUNC (DWtype u)
{
  ...
}

have no rounding mode support.  We should replace __floattisf, __floattidf,
__floatuntisf and __floatuntidf in libgcc2.c with these from soft-fp.

PR libgcc/88931
* config/i386/64/t-softfp-compat (libgcc2-ti-functions): New.
(LIB2FUNCS_EXCLUDE): Likewise.
(libgcc2-ti-softp): Likewise.
(LIB2ADD): Likewise.
---
 libgcc/config/i386/64/t-softfp-compat | 8 
 1 file changed, 8 insertions(+)

diff --git a/libgcc/config/i386/64/t-softfp-compat 
b/libgcc/config/i386/64/t-softfp-compat
index 0978695c3a4..abb78032bf5 100644
--- a/libgcc/config/i386/64/t-softfp-compat
+++ b/libgcc/config/i386/64/t-softfp-compat
@@ -13,3 +13,11 @@ libgcc2-tf-functions = _divtc3 _multc3 _powitf2
 LIB2FUNCS_EXCLUDE += $(libgcc2-tf-functions)
 libgcc2-tf-compats = $(addsuffix .c, $(libgcc2-tf-functions))
 LIB2ADD += $(addprefix $(srcdir)/config/i386/64/, $(libgcc2-tf-compats))
+
+# Replace _floatdisf, _floatdidf, _floatundisf and _floatundidf in
+# libgcc2.c, which have no rounding mode support, with floattisf.c,
+# floattidf.c, floatundisf.c and floatundidf.c from soft-fp.
+libgcc2-ti-functions = _floatdisf _floatdidf _floatundisf _floatundidf
+LIB2FUNCS_EXCLUDE += $(libgcc2-ti-functions)
+libgcc2-ti-softp = floattisf.c floattidf.c floatuntisf.c floatuntidf.c
+LIB2ADD += $(addprefix $(srcdir)/soft-fp/, $(libgcc2-ti-softp))
-- 
2.20.1

Re: [PATCH]i386: Add BDESC2 for ix86_isa_flags2 and refine all related.

[Uros Bizjak]

On Mon, Jan 21, 2019 at 11:00 AM Hongtao Liu  wrote:
>
> Hi Uros,
>
> There are
>
> struct builtin_description
> {
>   const HOST_WIDE_INT mask;
>   const enum insn_code icode;
>   const char *const name;
>   const enum ix86_builtins code;
>   const enum rtx_code comparison;
>   const int flag;
> };
>
> Since "mask" is used for both ix86_isa_flags and ix86_isa_flags2,
> buitins with both flags can't be handled easily.
> This patch intends to handle this issue.
> Tested with bootstrap and regression test on x86, no problem found.
> Is it ok for trunk?

Let's go all the way and add mask2 to all builtins. While it is
understandable that by introducing BDESC2 and relevant processing
functions you were trying to minimize the patch size, I think that the
proposed patch is complicating things too much. Although the patch
that adds mask2 to each and every builtin will be big, it will be
fairly straightforward (an hopefully the change can be scripted to
some degree), and it will avoid further future complications in this
area. Other than that, builtins are covered by a bunch of very picky
testcases via intrinsics, so I'm fairly confident that the patch is
manageable, despite its size.

BR,
Uros.

> Thanks,
> Hongtao
>
> ---
> gcc/
>
> 2019-01-21  Hongtao Liu 
> H.J. Lu 
>
> PR target/88909
> * config/i386/i386-builtin.def:
> Refine builtins related to ix86_isa_flags2.
> * config/i386/i386.c (BDESC2): Define.
> (BDESC2_FIRST): Likewise.
> (BDESC2_END): Likewise.
> (builtin_description): Add new member mask2.
> (define_builtin2): Modified to handle both
> ix86_isa_flags and ix86_isa_flags2.
> (define_builtin_const2): Likewise.
> (define_builtin): Likewise.
> (bdesc_tm[]): Likewise.
> (ix86_init_mmx_sse_builtins): Likewise.
> ---

Re: Patch ping (Re: [wwwdocs] Add __cpp_* feature macros to C++20 entries + other changes that have those in projects/cxx_status.html)

[Jonathan Wakely]

On 21/01/19 14:40 +0100, Jakub Jelinek wrote:

Hi!

On Sat, Jan 12, 2019 at 02:08:15PM +0100, Jakub Jelinek wrote:

Here is an updated patch, that in addition to that makes 9 URLs as we now
have #cxx in gcc-9/changes.html and adds missing P0941R2 entry that clang
table has.  For that one I'm not 100% sure what to say, I've copied all the
macros from http://wg21.link/p0941r2 into two source files (attached below),
one for core language features, another one for library and tested those
with -std=c++2a with current trunk.  Compared to what the paper lists, we
have __has_cpp_attribute (carries_dependency) 0, __cpp_guaranteed_copy_elision
and __cpp_nontype_template_parameter_auto not defined.  Is that what we
want?  On the library side, __cpp_lib_any, __cpp_lib_execution,
__cpp_lib_hardware_interference_size, __cpp_lib_null_iterators,
__cpp_lib_parallel_algorithm, __cpp_lib_raw_memory_algorithms,
__cpp_lib_to_chars, __cpp_lib_uncaught_exceptions, __cpp_lib_variant
macros aren't defined (at least not in ) and
__cpp_lib_optional, __cpp_lib_shared_ptr_arrays, __cpp_lib_string_view
have smaller values than those in the P0941R2.
Is that the desirable state given current C++2A implementation status?

Ok for wwwdocs (or do you suggest something different for the P0941R2
imlementation status)?


I'd like to ping this patch.


For P0941R2 I think we can just say it's supported. For the library
docs I said we support it since GCC 5.1 because that's when we started
defining feature test macros. The point of the paper is to define
macros for the features that are supported, and we've been doing that
for years. If a macro is missing, it's because we don't support the
feature yet, and that's a correct implementation of the macro!

RE: [EXT] Re: [Patch 2/4][Aarch64] v2: Implement Aarch64 SIMD ABI

[Tamar Christina]

Hi All,

The simd-clone-7.cc tests seem to fail on big-endian with

testsuite/g++.dg/vect/simd-clone-7.cc:7:1: warning: GCC does not currently 
support mixed size types for 'simd' functions

The test probably miss an effective target check?

Cheers,
Tamar


> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org 
> On Behalf Of Steve Ellcey
> Sent: Friday, January 18, 2019 17:58
> To: christophe.l...@linaro.org
> Cc: gcc-patches@gcc.gnu.org; Richard Sandiford
> 
> Subject: Re: [EXT] Re: [Patch 2/4][Aarch64] v2: Implement Aarch64 SIMD ABI
> 
> On Fri, 2019-01-18 at 15:35 +0100, Christophe Lyon wrote:
> >
> > Hi Steve,
> >
> > I've noticed that
> > FAIL: g++.dg/vect/simd-clone-7.cc  -std=c++14  (test for warnings,
> > line 7) (and for c++17 and c++98) when forcing -mabi=ilp32.
> >
> > I suspect you want to skip the test in this case?
> >
> > Christophe
> 
> Actually, I think we can compile that test, it just would not generate a
> warning in ILP32 mode because int, floats and pointers would now all be the
> same size.  So I think the fix is:
> 
> 
> % git diff simd-clone-7.cc
> diff --git a/gcc/testsuite/g++.dg/vect/simd-clone-7.cc
> b/gcc/testsuite/g++.dg/vect/simd-clone-7.cc
> index c2a63cd5f8e..3617f0ab6a7 100644
> --- a/gcc/testsuite/g++.dg/vect/simd-clone-7.cc
> +++ b/gcc/testsuite/g++.dg/vect/simd-clone-7.cc
> @@ -8,4 +8,4 @@ bar (float x, float *y, int)  {
>return y[0] + y[1] * x;
>  }
> -// { dg-warning "GCC does not currently support mixed size types for 'simd'
> functions" "" { target aarch64-*-* } .-4 }
> +// { dg-warning "GCC does not currently support mixed size types for
> +'simd' functions" "" { target { { aarch64-*-* } && lp64 } } .-4 }
> 
> 
> I haven't tested this, I don't have an ILP32 build sitting around right now.
> Does it work for you?  I can build a toolchain, test it, and submit a patch 
> if you
> want.
> 
> 
> Steve Ellcey
> sell...@marvell.com

RE: [PATCH] Fix gcc.dg/utf-array.c testcase

[Tamar Christina]

Forwarding to list.

> -Original Message-
> From: Tamar Christina
> Sent: Monday, January 21, 2019 15:25
> To: 'Jakub Jelinek' ; Jason Merrill 
> Cc: gcc-patches@gcc.gnu.org
> Subject: RE: [PATCH] Fix gcc.dg/utf-array.c testcase
> 
> Hi,
> 
> These fail on aarch64*-*-* and arm*-*-* too, but this patch fixes it.
> 
> So gentle ping? 
> 
> Tamar
> 
> > -Original Message-
> > From: gcc-patches-ow...@gcc.gnu.org 
> On
> > Behalf Of Jakub Jelinek
> > Sent: Friday, January 18, 2019 23:02
> > To: Jason Merrill 
> > Cc: gcc-patches@gcc.gnu.org
> > Subject: [PATCH] Fix gcc.dg/utf-array.c testcase
> >
> > Hi!
> >
> > The utf-array.c testcase FAILs e.g. on i686-linux or powerpc-linux,
> > the problem is that wchar_t there isn't int, but long int.
> > grep shows that WCHAR_TYPE is one of
> > int
> > short int
> > long int
> > unsigned int
> > short unsigned int
> > long unsigned int
> > depending on exact target and options.
> >
> > The following patch accepts them all, ok for trunk?
> >
> > 2019-01-18  Jakub Jelinek  
> >
> > * gcc.dg/utf-array.c: Allow wchar_t to be printed as
> > {long ,short ,}{unsigned ,}int.
> >
> > --- gcc/testsuite/gcc.dg/utf-array.c.jj 2019-01-18 00:33:20.867980701 
> > +0100
> > +++ gcc/testsuite/gcc.dg/utf-array.c2019-01-18 23:32:57.086524528 
> > +0100
> > @@ -12,13 +12,13 @@ typedef __CHAR32_TYPE__ char32_t;
> >  const char s_0[]   = "ab";
> >  const char s_1[]   = u"ab";/* { dg-error "from a string literal 
> > with
> > type array of" } */
> >  const char s_2[]   = U"ab";/* { dg-error "from a string literal 
> > with
> > type array of" } */
> > -const char s_3[]   = L"ab";/* { dg-error "from a string literal 
> > with
> > type array of .int." } */
> > +const char s_3[]   = L"ab";/* { dg-error "from a string literal 
> > with
> > type array of .(long |short )?(unsigned )?int." } */
> >  const char s_4[]   = u8"ab";
> >
> >  const char16_t s16_0[] = "ab"; /* { dg-error "from a string
> literal with
> > type array of .char." } */
> >  const char16_t s16_1[] = u"ab";
> >  const char16_t s16_2[] = U"ab";/* { dg-error "from a string
> literal with
> > type array of" } */
> > -const char16_t s16_3[] = L"ab";/* { dg-error "from a string
> literal with
> > type array of .int." "" { target { ! wchar_t_char16_t_compatible } } }
> > */
> > +const char16_t s16_3[] = L"ab";/* { dg-error "from a string
> > literal with type array of .(long |short )?(unsigned )?int." "" { target { !
> > wchar_t_char16_t_compatible } } } */
> >  const char16_t s16_4[] = u8"ab";   /* { dg-error "from a string
> literal with
> > type array of .char." } */
> >
> >  const char16_t s16_5[0] = u"ab";   /* { dg-warning "chars is too
> long" }
> > */
> > @@ -30,7 +30,7 @@ const char16_ts16_9[4] = u"ab";
> >  const char32_t s32_0[] = "ab"; /* { dg-error "from a string
> literal with
> > type array of .char." } */
> >  const char32_t s32_1[] = u"ab";/* { dg-error "from a string
> literal with
> > type array of" } */
> >  const char32_t s32_2[] = U"ab";
> > -const char32_t s32_3[] = L"ab";/* { dg-error "from a string
> literal with
> > type array of .int." "" { target { ! wchar_t_char32_t_compatible } } }
> > */
> > +const char32_t s32_3[] = L"ab";/* { dg-error "from a string
> > literal with type array of .(long |short )?(unsigned )?int." "" { target { !
> > wchar_t_char32_t_compatible } } } */
> >  const char32_t s32_4[] = u8"ab";   /* { dg-error "from a string
> literal with
> > type array of .char." } */
> >
> >  const char32_t s32_5[0] = U"ab";   /* { dg-warning "chars is too
> long" }
> > */
> >
> > Jakub

[PATCH][GCC] Fix oversized shifts in PR/88903 testcase.

[Tamar Christina]

Hi All,

The testcase for PR/tree-optimization 88903 hits
undefined behavior for the overwide shifts.  This is
causing the testcases to fail for all Arm platforms.

This updates the testcase to add an explicit & such
that the behavior is consistent.

Regtested on aarch64-none-linux-gnu and no issues.

Ok for trunk?

Thanks,
Tamar

gcc/testsuite/ChangeLog:

2019-01-21  Tamar Christina  

PR/tree-optimization 88903
* gcc.dg/vect/pr88903-1.c: Add explicit &.

-- 
diff --git a/gcc/testsuite/gcc.dg/vect/pr88903-1.c b/gcc/testsuite/gcc.dg/vect/pr88903-1.c
index dead2b5e723eaff77fa1edb6ae32d12b005c680e..77dbfd47c91be8cce0edde8b09b7b90d40268306 100644
--- a/gcc/testsuite/gcc.dg/vect/pr88903-1.c
+++ b/gcc/testsuite/gcc.dg/vect/pr88903-1.c
@@ -7,8 +7,8 @@ foo()
 {
   for (int i = 0; i < 512; ++i)
 {
-  x[2*i] = x[2*i] << (i+1);
-  x[2*i+1] = x[2*i+1] << (i+1);
+  x[2*i] = x[2*i] << ((i+1) & 31);
+  x[2*i+1] = x[2*i+1] << ((i+1) & 31);
 }
 }
 
@@ -20,7 +20,7 @@ main()
 x[i] = i;
   foo ();
   for (int i = 0; i < 1024; ++i)
-if (x[i] != i << (i/2+1))
+if (x[i] != i << ((i/2+1) & 31))
   __builtin_abort ();
   return 0;
 }

Re: [PATCH] Fix -Wattribute-alias option

[Arnd Bergmann]

On Mon, Jan 21, 2019 at 4:55 PM Bernd Edlinger
 wrote:
> On 1/21/19 4:42 PM, Arnd Bergmann wrote:
> > On Sat, Jan 19, 2019 at 11:06 AM Bernd Edlinger
> >  wrote:
> >>
> >> Hi,
> >>
> >> the command line option -Wattribute-alias (w/o the "=1") is currently 
> >> broken,
> >> and only -Wno-attribute-alias is still working, but what is worse, is that
> >> the #pragma GCC diagnostic fails to recognize the string 
> >> "-Wattribute-alias",
> >> as it used to do in gcc-8, which breaks the linux warning suppression macro
> >> because it relies on a _Pragma to work.
> >
> > I'm surprised by this, since I have not seen the warning in a while. I am
> > however still using gcc-8.1 locally. Did this change later during the
> > gcc-8 branch?
> >
>
> Yes.
>
> The -Wattribute-alias was split up in -Wattribute-alias=1 an 
> -Wattribute-alias=2
> and -Wmissing-attributes on gcc-trunk (but not in the gcc-8 branch as far as 
> I know).
>
> The -Wmissing-attribute also triggers in include/linux/module.h but for that 
> one,
> I will probably have to send a patch to the linux-kernel list.

I got it, I misread your earlier message as saying that it also
happened on gcc-8.

 Arnd

Re: [PATCH] Fix -Wattribute-alias option

[Bernd Edlinger]

On 1/21/19 4:42 PM, Arnd Bergmann wrote:
> On Sat, Jan 19, 2019 at 11:06 AM Bernd Edlinger
>  wrote:
>>
>> Hi,
>>
>> the command line option -Wattribute-alias (w/o the "=1") is currently broken,
>> and only -Wno-attribute-alias is still working, but what is worse, is that
>> the #pragma GCC diagnostic fails to recognize the string "-Wattribute-alias",
>> as it used to do in gcc-8, which breaks the linux warning suppression macro
>> because it relies on a _Pragma to work.
> 
> I'm surprised by this, since I have not seen the warning in a while. I am
> however still using gcc-8.1 locally. Did this change later during the
> gcc-8 branch?
> 

Yes.

The -Wattribute-alias was split up in -Wattribute-alias=1 an -Wattribute-alias=2
and -Wmissing-attributes on gcc-trunk (but not in the gcc-8 branch as far as I 
know).

The -Wmissing-attribute also triggers in include/linux/module.h but for that 
one,
I will probably have to send a patch to the linux-kernel list.


$ svn log -r265980

r265980 | msebor | 2018-11-09 18:32:52 +0100 (Fri, 09 Nov 2018) | 39 lines

PR middle-end/81824 - Warn for missing attributes with function aliases

gcc/c-family/ChangeLog:

PR middle-end/81824
* c-attribs.c (handle_copy_attribute): New function.

gcc/cp/ChangeLog:

PR middle-end/81824
* pt.c (warn_spec_missing_attributes): Move code to attribs.c.
Call decls_mismatched_attributes.

gcc/ChangeLog:

PR middle-end/81824
* attribs.c (has_attribute): New helper function.
(decls_mismatched_attributes, maybe_diag_alias_attributes): Same.
* attribs.h (decls_mismatched_attributes): Declare.
* cgraphunit.c (handle_alias_pairs): Call maybe_diag_alias_attributes.
(maybe_diag_incompatible_alias): Use OPT_Wattribute_alias_.
* common.opt (-Wattribute-alias): Take an argument.
(-Wno-attribute-alias): New option.
* doc/extend.texi (Common Function Attributes): Document copy.
(Common Variable Attributes): Same.
* doc/invoke.texi (-Wmissing-attributes): Document enhancement.
(-Wattribute-alias): Document new option argument.

gcc/testsuite/ChangeLog:

PR middle-end/81824
* gcc.dg/Wattribute-alias.c: New test.
* gcc.dg/Wmissing-attributes.c: New test.
* gcc.dg/attr-copy.c: New test.
* gcc.dg/attr-copy-2.c: New test.
* gcc.dg/attr-copy-3.c: New test.
* gcc.dg/attr-copy-4.c: New test.



Bernd.

Re: [PATCH] Fix -Wattribute-alias option

[Arnd Bergmann]

On Sat, Jan 19, 2019 at 11:06 AM Bernd Edlinger
 wrote:
>
> Hi,
>
> the command line option -Wattribute-alias (w/o the "=1") is currently broken,
> and only -Wno-attribute-alias is still working, but what is worse, is that
> the #pragma GCC diagnostic fails to recognize the string "-Wattribute-alias",
> as it used to do in gcc-8, which breaks the linux warning suppression macro
> because it relies on a _Pragma to work.

I'm surprised by this, since I have not seen the warning in a while. I am
however still using gcc-8.1 locally. Did this change later during the
gcc-8 branch?

 Arnd

[PATCH] Fix latent SLP bugs and a memleak

[Richard Biener]

When investigating some issues I ran into two SLP op gathering issues.
*You may not ask for SLP vector def ops in the wrong order*

Both vectorizable_comparison and vectorize_fold_left_reduction fall
into this trap.

I've also fixed a memleak uncovered by valgrind that I ran on the
above fix and a testcase.  I'm too lazy to try generate a testcase
that also fails with unpatched trunk but I think this qualifies
for this stage (at least the vectorizable_comparison one should
be easy to create).

Bootstrap & regtest running on x86_64-unknown-linux-gnu.

Richard.

>From b036b1ac618d9deb0efff89051f6ba1036d84ea3 Mon Sep 17 00:00:00 2001
From: Richard Guenther 
Date: Mon, 21 Jan 2019 15:40:49 +0100
Subject: [PATCH] fix-slp-op-gatherings-and-memleak

* tree-vect-loop.c (vect_analyze_loop_operations): Use
auto_vec for cost vector to fix memleak.
(vectorize_fold_left_reduction): Properly gather SLP defs.
(vectorizable_comparison): Do not swap operands to properly
gather SLP defs.

diff --git a/gcc/tree-vect-loop.c b/gcc/tree-vect-loop.c
index 6ec8e72cd99..50d19427e54 100644
--- a/gcc/tree-vect-loop.c
+++ b/gcc/tree-vect-loop.c
@@ -1470,8 +1470,7 @@ vect_analyze_loop_operations (loop_vec_info loop_vinfo)
 
   DUMP_VECT_SCOPE ("vect_analyze_loop_operations");
 
-  stmt_vector_for_cost cost_vec;
-  cost_vec.create (2);
+  auto_vec cost_vec;
 
   for (i = 0; i < nbbs; i++)
 {
@@ -1581,7 +1580,6 @@ vect_analyze_loop_operations (loop_vec_info loop_vinfo)
 } /* bbs */
 
   add_stmt_costs (loop_vinfo->target_cost_data, _vec);
-  cost_vec.release ();
 
   /* All operations in the loop are either irrelevant (deal with loop
  control, or dead), or only used outside the loop and can be moved
@@ -5742,8 +5740,14 @@ vectorize_fold_left_reduction (stmt_vec_info stmt_info,
   auto_vec vec_oprnds0;
   if (slp_node)
 {
-  vect_get_vec_defs (op0, NULL_TREE, stmt_info, _oprnds0, NULL,
-slp_node);
+  auto_vec > vec_defs (2);
+  auto_vec sops(2);
+  sops.quick_push (ops[0]);
+  sops.quick_push (ops[1]);
+  vect_get_slp_defs (sops, slp_node, _defs);
+  vec_oprnds0.safe_splice (vec_defs[1 - reduc_index]);
+  vec_defs[0].release ();
+  vec_defs[1].release ();
   group_size = SLP_TREE_SCALAR_STMTS (slp_node).length ();
   scalar_dest_def_info = SLP_TREE_SCALAR_STMTS (slp_node)[group_size - 1];
 }
diff --git a/gcc/tree-vect-stmts.c b/gcc/tree-vect-stmts.c
index c4f645e6d7d..b93097d6a6f 100644
--- a/gcc/tree-vect-stmts.c
+++ b/gcc/tree-vect-stmts.c
@@ -9274,6 +9274,7 @@ vectorizable_comparison (stmt_vec_info stmt_info, 
gimple_stmt_iterator *gsi,
BITOP2 (rhs1 BITOP1 rhs2) or
rhs1 BITOP2 (BITOP1 rhs2)
  depending on bitop1 and bitop2 arity.  */
+  bool swap_p = false;
   if (VECTOR_BOOLEAN_TYPE_P (vectype))
 {
   if (code == GT_EXPR)
@@ -9290,15 +9291,13 @@ vectorizable_comparison (stmt_vec_info stmt_info, 
gimple_stmt_iterator *gsi,
{
  bitop1 = BIT_NOT_EXPR;
  bitop2 = BIT_AND_EXPR;
- std::swap (rhs1, rhs2);
- std::swap (dts[0], dts[1]);
+ swap_p = true;
}
   else if (code == LE_EXPR)
{
  bitop1 = BIT_NOT_EXPR;
  bitop2 = BIT_IOR_EXPR;
- std::swap (rhs1, rhs2);
- std::swap (dts[0], dts[1]);
+ swap_p = true;
}
   else
{
@@ -9365,6 +9364,8 @@ vectorizable_comparison (stmt_vec_info stmt_info, 
gimple_stmt_iterator *gsi,
  vect_get_slp_defs (ops, slp_node, _defs);
  vec_oprnds1 = vec_defs.pop ();
  vec_oprnds0 = vec_defs.pop ();
+ if (swap_p)
+   std::swap (vec_oprnds0, vec_oprnds1);
}
  else
{
@@ -9384,6 +9385,8 @@ vectorizable_comparison (stmt_vec_info stmt_info, 
gimple_stmt_iterator *gsi,
 
   if (!slp_node)
{
+ if (swap_p)
+   std::swap (vec_rhs1, vec_rhs2);
  vec_oprnds0.quick_push (vec_rhs1);
  vec_oprnds1.quick_push (vec_rhs2);
}

[PATCH] Fix PR88934

[Richard Biener]

This fixes PR88934 and makes vect_mask_constant_operand_p a little
bit more sensible by consistently looking at the first comparison
operand rather than a different one depending on whether this is
a COND_EXPR vs. a tcc_comparison one.

The first one happens to be non-constant if any is.  We'll still
fail miserably if one is invariant and the other is not.

Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.

Richard.

2019-01-21  Richard Biener  

PR tree-optimization/88934
* tree-vect-slp.c (vect_mask_constant_operand_p): Always look
at the possibly non-constant operand.
(vect_get_constant_vectors): Adjust.

* gfortran.dg/pr88934.f90: New testcase.

Index: gcc/tree-vect-slp.c
===
--- gcc/tree-vect-slp.c (revision 268110)
+++ gcc/tree-vect-slp.c (working copy)
@@ -3109,25 +3109,21 @@ vect_slp_bb (basic_block bb)
 }
 
 
-/* Return 1 if vector type of boolean constant which is OPNUM
-   operand in statement STMT_VINFO is a boolean vector.  */
+/* Return 1 if vector type STMT_VINFO is a boolean vector.  */
 
 static bool
-vect_mask_constant_operand_p (stmt_vec_info stmt_vinfo, int opnum)
+vect_mask_constant_operand_p (stmt_vec_info stmt_vinfo)
 {
   enum tree_code code = gimple_expr_code (stmt_vinfo->stmt);
   tree op, vectype;
   enum vect_def_type dt;
 
   /* For comparison and COND_EXPR type is chosen depending
- on the other comparison operand.  */
+ on the non-constant other comparison operand.  */
   if (TREE_CODE_CLASS (code) == tcc_comparison)
 {
   gassign *stmt = as_a  (stmt_vinfo->stmt);
-  if (opnum)
-   op = gimple_assign_rhs1 (stmt);
-  else
-   op = gimple_assign_rhs2 (stmt);
+  op = gimple_assign_rhs1 (stmt);
 
   if (!vect_is_simple_use (op, stmt_vinfo->vinfo, , ))
gcc_unreachable ();
@@ -3142,8 +3138,6 @@ vect_mask_constant_operand_p (stmt_vec_i
 
   if (TREE_CODE (cond) == SSA_NAME)
op = cond;
-  else if (opnum)
-   op = TREE_OPERAND (cond, 1);
   else
op = TREE_OPERAND (cond, 0);
 
@@ -3302,7 +3296,7 @@ vect_get_constant_vectors (tree op, slp_
 
   /* Check if vector type is a boolean vector.  */
   if (VECT_SCALAR_BOOLEAN_TYPE_P (TREE_TYPE (op))
-  && vect_mask_constant_operand_p (stmt_vinfo, op_num))
+  && vect_mask_constant_operand_p (stmt_vinfo))
 vector_type
   = build_same_sized_truth_vector_type (STMT_VINFO_VECTYPE (stmt_vinfo));
   else
Index: gcc/testsuite/gfortran.dg/pr88934.f90
===
--- gcc/testsuite/gfortran.dg/pr88934.f90   (nonexistent)
+++ gcc/testsuite/gfortran.dg/pr88934.f90   (working copy)
@@ -0,0 +1,23 @@
+! { dg-do compile }
+! { dg-options "-O -ftree-vectorize" }
+! { dg-additional-options "-mvsx" { target powerpc*-*-* } }
+integer, parameter :: a=3
+  integer , dimension(a,a) :: b
+  logical, dimension(a,a) :: c
+  do i=0,1
+ b = ltoi(c)
+ do j=0,if
+if (anymatmul(b) /= 0) then
+end if
+ end do
+  end do
+contains
+  elemental function ltoi(d)
+logical, intent(in) :: d
+if (d) then
+   ltoi = 1
+else
+   ltoi = 0
+end if
+  end
+end

Re: Fortran vector math header

[Joseph Myers]

On Mon, 21 Jan 2019, Martin Liška wrote:

> I like the if('lp64'), if('ilp32') approach and I'm sending patch 
> candidate for that. Would it be accepted by glibc folks?

Since glibc supports libmvec for x86_64, both 64-bit and x32, but not for 
32-bit x86, those particular conditionals are insufficient because they 
can't distinguish x32 (libmvec supported) from 32-bit x86 (libmvec not 
supported); you need some architecture-specific conditional that can be 
used in the Fortran header.

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

Re: [RS6000] PR88614, output_operand: invalid %z value

[Segher Boessenkool]

On Mon, Jan 21, 2019 at 10:48:57PM +1030, Alan Modra wrote:
> On Mon, Jan 21, 2019 at 12:08:33AM +1030, Alan Modra wrote:
> > Hmm, if I invent a couple of new unspecs, UNSPEC_TLSGD_NOMARK and
> > UNSPEC_TLSLD_NOMARK, using them in place of UNSPEC_TLSGD and
> > UNSPEC_TLSLD when !TARGET_TLS_MARKERS then that should be enough to
> > tell when we have a -mno-tls-markers __tls_get_addr call.  So I guess
> > I could kill off edit_tls_call_insn and tls_gdld_nomark.  The
> > call_value_local and call_value_indirect insns would then need to
> > detect the special call and emit the arg setup insns.
> 
> Here's what the revised approach looks like, but without using new
> unspecs.  Bootstrap and regression test on powerpc64le-linux and
> powerpc64-linux biarch completed, and testing on powerpc64le-linux
> with -mno-tls-markers.  powerpc64-linux -mno-tls-markers testing still
> in progress.  OK?

This is easier to grok, thanks.

I think this would be nicer if you still used insn alternatives here.
What is needed for that?

> +void
> +rs6000_output_tlsargs (rtx *operands)
> +{
> +  rtx op[3];

Maybe comment what this temporary is for?

The patch is okay for trunk (if it survives on at least all three linux
targets).  Thanks!


Segher

Patch ping (Re: [wwwdocs] Add __cpp_* feature macros to C++20 entries + other changes that have those in projects/cxx_status.html)

[Jakub Jelinek]

Hi!

On Sat, Jan 12, 2019 at 02:08:15PM +0100, Jakub Jelinek wrote:
> Here is an updated patch, that in addition to that makes 9 URLs as we now
> have #cxx in gcc-9/changes.html and adds missing P0941R2 entry that clang
> table has.  For that one I'm not 100% sure what to say, I've copied all the
> macros from http://wg21.link/p0941r2 into two source files (attached below),
> one for core language features, another one for library and tested those
> with -std=c++2a with current trunk.  Compared to what the paper lists, we
> have __has_cpp_attribute (carries_dependency) 0, __cpp_guaranteed_copy_elision
> and __cpp_nontype_template_parameter_auto not defined.  Is that what we
> want?  On the library side, __cpp_lib_any, __cpp_lib_execution,
> __cpp_lib_hardware_interference_size, __cpp_lib_null_iterators,
> __cpp_lib_parallel_algorithm, __cpp_lib_raw_memory_algorithms,
> __cpp_lib_to_chars, __cpp_lib_uncaught_exceptions, __cpp_lib_variant
> macros aren't defined (at least not in ) and
> __cpp_lib_optional, __cpp_lib_shared_ptr_arrays, __cpp_lib_string_view
> have smaller values than those in the P0941R2.
> Is that the desirable state given current C++2A implementation status?
> 
> Ok for wwwdocs (or do you suggest something different for the P0941R2
> imlementation status)?

I'd like to ping this patch.

Thanks.

Jakub

Re: [PATCH] PR libstdc++/88782 avoid ODR problems in std::make_shared

[Jonathan Wakely]

On 18/01/19 21:28 +, Jonathan Wakely wrote:

The old version of _Sp_counted_ptr_inplace::_M_get_deleter (up to GCC
8.2.0) expects to be passed a real std::typeinfo object, so mixing that
with the new definition of the __shared_ptr constructor (which always
passes the fake tag) leads to accessing the fake object as a real
std::typeinfo. Instead of trying to make it safe to mix the old and new
definitions, just stop using that function. By passing a reference to
__shared_ptr::_M_ptr to the __shared_count constructor it can be set
directly, without needing to obtain the pointer via the _M_get_deleter
back-channel. This avoids a virtual dispatch (which fixes PR 87514).

This means that code built against new libstdc++ headers doesn't use
_M_get_deleter at all, and so make_shared works the same whether RTTI is
enabled or not.

Also change _M_get_deleter so that it checks for a real type_info object
even when RTTI is disabled, by calling a library function. Unless
libstdc++ itself is built without RTTI that library function will be
able to test if it's the right type_info. This means the new definition
of _M_get_deleter can handle both the fake type_info tag and a real
type_info object, even if built without RTTI.

If linking to objects built against older versions of libstdc++ then if
all objects use -frtti or all use -fno-rtti, then the caller of
_M_get_deleter and the definition of _M_get_deleter will be consistent
and it will work. If mixing -frtti with -fno-rtti it can still fail if
the linker picks an old definition of _M_get_deleter and an old
__shared_ptr constructor that are incompatible. In that some or all
objects might need to be recompiled.

PR libstdc++/87514
PR libstdc++/87520
PR libstdc++/88782
* config/abi/pre/gnu.ver (GLIBCXX_3.4.26): Export new symbol.
* include/bits/shared_ptr.h
(shared_ptr(_Sp_make_shared_tag, const Alloc&, Args&&...))
(allocate_shared): Change to use new tag type.
* include/bits/shared_ptr_base.h (_Sp_make_shared_tag::_S_eq):
Declare new member function.
(_Sp_alloc_shared_tag): Define new type.
(_Sp_counted_ptr_inplace): Declare __shared_count<_Lp> as a friend.
(_Sp_counted_ptr_inplace::_M_get_deleter) [!__cpp_rtti]: Use
_Sp_make_shared_tag::_S_eq to check type_info.
(__shared_count(Ptr, Deleter),__shared_count(Ptr, Deleter, Alloc)):
Constrain to prevent being called with _Sp_alloc_shared_tag.
(__shared_count(_Sp_make_shared_tag, const _Alloc&, Args&&...)):
Replace constructor with ...
(__shared_count(Tp*&, _Sp_alloc_shared_tag<_Alloc>, Args&&...)): Use
reference parameter so address of the new object can be returned to
the caller. Obtain the allocator from the tag type.
(__shared_ptr(_Sp_make_shared_tag, const Alloc&, Args&&...)): Replace
constructor with ...
(__shared_ptr(_Sp_alloc_shared_tag, Args&&...)): Pass _M_ptr
to the __shared_count constructor.
(__allocate_shared): Change to use new tag type.
* src/c++11/shared_ptr.cc (_Sp_make_shared_tag::_S_eq): Define.

Tested powerpc64le-linux, committed to trunk.

I'll backport this to gcc-8-branch without the new symbol in the library.


Here's the backport. It's the same, except that it doesn't add the new
_Sp_make_shared_tag::_S_eq function, and so there are no changes to
_Sp_counted_ptr_inplace::_M_get_deleter. This means that -fno-rtti
instantiations of _M_get_deleter will still return null to -frtti
callers. That can be fixed by recompiling the callers with GCC 8.3 or
later (so they don't use _M_get_deleter at all), or just by relinking
so that a -frtti instantiation of _M_get_deleter is kept by the
linker. I'll document that as requested by Richi.

Tested x86_64-linux, committed to gcc-8-branch as r268114.

I've also tested the reproducers from 87520 and 88782 with every
combination of GCC 8.2.0, 8.2.1 (after r266380 but before r268114),
8.2.1 (r268114) and 9.0.0 (r268086) and only the expected cases fail
(i.e.  when both objects use 8.2.0, because obviously the fix isn't
present, or when _M_get_deleter is compiled by 8.x with -fno-rtti and
a caller is compiled by 8.2.0 with -fno-rtti, as described above).

Re: V3 [PATCH] c-family: Update unaligned adress of packed member check

[H.J. Lu]

On Mon, Jan 21, 2019 at 4:57 AM Maxim Kuvyrkov
 wrote:
>
> Hi H.J.,
>
> I've bisected compiler crash on building linux kernel for ARM down to this 
> commit.  Search for
> ==
> fs/ntfs/super.c:597:3: internal compiler error: Segmentation fault
> ==
> in 
> https://ci.linaro.org/view/tcwg_kernel-gnu/job/tcwg_kernel-build-gnu-master-arm-mainline-defconfig/285/artifact/artifacts/5-count_linux_objs/console.log/*view*/
>  .
>
> This should be trivial to reproduce, but let me know if you need assistance.

That is

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

and a patch is posted.

-- 
H.J.

Re: V3 [PATCH] c-family: Update unaligned adress of packed member check

[Maxim Kuvyrkov]

Hi H.J.,

I've bisected compiler crash on building linux kernel for ARM down to this 
commit.  Search for
==
fs/ntfs/super.c:597:3: internal compiler error: Segmentation fault
==
in 
https://ci.linaro.org/view/tcwg_kernel-gnu/job/tcwg_kernel-build-gnu-master-arm-mainline-defconfig/285/artifact/artifacts/5-count_linux_objs/console.log/*view*/
 .

This should be trivial to reproduce, but let me know if you need assistance.

Regards,

--
Maxim Kuvyrkov
www.linaro.org



> On Jan 18, 2019, at 2:10 PM, Jakub Jelinek  wrote:
> 
> On Thu, Jan 17, 2019 at 04:00:47PM -0800, H.J. Lu wrote:
>> gcc/c-family/
>> 
>>  PR c/51628
>>  PR c/88664
>>  * c-common.h (warn_for_address_or_pointer_of_packed_member):
>>  Remove the boolean argument.
>>  * c-warn.c (check_address_of_packed_member): Renamed to ...
>>  (check_address_or_pointer_of_packed_member): This.  Also
>>  warn pointer conversion.
>>  (check_and_warn_address_of_packed_member): Renamed to ...
>>  (check_and_warn_address_or_pointer_of_packed_member): This.
>>  Also warn pointer conversion.
>>  (warn_for_address_or_pointer_of_packed_member): Remove the
>>  boolean argument.  Don't check pointer conversion here.
>> 
>> gcc/c
>> 
>>  PR c/51628
>>  PR c/88664
>>  * c-typeck.c (convert_for_assignment): Upate the
>>  warn_for_address_or_pointer_of_packed_member call.
>> 
>> gcc/cp
>> 
>>  PR c/51628
>>  PR c/88664
>>  * call.c (convert_for_arg_passing): Upate the
>>  warn_for_address_or_pointer_of_packed_member call.
>>  * typeck.c (convert_for_assignment): Likewise.
>> 
>> gcc/testsuite/
>> 
>>  PR c/51628
>>  PR c/88664
>>  * c-c++-common/pr51628-33.c: New test.
>>  * c-c++-common/pr51628-35.c: New test.
>>  * c-c++-common/pr88664-1.c: Likewise.
>>  * c-c++-common/pr88664-2.c: Likewise.
>>  * gcc.dg/pr51628-34.c: Likewise.
> 
> Ok, thanks.
> 
>   Jakub

Re: [PATCH] PR libstdc++/88782 avoid ODR problems in std::make_shared

[Jonathan Wakely]

On 21/01/19 11:32 +, Jonathan Wakely wrote:

On 21/01/19 12:16 +0100, Richard Biener wrote:

On Mon, Jan 21, 2019 at 12:08 PM Jonathan Wakely  wrote:


On 21/01/19 09:13 +0100, Richard Biener wrote:

On Fri, Jan 18, 2019 at 10:29 PM Jonathan Wakely  wrote:


The old version of _Sp_counted_ptr_inplace::_M_get_deleter (up to GCC
8.2.0) expects to be passed a real std::typeinfo object, so mixing that
with the new definition of the __shared_ptr constructor (which always
passes the fake tag) leads to accessing the fake object as a real
std::typeinfo. Instead of trying to make it safe to mix the old and new
definitions, just stop using that function. By passing a reference to
__shared_ptr::_M_ptr to the __shared_count constructor it can be set
directly, without needing to obtain the pointer via the _M_get_deleter
back-channel. This avoids a virtual dispatch (which fixes PR 87514).

This means that code built against new libstdc++ headers doesn't use
_M_get_deleter at all, and so make_shared works the same whether RTTI is
enabled or not.

Also change _M_get_deleter so that it checks for a real type_info object
even when RTTI is disabled, by calling a library function. Unless
libstdc++ itself is built without RTTI that library function will be
able to test if it's the right type_info. This means the new definition
of _M_get_deleter can handle both the fake type_info tag and a real
type_info object, even if built without RTTI.

If linking to objects built against older versions of libstdc++ then if
all objects use -frtti or all use -fno-rtti, then the caller of
_M_get_deleter and the definition of _M_get_deleter will be consistent
and it will work. If mixing -frtti with -fno-rtti it can still fail if
the linker picks an old definition of _M_get_deleter and an old
__shared_ptr constructor that are incompatible. In that some or all
objects might need to be recompiled.


Can you try summarizing whatever caveats result from this in
the 8.3/9 changes.html parts?  I have a hard time extracting that
myself from the above ;)  (small example what kind of simplest code might
run into this helps)


There are *fewer* caveats compared to previous releases.

There's an example in PR 87520 showing problems mixing -frtti and
-fno-rtti code, although it's a contrived example that uses explicit
instantiation of shared_ptr internals to demonstrate the problem. The
real issue reported privately to me is harder to reproduce, and will
be even harder with this fix committed. I'll try to document this
potential problem mixing -frtti and -fno-rtti (there are still others,
e.g. PR 43105 lists one).

The problems described in PR 88782 only happen if you use 8.2.1
snapshots post-20181122 and mix code compiled by that snapshot with
code compiled by earlier releases. If you only use 8.3.0 (or 9.1.0)
and no snapshots post-20181122 then, the problem can't happen. I don't
think we need to document transient issues that only existed for two
months with snapshots.


OK, I had the impression that with the fix in there's still more cases
that have issues than before whatever rev. triggered the original issue
on the GCC 8 branch.  If that's not so then I'm fine.


Nope, this makes some problem cases work, and introduces no new
problem cases compared to 8.2.0.


Oh, I guess I should mention that mixing std::make_shared compiled
with 8.2.0 and compiled with later versions will produce a bit of code
bloat compared to using the same version for all objects. That's
because they instantiate different constructors now, so the linker
will keep both definitions, instead of discarding one. (That's how the
bug is fixed, by ensuring the new code generates different symbols
which aren't affected by the behaviour of the old symbols). But that
happens with a lot of libstdc++ fixes, and we don't usually document
it.

Re: libgo patch committed: Update to Go1.12beta2

[Matthias Klose]

On 18.01.19 20:04, Ian Lance Taylor wrote:
> I have committed a patch to update libgo to the Go 1.12beta2 release.
> 
> As usual this sort of update is too large to include all changes in
> this e-mail.  I've included changes to gccgo-specific files below.
> 
> Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu.  Committed
> to mainline.

this broke the ARM32 builds:

libtool: compile:  /<>/build/./gcc/gccgo
-B/<>/build/./gcc/ -B/usr/arm-linux-gnueabihf/bin/
-B/usr/arm-linux-gnueabihf/lib/ -isystem /usr
/arm-linux-gnueabihf/include -isystem /usr/arm-linux-gnueabihf/sys-include
-isystem /<>/build/sys-include -fchecking=1 -O2 -g -I . -c
-fgo-pkgpath=int
ernal/cpu ../../../src/libgo/go/internal/cpu/cpu.go cpugen.go  -fPIC -o
internal/.libs/cpu.o
../../../src/libgo/go/internal/cpu/cpu.go:138:2: error: reference to undefined
name 'doinit'
  138 |  doinit()
  |  ^
make[6]: *** [Makefile:2843: internal/cpu.lo] Error 1
make[6]: Leaving directory '/<>/build/arm-linux-gnueabihf/libgo'
make[5]: *** [Makefile:2241: all-recursive] Error 1



on the HURD (without any local patches):

gccgo: fatal error: no input files
compilation terminated.
Makefile:2843: recipe for target 'runtime.lo' failed
make[6]: *** [runtime.lo] Error 1
make[6]: Leaving directory '/<>/build/i686-gnu/libgo'
Makefile:2241: recipe for target 'all-recursive' failed
make[5]: *** [all-recursive] Error 1

Re: [RS6000] PR88614, output_operand: invalid %z value

[Alan Modra]

On Mon, Jan 21, 2019 at 12:08:33AM +1030, Alan Modra wrote:
> Hmm, if I invent a couple of new unspecs, UNSPEC_TLSGD_NOMARK and
> UNSPEC_TLSLD_NOMARK, using them in place of UNSPEC_TLSGD and
> UNSPEC_TLSLD when !TARGET_TLS_MARKERS then that should be enough to
> tell when we have a -mno-tls-markers __tls_get_addr call.  So I guess
> I could kill off edit_tls_call_insn and tls_gdld_nomark.  The
> call_value_local and call_value_indirect insns would then need to
> detect the special call and emit the arg setup insns.

Here's what the revised approach looks like, but without using new
unspecs.  Bootstrap and regression test on powerpc64le-linux and
powerpc64-linux biarch completed, and testing on powerpc64le-linux
with -mno-tls-markers.  powerpc64-linux -mno-tls-markers testing still
in progress.  OK?


The direct cause of this PR is the fact that tls_gdld_nomark didn't
handle indirect calls.  Also, most indirect calls were being optimised
back to direct calls anyway, due to tls_gdld_nomark not checking any
of the parallel elements except the first (plus the extra element that
distinguishes this call from normal calls).  There were other unwanted
substitutions too.

So this patch attacks the problem of handling special calls in a
different way.  Rather than adding another element to the call insn
parallel to distinguish -mno-tls-markers __tls_get_addr calls from any
other calls, we now inspect the second CALL arg.  Each
call_value_nonlocal and call_value_indirect insn now checks for the
tlsgd/ld unspecs when !TARGET_TLS_MARKERS and emits the arg setup
insns.  I disallow the local call patterns since we'll only see local
calls to __tls_get_addr in testcases, and it doesn't seem a good idea
to complicate the patterns just for a minor optimisation.  Sibling
call insns aren't used for libcalls, so none of these insns need to
change.

The patch also fixes a minor problem with -mno-tls-markers
__tls_get_addr calls causing a "li 3,0" instruction to be emitted
prior to the arg setup instructions, due to using a libcall with one
arg.  That isn't correct when the call insn itself sets up its arg.
Also, I've tidied the V4 secure-plt calls, generating them in
rs6000_call_sysv rather than by splitting in rs6000.md.  The
CALL_INSN_FUNCTION_USAGE added in edit_tls_call_insn is no longer
needed (since git commit 0a4b5c66df9).

On the subject of unwanted substitutions, I also saw a
_GLOBAL_OFFSET_TABLE_ symbol_ref being substituted for the GOT reg,
resulting in code like "addi 3,_GLOBAL_OFFSET_TABLE_,tls_ld@got@tlsld".
Fixed by the unspec_tls change.

PR 88614
* config/rs6000/predicates.md (unspec_tls): Ensure GOT reg
stays a reg.  Allow a const_int.
* config/rs6000/rs6000-protos.h (rs6000_output_tlsargs): Declare.
* config/rs6000/rs6000.h (IS_V4_FP_ARGS): Define.
(IS_NOMARK_TLSGETADDR): Define.
* config/rs6000/rs6000.c (edit_tls_call_insn): Delete.
(rs6000_output_tlsargs): New function.
(rs6000_legitimize_tls_address): Don't say a !TARGET_TLS_MARKERS
__tls_get_addr call takes an arg.
(rs6000_call_sysv): Generate sysv4 secure plt call pattern here..
* config/rs6000/rs6000.md (call_nonlocal_sysv): ..rather than here,
delete split..
(call_value_nonlocal_sysv): ..or here, delete split.
(tls_gdld_nomark): Delete.
(call_value_indirect_nonlocal_sysv): Use unspec_tls as operand2
predicate.  Call rs6000_output_tlsargs.  Adjust length to suit.
(call_value_nonlocal_sysv): Likewise.
(call_value_nonlocal_sysv_secure): Likewise.
(call_value_nonlocal_aix): Likewise.
(call_value_indirect_aix): Likewise.
(call_value_indirect_elfv2): Likewise.
(call_value_local32, call_value_local64): Disable for no-mark tls.
(call_value_local_aix): Likewise.

diff --git a/gcc/config/rs6000/predicates.md b/gcc/config/rs6000/predicates.md
index 21791c51f2f..540f45887e6 100644
--- a/gcc/config/rs6000/predicates.md
+++ b/gcc/config/rs6000/predicates.md
@@ -984,11 +984,18 @@ (define_predicate "rs6000_tls_symbol_ref"
   (and (match_code "symbol_ref")
(match_test "RS6000_SYMBOL_REF_TLS_P (op)")))
 
-;; Return 1 for the UNSPEC used in TLS call operands
+;; Return 1 for the CONST_INT or UNSPEC second CALL operand.
+;; Prevents unwanted substitution of the unspec got_reg arg.
 (define_predicate "unspec_tls"
-  (match_code "unspec")
+  (match_code "const_int,unspec")
 {
-  return XINT (op, 1) == UNSPEC_TLSGD || XINT (op, 1) == UNSPEC_TLSLD;
+  if (CONST_INT_P (op))
+return 1;
+  if (XINT (op, 1) == UNSPEC_TLSGD)
+return REG_P (XVECEXP (op, 0, 1));
+  if (XINT (op, 1) == UNSPEC_TLSLD)
+return REG_P (XVECEXP (op, 0, 0));
+  return 0;
 })
 
 ;; Return 1 if the operand, used inside a MEM, is a valid first argument
diff --git a/gcc/config/rs6000/rs6000-protos.h 
b/gcc/config/rs6000/rs6000-protos.h
index ea5c94b3ec7..9af619808ac 100644
--- 

Re: [PATCH] PR libstdc++/88782 avoid ODR problems in std::make_shared

[Jonathan Wakely]

On 21/01/19 12:16 +0100, Richard Biener wrote:

On Mon, Jan 21, 2019 at 12:08 PM Jonathan Wakely  wrote:


On 21/01/19 09:13 +0100, Richard Biener wrote:
>On Fri, Jan 18, 2019 at 10:29 PM Jonathan Wakely  wrote:
>>
>> The old version of _Sp_counted_ptr_inplace::_M_get_deleter (up to GCC
>> 8.2.0) expects to be passed a real std::typeinfo object, so mixing that
>> with the new definition of the __shared_ptr constructor (which always
>> passes the fake tag) leads to accessing the fake object as a real
>> std::typeinfo. Instead of trying to make it safe to mix the old and new
>> definitions, just stop using that function. By passing a reference to
>> __shared_ptr::_M_ptr to the __shared_count constructor it can be set
>> directly, without needing to obtain the pointer via the _M_get_deleter
>> back-channel. This avoids a virtual dispatch (which fixes PR 87514).
>>
>> This means that code built against new libstdc++ headers doesn't use
>> _M_get_deleter at all, and so make_shared works the same whether RTTI is
>> enabled or not.
>>
>> Also change _M_get_deleter so that it checks for a real type_info object
>> even when RTTI is disabled, by calling a library function. Unless
>> libstdc++ itself is built without RTTI that library function will be
>> able to test if it's the right type_info. This means the new definition
>> of _M_get_deleter can handle both the fake type_info tag and a real
>> type_info object, even if built without RTTI.
>>
>> If linking to objects built against older versions of libstdc++ then if
>> all objects use -frtti or all use -fno-rtti, then the caller of
>> _M_get_deleter and the definition of _M_get_deleter will be consistent
>> and it will work. If mixing -frtti with -fno-rtti it can still fail if
>> the linker picks an old definition of _M_get_deleter and an old
>> __shared_ptr constructor that are incompatible. In that some or all
>> objects might need to be recompiled.
>
>Can you try summarizing whatever caveats result from this in
>the 8.3/9 changes.html parts?  I have a hard time extracting that
>myself from the above ;)  (small example what kind of simplest code might
>run into this helps)

There are *fewer* caveats compared to previous releases.

There's an example in PR 87520 showing problems mixing -frtti and
-fno-rtti code, although it's a contrived example that uses explicit
instantiation of shared_ptr internals to demonstrate the problem. The
real issue reported privately to me is harder to reproduce, and will
be even harder with this fix committed. I'll try to document this
potential problem mixing -frtti and -fno-rtti (there are still others,
e.g. PR 43105 lists one).

The problems described in PR 88782 only happen if you use 8.2.1
snapshots post-20181122 and mix code compiled by that snapshot with
code compiled by earlier releases. If you only use 8.3.0 (or 9.1.0)
and no snapshots post-20181122 then, the problem can't happen. I don't
think we need to document transient issues that only existed for two
months with snapshots.


OK, I had the impression that with the fix in there's still more cases
that have issues than before whatever rev. triggered the original issue
on the GCC 8 branch.  If that's not so then I'm fine.


Nope, this makes some problem cases work, and introduces no new
problem cases compared to 8.2.0.

That's the plan, anyway. I've been wrong before :-(



I wasn't aware of any -f[no-]rtti mixing issues at all so documenting
those might still be nice.


Agreed, I'll see what I can do about that ...

incorrect parsing of -fopt-info

[Ulrich Drepper]

There is a problem with parsing the second part of the -fopt-info
command line parameter in case there is an equal sign followed by a
filename with a dash:

$ g++ -c -O -fopt-info-all=some-file u.cc
cc1plus: warning: unknown option ‘all=some’ in ‘-fopt-info-all=some-file’
cc1plus: error: unrecognized command line option ‘-fopt-info-all=some-file’

The code looks for a '-' and a '=' concurrently but does not ignore the
'-' if it is part of the filename specified after the '='.  The patch
below fixes this.  I also changed the second 'if' into 'else if' which
is clearly always the case but the current code makes it unnecessarily
cumbersome to understand.

This is a highly annoying bug in the right circumstance. I have file
names generated based in the source file name and those include in some
situations dashes.

OK for trunk?

gcc/ChangeLog
2019-01-21  Ulrich Drepper  

* dumpfile.c (opt_info_switch_p_1): Ignore '-' if it appears
after the '='.


diff --git a/gcc/dumpfile.c b/gcc/dumpfile.c
index c92bba8efd1..14b6dfea75e 100644
--- a/gcc/dumpfile.c
+++ b/gcc/dumpfile.c
@@ -1915,10 +1915,9 @@ opt_info_switch_p_1 (const char *arg, dump_flags_t 
*flags,
   end_ptr = strchr (ptr, '-');
   eq_ptr = strchr (ptr, '=');
 
-  if (eq_ptr && !end_ptr)
+  if (eq_ptr && (!end_ptr || eq_ptr < end_ptr))
 end_ptr = eq_ptr;
-
-  if (!end_ptr)
+  else if (!end_ptr)
end_ptr = ptr + strlen (ptr);
   length = end_ptr - ptr;
 


signature.asc
Description: OpenPGP digital signature

Re: [RFC] [Patch] [Debug] Add new NOTE to be used for debugging.

[Alan Hayward]

(Apologies this isn’t using the reply id)

FYI, I tried the patch below and I’m happy it fixes the GDB issue in PR 
debug/88432.

In the meantime, GDB HEAD has a workaround to disable stack protection in
the GDB testsuite, and a KFAILed test for the exact bug. See:
https://sourceware.org/ml/gdb-patches/2019-01/msg00425.html


Alan.


Re: [RFC] [Patch] [Debug] Add new FUNCTION_BEG NOTE to be used for debugging.

• From: Matthew Malcomson 
• To: "gcc-patches at gcc dot gnu dot org" 
• Cc: "jason at redhat dot com" , nd ,  "ccoutant at gmail dot com" , 
"wilson at tuliptree dot org"  , Eric Botcazou 

• Date: Fri, 18 Jan 2019 15:45:58 +
• Subject: Re: [RFC] [Patch] [Debug] Add new FUNCTION_BEG NOTE to be 
used for debugging.
• References: 


Ping.
(note -- when running the GDB testsuite ensuring that 
-fstack-protector-all is used for compiling each testcase, this patch 
fixes over 1500 FAIL's)

On 10/01/19 13:28, Matthew Malcomson wrote:
> At the moment NOTE_INSN_FUNCTION_BEG is used for three different purposes.
> The first is as a marker just before the first insn coming from a
> "source code statement" of the function.
> Bug 88432 is due to the fact that the note does not accurately point to
> this logical position in a function -- in that case the stack protect
> prologue is directly after NOTE_INSN_FUNCTION_BEG.
> 
> The second is (I believe) to make assumptions about what values are in the
> parameter passing registers (in alias.c and calls.c).
> (I'm not sure about this second use, if I am correctly reading this code then
> it seems like a bug -- e.g. asan_emit_stack_protect inserts insns in the 
> stream
> that break the assumption that seems to be made.)
> 
> The third is as a marker to determine where to put extra code later in
> sjlj_emit_function_enter from except.c, where to insert profiling code for a
> function in final.c, and where to insert variable expansion code in
> pass_expand::execute from cfgexpand.c.
> 
> These three uses seem to be at odds with each other -- insns that change the
> values in the parameter passing registers store can come from automatically
> inserted code like stack protection, and some requirements on where 
> instructions
> should get inserted have moved the position of this NOTE (e.g. see bugzilla 
> bug
> 81186).
> 
> This patch splits the current note into two different notes, one to retain 
> uses
> 2 and 3 above, and one for use in genrating debug information.
> 
> The first two uses are still attached to NOTE_INSN_FUNCTION_BEG, while the
> debugging use is now implemented with NOTE_INSN_DEBUG_FUNCTION_BEG.
> 
> These two notes are put into the functions' insn chain in different
> places during the expand pass, and can hence satisfy their respective
> uses.
> 
> Bootstrapped and regtested on aarch64.
> TODO -- Manual tests done on resulting debug information -- yet to be 
> automated.
> 
> gcc/ChangeLog:
> 
> 2019-01-10  Matthew Malcomson  
> 
>   PR debug/88432
>   * cfgexpand.c (pass_expand::execute): Insert
>   NOTE_INSN_DEBUG_FUNCTION_BEG.
>   * function.c (thread_prologue_and_epilogue_insns): Account
>   for NOTE_INSN_DEBUG_FUNCTION_BEG.
>   * cfgrtl.c (duplicate_insn_chain): Account for new NOTE.
>   * doc/rtl.texi: Document new NOTE.
>   * dwarf2out.c (dwarf2out_source_line): Change comment to
>   reference new NOTE.
>   * final.c (asm_show_source): As above.
>   (final_scan_insn_1): Split action on NOTE_INSN_FUNCTION_BEG into
>   two, and move debugging info action to trigger on
>   NOTE_INSN_DEBUG_FUNCTION_BEG.
>   * insn-notes.def (INSN_NOTE): Add new NOTE.
> 
> 
> 
> ### Attachment also inlined for ease of reply
> ###
> 
> 
> diff --git a/gcc/cfgexpand.c b/gcc/cfgexpand.c
> index 
> 60c1cfb4556e1a659db19f6719adccc1dab0fe46..491f441d01de226ba5aff2af8c71680b78648a12
>  100644
> --- a/gcc/cfgexpand.c
> +++ b/gcc/cfgexpand.c
> @@ -6476,6 +6476,12 @@ pass_expand::execute (function *fun)
> if (crtl->stack_protect_guard && targetm.stack_protect_runtime_enabled_p 
> ())
>   stack_protect_prologue ();
>   
> +  /* Insert a NOTE that marks the end of "generated code" and the start of 
> code
> + that comes from the user.  This is the point which dwarf2out.c will 
> treat
> + as the beginning of the users code in this function.  e.g. GDB will stop
> + just after this note when breaking on entry to the function.  */
> +  emit_note (NOTE_INSN_DEBUG_FUNCTION_BEG);
> +
> expand_phi_nodes ();
>   
> /* Release any stale SSA redirection data.  */
> diff --git a/gcc/cfgrtl.c b/gcc/cfgrtl.c
> index 
> 172bdf585d036e27bcf53dba89c1ffc1b6cb84c7..d0cbca84aa3f14002a568a65e70016c3e15d6b9c
>  100644
> --- a/gcc/cfgrtl.c
> +++ b/gcc/cfgrtl.c
> @@ -4215,6 +4215,7 @@ duplicate_insn_chain (rtx_insn *from, rtx_insn *to)
>   case NOTE_INSN_DELETED_DEBUG_LABEL:
> /* No problem to strip these. 

Re: [PATCH][GCC][Arm] Rewrite arm testcase to use intrinsics

[Ramana Radhakrishnan]

On 20/01/2019 15:48, Segher Boessenkool wrote:
> Hi!
> 
> On Thu, Jan 17, 2019 at 03:02:00PM +, Tamar Christina wrote:
>> This test was added back when builtins were being used instead of ACLE
>> intrinsics.  The test as far as I can tell is really testing vcombine,
>> however some of these builtins no longer exist and causes an ICE.
>>
>> This fixes the testcase by changing it to use neon intrinsics.

JFTR, I think this was a case when we were using builtins for
implementation of the ACLE intrinsics and the testcase was reduced to
remove the use of arm_neon.h . Thus the test needs to go back to using
the neon intrinsics directly if possible.

Also if there are other tests like this it would be a good small cleanup
to do.

> 
> Shouldn't the ICE be fixed as well?  [ Sorry if you send a separate patch
> for that and I missed it ].
> 

Indeed but that's a separate issue to this.

regards
Ramana
> 
> Segher
> 

Re: Implement C++20 feature P0600r1: nodiscard in the library

[Jonathan Wakely]

On 20/01/19 17:09 +0100, Ulrich Drepper wrote:

Since a previous patch introduced the _GLIBCXX_NODISCARD macro it is now
simple to implement the rest of P0600.  The parts specific to C++20 were
already added, this patch adds the attribute to the other functions.

Even though the feature specifies the nodiscard attribute only for C++20
it makes no sense to restrict its use.  Code which provokes the warning
but uses C++17 also has a problem.  I do not propose to go beyond C++17
yet.  Just as for the shared_ptr comparison patch, let's first see how
things go and then we can extend the attribute to previous revisions.

If a code base is compiled with multiple compilers chances are that no
problem will be flagged.  Other library implementations are much more
aggressive with the use of this flag.  In the gcc code base on one test
case was flagged and that code sequence obviously should never appear in
real code (allocate and discard the result).

The test suite shows no additional errors and given that only the
functions mentioned in the feature (allocate, empty, new, async) are
changed I think this is a patch which can be applied to the trunk.  It
can catch real mistakes.

OK?


OK, thanks.

Re: [PATCH] Use __builtin_is_constant_evaluated some more (PR libstdc++/86590)

[Jonathan Wakely]

On 19/01/19 23:56 +0100, Jakub Jelinek wrote:

Hi!

The following patch uses __builtin_is_constant_evaluated for
__constant_string_p and __constant_char_array_p - in constexpr contexts,
all the strings or arrays should be constant, and by doing it this way the
compiler should be able to optimize better the callers of these inline
functions already shortly after early inlining rather than having to wait
until fold builtins pass much later.

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


OK, thanks.

Re: [PATCH] PR libstdc++/88782 avoid ODR problems in std::make_shared

[Richard Biener]

On Mon, Jan 21, 2019 at 12:08 PM Jonathan Wakely  wrote:
>
> On 21/01/19 09:13 +0100, Richard Biener wrote:
> >On Fri, Jan 18, 2019 at 10:29 PM Jonathan Wakely  wrote:
> >>
> >> The old version of _Sp_counted_ptr_inplace::_M_get_deleter (up to GCC
> >> 8.2.0) expects to be passed a real std::typeinfo object, so mixing that
> >> with the new definition of the __shared_ptr constructor (which always
> >> passes the fake tag) leads to accessing the fake object as a real
> >> std::typeinfo. Instead of trying to make it safe to mix the old and new
> >> definitions, just stop using that function. By passing a reference to
> >> __shared_ptr::_M_ptr to the __shared_count constructor it can be set
> >> directly, without needing to obtain the pointer via the _M_get_deleter
> >> back-channel. This avoids a virtual dispatch (which fixes PR 87514).
> >>
> >> This means that code built against new libstdc++ headers doesn't use
> >> _M_get_deleter at all, and so make_shared works the same whether RTTI is
> >> enabled or not.
> >>
> >> Also change _M_get_deleter so that it checks for a real type_info object
> >> even when RTTI is disabled, by calling a library function. Unless
> >> libstdc++ itself is built without RTTI that library function will be
> >> able to test if it's the right type_info. This means the new definition
> >> of _M_get_deleter can handle both the fake type_info tag and a real
> >> type_info object, even if built without RTTI.
> >>
> >> If linking to objects built against older versions of libstdc++ then if
> >> all objects use -frtti or all use -fno-rtti, then the caller of
> >> _M_get_deleter and the definition of _M_get_deleter will be consistent
> >> and it will work. If mixing -frtti with -fno-rtti it can still fail if
> >> the linker picks an old definition of _M_get_deleter and an old
> >> __shared_ptr constructor that are incompatible. In that some or all
> >> objects might need to be recompiled.
> >
> >Can you try summarizing whatever caveats result from this in
> >the 8.3/9 changes.html parts?  I have a hard time extracting that
> >myself from the above ;)  (small example what kind of simplest code might
> >run into this helps)
>
> There are *fewer* caveats compared to previous releases.
>
> There's an example in PR 87520 showing problems mixing -frtti and
> -fno-rtti code, although it's a contrived example that uses explicit
> instantiation of shared_ptr internals to demonstrate the problem. The
> real issue reported privately to me is harder to reproduce, and will
> be even harder with this fix committed. I'll try to document this
> potential problem mixing -frtti and -fno-rtti (there are still others,
> e.g. PR 43105 lists one).
>
> The problems described in PR 88782 only happen if you use 8.2.1
> snapshots post-20181122 and mix code compiled by that snapshot with
> code compiled by earlier releases. If you only use 8.3.0 (or 9.1.0)
> and no snapshots post-20181122 then, the problem can't happen. I don't
> think we need to document transient issues that only existed for two
> months with snapshots.

OK, I had the impression that with the fix in there's still more cases
that have issues than before whatever rev. triggered the original issue
on the GCC 8 branch.  If that's not so then I'm fine.

I wasn't aware of any -f[no-]rtti mixing issues at all so documenting
those might still be nice.

Richard.

> >Richard.
> >
> >> PR libstdc++/87514
> >> PR libstdc++/87520
> >> PR libstdc++/88782
> >> * config/abi/pre/gnu.ver (GLIBCXX_3.4.26): Export new symbol.
> >> * include/bits/shared_ptr.h
> >> (shared_ptr(_Sp_make_shared_tag, const Alloc&, Args&&...))
> >> (allocate_shared): Change to use new tag type.
> >> * include/bits/shared_ptr_base.h (_Sp_make_shared_tag::_S_eq):
> >> Declare new member function.
> >> (_Sp_alloc_shared_tag): Define new type.
> >> (_Sp_counted_ptr_inplace): Declare __shared_count<_Lp> as a friend.
> >> (_Sp_counted_ptr_inplace::_M_get_deleter) [!__cpp_rtti]: Use
> >> _Sp_make_shared_tag::_S_eq to check type_info.
> >> (__shared_count(Ptr, Deleter),__shared_count(Ptr, Deleter, Alloc)):
> >> Constrain to prevent being called with _Sp_alloc_shared_tag.
> >> (__shared_count(_Sp_make_shared_tag, const _Alloc&, Args&&...)):
> >> Replace constructor with ...
> >> (__shared_count(Tp*&, _Sp_alloc_shared_tag<_Alloc>, Args&&...)): 
> >> Use
> >> reference parameter so address of the new object can be returned to
> >> the caller. Obtain the allocator from the tag type.
> >> (__shared_ptr(_Sp_make_shared_tag, const Alloc&, Args&&...)): 
> >> Replace
> >> constructor with ...
> >> (__shared_ptr(_Sp_alloc_shared_tag, Args&&...)): Pass _M_ptr
> >> to the __shared_count constructor.
> >> (__allocate_shared): Change to use new tag type.
> >> * src/c++11/shared_ptr.cc 

Re: [PATCH] doc: showcase a "union of vectors" pattern (PR 88698)

[Richard Biener]

On Mon, Jan 21, 2019 at 10:14 AM Alexander Monakov  wrote:
>
> On Mon, 21 Jan 2019, Richard Biener wrote:
>
> > I'm not sure whether it's permitted to use this in C++ or not (and whether
> > the C usage is now officially sanctioned other than via a non-normative
> > footnote) - but at least GCC will guarantee that it works.
>
> My impression is that, via the "active member" wording, C++ standard says
> clearly this is UB.  I assume on the GCC side the intention is to treat it
> like in C (for POD types only?..), but I don't want to go there in the
> "Vector Extensions" section.  Hence my patch limits the suggestion to C.
>
> I think in C++ it's a bit less of an issue anyway, because people can use
> operator overloading to achieve a similar end result, with some extra legwork.
>
> Do you want me to change the text somehow?

No, it was just a note from my side.

> > Might be interesting to show how to do argument marshalling with the
> > same union.
>
> Sorry, I don't see what you mean here; can you give an example or elaborate?

when you call a function with v4si signature but want to pass it a result
from a __mm intrinsic you'd need a temporary union to do the marshalling.
I think you can use a union argument in the function itself and you can
elide the temporary then if you use transparent_union.  But I didn't try.

Richard.

> Thanks!
> Alexander

Re: [PATCH] PR libstdc++/88782 avoid ODR problems in std::make_shared

[Jonathan Wakely]

On 21/01/19 09:13 +0100, Richard Biener wrote:

On Fri, Jan 18, 2019 at 10:29 PM Jonathan Wakely  wrote:


The old version of _Sp_counted_ptr_inplace::_M_get_deleter (up to GCC
8.2.0) expects to be passed a real std::typeinfo object, so mixing that
with the new definition of the __shared_ptr constructor (which always
passes the fake tag) leads to accessing the fake object as a real
std::typeinfo. Instead of trying to make it safe to mix the old and new
definitions, just stop using that function. By passing a reference to
__shared_ptr::_M_ptr to the __shared_count constructor it can be set
directly, without needing to obtain the pointer via the _M_get_deleter
back-channel. This avoids a virtual dispatch (which fixes PR 87514).

This means that code built against new libstdc++ headers doesn't use
_M_get_deleter at all, and so make_shared works the same whether RTTI is
enabled or not.

Also change _M_get_deleter so that it checks for a real type_info object
even when RTTI is disabled, by calling a library function. Unless
libstdc++ itself is built without RTTI that library function will be
able to test if it's the right type_info. This means the new definition
of _M_get_deleter can handle both the fake type_info tag and a real
type_info object, even if built without RTTI.

If linking to objects built against older versions of libstdc++ then if
all objects use -frtti or all use -fno-rtti, then the caller of
_M_get_deleter and the definition of _M_get_deleter will be consistent
and it will work. If mixing -frtti with -fno-rtti it can still fail if
the linker picks an old definition of _M_get_deleter and an old
__shared_ptr constructor that are incompatible. In that some or all
objects might need to be recompiled.


Can you try summarizing whatever caveats result from this in
the 8.3/9 changes.html parts?  I have a hard time extracting that
myself from the above ;)  (small example what kind of simplest code might
run into this helps)


There are *fewer* caveats compared to previous releases.

There's an example in PR 87520 showing problems mixing -frtti and
-fno-rtti code, although it's a contrived example that uses explicit
instantiation of shared_ptr internals to demonstrate the problem. The
real issue reported privately to me is harder to reproduce, and will
be even harder with this fix committed. I'll try to document this
potential problem mixing -frtti and -fno-rtti (there are still others,
e.g. PR 43105 lists one).

The problems described in PR 88782 only happen if you use 8.2.1
snapshots post-20181122 and mix code compiled by that snapshot with
code compiled by earlier releases. If you only use 8.3.0 (or 9.1.0)
and no snapshots post-20181122 then, the problem can't happen. I don't
think we need to document transient issues that only existed for two
months with snapshots.


Richard.


PR libstdc++/87514
PR libstdc++/87520
PR libstdc++/88782
* config/abi/pre/gnu.ver (GLIBCXX_3.4.26): Export new symbol.
* include/bits/shared_ptr.h
(shared_ptr(_Sp_make_shared_tag, const Alloc&, Args&&...))
(allocate_shared): Change to use new tag type.
* include/bits/shared_ptr_base.h (_Sp_make_shared_tag::_S_eq):
Declare new member function.
(_Sp_alloc_shared_tag): Define new type.
(_Sp_counted_ptr_inplace): Declare __shared_count<_Lp> as a friend.
(_Sp_counted_ptr_inplace::_M_get_deleter) [!__cpp_rtti]: Use
_Sp_make_shared_tag::_S_eq to check type_info.
(__shared_count(Ptr, Deleter),__shared_count(Ptr, Deleter, Alloc)):
Constrain to prevent being called with _Sp_alloc_shared_tag.
(__shared_count(_Sp_make_shared_tag, const _Alloc&, Args&&...)):
Replace constructor with ...
(__shared_count(Tp*&, _Sp_alloc_shared_tag<_Alloc>, Args&&...)): Use
reference parameter so address of the new object can be returned to
the caller. Obtain the allocator from the tag type.
(__shared_ptr(_Sp_make_shared_tag, const Alloc&, Args&&...)): Replace
constructor with ...
(__shared_ptr(_Sp_alloc_shared_tag, Args&&...)): Pass _M_ptr
to the __shared_count constructor.
(__allocate_shared): Change to use new tag type.
* src/c++11/shared_ptr.cc (_Sp_make_shared_tag::_S_eq): Define.

Tested powerpc64le-linux, committed to trunk.

I'll backport this to gcc-8-branch without the new symbol in the library.

[PATCH]i386: Add BDESC2 for ix86_isa_flags2 and refine all related.

[Hongtao Liu]

Hi Uros,

There are

struct builtin_description
{
  const HOST_WIDE_INT mask;
  const enum insn_code icode;
  const char *const name;
  const enum ix86_builtins code;
  const enum rtx_code comparison;
  const int flag;
};

Since "mask" is used for both ix86_isa_flags and ix86_isa_flags2,
buitins with both flags can't be handled easily.
This patch intends to handle this issue.
Tested with bootstrap and regression test on x86, no problem found.
Is it ok for trunk?

Thanks,
Hongtao

---
gcc/

2019-01-21  Hongtao Liu 
H.J. Lu 

PR target/88909
* config/i386/i386-builtin.def:
Refine builtins related to ix86_isa_flags2.
* config/i386/i386.c (BDESC2): Define.
(BDESC2_FIRST): Likewise.
(BDESC2_END): Likewise.
(builtin_description): Add new member mask2.
(define_builtin2): Modified to handle both
ix86_isa_flags and ix86_isa_flags2.
(define_builtin_const2): Likewise.
(define_builtin): Likewise.
(bdesc_tm[]): Likewise.
(ix86_init_mmx_sse_builtins): Likewise.
---
From 766f42d921c5e33e6bf786908dbd701677b159b7 Mon Sep 17 00:00:00 2001
From: "Liu, Hongtao" 
Date: Thu, 17 Jan 2019 18:01:07 -0800
Subject: [PATCH] Add BDESC2 for ix86_isa_flags2 and refine all related.

gcc/

2019-01-21  Hongtao Liu 
	H.J. Lu	

	PR target/88909
	* config/i386/i386-builtin.def:
	Refine builtins related to ix86_isa_flags2.
	* config/i386/i386.c (BDESC2): Define.
	(BDESC2_FIRST): Likewise.
	(BDESC2_END): Likewise.
	(builtin_description): Add new member mask2.
	(define_builtin2): Modified to handle both
	ix86_isa_flags and ix86_isa_flags2.
	(define_builtin_const2): Likewise.
	(define_builtin): Likewise.
	(bdesc_tm[]): Likewise.
	(ix86_init_mmx_sse_builtins): Likewise.
---
 gcc/config/i386/i386-builtin.def |  70 +--
 gcc/config/i386/i386.c   | 193 ---
 2 files changed, 132 insertions(+), 131 deletions(-)

diff --git a/gcc/config/i386/i386-builtin.def b/gcc/config/i386/i386-builtin.def
index 42959ced4dd..d77272771c3 100644
--- a/gcc/config/i386/i386-builtin.def
+++ b/gcc/config/i386/i386-builtin.def
@@ -2842,48 +2842,48 @@ BDESC (OPTION_MASK_ISA_AVX512DQ, CODE_FOR_avx512dq_rangepv8df_mask_round, "__bui
 BDESC_END (ROUND_ARGS, ARGS2)
 
 /* AVX512_4FMAPS and AVX512_4VNNIW builtins with variable number of arguments. Defined in additional ix86_isa_flags2.  */
-BDESC_FIRST (args2, ARGS2,
-   OPTION_MASK_ISA_AVX5124FMAPS, CODE_FOR_avx5124fmaddps_4fmaddps_mask, "__builtin_ia32_4fmaddps_mask", IX86_BUILTIN_4FMAPS_MASK, UNKNOWN, (int) V16SF_FTYPE_V16SF_V16SF_V16SF_V16SF_V16SF_PCV4SF_V16SF_UHI)
-BDESC (OPTION_MASK_ISA_AVX5124FMAPS, CODE_FOR_avx5124fmaddps_4fmaddps, "__builtin_ia32_4fmaddps", IX86_BUILTIN_4FMAPS, UNKNOWN, (int) V16SF_FTYPE_V16SF_V16SF_V16SF_V16SF_V16SF_PCV4SF)
-BDESC (OPTION_MASK_ISA_AVX5124FMAPS, CODE_FOR_avx5124fmaddps_4fmaddss, "__builtin_ia32_4fmaddss", IX86_BUILTIN_4FMASS, UNKNOWN, (int) V4SF_FTYPE_V4SF_V4SF_V4SF_V4SF_V4SF_PCV4SF)
-BDESC (OPTION_MASK_ISA_AVX5124FMAPS, CODE_FOR_avx5124fmaddps_4fmaddss_mask, "__builtin_ia32_4fmaddss_mask", IX86_BUILTIN_4FMASS_MASK, UNKNOWN, (int) V4SF_FTYPE_V4SF_V4SF_V4SF_V4SF_V4SF_PCV4SF_V4SF_UQI)
-BDESC (OPTION_MASK_ISA_AVX5124FMAPS, CODE_FOR_avx5124fmaddps_4fnmaddps_mask, "__builtin_ia32_4fnmaddps_mask", IX86_BUILTIN_4FNMAPS_MASK, UNKNOWN, (int) V16SF_FTYPE_V16SF_V16SF_V16SF_V16SF_V16SF_PCV4SF_V16SF_UHI)
-BDESC (OPTION_MASK_ISA_AVX5124FMAPS, CODE_FOR_avx5124fmaddps_4fnmaddps, "__builtin_ia32_4fnmaddps", IX86_BUILTIN_4FNMAPS, UNKNOWN, (int) V16SF_FTYPE_V16SF_V16SF_V16SF_V16SF_V16SF_PCV4SF)
-BDESC (OPTION_MASK_ISA_AVX5124FMAPS, CODE_FOR_avx5124fmaddps_4fnmaddss, "__builtin_ia32_4fnmaddss", IX86_BUILTIN_4FNMASS, UNKNOWN, (int) V4SF_FTYPE_V4SF_V4SF_V4SF_V4SF_V4SF_PCV4SF)
-BDESC (OPTION_MASK_ISA_AVX5124FMAPS, CODE_FOR_avx5124fmaddps_4fnmaddss_mask, "__builtin_ia32_4fnmaddss_mask", IX86_BUILTIN_4FNMASS_MASK, UNKNOWN, (int) V4SF_FTYPE_V4SF_V4SF_V4SF_V4SF_V4SF_PCV4SF_V4SF_UQI)
-BDESC (OPTION_MASK_ISA_AVX5124VNNIW, CODE_FOR_avx5124vnniw_vp4dpwssd, "__builtin_ia32_vp4dpwssd", IX86_BUILTIN_4DPWSSD, UNKNOWN, (int) V16SI_FTYPE_V16SI_V16SI_V16SI_V16SI_V16SI_PCV4SI)
-BDESC (OPTION_MASK_ISA_AVX5124VNNIW, CODE_FOR_avx5124vnniw_vp4dpwssd_mask, "__builtin_ia32_vp4dpwssd_mask", IX86_BUILTIN_4DPWSSD_MASK, UNKNOWN, (int) V16SI_FTYPE_V16SI_V16SI_V16SI_V16SI_V16SI_PCV4SI_V16SI_UHI)
-BDESC (OPTION_MASK_ISA_AVX5124VNNIW, CODE_FOR_avx5124vnniw_vp4dpwssds, "__builtin_ia32_vp4dpwssds", IX86_BUILTIN_4DPWSSDS, UNKNOWN, (int) V16SI_FTYPE_V16SI_V16SI_V16SI_V16SI_V16SI_PCV4SI)
-BDESC (OPTION_MASK_ISA_AVX5124VNNIW, CODE_FOR_avx5124vnniw_vp4dpwssds_mask, "__builtin_ia32_vp4dpwssds_mask", IX86_BUILTIN_4DPWSSDS_MASK, UNKNOWN, (int) V16SI_FTYPE_V16SI_V16SI_V16SI_V16SI_V16SI_PCV4SI_V16SI_UHI)
+BDESC2_FIRST (args2, ARGS2,
+0, OPTION_MASK_ISA_AVX5124FMAPS, CODE_FOR_avx5124fmaddps_4fmaddps_mask, "__builtin_ia32_4fmaddps_mask", IX86_BUILTIN_4FMAPS_MASK, UNKNOWN, (int) V16SF_FTYPE_V16SF_V16SF_V16SF_V16SF_V16SF_PCV4SF_V16SF_UHI)
+BDESC2 (0, OPTION_MASK_ISA_AVX5124FMAPS, 

Re: Fortran vector math header

[Jakub Jelinek]

On Mon, Jan 21, 2019 at 10:36:20AM +0100, Martin Liška wrote:
> @@ -11338,7 +11339,7 @@ gfc_match_gcc_unroll (void)
>return MATCH_ERROR;
>  }
>  
> -/* Match a !GCC$ builtin (b) attributes simd flags form:
> +/* Match a !GCC$ builtin (b) attributes simd if(target) flags form:
>  
> The parameter b is name of a middle-end built-in.
> Flags are one of:
> @@ -11346,11 +11347,16 @@ gfc_match_gcc_unroll (void)
>   - inbranch
>   - notinbranch
>  
> +   Target must be one of:
> + - lp64
> + - ilp32
> +

Not exactly correct.  if(target) is optional, not mandatory, and, if it
appears, must appear after flags.  flags is also incorrect, because it is
either nothing, or (inbranch), or (notinbranch), while the function comment
suggests that it is inbranch or notinbranch.

Jakub

Re: Fortran vector math header

[Martin Liška]

On 1/21/19 10:19 AM, Jakub Jelinek wrote:
> On Mon, Jan 21, 2019 at 10:09:01AM +0100, Martin Liška wrote:
>> @@ -11351,6 +11352,7 @@ match
>>  gfc_match_gcc_builtin (void)
>>  {
>>char builtin[GFC_MAX_SYMBOL_LEN + 1];
>> +  char target[GFC_MAX_SYMBOL_LEN + 1];
>>  
>>if (gfc_match (" ( %n ) attributes simd", builtin) != MATCH_YES)
>>  return MATCH_ERROR;
>> @@ -11361,6 +11363,26 @@ gfc_match_gcc_builtin (void)
>>else if (gfc_match (" ( inbranch ) ") == MATCH_YES)
>>  clause = SIMD_INBRANCH;
>>  
>> +  if (gfc_match (" if ( %n ) ", target) == MATCH_YES)
>> +{
>> +  if (strcmp (target, "lp64") == 0)
>> +{
>> +  if (TYPE_PRECISION (long_integer_type_node) != 64
>> +  || POINTER_SIZE != 64
>> +  || TYPE_PRECISION (integer_type_node) != 32)
>> +return MATCH_YES;
>> +}
>> +  else if (strcmp (target, "ilp32") == 0)
>> +{
>> +  if (TYPE_PRECISION (long_integer_type_node) != 32
>> +  || POINTER_SIZE != 32
>> +  || TYPE_PRECISION (integer_type_node) != 32)
>> +return MATCH_YES;
>> +}
>> +  else
>> +return MATCH_ERROR;
>> +}
> 
> You should adjust the syntax above the function too.
> And you need here buy-in from glibc folks.
>> +
>>if (gfc_vectorized_builtins == NULL)
>>  gfc_vectorized_builtins = new hash_map ();
>>  
>> diff --git a/gcc/testsuite/gfortran.dg/simd-builtins-7.f90 
>> b/gcc/testsuite/gfortran.dg/simd-builtins-7.f90
>> new file mode 100644
>> index 000..6445733d288
>> --- /dev/null
>> +++ b/gcc/testsuite/gfortran.dg/simd-builtins-7.f90
>> @@ -0,0 +1,21 @@
>> +! { dg-do compile { target { i?86-*-linux* x86_64-*-linux* } } }
>> +! { dg-additional-options "-msse2 -mno-avx -nostdinc -Ofast 
>> -fpre-include=simd-builtins-7.h -fdump-tree-optimized" }
>> +
>> +program test_overloaded_intrinsic
>> +  real(4) :: x4(3200), y4(3200)
>> +  real(8) :: x8(3200), y8(3200)
>> +
>> +  ! this should be using simd clone
>> +  y4 = sin(x4)
>> +  print *, y4
>> +
>> +  ! this should not be using simd clone
> 
> The above 2 comments are misleading, they only match what ia32 does.
> 
>> +  y4 = sin(x8)
>> +  print *, y8
>> +end
>> +
>> +! { dg-final { scan-tree-dump "sinf.simdclone" "optimized" { target ia32 } 
>> } } */
>> +! { dg-final { scan-tree-dump-not "sin.simdclone" "optimized" { target ia32 
>> } } } */
> 
> Perhaps use ilp32 instead of ia32?
> 
>   Jakub
> 

Thanks for review, I'm attaching updated patch.

Martin
>From f8901f176f7832591dd9702da681859b9f3ddf38 Mon Sep 17 00:00:00 2001
From: marxin 
Date: Mon, 21 Jan 2019 08:46:06 +0100
Subject: [PATCH] Support if statement in !GCC$ builtin directive.

gcc/fortran/ChangeLog:

2019-01-21  Martin Liska  

	* decl.c (gfc_match_gcc_builtin): Support filtering for
	'lp64' and 'ilp32'.

gcc/testsuite/ChangeLog:

2019-01-21  Martin Liska  

	* gfortran.dg/simd-builtins-7.f90: New test.
	* gfortran.dg/simd-builtins-7.h: New test.
---
 gcc/fortran/decl.c| 28 ++-
 gcc/testsuite/gfortran.dg/simd-builtins-7.f90 | 19 +
 gcc/testsuite/gfortran.dg/simd-builtins-7.h   |  2 ++
 3 files changed, 48 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gfortran.dg/simd-builtins-7.f90
 create mode 100644 gcc/testsuite/gfortran.dg/simd-builtins-7.h

diff --git a/gcc/fortran/decl.c b/gcc/fortran/decl.c
index 3314e176881..3e2e9adcb4a 100644
--- a/gcc/fortran/decl.c
+++ b/gcc/fortran/decl.c
@@ -28,6 +28,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "match.h"
 #include "parse.h"
 #include "constructor.h"
+#include "target.h"
 
 /* Macros to access allocate memory for gfc_data_variable,
gfc_data_value and gfc_data.  */
@@ -11338,7 +11339,7 @@ gfc_match_gcc_unroll (void)
   return MATCH_ERROR;
 }
 
-/* Match a !GCC$ builtin (b) attributes simd flags form:
+/* Match a !GCC$ builtin (b) attributes simd if(target) flags form:
 
The parameter b is name of a middle-end built-in.
Flags are one of:
@@ -11346,11 +11347,16 @@ gfc_match_gcc_unroll (void)
  - inbranch
  - notinbranch
 
+   Target must be one of:
+ - lp64
+ - ilp32
+
When we come here, we have already matched the !GCC$ builtin string.  */
 match
 gfc_match_gcc_builtin (void)
 {
   char builtin[GFC_MAX_SYMBOL_LEN + 1];
+  char target[GFC_MAX_SYMBOL_LEN + 1];
 
   if (gfc_match (" ( %n ) attributes simd", builtin) != MATCH_YES)
 return MATCH_ERROR;
@@ -11361,6 +11367,26 @@ gfc_match_gcc_builtin (void)
   else if (gfc_match (" ( inbranch ) ") == MATCH_YES)
 clause = SIMD_INBRANCH;
 
+  if (gfc_match (" if ( %n ) ", target) == MATCH_YES)
+{
+  if (strcmp (target, "lp64") == 0)
+	{
+	  if (TYPE_PRECISION (long_integer_type_node) != 64
+	  || POINTER_SIZE != 64
+	  || TYPE_PRECISION (integer_type_node) != 32)
+	return MATCH_YES;
+	}
+  else if (strcmp (target, "ilp32") == 0)
+	{
+	  if (TYPE_PRECISION (long_integer_type_node) != 32
+	  || POINTER_SIZE != 32

Re: Fortran vector math header

[Jakub Jelinek]

On Mon, Jan 21, 2019 at 10:09:01AM +0100, Martin Liška wrote:
> @@ -11351,6 +11352,7 @@ match
>  gfc_match_gcc_builtin (void)
>  {
>char builtin[GFC_MAX_SYMBOL_LEN + 1];
> +  char target[GFC_MAX_SYMBOL_LEN + 1];
>  
>if (gfc_match (" ( %n ) attributes simd", builtin) != MATCH_YES)
>  return MATCH_ERROR;
> @@ -11361,6 +11363,26 @@ gfc_match_gcc_builtin (void)
>else if (gfc_match (" ( inbranch ) ") == MATCH_YES)
>  clause = SIMD_INBRANCH;
>  
> +  if (gfc_match (" if ( %n ) ", target) == MATCH_YES)
> +{
> +  if (strcmp (target, "lp64") == 0)
> + {
> +   if (TYPE_PRECISION (long_integer_type_node) != 64
> +   || POINTER_SIZE != 64
> +   || TYPE_PRECISION (integer_type_node) != 32)
> + return MATCH_YES;
> + }
> +  else if (strcmp (target, "ilp32") == 0)
> + {
> +   if (TYPE_PRECISION (long_integer_type_node) != 32
> +   || POINTER_SIZE != 32
> +   || TYPE_PRECISION (integer_type_node) != 32)
> + return MATCH_YES;
> + }
> +  else
> + return MATCH_ERROR;
> +}

You should adjust the syntax above the function too.
And you need here buy-in from glibc folks.
> +
>if (gfc_vectorized_builtins == NULL)
>  gfc_vectorized_builtins = new hash_map ();
>  
> diff --git a/gcc/testsuite/gfortran.dg/simd-builtins-7.f90 
> b/gcc/testsuite/gfortran.dg/simd-builtins-7.f90
> new file mode 100644
> index 000..6445733d288
> --- /dev/null
> +++ b/gcc/testsuite/gfortran.dg/simd-builtins-7.f90
> @@ -0,0 +1,21 @@
> +! { dg-do compile { target { i?86-*-linux* x86_64-*-linux* } } }
> +! { dg-additional-options "-msse2 -mno-avx -nostdinc -Ofast 
> -fpre-include=simd-builtins-7.h -fdump-tree-optimized" }
> +
> +program test_overloaded_intrinsic
> +  real(4) :: x4(3200), y4(3200)
> +  real(8) :: x8(3200), y8(3200)
> +
> +  ! this should be using simd clone
> +  y4 = sin(x4)
> +  print *, y4
> +
> +  ! this should not be using simd clone

The above 2 comments are misleading, they only match what ia32 does.

> +  y4 = sin(x8)
> +  print *, y8
> +end
> +
> +! { dg-final { scan-tree-dump "sinf.simdclone" "optimized" { target ia32 } } 
> } */
> +! { dg-final { scan-tree-dump-not "sin.simdclone" "optimized" { target ia32 
> } } } */

Perhaps use ilp32 instead of ia32?

Jakub

Re: [PATCH] doc: showcase a "union of vectors" pattern (PR 88698)

[Alexander Monakov]

On Mon, 21 Jan 2019, Richard Biener wrote:

> I'm not sure whether it's permitted to use this in C++ or not (and whether
> the C usage is now officially sanctioned other than via a non-normative
> footnote) - but at least GCC will guarantee that it works.

My impression is that, via the "active member" wording, C++ standard says
clearly this is UB.  I assume on the GCC side the intention is to treat it
like in C (for POD types only?..), but I don't want to go there in the
"Vector Extensions" section.  Hence my patch limits the suggestion to C.

I think in C++ it's a bit less of an issue anyway, because people can use
operator overloading to achieve a similar end result, with some extra legwork.

Do you want me to change the text somehow?

> Might be interesting to show how to do argument marshalling with the
> same union.

Sorry, I don't see what you mean here; can you give an example or elaborate?

Thanks!
Alexander

Re: Fortran vector math header

[Martin Liška]

On 1/21/19 8:58 AM, Jakub Jelinek wrote:
> On Mon, Jan 21, 2019 at 08:47:42AM +0100, Martin Liška wrote:
>> diff --git a/gcc/fortran/decl.c b/gcc/fortran/decl.c
>> index 3314e176881..5c7c062574b 100644
>> --- a/gcc/fortran/decl.c
>> +++ b/gcc/fortran/decl.c
>> @@ -11351,6 +11351,7 @@ match
>>  gfc_match_gcc_builtin (void)
>>  {
>>char builtin[GFC_MAX_SYMBOL_LEN + 1];
>> +  char target[GFC_MAX_SYMBOL_LEN + 1];
>>  
>>if (gfc_match (" ( %n ) attributes simd", builtin) != MATCH_YES)
>>  return MATCH_ERROR;
>> @@ -11361,6 +11362,24 @@ gfc_match_gcc_builtin (void)
>>else if (gfc_match (" ( inbranch ) ") == MATCH_YES)
>>  clause = SIMD_INBRANCH;
>>  
>> +  if (gfc_match (" if ( %n ) ", target) == MATCH_YES)
>> +{
>> +  unsigned HOST_WIDE_INT size_of_long
>> += tree_to_uhwi (TYPE_SIZE_UNIT (long_integer_type_node));
>> +  if (strcmp (target, "lp64") == 0)
>> +{
>> +  if (size_of_long != 8)
>> +return MATCH_YES;
> 
> __LP64__ macro is defined if:
>   if (TYPE_PRECISION (long_integer_type_node) == 64
>   && POINTER_SIZE == 64
>   && TYPE_PRECISION (integer_type_node) == 32)
> All of these are middle-end types or target macros, so you should be able to
> test that in the Fortran FE too.
> 
>> +}
>> +  else if (strcmp (target, "ilp32") == 0)
>> +{
>> +  if (size_of_long != 4)
>> +return MATCH_YES;
> 
> For this obviously as well.
> 
>> +}
>> +  else
>> +return MATCH_ERROR;
>> +}
>> +
>>if (gfc_vectorized_builtins == NULL)
>>  gfc_vectorized_builtins = new hash_map ();
> 
>   Jakub
> 

Sure, this is patch I've been currently testing.

Thoughts?

Martin
>From 1520b49856a1b39358602c4105dda3891cb166ff Mon Sep 17 00:00:00 2001
From: marxin 
Date: Mon, 21 Jan 2019 08:46:06 +0100
Subject: [PATCH] Support if statement in !GCC$ builtin directive.

gcc/fortran/ChangeLog:

2019-01-21  Martin Liska  

	* decl.c (gfc_match_gcc_builtin): Support filtering for
	'lp64' and 'ilp32'.

gcc/testsuite/ChangeLog:

2019-01-21  Martin Liska  

	* gfortran.dg/simd-builtins-7.f90: New test.
	* gfortran.dg/simd-builtins-7.h: New test.
---
 gcc/fortran/decl.c| 22 +++
 gcc/testsuite/gfortran.dg/simd-builtins-7.f90 | 21 ++
 gcc/testsuite/gfortran.dg/simd-builtins-7.h   |  2 ++
 3 files changed, 45 insertions(+)
 create mode 100644 gcc/testsuite/gfortran.dg/simd-builtins-7.f90
 create mode 100644 gcc/testsuite/gfortran.dg/simd-builtins-7.h

diff --git a/gcc/fortran/decl.c b/gcc/fortran/decl.c
index 3314e176881..d68ab8e7931 100644
--- a/gcc/fortran/decl.c
+++ b/gcc/fortran/decl.c
@@ -28,6 +28,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "match.h"
 #include "parse.h"
 #include "constructor.h"
+#include "target.h"
 
 /* Macros to access allocate memory for gfc_data_variable,
gfc_data_value and gfc_data.  */
@@ -11351,6 +11352,7 @@ match
 gfc_match_gcc_builtin (void)
 {
   char builtin[GFC_MAX_SYMBOL_LEN + 1];
+  char target[GFC_MAX_SYMBOL_LEN + 1];
 
   if (gfc_match (" ( %n ) attributes simd", builtin) != MATCH_YES)
 return MATCH_ERROR;
@@ -11361,6 +11363,26 @@ gfc_match_gcc_builtin (void)
   else if (gfc_match (" ( inbranch ) ") == MATCH_YES)
 clause = SIMD_INBRANCH;
 
+  if (gfc_match (" if ( %n ) ", target) == MATCH_YES)
+{
+  if (strcmp (target, "lp64") == 0)
+	{
+	  if (TYPE_PRECISION (long_integer_type_node) != 64
+	  || POINTER_SIZE != 64
+	  || TYPE_PRECISION (integer_type_node) != 32)
+	return MATCH_YES;
+	}
+  else if (strcmp (target, "ilp32") == 0)
+	{
+	  if (TYPE_PRECISION (long_integer_type_node) != 32
+	  || POINTER_SIZE != 32
+	  || TYPE_PRECISION (integer_type_node) != 32)
+	return MATCH_YES;
+	}
+  else
+	return MATCH_ERROR;
+}
+
   if (gfc_vectorized_builtins == NULL)
 gfc_vectorized_builtins = new hash_map ();
 
diff --git a/gcc/testsuite/gfortran.dg/simd-builtins-7.f90 b/gcc/testsuite/gfortran.dg/simd-builtins-7.f90
new file mode 100644
index 000..6445733d288
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/simd-builtins-7.f90
@@ -0,0 +1,21 @@
+! { dg-do compile { target { i?86-*-linux* x86_64-*-linux* } } }
+! { dg-additional-options "-msse2 -mno-avx -nostdinc -Ofast -fpre-include=simd-builtins-7.h -fdump-tree-optimized" }
+
+program test_overloaded_intrinsic
+  real(4) :: x4(3200), y4(3200)
+  real(8) :: x8(3200), y8(3200)
+
+  ! this should be using simd clone
+  y4 = sin(x4)
+  print *, y4
+
+  ! this should not be using simd clone
+  y4 = sin(x8)
+  print *, y8
+end
+
+! { dg-final { scan-tree-dump "sinf.simdclone" "optimized" { target ia32 } } } */
+! { dg-final { scan-tree-dump-not "sin.simdclone" "optimized" { target ia32 } } } */
+
+! { dg-final { scan-tree-dump "sin.simdclone" "optimized" { target lp64} } } */
+! { dg-final { scan-tree-dump-not "sinf.simdclone" "optimized" { target lp64 } } } */
diff --git a/gcc/testsuite/gfortran.dg/simd-builtins-7.h 

Re: [PATCH][gcc] libgccjit: introduce gcc_jit_context_add_driver_option

[Kyrill Tkachov]

Hi David,

On 19/01/19 01:36, David Malcolm wrote:

On Fri, 2019-01-18 at 19:25 +, Andrea Corallo wrote:
> Hi all,
> this patch add gcc_jit_context_add_driver_option to the libgccjit ABI
> and a testcase for it.
>
> Using this interface is now possible to pass options affecting
> assembler and linker.
>
> Does not introduce any new regression running make check-jit.
>
> Bests
>
>   Andrea
>
>
> gcc/jit/ChangeLog
> 2019-01-16  Andrea Corallo  andrea.cora...@arm.com
>
> * docs/topics/compatibility.rst (LIBGCCJIT_ABI_11): New ABI tag.
> * docs/topics/contexts.rst (Additional driver options): New
> section.
> * jit-playback.c (invoke_driver): Add call to append_driver_options.
> * jit-recording.c: Within namespace gcc::jit...
> (recording::context::~context): Free the optnames within
> m_driver_options.
> (recording::context::add_driver_option): New method.
> (recording::context::append_driver_options): New method.
> (recording::context::dump_reproducer_to_file): Add driver
> options.
> * jit-recording.h: Within namespace gcc::jit...
> (recording::context::add_driver_option): New method.
> (recording::context::append_driver_options): New method.
> (recording::context::m_driver_options): New field.
> * libgccjit++.h (gccjit::context::add_driver_option): New
> method.
> * libgccjit.c (gcc_jit_context_add_driver_option): New API
> entrypoint.
> * libgccjit.h (gcc_jit_context_add_driver_option): New API
> entrypoint.
> (LIBGCCJIT_HAVE_gcc_jit_context_add_driver_option): New
> macro.
> * libgccjit.map (LIBGCCJIT_ABI_11): New ABI tag.
>
>
> gcc/testsuite/ChangeLog
> 2019-01-16  Andrea Corallo  andrea.cora...@arm.com
>
> * jit.dg/add-driver-options-testlib.c: Add support file for
> test-add-driver-options.c testcase.
> * jit.dg/all-non-failing-tests.h: Add test-add-driver-options.c
> * jit.dg/jit.exp (jit-dg-test): Update to support
> add-driver-options-testlib.c compilation.
> * jit.dg/test-add-driver-options.c: New testcase.

Thanks for this patch.

One nit:

[...snip...]

> diff --git a/gcc/testsuite/jit.dg/all-non-failing-tests.h 
b/gcc/testsuite/jit.dg/all-non-failing-tests.h
> index bf02e12..9f816b4 100644
> --- a/gcc/testsuite/jit.dg/all-non-failing-tests.h
> +++ b/gcc/testsuite/jit.dg/all-non-failing-tests.h
> @@ -251,6 +251,13 @@
>  #undef create_code
>  #undef verify_code
>
> +/* test-add-driver-options.c */
> +#define create_code create_code_add_driver_options
> +#define verify_code verify_code_add_driver_options
> +#include "test-add-driver-options.c"
> +#undef create_code
> +#undef verify_code
> +
>  /* Now expose the individual testcases as instances of this struct.  */
>
>  struct testcase

The purpose of the above file is to allow for copies of tests to be
built into test-combination.c and test-threads.c (to shake out state-
handling bugs).  If you're going to embed the test into those, then
they'd also need to be added to the "testcases" array towards the end
of that header.

But given that the new test adds options that affect the whole context,
it's probably best not to embed it into those combined tests.  Instead,
add a comment to all-non-failing-tests.h, similar to the one that
reads:

  /* test-extra-options.c: We don't use this one, since the extra options
 affect the whole context.  */

(changing the filename, of course).

Other than that the patch looks good.

Do you have your copyright assignment paperwork in place?



I believe Andrea's copyright assignment should be covered by the copyright 
assignment from Arm.

Thanks,
Kyrill


Also, we're currently in stage 4 of development for gcc 9, so adding a
feature to libgccjit probably requires Release Manager approval.
(Given the recent discussion on the jit mailing list, this might not be
the only late-breaking jit patch).

Dave

[PATCH][gcc] libgccjit: introduce gcc_jit_context_add_driver_option

[Andrea Corallo]

Hi all,
Second version of the patch addressing David's comment about 
all-non-failing-tests.h

Adds gcc_jit_context_add_driver_option to the libgccjit ABI and a testcase for 
it.

Using this interface is now possible to pass options affecting assembler and 
linker.

Does not introduce regressions running make check-jit

Bests

  Andrea


gcc/jit/ChangeLog
2019-01-16  Andrea Corallo  andrea.cora...@arm.com

* docs/topics/compatibility.rst (LIBGCCJIT_ABI_11): New ABI tag.
* docs/topics/contexts.rst (Additional driver options): New
section.
* jit-playback.c (invoke_driver): Add call to append_driver_options.
* jit-recording.c: Within namespace gcc::jit...
(recording::context::~context): Free the optnames within
m_driver_options.
(recording::context::add_driver_option): New method.
(recording::context::append_driver_options): New method.
(recording::context::dump_reproducer_to_file): Add driver
options.
* jit-recording.h: Within namespace gcc::jit...
(recording::context::add_driver_option): New method.
(recording::context::append_driver_options): New method.
(recording::context::m_driver_options): New field.
* libgccjit++.h (gccjit::context::add_driver_option): New
method.
* libgccjit.c (gcc_jit_context_add_driver_option): New API
entrypoint.
* libgccjit.h (gcc_jit_context_add_driver_option): New API
entrypoint.
(LIBGCCJIT_HAVE_gcc_jit_context_add_driver_option): New
macro.
* libgccjit.map (LIBGCCJIT_ABI_11): New ABI tag.



gcc/testsuite/ChangeLog
2019-01-16  Andrea Corallo  andrea.cora...@arm.com

* jit.dg/add-driver-options-testlib.c: Add support file for
test-add-driver-options.c testcase.
* jit.dg/all-non-failing-tests.h: Add note about
test-add-driver-options.c
* jit.dg/jit.exp (jit-dg-test): Update to support
add-driver-options-testlib.c compilation.
* jit.dg/test-add-driver-options.c: New testcase.

diff --git a/gcc/jit/docs/topics/compatibility.rst b/gcc/jit/docs/topics/compatibility.rst
index 38d338b..abefa56 100644
--- a/gcc/jit/docs/topics/compatibility.rst
+++ b/gcc/jit/docs/topics/compatibility.rst
@@ -168,6 +168,12 @@ entrypoints:
 
 ``LIBGCCJIT_ABI_10``
 
-
 ``LIBGCCJIT_ABI_10`` covers the addition of
 :func:`gcc_jit_context_new_rvalue_from_vector`
+
+.. _LIBGCCJIT_ABI_11:
+
+``LIBGCCJIT_ABI_11``
+
+``LIBGCCJIT_ABI_11`` covers the addition of
+:func:`gcc_jit_context_add_driver_option`
diff --git a/gcc/jit/docs/topics/contexts.rst b/gcc/jit/docs/topics/contexts.rst
index 95964ca..2f8aeb7 100644
--- a/gcc/jit/docs/topics/contexts.rst
+++ b/gcc/jit/docs/topics/contexts.rst
@@ -546,3 +546,36 @@ Additional command-line options
.. code-block:: c
 
   #ifdef LIBGCCJIT_HAVE_gcc_jit_context_add_command_line_option
+
+.. function:: void gcc_jit_context_add_driver_option (gcc_jit_context *ctxt,\
+		  const char *optname)
+
+   Add an arbitrary gcc driver option to the context, for use by
+   :func:`gcc_jit_context_compile` and
+   :func:`gcc_jit_context_compile_to_file`.
+
+   The parameter ``optname`` must be non-NULL.  The underlying buffer is
+   copied, so that it does not need to outlive the call.
+
+   Extra options added by `gcc_jit_context_add_driver_option` are
+   applied *after* all other options potentially overriding them.
+   Options from parent contexts are inherited by child contexts; options
+   from the parent are applied *before* those from the child.
+
+   For example:
+
+   .. code-block:: c
+
+  gcc_jit_context_add_driver_option (ctxt, "-lm");
+  gcc_jit_context_add_driver_option (ctxt, "-fuse-linker-plugin");
+
+   Note that only some options are likely to be meaningful; there is no
+   "frontend" within libgccjit, so typically only those affecting
+   assembler and linker are likely to be useful.
+
+   This entrypoint was added in :ref:`LIBGCCJIT_ABI_11`; you can test for
+   its presence using
+
+   .. code-block:: c
+
+  #ifdef LIBGCCJIT_HAVE_gcc_jit_context_add_driver_option
diff --git a/gcc/jit/jit-playback.c b/gcc/jit/jit-playback.c
index 86f588d..b74495c 100644
--- a/gcc/jit/jit-playback.c
+++ b/gcc/jit/jit-playback.c
@@ -2459,6 +2459,10 @@ invoke_driver (const char *ctxt_progname,
   if (0)
 ADD_ARG ("-v");
 
+  /* Add any user-provided driver extra options.  */
+
+  m_recording_ctxt->append_driver_options ();
+
 #undef ADD_ARG
 
   /* pex_one's error-handling requires pname to be non-NULL.  */
diff --git a/gcc/jit/jit-recording.c b/gcc/jit/jit-recording.c
index 04cc6a6..8ffd0d4 100644
--- a/gcc/jit/jit-recording.c
+++ b/gcc/jit/jit-recording.c
@@ -616,6 +616,8 @@ recording::context::~context ()
   char *optname;
   FOR_EACH_VEC_ELT (m_command_line_options, i, optname)
 free (optname);
+  FOR_EACH_VEC_ELT (m_driver_options, i, optname)
+free (optname);
 
   if (m_builtins_manager)
 delete m_builtins_manager;
@@ -1307,6 +1309,31 @@ recording::context::append_command_line_options (vec  *argvec)
 argvec->safe_push (xstrdup (optname));
 }
 
+/* Add the given optname to this context's list of 

[PATCH] Revert a hunk from r261322 (PR lto/88876).

[Martin Liška]

Hi.

The patch puts back ::get_create for a node that can be seen first time.
It's due to -O0 optimize attribute. It was unable to write properly
LTO test-case for it.

Patch can bootstrap on x86_64-linux-gnu and survives regression tests.

Ready to be installed?
Thanks,
Martin

gcc/ChangeLog:

2019-01-18  Martin Liska  

PR lto/88876
* ipa-pure-const.c (propagate_pure_const): Revert hunk as
we need default values of funct_state for a function that
is not optimized.
---
 gcc/ipa-pure-const.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)


diff --git a/gcc/ipa-pure-const.c b/gcc/ipa-pure-const.c
index 8227eed29bc..b8fd08c0a7e 100644
--- a/gcc/ipa-pure-const.c
+++ b/gcc/ipa-pure-const.c
@@ -1498,7 +1498,8 @@ propagate_pure_const (void)
 		}
 	  if (avail > AVAIL_INTERPOSABLE)
 		{
-		  funct_state y_l = funct_state_summaries->get (y);
+		  funct_state y_l = funct_state_summaries->get_create (y);
+
 		  if (dump_file && (dump_flags & TDF_DETAILS))
 		{
 		  fprintf (dump_file,

Re: [PATCH, zlib] Rename libzgcj_convenience to libz_convenience

[Richard Biener]

On Sun, Jan 20, 2019 at 8:34 PM Iain Buclaw  wrote:
>
> Hi,
>
> As a prerequisite for enabling subdir-objects to libphobos configure
> scripts, the build should be linking to a zlib convenience library,
> rather than building the zlib sources directly from libphobos.
>
> Looking at the existing configure scripts, there's already a
> libzgcj_convenience.a, it is not in use any more as far as I can tell,
> neither is target_all.
>
> Is it OK to drop the reference to gcj in the name?

OK

> --
> Iain
> ---
> zlib/ChangeLog.gcj:
>
> 2019-01-20  Iain Buclaw  
>
> * Makefile.am (noinst_LTLIBRARIES): Rename libzgcj_convience.la to
> libz_convenience.la.
> * Makefile.in: Regenerate.
> * configure.ac: Remove target_all.
> * configure: Regenerate.
> ---

Re: [PATCH] doc: showcase a "union of vectors" pattern (PR 88698)

[Richard Biener]

On Sun, Jan 20, 2019 at 11:40 AM Alexander Monakov  wrote:
>
> Hi,
>
> PR 88698 ("Relax generic vector conversions") is asking to be more permissive
> about type compatibility for generic vector types.  While I don't think that's
> a good idea per se, from a "compiler user" point of view I also see how 
> writing
> code for SSE/AVX using both generic vectors and x86 intrinsics is inconvenient
> because all intrinsics use the same type such as __m128i, regardless of 
> whether
> they operate on 8/16/32/64-bit signed/unsigned lanes.
>
> My solution to that is to introduce a union type that holds both the type
> accepted by intrinsics and generic vector types used by my code. It also has
> an interesting effect that each statement spells out the lane type.
>
> Is it appropriate to showcase this approach in our documentation, as done in
> this patch?  What to do with the PR, should I leave it open?

I think it's appropriate to have this kind of hints in the documentation.

I'm not sure whether it's permitted to use this in C++ or not (and whether
the C usage is now officially sanctioned other than via a non-normative
footnote) - but at least GCC will guarantee that it works.

Might be interesting to show how to do argument marshalling with the
same union.

Richard.

> PR c/88698
> * doc/extend.texi (Vector Extensions): Add an example of using vector
> types together with x86 intrinsics.
>
> --- a/gcc/doc/extend.texi
> +++ b/gcc/doc/extend.texi
> @@ -10632,6 +10632,40 @@ v4si g = __builtin_convertvector (f, v4si); /* g is 
> @{1,-2,3,7@} */
>  v4si h = __builtin_convertvector (c, v4si); /* h is @{1,5,0,10@} */
>  @end smallexample
>
> +@cindex vector types, using with x86 intrinsics
> +Sometimes it is desirable to write code using a mix of generic vector
> +operations (for clarity) and machine-specific vector intrinsics (to
> +access vector instructions that are not exposed via generic built-ins).
> +On x86, intrinsic functions for integer vectors typically use the same
> +vector type @code{__m128i} irrespective of how they interpret the vector,
> +making it necessary to cast their arguments and return values from/to
> +other vector types.  In C, you can make use of a @code{union} type:
> +@c In C++ such type punning via a union is not allowed by the language
> +@smallexample
> +#include 
> +
> +typedef unsigned char u8x16 __attribute__ ((vector_size (16)));
> +typedef unsigned int  u32x4 __attribute__ ((vector_size (16)));
> +
> +typedef union @{
> +u8x16   u8;
> +u32x4   u32;
> +__m128i mm;
> +@} v128;
> +@end smallexample
> +
> +@noindent
> +for variables that can be used with both built-in operations and x86
> +intrinsics:
> +
> +@smallexample
> +v128 x, y = @{ 0 @};
> +memcpy (, ptr, sizeof x);
> +y.u8  += 0x80;
> +x.mm  = _mm_adds_epu8 (x.mm, y.mm);
> +x.u32 &= 0xff;
> +@end smallexample
> +
>  @node Offsetof
>  @section Support for @code{offsetof}
>  @findex __builtin_offsetof

Re: [PATCH] introduce effective-target fold_memcpy

[Richard Biener]

On Sat, Jan 19, 2019 at 12:25 AM Martin Sebor  wrote:
>
> Some of the -Warray-bounds and -Wrestrict tests are prone to failing
> on targets like arm-eabi and others that use different parameters to
> decide which memcpy calls should be folded to MEM_REF (those that do
> are copies of small power-of-two sizes where the power tends to vary
> from target to target and may be as little as 1).  The failures then
> waste the time of those who maintain those secondary targets reporting
> failures (see * below), as well as those who wrote the tests debugging
> the problems and working around them.
>
> To reduce this effort (and ideally avoid these regressions going
> forward) the attached patch adds a new effective-target to the test
> harness: fold_memcpy_N.  It detects the target's willingness to fold
> memcpy call of the given size (N).  While testing this with the arm
> cross-compiler I also tweaked the tests that #include standard
> headers to only do so when __has_include says the header exists.
> This lets the tests pass even when using a cross-compiler without
> library headers installed (my default MO).  If/when the warnings
> are improved to detect the problems regardless of the folding as
> I'm hoping to eventually do, this new effective-target feature
> can be removed.

But all the memcpy folding does is see whether the target can
access unaligned {2,4,8,} memory.  So
a effective target unaligned_move_{2,4,8...} would be better and
possibly useful in other contexts?  memcpy folding might be indeed
a nice vehicle to test this property.

Thus, I guess I'm only asking to rename the effective target keyword.

Btw, new effective targets need documenting in sourcebuild.texi

Richard.

> Martin
>
> [*] https://gcc.gnu.org/ml/gcc-patches/2019-01/msg01056.html

Re: [PATCH] Don't use align > MAX_SUPPORTED_STACK_ALIGNMENT in assign_stack_temp_for_type (PR bootstrap/88450)

[Eric Botcazou]

> Bootstrapped/regtested on x86_64-linux and i686-linux, but that doesn't mean
> much, because MAX_SUPPORTED_STACK_ALIGNMENT there is 1 << 28.  Guess more
> useful would be to test it on mingw where BIGGEST_ALIGNMENT is often higher
> than MAX_SUPPORTED_STACK_ALIGNMENT.
> 
> Thoughts on this?
> 
> 2019-01-10  Jakub Jelinek  
> 
>   PR bootstrap/88450
>   * function.c (assign_stack_temp_for_type): Use alignment at most
>   MAX_SUPPORTED_STACK_ALIGNMENT.  Adjust assert correspondingly.

Not clear to me if this shouldn't be done in get_stack_local_alignment instead 
but I don't really have a strong opinion here.

-- 
Eric Botcazou

Re: [PATCH] PR libstdc++/88782 avoid ODR problems in std::make_shared

[Richard Biener]

On Fri, Jan 18, 2019 at 10:29 PM Jonathan Wakely  wrote:
>
> The old version of _Sp_counted_ptr_inplace::_M_get_deleter (up to GCC
> 8.2.0) expects to be passed a real std::typeinfo object, so mixing that
> with the new definition of the __shared_ptr constructor (which always
> passes the fake tag) leads to accessing the fake object as a real
> std::typeinfo. Instead of trying to make it safe to mix the old and new
> definitions, just stop using that function. By passing a reference to
> __shared_ptr::_M_ptr to the __shared_count constructor it can be set
> directly, without needing to obtain the pointer via the _M_get_deleter
> back-channel. This avoids a virtual dispatch (which fixes PR 87514).
>
> This means that code built against new libstdc++ headers doesn't use
> _M_get_deleter at all, and so make_shared works the same whether RTTI is
> enabled or not.
>
> Also change _M_get_deleter so that it checks for a real type_info object
> even when RTTI is disabled, by calling a library function. Unless
> libstdc++ itself is built without RTTI that library function will be
> able to test if it's the right type_info. This means the new definition
> of _M_get_deleter can handle both the fake type_info tag and a real
> type_info object, even if built without RTTI.
>
> If linking to objects built against older versions of libstdc++ then if
> all objects use -frtti or all use -fno-rtti, then the caller of
> _M_get_deleter and the definition of _M_get_deleter will be consistent
> and it will work. If mixing -frtti with -fno-rtti it can still fail if
> the linker picks an old definition of _M_get_deleter and an old
> __shared_ptr constructor that are incompatible. In that some or all
> objects might need to be recompiled.

Can you try summarizing whatever caveats result from this in
the 8.3/9 changes.html parts?  I have a hard time extracting that
myself from the above ;)  (small example what kind of simplest code might
run into this helps)

Richard.

> PR libstdc++/87514
> PR libstdc++/87520
> PR libstdc++/88782
> * config/abi/pre/gnu.ver (GLIBCXX_3.4.26): Export new symbol.
> * include/bits/shared_ptr.h
> (shared_ptr(_Sp_make_shared_tag, const Alloc&, Args&&...))
> (allocate_shared): Change to use new tag type.
> * include/bits/shared_ptr_base.h (_Sp_make_shared_tag::_S_eq):
> Declare new member function.
> (_Sp_alloc_shared_tag): Define new type.
> (_Sp_counted_ptr_inplace): Declare __shared_count<_Lp> as a friend.
> (_Sp_counted_ptr_inplace::_M_get_deleter) [!__cpp_rtti]: Use
> _Sp_make_shared_tag::_S_eq to check type_info.
> (__shared_count(Ptr, Deleter),__shared_count(Ptr, Deleter, Alloc)):
> Constrain to prevent being called with _Sp_alloc_shared_tag.
> (__shared_count(_Sp_make_shared_tag, const _Alloc&, Args&&...)):
> Replace constructor with ...
> (__shared_count(Tp*&, _Sp_alloc_shared_tag<_Alloc>, Args&&...)): Use
> reference parameter so address of the new object can be returned to
> the caller. Obtain the allocator from the tag type.
> (__shared_ptr(_Sp_make_shared_tag, const Alloc&, Args&&...)): Replace
> constructor with ...
> (__shared_ptr(_Sp_alloc_shared_tag, Args&&...)): Pass _M_ptr
> to the __shared_count constructor.
> (__allocate_shared): Change to use new tag type.
> * src/c++11/shared_ptr.cc (_Sp_make_shared_tag::_S_eq): Define.
>
> Tested powerpc64le-linux, committed to trunk.
>
> I'll backport this to gcc-8-branch without the new symbol in the library.
>
>

Re: [PATCH] Fix leak in splay-tree

[Richard Biener]

On Fri, Jan 18, 2019 at 10:27 PM Tom Tromey  wrote:
>
> Philippe Waroquiers noticed a memory leak in gdb, which he tracked
> down to a bug in splay-tree.  splay_tree_remove does not call the
> `delete_key' function when it removes the old node; but it should.
>
> I looked at every splay tree in GCC and there is only one that passes
> a non-NULL delete function -- the one in lto.c.  That file does not
> call splay_tree_remove.  So, I think this is safe to check in.
>
> I re-ran the LTO tests to double check.

OK

> libiberty/
> * splay-tree.c (splay_tree_remove): Delete the key if necessary.
> ---
>  libiberty/ChangeLog| 4 
>  libiberty/splay-tree.c | 2 ++
>  2 files changed, 6 insertions(+)
>
> diff --git a/libiberty/ChangeLog b/libiberty/ChangeLog
> index bcc0227bdd8..1eb25f928f2 100644
> --- a/libiberty/ChangeLog
> +++ b/libiberty/ChangeLog
> @@ -1,3 +1,7 @@
> +2019-01-18  Tom Tromey  
> +
> +   * splay-tree.c (splay_tree_remove): Delete the key if necessary.
> +
>  2019-01-14  Tom Honermann  
>
> * cp-demangle.c (cplus_demangle_builtin_types)
> diff --git a/libiberty/splay-tree.c b/libiberty/splay-tree.c
> index 920e68db2cb..21d23c38dfc 100644
> --- a/libiberty/splay-tree.c
> +++ b/libiberty/splay-tree.c
> @@ -425,6 +425,8 @@ splay_tree_remove (splay_tree sp, splay_tree_key key)
>right = sp->root->right;
>
>/* Delete the root node itself.  */
> +  if (sp->delete_key)
> +   (*sp->delete_key) (sp->root->key);
>if (sp->delete_value)
> (*sp->delete_value) (sp->root->value);
>(*sp->deallocate) (sp->root, sp->allocate_data);
> --
> 2.17.2
>

Re: [PATCH] i386: Move Intel intrinsics head files to

[Richard Biener]

On Sun, 20 Jan 2019, Uros Bizjak wrote:

> On Sun, Jan 20, 2019 at 4:11 PM H.J. Lu  wrote:
> >
> > On Sun, Jan 20, 2019 at 4:03 AM Uros Bizjak  wrote:
> > >
> > > On 1/19/19, H.J. Lu  wrote:
> > > > According to Intel Intrinsics Guide:
> > > >
> > > > https://software.intel.com/sites/landingpage/IntrinsicsGuide/
> > > >
> > > > Intel intrinsics should be available by including .  This
> > > > patch moves remaining Intel intrinsics head files from  to
> > > > .
> > >
> > > I can't find the quoted requirement in the provided link.
> >
> > That is an interactive website.  If you type in "_xgetbv" and click on it,
> > you will get
> >
> > Synopsis
> >
> > unsigned __int64 _xgetbv (unsigned int a)
> > #include 
> > Instruction: xgetbv
> > CPUID Flags: XSAVE
> >
> > Description
> >
> > Copy up to 64-bits from the value of the extended control register
> > (XCR) specified by a into dst. Currently only XFEATURE_ENABLED_MASK
> > XCR is supported.
> >
> > Operation
> >
> > dst[63:0] := XCR[a]
> 
> Ah, thanks for the hint. LGTM, but still needs RM approval.

OK.

Richard.

> Thanks.
> Uros.
> 
> > > > OK for trunk?
> > >
> > > You will need a RM approval for a non-regression fix patch at this point.
> >
> > Richard, is this OK for GCC 9?
> >
> > > Uros.
> > >
> > > > H.J.
> > > > ---
> > > >   PR target/71659
> > > >   * config/i386/adxintrin.h: Just check _IMMINTRIN_H_INCLUDED.
> > > >   * config/i386/clflushoptintrin.h: Check _IMMINTRIN_H_INCLUDED
> > > >   instead of _X86INTRIN_H_INCLUDED.
> > > >   * onfig/i386/clwbintrin.h: Likewise.
> > > >   * config/i386/pkuintrin.h: Likewise.
> > > >   * config/i386/prfchwintrin.h: Likewise.
> > > >   * config/i386/rdseedintrin.h: Likewise.
> > > >   * config/i386/wbnoinvdintrin.h: Likewise.
> > > >   * config/i386/xsavecintrin.h: Likewise.
> > > >   * config/i386/xsavesintrin.h: Likewise.
> > > >   * config/i386/fxsrintrin.h: Enable _IMMINTRIN_H_INCLUDED check.
> > > >   * config/i386/xsaveintrin.h: Likewise.
> > > >   * config/i386/xsaveoptintrin.h: Likewise.
> > > >   * config/i386/x86intrin.h: Move "#include" ,
> > > >   , , ,
> > > >   , , ,
> > > >   , , ,
> > > >and  to ...
> > > >   * config/i386/immintrin.h: Here.
> > > > ---
> > > >  gcc/config/i386/adxintrin.h|  4 ++--
> > > >  gcc/config/i386/clflushoptintrin.h |  4 ++--
> > > >  gcc/config/i386/clwbintrin.h   |  4 ++--
> > > >  gcc/config/i386/fxsrintrin.h   |  6 +++---
> > > >  gcc/config/i386/immintrin.h| 24 
> > > >  gcc/config/i386/pkuintrin.h|  4 ++--
> > > >  gcc/config/i386/prfchwintrin.h |  4 ++--
> > > >  gcc/config/i386/rdseedintrin.h |  4 ++--
> > > >  gcc/config/i386/wbnoinvdintrin.h   |  4 ++--
> > > >  gcc/config/i386/x86intrin.h| 28 
> > > >  gcc/config/i386/xsavecintrin.h |  4 ++--
> > > >  gcc/config/i386/xsaveintrin.h  |  6 +++---
> > > >  gcc/config/i386/xsaveoptintrin.h   |  6 +++---
> > > >  gcc/config/i386/xsavesintrin.h |  4 ++--
> > > >  14 files changed, 51 insertions(+), 55 deletions(-)
> > > >
> > > > diff --git a/gcc/config/i386/adxintrin.h b/gcc/config/i386/adxintrin.h
> > > > index e01b77ddb4b..e8cb004390c 100644
> > > > --- a/gcc/config/i386/adxintrin.h
> > > > +++ b/gcc/config/i386/adxintrin.h
> > > > @@ -21,8 +21,8 @@
> > > > see the files COPYING3 and COPYING.RUNTIME respectively.  If not, 
> > > > see
> > > > .  */
> > > >
> > > > -#if !defined _X86INTRIN_H_INCLUDED && !defined _IMMINTRIN_H_INCLUDED
> > > > -# error "Never use  directly; include  
> > > > instead."
> > > > +#if !defined _IMMINTRIN_H_INCLUDED
> > > > +# error "Never use  directly; include  
> > > > instead."
> > > >  #endif
> > > >
> > > >  #ifndef _ADXINTRIN_H_INCLUDED
> > > > diff --git a/gcc/config/i386/clflushoptintrin.h
> > > > b/gcc/config/i386/clflushoptintrin.h
> > > > index 1e720c2515c..89aa0f68fc2 100644
> > > > --- a/gcc/config/i386/clflushoptintrin.h
> > > > +++ b/gcc/config/i386/clflushoptintrin.h
> > > > @@ -21,8 +21,8 @@
> > > > see the files COPYING3 and COPYING.RUNTIME respectively.  If not, 
> > > > see
> > > > .  */
> > > >
> > > > -#if !defined _X86INTRIN_H_INCLUDED
> > > > -# error "Never use  directly; include 
> > > > instead."
> > > > +#if !defined _IMMINTRIN_H_INCLUDED
> > > > +# error "Never use  directly; include 
> > > > instead."
> > > >  #endif
> > > >
> > > >  #ifndef _CLFLUSHOPTINTRIN_H_INCLUDED
> > > > diff --git a/gcc/config/i386/clwbintrin.h b/gcc/config/i386/clwbintrin.h
> > > > index 217fb3babf2..68b20ea1635 100644
> > > > --- a/gcc/config/i386/clwbintrin.h
> > > > +++ b/gcc/config/i386/clwbintrin.h
> > > > @@ -21,8 +21,8 @@
> > > > see the files COPYING3 and COPYING.RUNTIME respectively.  If not, 
> > > > see
> > > > .  */
> > > >
> > > > -#if !defined