Reset safe iterator state only if needed
We reset safe iterator state a lot, quite annoying when debugging.
Comitted as trivial.
2018-06-07 François Dumont
* src/c++11/debug.cc
(_Safe_iterator_base::_M_detach()): Reset state only if needed.
(_Safe_iterator_base::_M_detach_single()): Likewise.
(_Safe_local_iterator_base::_M_detach()): Reset state only if needed.
(_Safe_local_iterator_base::_M_detach_single()): Likewise.
diff --git a/libstdc++-v3/src/c++11/debug.cc b/libstdc++-v3/src/c++11/debug.cc
index d20725c..f7249a3 100644
--- a/libstdc++-v3/src/c++11/debug.cc
+++ b/libstdc++-v3/src/c++11/debug.cc
@@ -379,9 +379,10 @@ namespace __gnu_debug
_M_detach()
{
if (_M_sequence)
- _M_sequence->_M_detach(this);
-
-_M_reset();
+ {
+ _M_sequence->_M_detach(this);
+ _M_reset();
+ }
}
void
@@ -389,9 +390,10 @@ namespace __gnu_debug
_M_detach_single() throw ()
{
if (_M_sequence)
- _M_sequence->_M_detach_single(this);
-
-_M_reset();
+ {
+ _M_sequence->_M_detach_single(this);
+ _M_reset();
+ }
}
void
@@ -462,9 +464,10 @@ namespace __gnu_debug
_M_detach()
{
if (_M_sequence)
- _M_get_container()->_M_detach_local(this);
-
-_M_reset();
+ {
+ _M_get_container()->_M_detach_local(this);
+ _M_reset();
+ }
}
void
@@ -472,9 +475,10 @@ namespace __gnu_debug
_M_detach_single() throw ()
{
if (_M_sequence)
- _M_get_container()->_M_detach_local_single(this);
-
-_M_reset();
+ {
+ _M_get_container()->_M_detach_local_single(this);
+ _M_reset();
+ }
}
void
Re: libgcov-driver-system bootstrap failure
On 06/06/2018 03:25 PM, David Edelsohn wrote: > Thanks for both patches. GCC bootstrap on AIX is progressing much > better with the patches installed. > > Thanks, David Thanks David for testing, I've just installed both patches. Martin
RE:Look for the diamond tools 2018/6/7 8:03:13
| Hi dear customer, Have a great day. My name is Peter. We are the facotory in China, produce stone abrasive and diamond tools. Our main products as below: 1. Cutting tools. 2. Grinding & polishing tools. 3. Other tools to process stone, concrete, ceramics etc. We also can make tools as your requirement. Do not hesitate to contact us, if you need our products. Thanks and best regards, Peter Ye | | 2018/6/7 8:03:19 | -- Quanzhou Danar Diamond Tools & Abrasive Co.,Ltd Email: i...@danartool.com Mobile Ph:+8613645919851(WhatsApp&Wechat) Skype:892721...@qq.com Website: www.danartool.com
[PATCH, rs6000] Add missing test cases, fix arguments to match specifications.
GCC Maintainers:
This patch adds various missing test cases for a few builtins. It also
fixes the arguments to match the builtin specifications in the ABI.
The patch was retested on:
powerpc64le-unknown-linux-gnu (Power 8 LE)
powerpc64le-unknown-linux-gnu (Power 9 LE)
powerpc64-unknown-linux-gnu (Power 8 BE)
With no regressions.
Please let me know if the patch looks OK for GCC mainline.
Carl Love
-
gcc/testsuite/ChangeLog:
2018-06-06 Carl Love
* gcc.target/powerpc/p8vector-builtin-3.c: Add vec_pack test. Update
vpkudum counts.
* gcc.target/powerpc/p9-extract-1.c: Make second argument of
vec_extract a signed int. Add vec_extract tests.
* gcc.target/powerpc/p9-extract-3.c: Make second argument of
vec_extract a signed int.
* gcc.target/powerpc/vec-cmp.c: Add vec_cmple, vec_cmpge tests. Update,
vcmpgtsb, vcmpgtub, vcmpgtsh, vcmpgtuh, vcmpgtsw, vcmpgtsw, vcmpgtuw,
vcmpgtsd,
vcmpgtud.
* gcc.target/powerpc/vsx-extract-4.c: Make second argument of
vec_extract a signed int.
* gcc.target/powerpc/vsx-extract-5.c: Make second argument of
vec_extract a signed int.
* gcc.target/powerpc/vsx-vector-7.c (foo): Add tests for vec_sel and
vec_xor builtins. Update xxsel, xxlxor counts.
---
.../gcc.target/powerpc/p8vector-builtin-3.c| 9 +-
gcc/testsuite/gcc.target/powerpc/p9-extract-1.c| 77 --
gcc/testsuite/gcc.target/powerpc/p9-extract-3.c| 36 +++--
gcc/testsuite/gcc.target/powerpc/vec-cmp.c | 159 +++--
gcc/testsuite/gcc.target/powerpc/vsx-extract-4.c | 24 ++--
gcc/testsuite/gcc.target/powerpc/vsx-extract-5.c | 24 ++--
gcc/testsuite/gcc.target/powerpc/vsx-vector-7.c| 72 --
7 files changed, 340 insertions(+), 61 deletions(-)
diff --git a/gcc/testsuite/gcc.target/powerpc/p8vector-builtin-3.c
b/gcc/testsuite/gcc.target/powerpc/p8vector-builtin-3.c
index ff50a9a..56ba6c7 100644
--- a/gcc/testsuite/gcc.target/powerpc/p8vector-builtin-3.c
+++ b/gcc/testsuite/gcc.target/powerpc/p8vector-builtin-3.c
@@ -33,7 +33,12 @@ vi_sign vi_pack_2 (vll_sign a, vll_sign b)
return vec_pack (a, b);
}
-vi_sign vi_pack_3 (vll_sign a, vll_sign b)
+vi_uns vi_pack_3 (vll_uns a, vll_uns b)
+{
+ return vec_pack (a, b);
+}
+
+vi_sign vi_pack_4 (vll_sign a, vll_sign b)
{
return vec_vpkudum (a, b);
}
@@ -98,7 +103,7 @@ vll_sign vll_unpack_lo_3 (vi_sign a)
return vec_vupklsw (a);
}
-/* { dg-final { scan-assembler-times "vpkudum" 3 } } */
+/* { dg-final { scan-assembler-times "vpkudum" 4 } } */
/* { dg-final { scan-assembler-times "vpkuwum" 3 } } */
/* { dg-final { scan-assembler-times "vpkuhum" 3 } } */
/* { dg-final { scan-assembler-times "vupklsw" 3 } } */
diff --git a/gcc/testsuite/gcc.target/powerpc/p9-extract-1.c
b/gcc/testsuite/gcc.target/powerpc/p9-extract-1.c
index ecbe0ed..c708993 100644
--- a/gcc/testsuite/gcc.target/powerpc/p9-extract-1.c
+++ b/gcc/testsuite/gcc.target/powerpc/p9-extract-1.c
@@ -13,84 +13,136 @@
int
extract_int_0 (vector int a)
{
- int b = vec_extract (a, 0);
+ int c = 0;
+ int b = vec_extract (a, c);
return b;
}
int
extract_int_3 (vector int a)
{
- int b = vec_extract (a, 3);
+ int c = 3;
+ int b = vec_extract (a, c);
return b;
}
unsigned int
extract_uint_0 (vector unsigned int a)
{
- unsigned int b = vec_extract (a, 0);
+ int c = 0;
+ unsigned int b = vec_extract (a, c);
return b;
}
unsigned int
extract_uint_3 (vector unsigned int a)
{
- unsigned int b = vec_extract (a, 3);
+ int c = 3;
+ unsigned int b = vec_extract (a, c);
return b;
}
short
extract_short_0 (vector short a)
{
- short b = vec_extract (a, 0);
+ int c = 0;
+ short b = vec_extract (a, c);
return b;
}
short
extract_short_7 (vector short a)
{
- short b = vec_extract (a, 7);
+ int c = 7;
+ short b = vec_extract (a, c);
return b;
}
unsigned short
extract_ushort_0 (vector unsigned short a)
{
- unsigned short b = vec_extract (a, 0);
+ int c = 0;
+ unsigned short b = vec_extract (a, c);
return b;
}
unsigned short
extract_ushort_7 (vector unsigned short a)
{
- unsigned short b = vec_extract (a, 7);
+ int c = 7;
+ unsigned short b = vec_extract (a, c);
return b;
}
signed char
extract_schar_0 (vector signed char a)
{
- signed char b = vec_extract (a, 0);
+ int c = 0;
+ signed char b = vec_extract (a, c);
return b;
}
signed char
extract_schar_15 (vector signed char a)
{
- signed char b = vec_extract (a, 15);
+ int c = 15;
+ signed char b = vec_extract (a, c);
return b;
}
unsigned char
extract_uchar_0 (vector unsigned char a)
{
- unsigned char b = vec_extract (a, 0);
+ int c = 0;
+ unsigned char b = vec_extract (a, c);
return b;
}
unsigned char
extract_uchar_15 (vector unsigned char a)
{
- signed
New Esperanto PO file for 'cpplib' (version 8.1-b20180128)
Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'cpplib' has been submitted by the Esperanto team of translators. The file is available at: http://translationproject.org/latest/cpplib/eo.po (This file, 'cpplib-8.1-b20180128.eo.po', has just now been sent to you in a separate email.) All other PO files for your package are available in: http://translationproject.org/latest/cpplib/ Please consider including all of these in your next release, whether official or a pretest. Whenever you have a new distribution with a new version number ready, containing a newer POT file, please send the URL of that distribution tarball to the address below. The tarball may be just a pretest or a snapshot, it does not even have to compile. It is just used by the translators when they need some extra translation context. The following HTML page has been updated: http://translationproject.org/domain/cpplib.html If any question arises, please contact the translation coordinator. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator.
Contents of PO file 'cpplib-8.1-b20180128.eo.po'
cpplib-8.1-b20180128.eo.po.gz Description: Binary data The Translation Project robot, in the name of your translation coordinator.
Re: [PATCH, rs6000] Add BE support for first_match_index, first_match_or_eos_index, first_mismatch_index, first_mismatch_or_eos_index
Segher: > > > > rtx tmp = gen_reg_rtx (SImode); > > > > - emit_insn (gen_vctzlsbb_ (tmp, result)); > > > > + if (!BYTES_BIG_ENDIAN) > > > > +emit_insn (gen_vctzlsbb_ (tmp, result)); > > > > + else > > > > +emit_insn (gen_vclzlsbb_ (tmp, result)); > > > > emit_insn (gen_ashrsi3 (operands[0], tmp, GEN_INT > > > > (sh))); > > > > } > > > > > > Can this work with lshrsi3 instead? That is slightly cheaper. > > > > > > Looks great, please apply to trunk. Thanks! > > > > Yes, the builtin works with lshrsi3 change. I will commit with > > this > > change. > > It occurs in four places, please fix all then. Yup, I already got all four of them. :-) Carl Love
Re: [PATCH, rs6000] Add BE support for first_match_index, first_match_or_eos_index, first_mismatch_index, first_mismatch_or_eos_index
On Wed, Jun 06, 2018 at 03:30:17PM -0700, Carl Love wrote:
> > One thing that caught my eye, nothing new though:
> >
> > > {
> > > rtx tmp = gen_reg_rtx (SImode);
> > > - emit_insn (gen_vctzlsbb_ (tmp, result));
> > > + if (!BYTES_BIG_ENDIAN)
> > > +emit_insn (gen_vctzlsbb_ (tmp, result));
> > > + else
> > > +emit_insn (gen_vclzlsbb_ (tmp, result));
> > > emit_insn (gen_ashrsi3 (operands[0], tmp, GEN_INT (sh)));
> > > }
> >
> > Can this work with lshrsi3 instead? That is slightly cheaper.
> >
> > Looks great, please apply to trunk. Thanks!
>
> Yes, the builtin works with lshrsi3 change. I will commit with this
> change.
It occurs in four places, please fix all then.
> FYI, Bill would like to patch backported to GCC 8. Is that OK?
Certainly. Thanks!
Segher
Re: [PATCH] [MSP430] Fix device name symbol defined for MSP430i series of devices
That's fine too, I was thinking of checking mcu_name[i] against NUL. Any of those solutions would work :-)
Re: [PATCH, rs6000] Add BE support for first_match_index, first_match_or_eos_index, first_mismatch_index, first_mismatch_or_eos_index
Segher:
> > * gcc/config/rs6000/vsx.md (first_match_index_):
> > Calculate index using natureal element order.
>
> Typo ("natural"). You normally shouldn't do a line break after :
> btw.
>
Fixed both issues.
> One thing that caught my eye, nothing new though:
>
> > {
> > rtx tmp = gen_reg_rtx (SImode);
> > - emit_insn (gen_vctzlsbb_ (tmp, result));
> > + if (!BYTES_BIG_ENDIAN)
> > +emit_insn (gen_vctzlsbb_ (tmp, result));
> > + else
> > +emit_insn (gen_vclzlsbb_ (tmp, result));
> > emit_insn (gen_ashrsi3 (operands[0], tmp, GEN_INT (sh)));
> > }
>
> Can this work with lshrsi3 instead? That is slightly cheaper.
>
> Looks great, please apply to trunk. Thanks!
Yes, the builtin works with lshrsi3 change. I will commit with this
change.
FYI, Bill would like to patch backported to GCC 8. Is that OK?
Carl Love
Re: [PATCH v2, #3 of 3], Add weak references to bridge old/new PowerPC ieee 128-bit name mangling
On Wed, Jun 06, 2018 at 02:52:27PM -0500, Segher Boessenkool wrote:
> On Tue, Jun 05, 2018 at 07:11:41PM -0400, Michael Meissner wrote:
> > This patch makes the long double pack/unpack built-in functions only
> > available
> > if the long double format is IBM extended double.
> >
> > I added new pack and unpack functions that use __ibm128 instead of long
> > double
> > in case somebody needs to build IBM extended double after we have changed
> > the
> > default to IEEE 128-bit.
>
> > @@ -15339,10 +15340,9 @@ rs6000_invalid_builtin (enum rs6000_buil
> >else if ((fnmask & RS6000_BTM_P9_MISC) == RS6000_BTM_P9_MISC)
> > error ("builtin function %qs requires the %qs option", name,
> >"-mcpu=power9");
> > - else if ((fnmask & (RS6000_BTM_HARD_FLOAT | RS6000_BTM_LDBL128))
> > - == (RS6000_BTM_HARD_FLOAT | RS6000_BTM_LDBL128))
> > -error ("builtin function %qs requires the %qs and %qs options",
> > - name, "-mhard-float", "-mlong-double-128");
> > + else if ((fnmask & RS6000_BTM_LDBL128) == RS6000_BTM_LDBL128)
> > +error ("builtin function %qs requires the %qs option", name,
> > + TARGET_IEEEQUAD ? "-mabi=ibmlongdouble" : "-mlong-double-128");
>
> This no longer tests for hard float. Is that correct, i.e. is hard
> float always enabled if we get here?
I originally thought that, but perhaps it is better to add an explict check
once again.
> > + /* For the pack and unpack int128 routines, fix up the builtin so it
> > +uses the correct IBM128 type. */
> > +case MISC_BUILTIN_PACK_IF:
> > + if (TARGET_LONG_DOUBLE_128 && !TARGET_IEEEQUAD)
> > + {
> > + icode = CODE_FOR_packtf;
> > + fcode = MISC_BUILTIN_PACK_TF;
> > + uns_fcode = (size_t)fcode;
> > + }
> > + break;
> > +
> > +case MISC_BUILTIN_UNPACK_IF:
> > + if (TARGET_LONG_DOUBLE_128 && !TARGET_IEEEQUAD)
> > + {
> > + icode = CODE_FOR_unpacktf;
> > + fcode = MISC_BUILTIN_UNPACK_TF;
> > + uns_fcode = (size_t)fcode;
> > + }
> > + break;
>
> (Space after cast, but nothing here does that I see).
>
> Is this correct? Why should it not use the IFmode version?
Because in the patch that I just commited (patch #2), we use the TF type for
__ibm128 when long double is IBM 128-bit. This makes templates work.
Otherwise if you try a template of __ibm128 and long double, you get an
internal compiler error.
> > +is returned. The @code{__builtin_unpack_longdouble} function is only
> > +availble if @code{long double} uses the IBM extended double
> > +representation.
>
> Typo ("available").
Ok.
> > +The @code{__builtin_pack_longdouble} function takes two @code{double}
> > +arguments and returns a @code{long double} value that combines the two
> > +arguments. The @code{__builtin_pack_longdouble} function is only
> > +availble if @code{long double} uses the IBM extended double
> > +representation.
>
> And here.
Ok.
> Okay for trunk (and backports) if those are not mistakes or you fix them,
> and maybe add some comment.
I will add a check for hard float back again.
--
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797
Re: [PATCH] [MSP430] Fix device name symbol defined for MSP430i series of devices
On 06/06/18 22:02, DJ Delorie wrote:
Jozef Lawrynowicz writes:
- for (i = start_upper; i < strlen (mcu_name); i++)
+ for (i = start_upper; i < strlen (mcu_name) - 2; i++)
Might be faster to test mcu_name[i] instead of calling strlen repeatedly
too, but this only runs once per invocation ;-)
Some devices have '_' as part of the name so we can't test against that for
when to break from the loop.
Stored the index to stop on in a variable, so at least strlen isn't called every
time.
>From fac4ae33d665189641b58219598c0af63fe6d316 Mon Sep 17 00:00:00 2001
From: Jozef Lawrynowicz
Date: Mon, 4 Jun 2018 12:04:54 +0100
Subject: [PATCH] MSP430: Fix device name symbol defined for msp430i* devices
2018-06-04 Jozef Lawrynowicz
* gcc/config/msp430/msp430.c (msp430_mcu_name): Set the "i" in the
symbol defined for msp430i* devices to be lower case.
gcc/testsuite/gcc.target/msp430/
* msp430i-device-symbol.c: New test.
* msp430f-device-symbol.c: New test.
* msp430.h: New test header file.
---
gcc/config/msp430/msp430.c | 21 ++---
gcc/testsuite/gcc.target/msp430/msp430.h| 8
.../gcc.target/msp430/msp430f-device-symbol.c | 4
.../gcc.target/msp430/msp430i-device-symbol.c | 4
4 files changed, 34 insertions(+), 3 deletions(-)
create mode 100644 gcc/testsuite/gcc.target/msp430/msp430.h
create mode 100644 gcc/testsuite/gcc.target/msp430/msp430f-device-symbol.c
create mode 100644 gcc/testsuite/gcc.target/msp430/msp430i-device-symbol.c
diff --git a/gcc/config/msp430/msp430.c b/gcc/config/msp430/msp430.c
index a8fed12..50c92da 100644
--- a/gcc/config/msp430/msp430.c
+++ b/gcc/config/msp430/msp430.c
@@ -725,10 +725,25 @@ msp430_mcu_name (void)
if (target_mcu)
{
unsigned int i;
- static char mcu_name [64];
+ unsigned int start_upper;
+ unsigned int end_upper;
+ static char mcu_name[64];
- snprintf (mcu_name, sizeof (mcu_name) - 1, "__%s__", target_mcu);
- for (i = strlen (mcu_name); i--;)
+ /* The 'i' in the device name symbol for msp430i* devices must be lower
+ case, to match the expected symbol in msp430.h. */
+ if (strncmp (target_mcu, "msp430i", 7) == 0)
+ {
+ snprintf (mcu_name, sizeof (mcu_name) - 1, "__MSP430i%s__",
+ target_mcu + 7);
+ start_upper = 9;
+ }
+ else
+ {
+ snprintf (mcu_name, sizeof (mcu_name) - 1, "__%s__", target_mcu);
+ start_upper = 2;
+ }
+ end_upper = strlen (mcu_name) - 2;
+ for (i = start_upper; i < end_upper; i++)
mcu_name[i] = TOUPPER (mcu_name[i]);
return mcu_name;
}
diff --git a/gcc/testsuite/gcc.target/msp430/msp430.h b/gcc/testsuite/gcc.target/msp430/msp430.h
new file mode 100644
index 000..1dedbc0
--- /dev/null
+++ b/gcc/testsuite/gcc.target/msp430/msp430.h
@@ -0,0 +1,8 @@
+#if defined (__MSP430i2020__)
+
+#elif defined (__MSP430F5529__)
+
+#else
+#error "Device not supported by msp430.h"
+
+#endif
diff --git a/gcc/testsuite/gcc.target/msp430/msp430f-device-symbol.c b/gcc/testsuite/gcc.target/msp430/msp430f-device-symbol.c
new file mode 100644
index 000..e41cdaf
--- /dev/null
+++ b/gcc/testsuite/gcc.target/msp430/msp430f-device-symbol.c
@@ -0,0 +1,4 @@
+/* { dg-do preprocess } */
+/* { dg-skip-if "" { "*-*-*" } { "-mcpu=msp430" "-mmcu=*" "-mhwmult=32bit" "-mhwmult=16bit" } { "" } } */
+/* { dg-options "-mmcu=msp430f5529" } */
+#include "msp430.h"
diff --git a/gcc/testsuite/gcc.target/msp430/msp430i-device-symbol.c b/gcc/testsuite/gcc.target/msp430/msp430i-device-symbol.c
new file mode 100644
index 000..36a86c1
--- /dev/null
+++ b/gcc/testsuite/gcc.target/msp430/msp430i-device-symbol.c
@@ -0,0 +1,4 @@
+/* { dg-do preprocess } */
+/* { dg-skip-if "" { "*-*-*" } { "-mlarge" "-mcpu=msp430x*" "-mmcu=*" "-mhwmult=32bit" "-mhwmult=f5series" } { "" } } */
+/* { dg-options "-mmcu=msp430i2020" } */
+#include "msp430.h"
--
2.7.4
[patch, fortran, committed] Fix PR 85641
Hello world,
I have just committed the attached patch as obvious after
regression-testing.
Since this fixes a regression, I will backport to gcc8 and gcc7 in
the next days.
Regards
Thomas
2018-06-06 Thomas Koenig
PR fortran/85641
* frontend-passes.c (is_fe_temp): Add prototype.
(realloc_string_callback): Early return for frontend-generated
temporary.
2018-06-06 Thomas Koenig
PR fortran/85641
* gfortran.dg/realloc_on_assign_30.f90: New test.
Index: frontend-passes.c
===
--- frontend-passes.c (Revision 261245)
+++ frontend-passes.c (Arbeitskopie)
@@ -57,6 +57,8 @@ static bool has_dimen_vector_ref (gfc_expr *);
static int matmul_temp_args (gfc_code **, int *,void *data);
static int index_interchange (gfc_code **, int*, void *);
+static bool is_fe_temp (gfc_expr *e);
+
#ifdef CHECKING_P
static void check_locus (gfc_namespace *);
#endif
@@ -254,6 +256,9 @@ realloc_string_callback (gfc_code **c, int *walk_s
|| !expr1->ts.deferred)
return 0;
+ if (is_fe_temp (expr1))
+return 0;
+
expr2 = gfc_discard_nops (co->expr2);
if (expr2->expr_type == EXPR_VARIABLE)
! { dg-do compile }
! PR 85641 - this used to ICE due do infinite recursion.
! Test case by Antony Lewis.
program tester
character(LEN=:), allocatable :: fields
integer j
character(LEN=4), parameter :: CMB_CL_Fields = 'TEBP'
fields = ''
j=1
fields = fields // CMB_CL_Fields(j:j)
end program tester
C++ PATCH for c++/86063, ICE with attribute with pack expansion
We crash on this testcase containing a bogus attribute, because
cp_check_const_attributes accessed TREE_VALUE of a tree that happened to be
expr_pack_expansion. Since here we're merely trying to evaluate constexpr
arguments, I thought we could skip such bogus arguments.
Bootstrapped/regtested on x86_64-linux, ok for trunk?
2018-06-06 Marek Polacek
PR c++/86063
* decl2.c (cp_check_const_attributes): Skip trees that are not
TREE_LISTs.
* g++.dg/cpp0x/gen-attrs-65.C: New test.
diff --git gcc/cp/decl2.c gcc/cp/decl2.c
index 2cef9c750ed..35d8e423397 100644
--- gcc/cp/decl2.c
+++ gcc/cp/decl2.c
@@ -1386,7 +1386,8 @@ cp_check_const_attributes (tree attributes)
for (attr = attributes; attr; attr = TREE_CHAIN (attr))
{
tree arg;
- for (arg = TREE_VALUE (attr); arg; arg = TREE_CHAIN (arg))
+ for (arg = TREE_VALUE (attr); arg && TREE_CODE (arg) == TREE_LIST;
+ arg = TREE_CHAIN (arg))
{
tree expr = TREE_VALUE (arg);
if (EXPR_P (expr))
diff --git gcc/testsuite/g++.dg/cpp0x/gen-attrs-65.C
gcc/testsuite/g++.dg/cpp0x/gen-attrs-65.C
index e69de29bb2d..1d2b2f04e7a 100644
--- gcc/testsuite/g++.dg/cpp0x/gen-attrs-65.C
+++ gcc/testsuite/g++.dg/cpp0x/gen-attrs-65.C
@@ -0,0 +1,7 @@
+// PR c++/86063
+// { dg-do compile { target c++11 } }
+
+template
+struct S {
+ [[foobar(alignof(T))...]] char t; // { dg-warning "attribute directive
ignored" }
+};
Re: [PATCH] [MSP430] Fix device name symbol defined for MSP430i series of devices
Jozef Lawrynowicz writes: > - for (i = start_upper; i < strlen (mcu_name); i++) > + for (i = start_upper; i < strlen (mcu_name) - 2; i++) Might be faster to test mcu_name[i] instead of calling strlen repeatedly too, but this only runs once per invocation ;-)
Re: [PATCH] [MSP430] Fix device name symbol defined for MSP430i series of devices
On 06/06/18 21:38, DJ Delorie wrote: + snprintf (mcu_name, sizeof (mcu_name) - 1, "__%s__", target_mcu); + start_upper = 0; Can optimize this to 2 :-) Otherwise OK. Ah yes. Could also do: - for (i = start_upper; i < strlen (mcu_name); i++) + for (i = start_upper; i < strlen (mcu_name) - 2; i++)
Re: [PATCH][RFC] Drop GENERIC conds in [VEC_]COND_EXPRs
Richard Biener writes:
> On Tue, 5 Jun 2018, Richard Biener wrote:
>
>>
>> This is a prototype enforcing is_gimple_val conditions in
>> [VEC_]COND_EXPRs. It shows quite some fallout - some likely
>> due to necessary testsuite adjustments like gcc.dg/tree-ssa/ssa-lim-12.c
>> others because some code simply doesn't handle conditions visible
>> only via following SSA defs like vect_recog_mixed_size_cond_pattern.
>>
>> So on x86_64 there's quite some vect.exp fallout.
>>
>> Anyhow, to assess the effect on other targets I'm throwing this
>> in here.
>>
>> I've hopefully nailed all ICEs (or at least makes catching them
>> easy with some asserts in GIMPLE stmt building).
>>
>> Full bootstrap and regtest for all languages running on
>> x86_64-unknown-linux-gnu.
FWIW, I ran the original version through our internal SVE benchmarks.
There were quite a few ICEs from:
pattern_stmt
= gimple_build_assign (vect_recog_temp_ssa_var (itype, NULL),
COND_EXPR, cond_expr, trueval,
build_int_cst (itype, 0));
in adjust_bool_pattern and some from loop_cand::undo_simple_reduction
(which it looks like you fixed in the updated patch). But of the
tests that successfully built, it looks like this is neutral (good!).
I can try to fix the adjust_bool_pattern thing if you don't see it for AVX.
> Testing shows a few omissions in the patch (updated patch attached
> below). It also shows that expand_vec_cond_expr_p and friends
> need some heavy lifting to deal with vcond* patterns which have
> the comparison embedded. There's vcond_mask* which would be
> more suited to the GIMPLE we have after this patch and I suspect
> we can always expand
>
> _1 = _2 < _3;
> _4 = _1 ? _5 : _66;
>
> as
>
> _1 = _2 < _3 ? { -1,...} : {0,...}; via vcond_*
> _4 = _1 != 0 ? _5 : _6; via vcond_*
>
> at expansion time TER might come to the rescue, if there are multiple
> uses of _1 then there's cost issues to honor in case _1 = _2 < _3
> can be expanded more efficiently than via such fake vcond_*.
>
> In any case the expander now needs to be made more smart
> (as well as the pattern recog part of the vectorizer).
Why not match them as internal functions, like we now do for FMA* etc.?
It seems like a similar case: for FMAs we wanted to fold in negates while
here we want to fold in the comparison. The fold could be handled by
match.pd, gated on a suitably late predicate. (Unless the vectoriser
really does have to generate it directly, in which case maybe it could
also/instead be done as a pattern. That might even make the generation
side simpler, since the pattern would just go through vectorizable_call.)
Using one internal function per comparison type would also help to clean
up the optabs interface. At the moment, targets basically have to
accept any comparison type that's going, regardless of what the target
can actually support. If we use internal functions that directly map to
individual optabs, then we can use target-independent code to make the
comparison fit. (At least for the obvious cases. Some FP comparisons
might still be better emulated directly by the target.)
> Jakub - I remember you weren't too happy about splitting the
> conditions out of [VEC_]COND_EXPRs this came up last time?
> With the alternative idea of transitioning [VEC_]COND_EXPRs to
> tcc_comparisons with conditional ops aka
>
> _1 = _2 < _3 ? _5 : _6;
>
> with RHS code LT_EXPR and 4 operands what do you think of
> Richards complaint about being forced to repeat _2 < _3?
> A split out _2 < _3 would then look like
>
> _4 = _2 < _3 ? {-1,...} : {0,...};
> _1 = _4 != {0,...} ? _5 : _6;
>
> so "plain" LT_EXPR rhs wouldn't be supported anymore but they'd
> always have explicit true and false values attached. With making
> the last two ops optional we could make them implicit again of course.
> We could also keep [VEC_]COND_EXPR then in 3-operand form with
> a gimple-val predicate rather than a comparison. Of course that
> wouldn't really simplify the IL overall...
Yeah, this still doesn't seem like an improvement to me TBH. For one
thing it'd be confusing for LT_EXPR to have 2 operands for generic and
4 for gimple: are there any other cases where we do that? I suppose the
GIMPLE_SINGLE_RHS stuff is a special case too, but it sounded like you
saw that was a wart and wanted to move away from it.
Thanks,
Richard
Re: [PATCH, rs6000] Split up builtins-3.c tests
On Wed, Jun 06, 2018 at 10:07:23AM -0700, Carl Love wrote:
> The following patch moves the tests from builtins-3.c that require the
> -mvsx" command line option to the new test file builtins-4.c. The
> tests that are left in file builtins-3.c require just the -maltivec
> option.
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/powerpc/builtins-4.c
> @@ -0,0 +1,167 @@
> +/* { dg-do compile { target powerpc*-*-* } } */
> +/* { dg-require-effective-target powerpc_altivec_ok } */
> +/* { dg-options "-mvsx" } */
You need powerpc_vsx_ok here? Okay for trunk with that change. Thanks!
Segher
Re: [PATCH,rs6000] Fix vec_permxor builtin support, fix test cases for vec_permxor and vec_insert4b
On Wed, Jun 06, 2018 at 08:29:47AM -0700, Carl Love wrote: > 2018-06-06 Carl Love > * gcc.target/powerpc/builtins-7-p9-runnable.c: Change first > argument to vui_arg. This is fine, please go ahead. Thanks! Segher
Re: [PATCH, rs6000] Add BE support for first_match_index, first_match_or_eos_index, first_mismatch_index, first_mismatch_or_eos_index
On Wed, Jun 06, 2018 at 08:01:22AM -0700, Carl Love wrote:
> 2018-06-04 Carl Love
>
> * gcc/config/rs6000/vsx.md (first_match_index_):
> Calculate index using natureal element order.
Typo ("natural"). You normally shouldn't do a line break after : btw.
One thing that caught my eye, nothing new though:
> {
>rtx tmp = gen_reg_rtx (SImode);
> - emit_insn (gen_vctzlsbb_ (tmp, result));
> + if (!BYTES_BIG_ENDIAN)
> +emit_insn (gen_vctzlsbb_ (tmp, result));
> + else
> +emit_insn (gen_vclzlsbb_ (tmp, result));
>emit_insn (gen_ashrsi3 (operands[0], tmp, GEN_INT (sh)));
> }
Can this work with lshrsi3 instead? That is slightly cheaper.
Looks great, please apply to trunk. Thanks!
Segher
Re: [PATCH] [MSP430] Fix device name symbol defined for MSP430i series of devices
> + snprintf (mcu_name, sizeof (mcu_name) - 1, "__%s__", target_mcu); > + start_upper = 0; Can optimize this to 2 :-) Otherwise OK.
Re: Extend tree code folds to IFN_COND_*
> On Thu, May 24, 2018 at 11:36 AM Richard Sandiford
> wrote:
>>
>> This patch adds match.pd support for applying normal folds to their
>> IFN_COND_* forms. E.g. the rule:
>>
>> (plus @0 (negate @1)) -> (minus @0 @1)
>>
>> also allows the fold:
>>
>> (IFN_COND_ADD @0 @1 (negate @2) @3) -> (IFN_COND_SUB @0 @1 @2 @3)
>>
>> Actually doing this by direct matches in gimple-match.c would
>> probably lead to combinatorial explosion, so instead, the patch
>> makes gimple_match_op carry a condition under which the operation
>> happens ("cond"), and the value to use when the condition is false
>> ("else_value"). Thus in the example above we'd do the following
>>
>> (a) convert:
>>
>> cond:NULL_TREE (IFN_COND_ADD @0 @1 @4 @3) else_value:NULL_TREE
>>
>> to:
>>
>> cond:@0 (plus @1 @4) else_value:@3
>>
>> (b) apply gimple_resimplify to (plus @1 @4)
>>
>> (c) reintroduce cond and else_value when constructing the result.
>>
>> Nested operations inherit the condition of the outer operation
>> (so that we don't introduce extra faults) but have a null else_value.
>> If we try to build such an operation, the target gets to choose what
>> else_value it can handle efficiently: obvious choices include one of
>> the operands or a zero constant. (The alternative would be to have some
>> representation for an undefined value, but that seems a bit invasive,
>> and isn't likely to be useful here.)
>>
>> I've made the condition a mandatory part of the gimple_match_op
>> constructor so that it doesn't accidentally get dropped.
>>
>> Tested on aarch64-linux-gnu (with and without SVE), aarch64_be-elf
>> and x86_64-linux-gnu. OK to install?
>
> It looks somewhat clever but after looking for a while it doesn't handle
> simplifying
>
> (IFN_COND_ADD @0 @1 (IFN_COND_SUB @0 @2 @1 @3) @3)
>
> to
>
> (cond @0 @2 @3)
>
> right? Because while the conditional gimple_match_op is built
> by try_conditional_simplification it isn't built when doing
> SSA use->def following in the generated matching code?
Right. This would be easy to add, but there's no motivating case yet.
> So it looks like a bit much noise for this very special case?
>
> I suppose you ran into the need of these foldings from looking
> at real code - which foldings specifically were appearing here?
> Usually code is well optimized before if-conversion/vectorization
> so we shouldn't need full-blown handling?
It's needed to get the FMA, FMS, FNMA and FNMS folds for IFN_COND_* too.
I thought it'd be better to do it "automatically" rather than add specific
folds, since if we don't do it automatically now, it's going to end up
being a precedent for not doing it automatically in future either.
> That said, I'm not sure how much work it is to massage
>
> if (gimple *def_stmt = get_def (valueize, op2))
> {
> if (gassign *def = dyn_cast (def_stmt))
> switch (gimple_assign_rhs_code (def))
> {
> case PLUS_EXPR:
>
> to look like
>
> if (gimple *def_stmt = get_def (valueize, op2))
> {
>code = ERROR_MARK;
>if (!is_cond_ifn_with_cond (curr_gimple_match_op, &code))
> if (gassign *def dyn_cast (def_stmt))
>code = gimple_assign_rhs_code (def);
>switch (code)
> {
> case PLUS_EXPR:
>
> thus transparently treat the IFN_COND_* as their "code" if the condition
> matches that of the context (I'm not sure if we can do anything for
> mismatching contexts).
Yeah, this was one approach I had in mind for the subnodes, if we do
end up needing it. But at least for the top-level node, we want to try
both as a native IFN_COND_FOO and as a conditional FOO, which is why the
top-level case is handled directly in gimple-match-head.c.
Of course, trying both for subnodes would lead to exponential behaviour
in general. And like you say, in practice most double-IFN_COND cases
should have been folded before we created the IFN_CONDs, so it's hard
to tell which recursive behaviour would be best.
Thanks,
Richard
Re: [PATCH, rs6000] Fix PR target/63177: Powerpc no-vfa-vect-depend-2.c and no-vfa-vect-depend-3.c failures
On Tue, Jun 05, 2018 at 10:03:46PM -0500, Peter Bergner wrote: > On 6/5/18 3:22 PM, Segher Boessenkool wrote: > > Ah, that's the crux. Thanks. Add a comment to the code please? > > Like so? I tried placing it next to the mcpu=power8 clause, but it seems > you cannot place comments there, as it creates syntax errors during the build. > > /* Common ASM definitions used by ASM_SPEC among the various targets for > handling -mcpu=xxx switches. There is a parallel list in driver-rs6000.c > to > provide the default assembler options if the user uses -mcpu=native, so if > - you make changes here, make them also there. */ > + you make changes here, make them also there. PR63177: Do not pass > -mpower8 > + to the assembler if -mpower9-vector was also used. */ > #define ASM_CPU_SPEC \ > ... Yes that's great, thanks! Backports are okay, too. Segher
Re: [PATCH v2, #3 of 3], Add weak references to bridge old/new PowerPC ieee 128-bit name mangling
On Tue, Jun 05, 2018 at 07:11:41PM -0400, Michael Meissner wrote:
> This patch makes the long double pack/unpack built-in functions only available
> if the long double format is IBM extended double.
>
> I added new pack and unpack functions that use __ibm128 instead of long double
> in case somebody needs to build IBM extended double after we have changed the
> default to IEEE 128-bit.
> @@ -15339,10 +15340,9 @@ rs6000_invalid_builtin (enum rs6000_buil
>else if ((fnmask & RS6000_BTM_P9_MISC) == RS6000_BTM_P9_MISC)
> error ("builtin function %qs requires the %qs option", name,
> "-mcpu=power9");
> - else if ((fnmask & (RS6000_BTM_HARD_FLOAT | RS6000_BTM_LDBL128))
> -== (RS6000_BTM_HARD_FLOAT | RS6000_BTM_LDBL128))
> -error ("builtin function %qs requires the %qs and %qs options",
> -name, "-mhard-float", "-mlong-double-128");
> + else if ((fnmask & RS6000_BTM_LDBL128) == RS6000_BTM_LDBL128)
> +error ("builtin function %qs requires the %qs option", name,
> +TARGET_IEEEQUAD ? "-mabi=ibmlongdouble" : "-mlong-double-128");
This no longer tests for hard float. Is that correct, i.e. is hard
float always enabled if we get here?
> + /* For the pack and unpack int128 routines, fix up the builtin so it
> + uses the correct IBM128 type. */
> +case MISC_BUILTIN_PACK_IF:
> + if (TARGET_LONG_DOUBLE_128 && !TARGET_IEEEQUAD)
> + {
> + icode = CODE_FOR_packtf;
> + fcode = MISC_BUILTIN_PACK_TF;
> + uns_fcode = (size_t)fcode;
> + }
> + break;
> +
> +case MISC_BUILTIN_UNPACK_IF:
> + if (TARGET_LONG_DOUBLE_128 && !TARGET_IEEEQUAD)
> + {
> + icode = CODE_FOR_unpacktf;
> + fcode = MISC_BUILTIN_UNPACK_TF;
> + uns_fcode = (size_t)fcode;
> + }
> + break;
(Space after cast, but nothing here does that I see).
Is this correct? Why should it not use the IFmode version?
> +is returned. The @code{__builtin_unpack_longdouble} function is only
> +availble if @code{long double} uses the IBM extended double
> +representation.
Typo ("available").
> +The @code{__builtin_pack_longdouble} function takes two @code{double}
> +arguments and returns a @code{long double} value that combines the two
> +arguments. The @code{__builtin_pack_longdouble} function is only
> +availble if @code{long double} uses the IBM extended double
> +representation.
And here.
Okay for trunk (and backports) if those are not mistakes or you fix them,
and maybe add some comment.
Thanks,
Segher
[PATCH] Remove redundant std::move on const object
This parameter is a reference-to-const so moving it doesn't do anything. Allocators should be cheap to copy anyway. * include/bits/shared_ptr_base.h (__shared_count): Remove redundant move of const value. Tested powerpc64le-linux, committed to trunk. commit 11b524858a52ef3f22b515c5a0320bbbae7be597 Author: Jonathan Wakely Date: Wed Jun 6 15:54:01 2018 +0100 Remove redundant std::move on const object * include/bits/shared_ptr_base.h (__shared_count): Remove redundant move of const value. diff --git a/libstdc++-v3/include/bits/shared_ptr_base.h b/libstdc++-v3/include/bits/shared_ptr_base.h index 6c5089afdda..887edbd7879 100644 --- a/libstdc++-v3/include/bits/shared_ptr_base.h +++ b/libstdc++-v3/include/bits/shared_ptr_base.h @@ -534,6 +534,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION public: using __allocator_type = __alloc_rebind<_Alloc, _Sp_counted_ptr_inplace>; + // Alloc parameter is not a reference so doesn't alias anything in __args template _Sp_counted_ptr_inplace(_Alloc __a, _Args&&... __args) : _M_impl(__a) @@ -653,8 +654,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION typename _Sp_cp_type::__allocator_type __a2(__a); auto __guard = std::__allocate_guarded(__a2); _Sp_cp_type* __mem = __guard.get(); - ::new (__mem) _Sp_cp_type(std::move(__a), - std::forward<_Args>(__args)...); + ::new (__mem) _Sp_cp_type(__a, std::forward<_Args>(__args)...); _M_pi = __mem; __guard = nullptr; }
Re: [PATCH] PR fortran/86045 -- test for P=0 in mod(, 0)
Hi Steve, The attached patch re-arranges the code in gfc_simply_mod(). This allows gfortran to test if the 2nd argument is zero. Tested on i586-*-freebsd and x86_64-*-freebsd. OK to commit? OK. Thanks for the patch! Regards Thomas
[PATCH] RISC-V: Add interrupt attribute modes.
This adds support for interrupt attributes to be used for user-level and
supervisor-level delegated interrupts by adding an argument that allows one
to specify the privilege level (aka mode). This also adds some testcases
and documentation updates for the new feature.
This was tested with riscv32-elf and riscv64-linux cross builds and checks.
There were no regressions.
Committed.
Jim
gcc/
* config/riscv/riscv.c (enum riscv_privilege_levels): New.
(struct machine_function): New field interrupt_mode.
(riscv_handle_type_attribute): New function. Add forward declaration.
(riscv_attribute_table) : Use riscv_handle_type_attribute.
(riscv_expand_epilogue): Check interrupt_mode field.
(riscv_set_current_function): Check interrupt attribute args and
set interrupt_mode field.
* config/riscv/riscv.md (UNSPECV_SRET, UNSPECV_URET): New.
(riscv_sret, riscv_uret): New.
* doc/extend.texi (RISC-V Function Attributes) : Document
new arguments to interrupt attribute.
gcc/testsuite/
* gcc.target/riscv/interrupt-5.c (sub3): Add new test.
* gcc.target/riscv/interrupt-mmode.c: New.
* gcc.target/riscv/interrupt-smode.c: New.
* gcc.target/riscv/interrupt-umode.c: New.
---
gcc/config/riscv/riscv.c | 82 ++-
gcc/config/riscv/riscv.md | 12 +++
gcc/doc/extend.texi | 11 +++
gcc/testsuite/gcc.target/riscv/interrupt-5.c | 5 ++
.../gcc.target/riscv/interrupt-mmode.c| 8 ++
.../gcc.target/riscv/interrupt-smode.c| 8 ++
.../gcc.target/riscv/interrupt-umode.c| 8 ++
7 files changed, 131 insertions(+), 3 deletions(-)
create mode 100644 gcc/testsuite/gcc.target/riscv/interrupt-mmode.c
create mode 100644 gcc/testsuite/gcc.target/riscv/interrupt-smode.c
create mode 100644 gcc/testsuite/gcc.target/riscv/interrupt-umode.c
diff --git a/gcc/config/riscv/riscv.c b/gcc/config/riscv/riscv.c
index c418dc1ec2e..2709ebdd797 100644
--- a/gcc/config/riscv/riscv.c
+++ b/gcc/config/riscv/riscv.c
@@ -122,6 +122,10 @@ struct GTY(()) riscv_frame_info {
HOST_WIDE_INT arg_pointer_offset;
};
+enum riscv_privilege_levels {
+ USER_MODE, SUPERVISOR_MODE, MACHINE_MODE
+};
+
struct GTY(()) machine_function {
/* The number of extra stack bytes taken up by register varargs.
This area is allocated by the callee at the very top of the frame. */
@@ -132,6 +136,8 @@ struct GTY(()) machine_function {
/* True if current function is an interrupt function. */
bool interrupt_handler_p;
+ /* For an interrupt handler, indicates the privilege level. */
+ enum riscv_privilege_levels interrupt_mode;
/* True if attributes on current function have been checked. */
bool attributes_checked_p;
@@ -282,6 +288,7 @@ static const struct riscv_tune_info optimize_size_tune_info
= {
};
static tree riscv_handle_fndecl_attribute (tree *, tree, tree, int, bool *);
+static tree riscv_handle_type_attribute (tree *, tree, tree, int, bool *);
/* Defining target-specific uses of __attribute__. */
static const struct attribute_spec riscv_attribute_table[] =
@@ -294,7 +301,8 @@ static const struct attribute_spec riscv_attribute_table[] =
{ "naked", 0, 0, true, false, false, false,
riscv_handle_fndecl_attribute, NULL },
/* This attribute generates prologue/epilogue for interrupt handlers. */
- { "interrupt", 0, 0, false, true, true, false, NULL, NULL },
+ { "interrupt", 0, 1, false, true, true, false,
+riscv_handle_type_attribute, NULL },
/* The last attribute spec is set to be NULL. */
{ NULL, 0, 0, false, false, false, false, NULL, NULL }
@@ -2721,6 +2729,47 @@ riscv_handle_fndecl_attribute (tree *node, tree name,
return NULL_TREE;
}
+/* Verify type based attributes. NODE is the what the attribute is being
+ applied to. NAME is the attribute name. ARGS are the attribute args.
+ FLAGS gives info about the context. NO_ADD_ATTRS should be set to true if
+ the attribute should be ignored. */
+
+static tree
+riscv_handle_type_attribute (tree *node ATTRIBUTE_UNUSED, tree name, tree args,
+int flags ATTRIBUTE_UNUSED, bool *no_add_attrs)
+{
+ /* Check for an argument. */
+ if (is_attribute_p ("interrupt", name))
+{
+ if (args)
+ {
+ tree cst = TREE_VALUE (args);
+ const char *string;
+
+ if (TREE_CODE (cst) != STRING_CST)
+ {
+ warning (OPT_Wattributes,
+ "%qE attribute requires a string argument",
+ name);
+ *no_add_attrs = true;
+ return NULL_TREE;
+ }
+
+ string = TREE_STRING_POINTER (cst);
+ if (strcmp (string, "user") && strcmp (string, "supervisor")
+ && strcmp (string, "machine"))
+ {
+ warning (OPT_Wattributes,
+
Re: [PATCH] [MSP430] Fix device name symbol defined for MSP430i series of devices
On 06/06/18 17:43, DJ Delorie wrote:
Jozef Lawrynowicz writes:
Word from TI is that the lowercase i is an exception, the rule is to have all
uppercase letters. No further msp430i devices are planned so the rules for
generating device names in this patch shouldn't need any future changes.
So a future-proof patch would TOUPPER the 430i suffixes, but the
expectation is that there will never be anything for the TOUPPER to
upper, yes?
Well that's a good point, there's no harm in calling to TOUPPER on the
characters after 'i', given that the lower case i is the exception.
I also added a test for the regular case where the whole string is made
uppercase.
Here's an updated patch, device name tests pass with this applied.
Ok to apply?
Thanks,
Jozef
>From efd996c3efa7f14fa649630b2e88decb0a48ac90 Mon Sep 17 00:00:00 2001
From: Jozef Lawrynowicz
Date: Mon, 4 Jun 2018 12:04:54 +0100
Subject: [PATCH] MSP430: Fix device name symbol defined for msp430i* devices
2018-06-04 Jozef Lawrynowicz
* gcc/config/msp430/msp430.c (msp430_mcu_name): Set the "i" in the
symbol defined for msp430i* devices to be lower case.
gcc/testsuite/gcc.target/msp430/
* msp430i-device-symbol.c: New test.
* msp430f-device-symbol.c: New test.
* msp430.h: New test header file.
---
gcc/config/msp430/msp430.c| 19 ---
gcc/testsuite/gcc.target/msp430/msp430.h | 8
.../gcc.target/msp430/msp430f-device-symbol.c | 4
.../gcc.target/msp430/msp430i-device-symbol.c | 4
4 files changed, 32 insertions(+), 3 deletions(-)
create mode 100644 gcc/testsuite/gcc.target/msp430/msp430.h
create mode 100644 gcc/testsuite/gcc.target/msp430/msp430f-device-symbol.c
create mode 100644 gcc/testsuite/gcc.target/msp430/msp430i-device-symbol.c
diff --git a/gcc/config/msp430/msp430.c b/gcc/config/msp430/msp430.c
index a8fed12..b535c0b 100644
--- a/gcc/config/msp430/msp430.c
+++ b/gcc/config/msp430/msp430.c
@@ -725,10 +725,23 @@ msp430_mcu_name (void)
if (target_mcu)
{
unsigned int i;
- static char mcu_name [64];
+ unsigned int start_upper;
+ static char mcu_name[64];
- snprintf (mcu_name, sizeof (mcu_name) - 1, "__%s__", target_mcu);
- for (i = strlen (mcu_name); i--;)
+ /* The 'i' in the device name symbol for msp430i* devices must be lower
+ case, to match the expected symbol in msp430.h. */
+ if (strncmp (target_mcu, "msp430i", 7) == 0)
+ {
+ snprintf (mcu_name, sizeof (mcu_name) - 1, "__MSP430i%s__",
+ target_mcu + 7);
+ start_upper = 9;
+ }
+ else
+ {
+ snprintf (mcu_name, sizeof (mcu_name) - 1, "__%s__", target_mcu);
+ start_upper = 0;
+ }
+ for (i = start_upper; i < strlen (mcu_name); i++)
mcu_name[i] = TOUPPER (mcu_name[i]);
return mcu_name;
}
diff --git a/gcc/testsuite/gcc.target/msp430/msp430.h b/gcc/testsuite/gcc.target/msp430/msp430.h
new file mode 100644
index 000..1dedbc0
--- /dev/null
+++ b/gcc/testsuite/gcc.target/msp430/msp430.h
@@ -0,0 +1,8 @@
+#if defined (__MSP430i2020__)
+
+#elif defined (__MSP430F5529__)
+
+#else
+#error "Device not supported by msp430.h"
+
+#endif
diff --git a/gcc/testsuite/gcc.target/msp430/msp430f-device-symbol.c b/gcc/testsuite/gcc.target/msp430/msp430f-device-symbol.c
new file mode 100644
index 000..e41cdaf
--- /dev/null
+++ b/gcc/testsuite/gcc.target/msp430/msp430f-device-symbol.c
@@ -0,0 +1,4 @@
+/* { dg-do preprocess } */
+/* { dg-skip-if "" { "*-*-*" } { "-mcpu=msp430" "-mmcu=*" "-mhwmult=32bit" "-mhwmult=16bit" } { "" } } */
+/* { dg-options "-mmcu=msp430f5529" } */
+#include "msp430.h"
diff --git a/gcc/testsuite/gcc.target/msp430/msp430i-device-symbol.c b/gcc/testsuite/gcc.target/msp430/msp430i-device-symbol.c
new file mode 100644
index 000..36a86c1
--- /dev/null
+++ b/gcc/testsuite/gcc.target/msp430/msp430i-device-symbol.c
@@ -0,0 +1,4 @@
+/* { dg-do preprocess } */
+/* { dg-skip-if "" { "*-*-*" } { "-mlarge" "-mcpu=msp430x*" "-mmcu=*" "-mhwmult=32bit" "-mhwmult=f5series" } { "" } } */
+/* { dg-options "-mmcu=msp430i2020" } */
+#include "msp430.h"
--
2.7.4
Re: [PATCH] Avoid optimizing memory references with side effects in compare-elim.c
On 6/6/18 1:23 PM, Paul Koning wrote: >> On Jun 6, 2018, at 11:53 AM, Eric Botcazou wrote: >> I would suggest using "diff -up" to generate patches with more context. > > Yes, sorry. I normally use the subversion internal diff which doesn't do > this. If you edit ~/.subversion/config and use the line: diff-extensions = -u -p that will do that for you. It's probably already in that config file and just needs to be uncommented out. Peter
Re: [PATCH] Avoid optimizing memory references with side effects in compare-elim.c
> On Jun 6, 2018, at 11:53 AM, Eric Botcazou wrote:
>
>> That simplifies the patch, which now looks like this. Ok for trunk?
>>
>> paul
>>
>> gcc/ChangeLog:
>>
>> 2018-06-05 Paul Koning
>>
>> * compare-elim.c (try_merge_compare): Don't merge compare if
>> address contains a side effect.
>> * gcc.c-torture/compile/20180605-1.c: New test case.
>
> The patch is OK, but its ChangeLog is not. :-) It does not modify one
> function but two (try_merge_compare and try_eliminate_compare). I would
> suggest using "diff -up" to generate patches with more context.
Yes, sorry. I normally use the subversion internal diff which doesn't do this.
Here is a corrected version. Ok with this change?
paul
gcc/ChangeLog:
2018-06-06 Paul Koning
* compare-elim.c (try_merge_compare): Don't merge compare if
address contains a side effect.
(try_eliminate_compare): Likewise.
* gcc.c-torture/compile/20180605-1.c: New test case.
Index: compare-elim.c
===
--- compare-elim.c (revision 261207)
+++ compare-elim.c (working copy)
@@ -690,6 +690,13 @@ try_merge_compare (struct comparison *cm
return false;
rtx src = SET_SRC (set);
+
+ /* If the source uses addressing modes with side effects, we can't
+ do the merge because we'd end up with a PARALLEL that has two
+ instances of that side effect in it. */
+ if (side_effects_p (src))
+return false;
+
rtx flags = maybe_select_cc_mode (cmp, src, CONST0_RTX (GET_MODE (src)));
if (!flags)
{
@@ -809,6 +816,12 @@ try_eliminate_compare (struct comparison
else
return false;
+ /* If the source uses addressing modes with side effects, we can't
+ do the merge because we'd end up with a PARALLEL that has two
+ instances of that side effect in it. */
+ if (side_effects_p (cmp_src))
+return false;
+
/* Determine if we ought to use a different CC_MODE here. */
flags = maybe_select_cc_mode (cmp, cmp_src, in_b);
if (flags == NULL)
Index: testsuite/gcc.c-torture/compile/20180605-1.c
===
--- testsuite/gcc.c-torture/compile/20180605-1.c(nonexistent)
+++ testsuite/gcc.c-torture/compile/20180605-1.c(working copy)
@@ -0,0 +1,9 @@
+void f (int *p, int n)
+{
+int j = 0, k;
+
+for (int i = 0; i < n; i++)
+if ((k = *p++) > 0)
+j += k;
+return j;
+}
C++ PATCH for c++/86060, c++98 ICE with range for
If we're going to allow it with a pedwarn, we shouldn't clobber the
decl with an error_mark_node.
Tested x86_64-pc-linux-gnu, applying to trunk and 8.
commit ee298d715781a806980f93348ba1b0afd62187db
Author: Jason Merrill
Date: Wed Jun 6 17:21:42 2018 +0200
PR c++/86060 - ICE on range for with -std=c++98.
* parser.c (cp_parser_init_statement): Don't clobber *decl after
pedwarn.
diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index 03aea2f1150..edb0ef8025e 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -12384,12 +12384,9 @@ cp_parser_init_statement (cp_parser *parser, tree *decl)
cp_lexer_consume_token (parser->lexer);
is_range_for = true;
if (cxx_dialect < cxx11)
- {
- pedwarn (cp_lexer_peek_token (parser->lexer)->location, 0,
- "range-based % loops only available with "
- "-std=c++11 or -std=gnu++11");
- *decl = error_mark_node;
- }
+ pedwarn (cp_lexer_peek_token (parser->lexer)->location, 0,
+ "range-based % loops only available with "
+ "-std=c++11 or -std=gnu++11");
}
else
/* The ';' is not consumed yet because we told
diff --git a/gcc/testsuite/g++.dg/cpp0x/range-for35.C b/gcc/testsuite/g++.dg/cpp0x/range-for35.C
new file mode 100644
index 000..c77a5af5a44
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/range-for35.C
@@ -0,0 +1,8 @@
+// PR c++/86060
+// { dg-options -Wpedantic }
+
+template void foo(T (&a)[8]) {
+ for (int i : a) // { dg-warning "range-based" "" { target c++98_only } }
+i;
+}
+void fn1() { foo; }
Re: [C++ PATCH] Fix up __cpp_transactional_memory value (PR c++/86068)
On Wed, Jun 6, 2018 at 3:41 PM, Jakub Jelinek wrote: > Hi! > > As mentioned in the PR, the current __cpp_transactional_memory macro > value with -fgnu-tm is clearly bogus, what will be standardized in 2105 > is unknown. > > The big question is if we should go with the value that was meant to be used > in r228462 as this patch does, or if we should go for 201505 - is > atomic_cancel implemented now? This patch is OK; atomic_cancel is not implemented. Jason
Re: C++ PATCH for c++/85977, array reference size deduction failure
OK.
On Wed, Jun 6, 2018 at 7:28 PM, Marek Polacek wrote:
> On Wed, Jun 06, 2018 at 06:22:16PM +0200, Jason Merrill wrote:
>> Right, you want to test conversion to the element type, not the array or
>> init list type.
>
> Indeed. Please tell me this is the right approach :).
>
> Bootstrapped/regtested on x86_64-linux, ok for trunk?
>
> 2018-06-06 Marek Polacek
>
> PR c++/85977
> * pt.c (unify): If ELTTYPE has no deducible template parms, skip
> deduction from the list elements.
> (type_unification_real): Check convertibility of list elements.
>
> * g++.dg/cpp0x/initlist102.C: New test.
> * g++.dg/cpp0x/initlist103.C: New test.
> * g++.dg/cpp0x/initlist104.C: New test.
>
> diff --git gcc/cp/pt.c gcc/cp/pt.c
> index 448cd69b722..d8880eb138d 100644
> --- gcc/cp/pt.c
> +++ gcc/cp/pt.c
> @@ -20370,6 +20370,22 @@ type_unification_real (tree tparms,
> if (check_non_deducible_conversion (parm, arg, strict, flags,
> explain_p))
> return 1;
> +
> + if (BRACE_ENCLOSED_INITIALIZER_P (arg)
> + && (TREE_CODE (parm) == ARRAY_TYPE || is_std_init_list
> (parm)))
> + {
> + tree elt, elttype;
> + unsigned int i;
> +
> + if (TREE_CODE (parm) == ARRAY_TYPE)
> + elttype = TREE_TYPE (parm);
> + else
> + elttype = TREE_VEC_ELT (CLASSTYPE_TI_ARGS (parm), 0);
> + FOR_EACH_CONSTRUCTOR_VALUE (CONSTRUCTOR_ELTS (arg), i, elt)
> + if (check_non_deducible_conversion (elttype, elt, strict,
> + flags, explain_p))
> + return 1;
> + }
> }
>
>/* Now substitute into the default template arguments. */
> @@ -21404,24 +21420,30 @@ unify (tree tparms, tree targs, tree parm, tree
> arg, int strict,
> return unify_success (explain_p);
> }
>
> - FOR_EACH_CONSTRUCTOR_VALUE (CONSTRUCTOR_ELTS (arg), i, elt)
> - {
> - int elt_strict = strict;
> + if (strict != DEDUCE_EXACT
> + && TYPE_P (elttype)
> + && !uses_deducible_template_parms (elttype))
> + /* If ELTTYPE has no deducible template parms, skip deduction from
> + the list elements. */;
> + else
> + FOR_EACH_CONSTRUCTOR_VALUE (CONSTRUCTOR_ELTS (arg), i, elt)
> + {
> + int elt_strict = strict;
>
> - if (elt == error_mark_node)
> - return unify_invalid (explain_p);
> + if (elt == error_mark_node)
> + return unify_invalid (explain_p);
>
> - if (!BRACE_ENCLOSED_INITIALIZER_P (elt))
> - {
> - tree type = TREE_TYPE (elt);
> - if (type == error_mark_node)
> - return unify_invalid (explain_p);
> - /* It should only be possible to get here for a call. */
> - gcc_assert (elt_strict & UNIFY_ALLOW_OUTER_LEVEL);
> - elt_strict |= maybe_adjust_types_for_deduction
> - (DEDUCE_CALL, &elttype, &type, elt);
> - elt = type;
> - }
> + if (!BRACE_ENCLOSED_INITIALIZER_P (elt))
> + {
> + tree type = TREE_TYPE (elt);
> + if (type == error_mark_node)
> + return unify_invalid (explain_p);
> + /* It should only be possible to get here for a call. */
> + gcc_assert (elt_strict & UNIFY_ALLOW_OUTER_LEVEL);
> + elt_strict |= maybe_adjust_types_for_deduction
> + (DEDUCE_CALL, &elttype, &type, elt);
> + elt = type;
> + }
>
> RECUR_AND_CHECK_FAILURE (tparms, targs, elttype, elt, elt_strict,
>explain_p);
> diff --git gcc/testsuite/g++.dg/cpp0x/initlist102.C
> gcc/testsuite/g++.dg/cpp0x/initlist102.C
> index e69de29bb2d..e114866292f 100644
> --- gcc/testsuite/g++.dg/cpp0x/initlist102.C
> +++ gcc/testsuite/g++.dg/cpp0x/initlist102.C
> @@ -0,0 +1,39 @@
> +// PR c++/85977, Incorrect handling of array reference size deduction
> +// { dg-do compile { target c++11 } }
> +
> +template
> +void fn1 (const char (&)[N]) { static_assert (N == 3, "fn1");}
> +
> +template
> +void fn2 (const short (&)[N]) { static_assert (N == 3, "fn2");}
> +
> +template
> +void fn3 (const int (&)[N]) { static_assert (N == 3, "fn2");}
> +
> +template
> +void fn4 (const long (&)[N]) { static_assert (N == 3, "fn4");}
> +
> +template
> +void fn5 (const unsigned char (&)[N]) { static_assert (N == 3, "fn5");}
> +
> +template
> +void fn6 (const unsigned short (&)[N]) { static_assert (N == 3, "fn6");}
> +
> +template
> +void fn7 (const unsigned int (&)[N]) { static_assert (N == 3, "fn7");}
> +
> +template
> +void fn8 (const unsigned int (&)[N]) { static_assert (N == 3, "fn8");}
> +
> +void
> +bar ()
> +{
> + fn1 ({1,
[PATCH] Document usage of line number 0 in dg-{warning,error,message,bogus} directives
For the dg-{warning,error,message,bogus} directives, a value of 0 for the line
argument can be passed to specify that the message is not associated with any
line. This patch documents that in the Directives section of the
documentation.
Ok for trunk?
>From d08160770abef420b6699f6bd2c30a055bd10350 Mon Sep 17 00:00:00 2001
From: Jozef Lawrynowicz
Date: Wed, 6 Jun 2018 18:20:56 +0100
Subject: [PATCH] Document usage of line number 0 in
dg-{warning,error,message,bogus} directives
2018-06-06 Jozef Lawrynowicz
* gcc/doc/sourcebuild.texi: Document usage of line number 0 in verify
compiler messages directives.
---
gcc/doc/sourcebuild.texi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/gcc/doc/sourcebuild.texi b/gcc/doc/sourcebuild.texi
index 09c0053..d52183d 100644
--- a/gcc/doc/sourcebuild.texi
+++ b/gcc/doc/sourcebuild.texi
@@ -1177,6 +1177,8 @@ conditions (which are the same as for @code{dg-skip-if}) are met.
@end table
@subsubsection Verify compiler messages
+Where @var{line} is an accepted argument for these commands, a value of @samp{0}
+can be used if there is no line associated with the message.
@table @code
@item @{ dg-error @var{regexp} [@var{comment} [@{ target/xfail @var{selector} @} [@var{line}] ]] @}
--
2.7.4
Re: [PATCH v2, #2 of 3], Add weak references to bridge old/new PowerPC ieee 128-bit name mangling
Hi Mike,
On Tue, Jun 05, 2018 at 06:47:52PM -0400, Michael Meissner wrote:
> With this fix, the compiler no longer raises an internal error if you use
> explicit overloading of __ibm128 and long double. Instead it generates the
> expected error:
>
> foo01.C:33:15: error: 'bool foo::iszero(long double)' cannot be overloaded
> with 'bool foo::iszero(long double)'
>inline bool iszero (__ibm128 i128) { return i128 == 0.0; }
>^~
> foo01.C:32:15: note: previous declaration 'bool foo::iszero(long double)'
>inline bool iszero (long double ld) { return ld == 0.0; }
Excellent.
> --- gcc/config/rs6000/rs6000.c(revision 261175)
> +++ gcc/config/rs6000/rs6000.c(working copy)
> @@ -16383,14 +16383,21 @@ rs6000_init_builtins (void)
> __ieee128. */
>if (TARGET_FLOAT128_TYPE)
> {
> - ibm128_float_type_node = make_node (REAL_TYPE);
> - TYPE_PRECISION (ibm128_float_type_node) = 128;
> - SET_TYPE_MODE (ibm128_float_type_node, IFmode);
> - layout_type (ibm128_float_type_node);
> + if (TARGET_IEEEQUAD || !TARGET_LONG_DOUBLE_128)
> + {
> + ibm128_float_type_node = make_node (REAL_TYPE);
> + TYPE_PRECISION (ibm128_float_type_node) = 128;
> + SET_TYPE_MODE (ibm128_float_type_node, IFmode);
> + layout_type (ibm128_float_type_node);
> + }
> + else
> + ibm128_float_type_node = long_double_type_node;
> +
>lang_hooks.types.register_builtin_type (ibm128_float_type_node,
> "__ibm128");
>
> - ieee128_float_type_node = float128_type_node;
> + ieee128_float_type_node
> + = TARGET_IEEEQUAD ? long_double_type_node : float128_type_node;
>lang_hooks.types.register_builtin_type (ieee128_float_type_node,
> "__ieee128");
> }
Should we use float128_type_node at all anymore, btw?
Okay for trunk, and later for 8, but please test on BE and p9.
Segher
Re: C++ PATCH for c++/85977, array reference size deduction failure
On Wed, Jun 06, 2018 at 06:22:16PM +0200, Jason Merrill wrote:
> Right, you want to test conversion to the element type, not the array or
> init list type.
Indeed. Please tell me this is the right approach :).
Bootstrapped/regtested on x86_64-linux, ok for trunk?
2018-06-06 Marek Polacek
PR c++/85977
* pt.c (unify): If ELTTYPE has no deducible template parms, skip
deduction from the list elements.
(type_unification_real): Check convertibility of list elements.
* g++.dg/cpp0x/initlist102.C: New test.
* g++.dg/cpp0x/initlist103.C: New test.
* g++.dg/cpp0x/initlist104.C: New test.
diff --git gcc/cp/pt.c gcc/cp/pt.c
index 448cd69b722..d8880eb138d 100644
--- gcc/cp/pt.c
+++ gcc/cp/pt.c
@@ -20370,6 +20370,22 @@ type_unification_real (tree tparms,
if (check_non_deducible_conversion (parm, arg, strict, flags,
explain_p))
return 1;
+
+ if (BRACE_ENCLOSED_INITIALIZER_P (arg)
+ && (TREE_CODE (parm) == ARRAY_TYPE || is_std_init_list (parm)))
+ {
+ tree elt, elttype;
+ unsigned int i;
+
+ if (TREE_CODE (parm) == ARRAY_TYPE)
+ elttype = TREE_TYPE (parm);
+ else
+ elttype = TREE_VEC_ELT (CLASSTYPE_TI_ARGS (parm), 0);
+ FOR_EACH_CONSTRUCTOR_VALUE (CONSTRUCTOR_ELTS (arg), i, elt)
+ if (check_non_deducible_conversion (elttype, elt, strict,
+ flags, explain_p))
+ return 1;
+ }
}
/* Now substitute into the default template arguments. */
@@ -21404,24 +21420,30 @@ unify (tree tparms, tree targs, tree parm, tree arg,
int strict,
return unify_success (explain_p);
}
- FOR_EACH_CONSTRUCTOR_VALUE (CONSTRUCTOR_ELTS (arg), i, elt)
- {
- int elt_strict = strict;
+ if (strict != DEDUCE_EXACT
+ && TYPE_P (elttype)
+ && !uses_deducible_template_parms (elttype))
+ /* If ELTTYPE has no deducible template parms, skip deduction from
+ the list elements. */;
+ else
+ FOR_EACH_CONSTRUCTOR_VALUE (CONSTRUCTOR_ELTS (arg), i, elt)
+ {
+ int elt_strict = strict;
- if (elt == error_mark_node)
- return unify_invalid (explain_p);
+ if (elt == error_mark_node)
+ return unify_invalid (explain_p);
- if (!BRACE_ENCLOSED_INITIALIZER_P (elt))
- {
- tree type = TREE_TYPE (elt);
- if (type == error_mark_node)
- return unify_invalid (explain_p);
- /* It should only be possible to get here for a call. */
- gcc_assert (elt_strict & UNIFY_ALLOW_OUTER_LEVEL);
- elt_strict |= maybe_adjust_types_for_deduction
- (DEDUCE_CALL, &elttype, &type, elt);
- elt = type;
- }
+ if (!BRACE_ENCLOSED_INITIALIZER_P (elt))
+ {
+ tree type = TREE_TYPE (elt);
+ if (type == error_mark_node)
+ return unify_invalid (explain_p);
+ /* It should only be possible to get here for a call. */
+ gcc_assert (elt_strict & UNIFY_ALLOW_OUTER_LEVEL);
+ elt_strict |= maybe_adjust_types_for_deduction
+ (DEDUCE_CALL, &elttype, &type, elt);
+ elt = type;
+ }
RECUR_AND_CHECK_FAILURE (tparms, targs, elttype, elt, elt_strict,
explain_p);
diff --git gcc/testsuite/g++.dg/cpp0x/initlist102.C
gcc/testsuite/g++.dg/cpp0x/initlist102.C
index e69de29bb2d..e114866292f 100644
--- gcc/testsuite/g++.dg/cpp0x/initlist102.C
+++ gcc/testsuite/g++.dg/cpp0x/initlist102.C
@@ -0,0 +1,39 @@
+// PR c++/85977, Incorrect handling of array reference size deduction
+// { dg-do compile { target c++11 } }
+
+template
+void fn1 (const char (&)[N]) { static_assert (N == 3, "fn1");}
+
+template
+void fn2 (const short (&)[N]) { static_assert (N == 3, "fn2");}
+
+template
+void fn3 (const int (&)[N]) { static_assert (N == 3, "fn2");}
+
+template
+void fn4 (const long (&)[N]) { static_assert (N == 3, "fn4");}
+
+template
+void fn5 (const unsigned char (&)[N]) { static_assert (N == 3, "fn5");}
+
+template
+void fn6 (const unsigned short (&)[N]) { static_assert (N == 3, "fn6");}
+
+template
+void fn7 (const unsigned int (&)[N]) { static_assert (N == 3, "fn7");}
+
+template
+void fn8 (const unsigned int (&)[N]) { static_assert (N == 3, "fn8");}
+
+void
+bar ()
+{
+ fn1 ({1, 2, 3});
+ fn2 ({1, 2, 3});
+ fn3 ({1, 2, 3});
+ fn4 ({1, 2, 3});
+ fn5 ({1, 2, 3});
+ fn6 ({1, 2, 3});
+ fn7 ({1, 2, 3});
+ fn8 ({1, 2, 3});
+}
diff --git gcc/testsuite/g++.dg/cpp0x/initlist103.C
gcc/testsuite/g++.dg/cpp0x/initlist103.C
index e69de29bb2d..0c1923c6ab0 100644
--- gcc/testsuite/g++.d
Re: libgcov-driver-system bootstrap failure
On 6/5/18, David Edelsohn wrote: > Martin, > > With your recent patch, I receive the following failure building > libgcov-driver-system.c > > In file included from > /nasfarm/edelsohn/src/src/gcc/../libgcc/libgcov-driver.c:322:0: > /nasfarm/edelsohn/src/src/gcc/../libgcc/libgcov-driver-system.c: In > function 'char* replace_filename_variables(char*)': > /nasfarm/edelsohn/src/src/gcc/../libgcc/libgcov-driver-system.c:193:61: > error: 'mempcpy' was not declared in this scope > buffer_ptr = (char *)mempcpy (buffer_ptr, filename, start); > > mempcpy is a GLIBC extension and not defined in POSIX. There is no > libiberty implementation. Please avoid use of GLIBC-specific > functions. > > Thanks, David > About there being no libiberty implementation, there is a gnulib one: https://www.gnu.org/software/gnulib/manual/html_node/mempcpy.html Thus, if the "replace libiberty with gnulib" project is ever picked up again, it'd be easy to have mempcpy available thru it.
[PATCH][Aarch64] v2: Arithmetic overflow tests [Patch 4/4]
This is a respin of a AArch64 patch that adds support for builtin arithmetic overflow operations. This update separates the patch into multiple pieces and addresses comments made by Richard Earnshaw here: https://gcc.gnu.org/ml/gcc-patches/2017-07/msg00249.html Original patch and motivation for patch here: https://gcc.gnu.org/ml/gcc-patches/2017-05/msg01512.html This patch contains new test cases to verify that the new overflow patterns are being utilized. Bootstrapped and tested on aarch64-linux-gnu. Okay for trunk? 2018-05-31 Michael Collison Richard Henderson * gcc.target/aarch64/builtin_sadd_128.c: New testcase. * gcc.target/aarch64/builtin_saddl.c: New testcase. * gcc.target/aarch64/builtin_saddll.c: New testcase. * gcc.target/aarch64/builtin_uadd_128.c: New testcase. * gcc.target/aarch64/builtin_uaddl.c: New testcase. * gcc.target/aarch64/builtin_uaddll.c: New testcase. * gcc.target/aarch64/builtin_ssub_128.c: New testcase. * gcc.target/aarch64/builtin_ssubl.c: New testcase. * gcc.target/aarch64/builtin_ssubll.c: New testcase. * gcc.target/aarch64/builtin_usub_128.c: New testcase. * gcc.target/aarch64/builtin_usubl.c: New testcase. * gcc.target/aarch64/builtin_usubll.c: New testcase. gnutools-6308-pt4.patch Description: gnutools-6308-pt4.patch
[PATCH][Aarch64] v2: Arithmetic overflow subv patterns [Patch 3/4]
This is a respin of a AArch64 patch that adds support for builtin arithmetic overflow operations. This update separates the patch into multiple pieces and addresses comments made by Richard Earnshaw here: https://gcc.gnu.org/ml/gcc-patches/2017-07/msg00249.html Original patch and motivation for patch here: https://gcc.gnu.org/ml/gcc-patches/2017-05/msg01512.html This patch contains new patterns for subv overflow patterns. Bootstrapped and tested on aarch64-linux-gnu. Okay for trunk? 2018-05-31 Michael Collison Richard Henderson * config/aarch64/aarch64.md (subv4, usubv4): New patterns. (subti): Handle op1 zero. (subvti4, usub4ti4): New. (*sub3_compare1_imm): New. (sub3_carryinCV): New. (*sub3_carryinCV_z1_z2, *sub3_carryinCV_z1): New. (*sub3_carryinCV_z2, *sub3_carryinCV): New. gnutools-6308-pt3.patch Description: gnutools-6308-pt3.patch
[PATCH][Aarch64] v2: Arithmetic overflow addv patterns [Patch 2/4]
This is a respin of a AArch64 patch that adds support for builtin arithmetic overflow operations. This update separates the patch into multiple pieces and addresses comments made by Richard Earnshaw here: https://gcc.gnu.org/ml/gcc-patches/2017-07/msg00249.html Original patch and motivation for patch here: https://gcc.gnu.org/ml/gcc-patches/2017-05/msg01512.html This patch contains new patterns for addv overflow patterns. Bootstrapped and tested on aarch64-linux-gnu. Okay for trunk? 2018-05-31 Michael Collison Richard Henderson * config/aarch64/aarch64.md: (addv4, uaddv4): New. (addti3): Create simpler code if low part is already known to be 0. (addvti4, uaddvti4): New. (*add3_compareC_cconly_imm): New. (*add3_compareC_cconly): New. (*add3_compareC_imm): New. (*add3_compareC): Rename from add3_compare1; do not handle constants within this pattern.. (*add3_compareV_cconly_imm): New. (*add3_compareV_cconly): New. (*add3_compareV_imm): New. (add3_compareV): New. (add3_carryinC, add3_carryinV): New. (*add3_carryinC_zero, *add3_carryinV_zero): New. (*add3_carryinC, *add3_carryinV): New. ((*add3_compareC_cconly_imm): Replace 'ne' operator with 'comparison' operator. (*add3_compareV_cconly_imm): Ditto. (*add3_compareV_cconly): Ditto. (*add3_compareV_imm): Ditto. (add3_compareV): Ditto. (add3_carryinC): Ditto. (*add3_carryinC_zero): Ditto. (*add3_carryinC): Ditto. (add3_carryinV): Ditto. (*add3_carryinV_zero): Ditto. (*add3_carryinV): Ditto. gnutools-6308-pt2.patch Description: gnutools-6308-pt2.patch
[PATCH][Aarch64] v2: Arithmetic overflow common functions [Patch 1/4]
This is a respin of a AArch64 patch that adds support for builtin arithmetic overflow operations. This update separates the patch into multiple pieces and addresses comments made by Richard Earnshaw here: https://gcc.gnu.org/ml/gcc-patches/2017-07/msg00249.html Original patch and motivation for patch here: https://gcc.gnu.org/ml/gcc-patches/2017-05/msg01512.html This patch primarily contains common functions in aarch64.c for generating TImode scratch registers, and common rtl functions utilized by the overflow patterns in aarch64.md. In addition a new mode representing overflow CC_Vmode is introduced. Bootstrapped and tested on aarch64-linux-gnu. Okay for trunk? 2018-05-31 Michael Collison Richard Henderson * config/aarch64/aarch64-modes.def (CC_V): New. * config/aarch64/aarch64-protos.h (aarch64_add_128bit_scratch_regs): Declare (aarch64_subv_128bit_scratch_regs): Declare. (aarch64_expand_subvti): Declare. (aarch64_gen_unlikely_cbranch): Declare * config/aarch64/aarch64.c (aarch64_select_cc_mode): Test for signed overflow using CC_Vmode. (aarch64_get_condition_code_1): Handle CC_Vmode. (aarch64_gen_unlikely_cbranch): New function. (aarch64_add_128bit_scratch_regs): New function. (aarch64_subv_128bit_scratch_regs): New function. (aarch64_expand_subvti): New function. gnutools-6308-pt1.patch Description: gnutools-6308-pt1.patch
[PATCH, rs6000] Split up builtins-3.c tests
GCC Maintainers:
The builtins-3.c test fails on Power 6 since -mvsx is not enabled with
the -maltivec option.
The following patch moves the tests from builtins-3.c that require the
-mvsx" command line option to the new test file builtins-4.c. The
tests that are left in file builtins-3.c require just the -maltivec
option.
The patch was retested on:
powerpc64le-unknown-linux-gnu (Power 8 LE)
powerpc64le-unknown-linux-gnu (Power 9 LE)
powerpc64-unknown-linux-gnu (Power 8 BE)
With no regressions.
The following manual tests were also run
make -k check-gcc RUNTESTFLAGS="-mcpu=power6 --target_board=unix'{-m64,-m32}'
powerpc.exp=builtins-3.c"
make -k check-gcc RUNTESTFLAGS="-mcpu=power6 --target_board=unix'{-m64,-m32}'
powerpc.exp=builtins-4.c"
to verify the tests work on Power 6.
Please let me know if the patch looks OK for GCC mainline.
Carl Love
-
gcc/testsuite/ChangeLog:
2018-06-05 Carl Love
* gcc.target/powerpc/builtins-3.c: Move tests requiring -mvsx
to builtins-4.c.
* gcc.target/powerpc/builtins-4.c: New test file for tests
that need -mvsx.
---
gcc/testsuite/gcc.target/powerpc/builtins-3.c | 164 +
gcc/testsuite/gcc.target/powerpc/builtins-4.c | 167 ++
2 files changed, 172 insertions(+), 159 deletions(-)
create mode 100644 gcc/testsuite/gcc.target/powerpc/builtins-4.c
diff --git a/gcc/testsuite/gcc.target/powerpc/builtins-3.c
b/gcc/testsuite/gcc.target/powerpc/builtins-3.c
index f0edd12..fc4fd60 100644
--- a/gcc/testsuite/gcc.target/powerpc/builtins-3.c
+++ b/gcc/testsuite/gcc.target/powerpc/builtins-3.c
@@ -22,12 +22,6 @@ test_eq_int (vector bool int x, vector bool int y)
return vec_cmpeq (x, y);
}
-vector double
-test_shift_left_double (vector double x, vector double y)
-{
- return vec_sld (x, y, /* shift_by */ 10);
-}
-
vector signed char
test_nabs_char (vector signed char x)
{
@@ -46,18 +40,6 @@ test_nabs_int (vector int x)
return vec_nabs (x);
}
-vector float
-test_nabs_float (vector float x)
-{
- return vec_nabs (x);
-}
-
-vector double
-test_nabs_double (vector double x)
-{
- return vec_nabs (x);
-}
-
vector signed char
test_sll_vsc_vsc_vsuc (vector signed char x, vector unsigned char y)
{
@@ -82,40 +64,6 @@ test_sll_vui_vui_vuc (vector unsigned int x, vector unsigned
char y)
return vec_sll (x, y);
}
-vector signed int long long
-test_sll_vsill_vsill_vuc (vector signed long long int x,
- vector unsigned char y)
-{
- return vec_sll (x, y);
-}
-
-vector unsigned int long long
-test_sll_vuill_vuill_vuc (vector unsigned long long int x,
- vector unsigned char y)
-{
- return vec_sll (x, y);
-}
-
-vector bool long long
-test_sll_vbll_vbll_vuc (vector bool long long x,
- vector unsigned char y)
-{
- return vec_sll (x, y);
-}
-
-vector bool long long
-test_sll_vbll_vbll_vull (vector bool long long x,
- vector unsigned long long y)
-{
- return vec_sll (x, y);
-}
-
-vector bool long long
-test_sll_vbll_vbll_vus (vector bool long long x,
- vector unsigned short y)
-{
- return vec_sll (x, y);
-}
vector pixel
test_sll_vp_vp_vuc (vector pixel x, vector unsigned char y)
{
@@ -182,30 +130,6 @@ test_slo_vui_vui_vuc (vector unsigned int x, vector
unsigned char y)
return vec_slo (x, y);
}
-vector signed long long
-test_slo_vsll_slo_vsll_vsc (vector signed long long x, vector signed char y)
-{
- return vec_slo (x, y);
-}
-
-vector signed long long
-test_slo_vsll_slo_vsll_vuc (vector signed long long x, vector unsigned char y)
-{
- return vec_slo (x, y);
-}
-
-vector unsigned long long
-test_slo_vull_slo_vull_vsc (vector unsigned long long x, vector signed char y)
-{
- return vec_slo (x, y);
-}
-
-vector unsigned long long
-test_slo_vull_slo_vull_vuc (vector unsigned long long x,
- vector unsigned char y)
-{
- return vec_slo (x, y);
-}
vector pixel
test_slo_vp_vp_vsc (vector pixel int x, vector signed char y)
@@ -255,57 +179,6 @@ test_slo_vf_vf_vuc (vector float x, vector unsigned char y)
return vec_slo (x, y);
}
-vector signed char
-test_vsc_sldw_vsc_vsc (vector signed char x, vector signed char y)
-{
- return vec_sldw (x, y, 1);
-}
-
-vector unsigned char
-test_vuc_sldw_vuc_vuc (vector unsigned char x, vector unsigned char y)
-{
- return vec_sldw (x, y, 3);
-}
-
-vector signed short int
-test_vssi_sldw_vssi_vssi (vector signed short int x,
- vector signed short int y)
-{
- return vec_sldw (x, y, 1);
-}
-
-vector unsigned short int
-test_vusi_sldw_vusi_vusi (vector unsigned short int x,
- vector unsigned short int y)
-{
- return vec_sldw (x, y, 3);
-}
-
-vector signed
Re: [PATCH] [MSP430] Fix device name symbol defined for MSP430i series of devices
Jozef Lawrynowicz writes: > Word from TI is that the lowercase i is an exception, the rule is to have all > uppercase letters. No further msp430i devices are planned so the rules for > generating device names in this patch shouldn't need any future changes. So a future-proof patch would TOUPPER the 430i suffixes, but the expectation is that there will never be anything for the TOUPPER to upper, yes? If so, no further objections from me. It can be tweaked later if they change their minds.
Re: [PATCH v2, #1 of 3], Add weak references to bridge old/new PowerPC ieee 128-bit name mangling
Hi! On Tue, Jun 05, 2018 at 02:02:05PM -0400, Michael Meissner wrote: > I tested this on a little endian power8 system running Linux. There were no > regressions. Can I install this in the trunk and eventually back port it to > GCC 8.2? Please test on a BE system as well? And maybe on a p9? I don't expect problems, but we should know. (No need to test this patch, we'll find out after you commit in the unlikely case there are problems; buy in the future, please do). > --- gcc/config/rs6000/rs6000.c(revision 261170) > +++ gcc/config/rs6000/rs6000.c(working copy) > @@ -200,6 +200,17 @@ int dot_symbols; > of this machine mode. */ > scalar_int_mode rs6000_pmode; > > +/* Note whether IEEE 128-bit floating point was passed or returned, either as > + the __float128/_Float128 explicit type, or when long double is IEEE > 128-bit I think you mean __ieee128? There is no __float128 type anymore. > +static bool rs6000_passes_ieee128; > + > +/* Generate the manged name (i.e. U10__float128) used in GCC 8.1, and not the > + name used in current releases (i.e. u9__ieee128). */ > +static bool ieee128_mangling_gcc_8_1; It's a manged name, sure, but you mean mangled :-) Okay for trunk and backports. Thanks! Segher
Re: [C++ PATCH] Speed up inplace_merge algorithm & fix inefficient logic(PR c++/83938)
Hi
I review and rework this proposal. I noticed that the same idea to
limit buffer size within inplace_merge also apply to stable_sort.
I also change the decision when buffer is too small to consider the
buffer size rather than going through successive cuts of the original
ranges. This way we won't cut the range more than necessary. Note that
if you prefer this second part could be committed seperatly.
PR libstdc++/83938
* include/bits/stl_algo.h:
(__stable_partition_adaptive): When buffer to small cut range using
buffer size.
(__inplace_merge): Take temporary buffer length from smallest range.
(__merge_adaptive): When buffer too small consider smallest range first
and cut based on buffer size.
(__stable_sort_adaptive): When buffer too small cut based on buffer
size.
(__stable_sort): Limit temporary buffer length.
* include/bits/stl_tempbuf.h (get_temporary_buffer): Change function
to reduce requested buffer length on allocation failure.
Tested under Linux x86_64.
Ok to commit ?
François
On 25/01/2018 23:37, chang jc wrote:
Hi:
1. The __len = (__len + 1) / 2; is as you suggested, need to modify as
__len = (__len == 1) ? 0 : ((__len + 1) / 2);
2. The coding gain has been shown PR c++/83938; I re-post here
21
20
19
18
17
16
0.471136
0.625695
0.767262
0.907461
1.04838
1.19508
0.340845
0.48651
0.639139
0.770133
0.898454
1.04632
it means when Merge [0, 4325376, 16777216); A is a sorted integer with
4325376 & B with 12451840 elements, total with 16M integers
The proposed method has the speed up under given buffer size =, ex
2^16, 2^17, ... 2^21 in unit of sizeof(int), for example, 2^16 means
given sizof(int)*64K bytes.
3. As your suggestion, _TmpBuf __buf should be rewrite.
4. It represents a fact that the intuitive idea to split from larger
part is wrong.
For example, if you have an input sorted array A & B, A has 8 integers
& B has 24 integers. Given tmp buffer whose capacity = 4 integers.
Current it tries to split from B, right?
Then we have:
A1 | A2 B1 | B2
B1 & B2 has 12 integers each, right?
Current algorithm selects pivot as 13th integer from B, right?
If the corresponding upper bound of A is 6th integer.
Then it split in
A1 = 5 | A2 = 3 | B1 = 12 | B2 = 12
After rotate, we have two arrays to merge
[A1 = 5 | B1 = 12] & [A2 = 3 | B2 = 12]
Great, [A2 = 3 | B2 = 12] can use tmp buffer to merge.
Sadly, [A1 = 5 | B1 = 12] CANNOT.
So we do rotate again, split & merge the two split arrays from [A1 = 5
| B1 = 12] again.
But wait, if we always split from the smaller one instead of larger one.
After rotate, it promises two split arrays both contain ceiling[small/2].
Since tmp buffer also allocate by starting from sizeof(small) &
recursively downgrade by ceiling[small/2^(# of fail allocate)].
It means the allocated tmp buffer promises to be sufficient at the
level of (# of fail allocate).
Instead, you can see if split from large at level (# of fail allocate)
several split array still CANNOT use tmp buffer to do buffered merge.
As you know, buffered merge is far speed then (split, rotate, and
merge two sub-arrays) (PR c++/83938 gives the profiling figures),
the way should provide speedup.
Thanks.
On 24/01/2018 18:23, François Dumont wrote:
Hi
It sounds like a very sensitive change to make but nothing worth figures.
Do you have any bench showing the importance of the gain ?
At least the memory usage optimization is obvious.
On 19/01/2018 10:43, chang jc wrote:
Current std::inplace_merge() suffers from performance issue by inefficient
logic under limited memory,
It leads to performance downgrade.
Please help to review it.
Index: include/bits/stl_algo.h
===
--- include/bits/stl_algo.h(revision 256871)
+++ include/bits/stl_algo.h(working copy)
@@ -2437,7 +2437,7 @@
_BidirectionalIterator __second_cut = __middle;
_Distance __len11 = 0;
_Distance __len22 = 0;
- if (__len1 > __len2)
+ if (__len1 < __len2)
{
__len11 = __len1 / 2;
std::advance(__first_cut, __len11);
@@ -2539,9 +2539,15 @@
const _DistanceType __len1 = std::distance(__first, __middle);
const _DistanceType __len2 = std::distance(__middle, __last);
+
typedef _Temporary_buffer<_BidirectionalIterator, _ValueType>
_TmpBuf;
- _TmpBuf __buf(__first, __last);
-
+ _BidirectionalIterator __start, __end;
+ if (__len1 < __len2) {
+__start = __first; __end = __middle;
+ } else {
+__start = __middle; __end = __last;
+ }
+ _TmpBuf __buf(__start, ___end);
Note another optimization, we could introduce a _Temporary_buffer<> constructor
in order to write:
_TmpBuf __buf(std::min(__len1, __len2), __first);
So that std::distance do not need to be called again.
if (
Re: C++ PATCH for c++/85977, array reference size deduction failure
On Wed, Jun 6, 2018, 4:43 PM Marek Polacek wrote:
> On Fri, Jun 01, 2018 at 12:39:08PM -0400, Jason Merrill wrote:
> > Yes, we still need to do deduction on the array bound, so we can't
> > return immediately. We just want to avoid the
> >
> > FOR_EACH_CONSTRUCTOR_VALUE (CONSTRUCTOR_ELTS (arg), i, elt)
> >
> > loop.
>
> Got it. But then there's this part:
>
> > And then we want to check convertibility of the elements in
> > type_unification_real, when we check convertibility of other function
> > parameters that don't involve template parameters:
> >
> > /* DR 1391: All parameters have args, now check non-dependent
> > parms for convertibility. */
>
> which I hoped would be achieved by this:
>
> @@ -20370,6 +20370,16 @@ type_unification_real (tree tparms,
> if (check_non_deducible_conversion (parm, arg, strict, flags,
> explain_p))
> return 1;
> +
> + if (BRACE_ENCLOSED_INITIALIZER_P (arg))
> + {
> + tree elt;
> + unsigned int i;
> + FOR_EACH_CONSTRUCTOR_VALUE (CONSTRUCTOR_ELTS (arg), i, elt)
> + if (check_non_deducible_conversion (parm, elt, strict, flags,
> + explain_p))
> + return 1;
> + }
> }
>
>/* Now substitute into the default template arguments. */
>
>
> but that breaks e.g. initlist34.C, because ARG is {0} and PARM is
> struct initializer_list, and checking whether we can convert 0 to
> struct initializer_list doesn't work, so we return 1.
Right, you want to test conversion to the element type, not the array or
init list type.
I've probably
> misunderstood what you wanted me to do here. For the attached testcases
> we'll never reach that code anyway, because PARM depends on a template
> parameter.
>
> 2018-06-05 Marek Polacek
>
> PR c++/85977
> * pt.c (unify): If ELTTYPE has no deducible template parms, skip
> deduction from the list elements.
>
> * g++.dg/cpp0x/initlist102.C: New test.
> * g++.dg/cpp0x/initlist103.C: New test.
> * g++.dg/cpp0x/initlist104.C: New test.
>
> diff --git gcc/cp/pt.c gcc/cp/pt.c
> index aad68a32643..19c542b76d5 100644
> --- gcc/cp/pt.c
> +++ gcc/cp/pt.c
> @@ -21404,24 +21415,30 @@ unify (tree tparms, tree targs, tree parm, tree
> arg, int strict,
> return unify_success (explain_p);
> }
>
> - FOR_EACH_CONSTRUCTOR_VALUE (CONSTRUCTOR_ELTS (arg), i, elt)
> - {
> - int elt_strict = strict;
> + if (strict != DEDUCE_EXACT
> + && TYPE_P (elttype)
> + && !uses_deducible_template_parms (elttype))
> + /* If ELTTYPE has no deducible template parms, skip deduction from
> + the list elements. */;
> + else
> + FOR_EACH_CONSTRUCTOR_VALUE (CONSTRUCTOR_ELTS (arg), i, elt)
> + {
> + int elt_strict = strict;
>
> - if (elt == error_mark_node)
> - return unify_invalid (explain_p);
> + if (elt == error_mark_node)
> + return unify_invalid (explain_p);
>
> - if (!BRACE_ENCLOSED_INITIALIZER_P (elt))
> - {
> - tree type = TREE_TYPE (elt);
> - if (type == error_mark_node)
> - return unify_invalid (explain_p);
> - /* It should only be possible to get here for a call. */
> - gcc_assert (elt_strict & UNIFY_ALLOW_OUTER_LEVEL);
> - elt_strict |= maybe_adjust_types_for_deduction
> - (DEDUCE_CALL, &elttype, &type, elt);
> - elt = type;
> - }
> + if (!BRACE_ENCLOSED_INITIALIZER_P (elt))
> + {
> + tree type = TREE_TYPE (elt);
> + if (type == error_mark_node)
> + return unify_invalid (explain_p);
> + /* It should only be possible to get here for a call. */
> + gcc_assert (elt_strict & UNIFY_ALLOW_OUTER_LEVEL);
> + elt_strict |= maybe_adjust_types_for_deduction
> + (DEDUCE_CALL, &elttype, &type, elt);
> + elt = type;
> + }
>
> RECUR_AND_CHECK_FAILURE (tparms, targs, elttype, elt, elt_strict,
>explain_p);
> diff --git gcc/testsuite/g++.dg/cpp0x/initlist102.C
> gcc/testsuite/g++.dg/cpp0x/initlist102.C
> index e69de29bb2d..e114866292f 100644
> --- gcc/testsuite/g++.dg/cpp0x/initlist102.C
> +++ gcc/testsuite/g++.dg/cpp0x/initlist102.C
> @@ -0,0 +1,39 @@
> +// PR c++/85977, Incorrect handling of array reference size deduction
> +// { dg-do compile { target c++11 } }
> +
> +template
> +void fn1 (const char (&)[N]) { static_assert (N == 3, "fn1");}
> +
> +template
> +void fn2 (const short (&)[N]) { static_assert (N == 3, "fn2");}
> +
> +template
> +void fn3 (const int (&)[N]) { static_assert (N == 3, "fn2");}
> +
> +template
> +void fn4 (const long (&)[N]) { static_assert (N == 3, "fn4");}
> +
> +template
> +void fn5 (const uns
Re: [PATCH] Avoid optimizing memory references with side effects in compare-elim.c
> That simplifies the patch, which now looks like this. Ok for trunk? > > paul > > gcc/ChangeLog: > > 2018-06-05 Paul Koning > > * compare-elim.c (try_merge_compare): Don't merge compare if > address contains a side effect. > * gcc.c-torture/compile/20180605-1.c: New test case. The patch is OK, but its ChangeLog is not. :-) It does not modify one function but two (try_merge_compare and try_eliminate_compare). I would suggest using "diff -up" to generate patches with more context. -- Eric Botcazou
Re: [PATCH] add support for strnlen (PR 81384)
On Wed, Jun 06, 2018 at 09:14:11AM -0600, Martin Sebor wrote: > On 06/05/2018 04:19 PM, Jakub Jelinek wrote: > > On Tue, Jun 05, 2018 at 03:43:17PM -0600, Martin Sebor wrote: > > > --- a/gcc/builtins.def > > > +++ b/gcc/builtins.def > > > @@ -733,6 +733,7 @@ DEF_EXT_LIB_BUILTIN(BUILT_IN_STRNCASECMP, > > > "strncasecmp", BT_FN_INT_CONST_STR > > > DEF_LIB_BUILTIN(BUILT_IN_STRNCAT, "strncat", > > > BT_FN_STRING_STRING_CONST_STRING_SIZE, ATTR_RET1_NOTHROW_NONNULL_LEAF) > > > DEF_LIB_BUILTIN(BUILT_IN_STRNCMP, "strncmp", > > > BT_FN_INT_CONST_STRING_CONST_STRING_SIZE, ATTR_PURE_NOTHROW_NONNULL_LEAF) > > > DEF_LIB_BUILTIN(BUILT_IN_STRNCPY, "strncpy", > > > BT_FN_STRING_STRING_CONST_STRING_SIZE, ATTR_RET1_NOTHROW_NONNULL_LEAF) > > > +DEF_LIB_BUILTIN_CHKP (BUILT_IN_STRNLEN, "strnlen", > > > BT_FN_SIZE_CONST_STRING_SIZE, ATTR_PURE_NOTHROW_NONNULL_LEAF) > > > > strnlen isn't a C89, C99 nor C11 function, so I think it should be > > DEF_EXT_LIB_BUILTIN like e.g. stpcpy, not DEF_LIB_BUILTIN. > > Thanks. Let me change that. > > > And not really sure it is worth adding the CHKP stuff when it will be just > > more work for Martin Liska to remove it again. > > Sure, let me take that out. > > Is there anything else? This wasn't a review, I just wanted to point out these two things. Jakub
Re: [PATCH,rs6000] Fix vec_permxor builtin support, fix test cases for vec_permxor and vec_insert4b
GCC maintainers:
Per the comment from Segher, there is a typo in the ABI.
On Tue, 2018-06-05 at 16:45 -0500, Bill Schmidt wrote:
> Hi Carl,
>
> That looks like a typo in the ABI document to me. The return type
> should match the
> argument types like it does for the other variants. Sorry -- I'll
> open a bug against
> the ABI doc.
>
> Thanks! Good catch, Segher.
>
>> So, the ABI doc currently says:
> >
> > vector unsigned char vec_permxor (vector signed char, vector
> > signed char, vector signed char);
> > vector unsigned char vec_permxor (vector unsigned char, vector
> > unsigned char, vector unsigned char);
> >
> > and we want it to read:
> >
> > vector signed char vec_permxor (vector signed char, vector
> > signed char, vector signed char);
> > vector unsigned char vec_permxor (vector unsigned char, vector
> > unsigned char, vector unsigned char);>
> Yep, correct!
> Bill
Given that, the changes to match the ABI in gcc/config/rs6000/rs6000-
c.c and gcc/testsuite/gcc.target/powerpc/builtins-7-runnable.c were
removed from the patch leaving just the changes to file
gcc/testsuite/gcc.target/powerpc/builtins-7-p9-runnable.c.
The patch was retested on:
powerpc64le-unknown-linux-gnu (Power 8 LE)
powerpc64le-unknown-linux-gnu (Power 9 LE)
powerpc64-unknown-linux-gnu (Power 8 BE)
With no regressions.
Please let me know if the patch looks OK for GCC mainline.
Carl Love
-
gcc/testsuite/ChangeLog:
2018-06-06 Carl Love
* gcc.target/powerpc/builtins-7-p9-runnable.c: Change first
argument to vui_arg.
---
gcc/testsuite/gcc.target/powerpc/builtins-7-p9-runnable.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/gcc/testsuite/gcc.target/powerpc/builtins-7-p9-runnable.c
b/gcc/testsuite/gcc.target/powerpc/builtins-7-p9-runnable.c
index 137b46b..f277344 100644
--- a/gcc/testsuite/gcc.target/powerpc/builtins-7-p9-runnable.c
+++ b/gcc/testsuite/gcc.target/powerpc/builtins-7-p9-runnable.c
@@ -82,6 +82,7 @@ vext (vector unsigned char *vc)
int main()
{
vector signed int vsi_arg;
+ vector unsigned int vui_arg;
vector unsigned char vec_uc_arg, vec_uc_result, vec_uc_expected;
vector unsigned long long vec_ull_result, vec_ull_expected;
unsigned long long ull_result, ull_expected;
@@ -113,10 +114,12 @@ int main()
/* insert into char 4 location */
vec_uc_expected = (vector unsigned char){1, 2, 3, 4,
- 0xC, 0, 0, 0,
+ 2, 0, 0, 0,
9, 10, 11, 12,
13, 14, 15, 16};
- vec_uc_result = vec_insert4b (vsi_arg, vec_uc_arg, 4);
+ vui_arg = (vector unsigned int){0x4, 0x3, 0x2, 0x1};
+
+ vec_uc_result = vec_insert4b (vui_arg, vec_uc_arg, 4);
if (result_wrong_uc(vec_uc_expected, vec_uc_result))
{
--
2.7.4
Re: [PATCH] add support for strnlen (PR 81384)
On 06/05/2018 04:19 PM, Jakub Jelinek wrote: On Tue, Jun 05, 2018 at 03:43:17PM -0600, Martin Sebor wrote: --- a/gcc/builtins.def +++ b/gcc/builtins.def @@ -733,6 +733,7 @@ DEF_EXT_LIB_BUILTIN(BUILT_IN_STRNCASECMP, "strncasecmp", BT_FN_INT_CONST_STR DEF_LIB_BUILTIN(BUILT_IN_STRNCAT, "strncat", BT_FN_STRING_STRING_CONST_STRING_SIZE, ATTR_RET1_NOTHROW_NONNULL_LEAF) DEF_LIB_BUILTIN(BUILT_IN_STRNCMP, "strncmp", BT_FN_INT_CONST_STRING_CONST_STRING_SIZE, ATTR_PURE_NOTHROW_NONNULL_LEAF) DEF_LIB_BUILTIN(BUILT_IN_STRNCPY, "strncpy", BT_FN_STRING_STRING_CONST_STRING_SIZE, ATTR_RET1_NOTHROW_NONNULL_LEAF) +DEF_LIB_BUILTIN_CHKP (BUILT_IN_STRNLEN, "strnlen", BT_FN_SIZE_CONST_STRING_SIZE, ATTR_PURE_NOTHROW_NONNULL_LEAF) strnlen isn't a C89, C99 nor C11 function, so I think it should be DEF_EXT_LIB_BUILTIN like e.g. stpcpy, not DEF_LIB_BUILTIN. Thanks. Let me change that. And not really sure it is worth adding the CHKP stuff when it will be just more work for Martin Liska to remove it again. Sure, let me take that out. Is there anything else? Martin
C++ PATCH for c++/58710, -Wmemset-elt-size in a template
In this testcase, -Wmemset-elt-size was crashing because
TYPE_UNIT_SIZE of A was NULL. The first hunk fixes that. The
patch also moves the warning into finish_call_expr so that it can be
issued at instantiation time as well, for dependent arguments. And I
noticed that we were unnecessarily wrapping CONST_DECL in
NON_DEPENDENT_EXPR.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 94e6a80b724b3f2f8f83274a4f74ab13915d42f0
Author: Jason Merrill
Date: Wed Jun 6 11:06:48 2018 +0200
PR c++/85710 - ICE with -Wmemset-elt-size.
c-family/
* c-warn.c (warn_for_memset): Don't crash on incomplete element type.
cp/
* semantics.c (finish_call_expr): Call warn_for_memset here.
* parser.c (cp_parser_postfix_expression): Not here.
(literal_integer_zerop): No longer static.
* pt.c (build_non_dependent_expr): Don't wrap CONST_DECL.
diff --git a/gcc/c-family/c-warn.c b/gcc/c-family/c-warn.c
index e7bcbb18a3c..859d72b3f83 100644
--- a/gcc/c-family/c-warn.c
+++ b/gcc/c-family/c-warn.c
@@ -1897,7 +1897,8 @@ warn_for_memset (location_t loc, tree arg0, tree arg2,
{
tree elt_type = TREE_TYPE (type);
tree domain = TYPE_DOMAIN (type);
- if (!integer_onep (TYPE_SIZE_UNIT (elt_type))
+ if (COMPLETE_TYPE_P (elt_type)
+ && !integer_onep (TYPE_SIZE_UNIT (elt_type))
&& domain != NULL_TREE
&& TYPE_MAX_VALUE (domain)
&& TYPE_MIN_VALUE (domain)
diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index f2016f173bd..a6d0b431a9d 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -6548,6 +6548,7 @@ extern bool parsing_default_capturing_generic_lambda_in_template (void);
extern void inject_this_parameter (tree, cp_cv_quals);
extern location_t defarg_location (tree);
extern void maybe_show_extern_c_location (void);
+extern bool literal_integer_zerop (const_tree);
/* in pt.c */
extern bool check_template_shadow (tree);
diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index de090d42d8d..03aea2f1150 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -6614,11 +6614,11 @@ cp_parser_compound_literal_p (cp_parser *parser)
/* Return true if EXPR is the integer constant zero or a complex constant
of zero, without any folding, but ignoring location wrappers. */
-static bool
+bool
literal_integer_zerop (const_tree expr)
{
- STRIP_ANY_LOCATION_WRAPPER (expr);
- return integer_zerop (expr);
+ return (location_wrapper_p (expr)
+ && integer_zerop (TREE_OPERAND (expr, 0)));
}
/* Parse a postfix-expression.
@@ -7159,19 +7159,6 @@ cp_parser_postfix_expression (cp_parser *parser, bool address_p, bool cast_p,
}
}
- if (TREE_CODE (postfix_expression) == FUNCTION_DECL
- && DECL_BUILT_IN_CLASS (postfix_expression) == BUILT_IN_NORMAL
- && DECL_FUNCTION_CODE (postfix_expression) == BUILT_IN_MEMSET
- && vec_safe_length (args) == 3)
- {
- tree arg0 = (*args)[0];
- tree arg1 = (*args)[1];
- tree arg2 = (*args)[2];
- int literal_mask = ((literal_integer_zerop (arg1) << 1)
-| (literal_integer_zerop (arg2) << 2));
- warn_for_memset (input_location, arg0, arg2, literal_mask);
- }
-
if (TREE_CODE (postfix_expression) == COMPONENT_REF)
{
tree instance = TREE_OPERAND (postfix_expression, 0);
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index aad68a32643..448cd69b722 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -25837,8 +25837,8 @@ build_non_dependent_expr (tree expr)
if (is_overloaded_fn (inner_expr)
|| TREE_CODE (inner_expr) == OFFSET_REF)
return orig_expr;
- /* There is no need to return a proxy for a variable. */
- if (VAR_P (expr))
+ /* There is no need to return a proxy for a variable or enumerator. */
+ if (VAR_P (expr) || TREE_CODE (expr) == CONST_DECL)
return orig_expr;
/* Preserve string constants; conversions from string constants to
"char *" are allowed, even though normally a "const char *"
diff --git a/gcc/cp/semantics.c b/gcc/cp/semantics.c
index a3426623385..55791894221 100644
--- a/gcc/cp/semantics.c
+++ b/gcc/cp/semantics.c
@@ -2350,7 +2350,7 @@ finish_call_expr (tree fn, vec **args, bool disallow_virtual,
{
tree result;
tree orig_fn;
- vec *orig_args = NULL;
+ vec *orig_args = *args;
if (fn == error_mark_node)
return error_mark_node;
@@ -2524,6 +2524,22 @@ finish_call_expr (tree fn, vec **args, bool disallow_virtual,
sizeof_arg, same_type_ignoring_top_level_qualifiers_p);
}
+ if ((complain & tf_warning)
+ && TREE_CODE (fn) == FUNCTION_DECL
+ && DECL_BUILT_IN_CLASS (fn) == BUILT_IN_NORMAL
+ && DECL_FUNCTION_CODE (fn) == BUILT_IN_MEMSET
+ && vec_safe_length (*args) == 3
+ && !any_type_dependent_arguments_p (*args))
+ {
+ tree arg0 = (*orig_args)[0];
+ tree arg1 = (*orig_args)[1];
+ tree arg2 = (*orig_args)[2];
+ int literal_mask = ((literal_integer_zerop (arg1) << 1)
+ | (literal_integer_zerop (arg2) << 2));
+
[PATCH, rs6000] Add BE support for first_match_index, first_match_or_eos_index, first_mismatch_index, first_mismatch_or_eos_index
GCC Maintainers:
The Power 9 builtins first_match_index, first_match_or_eos_index,
first_mismatch_index, first_mismatch_or_eos_index work for LE only.
The following patch adds BE support to each of the builtins.
Additional debug print statements were added to the test case to aid in
verifying the results.
The patch was tested on:
powerpc64le-unknown-linux-gnu (Power 8 LE)
powerpc64le-unknown-linux-gnu (Power 9 LE)
powerpc64-unknown-linux-gnu (Power 8 BE)
With no regressions.
Currently, there are no Power 9 BE systems to test the patch on. The
test file was compiled on a Power 8 BE system and then the generated
binary file was examined via objdump to see that the desired
instruction was generated.
Please let me know if the patch looks OK for GCC mainline.
Carl Love
-
gcc/ChangeLog:
2018-06-04 Carl Love
* gcc/config/rs6000/vsx.md (first_match_index_):
Calculate index using natureal element order.
(first_match_or_eos_index_):
Calculate index using natural element order.
(first_match_index_):
Calculate index using natural element order.
(first_match_or_eos_index_):
Calculate index using natural order.
(define_insn vclzlsbb): Change to define_insn vclzlsbb_.
for BE and LE modes.
* gcc/config/rs6000/rs6000-c.c: Rename P9V_BUILTIN_VCLZLSBB,
P9V_BUILTIN_VCLZLSBB_V16QI.
* gcc/config/rs6000/rs6000-builtin.def: Make VCLZLSBB mode
specific.
gcc/testsuite/ChangeLog:
2018-06-04 Carl Love
* gcc.target/powerpc/builtins-8-p9-runnable.c: Add additional
debug print statements. Fix a few formating issues.
* gcc.target/powerpc/vsu/vec-cntlz-lsbb-2.c (dg-error): Update expected
error message.
---
gcc/config/rs6000/rs6000-builtin.def | 4 +-
gcc/config/rs6000/rs6000-c.c | 4 +-
gcc/config/rs6000/vsx.md | 62 ++-
.../gcc.target/powerpc/builtins-8-p9-runnable.c| 503 -
.../gcc.target/powerpc/vsu/vec-cntlz-lsbb-2.c | 2 +-
5 files changed, 543 insertions(+), 32 deletions(-)
diff --git a/gcc/config/rs6000/rs6000-builtin.def
b/gcc/config/rs6000/rs6000-builtin.def
index 5503893..779f8a3 100644
--- a/gcc/config/rs6000/rs6000-builtin.def
+++ b/gcc/config/rs6000/rs6000-builtin.def
@@ -2194,7 +2194,9 @@ BU_P9V_64BIT_AV_X (STXVL, "stxvl",MISC)
BU_P9V_64BIT_AV_X (XST_LEN_R, "xst_len_r",MISC)
/* 1 argument vector functions added in ISA 3.0 (power9). */
-BU_P9V_AV_1 (VCLZLSBB, "vclzlsbb", CONST, vclzlsbb)
+BU_P9V_AV_1 (VCLZLSBB_V16QI, "vclzlsbb_v16qi", CONST, vclzlsbb_v16qi)
+BU_P9V_AV_1 (VCLZLSBB_V8HI, "vclzlsbb_v8hi", CONST, vclzlsbb_v8hi)
+BU_P9V_AV_1 (VCLZLSBB_V4SI, "vclzlsbb_v4si", CONST, vclzlsbb_v4si)
BU_P9V_AV_1 (VCTZLSBB_V16QI, "vctzlsbb_v16qi", CONST, vctzlsbb_v16qi)
BU_P9V_AV_1 (VCTZLSBB_V8HI, "vctzlsbb_v8hi", CONST, vctzlsbb_v8hi)
BU_P9V_AV_1 (VCTZLSBB_V4SI, "vctzlsbb_v4si", CONST, vctzlsbb_v4si)
diff --git a/gcc/config/rs6000/rs6000-c.c b/gcc/config/rs6000/rs6000-c.c
index 6cf5537..948d387 100644
--- a/gcc/config/rs6000/rs6000-c.c
+++ b/gcc/config/rs6000/rs6000-c.c
@@ -5451,9 +5451,9 @@ const struct altivec_builtin_types
altivec_overloaded_builtins[] = {
RS6000_BTI_bool_V4SI, RS6000_BTI_unsigned_V4SI,
RS6000_BTI_unsigned_V4SI, 0 },
- { P9V_BUILTIN_VEC_VCLZLSBB, P9V_BUILTIN_VCLZLSBB,
+ { P9V_BUILTIN_VEC_VCLZLSBB, P9V_BUILTIN_VCLZLSBB_V16QI,
RS6000_BTI_INTSI, RS6000_BTI_V16QI, 0, 0 },
- { P9V_BUILTIN_VEC_VCLZLSBB, P9V_BUILTIN_VCLZLSBB,
+ { P9V_BUILTIN_VEC_VCLZLSBB, P9V_BUILTIN_VCLZLSBB_V16QI,
RS6000_BTI_INTSI, RS6000_BTI_unsigned_V16QI, 0, 0 },
{ P9V_BUILTIN_VEC_VCTZLSBB, P9V_BUILTIN_VCTZLSBB_V16QI,
diff --git a/gcc/config/rs6000/vsx.md b/gcc/config/rs6000/vsx.md
index 58796ff..36a6312 100644
--- a/gcc/config/rs6000/vsx.md
+++ b/gcc/config/rs6000/vsx.md
@@ -4723,7 +4723,8 @@
"vcmpnez. %0,%1,%2"
[(set_attr "type" "vecsimple")])
-;; Return first position of match between vectors
+;; Return first position of match between vectors using natural order
+;; for both LE and BE execution modes.
(define_expand "first_match_index_"
[(match_operand:SI 0 "register_operand")
(unspec:SI [(match_operand:VSX_EXTRACT_I 1 "register_operand")
@@ -4743,17 +4744,26 @@
sh = GET_MODE_SIZE (GET_MODE_INNER (mode)) / 2;
if (mode == V16QImode)
-emit_insn (gen_vctzlsbb_ (operands[0], not_result));
+{
+ if (!BYTES_BIG_ENDIAN)
+emit_insn (gen_vctzlsbb_ (operands[0], not_result));
+ else
+emit_insn (gen_vclzlsbb_ (operands[0], not_result));
+}
else
{
rtx tmp = gen_reg_rtx (SImode);
- emit_insn (gen_vctzlsbb_ (tmp, not_result));
+ if (!BYTES_BIG_ENDIAN)
+emit_insn (gen_vctzlsbb_ (tmp, not_result));
+ else
+em
Re: [RFC] [aarch64] Add HiSilicon tsv110 CPU support
Hi Shaokun, On 01/06/18 10:56, Zhangshaokun wrote: Hi Ramana, Sorry to reply so later because of short leave. On 2018/5/23 18:41, Ramana Radhakrishnan wrote: On 23/05/2018 03:50, Zhangshaokun wrote: Hi Ramana, On 2018/5/22 18:28, Ramana Radhakrishnan wrote: On Tue, May 22, 2018 at 9:40 AM, Shaokun Zhang wrote: tsv110 is designed by HiSilicon and supports v8_4A, it also optimizes L1 Icache which can access L1 Dcache. Therefore, DC CVAU is not necessary in __aarch64_sync_cache_range for tsv110, is there any good idea to skip DC CVAU operation for tsv110. A solution would be to use an ifunc but on a cpu variant. ifunc, can you give further explanation? If on a cpu variant, for HiSilicon tsv110, we have two version and CPU variants are 0 and 1. Both are expected to skip DC CVAU operation in sync icache and dcache. Since it is not necessary for sync icache and dcache, it is beneficial for performance to skip the redundant DC CVAU and do IC IVAU only. For JVM, __clear_cache is called many times. Thanks for some more detail as to where you think you want to use this. Have you investigated whether the jvm can actually elide such a call rather than trying to fix this in the toolchain ? In fact, We(HiSilicon) want optimize DC CVAU not only in the toolchain, but also for LLVM and others. If you really need to think about solutions in the toolchain - The simplest first step would be to implement the changes hinted at by the comment in aarch64.h . If you read the comment above CLEAR_INSN_CACHE in aarch64.h you would see that /* This definition should be relocated to aarch64-elf-raw.h. This macro should be undefined in aarch64-linux.h and a clear_cache pattern implmented to emit either the call to __aarch64_sync_cache_range() directly or preferably the appropriate sycall or cache clear instructions inline. */ #define CLEAR_INSN_CACHE(beg, end) \ extern void __aarch64_sync_cache_range (void *, void *); \ __aarch64_sync_cache_range (beg, end) Thus I would expect that by implementing the clear_cache pattern and deciding whether to put out the call to the __aarch64_sync_cache_range function or not depending on whether you had the tsv110 chosen on the command line would allow you to have an idea of what the performance gain actually is by compiling the jvm with -mcpu=tsv110 vs -march=armv8-a. You probably also want to clean up the trampoline_init code while you are here. Thanks for your nice explanation and guidance. For our next generation cpu core tsv200, We will optimize for IC IVAU that there is no need to flush Icache, keep the clear_cache as NOP function. Shall I consider this? or Maybe i lose something what your said. I've had a look at the __clear_cache implementation and investigated these cache coherency bits. If clearing the instruction cache means you don't need to explicitly clear the data cache then the IDC bit of the CTR_EL0 register will be set to 1. This is how you can identify that you can avoid the explicit "DC CVAU" in __clear_cache. Have a look at the D10.2.33 section in the Arm Architecture Reference Manual Issue C.a [1] for more documentation. To implement this elision in libgcc you'd need to extend __arch64_sync_cache_range in config/aarch64/sync_cache.c to read the IDC bit from CTR_EL0. The code there already reads CTR_EL0 and caches its value so you just need to extract that bit and use it to decide whether to perform the "DC CVAU" loop. But that should a patch on its own. Your patch to add a tsv110 entry into aarch64-cores.def can be respun and reviewed separately. Thanks, Kyrill [1] https://developer.arm.com/products/architecture/a-profile/docs/ddi0487/latest/arm-architecture-reference-manual-armv8-for-armv8-a-architecture-profile Thanks, Shaokun I do think that's something that should be easy enough to do and the subject of a patch series in its own right. If your users can rebuild the world for tsv110 then this is sufficient. If you want to have a single jvm binary without any run time checks, then you need to investigate the use of ifuncs which are a mechanism in the GNU toolchain for some of this kind of stuff. We tend not to ifuncs on a per CPU basis unless there is a very good reason and the performance improvement is worth it (but probably more on a per architecture or per architectural basis) and you will need to make the case for it including what sort of performance benefits it gives. Some introduction about this feature can be found here. https://sourceware.org/glibc/wiki/GNU_IFUNC regards Ramana Hi ARM guys, are you happy to share yours idea about this? Is this really that important for performance and on what workloads ? Since it is not necessary for sync icache and dcache, it is beneficial for performance to skip the redundant DC CVAU and do IC IVAU only. For JVM, __clear_cache is called many times. Thanks, Shaokun regards Ramana Any thoughts and
libgo patch committed: Fix hash/string values computed by reflect.StructOf
This libgo patch adjusts the hash and string fields computed by
reflect.StructOf to match the values that the compiler computes for a
struct type with the same field names and types. This makes the
reflect code match the compiler's Type::hash_for_method and
Type::reflection methods. This fixes https://golang.org/issue/25284.
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 261216)
+++ gcc/go/gofrontend/MERGE (working copy)
@@ -1,4 +1,4 @@
-8b6c7f3f9762366bab96ea95b966e93e2593be13
+baf289294a026ddd30c9e4341aff528084337763
The first line of this file holds the git revision number of the last
merge done from the gofrontend repository.
Index: libgo/go/reflect/all_test.go
===
--- libgo/go/reflect/all_test.go(revision 261216)
+++ libgo/go/reflect/all_test.go(working copy)
@@ -4411,6 +4411,17 @@ func TestStructOf(t *testing.T) {
})
// check that type already in binary is found
checkSameType(t, StructOf(fields[2:3]), struct{ Y uint64 }{})
+
+ // gccgo used to fail this test.
+ type structFieldType interface{}
+ checkSameType(t,
+ StructOf([]StructField{
+ StructField{
+ Name: "F",
+ Type: TypeOf((*structFieldType)(nil)).Elem(),
+ },
+ }),
+ struct{ F structFieldType }{})
}
func TestStructOfExportRules(t *testing.T) {
Index: libgo/go/reflect/type.go
===
--- libgo/go/reflect/type.go(revision 261216)
+++ libgo/go/reflect/type.go(working copy)
@@ -1912,7 +1912,7 @@ func isValidFieldName(fieldName string)
// This limitation may be lifted in a future version.
func StructOf(fields []StructField) Type {
var (
- hash = uint32(0)
+ hash = uint32(12)
size uintptr
typalign int8
comparable = true
@@ -1997,7 +1997,7 @@ func StructOf(fields []StructField) Type
}
fset[name] = struct{}{}
- repr = append(repr, (" " + ft.String())...)
+ repr = append(repr, (" " + *ft.string)...)
if f.tag != nil {
repr = append(repr, (" " + strconv.Quote(*f.tag))...)
}
Re: [PATCH] add support for strnlen (PR 81384)
On 06/05/2018 06:39 PM, Eric Gallager wrote: On 6/5/18, Martin Sebor wrote: The attached patch adds basic support for handling strnlen as a built-in function. It touches the strlen pass where it folds constant results of the function, and builtins.c to add simple support for expanding strnlen calls with known results. It also changes calls.c to detect excessive bounds to the function and unsafe calls with arguments declared attribute nonstring. A side-effect of the strlen change I should call out is that strlen() calls to all zero-length arrays that aren't considered flexible array members (i.e., internal members or non-members) are folded into zero. No warning is issued for such invalid uses of zero-length arrays but based on the responses to my question Re: aliasing between internal zero-length-arrays and other members(*) it sounds like one would be appropriate. I will see about adding one in a separate patch. Martin [*] https://gcc.gnu.org/ml/gcc/2018-06/msg00046.html I see stuff in the patch mentioning the library version of strnlen; have you tested on platforms both with and without strnlen in their libcs? The gnulib documentation lists these platforms as having missing or buggy strnlens: This function is missing on some platforms: Mac OS X 10.5, FreeBSD 6.0, NetBSD 5.0, OpenBSD 3.8, AIX 4.3.2, HP-UX 11, IRIX 6.5, OSF/1 5.1, Solaris 10, mingw, Interix 3.5. This function is buggy on some platforms: AIX 4.3. https://www.gnu.org/software/gnulib/manual/html_node/strnlen.html The patch doesn't make GCC synthesize calls to strnlen if they don't appear in source code. It's the responsibility of programmers for those targets to work around their limitations, bugs, or absence of support for the function (e.g., by avoiding making calls to it). This is the same as for most other library functions, except a few exceptions like memcpy and memset where GCC relies on the target to provide conforming implementations. I only tested the patch on x86_64-linux. Martin
Re: [PATCH] Slightly improve reassoc optimize_range_tests_var_bound (PR tree-optimization/69615)
On Wed, 6 Jun 2018, Jakub Jelinek wrote:
> Hi!
>
> The following testcase shows another case that can be handled easily.
> If rhs2 is defined in a bb dominated by first_bb, we need to be careful
> because we can't rely on value range information of it after we optimize the
> guarding >= 0 check into 1. On the testcase, we have there
> rhs2 = (int) something_N;
> cast where both types are integral with the same precision, so we can in
> this case just check if something_N is defined in some bb not dominated by
> first_bb, or if it is result of & constant, or zero extension etc.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
OK.
Thanks,
Richard.
> 2018-06-05 Jakub Jelinek
>
> PR tree-optimization/69615
> * tree-ssa-reassoc.c (optimize_range_tests_var_bound): If rhs2 is lhs
> of a cast from a same precision integral SSA_NAME in a bb dominated
> by first_bb, retry with rhs2 set to the rhs1 of the cast. Don't emit
> cast to utype if rhs2 has already a compatible type.
>
> * gcc.dg/tree-ssa/pr69615.c: New test.
>
> --- gcc/tree-ssa-reassoc.c.jj 2018-04-27 09:08:57.667850280 +0200
> +++ gcc/tree-ssa-reassoc.c2018-06-05 17:01:39.028144763 +0200
> @@ -3172,7 +3172,7 @@ optimize_range_tests_var_bound (enum tre
>to (unsigned) k_32 < (unsigned) iftmp.0_44, then we would execute
>those stmts even for negative k_32 and the value ranges would be no
>longer guaranteed and so the optimization would be invalid. */
> - if (opcode == ERROR_MARK)
> + while (opcode == ERROR_MARK)
> {
> gimple *g = SSA_NAME_DEF_STMT (rhs2);
> basic_block bb2 = gimple_bb (g);
> @@ -3182,21 +3182,37 @@ optimize_range_tests_var_bound (enum tre
> {
> /* As an exception, handle a few common cases. */
> if (gimple_assign_cast_p (g)
> - && INTEGRAL_TYPE_P (TREE_TYPE (gimple_assign_rhs1 (g)))
> - && TYPE_UNSIGNED (TREE_TYPE (gimple_assign_rhs1 (g)))
> - && (TYPE_PRECISION (TREE_TYPE (rhs2))
> - > TYPE_PRECISION (TREE_TYPE (gimple_assign_rhs1 (g)
> - /* Zero-extension is always ok. */ ;
> + && INTEGRAL_TYPE_P (TREE_TYPE (gimple_assign_rhs1 (g
> + {
> + tree op0 = gimple_assign_rhs1 (g);
> + if (TYPE_UNSIGNED (TREE_TYPE (op0))
> + && (TYPE_PRECISION (TREE_TYPE (rhs2))
> + > TYPE_PRECISION (TREE_TYPE (op0
> + /* Zero-extension is always ok. */
> + break;
> + else if (TYPE_PRECISION (TREE_TYPE (rhs2))
> +== TYPE_PRECISION (TREE_TYPE (op0))
> +&& TREE_CODE (op0) == SSA_NAME)
> + {
> + /* Cast from signed to unsigned or vice versa. Retry
> + with the op0 as new rhs2. */
> + rhs2 = op0;
> + continue;
> + }
> + }
> else if (is_gimple_assign (g)
> && gimple_assign_rhs_code (g) == BIT_AND_EXPR
> && TREE_CODE (gimple_assign_rhs2 (g)) == INTEGER_CST
> && !wi::neg_p (wi::to_wide (gimple_assign_rhs2 (g
> /* Masking with INTEGER_CST with MSB clear is always ok
> -too. */ ;
> - else
> - continue;
> +too. */
> + break;
> + rhs2 = NULL_TREE;
> }
> + break;
> }
> + if (rhs2 == NULL_TREE)
> + continue;
>
>wide_int nz = get_nonzero_bits (rhs2);
>if (wi::neg_p (nz))
> @@ -3253,10 +3269,13 @@ optimize_range_tests_var_bound (enum tre
>gimple_set_uid (g, uid);
>rhs1 = gimple_assign_lhs (g);
>gsi_insert_before (&gsi, g, GSI_SAME_STMT);
> - g = gimple_build_assign (make_ssa_name (utype), NOP_EXPR, rhs2);
> - gimple_set_uid (g, uid);
> - rhs2 = gimple_assign_lhs (g);
> - gsi_insert_before (&gsi, g, GSI_SAME_STMT);
> + if (!useless_type_conversion_p (utype, TREE_TYPE (rhs2)))
> + {
> + g = gimple_build_assign (make_ssa_name (utype), NOP_EXPR, rhs2);
> + gimple_set_uid (g, uid);
> + rhs2 = gimple_assign_lhs (g);
> + gsi_insert_before (&gsi, g, GSI_SAME_STMT);
> + }
>if (tree_swap_operands_p (rhs1, rhs2))
> {
> std::swap (rhs1, rhs2);
> --- gcc/testsuite/gcc.dg/tree-ssa/pr69615.c.jj2018-06-06
> 12:55:16.535159073 +0200
> +++ gcc/testsuite/gcc.dg/tree-ssa/pr69615.c 2018-06-06 12:54:53.993133421
> +0200
> @@ -0,0 +1,16 @@
> +/* PR tree-optimization/69615 */
> +/* { dg-do compile } */
> +/* { dg-options "-O2 -fdump-tree-optimized" } */
> +/* { dg-final { scan-tree-dump-not " >= 0" "optimized" } } */
> +/* { dg-final { scan-tree-dump-not " < 0" "optimized" } } */
> +
> +extern void foo (void);
> +
> +vo
Re: C++ PATCH for c++/85977, array reference size deduction failure
On Fri, Jun 01, 2018 at 12:39:08PM -0400, Jason Merrill wrote:
> Yes, we still need to do deduction on the array bound, so we can't
> return immediately. We just want to avoid the
>
> FOR_EACH_CONSTRUCTOR_VALUE (CONSTRUCTOR_ELTS (arg), i, elt)
>
> loop.
Got it. But then there's this part:
> And then we want to check convertibility of the elements in
> type_unification_real, when we check convertibility of other function
> parameters that don't involve template parameters:
>
> /* DR 1391: All parameters have args, now check non-dependent
> parms for convertibility. */
which I hoped would be achieved by this:
@@ -20370,6 +20370,16 @@ type_unification_real (tree tparms,
if (check_non_deducible_conversion (parm, arg, strict, flags,
explain_p))
return 1;
+
+ if (BRACE_ENCLOSED_INITIALIZER_P (arg))
+ {
+ tree elt;
+ unsigned int i;
+ FOR_EACH_CONSTRUCTOR_VALUE (CONSTRUCTOR_ELTS (arg), i, elt)
+ if (check_non_deducible_conversion (parm, elt, strict, flags,
+ explain_p))
+ return 1;
+ }
}
/* Now substitute into the default template arguments. */
but that breaks e.g. initlist34.C, because ARG is {0} and PARM is
struct initializer_list, and checking whether we can convert 0 to
struct initializer_list doesn't work, so we return 1. I've probably
misunderstood what you wanted me to do here. For the attached testcases
we'll never reach that code anyway, because PARM depends on a template
parameter.
2018-06-05 Marek Polacek
PR c++/85977
* pt.c (unify): If ELTTYPE has no deducible template parms, skip
deduction from the list elements.
* g++.dg/cpp0x/initlist102.C: New test.
* g++.dg/cpp0x/initlist103.C: New test.
* g++.dg/cpp0x/initlist104.C: New test.
diff --git gcc/cp/pt.c gcc/cp/pt.c
index aad68a32643..19c542b76d5 100644
--- gcc/cp/pt.c
+++ gcc/cp/pt.c
@@ -21404,24 +21415,30 @@ unify (tree tparms, tree targs, tree parm, tree arg,
int strict,
return unify_success (explain_p);
}
- FOR_EACH_CONSTRUCTOR_VALUE (CONSTRUCTOR_ELTS (arg), i, elt)
- {
- int elt_strict = strict;
+ if (strict != DEDUCE_EXACT
+ && TYPE_P (elttype)
+ && !uses_deducible_template_parms (elttype))
+ /* If ELTTYPE has no deducible template parms, skip deduction from
+ the list elements. */;
+ else
+ FOR_EACH_CONSTRUCTOR_VALUE (CONSTRUCTOR_ELTS (arg), i, elt)
+ {
+ int elt_strict = strict;
- if (elt == error_mark_node)
- return unify_invalid (explain_p);
+ if (elt == error_mark_node)
+ return unify_invalid (explain_p);
- if (!BRACE_ENCLOSED_INITIALIZER_P (elt))
- {
- tree type = TREE_TYPE (elt);
- if (type == error_mark_node)
- return unify_invalid (explain_p);
- /* It should only be possible to get here for a call. */
- gcc_assert (elt_strict & UNIFY_ALLOW_OUTER_LEVEL);
- elt_strict |= maybe_adjust_types_for_deduction
- (DEDUCE_CALL, &elttype, &type, elt);
- elt = type;
- }
+ if (!BRACE_ENCLOSED_INITIALIZER_P (elt))
+ {
+ tree type = TREE_TYPE (elt);
+ if (type == error_mark_node)
+ return unify_invalid (explain_p);
+ /* It should only be possible to get here for a call. */
+ gcc_assert (elt_strict & UNIFY_ALLOW_OUTER_LEVEL);
+ elt_strict |= maybe_adjust_types_for_deduction
+ (DEDUCE_CALL, &elttype, &type, elt);
+ elt = type;
+ }
RECUR_AND_CHECK_FAILURE (tparms, targs, elttype, elt, elt_strict,
explain_p);
diff --git gcc/testsuite/g++.dg/cpp0x/initlist102.C
gcc/testsuite/g++.dg/cpp0x/initlist102.C
index e69de29bb2d..e114866292f 100644
--- gcc/testsuite/g++.dg/cpp0x/initlist102.C
+++ gcc/testsuite/g++.dg/cpp0x/initlist102.C
@@ -0,0 +1,39 @@
+// PR c++/85977, Incorrect handling of array reference size deduction
+// { dg-do compile { target c++11 } }
+
+template
+void fn1 (const char (&)[N]) { static_assert (N == 3, "fn1");}
+
+template
+void fn2 (const short (&)[N]) { static_assert (N == 3, "fn2");}
+
+template
+void fn3 (const int (&)[N]) { static_assert (N == 3, "fn2");}
+
+template
+void fn4 (const long (&)[N]) { static_assert (N == 3, "fn4");}
+
+template
+void fn5 (const unsigned char (&)[N]) { static_assert (N == 3, "fn5");}
+
+template
+void fn6 (const unsigned short (&)[N]) { static_assert (N == 3, "fn6");}
+
+template
+void fn7 (const unsigned int (&)[N]) { static_assert (N == 3, "fn7");}
+
+template
+void fn8 (const unsigned int (&)[N]) { static_assert (N == 3, "fn8");}
+
+void
+bar ()
+{
+ fn1 ({1, 2, 3});
+ fn2 ({1, 2, 3});
+ fn3 ({1,
[PATCH] Slightly improve reassoc optimize_range_tests_var_bound (PR tree-optimization/69615)
Hi!
The following testcase shows another case that can be handled easily.
If rhs2 is defined in a bb dominated by first_bb, we need to be careful
because we can't rely on value range information of it after we optimize the
guarding >= 0 check into 1. On the testcase, we have there
rhs2 = (int) something_N;
cast where both types are integral with the same precision, so we can in
this case just check if something_N is defined in some bb not dominated by
first_bb, or if it is result of & constant, or zero extension etc.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2018-06-05 Jakub Jelinek
PR tree-optimization/69615
* tree-ssa-reassoc.c (optimize_range_tests_var_bound): If rhs2 is lhs
of a cast from a same precision integral SSA_NAME in a bb dominated
by first_bb, retry with rhs2 set to the rhs1 of the cast. Don't emit
cast to utype if rhs2 has already a compatible type.
* gcc.dg/tree-ssa/pr69615.c: New test.
--- gcc/tree-ssa-reassoc.c.jj 2018-04-27 09:08:57.667850280 +0200
+++ gcc/tree-ssa-reassoc.c 2018-06-05 17:01:39.028144763 +0200
@@ -3172,7 +3172,7 @@ optimize_range_tests_var_bound (enum tre
to (unsigned) k_32 < (unsigned) iftmp.0_44, then we would execute
those stmts even for negative k_32 and the value ranges would be no
longer guaranteed and so the optimization would be invalid. */
- if (opcode == ERROR_MARK)
+ while (opcode == ERROR_MARK)
{
gimple *g = SSA_NAME_DEF_STMT (rhs2);
basic_block bb2 = gimple_bb (g);
@@ -3182,21 +3182,37 @@ optimize_range_tests_var_bound (enum tre
{
/* As an exception, handle a few common cases. */
if (gimple_assign_cast_p (g)
- && INTEGRAL_TYPE_P (TREE_TYPE (gimple_assign_rhs1 (g)))
- && TYPE_UNSIGNED (TREE_TYPE (gimple_assign_rhs1 (g)))
- && (TYPE_PRECISION (TREE_TYPE (rhs2))
- > TYPE_PRECISION (TREE_TYPE (gimple_assign_rhs1 (g)
- /* Zero-extension is always ok. */ ;
+ && INTEGRAL_TYPE_P (TREE_TYPE (gimple_assign_rhs1 (g
+ {
+ tree op0 = gimple_assign_rhs1 (g);
+ if (TYPE_UNSIGNED (TREE_TYPE (op0))
+ && (TYPE_PRECISION (TREE_TYPE (rhs2))
+ > TYPE_PRECISION (TREE_TYPE (op0
+ /* Zero-extension is always ok. */
+ break;
+ else if (TYPE_PRECISION (TREE_TYPE (rhs2))
+ == TYPE_PRECISION (TREE_TYPE (op0))
+ && TREE_CODE (op0) == SSA_NAME)
+ {
+ /* Cast from signed to unsigned or vice versa. Retry
+with the op0 as new rhs2. */
+ rhs2 = op0;
+ continue;
+ }
+ }
else if (is_gimple_assign (g)
&& gimple_assign_rhs_code (g) == BIT_AND_EXPR
&& TREE_CODE (gimple_assign_rhs2 (g)) == INTEGER_CST
&& !wi::neg_p (wi::to_wide (gimple_assign_rhs2 (g
/* Masking with INTEGER_CST with MSB clear is always ok
- too. */ ;
- else
- continue;
+ too. */
+ break;
+ rhs2 = NULL_TREE;
}
+ break;
}
+ if (rhs2 == NULL_TREE)
+ continue;
wide_int nz = get_nonzero_bits (rhs2);
if (wi::neg_p (nz))
@@ -3253,10 +3269,13 @@ optimize_range_tests_var_bound (enum tre
gimple_set_uid (g, uid);
rhs1 = gimple_assign_lhs (g);
gsi_insert_before (&gsi, g, GSI_SAME_STMT);
- g = gimple_build_assign (make_ssa_name (utype), NOP_EXPR, rhs2);
- gimple_set_uid (g, uid);
- rhs2 = gimple_assign_lhs (g);
- gsi_insert_before (&gsi, g, GSI_SAME_STMT);
+ if (!useless_type_conversion_p (utype, TREE_TYPE (rhs2)))
+ {
+ g = gimple_build_assign (make_ssa_name (utype), NOP_EXPR, rhs2);
+ gimple_set_uid (g, uid);
+ rhs2 = gimple_assign_lhs (g);
+ gsi_insert_before (&gsi, g, GSI_SAME_STMT);
+ }
if (tree_swap_operands_p (rhs1, rhs2))
{
std::swap (rhs1, rhs2);
--- gcc/testsuite/gcc.dg/tree-ssa/pr69615.c.jj 2018-06-06 12:55:16.535159073
+0200
+++ gcc/testsuite/gcc.dg/tree-ssa/pr69615.c 2018-06-06 12:54:53.993133421
+0200
@@ -0,0 +1,16 @@
+/* PR tree-optimization/69615 */
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-optimized" } */
+/* { dg-final { scan-tree-dump-not " >= 0" "optimized" } } */
+/* { dg-final { scan-tree-dump-not " < 0" "optimized" } } */
+
+extern void foo (void);
+
+void
+bar (int z, unsigned int y)
+{
+ long long x = z;
+ y &= 0xf;
+ if (x >= 0 && x < (int) y)
+foo ();
+}
Jakub
[C++ PATCH] Fix up __cpp_transactional_memory value (PR c++/86068)
Hi! As mentioned in the PR, the current __cpp_transactional_memory macro value with -fgnu-tm is clearly bogus, what will be standardized in 2105 is unknown. The big question is if we should go with the value that was meant to be used in r228462 as this patch does, or if we should go for 201505 - is atomic_cancel implemented now? In any case, bootstrapped/regtested on x86_64-linux and i686-linux. 2018-06-06 Jakub Jelinek PR c++/86068 * c-cppbuiltin.c (c_cpp_builtins): Fix a typo, set __cpp_transactional_memory to 201500 instead of 210500. * include/bits/c++config: Check __cpp_transactional_memory >= 201500L rather than __cpp_transactional_memory >= 201505L. --- gcc/c-family/c-cppbuiltin.c.jj 2018-06-04 09:20:01.356136845 +0200 +++ gcc/c-family/c-cppbuiltin.c 2018-06-06 12:30:23.399425653 +0200 @@ -981,7 +981,7 @@ c_cpp_builtins (cpp_reader *pfile) if (flag_tm) /* Use a value smaller than the 201505 specified in the TS, since we don't yet support atomic_cancel. */ - cpp_define (pfile, "__cpp_transactional_memory=210500"); + cpp_define (pfile, "__cpp_transactional_memory=201500"); if (flag_sized_deallocation) cpp_define (pfile, "__cpp_sized_deallocation=201309"); if (aligned_new_threshold) --- libstdc++-v3/include/bits/c++config.jj 2018-05-10 22:40:51.010061973 +0200 +++ libstdc++-v3/include/bits/c++config 2018-06-06 15:36:49.883421506 +0200 @@ -535,7 +535,7 @@ namespace std // Most of the following conditions are due to limitations in the current // implementation. #if __cplusplus >= 201103L && _GLIBCXX_USE_CXX11_ABI \ - && _GLIBCXX_USE_DUAL_ABI && __cpp_transactional_memory >= 201505L\ + && _GLIBCXX_USE_DUAL_ABI && __cpp_transactional_memory >= 201500L\ && !_GLIBCXX_FULLY_DYNAMIC_STRING && _GLIBCXX_USE_WEAK_REF \ && _GLIBCXX_USE_ALLOCATOR_NEW #define _GLIBCXX_TXN_SAFE transaction_safe Jakub
[committed] ix86_expand_call: convert return type to rtx_insn *
Eliminate an "as_a ()" cast. Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu. I'm treating this as pre-approved, under the pre-approval on rtx -> rtx_insn * cleanups here: https://gcc.gnu.org/ml/gcc-patches/2014-08/msg01310.html Committed to trunk as r261233. gcc/ChangeLog: * config/i386/i386-protos.h (ix86_expand_call): Strengthen return type from "rtx" to "rtx_insn *". * config/i386/i386.c (ix86_expand_split_stack_prologue): Likewise for local "call_insn", removing cast. (ix86_expand_call): Likewise, introducing a "call_insn" local. --- gcc/config/i386/i386-protos.h | 2 +- gcc/config/i386/i386.c| 13 +++-- 2 files changed, 8 insertions(+), 7 deletions(-) diff --git a/gcc/config/i386/i386-protos.h b/gcc/config/i386/i386-protos.h index 40756f5..02991a5 100644 --- a/gcc/config/i386/i386-protos.h +++ b/gcc/config/i386/i386-protos.h @@ -139,7 +139,7 @@ extern bool ix86_expand_fp_vec_cmp (rtx[]); extern void ix86_expand_sse_movcc (rtx, rtx, rtx, rtx); extern void ix86_expand_sse_unpack (rtx, rtx, bool, bool); extern bool ix86_expand_int_addcc (rtx[]); -extern rtx ix86_expand_call (rtx, rtx, rtx, rtx, rtx, bool); +extern rtx_insn *ix86_expand_call (rtx, rtx, rtx, rtx, rtx, bool); extern void ix86_split_call_vzeroupper (rtx, rtx); extern void x86_initialize_trampoline (rtx, rtx, rtx); extern rtx ix86_zero_extend_to_Pmode (rtx); diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c index 637c105..9568d25 100644 --- a/gcc/config/i386/i386.c +++ b/gcc/config/i386/i386.c @@ -15064,7 +15064,8 @@ ix86_expand_split_stack_prologue (void) HOST_WIDE_INT allocate; unsigned HOST_WIDE_INT args_size; rtx_code_label *label; - rtx limit, current, allocate_rtx, call_insn, call_fusage; + rtx limit, current, allocate_rtx, call_fusage; + rtx_insn *call_insn; rtx scratch_reg = NULL_RTX; rtx_code_label *varargs_label = NULL; rtx fn; @@ -15234,7 +15235,7 @@ ix86_expand_split_stack_prologue (void) if (!TARGET_64BIT) add_reg_note (call_insn, REG_ARGS_SIZE, GEN_INT (0)); /* Indicate that this function can't jump to non-local gotos. */ - make_reg_eh_region_note_nothrow_nononlocal (as_a (call_insn)); + make_reg_eh_region_note_nothrow_nononlocal (call_insn); /* In order to make call/return prediction work right, we now need to execute a return instruction. See @@ -28466,7 +28467,7 @@ construct_plt_address (rtx symbol) return tmp; } -rtx +rtx_insn * ix86_expand_call (rtx retval, rtx fnaddr, rtx callarg1, rtx callarg2, rtx pop, bool sibcall) @@ -28681,11 +28682,11 @@ ix86_expand_call (rtx retval, rtx fnaddr, rtx callarg1, if (vec_len > 1) call = gen_rtx_PARALLEL (VOIDmode, gen_rtvec_v (vec_len, vec)); - call = emit_call_insn (call); + rtx_insn *call_insn = emit_call_insn (call); if (use) -CALL_INSN_FUNCTION_USAGE (call) = use; +CALL_INSN_FUNCTION_USAGE (call_insn) = use; - return call; + return call_insn; } /* Return true if the function being called was marked with attribute -- 1.8.5.3
Re: [Patch, Fortran] PR25829: Asynchronous I/O (v2)
Hi Nicolas,
a few other nits:
* The current patch has a large number of GNU Coding Style violations,
many catched by contrib/check_GNU_style.{sh,py}.
* Others are partially pre-existing (additional blank before formal
paramater name as in
+destroy_adv_cond (struct adv_cond * ac)
and many many more.
* Many of the new functions lack comments.
* Hardcoded escape codes in async.h.
* Several indentation and line length errors, like
+ if (au->tail)
+ internal_error(NULL, "Trying to free nonempty unit");
TAB instead of 4 spaces.
* Stuff like this in async.c at the very least needs a comment
explaining what's going on:
+#ifndef GTHREAD_USE_WEAK
+#ifdef SUPPORTS_WEAK
+#define GTHREAD_USE_WEAK 1
+#endif
+#endif
This should already be handled in gthr.h. Why not use that?
+#define _GTHREAD_USE_COND_INIT_FUNC
+#include "../../libgcc/gthr-posix.h"
Again: gthr.h would include that (via gthr-default.h) already.
As I stated, those are mostly nits, but should be fixed before this
patch goes in.
Thanks.
Rainer
--
-
Rainer Orth, Center for Biotechnology, Bielefeld University
Re: libgcov-driver-system bootstrap failure
Hi, Martin Thanks for both patches. GCC bootstrap on AIX is progressing much better with the patches installed. Thanks, David On Wed, Jun 6, 2018 at 5:05 AM Martin Liška wrote: > > On 06/06/2018 03:09 AM, David Edelsohn wrote: > > Also, there seems to be a find-and-replace mistake in libgcov-driver.c > > > > #if !GCOV_LOCKED > > /* summary for all instances of program. */ > > struct gcov_summary *cs_all; > > #endif > > > > cs_all is declared within the !GCOV_LOCKED macro > > > > but later all references have been changed to "all", not "cs_all" > > > > #if !GCOV_LOCKED > > all = &all_prg->ctrs[t_ix]; > > > > and all_prg no longer has some of the members. Was the !GCOV_LOCKED > > path not tested for the recent changes? > > Hi. > > Sorry for the breakage, I forgot to test !GCOV_LOCKED conditional compilation. > I'm sending patch candidate. I manually overwritten GCOV_LOCKED on my machine > and > verified that gcov.exp tests work. And I also checked that gcov-dump prints > correct > numbers. > > I'll install the patch later if there are no objections. > > Martin > > > > > Thanks, David > > > > On Tue, Jun 5, 2018 at 8:28 PM David Edelsohn wrote: > >> > >> Martin, > >> > >> With your recent patch, I receive the following failure building > >> libgcov-driver-system.c > >> > >> In file included from > >> /nasfarm/edelsohn/src/src/gcc/../libgcc/libgcov-driver.c:322:0: > >> /nasfarm/edelsohn/src/src/gcc/../libgcc/libgcov-driver-system.c: In > >> function 'char* replace_filename_variables(char*)': > >> /nasfarm/edelsohn/src/src/gcc/../libgcc/libgcov-driver-system.c:193:61: > >> error: 'mempcpy' was not declared in this scope > >> buffer_ptr = (char *)mempcpy (buffer_ptr, filename, start); > >> > >> mempcpy is a GLIBC extension and not defined in POSIX. There is no > >> libiberty implementation. Please avoid use of GLIBC-specific > >> functions. > >> > >> Thanks, David >
Fix PR tree-optimization/86066
process_store was wrongly bypassing a BIT_NOT_EXPR if there was a NOP_EXPR
right after it in the SSA chain.
Tested on x86-64/Linux, applied on the mainline as obvious.
2018-06-06 Eric Botcazou
PR tree-optimization/86066
* gimple-ssa-store-merging.c (process_store): Do not bypass BIT_NOT_EXPR
for BIT_INSERT_EXPR stores.
2018-06-06 Eric Botcazou
* gcc.dg/torture/pr86066.c: New test.
--
Eric BotcazouIndex: gimple-ssa-store-merging.c
===
--- gimple-ssa-store-merging.c (revision 261173)
+++ gimple-ssa-store-merging.c (working copy)
@@ -4333,7 +4333,9 @@ pass_store_merging::process_store (gimpl
&& const_bitsize <= 64)
{
/* Bypass a conversion to the bit-field type. */
- if (is_gimple_assign (def_stmt) && CONVERT_EXPR_CODE_P (rhs_code))
+ if (!bit_not_p
+ && is_gimple_assign (def_stmt)
+ && CONVERT_EXPR_CODE_P (rhs_code))
{
tree rhs1 = gimple_assign_rhs1 (def_stmt);
if (TREE_CODE (rhs1) == SSA_NAME
@@ -4341,6 +4343,7 @@ pass_store_merging::process_store (gimpl
rhs = rhs1;
}
rhs_code = BIT_INSERT_EXPR;
+ bit_not_p = false;
ops[0].val = rhs;
ops[0].base_addr = NULL_TREE;
ops[1].base_addr = NULL_TREE;
/* PR tree-optimization/86066 */
/* Testcase by Zhendong Su */
struct A
{
int b:2;
int c:2;
unsigned d:8;
};
int main ()
{
struct A t = { 0, 0, 2 };
L:
t.d = ~(~(~0 % t.d) % 2);
if (!t.d)
goto L;
return 0;
}
[PATCH] Fix PR85935
The following fixes another disconnect as to with respect to what
loop to analyze CHRECs.
Boostrap and regtest running on x86_64-unknown-linux-gnu.
Richard.
2018-06-06 Richard Biener
PR tree-optimization/85935
* graphite-scop-detection.c (find_params_in_bb): Analyze
condition operands with respect to the correct loop. Assert
the analysis doesn't fail.
* gcc.dg/graphite/pr85935.c: New testcase.
diff --git a/gcc/graphite-scop-detection.c b/gcc/graphite-scop-detection.c
index 48e40142e59..0dafc399521 100644
--- a/gcc/graphite-scop-detection.c
+++ b/gcc/graphite-scop-detection.c
@@ -1176,13 +1176,15 @@ find_params_in_bb (sese_info_p region, gimple_poly_bb_p
gbb)
/* Find parameters in conditional statements. */
gimple *stmt;
- loop_p loop = GBB_BB (gbb)->loop_father;
FOR_EACH_VEC_ELT (GBB_CONDITIONS (gbb), i, stmt)
{
+ loop_p loop = gimple_bb (stmt)->loop_father;
tree lhs = scalar_evolution_in_region (region->region, loop,
gimple_cond_lhs (stmt));
tree rhs = scalar_evolution_in_region (region->region, loop,
gimple_cond_rhs (stmt));
+ gcc_assert (!chrec_contains_undetermined (lhs)
+ && !chrec_contains_undetermined (rhs));
scan_tree_for_params (region, lhs);
scan_tree_for_params (region, rhs);
diff --git a/gcc/testsuite/gcc.dg/graphite/pr85935.c
b/gcc/testsuite/gcc.dg/graphite/pr85935.c
new file mode 100644
index 000..8c63ea93770
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/graphite/pr85935.c
@@ -0,0 +1,25 @@
+/* { dg-do compile } */
+/* { dg-options "-O -floop-parallelize-all -fno-tree-loop-im --param
scev-max-expr-size=3" } */
+
+typedef int dq;
+
+int gb;
+
+void
+qq (dq ww, int kk)
+{
+ dq *up = &ww;
+
+ (void) *up;
+
+ while (kk < 1)
+{
+ ++ww;
+
+ if (ww == 0)
+ for (gb = 0; gb < 2; ++gb)
+ ;
+
+ ++kk;
+}
+}
[PATCH] Fix PR86062
I was overly cautionous when implementing this part of VN translation
but given the code is never executed from PRE (and thus the result
will never be inserted as real code) there's no TBAA issue to be
avoided.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
>From b44f9be5b45bdf9c3604fcb78ba96cedfb7efa78 Mon Sep 17 00:00:00 2001
From: Richard Guenther
Date: Wed, 6 Jun 2018 12:16:38 +0200
Subject: [PATCH] fix-pr86062
2018-06-06 Richard Biener
PR tree-optimization/86062
* tree-ssa-sccvn.c (vn_reference_lookup_3): Handle arbitrary
component refs ontop
of to be offsetted base.
* g++.dg/tree-ssa/pr86062.C: New testcase.
diff --git a/gcc/testsuite/g++.dg/tree-ssa/pr86062.C
b/gcc/testsuite/g++.dg/tree-ssa/pr86062.C
new file mode 100644
index 000..d62bdf6d2f7
--- /dev/null
+++ b/gcc/testsuite/g++.dg/tree-ssa/pr86062.C
@@ -0,0 +1,23 @@
+// { dg-do compile }
+// { dg-require-effective-target c++14 }
+// { dg-options "-O2 -ffinite-math-only -fdump-tree-fre1" }
+
+#include
+
+struct I { double i,s; I(double d):i(d),s(d){} };
+typedef std::array P;
+typedef std::array AP;
+
+static AP c(P const&p){
+ return {p[0],p[1],p[2]};
+}
+template auto const& ac(T const&p, int n){return p[n];}
+static double g(P const&p, int n)
+{
+I res = ac(c(p),n);
+ return res.s-res.i;
+}
+
+__attribute__((flatten)) double fff(P p){ return g(p,1); }
+
+// { dg-final { scan-tree-dump "return 0.0;" "fre1" } }
diff --git a/gcc/tree-ssa-sccvn.c b/gcc/tree-ssa-sccvn.c
index 4e946ba7baf..4aec41e96c1 100644
--- a/gcc/tree-ssa-sccvn.c
+++ b/gcc/tree-ssa-sccvn.c
@@ -2270,14 +2270,16 @@ vn_reference_lookup_3 (ao_ref *ref, tree vuse, void
*vr_,
/* Apply an extra offset to the inner MEM_REF of the RHS. */
if (maybe_ne (extra_off, 0))
{
- if (rhs.length () < 2
- || rhs[0].opcode != MEM_REF
- || known_eq (rhs[0].off, -1))
+ if (rhs.length () < 2)
return (void *)-1;
- rhs[0].off += extra_off;
- rhs[0].op0 = int_const_binop (PLUS_EXPR, rhs[0].op0,
- build_int_cst (TREE_TYPE (rhs[0].op0),
- extra_off));
+ int ix = rhs.length () - 2;
+ if (rhs[ix].opcode != MEM_REF
+ || known_eq (rhs[ix].off, -1))
+ return (void *)-1;
+ rhs[ix].off += extra_off;
+ rhs[ix].op0 = int_const_binop (PLUS_EXPR, rhs[ix].op0,
+build_int_cst (TREE_TYPE (rhs[ix].op0),
+ extra_off));
}
/* We need to pre-pend vr->operands[0..i] to rhs. */
Re: [PATCH (for gdb)] enum-flags.h: Add trailing semicolon to example in comment
On Tue, 2018-06-05 at 18:31 +0100, Pedro Alves wrote: > [adding gdb-patches] > > On 06/05/2018 06:56 PM, David Malcolm wrote: > > On Tue, 2018-06-05 at 17:13 +0100, Pedro Alves wrote: > > > On 06/05/2018 03:49 PM, David Malcolm wrote: > > > > On Tue, 2018-06-05 at 04:40 -0400, Trevor Saunders wrote: > > > > > You may want to look at gdb's enum-flags.h which I think > > > > > already > > > > > implements what your doing here. > > > > > > > > Aha! Thanks! > > > > > > > > Browsing the git web UI, that gdb header was introduced by > > > > Pedro > > > > Alves > > > > in: > > > > https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=co > > > > mmit > > > > diff;h=8d297bbf604c8318ffc72d5a7b3db654409c5ed9 > > > > and the current state is here: > > > > https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=bl > > > > ob;f > > > > =gdb/common/enum-flags.h;hb=HEAD > > > > > > > > I'll try this out with GCC; hopefully it works with C++98. > > > > > > It should -- it was written/added while GDB still required C++98. > > > > Thanks. > > > > > Note I have a WIP series here: > > > > > > https://github.com/palves/gdb/commits/palves/cxx11-enum-flags > > > > > > that fixes a few things, and adds a bunch of unit tests. In > > > the process, it uses C++11 constructs (hence the branch's name), > > > but I think that can be reverted to still work with C++98. > > > > > > I had seen some noises recently about GCC maybe considering > > > requiring C++11. Is that reasonable to expect in this cycle? > > > (GDB requires GCC 4.8 or later, FWIW.) > > > > I'm expecting that GCC 9 will still require C++98. > > OK. > > > > > > Getting that branch into master had fallen lower on my TODO, > > > but if there's interest, I can try to finish it off soon, so we > > > can share a better baseline. (I posted it once, but found > > > some issues which I fixed since but never managed to repost.) > > > > Interestingly, it looks like gdb is using Google Test for > > selftests; > > gcc is using a hand-rolled API that is similar, but has numerous > > differences (e.g. explicit calling of test functions, rather than > > implicit test discovery). So that's another area of drift between > > the projects. > > Nope, the unit tests framework is hand rolled too. See > gdb/selftest.h/c. > It can be invoked with gdb's "maint selftest" command. > You can see the list of tests with "maint info selftests", and > you can pass a filter to "maint selftest" too. Aha. Thanks. Looks like gdb and gcc each have different hand-rolled selftest APIs: * gdb's selftest.h/c has manual test registration; test failures are handled via exceptions * gcc's selftest.h/c has no test registration (test functions are called explicitly); test failures are handled via "abort" I'm not suggesting we try to unify these APIs at this time. > > > > > > > > Presumably it would be good to share this header between GCC > > > > and > > > > GDB; > > > > CCing Pedro; Pedro: hi! Does this sound sane? > > > > (for reference, the GCC patch we're discussing here is: > > > > https://gcc.gnu.org/ml/gcc-patches/2018-05/msg01685.html ) > > > > > > Sure! > > > > Alternatively, if GCC needs to stay at C++98 and GDB moves on to > > C++11, > > then we can at least take advantage of this tested and FSF-assigned > > C++98 code (better than writing it from scratch). > > Agreed, but I'll try to see about making the fixes in the branch > C++98 compatible. Thanks. > > > > I ran into one issue with the header, e.g. with: > > > > /* Dump flags type. */ > > DEF_ENUM_FLAGS_TYPE(enum dump_flag, dump_flags_t); > > > > This doesn't work: > > TDF_SLIM | flags > > but this does: > > flags | TDF_SLIM > > where TDF_SLIM is one of the values of "enum dump_flag". > > ISTR that that's fixed in the branch. Interesting; I'll have a look. > > BTW, I spotted this trivial issue in a comment in enum-flags.h > > whilst > > trying it out for gcc: > > > > > > > > The DEF_ENUM_FLAGS_TYPE macro should be used with a trailing > > semicolon, but the example in the comment lacks one. > > > > * enum-flags.h: Add trailing semicolon to example in comment. > > Thanks. I've merged it. Thanks. [...snip...] Dave
Re: [Patch, Fortran] PR25829: Asynchronous I/O (v2)
Hi Jakub, >> I do note that if one has, say, 8 files and only one >> file uses async IO, then during linking of the 8 *.o >> files to make the final execute -lpthread must be added. >> How doesn't gfortran communicate that to the loader? > > ELF doesn't a way to do this, you'd need to add a special linker plugin for > that. But is that really necessary? > Simply let the users link with -lpthread or -pthread if they want real > asynchronous IO, or without it if they are ok with the gcc <= 8 > behavior and document it. wouldn't it be better to use a special gfortran flag for that? -pthread/-lpthread is an implementation detail on some platforms, but others may not need it (Solaris has folded libpthread into libc and there are no more single-threaded processes, for example) or need something different for async io (Windows, ...). IMO it would be better to abstract this low-level detail away and let the driver DTRT, under the control of a flag if need be. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [PATCH] [MSP430] Allow interrupt handers to be static and fix __interrupt__ attribute causing an ICE
On 29/05/18 23:55, DJ Delorie wrote: Jozef Lawrynowicz writes: If an argument is passed to the interrupt attribute, GCC will create a section for the interrupt vector when outputting the assembly. This, combined with the code to ensure the interrupt function doesn't get optimized out, ensures the symbol for the interrupt function is available when it comes to linking. I did also test on hardware that static interrupts works as expected, and they do. It sounds like things have changed since I first wrote that code, so as long as it works now, I'm OK with it :-) Thanks, installed on trunk.
Re: Extend tree code folds to IFN_COND_*
On Thu, May 24, 2018 at 11:36 AM Richard Sandiford
wrote:
>
> This patch adds match.pd support for applying normal folds to their
> IFN_COND_* forms. E.g. the rule:
>
> (plus @0 (negate @1)) -> (minus @0 @1)
>
> also allows the fold:
>
> (IFN_COND_ADD @0 @1 (negate @2) @3) -> (IFN_COND_SUB @0 @1 @2 @3)
>
> Actually doing this by direct matches in gimple-match.c would
> probably lead to combinatorial explosion, so instead, the patch
> makes gimple_match_op carry a condition under which the operation
> happens ("cond"), and the value to use when the condition is false
> ("else_value"). Thus in the example above we'd do the following
>
> (a) convert:
>
> cond:NULL_TREE (IFN_COND_ADD @0 @1 @4 @3) else_value:NULL_TREE
>
> to:
>
> cond:@0 (plus @1 @4) else_value:@3
>
> (b) apply gimple_resimplify to (plus @1 @4)
>
> (c) reintroduce cond and else_value when constructing the result.
>
> Nested operations inherit the condition of the outer operation
> (so that we don't introduce extra faults) but have a null else_value.
> If we try to build such an operation, the target gets to choose what
> else_value it can handle efficiently: obvious choices include one of
> the operands or a zero constant. (The alternative would be to have some
> representation for an undefined value, but that seems a bit invasive,
> and isn't likely to be useful here.)
>
> I've made the condition a mandatory part of the gimple_match_op
> constructor so that it doesn't accidentally get dropped.
>
> Tested on aarch64-linux-gnu (with and without SVE), aarch64_be-elf
> and x86_64-linux-gnu. OK to install?
It looks somewhat clever but after looking for a while it doesn't handle
simplifying
(IFN_COND_ADD @0 @1 (IFN_COND_SUB @0 @2 @1 @3) @3)
to
(cond @0 @2 @3)
right? Because while the conditional gimple_match_op is built
by try_conditional_simplification it isn't built when doing
SSA use->def following in the generated matching code?
So it looks like a bit much noise for this very special case?
I suppose you ran into the need of these foldings from looking
at real code - which foldings specifically were appearing here?
Usually code is well optimized before if-conversion/vectorization
so we shouldn't need full-blown handling?
That said, I'm not sure how much work it is to massage
if (gimple *def_stmt = get_def (valueize, op2))
{
if (gassign *def = dyn_cast (def_stmt))
switch (gimple_assign_rhs_code (def))
{
case PLUS_EXPR:
to look like
if (gimple *def_stmt = get_def (valueize, op2))
{
code = ERROR_MARK;
if (!is_cond_ifn_with_cond (curr_gimple_match_op, &code))
if (gassign *def dyn_cast (def_stmt))
code = gimple_assign_rhs_code (def);
switch (code)
{
case PLUS_EXPR:
thus transparently treat the IFN_COND_* as their "code" if the condition
matches that of the context (I'm not sure if we can do anything for
mismatching contexts).
Richard.
> Richard
>
>
> 2018-05-24 Richard Sandiford
>
> gcc/
> * target.def (preferred_else_value): New target hook.
> * doc/tm.texi.in (TARGET_PREFERRED_ELSE_VALUE): New hook.
> * doc/tm.texi: Regenerate.
> * targhooks.h (default_preferred_else_value): Declare.
> * targhooks.c (default_preferred_else_value): New function.
> * internal-fn.h (conditional_internal_fn_code): Declare.
> * internal-fn.c (FOR_EACH_CODE_MAPPING): New macro.
> (get_conditional_internal_fn): Use it.
> (conditional_internal_fn_code): New function.
> * gimple-match.h (gimple_match_cond): New struct.
> (gimple_match_op): Add a cond member function.
> (gimple_match_op::gimple_match_op): Update all forms to take a
> gimple_match_cond.
> * genmatch.c (expr::gen_transform): Use the same condition as res_op
> for the suboperation, but don't specify a particular else_value.
> * tree-ssa-sccvn.c (vn_nary_simplify, vn_reference_lookup_3)
> (visit_nary_op, visit_reference_op_load): Pass
> gimple_match_cond::UNCOND to the gimple_match_op constructor.
> * gimple-match-head.c: Include tree-eh.h
> (convert_conditional_op): New function.
> (maybe_resimplify_conditional_op): Likewise.
> (gimple_resimplify1): Call maybe_resimplify_conditional_op.
> (gimple_resimplify2): Likewise.
> (gimple_resimplify3): Likewise.
> (gimple_resimplify4): Likewise.
> (maybe_push_res_to_seq): Return null for conditional operations.
> (try_conditional_simplification): New function.
> (gimple_simplify): Call it. Pass conditions to the gimple_match_op
> constructor.
> * match.pd: Fold VEC_COND_EXPRs of an IFN_COND_* call to a new
> IFN_COND_* call.
> * config/aarch64/aarch64.c (aarch64_preferred_else_value): New
> function.
>
Re: [PATCH][RFC] Drop GENERIC conds in [VEC_]COND_EXPRs
On Tue, 5 Jun 2018, Richard Biener wrote:
>
> This is a prototype enforcing is_gimple_val conditions in
> [VEC_]COND_EXPRs. It shows quite some fallout - some likely
> due to necessary testsuite adjustments like gcc.dg/tree-ssa/ssa-lim-12.c
> others because some code simply doesn't handle conditions visible
> only via following SSA defs like vect_recog_mixed_size_cond_pattern.
>
> So on x86_64 there's quite some vect.exp fallout.
>
> Anyhow, to assess the effect on other targets I'm throwing this
> in here.
>
> I've hopefully nailed all ICEs (or at least makes catching them
> easy with some asserts in GIMPLE stmt building).
>
> Full bootstrap and regtest for all languages running on
> x86_64-unknown-linux-gnu.
Testing shows a few omissions in the patch (updated patch attached
below). It also shows that expand_vec_cond_expr_p and friends
need some heavy lifting to deal with vcond* patterns which have
the comparison embedded. There's vcond_mask* which would be
more suited to the GIMPLE we have after this patch and I suspect
we can always expand
_1 = _2 < _3;
_4 = _1 ? _5 : _66;
as
_1 = _2 < _3 ? { -1,...} : {0,...}; via vcond_*
_4 = _1 != 0 ? _5 : _6; via vcond_*
at expansion time TER might come to the rescue, if there are multiple
uses of _1 then there's cost issues to honor in case _1 = _2 < _3
can be expanded more efficiently than via such fake vcond_*.
In any case the expander now needs to be made more smart
(as well as the pattern recog part of the vectorizer).
Jakub - I remember you weren't too happy about splitting the
conditions out of [VEC_]COND_EXPRs this came up last time?
With the alternative idea of transitioning [VEC_]COND_EXPRs to
tcc_comparisons with conditional ops aka
_1 = _2 < _3 ? _5 : _6;
with RHS code LT_EXPR and 4 operands what do you think of
Richards complaint about being forced to repeat _2 < _3?
A split out _2 < _3 would then look like
_4 = _2 < _3 ? {-1,...} : {0,...};
_1 = _4 != {0,...} ? _5 : _6;
so "plain" LT_EXPR rhs wouldn't be supported anymore but they'd
always have explicit true and false values attached. With making
the last two ops optional we could make them implicit again of course.
We could also keep [VEC_]COND_EXPR then in 3-operand form with
a gimple-val predicate rather than a comparison. Of course that
wouldn't really simplify the IL overall...
Richard.
>From bf05ad5789bb79452364c0e22f798b66013a0919 Mon Sep 17 00:00:00 2001
From: Richard Guenther
Date: Tue, 5 Jun 2018 16:09:26 +0200
Subject: [PATCH] vec_cond_expr_gimple_val
vect_recog_mixed_size_cond_pattern will be disabled
diff --git a/gcc/gimple-loop-interchange.cc b/gcc/gimple-loop-interchange.cc
index eb35263e69c..23fbed590e0 100644
--- a/gcc/gimple-loop-interchange.cc
+++ b/gcc/gimple-loop-interchange.cc
@@ -891,7 +891,9 @@ loop_cand::undo_simple_reduction (reduction_p re, bitmap
dce_seeds)
/* Init new_var to MEM_REF or CONST depending on if it is the first
iteration. */
induction_p iv = m_inductions[0];
- cond = fold_build2 (NE_EXPR, boolean_type_node, iv->var, iv->init_val);
+ cond = make_ssa_name (boolean_type_node);
+ stmt = gimple_build_assign (cond, NE_EXPR, iv->var, iv->init_val);
+ gimple_seq_add_stmt_without_update (&stmts, stmt);
new_var = copy_ssa_name (re->var);
stmt = gimple_build_assign (new_var, COND_EXPR, cond, tmp, re->init);
gimple_seq_add_stmt_without_update (&stmts, stmt);
diff --git a/gcc/gimple.c b/gcc/gimple.c
index 4b91151873c..24d7963117e 100644
--- a/gcc/gimple.c
+++ b/gcc/gimple.c
@@ -442,6 +442,8 @@ gimple_build_assign_1 (tree lhs, enum tree_code subcode,
tree op1,
gimple_build_with_ops_stat (GIMPLE_ASSIGN, (unsigned)subcode, num_ops
PASS_MEM_STAT));
gimple_assign_set_lhs (p, lhs);
+ gcc_assert ((subcode != COND_EXPR && subcode != VEC_COND_EXPR)
+ || is_gimple_val (op1));
gimple_assign_set_rhs1 (p, op1);
if (op2)
{
@@ -1691,6 +1693,8 @@ gimple_assign_set_rhs_with_ops (gimple_stmt_iterator
*gsi, enum tree_code code,
gimple_set_num_ops (stmt, new_rhs_ops + 1);
gimple_set_subcode (stmt, code);
+ gcc_assert ((code != COND_EXPR && code != VEC_COND_EXPR)
+ || is_gimple_val (op1));
gimple_assign_set_rhs1 (stmt, op1);
if (new_rhs_ops > 1)
gimple_assign_set_rhs2 (stmt, op2);
diff --git a/gcc/gimplify.c b/gcc/gimplify.c
index 44cb784620a..b679241e377 100644
--- a/gcc/gimplify.c
+++ b/gcc/gimplify.c
@@ -3899,7 +3899,7 @@ gimplify_pure_cond_expr (tree *expr_p, gimple_seq *pre_p)
TREE_SET_CODE (cond, TRUTH_AND_EXPR);
else if (code == TRUTH_ORIF_EXPR)
TREE_SET_CODE (cond, TRUTH_OR_EXPR);
- ret = gimplify_expr (&cond, pre_p, NULL, is_gimple_condexpr, fb_rvalue);
+ ret = gimplify_expr (&cond, pre_p, NULL, is_gimple_val, fb_rvalue);
COND_EXPR_COND (*expr_p) = cond;
tret = gimplify_expr (&COND_EXPR_THEN (expr), pre_p, NULL,
@@ -12078,7 +12078,7 @@ gimplify_expr (tree *exp
Re: [Patch, Fortran] PR25829: Asynchronous I/O (v2)
On Tue, Jun 05, 2018 at 11:47:21PM -0700, Steve Kargl wrote: > I have not looked at the source code, but do have a question. > With -fopenmp, gfortran automatically adds -lpthread to > the command line. Is it possible during the parsing Even if it wouldn't, libgomp.so.1 depends on libpthread.so.0 and thus it will be around. > phase to detect an async structure and on the fly add > -lpthread to the loader options? > > I do note that if one has, say, 8 files and only one > file uses async IO, then during linking of the 8 *.o > files to make the final execute -lpthread must be added. > How doesn't gfortran communicate that to the loader? ELF doesn't a way to do this, you'd need to add a special linker plugin for that. But is that really necessary? Simply let the users link with -lpthread or -pthread if they want real asynchronous IO, or without it if they are ok with the gcc <= 8 behavior and document it. Jakub
Re: [PATCH] [MSP430] Fix device name symbol defined for MSP430i series of devices
On 04/06/18 18:52, DJ Delorie wrote: Jozef Lawrynowicz writes: For the currently released msp430i* devices, only digits follow the i, so no upper or lower case conversion is needed. Thinking of the future... do we expect any new devices with letters? Should we plan for them? Or better to wait, in case there are more lower-case-letter symbols? Just trying to think of all the possibilities here. Word from TI is that the lowercase i is an exception, the rule is to have all uppercase letters. No further msp430i devices are planned so the rules for generating device names in this patch shouldn't need any future changes.
Re: [Patch, Fortran] PR25829: Asynchronous I/O
On 06/04/2018 11:21 PM, JonY wrote: > On 06/03/2018 06:59 PM, Nicolas Koenig wrote: >> Hello everyone, >> >> this patch adds asynchronous I/O support. Thomas and I finally finished >> a feature-complete and debugged version, so here it is. In order to use >> asynchronous I/O, it is still necessary to link against libpthread, >> libgomp or another library linked against any of the aforementioned two. >> While it might not be the nicest way, it at least keeps in line with the >> likes of ifort. Two of the test I send deal with asynchronous error >> handling, so they will fail if not linked accordingly. >> >> Since the implementation relies on pthreads, it would be great if >> somebody could try the patch on non-linux targets, to see whether it >> causes any problems there. >> >> Let the rain of regressions begin ;) >> >> Nicolas >> >> P.S.: I would very much recommend removing the #undef DEBUG in async.h. >> I have to admit, I am quite proud of the debug printouts. They even >> build a data structure in the background telling you were a locked mutex >> was locked. > > I'm not too familiar with Fortran, but I'll test it out over the > weekends with the asynchronous_9.f90 program. > > Looks like v1 is working with x86_64-w64-mingw32 and winpthreads, I don't have the mail for v2, strangely. signature.asc Description: OpenPGP digital signature
Re: libgcov-driver-system bootstrap failure
On 06/06/2018 03:09 AM, David Edelsohn wrote:
> Also, there seems to be a find-and-replace mistake in libgcov-driver.c
>
> #if !GCOV_LOCKED
> /* summary for all instances of program. */
> struct gcov_summary *cs_all;
> #endif
>
> cs_all is declared within the !GCOV_LOCKED macro
>
> but later all references have been changed to "all", not "cs_all"
>
> #if !GCOV_LOCKED
> all = &all_prg->ctrs[t_ix];
>
> and all_prg no longer has some of the members. Was the !GCOV_LOCKED
> path not tested for the recent changes?
Hi.
Sorry for the breakage, I forgot to test !GCOV_LOCKED conditional compilation.
I'm sending patch candidate. I manually overwritten GCOV_LOCKED on my machine
and
verified that gcov.exp tests work. And I also checked that gcov-dump prints
correct
numbers.
I'll install the patch later if there are no objections.
Martin
>
> Thanks, David
>
> On Tue, Jun 5, 2018 at 8:28 PM David Edelsohn wrote:
>>
>> Martin,
>>
>> With your recent patch, I receive the following failure building
>> libgcov-driver-system.c
>>
>> In file included from
>> /nasfarm/edelsohn/src/src/gcc/../libgcc/libgcov-driver.c:322:0:
>> /nasfarm/edelsohn/src/src/gcc/../libgcc/libgcov-driver-system.c: In
>> function 'char* replace_filename_variables(char*)':
>> /nasfarm/edelsohn/src/src/gcc/../libgcc/libgcov-driver-system.c:193:61:
>> error: 'mempcpy' was not declared in this scope
>> buffer_ptr = (char *)mempcpy (buffer_ptr, filename, start);
>>
>> mempcpy is a GLIBC extension and not defined in POSIX. There is no
>> libiberty implementation. Please avoid use of GLIBC-specific
>> functions.
>>
>> Thanks, David
>From d1913b67feed71614a3d687c9288297d6b4a200a Mon Sep 17 00:00:00 2001
From: marxin
Date: Wed, 6 Jun 2018 11:02:17 +0200
Subject: [PATCH] Fix compilation of libgcov with GCOV_LOCKED=0.
libgcc/ChangeLog:
2018-06-06 Martin Liska
* libgcov-driver.c: Rename cs_all to all and assign it from
all_prg.
---
libgcc/libgcov-driver.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libgcc/libgcov-driver.c b/libgcc/libgcov-driver.c
index 922d9dde833..d718942978b 100644
--- a/libgcc/libgcov-driver.c
+++ b/libgcc/libgcov-driver.c
@@ -581,7 +581,7 @@ merge_summary (const char *filename __attribute__ ((unused)), int run_counted,
{
#if !GCOV_LOCKED
/* summary for all instances of program. */
- struct gcov_summary *cs_all;
+ struct gcov_summary *all;
#endif
/* Merge the summary. */
@@ -601,7 +601,7 @@ merge_summary (const char *filename __attribute__ ((unused)), int run_counted,
else
gcov_histogram_merge (prg->histogram, this_prg->histogram);
#if !GCOV_LOCKED
- all = &all_prg->ctrs[t_ix];
+ all = all_prg;
if (!all->runs && prg->runs)
{
all->num = prg->num;
--
2.17.0
Re: libgcov-driver-system bootstrap failure
On 06/06/2018 02:28 AM, David Edelsohn wrote:
> Martin,
>
> With your recent patch, I receive the following failure building
> libgcov-driver-system.c
>
> In file included from
> /nasfarm/edelsohn/src/src/gcc/../libgcc/libgcov-driver.c:322:0:
> /nasfarm/edelsohn/src/src/gcc/../libgcc/libgcov-driver-system.c: In
> function 'char* replace_filename_variables(char*)':
> /nasfarm/edelsohn/src/src/gcc/../libgcc/libgcov-driver-system.c:193:61:
> error: 'mempcpy' was not declared in this scope
> buffer_ptr = (char *)mempcpy (buffer_ptr, filename, start);
>
> mempcpy is a GLIBC extension and not defined in POSIX. There is no
> libiberty implementation. Please avoid use of GLIBC-specific
> functions.
>
> Thanks, David
>
Hi David.
Sorry for the breakage. I'm sending patch where I replace mempcpy with memcpy.
Apart from that I realized that we need to allocate memory for each individual
gf->filename
in gcov_exit_open_gcda_file. That's due to fact that expansion of ENV variables
can extend
maximum expected length of a filename. Thus max_length is not now needed.
Patch can survives gcov.exp test-suite and I verified that valgrind is happy
for various
-fprofile-generate values with expansion variables provided.
Martin
>From e3675ab3eebe27b4112c9fd3a2b4bb28a6ce60fd Mon Sep 17 00:00:00 2001
From: marxin
Date: Wed, 6 Jun 2018 10:44:47 +0200
Subject: [PATCH] Fix libgcov-driver-system bootstrap failure.
libgcc/ChangeLog:
2018-06-06 Martin Liska
* libgcov-driver-system.c (replace_filename_variables): Use
memcpy instead of mempcpy.
(allocate_filename_struct): Do not allocate filename, allocate
prefix and set it.
(gcov_exit_open_gcda_file): Allocate memory for gf->filename
here and properly copy content into it.
* libgcov-driver.c (struct gcov_filename): Remove max_length
field, change prefix from size_t into char *.
(compute_summary): Do not calculate longest filename.
(gcov_do_dump): Release memory of gf.filename after each file.
* libgcov-util.c (compute_summary): Use new signature of
compute_summary.
(calculate_overlap): Likewise.
---
libgcc/libgcov-driver-system.c | 34 +-
libgcc/libgcov-driver.c| 23 +--
libgcc/libgcov-util.c | 7 +++
3 files changed, 37 insertions(+), 27 deletions(-)
diff --git a/libgcc/libgcov-driver-system.c b/libgcc/libgcov-driver-system.c
index 7f3de631701..8c1fef00456 100644
--- a/libgcc/libgcov-driver-system.c
+++ b/libgcc/libgcov-driver-system.c
@@ -190,9 +190,12 @@ replace_filename_variables (char *filename)
char *buffer = (char *)xmalloc (start + end + repl_length + 1);
char *buffer_ptr = buffer;
- buffer_ptr = (char *)mempcpy (buffer_ptr, filename, start);
- buffer_ptr = (char *)mempcpy (buffer_ptr, replacement, repl_length);
- buffer_ptr = (char *)mempcpy (buffer_ptr, p, end);
+ buffer_ptr = (char *)memcpy (buffer_ptr, filename, start);
+ buffer_ptr += start;
+ buffer_ptr = (char *)memcpy (buffer_ptr, replacement, repl_length);
+ buffer_ptr += repl_length;
+ buffer_ptr = (char *)memcpy (buffer_ptr, p, end);
+ buffer_ptr += end;
*buffer_ptr = '\0';
free (filename);
@@ -210,6 +213,7 @@ allocate_filename_struct (struct gcov_filename *gf)
const char *gcov_prefix;
size_t prefix_length;
int strip = 0;
+ gf->filename = NULL;
{
/* Check if the level of dirs to strip off specified. */
@@ -239,12 +243,16 @@ allocate_filename_struct (struct gcov_filename *gf)
gcov_prefix = ".";
prefix_length = 1;
}
- gf->prefix = prefix_length;
/* Allocate and initialize the filename scratch space. */
- gf->filename = (char *) xmalloc (gf->max_length + prefix_length + 2);
if (prefix_length)
-memcpy (gf->filename, gcov_prefix, prefix_length);
+{
+ gf->prefix = (char *) xmalloc (prefix_length + 1);
+ char *p = (char *) memcpy (gf->prefix, gcov_prefix, prefix_length);
+ *(p + prefix_length) = '\0';
+}
+ else
+gf->prefix = NULL;
}
/* Open a gcda file specified by GI_FILENAME.
@@ -255,7 +263,7 @@ gcov_exit_open_gcda_file (struct gcov_info *gi_ptr,
struct gcov_filename *gf)
{
const char *fname = gi_ptr->filename;
- char *dst = gf->filename + gf->prefix;
+ int append_slash = 0;
fname = gi_ptr->filename;
@@ -288,9 +296,17 @@ gcov_exit_open_gcda_file (struct gcov_info *gi_ptr,
fname += 2;
if (!IS_DIR_SEPARATOR (*fname))
- *dst++ = '/';
+ append_slash = 1;
}
- strcpy (dst, fname);
+
+ size_t prefix_length = gf->prefix ? strlen (gf->prefix) : 0;
+ gf->filename = (char *) xmalloc (prefix_length + strlen (fname) + 2);
+ *gf->filename = '\0';
+ if (prefix_length)
+strcat (gf->filename, gf->prefix);
+ if (append_slash)
+*gf->filename++ = '/';
+ strcat (gf->filename, fname);
gf->filename = replace_filename_variables (gf->filename);
diff --git a/libgcc/libgcov-driver.c b/libgcc/libgcov-driver.c
index 922d9dde833..7
