[RFA] fix copyright year range in libstdc++ test file (was: "Re: [v3 PATCH] Implement std::string_view and P0254r2, Integrating std::string_view and std::string.")
Hello,
In working on updating the copyright year notices for the GDB files,
I noticed something very minor regarding the patch which added the
file below (the same file was copied in gdb's testsuite); it looks
like the year range for one of the files is truncated:
| diff --git
a/libstdc++-v3/testsuite/21_strings/basic_string_view/element_access/char/empty.cc
b/libstdc++-v3/testsuite/21_strings/basic_string_view/element_access/char/empty.cc
| new file mode 100644
| index 000..c0f8206
| --- /dev/null
| +++
b/libstdc++-v3/testsuite/21_strings/basic_string_view/element_access/char/empty.cc
| @@ -0,0 +1,40 @@
| +// { dg-options "-std=gnu++17" }
| +
| +// Copyright (C) 3 Free Software Foundation, Inc.
The file was contributed around July 2016, so it should be at least
2016-2018 now, but, looking at all the other test files around,
all ranges start with 2013, so I suspect the intention was for
this file to be the same. This is what the attached patch proposes.
libstdc++-v3/ChangeLog:
* testsuite/21_strings/basic_string_view/element_access/char/empty.cc:
Fix year range in copyright header.
OK for trunk?
One a fix pushed to GCC, I will take care of the GDB side.
Thank you,
--
Joel
>From a29191e526c1aeed7da592af3e9bb51c7db8c297 Mon Sep 17 00:00:00 2001
From: Joel Brobecker
Date: Tue, 1 Jan 2019 09:40:00 +0400
Subject: [PATCH] Fix year range in libstdc++v3/testsuite/.../empty.cc
copyright header
libstdc++-v3/ChangeLog:
* testsuite/21_strings/basic_string_view/element_access/char/empty.cc:
Fix year range in copyright header.
---
.../21_strings/basic_string_view/element_access/char/empty.cc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libstdc++-v3/testsuite/21_strings/basic_string_view/element_access/char/empty.cc b/libstdc++-v3/testsuite/21_strings/basic_string_view/element_access/char/empty.cc
index fad5eb798ba..bf577882d6f 100644
--- a/libstdc++-v3/testsuite/21_strings/basic_string_view/element_access/char/empty.cc
+++ b/libstdc++-v3/testsuite/21_strings/basic_string_view/element_access/char/empty.cc
@@ -1,6 +1,6 @@
// { dg-options "-std=gnu++17" }
-// Copyright (C) 3 Free Software Foundation, Inc.
+// Copyright (C) 2013-2019 Free Software Foundation, Inc.
//
// This file is part of the GNU ISO C++ Library. This library is free
// software; you can redistribute it and/or modify it under the
--
2.17.1
Re: [patch, rfa] Fix PR other/16615, change "can not" to "cannot" throughout docs and code
On Fri, 28 Dec 2018, Sandra Loosemore wrote: > Taken individually, all these changes probably qualify as obvious, but given > how extensive they are and how many files are touched, I thought it would be > good to get a sanity check on methodology before checking in the whole pile. > E.g. are there other files that should be excluded from the recipe for part 1? gcc/go/gofrontend/ and libgo/ have their own commit processes involving applying fixes to another repository first (and no ChangeLogs). Unfortunately the URL to that repository in gcc/go/README.gcc and libgo/README.gcc no longer works. I think the same applies to gcc/d/dmd/, though I'm not sure the process there is documented anywhere. Likewise for parts of libphobos (although that has a ChangeLog for the GCC-local build machinery). The .po files come verbatim from the Translation Project; it's useless to patch those locally in GCC since the changes will be overwritten by the next copy from the TP. gettext's fuzzy match machinery should suffice to help translators match their old translation of a "can not" message to the new "cannot" message. I don't really think patching such issues in testcases is useful; certainly not for the ACATS tests coming from an upstream source. (Testsuite .exp files would be more like normal sources in this regard and should get spelling fixes etc., but I don't see any such files affected by your changes.) libtool.m4 and ltmain.sh come from upstream libtool; this seems like an issue that should be fixed there (if still present, our libtool version is very old), not patched locally in GCC. Not patching libtool.m4 locally might eliminate at least some of the configure regenerations. For tm.texi, make sure the changes exactly correspond to the result of regenerating given the target.def changes. For changes to include/ and libiberty/, it's helpful to apply them to binutils-gdb at the same time as GCC (the shared files and directories aren't always exactly in sync between the two repositories, but should be, and I'd consider copying a change from one to the other to be obvious). -- Joseph S. Myers jos...@codesourcery.com
Re: v2 [PATCH] Fixes for PR68356, PR81210, and PR81693
On Dec 29, 2018, at 5:13 AM, Dominique d'Humières wrote: > > New patch for taking into account the comments in > https://gcc.gnu.org/ml/gcc-patches/2017-11/msg01003.html > > 2018-12-29 Dominique d'Humieres > >PR tree-optimization/68356 >PR target/81210 >PR target/81693 >* gcc.dg/torture/pr68264.c: Skip on darwin. >* gcc.dg/torture/pr68037-1.c: Likewise. >* gcc.dg/torture/pr68037-2.c: Likewise. >* gcc.dg/torture/pr68037-3.c: Likewise. >* gcc.dg/torture/pr25967-1.c: Likewise. >* gcc.dg/torture/pr25967-2.c: Likewise. > > OK to commit to trunk and the gcc-8 branch? Ok.
Re: [committed] Replace type/fuzzy arguments with a single enum
On 12/31/18 1:29 AM, Bernd Edlinger wrote: > Hi Jeff, > > > I wonder if it would make sense at this point to rename one of the two > get_strlen_range functions? > > I always found it hard to tell which function is actually meant when they only > differ in the number of parameters. Yes, but I don't want to do it right now. I'd rather flush out these issues. The overloads are maddeningly confusing unless you're immersed in the code. jeff
Re: [committed] : Enable building pa-d.c on all hppa targets
On Sat, 29 Dec 2018 at 19:19, John David Anglin wrote: > > The attached patch enables building pa-c.d on all hppa targets. Tested > on hppa64-linux-gnu, > hppa64-hp-hpux11.11 and hppa2.0w-hp-hpux11.11. > > https://gcc.gnu.org/ml/gcc-testresults/2018-12/msg03264.html > https://gcc.gnu.org/ml/gcc-testresults/2018-12/msg02928.html > > As can be seen, the 64-bit test results are much better than the 32-bit > results. > Thanks, maybe raise a bug report for that internal compiler error? I can only assume that it's the same assert being triggered for all those tests. -- Iain
Re: [PATCH, ARM] Fix PR77904 testcase failure
Forgot the reference: [1] https://gcc.gnu.org/ml/gcc-patches/2018-12/msg01308.html On Monday, 31 December 2018, Thomas Preudhomme wrote: > Hi Richard, > > On Thursday, 20 December 2018, Richard Earnshaw (lists) < richard.earns...@arm.com> wrote: >> On 14/12/2018 23:28, Thomas Preudhomme wrote: >>> Hi, >>> >>> Commit r242693 forced fp to be saved/restored when needed due to an >>> instance of GCC using fp as a scratch register to save sp while it's >>> being clobbered by an inline asm. The normal path in >>> thumb1_compute_save_reg_mask saving callee-saved registers which are >>> live in the function does not work in that case because fp is chosen to >>> hold sp after that function is called. >>> >>> Since clobbering sp is now errored out by the compiler and this was the >>> only case reported where fp was live but not marked as such when >>> thumb1_compute_save_reg_mask is called, I believe the whole commit >>> r242693 should be reverted. >>> >>> ChangeLog entries are as follows: >>> >>> *** gcc/ChangeLog *** >>> >>> 2018-12-14 Thomas Preud'homme >>> >>> Revert: >>> 2016-11-22 Thomas Preud'homme >>> >>> PR target/77904 >>> * config/arm/arm.c (thumb1_compute_save_reg_mask): Mark frame pointer >>> in save register mask if it is needed. >>> >>> *** gcc/testsuite/ChangeLog *** >>> >>> 2018-12-14 Thomas Preud'homme >>> >>> Revert: >>> 2016-11-22 Thomas Preud'homme >>> >>> PR target/77904 >>> * gcc.target/arm/pr77904.c: New test. >>> >>> Testing: Built an arm-none-eabi GCC cross-compiler targeting Armv6S-M >>> and regression testsuite does not show any regression. >>> >>> Ok for stage3? >> >> OK. >> >> R. > > Bernd suggested in [1] that the behaviour tested by pr77904.c might actually be a behaviour we can allow with a patch to add a dg-warning to the decade. I'll wait for a resolution on that suggestion before deciding whether to commit this. > > Best regards, > > Thomas > >> >>> >>> Best regards, >>> >>> Thomas >>> >>> >>> fix_pr77904_test_failure.patch >>> >>> From 63c52e7bf932947be7122cdc63f6cdc913479259 Mon Sep 17 00:00:00 2001 >>> From: Thomas Preud'homme >>> Date: Fri, 14 Dec 2018 16:02:59 + >>> Subject: [PATCH] [PATCH, ARM] Fix PR77904 testcase failure >>> >>> Hi, >>> >>> Commit r242693 forced fp to be saved/restored when needed due to an >>> instance of GCC using fp as a scratch register to save sp while it's >>> being clobbered by an inline asm. The normal path in >>> thumb1_compute_save_reg_mask saving callee-saved registers which are >>> live in the function does not work in that case because fp is chosen to >>> hold sp after that function is called. >>> >>> Since clobbering sp is now errored out by the compiler and this was the >>> only case reported where fp was live but not marked as such when >>> thumb1_compute_save_reg_mask is called, I believe the whole commit >>> r242693 should be reverted. >>> >>> ChangeLog entries are as follows: >>> >>> *** gcc/ChangeLog *** >>> >>> 2018-12-14 Thomas Preud'homme >>> >>> Revert: >>> 2016-11-22 Thomas Preud'homme >>> >>> PR target/77904 >>> * config/arm/arm.c (thumb1_compute_save_reg_mask): Mark frame pointer >>> in save register mask if it is needed. >>> >>> *** gcc/testsuite/ChangeLog *** >>> >>> 2018-12-14 Thomas Preud'homme >>> >>> Revert: >>> 2016-11-22 Thomas Preud'homme >>> >>> PR target/77904 >>> * gcc.target/arm/pr77904.c: New test. >>> >>> Testing: Built an arm-none-eabi GCC cross-compiler targeting Armv6S-M >>> and regression testsuite does not show any regression. >>> >>> Ok for stage3? >>> >>> Best regards, >>> >>> Thomas >>> --- >>> gcc/ChangeLog | 9 ++ >>> gcc/config/arm/arm.c | 4 --- >>> gcc/testsuite/ChangeLog| 8 + >>> gcc/testsuite/gcc.target/arm/pr77904.c | 45 -- >>> 4 files changed, 17 insertions(+), 49 deletions(-) >>> delete mode 100644 gcc/testsuite/gcc.target/arm/pr77904.c >>> >>> diff --git a/gcc/ChangeLog b/gcc/ChangeLog >>> index d8e374fb15f..9caeb1d5e18 100644 >>> --- a/gcc/ChangeLog >>> +++ b/gcc/ChangeLog >>> @@ -1,3 +1,12 @@ >>> +2018-12-14 Thomas Preud'homme >>> + >>> + Revert: >>> + 2016-11-22 Thomas Preud'homme >>> + >>> + PR target/77904 >>> + * config/arm/arm.c (thumb1_compute_save_reg_mask): Mark frame pointer >>> + in save register mask if it is needed. >>> + >>> 2018-11-27 Alan Modra >>> >>> * config/rs6000/aix71.h (ASM_SPEC): Don't select default -maix64 >>> diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c >>> index 40f0574e32e..2ab5d8abc33 100644 >>> --- a/gcc/config/arm/arm.c >>> +++ b/gcc/config/arm/arm.c >>> @@ -19553,10 +19553,6 @@ thumb1_compute_save_core_reg_mask (void) >>> if (df_regs_ever_live_p (reg) && callee_saved_reg_p (reg)) >>>mask |= 1 << reg; >>> >>> - /* Handle the frame pointer as a special case. */ >>> - if (frame_pointer_needed) >>> -
Re: [PATCH, ARM] Fix PR77904 testcase failure
Hi Richard, On Thursday, 20 December 2018, Richard Earnshaw (lists) < richard.earns...@arm.com> wrote: > On 14/12/2018 23:28, Thomas Preudhomme wrote: >> Hi, >> >> Commit r242693 forced fp to be saved/restored when needed due to an >> instance of GCC using fp as a scratch register to save sp while it's >> being clobbered by an inline asm. The normal path in >> thumb1_compute_save_reg_mask saving callee-saved registers which are >> live in the function does not work in that case because fp is chosen to >> hold sp after that function is called. >> >> Since clobbering sp is now errored out by the compiler and this was the >> only case reported where fp was live but not marked as such when >> thumb1_compute_save_reg_mask is called, I believe the whole commit >> r242693 should be reverted. >> >> ChangeLog entries are as follows: >> >> *** gcc/ChangeLog *** >> >> 2018-12-14 Thomas Preud'homme >> >> Revert: >> 2016-11-22 Thomas Preud'homme >> >> PR target/77904 >> * config/arm/arm.c (thumb1_compute_save_reg_mask): Mark frame pointer >> in save register mask if it is needed. >> >> *** gcc/testsuite/ChangeLog *** >> >> 2018-12-14 Thomas Preud'homme >> >> Revert: >> 2016-11-22 Thomas Preud'homme >> >> PR target/77904 >> * gcc.target/arm/pr77904.c: New test. >> >> Testing: Built an arm-none-eabi GCC cross-compiler targeting Armv6S-M >> and regression testsuite does not show any regression. >> >> Ok for stage3? > > OK. > > R. Bernd suggested in [1] that the behaviour tested by pr77904.c might actually be a behaviour we can allow with a patch to add a dg-warning to the decade. I'll wait for a resolution on that suggestion before deciding whether to commit this. Best regards, Thomas > >> >> Best regards, >> >> Thomas >> >> >> fix_pr77904_test_failure.patch >> >> From 63c52e7bf932947be7122cdc63f6cdc913479259 Mon Sep 17 00:00:00 2001 >> From: Thomas Preud'homme >> Date: Fri, 14 Dec 2018 16:02:59 + >> Subject: [PATCH] [PATCH, ARM] Fix PR77904 testcase failure >> >> Hi, >> >> Commit r242693 forced fp to be saved/restored when needed due to an >> instance of GCC using fp as a scratch register to save sp while it's >> being clobbered by an inline asm. The normal path in >> thumb1_compute_save_reg_mask saving callee-saved registers which are >> live in the function does not work in that case because fp is chosen to >> hold sp after that function is called. >> >> Since clobbering sp is now errored out by the compiler and this was the >> only case reported where fp was live but not marked as such when >> thumb1_compute_save_reg_mask is called, I believe the whole commit >> r242693 should be reverted. >> >> ChangeLog entries are as follows: >> >> *** gcc/ChangeLog *** >> >> 2018-12-14 Thomas Preud'homme >> >> Revert: >> 2016-11-22 Thomas Preud'homme >> >> PR target/77904 >> * config/arm/arm.c (thumb1_compute_save_reg_mask): Mark frame pointer >> in save register mask if it is needed. >> >> *** gcc/testsuite/ChangeLog *** >> >> 2018-12-14 Thomas Preud'homme >> >> Revert: >> 2016-11-22 Thomas Preud'homme >> >> PR target/77904 >> * gcc.target/arm/pr77904.c: New test. >> >> Testing: Built an arm-none-eabi GCC cross-compiler targeting Armv6S-M >> and regression testsuite does not show any regression. >> >> Ok for stage3? >> >> Best regards, >> >> Thomas >> --- >> gcc/ChangeLog | 9 ++ >> gcc/config/arm/arm.c | 4 --- >> gcc/testsuite/ChangeLog| 8 + >> gcc/testsuite/gcc.target/arm/pr77904.c | 45 -- >> 4 files changed, 17 insertions(+), 49 deletions(-) >> delete mode 100644 gcc/testsuite/gcc.target/arm/pr77904.c >> >> diff --git a/gcc/ChangeLog b/gcc/ChangeLog >> index d8e374fb15f..9caeb1d5e18 100644 >> --- a/gcc/ChangeLog >> +++ b/gcc/ChangeLog >> @@ -1,3 +1,12 @@ >> +2018-12-14 Thomas Preud'homme >> + >> + Revert: >> + 2016-11-22 Thomas Preud'homme >> + >> + PR target/77904 >> + * config/arm/arm.c (thumb1_compute_save_reg_mask): Mark frame pointer >> + in save register mask if it is needed. >> + >> 2018-11-27 Alan Modra >> >> * config/rs6000/aix71.h (ASM_SPEC): Don't select default -maix64 >> diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c >> index 40f0574e32e..2ab5d8abc33 100644 >> --- a/gcc/config/arm/arm.c >> +++ b/gcc/config/arm/arm.c >> @@ -19553,10 +19553,6 @@ thumb1_compute_save_core_reg_mask (void) >> if (df_regs_ever_live_p (reg) && callee_saved_reg_p (reg)) >>mask |= 1 << reg; >> >> - /* Handle the frame pointer as a special case. */ >> - if (frame_pointer_needed) >> -mask |= 1 << HARD_FRAME_POINTER_REGNUM; >> - >>if (flag_pic >>&& !TARGET_SINGLE_PIC_BASE >>&& arm_pic_register != INVALID_REGNUM >> diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog >> index 9e1f6d05a45..4e58c8940da 100644 >> --- a/gcc/testsuite/ChangeLog >> +++
Re: [PATCH] PR target/86814
On Sun, Dec 30, 2018 at 8:06 PM augustine.sterl...@gmail.com wrote: > On Sun, Dec 30, 2018 at 1:06 AM Max Filippov wrote: > > Xtensa architecture is not affected by speculation. > > > > gcc/ > > 2018-12-30 Max Filippov > > > > * config/xtensa/xtensa.c (TARGET_HAVE_SPECULATION_SAFE_VALUE): > > Define to speculation_safe_value_not_needed. > > Approved. Applied to trunk. Thank you and happy New Year! -- Max
C++ PATCH for c++/88612, ICE with -Waddress-of-packed-member
This new warning was missing tf_warning checks so we may've wound up
re-entering the reporting routines. Fixed thus.
Bootstrapped/regtested on x86_64-linux, ok for trunk?
2018-12-31 Marek Polacek
PR c++/88612 - ICE with -Waddress-of-packed-member.
* call.c (convert_for_arg_passing): Only give warnings with tf_warning.
* typeck.c (convert_for_assignment): Likewise.
* g++.dg/warn/Waddress-of-packed-member1.C: New test.
diff --git gcc/cp/call.c gcc/cp/call.c
index cd220d70df5..da05cb9bd4e 100644
--- gcc/cp/call.c
+++ gcc/cp/call.c
@@ -7630,7 +7630,8 @@ convert_for_arg_passing (tree type, tree val,
tsubst_flags_t complain)
maybe_warn_parm_abi (type, cp_expr_loc_or_loc (val, input_location));
}
- warn_for_address_or_pointer_of_packed_member (false, type, val);
+ if (complain & tf_warning)
+warn_for_address_or_pointer_of_packed_member (false, type, val);
return val;
}
diff --git gcc/cp/typeck.c gcc/cp/typeck.c
index d5d1115fd23..c4fb834fedc 100644
--- gcc/cp/typeck.c
+++ gcc/cp/typeck.c
@@ -9073,7 +9073,8 @@ convert_for_assignment (tree type, tree rhs,
TREE_NO_WARNING (rhs) = 1;
}
- warn_for_address_or_pointer_of_packed_member (false, type, rhs);
+ if (complain & tf_warning)
+warn_for_address_or_pointer_of_packed_member (false, type, rhs);
return perform_implicit_conversion_flags (strip_top_quals (type), rhs,
complain, flags);
diff --git gcc/testsuite/g++.dg/warn/Waddress-of-packed-member1.C
gcc/testsuite/g++.dg/warn/Waddress-of-packed-member1.C
new file mode 100644
index 000..8faa046fd92
--- /dev/null
+++ gcc/testsuite/g++.dg/warn/Waddress-of-packed-member1.C
@@ -0,0 +1,42 @@
+// PR c++/88612
+// { dg-do compile { target c++11 } }
+// { dg-options "-fpack-struct -Waddress-of-packed-member" }
+// { dg-prune-output "taking address of packed member" }
+
+template
+auto indirect_call(F f, T... t) -> decltype(f(t...))
+{
+ return f(t...);
+}
+
+template
+struct VariadicBind
+{
+ F f;
+ T t;
+
+ template
+ auto operator()(A... a) -> decltype(indirect_call(f, t, a...))
+ {
+return indirect_call(f, t, a...);
+ }
+};
+
+template
+void apply(F f)
+{
+ f();
+}
+
+template
+void apply(F f, V1 v1, V... v)
+{
+ apply(VariadicBind{f, v1}, v...);
+}
+
+void func(int, int) { }
+
+int main()
+{
+ apply(func, 0, 0);
+}
[ping][PATCH][MSP430][TESTSUITE] Fix tests for msp430-elf large memory model
Previous submission: https://gcc.gnu.org/ml/gcc-patches/2018-11/msg01885.html
The attached patch fixes various tests for msp430-elf with -mlarge.
Succesfully regtested x86_64-pc-linux-gnu and msp430-elf/-mlarge.
Ok for trunk?
>From 4cfb2ecd0e0580f69790fadd68b77e8a82992ef4 Mon Sep 17 00:00:00 2001
From: Jozef Lawrynowicz
Date: Sat, 10 Nov 2018 16:08:44 +
Subject: [PATCH] [TESTSUITE] Fix tests for msp430-elf large memory model
2018-11-21 Jozef Lawrynowicz
gcc/ChangeLog:
* doc/sourcebuild.texi: Document
check_effective_target_msp430_large_mem.
gcc/testsuite/ChangeLog:
* gcc.c-torture/execute/991014-1.c: Fix bufsize definition for
msp430 large memory model.
* gcc.dg/Walloca-1.c: Don't expect warning for msp430 large memory
model.
* gcc.dg/Walloca-2.c: Likewise.
* gcc.dg/c99-const-expr-2.c: Define ZERO macro for msp430 large memory
model.
* gcc.dg/format/format.h: Prefix typedefs using __SIZE_TYPE__ and
__PTRDIFF_TYPE__ with __extension__.
* gcc.dg/lto/20081210-1_0.c: Always typedef uintptr_t as
__UINTPTR_TYPE__.
* gcc.dg/pr36227.c: Likewise.
* gcc.dg/pr42611.c: Use __INTPTR_MAX__ as the maximum object size if
size_t and ptr_t are the same size.
* gcc.dg/pr78973.c: dg-warning XFAIL for int16 but not msp430 large
memory model.
* gcc.dg/tree-ssa/builtin-sprintf-warn-3.c: Update dg-warning
directives for msp430 large memory model.
* gcc.dg/tree-ssa/pr66449.c: Always use __INTPTR_TYPE__ when integer
type equal in size to ptr_t is required.
* gcc.dg/tree-ssa/ssa-dom-thread-8.c: Extend pointer size checking
macro for msp430.
* lib/target-supports.exp (check_effective_target_msp430_large_mem):
New.
---
gcc/doc/sourcebuild.texi | 8 ++
gcc/testsuite/gcc.c-torture/execute/991014-1.c | 7 -
gcc/testsuite/gcc.dg/Walloca-1.c | 4 +--
gcc/testsuite/gcc.dg/Walloca-2.c | 8 +++---
gcc/testsuite/gcc.dg/c99-const-expr-2.c| 2 ++
gcc/testsuite/gcc.dg/format/format.h | 6 ++--
gcc/testsuite/gcc.dg/lto/20081210-1_0.c| 8 +-
gcc/testsuite/gcc.dg/pr36227.c | 10 +--
gcc/testsuite/gcc.dg/pr42611.c | 3 +-
gcc/testsuite/gcc.dg/pr78973.c | 2 +-
.../gcc.dg/tree-ssa/builtin-sprintf-warn-3.c | 32 +++---
gcc/testsuite/gcc.dg/tree-ssa/pr66449.c| 8 ++
gcc/testsuite/gcc.dg/tree-ssa/ssa-dom-thread-8.c | 8 +++---
gcc/testsuite/lib/target-supports.exp | 13 +
14 files changed, 66 insertions(+), 53 deletions(-)
diff --git a/gcc/doc/sourcebuild.texi b/gcc/doc/sourcebuild.texi
index bfaa0fd..b5fac4e 100644
--- a/gcc/doc/sourcebuild.texi
+++ b/gcc/doc/sourcebuild.texi
@@ -1941,6 +1941,14 @@ when using the new ABI.
MIPS target supports @code{-mpaired-single}.
@end table
+@subsubsection MSP430-specific attributes
+
+@table @code
+@item msp430_large_mem
+The MSP430 large memory model (enabled with @code{-mlarge} compiler flag)
+is in use.
+@end table
+
@subsubsection PowerPC-specific attributes
@table @code
diff --git a/gcc/testsuite/gcc.c-torture/execute/991014-1.c b/gcc/testsuite/gcc.c-torture/execute/991014-1.c
index e0bcd6d..95e38ce 100644
--- a/gcc/testsuite/gcc.c-torture/execute/991014-1.c
+++ b/gcc/testsuite/gcc.c-torture/execute/991014-1.c
@@ -1,11 +1,16 @@
-
typedef __SIZE_TYPE__ Size_t;
+#ifdef __MSP430X_LARGE__
+/* size_t is __int20, so 20 bits, for __MSP430X_LARGE__, but __SIZEOF_POINTER__
+ returns the bytesize which is 4. */
+#define bufsize ((1L << (20 - 2))-256)
+#else /* !__MSP430X_LARGE__ */
#if __SIZEOF_LONG__ < __SIZEOF_POINTER__
#define bufsize ((1LL << (8 * sizeof(Size_t) - 2))-256)
#else
#define bufsize ((1L << (8 * sizeof(Size_t) - 2))-256)
#endif
+#endif
struct huge_struct
{
diff --git a/gcc/testsuite/gcc.dg/Walloca-1.c b/gcc/testsuite/gcc.dg/Walloca-1.c
index 85e9160..c9a6c57 100644
--- a/gcc/testsuite/gcc.dg/Walloca-1.c
+++ b/gcc/testsuite/gcc.dg/Walloca-1.c
@@ -24,8 +24,8 @@ void foo1 (size_t len, size_t len2, size_t len3)
char *s = alloca (123);
useit (s); // OK, constant argument to alloca
- s = alloca (num); // { dg-warning "large due to conversion" "" { target lp64 } }
- // { dg-warning "unbounded use of 'alloca'" "" { target { ! lp64 } } .-1 }
+ s = alloca (num); // { dg-warning "large due to conversion" "" { target { { lp64 } || { msp430_large_mem } } } }
+ // { dg-warning "unbounded use of 'alloca'" "" { target { { ! lp64 } && { ! msp430_large_mem } } } .-1 }
useit (s);
s = alloca (3); /* { dg-warning "is too large" } */
diff --git a/gcc/testsuite/gcc.dg/Walloca-2.c b/gcc/testsuite/gcc.dg/Walloca-2.c
index 766ff8d..446c811 100644
--- a/gcc/testsuite/gcc.dg/Walloca-2.c
+++ b/gcc/testsuite/gcc.dg/Walloca-2.c
@@ -13,7 +13,7 @@ g1 (int n)
// 32-bit targets because VRP is not giving us any range info for
// the argument to __builtin_alloca. This should be fixed
Re: Fix devirtualiation in expanded thunks
On 12/28/18 12:19 PM, Sudakshina Das wrote:
> Hi Jan
>
> On 21/12/18 7:20 PM, Jan Hubicka wrote:
>> Hi,
>> this patch fixes polymorphic call analysis in thunks. Unlike normal
>> methods, thunks take THIS pointer offsetted by a known constant. This
>> needs t be compensated for when calculating address of outer type.
>>
>> Bootstrapped/regtested x86_64-linux, also tested with Firefox where this
>> bug trigger misoptimization in spellchecker. I plan to backport it to
>> release branches soon.
>>
>> Honza
>>
>> PR ipa/88561
>> * ipa-polymorphic-call.c
>> (ipa_polymorphic_call_context::ipa_polymorphic_call_context): Handle
>> arguments of thunks correctly.
>> (ipa_polymorphic_call_context::get_dynamic_context): Be ready for
>> NULL instance pinter.
>> * lto-cgraph.c (lto_output_node): Always stream thunk info.
>> * g++.dg/tree-prof/devirt.C: New testcase.
>> Index: ipa-polymorphic-call.c
>> ===
>> --- ipa-polymorphic-call.c (revision 267325)
>> +++ ipa-polymorphic-call.c (working copy)
>> @@ -995,9 +995,22 @@ ipa_polymorphic_call_context::ipa_polymo
>> {
>>outer_type
>> = TYPE_MAIN_VARIANT (TREE_TYPE (TREE_TYPE (base_pointer)));
>> + cgraph_node *node = cgraph_node::get (current_function_decl);
>>gcc_assert (TREE_CODE (outer_type) == RECORD_TYPE
>>|| TREE_CODE (outer_type) == UNION_TYPE);
>>
>> + /* Handle the case we inlined into a thunk. In this case
>> + thunk has THIS pointer of type bar, but it really receives
>> + address to its base type foo which sits in bar at
>> + 0-thunk.fixed_offset. It starts with code that adds
>> + think.fixed_offset to the pointer to compensate for this.
>> +
>> + Because we walked all the way to the begining of thunk, we now
>> + see pointer _offset and need to compensate
>> + for it. */
>> + if (node->thunk.fixed_offset)
>> +offset -= node->thunk.fixed_offset * BITS_PER_UNIT;
>> +
>>/* Dynamic casting has possibly upcasted the type
>> in the hiearchy. In this case outer type is less
>> informative than inner type and we should forget
>> @@ -1005,7 +1018,11 @@ ipa_polymorphic_call_context::ipa_polymo
>>if ((otr_type
>> && !contains_type_p (outer_type, offset,
>> otr_type))
>> - || !contains_polymorphic_type_p (outer_type))
>> + || !contains_polymorphic_type_p (outer_type)
>> + /* If we compile thunk with virtual offset, the THIS pointer
>> + is adjusted by unknown value. We can't thus use outer info
>> + at all. */
>> + || node->thunk.virtual_offset_p)
>> {
>>outer_type = NULL;
>>if (instance)
>> @@ -1030,7 +1047,15 @@ ipa_polymorphic_call_context::ipa_polymo
>>maybe_in_construction = false;
>> }
>>if (instance)
>> -*instance = base_pointer;
>> +{
>> + /* If method is expanded thunk, we need to apply thunk offset
>> + to instance pointer. */
>> + if (node->thunk.virtual_offset_p
>> + || node->thunk.fixed_offset)
>> +*instance = NULL;
>> + else
>> +*instance = base_pointer;
>> +}
>>return;
>> }
>> /* Non-PODs passed by value are really passed by invisible
>> @@ -1547,6 +1572,9 @@ ipa_polymorphic_call_context::get_dynami
>> HOST_WIDE_INT instance_offset = offset;
>> tree instance_outer_type = outer_type;
>>
>> + if (!instance)
>> +return false;
>> +
>> if (otr_type)
>> otr_type = TYPE_MAIN_VARIANT (otr_type);
>>
>> Index: lto-cgraph.c
>> ===
>> --- lto-cgraph.c (revision 267325)
>> +++ lto-cgraph.c (working copy)
>> @@ -547,7 +547,11 @@ lto_output_node (struct lto_simple_outpu
>> streamer_write_bitpack ();
>> streamer_write_data_stream (ob->main_stream, section, strlen (section) +
>> 1);
>>
>> - if (node->thunk.thunk_p)
>> + /* Stream thunk info always because we use it in
>> + ipa_polymorphic_call_context::ipa_polymorphic_call_context
>> + to properly interpret THIS pointers for thunks that has been converted
>> + to Gimple. */
>> + if (node->definition)
>> {
>> streamer_write_uhwi_stream
>> (ob->main_stream,
>> @@ -1295,7 +1299,7 @@ input_node (struct lto_file_decl_data *f
>> if (section)
>> node->set_section_for_node (section);
>>
>> - if (node->thunk.thunk_p)
>> + if (node->definition)
>> {
>> int type = streamer_read_uhwi (ib);
>> HOST_WIDE_INT fixed_offset = streamer_read_uhwi (ib);
>> Index: testsuite/g++.dg/tree-prof/devirt.C
>> ===
>> ---
[ping][PATCH][TESTSUITE] Fix ISO C errors in tests when __PTRDIFF_TYPE__ and __SIZE_TYPE__ are not ISO C compatible
Previous submission/discussion here:
https://gcc.gnu.org/ml/gcc-patches/2018-11/msg02151.html
For msp430-elf with the large memory model (-mlarge), __{,U}INTPTR_TYPE__,
__PTRDIFF_TYPE__ and __SIZE_TYPE__ are __int20.
If a test using these macros is compiled with -pedantic-errors, and -std=* or
-ansi, then GCC emits an error:
ISO C does not support __int20 types
The macros expand to __int20 after pre-processing, so to prevent the errors
__extension__ needs to be added before their usage in the testsuite.
I should clarify that using size_t/ptrdiff_t does not cause any ISO C errors,
even though __int20 is the underlying type. It is only when the builtin macros
for these types are used does the error occur.
Successfully regtested x86_64-pc-linux-gnu and msp430-elf/-mlarge.
Ok for trunk?
>From b940f79fa7c2a76fdda75dae7baf2bd48c72e9fa Mon Sep 17 00:00:00 2001
From: Jozef Lawrynowicz
Date: Mon, 31 Dec 2018 11:36:09 +
Subject: [PATCH] [ping][TESTSUITE] Fix ISO C errors in tests when ptr_t/size_t
are not ISO C compatible
2018-12-31 Jozef Lawrynowicz
Fix ISO C errors in tests when ptr_t/size_t are not ISO C compatible
gcc/testsuite/ChangeLog:
* gcc.dg/addr_builtin-1.c: Add __extension__ before usage of
__SIZE_TYPE__ and __UINTPTR_TYPE__.
* gcc.dg/vla-11.c: Likewise.
* gcc.dg/c11-static-assert-3.c: Add __extension__ before usage of
__SIZE_TYPE__.
* gcc.dg/c11-uni-string-1.c: Likewise.
* gcc.dg/c99-const-expr-10.c: Likewise.
* gcc.dg/c99-const-expr-9.c: Likewise.
* gcc.dg/c99-init-1.c: Likewise.
* gcc.dg/pr52549.c: Likewise.
* gcc.dg/pr71558.c: Likewise.
* gcc.dg/pr77587.c: Likewise.
* gcc.dg/pr79223.c: Likewise.
* gcc.dg/vla-9.c: Likewise.
* gcc.dg/c99-const-expr-6.c: Add __extension__ before usage of
__INTPTR_TYPE__.
* gcc.dg/c99-stdint-5.c: Likewise.
* gcc.dg/c99-stdint-6.c: Likewise.
* gcc.dg/pr61240.c: Add __extension__ before usage of __PTRDIFF_TYPE__.
---
gcc/testsuite/gcc.dg/addr_builtin-1.c | 6 +++---
gcc/testsuite/gcc.dg/c11-static-assert-3.c | 2 +-
gcc/testsuite/gcc.dg/c11-uni-string-1.c| 2 +-
gcc/testsuite/gcc.dg/c99-const-expr-10.c | 14 +++---
gcc/testsuite/gcc.dg/c99-const-expr-6.c| 4 ++--
gcc/testsuite/gcc.dg/c99-const-expr-9.c| 2 +-
gcc/testsuite/gcc.dg/c99-init-1.c | 2 +-
gcc/testsuite/gcc.dg/c99-stdint-5.c| 4 ++--
gcc/testsuite/gcc.dg/c99-stdint-6.c| 4 ++--
gcc/testsuite/gcc.dg/pr52549.c | 3 ++-
gcc/testsuite/gcc.dg/pr61240.c | 2 +-
gcc/testsuite/gcc.dg/pr71558.c | 8 +---
gcc/testsuite/gcc.dg/pr77587.c | 2 +-
gcc/testsuite/gcc.dg/pr79223.c | 2 +-
gcc/testsuite/gcc.dg/vla-11.c | 4 ++--
gcc/testsuite/gcc.dg/vla-9.c | 4 +++-
16 files changed, 35 insertions(+), 30 deletions(-)
diff --git a/gcc/testsuite/gcc.dg/addr_builtin-1.c b/gcc/testsuite/gcc.dg/addr_builtin-1.c
index 4a0888a..d7ad785 100644
--- a/gcc/testsuite/gcc.dg/addr_builtin-1.c
+++ b/gcc/testsuite/gcc.dg/addr_builtin-1.c
@@ -2,7 +2,7 @@
{ dg-do compile } */
typedef void (F)(void);
-typedef __UINTPTR_TYPE__ uintptr_t;
+__extension__ typedef __UINTPTR_TYPE__ uintptr_t;
/* Utility function to test passing built-in functions as an ordinary
argument and via the ellipsis. */
@@ -122,7 +122,7 @@ static F* test_taking_address_of_gcc_builtin (void)
of a user-declared function that's also a GCC built-in. */
extern int abs (int);
-extern __SIZE_TYPE__ strlen (const char*);
+__extension__ extern __SIZE_TYPE__ strlen (const char*);
/* Taking the address of a builtin with a library "fallback" must be
allowed, either using the __builtin_xxx form or the xxx form, when
@@ -147,7 +147,7 @@ void test_taking_address_of_library_builtin (int i)
}
{
-typedef __SIZE_TYPE__ size_t;
+__extension__ typedef __SIZE_TYPE__ size_t;
typedef size_t F (const char*);
/* Compute the address of libc's strlen using the implicitly
diff --git a/gcc/testsuite/gcc.dg/c11-static-assert-3.c b/gcc/testsuite/gcc.dg/c11-static-assert-3.c
index 9799b97..25a9346 100644
--- a/gcc/testsuite/gcc.dg/c11-static-assert-3.c
+++ b/gcc/testsuite/gcc.dg/c11-static-assert-3.c
@@ -5,7 +5,7 @@
_Static_assert (__INT_MAX__ * 2, "overflow"); /* { dg-warning "integer overflow in expression" } */
/* { dg-error "overflow in constant expression" "error" { target *-*-* } .-1 } */
-_Static_assert ((void *)(__SIZE_TYPE__)16, "non-integer"); /* { dg-error "not an integer" } */
+_Static_assert (__extension__ (void *)(__SIZE_TYPE__)16, "non-integer"); /* { dg-error "not an integer" } */
_Static_assert (1.0, "non-integer"); /* { dg-error "not an integer" } */
diff --git a/gcc/testsuite/gcc.dg/c11-uni-string-1.c b/gcc/testsuite/gcc.dg/c11-uni-string-1.c
index 9f86bea..6ace5e0 100644
---
Re: Enable inter-unit-moves for -mtune=generic
On December 31, 2018 11:11:51 AM GMT+01:00, Jan Hubicka wrote:
>Hi,
>while working on the Firefox performance
>http://hubicka.blogspot.com/2018/12/even-more-fun-with-building-and.html
>I noticed that we still disable inter-unit-moves because of Bulldozer
>CPUs. Last year I left that in tuning because Zens was new and it did
>not seem to hurt much other CPUs in tests. I think it is time to tune
>for more recent CPUs in this case because it also turns out that this
>penalizes quite noticeably hand written vectorized code. In particular
>
>#include
>__m128i test (short a,short b,short c,short d,short e,short f,short g)
>{
> return _mm_set_epi16(a,b,c,d,e,f,g,255);
>}
>
>translates to
>movzwl %r8w, %r8d
>movzwl %di, %edi
>movzwl %r9w, %r9d
>movzwl %si, %esi
>salq$16, %r8
>salq$16, %rdi
>movzwl 8(%rsp), %eax
>movzwl %dx, %edx
>orq %r9, %r8
>orq %rsi, %rdi
>movzwl %cx, %ecx
>salq$16, %r8
>salq$16, %rdi
>orq %rax, %r8
>orq %rdx, %rdi
>salq$16, %r8
>salq$16, %rdi
>orb $-1, %r8b
>orq %rcx, %rdi
>movq%r8, -24(%rsp)
>movq%rdi, -16(%rsp)
>movdqa -24(%rsp), %xmm0
>ret
>
>Which has mismatches store.
>Now we produce:
>
>movd%r9d, %xmm3
>movd%ecx, %xmm1
>movd%esi, %xmm2
>movl$255, %eax
>movd%eax, %xmm0
>pinsrw $1, %r8d, %xmm3
>pinsrw $1, %edx, %xmm1
>pinsrw $1, 8(%rsp), %xmm0
>pinsrw $1, %edi, %xmm2
>punpckldq %xmm2, %xmm1
>punpckldq %xmm3, %xmm0
>punpcklqdq %xmm1, %xmm0
>
>which is a lot better.
>Clan does
>
>movd%edi, %xmm0
>movd%esi, %xmm1
>punpcklwd %xmm0, %xmm1# xmm1 =
>xmm1[0],xmm0[0],xmm1[1],xmm0[1],xmm1[2],xmm0[2],xmm1[3],xmm0[3]
>movd%edx, %xmm0
>movd%ecx, %xmm2
>punpcklwd %xmm0, %xmm2# xmm2 =
>xmm2[0],xmm0[0],xmm2[1],xmm0[1],xmm2[2],xmm0[2],xmm2[3],xmm0[3]
>punpckldq %xmm1, %xmm2# xmm2 =
>xmm2[0],xmm1[0],xmm2[1],xmm1[1]
>movd%r8d, %xmm0
>movd%r9d, %xmm1
>punpcklwd %xmm0, %xmm1# xmm1 =
>xmm1[0],xmm0[0],xmm1[1],xmm0[1],xmm1[2],xmm0[2],xmm1[3],xmm0[3]
>movl$255, %eax
>movd%eax, %xmm0
>movd8(%rsp), %xmm3 # xmm3 = mem[0],zero,zero,zero
>punpcklwd %xmm3, %xmm0# xmm0 =
>xmm0[0],xmm3[0],xmm0[1],xmm3[1],xmm0[2],xmm3[2],xmm0[3],xmm3[3]
>punpckldq %xmm1, %xmm0# xmm0 =
>xmm0[0],xmm1[0],xmm0[1],xmm1[1]
>punpcklqdq %xmm2, %xmm0# xmm0 = xmm0[0],xmm2[0]
>
>Which looks worse, but I like the comment explaining semantics.
Do we use inter-unit moves for size optimization independent of the tuning
setting?
>Bootstrapped/regtested x86_64 linux. Comitted.
>
> * x86-tune.def: Enable inter_unit_moves_to_vec for generic.
>Index: config/i386/x86-tune.def
>===
>--- config/i386/x86-tune.def (revision 267477)
>+++ config/i386/x86-tune.def (working copy)
>@@ -379,9 +379,13 @@ DEF_TUNE (X86_TUNE_SSE_LOAD0_BY_PXOR, "s
>
> /* X86_TUNE_INTER_UNIT_MOVES_TO_VEC: Enable moves in from integer
>to SSE registers. If disabled, the moves will be done by storing
>- the value to memory and reloading. */
>+ the value to memory and reloading.
>+ Enable this flag for generic - the only relevant architecture
>preferring
>+ no inter-unit moves is Buldozer. While this makes small regression
>on SPECfp
>+ scores (sub 0.3%), disabling inter-unit moves penalizes noticeably
>hand
>+ written vectorized code which use i.e. _mm_set_epi16. */
> DEF_TUNE (X86_TUNE_INTER_UNIT_MOVES_TO_VEC, "inter_unit_moves_to_vec",
>- ~(m_ATHLON_K8 | m_AMDFAM10 | m_BDVER | m_BTVER | m_GENERIC))
>+ ~(m_ATHLON_K8 | m_AMDFAM10 | m_BDVER | m_BTVER))
>
> /* X86_TUNE_INTER_UNIT_MOVES_TO_VEC: Enable moves in from SSE
> to integer registers. If disabled, the moves will be done by storing
Re: [patch, fortran] Handle missing optional MASK for intrinsics
Hi Thomas, Another glitch: the following test (reduced from gfortran.dg/optional_absent_4.f90) module z implicit none contains subroutine findloc_4 (input, val, res, mask) logical, intent(in), optional :: mask(:,:) integer, intent(in) :: input(:,:) integer, dimension(:), intent(out) :: res integer, intent(in) :: val integer :: n = 1 res = findloc(input, val, dim=n) end subroutine findloc_4 end module z program main use z implicit none integer :: i2(2,3) = reshape([1,2,4,8,16,32], [2,3]) integer, dimension(3) :: res3 res3 = -2 call findloc_4 (i2, 4, res3) end program main gives at runtime a.out(77719,0x10335e5c0) malloc: Incorrect checksum for freed object 0x7fb131403d50: probably modified after being freed. Corrupt value: 0x0 a.out(77719,0x10335e5c0) malloc: *** set a breakpoint in malloc_error_break to debug Program received signal SIGABRT: Process abort signal. TIA, Dominique
Re: [patch, fortran] Handle missing optional MASK for intrinsics
Hi Thomas, There are some duplicate STOPs (6 and 10) in the test gfortran.dg/optional_absent_4.f90. Thanks for the patch, Dominique
Re: [PATCH v4 4/6, Committed] [MIPS] Add Loongson 3A1000 processor support
Hi Gerald, patch send to here: https://gcc.gnu.org/ml/gcc-patches/2018-12/msg01785.html thanks. On Fri, Dec 28, 2018 at 12:50 AM Gerald Pfeifer wrote: > > Hi Paul and Matthew, > > I believe it would be good to get this and other MIPS changes covered > in the GCC 9 release notes at https://gcc.gnu.org/gcc-9/changes.html . > > Gerald > > PS: https://gcc.gnu.org/about.html has background how to go about this.
[wwwdoc][Patch] Mention Loongson 3a1000 3a2000 3a3000 2k1000 support in gcc9
Hi Gerald, The attached patch mention Loongson 3a1000 3a2000 3a3000 2k1000 support in gcc9. ok for commit? Index: changes.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-9/changes.html,v retrieving revision 1.30 diff -u -r1.30 changes.html --- changes.html 3 Dec 2018 17:20:20 - 1.30 +++ changes.html 31 Dec 2018 10:21:32 - @@ -214,6 +214,44 @@ +MIPS + + +The Loongson loongson-mmi and loongson-ext +extension has now been splited from loongson3a: + + loongson-mmi which contains + the Loongson MultiMedia extension Instructions operations. + loongson-ext which contains + the Loongson EXTension instructions. + + +The Loongson EXTension R2 instructions is now supported. + + loongson-ext2 which contains the Loongson EXTension R2 instructions. + +Use -mxxx or -mno-xxx will enable or disable those extersions. +for example: Using -mloongson-mmi/-mno-loongson-mmi +will enable/disable Loongson MultiMedia Instructions extensions. + +Support has been added for the following processors +(GCC identifiers in parentheses): + + Loongson 3A1000 (gs464) + which default enable loongson-mmi, loongson-ext. + Loongson 3A2000/3A3000 (gs464e) + which default enable loongson-mmi, loongson-ext, loongson-ext2. + Loongson 2K1000 (gs264e) + which default enable loongson-ext, loongson-ext2, msa. + +The GCC identifiers can be used +as arguments to the -mcpu or -mtune options, +for example: -mcpu=gs464 or +-mtune=gs464e or as arguments to the equivalent target +attributes and pragmas. + + +
Enable inter-unit-moves for -mtune=generic
Hi,
while working on the Firefox performance
http://hubicka.blogspot.com/2018/12/even-more-fun-with-building-and.html
I noticed that we still disable inter-unit-moves because of Bulldozer
CPUs. Last year I left that in tuning because Zens was new and it did
not seem to hurt much other CPUs in tests. I think it is time to tune
for more recent CPUs in this case because it also turns out that this
penalizes quite noticeably hand written vectorized code. In particular
#include
__m128i test (short a,short b,short c,short d,short e,short f,short g)
{
return _mm_set_epi16(a,b,c,d,e,f,g,255);
}
translates to
movzwl %r8w, %r8d
movzwl %di, %edi
movzwl %r9w, %r9d
movzwl %si, %esi
salq$16, %r8
salq$16, %rdi
movzwl 8(%rsp), %eax
movzwl %dx, %edx
orq %r9, %r8
orq %rsi, %rdi
movzwl %cx, %ecx
salq$16, %r8
salq$16, %rdi
orq %rax, %r8
orq %rdx, %rdi
salq$16, %r8
salq$16, %rdi
orb $-1, %r8b
orq %rcx, %rdi
movq%r8, -24(%rsp)
movq%rdi, -16(%rsp)
movdqa -24(%rsp), %xmm0
ret
Which has mismatches store.
Now we produce:
movd%r9d, %xmm3
movd%ecx, %xmm1
movd%esi, %xmm2
movl$255, %eax
movd%eax, %xmm0
pinsrw $1, %r8d, %xmm3
pinsrw $1, %edx, %xmm1
pinsrw $1, 8(%rsp), %xmm0
pinsrw $1, %edi, %xmm2
punpckldq %xmm2, %xmm1
punpckldq %xmm3, %xmm0
punpcklqdq %xmm1, %xmm0
which is a lot better.
Clan does
movd%edi, %xmm0
movd%esi, %xmm1
punpcklwd %xmm0, %xmm1# xmm1 =
xmm1[0],xmm0[0],xmm1[1],xmm0[1],xmm1[2],xmm0[2],xmm1[3],xmm0[3]
movd%edx, %xmm0
movd%ecx, %xmm2
punpcklwd %xmm0, %xmm2# xmm2 =
xmm2[0],xmm0[0],xmm2[1],xmm0[1],xmm2[2],xmm0[2],xmm2[3],xmm0[3]
punpckldq %xmm1, %xmm2# xmm2 = xmm2[0],xmm1[0],xmm2[1],xmm1[1]
movd%r8d, %xmm0
movd%r9d, %xmm1
punpcklwd %xmm0, %xmm1# xmm1 =
xmm1[0],xmm0[0],xmm1[1],xmm0[1],xmm1[2],xmm0[2],xmm1[3],xmm0[3]
movl$255, %eax
movd%eax, %xmm0
movd8(%rsp), %xmm3 # xmm3 = mem[0],zero,zero,zero
punpcklwd %xmm3, %xmm0# xmm0 =
xmm0[0],xmm3[0],xmm0[1],xmm3[1],xmm0[2],xmm3[2],xmm0[3],xmm3[3]
punpckldq %xmm1, %xmm0# xmm0 = xmm0[0],xmm1[0],xmm0[1],xmm1[1]
punpcklqdq %xmm2, %xmm0# xmm0 = xmm0[0],xmm2[0]
Which looks worse, but I like the comment explaining semantics.
Bootstrapped/regtested x86_64 linux. Comitted.
* x86-tune.def: Enable inter_unit_moves_to_vec for generic.
Index: config/i386/x86-tune.def
===
--- config/i386/x86-tune.def(revision 267477)
+++ config/i386/x86-tune.def(working copy)
@@ -379,9 +379,13 @@ DEF_TUNE (X86_TUNE_SSE_LOAD0_BY_PXOR, "s
/* X86_TUNE_INTER_UNIT_MOVES_TO_VEC: Enable moves in from integer
to SSE registers. If disabled, the moves will be done by storing
- the value to memory and reloading. */
+ the value to memory and reloading.
+ Enable this flag for generic - the only relevant architecture preferring
+ no inter-unit moves is Buldozer. While this makes small regression on SPECfp
+ scores (sub 0.3%), disabling inter-unit moves penalizes noticeably hand
+ written vectorized code which use i.e. _mm_set_epi16. */
DEF_TUNE (X86_TUNE_INTER_UNIT_MOVES_TO_VEC, "inter_unit_moves_to_vec",
- ~(m_ATHLON_K8 | m_AMDFAM10 | m_BDVER | m_BTVER | m_GENERIC))
+ ~(m_ATHLON_K8 | m_AMDFAM10 | m_BDVER | m_BTVER))
/* X86_TUNE_INTER_UNIT_MOVES_TO_VEC: Enable moves in from SSE
to integer registers. If disabled, the moves will be done by storing
Re: [committed] Replace type/fuzzy arguments with a single enum
Hi Jeff, I wonder if it would make sense at this point to rename one of the two get_strlen_range functions? I always found it hard to tell which function is actually meant when they only differ in the number of parameters. Regards Bernd.
