Re: [PATCH] Add test for PR c++/53711
On Sun, 23 Mar 2014, Patrick Palka wrote: On Fri, Mar 14, 2014 at 11:20 AM, Jason Merrill ja...@redhat.com wrote: Applied, thanks. Thanks! The commit seems to be missing the corresponding ChangeLog entry though. ChangeLog is kind of optional in the testsuite. Please keep providing entries, but don't be surprised when some go missing. -- Marc Glisse
Re: [PATCH] Fix g++.dg/opt/pr56999.C
On Sun, Mar 23, 2014 at 09:47:21PM -0400, John David Anglin wrote: On hppa64-hp-hpux11.11, the lack of a pragma to pop the currently hidden visibility before main results in main being hidden. The attached change adds a pop pragma to resolve the test failure: ld: (Warning) Potential unresolved symbol main: shared library reference is resolved to non-exported definition in file /var/tmp// ccUra9KR.o. FAIL: g++.dg/opt/pr56999.C -std=gnu++98 (test for excess errors) Tested on hppa2.0w-hp-hpux11.11 and hppa64-hp-hpux11.11. OK for trunk? 2014-03-23 John David Anglin dang...@gcc.gnu.org PR testsuite/58013 * g++.dg/opt/pr56999.C: Pop hidden visibility. Index: g++.dg/opt/pr56999.C === --- g++.dg/opt/pr56999.C(revision 208769) +++ g++.dg/opt/pr56999.C(working copy) @@ -159,6 +159,7 @@ pendingRecompiles-append (info); } volatile JITScript *JSScript::JITScriptHandle::UNJITTABLE; +#pragma GCC visibility pop(hidden) This must be #pragma GCC visibility pop Ok with that change (just verified the testcase is still miscompiled with that change before Vlad's r198082 fix and works after it. Jakub
Re: [PATCH] x86: _mm*_undefined_* (for real)
Hello Ulrich, On 21 Mar 06:41, Ulrich Drepper wrote: This is a tested version of the patch I sent before. I'm using the type var = var trick for the initialization so far even those this is not ideal as I have shown in one of the emails before. If anyone could work on a real solution we could get even better code generation. In the meantime, the patch should be fine. I've bootstrapped the compiler on x86-64. The patch adds the _mm*_undefined_* definitions and uses them where appropriate. Most of the related changes are cleanups. In some cases completely uninitialized variables are used and I consider that code buggy. So the patch is actually also a bug fix. 2014-03-19 Ulrich Drepper drep...@gmail.com * config/i386/avxintrin.h (_mm256_undefined_si256): Define. (_mm256_undefined_ps): Define. (_mm256_undefined_pd): Define. * config/i386/emmintrin.h (_mm_undefined_si128): Define. (_mm_undefined_pd): Define. * config/i386/xmmintrin.h (_mm_undefined_ps): Define. * config/i386/avx512fintrin.h (_mm512_undefined_si512): Define. (_mm512_undefined_ps): Define. (_mm512_undefined_pd): Define. Use _mm*_undefined_*. * config/i386/avx2intrin.h: Use _mm*_undefined_*. Anyone having a problem with the patch? I've tried your patch with AVX-512 simulator and see no new regressions. until after the release? I found a few more intrinsics which are missing and I'll have more patches. If list of missing intrinsics is big - maybe you could share it? I can help you implementing it. In general, I think _undefined idea is correct and the patch is doing most important thing - it localizes undef semantics in couple of built-ins. However I don't know which code is optimal to model undef behaviour. -- Thanks, K
Re: [committed] Skip gcc.dg/torture/pr60092.c on 32-bit hpux
John David Anglin dave.ang...@bell.net writes:
Index: gcc.dg/torture/pr60092.c
===
--- gcc.dg/torture/pr60092.c (revision 208769)
+++ gcc.dg/torture/pr60092.c (working copy)
@@ -1,5 +1,6 @@
/* { dg-do run } */
/* { dg-require-weak } */
+/* { dg-skip-if No undefined weak { hppa*-*-hpux* { ! lp64 } } { * }
{ } } */
Please omit those default args to dg-skip-if. Besides, it seems we
should have a separate undefined_weak (or whatever) keyword for this,
rather than listing targets explicitly. But that's certainly not 4.9
material.
Rainer
--
-
Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [committed] Fix failure of gcc.dg/tree-prof/pr59003.c on hppa*-*-hpux*
John David Anglin dave.ang...@bell.net writes:
Index: gcc.dg/tree-prof/pr59003.c
===
--- gcc.dg/tree-prof/pr59003.c(revision 208769)
+++ gcc.dg/tree-prof/pr59003.c(working copy)
@@ -1,6 +1,7 @@
/* PR target/59003 */
/* { dg-options -O2 } */
/* { dg-options -O2 -mtune=amdfam10 { target i?86-*-* x86_64-*-* } } */
+/* { dg-options -O2 -fno-common { target hppa*-*-hpux* } } */
Better handled with dg-additional-options rather than duplicating
dg-options. No need to change though, since the x86 entry already used
the less preferred style.
Rainer
--
-
Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [PATCH, doc] Mention nds32*-*-elf in the target specific installation notes.
Chung-Ju Wu jasonw...@gmail.com writes:
+@anchor{nds32x-x-elf}
+@heading nds32*-*-elf
+Andes NDS32 target.
+
+Use @samp{configure --target=nds32le-elf --enable-languages=c,c++} to
configure
+GCC@ for building a nds32 elf cross-compiler in little endian mode.
+
+Use @samp{configure --target=nds32be-elf --enable-languages=c,c++} to
configure
+GCC@ for building a nds32 elf cross-compiler in big endian mode.
I'd rather not list the full configure lines, but just describe the two
possible targets.
Thanks.
Rainer
--
-
Rainer Orth, Center for Biotechnology, Bielefeld University
Re: WCONTINUED is not portable
On Sun, Mar 23, 2014 at 03:18:42PM -0700, Ian Lance Taylor wrote: On Sun, Mar 23, 2014 at 3:50 AM, Martin Husemann mar...@duskware.de wrote: The flag WCONTINUED for waitpid() is not portable. The attached patch just defines it to 0 if missing. I don't understand why that code passes either WUNTRACED or WCONTINUED. Why not just pass 0? Note the patch Martin has posted is not needed, I've committed a change to define WCONTINUED to 0 if not defined several days ago as obvious. Adding Honza in the loop why he chose to use WUNTRACED | WCONTINUED. Jakub
[PATCH] Environment variables forwarding
Hi all,
When porting Lsan on arm, I ran into problem with testing, because
almost all lsan tests require environment variables forwarding for
remote targets. Unfortunately, this feature isn't implemented yet
neither in Dejagnu nor in GCC. These two small patches seem to resolve
this issue.
Tested on arm with asan.exp and ubsan.exp.
I've cross-posted this message in Dejagnu too.
Do these changes make sense? If not - what's the proper way to forward
env vars on remote targets?
-Maxim
2014-03-24 Max Ostapenko m.ostape...@partner.samsung.com
* config/unix.exp: Parse incoming string in environment variables
and program name itself.
diff --git a/config/unix.exp b/config/unix.exp
index 4b244ca..fa0327a 100644
--- a/config/unix.exp
+++ b/config/unix.exp
@@ -50,6 +50,9 @@ proc unix_load { dest prog args } {
set inp
}
+ regsub ^ *((\[^ \]+=\[^ \]* *)*).* $prog \\1 environ
+ regsub ^ *((\[^ \]+=\[^ \]* *)*) $prog prog
+
if {![file exists $prog]} then {
# We call both here because this should never happen.
perror $prog does not exist in unix_load.
@@ -114,7 +117,7 @@ proc unix_load { dest prog args } {
return [list unresolved ]
}
}
- set status [remote_exec $dest $remotefile $parg $inp]
+ set status [remote_exec $dest $environ $remotefile $parg $inp]
remote_file $dest delete $remotefile.o $remotefile
if { [lindex $status 0] 0 } {
verbose -log Couldn't execute $prog, [lindex $status 1] 3
2014-03-24 Max Ostapenko m.ostape...@partner.samsung.com
* lib/gcc-dg.exp: Add check if Dejagnu supports environment
variables forwarding for remote targets.
* lib/target-supports.exp
(check_runtime_env_vars_forwarding_nocache): New function.
(check_runtime_env_vars_forwarding): New function.
diff --git a/gcc/testsuite/lib/gcc-dg.exp b/gcc/testsuite/lib/gcc-dg.exp
index f9d52bc..05eab99 100644
--- a/gcc/testsuite/lib/gcc-dg.exp
+++ b/gcc/testsuite/lib/gcc-dg.exp
@@ -80,6 +80,9 @@ set LTO_TORTURE_OPTIONS
global gcc_force_conventional_output
set gcc_force_conventional_output
+global target_env_vars_available
+set target_env_vars_available
+
if [check_effective_target_lto] {
# When having plugin test both slim and fat LTO and plugin/nonplugin
# path.
@@ -258,11 +261,21 @@ if { [info procs ${tool}_load] != [list] \
set saved_target_env_var [list]
if { [info exists set_target_env_var] \
[llength $set_target_env_var] != 0 } {
- if { [is_remote target] } {
- return [list unsupported ]
- }
- set-target-env-var
- }
+if { [is_remote target] } {
+if [check_runtime_env_vars_forwarding] {
+foreach env_var $set_target_env_var {
+set var [lindex $env_var 0]
+set value [lindex $env_var 1]
+set program $var=$value $program
+}
+} else {
+return [list unsupported ]
+}
+} else {
+set-target-env-var
+}
+}
+
set result [eval [list saved_${tool}_load $program] $args]
if { [info exists set_target_env_var] \
[llength $set_target_env_var] != 0 } {
diff --git a/gcc/testsuite/lib/target-supports.exp b/gcc/testsuite/lib/target-supports.exp
index bee8471..3a3224f 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -5731,3 +5731,57 @@ proc force_conventional_output_for { test } {
}
}
+# This procedure is the same the check_runtime_nocache one. The only
+# difference is that executable will run with TEST=1 environment
+# variable. If Dejagnu supports environment variables forwarding
+# for remote targets, it will return 1, otherwise it will return 0.
+
+proc check_runtime_env_vars_forwarding_nocache {} {
+global tool
+global target_env_vars_available
+set basename env_forwarding_works
+set contents {
+#ifdef __cplusplus
+extern C
+#endif
+char *getenv(const char *name);
+
+#ifdef __cplusplus
+extern C
+#endif
+int strcmp(const char *s1, const char *s2);
+
+int main () { return strcmp(getenv(TEST), 1); }
+}
+
+set args
+
+set result [eval [list check_compile $basename executable $contents] $args]
+set lines [lindex $result 0]
+set output [lindex $result 1]
+
+set ok 0
+if { [string match $lines] } {
+# No error messages, everything is OK.
+set result [remote_load target TEST=1 ./$output ]
+set status [lindex $result 0]
+verbose check_runtime_nocache $basename: status is $status 2
+if { $status == pass } {
+set ok 1
+}
+}
+remote_file build delete $output
+return $ok
+}
+
+proc check_runtime_env_vars_forwarding {} {
+global target_env_vars_available
+if { $target_env_vars_available == } {
+if [check_runtime_env_vars_forwarding_nocache] {
+set target_env_vars_available 1
+}
Re: [PATCH] LeakSanitizer testsuite
On Thu, Mar 20, 2014 at 10:22:38AM +0400, Maxim Ostapenko wrote:
Hi,
This patch adds initial set of tests and dg infrastructure for
LeakSanitizer runtime.
Tested on x86_64.
Ok to commit?
Are you sure we need testsuite for something that doesn't have a GCC code
generation counterpart at all?
In any case, this isn't ok for 4.9, we are too late in the development
cycle.
Perhaps it could go in during next stage1.
--- /dev/null
+++ b/gcc/testsuite/c-c++-common/lsan/fork.c
@@ -0,0 +1,23 @@
+// Test that thread local data is handled correctly after forking without
exec().
+/* { dg-do run } */
+
+#include assert.h
+#include stdio.h
+#include stdlib.h
+#include sys/wait.h
+#include unistd.h
+
+__thread void *thread_local_var;
Tests using __thread should be guarded with
/* { dg-require-effective-target tls_runtime } */
Also, I wonder given the explicit uses of unistd.h if you just shouldn't
limit the test to *-*-linux* or similar.
--- /dev/null
+++ b/gcc/testsuite/c-c++-common/lsan/swapcontext-1.c
@@ -0,0 +1,41 @@
+// We can't unwind stack if we're running coroutines on heap-allocated
+// memory. Make sure we don't report these leaks.
I guess setcontext/getcontext/makecontext is supported even on far fewer
OSes.
Jakub
Re: LTO / invoke.texi: Add some words about static libraries and LTO
On Sat, Mar 22, 2014 at 3:36 PM, Tobias Burnus bur...@net-b.de wrote: Mention gcc-ar, gcc-ranlib, gcc-nm in the documentation. OK? Ok. Thanks, Richard. Tobias
Re: [PATCH] PR debug/16063. Add DW_AT_type to DW_TAG_enumeration.
On Sun, Mar 23, 2014 at 12:18 PM, Mark Wielaard m...@redhat.com wrote:
Add a new lang-hook that provides the underlying base type of an
ENUMERAL_TYPE. Including implementations for C and C++. Use this
enum_underlying_base_type lang-hook in dwarf2out.c to add a DW_AT_type
base type reference to a DW_TAG_enumeration.
Don't we have TREE_TYPE (enum-type) as that type? Thus, can we avoid
adding the new langhook?
Thanks,
Richard.
gcc/
* dwarf2out.c (gen_enumeration_type_die): Add DW_AT_type if
enum_underlying_base_type defined and DWARF version 3.
* langhooks.h (struct lang_hooks_for_types): Add
enum_underlying_base_type.
* langhooks-def.h (LANG_HOOKS_ENUM_UNDERLYING_BASE_TYPE): New define.
(LANG_HOOKS_FOR_TYPES_INITIALIZER): Add new lang hook.
gcc/c-family/
* c-common.c (c_enum_underlying_base_type): New function.
* c-common.h (c_enum_underlying_base_type): Add declaration.
gcc/c/
* c-objc-common.h (LANG_HOOKS_ENUM_UNDERLYING_BASE_TYPE): Define.
gcc/cp/
* dwarf2out.c (gen_enumeration_type_die): Add DW_AT_type if
enum_underlying_base_type defined and DWARF version 3.
* langhooks.h (struct lang_hooks_for_types): Add
enum_underlying_base_type.
* langhooks-def.h (LANG_HOOKS_ENUM_UNDERLYING_BASE_TYPE): New define.
(LANG_HOOKS_FOR_TYPES_INITIALIZER): Add new lang hook.
---
gcc/ChangeLog | 10 ++
gcc/c-family/ChangeLog |6 ++
gcc/c-family/c-common.c |8
gcc/c-family/c-common.h |1 +
gcc/c/ChangeLog |5 +
gcc/c/c-objc-common.h |2 ++
gcc/cp/ChangeLog|6 ++
gcc/cp/cp-lang.c| 18 ++
gcc/dwarf2out.c |7 +++
gcc/langhooks-def.h |4 +++-
gcc/langhooks.h |2 ++
11 files changed, 68 insertions(+), 1 deletions(-)
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index f3b4f2d..e90ea6e 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,5 +1,15 @@
2014-03-21 Mark Wielaard m...@redhat.com
+ PR debug/16063
+ * dwarf2out.c (gen_enumeration_type_die): Add DW_AT_type if
+ enum_underlying_base_type defined and DWARF version 3.
+ * langhooks.h (struct lang_hooks_for_types): Add
+ enum_underlying_base_type.
+ * langhooks-def.h (LANG_HOOKS_ENUM_UNDERLYING_BASE_TYPE): New define.
+ (LANG_HOOKS_FOR_TYPES_INITIALIZER): Add new lang hook.
+
+2014-03-21 Mark Wielaard m...@redhat.com
+
* dwarf2out.c (gen_enumeration_type_die): Add DW_AT_const_value
as unsigned or int depending on type and value used.
diff --git a/gcc/c-family/ChangeLog b/gcc/c-family/ChangeLog
index 4e5aea4..90b688b 100644
--- a/gcc/c-family/ChangeLog
+++ b/gcc/c-family/ChangeLog
@@ -1,3 +1,9 @@
+2014-03-21 Mark Wielaard m...@redhat.com
+
+ PR debug/16063
+ * c-common.c (c_enum_underlying_base_type): New function.
+ * c-common.h (c_enum_underlying_base_type): Add declaration.
+
2014-03-13 Jakub Jelinek ja...@redhat.com
PR middle-end/36282
diff --git a/gcc/c-family/c-common.c b/gcc/c-family/c-common.c
index abd96fb..55ebbcc 100644
--- a/gcc/c-family/c-common.c
+++ b/gcc/c-family/c-common.c
@@ -3902,6 +3902,14 @@ c_register_builtin_type (tree type, const char* name)
registered_builtin_types = tree_cons (0, type, registered_builtin_types);
}
+
+/* The C version of the enum_underlying_base_type langhook. */
+tree
+c_enum_underlying_base_type (const_tree type)
+{
+ return c_common_type_for_size (TYPE_PRECISION (type), TYPE_UNSIGNED
(type));
+}
+
/* Print an error message for invalid operands to arith operation
CODE with TYPE0 for operand 0, and TYPE1 for operand 1.
diff --git a/gcc/c-family/c-common.h b/gcc/c-family/c-common.h
index 1099b10..e378b44 100644
--- a/gcc/c-family/c-common.h
+++ b/gcc/c-family/c-common.h
@@ -832,6 +832,7 @@ extern void c_common_finish (void);
extern void c_common_parse_file (void);
extern alias_set_type c_common_get_alias_set (tree);
extern void c_register_builtin_type (tree, const char*);
+extern tree c_enum_underlying_base_type (const_tree);
extern bool c_promoting_integer_type_p (const_tree);
extern int self_promoting_args_p (const_tree);
extern tree strip_pointer_operator (tree);
diff --git a/gcc/c/ChangeLog b/gcc/c/ChangeLog
index b39b7d6..9ab6eab 100644
--- a/gcc/c/ChangeLog
+++ b/gcc/c/ChangeLog
@@ -1,3 +1,8 @@
+2014-03-21 Mark Wielaard m...@redhat.com
+
+ PR debug/16063
+ * c-objc-common.h (LANG_HOOKS_ENUM_UNDERLYING_BASE_TYPE): Define.
+
2014-03-18 Manuel López-Ibáñez m...@gcc.gnu.org
PR c/55383
diff --git a/gcc/c/c-objc-common.h b/gcc/c/c-objc-common.h
index 92cf60f..0651db7 100644
--- a/gcc/c/c-objc-common.h
+++ b/gcc/c/c-objc-common.h
@@ -84,6 +84,8 @@ along with GCC; see the file COPYING3. If not see
#define
Re: Fix PR rtl-optimization/60452
On Sun, Mar 23, 2014 at 1:02 PM, Eric Botcazou ebotca...@adacore.com wrote: This is a regression present on mainline and 4.8 branch: ifcvt generates a conditional move from an invalid location on the stack, resulting in a segfault at runtime. The testcase is pathological and exploits the very old RTL semantics (now embodied in may_trap_or_fault_p) of considering that stack references cannot trap, which is of course wrong for nonsensical offsets. This is an old issue (the attached testcase distilled by Jakub already fails with GCC 4.3) and the original testcase is clearly machine-generated, so I don't think that we need to pessimize the common case for it; instead fixing this kind of very minor issues on a case-by-case basis is good enough I think. The attached patch only adds a check in rtx_addr_can_trap_p_1 for nonsensical offsets against the frame pointer; this is sufficient for both testcases. The check is supposed to be exact (e.g. it never triggers during a bootstrap) so it won't pessimize anything. This might be different if the ??? comment is addressed later but, again, I don't think that we should care at this point. Tested on x86_64-suse-linux, any objections? Looks reasonable to me. Richard. 2014-03-23 Eric Botcazou ebotca...@adacore.com PR rtl-optimization/60452 * rtlanal.c (rtx_addr_can_trap_p_1): Fix head comment. case REG: Return 1 for nonsensical offsets from the frame pointer. 2014-03-23 Eric Botcazou ebotca...@adacore.com * gcc.c-torture/execute/20140323-1.c: New test. -- Eric Botcazou
Re: [PATCH][AARCH64]combine ubfiz and orr with bfi when certain condition meets.
On 17/03/14 10:27, Richard Earnshaw wrote: On 16/03/14 12:30, Renlin Li wrote: Hi all, Thank you for your suggestions, Richard. I have updated the patch accordingly. This is an optimization patch which will combine ubfiz and orr insns with a single bfi when certain conditions meet. tmp = (x m) | ( (y n) lsb) can be presented using and tmp, x, m bfi tmp, y, #lsb, #width if ((n+1) == 2^width) (m n lsb) == 0. A small test case is also added to verify it. Is this Okay for stage-1? Kind regards, Renlin Li This looks to me more like a 3 into two split operation where combine needs some help to do the split, since the transformation is non-trivial. As such, I think you just need a define_split rather than a define_insn_and_split (there's also no obvious reason why we would want to defer this split until after register allocation). Furthermore, you have an early-clobber situation here: it's important that y and tmp aren't in the same register. You appear to try to cater for this by using an operand tie, but that's unnecessary in general (the AND operation can write any usable register) and won't work in the specific case where x = y. R. Hi Richard, You are right, thank you for the suggestion. I will further consider and refine it. Regards, Renlin Li
[PATCH] Make some ubsan tests more robust
dg-output as it stands can't be used in a negate form, that is we can't
check that no output was produced. This is needed for ubsan: there
are testcases that when run should issue no output at all. We can,
however, use this really ugly hack, where we output some fake stuff
at the beginning and at the end of main() and check that nothing was
issued in between. And it's even uglier because I need to pull in
stdio.h because of stderr...
Fortunately in 5.0 this will not be needed, because I'll implement
the -fno-sanitize-recover option (then any runtime error causes the
program to abort).
Ran ubsan testsuite. Ok for trunk?
2014-03-24 Marek Polacek pola...@redhat.com
testsuite/
* c-c++-common/ubsan/div-by-zero-4.c: Don't include limits.h. Define
INT_MIN.
* c-c++-common/ubsan/overflow-1.c: Check for unwanted output.
* c-c++-common/ubsan/overflow-add-1.c: Likewise.
* c-c++-common/ubsan/overflow-mul-1.c: Likewise.
* c-c++-common/ubsan/overflow-mul-3.c: Likewise.
* c-c++-common/ubsan/overflow-negate-2.c: Likewise.
* c-c++-common/ubsan/overflow-sub-1.c: Likewise.
* c-c++-common/ubsan/pr59503.c: Likewise.
* c-c++-common/ubsan/pr60613-1.c: Likewise.
* c-c++-common/ubsan/save-expr-1.c: Likewise.
* c-c++-common/ubsan/shift-3.c: Likewise.
* c-c++-common/ubsan/shift-6.c: Likewise.
* c-c++-common/ubsan/undefined-1.c: Likewise.
* c-c++-common/ubsan/vla-2.c: Likewise.
* c-c++-common/ubsan/vla-3.c: Likewise.
* c-c++-common/ubsan/vla-4.c: Likewise.
* g++.dg/ubsan/cxx11-shift-1.C: Likewise.
* g++.dg/ubsan/return-2.C: Likewise.
diff --git gcc/testsuite/c-c++-common/ubsan/div-by-zero-4.c
gcc/testsuite/c-c++-common/ubsan/div-by-zero-4.c
index 295f624..02162e1 100644
--- gcc/testsuite/c-c++-common/ubsan/div-by-zero-4.c
+++ gcc/testsuite/c-c++-common/ubsan/div-by-zero-4.c
@@ -1,7 +1,7 @@
/* { dg-do run } */
/* { dg-options -fsanitize=integer-divide-by-zero -Wno-overflow } */
-#include limits.h
+#define INT_MIN (-__INT_MAX__ - 1)
int
main (void)
diff --git gcc/testsuite/c-c++-common/ubsan/overflow-1.c
gcc/testsuite/c-c++-common/ubsan/overflow-1.c
index 8165463..6819955 100644
--- gcc/testsuite/c-c++-common/ubsan/overflow-1.c
+++ gcc/testsuite/c-c++-common/ubsan/overflow-1.c
@@ -1,6 +1,8 @@
/* { dg-do run } */
/* { dg-options -fsanitize=signed-integer-overflow } */
+#include stdio.h
+
#ifndef ASM1
# define ASM1(a) /* Nothing */
#endif
@@ -51,6 +53,8 @@
int
main (void)
{
+ fputs (UBSAN TEST START\n, stderr);
+
CHECK (FN1 (char, char, +), 23);
CHECK (FN1 (char, char, -), 5);
CHECK (FN1 (char, char, *), 126);
@@ -258,5 +262,8 @@ main (void)
CHECK (FN5 (long long int), -77);
CHECK (FN5 (unsigned long long int), -77);
+ fputs (UBSAN TEST END\n, stderr);
return 0;
}
+
+/* { dg-output UBSAN TEST START(\n|\r\n|\r)UBSAN TEST END } */
diff --git gcc/testsuite/c-c++-common/ubsan/overflow-add-1.c
gcc/testsuite/c-c++-common/ubsan/overflow-add-1.c
index 3f4790b..fd6c6d3 100644
--- gcc/testsuite/c-c++-common/ubsan/overflow-add-1.c
+++ gcc/testsuite/c-c++-common/ubsan/overflow-add-1.c
@@ -1,6 +1,8 @@
/* { dg-do run } */
/* { dg-options -fsanitize=signed-integer-overflow -Wno-unused-variable } */
+#include stdio.h
+
#define SCHAR_MAX __SCHAR_MAX__
#define SHRT_MAX __SHRT_MAX__
#define INT_MAX __INT_MAX__
@@ -16,6 +18,8 @@ check (int i, int j)
int
main (void)
{
+ fputs (UBSAN TEST START\n, stderr);
+
#if __INT_MAX__ == 2147483647
/* Here, nothing should fail. */
volatile int j = INT_MAX;
@@ -56,5 +60,8 @@ main (void)
check (d, -32768);
#endif
+ fputs (UBSAN TEST END\n, stderr);
return 0;
}
+
+/* { dg-output UBSAN TEST START(\n|\r\n|\r)UBSAN TEST END } */
diff --git gcc/testsuite/c-c++-common/ubsan/overflow-mul-1.c
gcc/testsuite/c-c++-common/ubsan/overflow-mul-1.c
index bb355a2..afb1a25 100644
--- gcc/testsuite/c-c++-common/ubsan/overflow-mul-1.c
+++ gcc/testsuite/c-c++-common/ubsan/overflow-mul-1.c
@@ -1,6 +1,8 @@
/* { dg-do run } */
/* { dg-options -fsanitize=signed-integer-overflow -Wno-unused-variable } */
+#include stdio.h
+
#define SCHAR_MAX __SCHAR_MAX__
#define SHRT_MAX __SHRT_MAX__
#define INT_MAX __INT_MAX__
@@ -16,6 +18,8 @@ check (int i, int j)
int
main (void)
{
+ fputs (UBSAN TEST START\n, stderr);
+
/* Test integer promotion. */
#if __SCHAR_MAX__ == 127
volatile signed char a = -2;
@@ -42,5 +46,8 @@ main (void)
check (o, INT_MIN);
#endif
+ fputs (UBSAN TEST END\n, stderr);
return 0;
}
+
+/* { dg-output UBSAN TEST START(\n|\r\n|\r)UBSAN TEST END } */
diff --git gcc/testsuite/c-c++-common/ubsan/overflow-mul-3.c
gcc/testsuite/c-c++-common/ubsan/overflow-mul-3.c
index 49332dc..037609b 100644
--- gcc/testsuite/c-c++-common/ubsan/overflow-mul-3.c
+++ gcc/testsuite/c-c++-common/ubsan/overflow-mul-3.c
@@ -1,6 +1,8 @@
/* { dg-do run } */
/* { dg-options
Re: [PATCH] Make some ubsan tests more robust
On Mon, Mar 24, 2014 at 10:37:46AM +0100, Marek Polacek wrote: dg-output as it stands can't be used in a negate form, that is we can't check that no output was produced. This is needed for ubsan: there are testcases that when run should issue no output at all. We can, however, use this really ugly hack, where we output some fake stuff at the beginning and at the end of main() and check that nothing was issued in between. And it's even uglier because I need to pull in stdio.h because of stderr... Fortunately in 5.0 this will not be needed, because I'll implement the -fno-sanitize-recover option (then any runtime error causes the program to abort). Ran ubsan testsuite. Ok for trunk? 2014-03-24 Marek Polacek pola...@redhat.com testsuite/ * c-c++-common/ubsan/div-by-zero-4.c: Don't include limits.h. Define INT_MIN. * c-c++-common/ubsan/overflow-1.c: Check for unwanted output. * c-c++-common/ubsan/overflow-add-1.c: Likewise. * c-c++-common/ubsan/overflow-mul-1.c: Likewise. * c-c++-common/ubsan/overflow-mul-3.c: Likewise. * c-c++-common/ubsan/overflow-negate-2.c: Likewise. * c-c++-common/ubsan/overflow-sub-1.c: Likewise. * c-c++-common/ubsan/pr59503.c: Likewise. * c-c++-common/ubsan/pr60613-1.c: Likewise. * c-c++-common/ubsan/save-expr-1.c: Likewise. * c-c++-common/ubsan/shift-3.c: Likewise. * c-c++-common/ubsan/shift-6.c: Likewise. * c-c++-common/ubsan/undefined-1.c: Likewise. * c-c++-common/ubsan/vla-2.c: Likewise. * c-c++-common/ubsan/vla-3.c: Likewise. * c-c++-common/ubsan/vla-4.c: Likewise. * g++.dg/ubsan/cxx11-shift-1.C: Likewise. * g++.dg/ubsan/return-2.C: Likewise. Ok, thanks. Jakub
Re: [PATCH] Environment variables forwarding
Adding Dejagnu list this time.
On 03/24/2014 12:28 PM, Maxim Ostapenko wrote:
Hi all,
When porting Lsan on arm, I ran into problem with testing, because
almost all lsan tests require environment variables forwarding for
remote targets. Unfortunately, this feature isn't implemented yet
neither in Dejagnu nor in GCC. These two small patches seem to resolve
this issue.
Tested on arm with asan.exp and ubsan.exp.
I've cross-posted this message in Dejagnu too.
Do these changes make sense? If not - what's the proper way to forward
env vars on remote targets?
-Maxim
2014-03-24 Max Ostapenko m.ostape...@partner.samsung.com
* config/unix.exp: Parse incoming string in environment variables
and program name itself.
diff --git a/config/unix.exp b/config/unix.exp
index 4b244ca..fa0327a 100644
--- a/config/unix.exp
+++ b/config/unix.exp
@@ -50,6 +50,9 @@ proc unix_load { dest prog args } {
set inp
}
+ regsub ^ *((\[^ \]+=\[^ \]* *)*).* $prog \\1 environ
+ regsub ^ *((\[^ \]+=\[^ \]* *)*) $prog prog
+
if {![file exists $prog]} then {
# We call both here because this should never happen.
perror $prog does not exist in unix_load.
@@ -114,7 +117,7 @@ proc unix_load { dest prog args } {
return [list unresolved ]
}
}
- set status [remote_exec $dest $remotefile $parg $inp]
+ set status [remote_exec $dest $environ $remotefile $parg $inp]
remote_file $dest delete $remotefile.o $remotefile
if { [lindex $status 0] 0 } {
verbose -log Couldn't execute $prog, [lindex $status 1] 3
2014-03-24 Max Ostapenko m.ostape...@partner.samsung.com
* lib/gcc-dg.exp: Add check if Dejagnu supports environment
variables forwarding for remote targets.
* lib/target-supports.exp
(check_runtime_env_vars_forwarding_nocache): New function.
(check_runtime_env_vars_forwarding): New function.
diff --git a/gcc/testsuite/lib/gcc-dg.exp b/gcc/testsuite/lib/gcc-dg.exp
index f9d52bc..05eab99 100644
--- a/gcc/testsuite/lib/gcc-dg.exp
+++ b/gcc/testsuite/lib/gcc-dg.exp
@@ -80,6 +80,9 @@ set LTO_TORTURE_OPTIONS
global gcc_force_conventional_output
set gcc_force_conventional_output
+global target_env_vars_available
+set target_env_vars_available
+
if [check_effective_target_lto] {
# When having plugin test both slim and fat LTO and plugin/nonplugin
# path.
@@ -258,11 +261,21 @@ if { [info procs ${tool}_load] != [list] \
set saved_target_env_var [list]
if { [info exists set_target_env_var] \
[llength $set_target_env_var] != 0 } {
- if { [is_remote target] } {
- return [list unsupported ]
- }
- set-target-env-var
- }
+if { [is_remote target] } {
+if [check_runtime_env_vars_forwarding] {
+foreach env_var $set_target_env_var {
+set var [lindex $env_var 0]
+set value [lindex $env_var 1]
+set program $var=$value $program
+}
+} else {
+return [list unsupported ]
+}
+} else {
+set-target-env-var
+}
+}
+
set result [eval [list saved_${tool}_load $program] $args]
if { [info exists set_target_env_var] \
[llength $set_target_env_var] != 0 } {
diff --git a/gcc/testsuite/lib/target-supports.exp b/gcc/testsuite/lib/target-supports.exp
index bee8471..3a3224f 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -5731,3 +5731,57 @@ proc force_conventional_output_for { test } {
}
}
+# This procedure is the same the check_runtime_nocache one. The only
+# difference is that executable will run with TEST=1 environment
+# variable. If Dejagnu supports environment variables forwarding
+# for remote targets, it will return 1, otherwise it will return 0.
+
+proc check_runtime_env_vars_forwarding_nocache {} {
+global tool
+global target_env_vars_available
+set basename env_forwarding_works
+set contents {
+#ifdef __cplusplus
+extern C
+#endif
+char *getenv(const char *name);
+
+#ifdef __cplusplus
+extern C
+#endif
+int strcmp(const char *s1, const char *s2);
+
+int main () { return strcmp(getenv(TEST), 1); }
+}
+
+set args
+
+set result [eval [list check_compile $basename executable $contents] $args]
+set lines [lindex $result 0]
+set output [lindex $result 1]
+
+set ok 0
+if { [string match $lines] } {
+# No error messages, everything is OK.
+set result [remote_load target TEST=1 ./$output ]
+set status [lindex $result 0]
+verbose check_runtime_nocache $basename: status is $status 2
+if { $status == pass } {
+set ok 1
+}
+}
+remote_file build delete $output
+return $ok
+}
+
+proc check_runtime_env_vars_forwarding {} {
+global target_env_vars_available
+if { $target_env_vars_available == } {
+if
Re: [4.8, PATCH 0/26] Backport Power8 and LE support
Hi Bill, On 21 Mar 2014, at 02:05, Bill Schmidt wrote: For convenience of those who have kindly agreed to test the patch series, here is the entire series as a single compressed patch. Note that this does not include patch 15/26, which we've agreed to submit separately. To assess this on powerpc-apple-darwin9: - applied this series as per the attached archive. (You might wish to double-check for white-space issues, git complained about a few of the patches). - built tested all langs including obj-c++ and Ada (but NOT Java), (G5, m32/m64). I see no regressions related to this patch series*** ... as far as I'm concerned, the series presents no apparent issue for PPC/Darwin. cheers, Iain *** NOTE: JFTR, applying the series shows an apparent regression in g++/torture/pr45843.C @ -O3. however analysis of the case shows that it's just exposing a pre-existing issue (apparently, we don't check well-enough for alignment constraints before choosing ld with a LO14 reloc). Bill On Wed, 2014-03-19 at 14:23 -0500, Bill Schmidt wrote: Hi, Support for Power8 features and the new powerpc64le-linux-gnu target, including the ELFv2 ABI, has been developed up till now on the ibm/gcc-4_8-branch. It was appropriate to use this separate branch while the support was unstable, but this branch will not represent a particularly good support mechanism for distributions going forward. Most distros are set up to pull from the major release branches, and having a separate branch for one target is quite inconvenient. Also, the ibm/gcc-4_8-branch's original purpose is to serve as the code base for IBM's Advance Toolchain 7.0. Over time the two purposes that the branch currently serves will diverge and make things even more complicated. The code is now tested and stable enough that we are ready to backport this support to the FSF 4.8 branch. This patch series constitutes that backport. Almost all of the changes are specific to PowerPC portions of the code, and for those patches I am only CCing David. However, some of the patches require changes to common code, and for these I will CC Richard and Jakub. Three of these are slightly unrelated but necessary patches, one to enable decimal float ABS builtins, and two others to fix PR54537 and PR56843. In addition there are patches that update configuration files throughout for the new target, and some small changes in common call support (call.c, expr.h, function.c) to support how the new ABI handles calls. I realize it is unusual to backport such a large amount of code, but we have been asked by distribution partners to do this, and we feel it makes good sense for long-term support. I have tested the patch series by applying it to a clean FSF 4.8 branch and comparing the test results against those from the IBM 4.8 branch on three systems: * Power8, little endian (--mcpu=power8) * Power8, big endian (--mcpu=power8) * Power7, big endian (--mcpu=power7) I also checked a recursive diff against the two source directories to ensure that no patches were missed. Thanks, Bill [ 1/26] diff-p8 [ 2/26] diff-p8-htm [ 3/26] diff-le-config [ 4/26] diff-le-libtool [ 5/26] diff-le-tests [ 6/26] diff-le-dfp [ 7/26] diff-le-vector [ 8/26] diff-abi-compat [ 9/26] diff-abi-calls [10/26] diff-abi-elfv2 [11/26] diff-abi-gotest [12/26] diff-le-align [13/26] diff-abi-libffi [14/26] diff-dfp-abs [15/26] diff-pr54537 [16/26] diff-pr56843 [17/26] diff-direct-move [18/26] diff-le-config-2 [19/26] diff-quad-memory [20/26] diff-lra [21/26] diff-le-vector-api [22/26] diff-mcall [23/26] diff-pr60137-pr60203 [24/26] diff-reload [25/26] diff-v1ti [26/26] diff-trunk-missing 4_8-backport-single.patch.bz2
Re: [AArch64 testsuite] Make vect-abs.c C99 compliant
*ping*
Jakub pointed out to me recently that obvious patches are OK even in
Stage 4, so if I don't hear any objections in 24 hours, I'll push
this.
Thanks,
James
On Tue, Feb 18, 2014 at 12:35:17PM +, James Greenhalgh wrote:
Hi,
This test fails on a linux build because it tries to use the
LONG_LONG_{MAX/MIN} macros from types.h. These are not guaranteed
to exist, and my system types.h doesn't provide them. C99 provides
LLONG_{MIN/MAX} for this purpose.
A gnu89 baremetal compiler doesn't seem to carry these macros
so we must add -std=c99.
But then this testcase doesn't properly declare its functions, relying
on an implicit int return type.
So I've fixed those up and now the test passes on aarch64-none-elf and
aarch64-none-linux-gnu.
I guess the patch is obvious and low risk as it is a target
specific test, but as we are late in Stage 4 I'd like
approval before I commit.
OK?
Thanks,
James
---
gcc/testsuite/
2014-02-18 James Greenhalgh james.greenha...@arm.com
* gcc.target/aarch64/vect-abs.c (dg-options): Add -std=c99.
(LONG_LONG): Use LLONG.
(set_rvector_long): Explicitly return void.
(set_vector_long): Likewise.
(check_vector_long): Likewise.
diff --git a/gcc/testsuite/gcc.target/aarch64/vect-abs.c
b/gcc/testsuite/gcc.target/aarch64/vect-abs.c
index 954b106..9e0ed99 100644
--- a/gcc/testsuite/gcc.target/aarch64/vect-abs.c
+++ b/gcc/testsuite/gcc.target/aarch64/vect-abs.c
@@ -1,6 +1,6 @@
/* { dg-do run } */
-/* { dg-options -O3 } */
+/* { dg-options -O3 -std=c99 } */
#include limits.h
@@ -37,8 +37,9 @@ extern void abort (void);
SET_RVEC (8, SCHAR)
SET_RVEC (16, SHRT)
SET_RVEC (32, INT)
-SET_RVEC (64, LONG_LONG)
+SET_RVEC (64, LLONG)
+void
set_rvector_long (pRLONG a)
{
int i;
@@ -49,8 +50,9 @@ set_rvector_long (pRLONG a)
SET_VEC (8, SCHAR)
SET_VEC (16, SHRT)
SET_VEC (32, INT)
-SET_VEC (64, LONG_LONG)
+SET_VEC (64, LLONG)
+void
set_vector_long (long *__restrict__ a)
{
long i;
@@ -63,6 +65,7 @@ CHECK_VEC (16)
CHECK_VEC (32)
CHECK_VEC (64)
+void
check_vector_long (long *__restrict__ a, long *__restrict__ b)
{
long i;
[PATCH] Fix PR59626, _FORTIFY_SOURCE wrappers and LTO
Currently a _lot_ of packages fail to build with LTO because LTO
messes up fortify wrappers by replacing the call to the alias with
the symbol itself, making the wrapper look like infinitely
recursing.
The following patch fixes this by dropping the bodies of
DECL_EXTERN always-inline functions on the floor before IPA
(and when doing LTO). IMHO we should at some point do this
unconditional on LTO as the early inliner is supposed to
remove all references to always-inline functions.
I'm not 100% sure about the cgraph API use to drop the function
body, but at least it seems to work ;) I'm not sure if we want
to restrict the set of functions to apply this even more than
just those with always-inline and DECL_EXTERNAL set?
Now double-checking with a fortified LTO bootstrap.
Ok for trunk?
Thanks,
Richard.
2014-03-24 Richard Biener rguent...@suse.de
PR lto/59626
* passes.c (ipa_write_summaries): Drop function bodies of
extern always-inline functions.
* gcc.dg/lto/pr59626_0.c: New testcase.
* gcc.dg/lto/pr59626_1.c: Likewise.
Index: gcc/passes.c
===
*** gcc/passes.c(revision 208745)
--- gcc/passes.c(working copy)
*** ipa_write_summaries (void)
*** 2390,2404
if (cgraph_function_with_gimple_body_p (node))
{
! /* When streaming out references to statements as part of some IPA
!pass summary, the statements need to have uids assigned and the
!following does that for all the IPA passes here. Naturally, this
!ordering then matches the one IPA-passes get in their stmt_fixup
!hooks. */
!
! push_cfun (DECL_STRUCT_FUNCTION (node-decl));
! renumber_gimple_stmt_uids ();
! pop_cfun ();
}
if (node-definition)
lto_set_symtab_encoder_in_partition (encoder, node);
--- 2396,2427
if (cgraph_function_with_gimple_body_p (node))
{
! if (DECL_EXTERNAL (node-decl)
! lookup_attribute (always_inline,
! DECL_ATTRIBUTES (node-decl)) != NULL)
! {
! /* We mess up uses of extern always-inline wrappers that
!end up calling an alias to itself like glibc _FORTIFY_SOURCE
!wrappers. Simply drop the bodies of the extern inlines
!here to avoid that. */
! cgraph_release_function_body (node);
! node-analyzed = false;
! node-definition = false;
! DECL_ATTRIBUTES (node-decl)
! = remove_attribute (always_inline,
! DECL_ATTRIBUTES (node-decl));
! }
! else
! {
! /* When streaming out references to statements as part of some
!IPA pass summary, the statements need to have uids assigned
!and the following does that for all the IPA passes here.
!Naturally, this ordering then matches the one IPA-passes get
!in their stmt_fixup hooks. */
! push_cfun (DECL_STRUCT_FUNCTION (node-decl));
! renumber_gimple_stmt_uids ();
! pop_cfun ();
! }
}
if (node-definition)
lto_set_symtab_encoder_in_partition (encoder, node);
Index: gcc/testsuite/gcc.dg/lto/pr59626_0.c
===
*** gcc/testsuite/gcc.dg/lto/pr59626_0.c(revision 0)
--- gcc/testsuite/gcc.dg/lto/pr59626_0.c(working copy)
***
*** 0
--- 1,15
+ /* { dg-lto-do run } */
+
+ int __atoi (const char *) __asm__(atoi);
+ extern inline __attribute__((always_inline,gnu_inline))
+ int atoi (const char *x)
+ {
+ return __atoi (x);
+ }
+
+ int bar (int (*)(const char *));
+
+ int main()
+ {
+ return bar (atoi);
+ }
Index: gcc/testsuite/gcc.dg/lto/pr59626_1.c
===
*** gcc/testsuite/gcc.dg/lto/pr59626_1.c(revision 0)
--- gcc/testsuite/gcc.dg/lto/pr59626_1.c(working copy)
***
*** 0
--- 1,4
+ int bar (int (*fn)(const char *))
+ {
+ return fn (0);
+ }
Re: [4.8, PATCH 4/26] Backport Power8 and LE support: Libtool and configure bits 2
On Wed, 19 Mar 2014, Bill Schmidt wrote:
Hi,
This patch (diff-le-libtool) backports changes to use a libtool.m4 that
supports powerpc64le-*linux*.
Ok.
Thanks,
Richard.
Thanks,
Bill
2014-03-19 Bill Schmidt wschm...@linux.vnet.ibm.com
Backport from mainline
2013-11-22 Ulrich Weigand ulrich.weig...@de.ibm.com
* libgo/config/libtool.m4: Update to mainline version.
* libgo/configure: Regenerate.
2013-11-17 Ulrich Weigand ulrich.weig...@de.ibm.com
* libgo/config/libtool.m4: Update to mainline version.
* libgo/configure: Regenerate.
2013-11-15 Ulrich Weigand ulrich.weig...@de.ibm.com
* libtool.m4: Update to mainline version.
* libjava/libltdl/acinclude.m4: Likewise.
* gcc/configure: Regenerate.
* boehm-gc/configure: Regenerate.
* libatomic/configure: Regenerate.
* libbacktrace/configure: Regenerate.
* libffi/configure: Regenerate.
* libgfortran/configure: Regenerate.
* libgomp/configure: Regenerate.
* libitm/configure: Regenerate.
* libjava/configure: Regenerate.
* libjava/libltdl/configure: Regenerate.
* libjava/classpath/configure: Regenerate.
* libmudflap/configure: Regenerate.
* libobjc/configure: Regenerate.
* libquadmath/configure: Regenerate.
* libsanitizer/configure: Regenerate.
* libssp/configure: Regenerate.
* libstdc++-v3/configure: Regenerate.
* lto-plugin/configure: Regenerate.
* zlib/configure: Regenerate.
Backport from mainline
2013-09-20 Alan Modra amo...@gmail.com
* libtool.m4 (_LT_ENABLE_LOCK ld -m flags): Remove non-canonical
ppc host match. Support little-endian powerpc linux hosts.
* configure: Regenerate.
Index: gcc-4_8-branch/gcc/configure
===
--- gcc-4_8-branch.orig/gcc/configure 2013-12-28 17:41:32.733630408 +0100
+++ gcc-4_8-branch/gcc/configure 2013-12-28 17:50:38.646332701 +0100
@@ -13589,7 +13589,7 @@ ia64-*-hpux*)
rm -rf conftest*
;;
-x86_64-*kfreebsd*-gnu|x86_64-*linux*|ppc*-*linux*|powerpc*-*linux*| \
+x86_64-*kfreebsd*-gnu|x86_64-*linux*|powerpc*-*linux*| \
s390*-*linux*|s390*-*tpf*|sparc*-*linux*)
# Find out which ABI we are using.
echo 'int i;' conftest.$ac_ext
@@ -13614,7 +13614,10 @@ s390*-*linux*|s390*-*tpf*|sparc*-*linux*
;;
esac
;;
- ppc64-*linux*|powerpc64-*linux*)
+ powerpc64le-*linux*)
+ LD=${LD-ld} -m elf32lppclinux
+ ;;
+ powerpc64-*linux*)
LD=${LD-ld} -m elf32ppclinux
;;
s390x-*linux*)
@@ -13633,7 +13636,10 @@ s390*-*linux*|s390*-*tpf*|sparc*-*linux*
x86_64-*linux*)
LD=${LD-ld} -m elf_x86_64
;;
- ppc*-*linux*|powerpc*-*linux*)
+ powerpcle-*linux*)
+ LD=${LD-ld} -m elf64lppc
+ ;;
+ powerpc-*linux*)
LD=${LD-ld} -m elf64ppc
;;
s390*-*linux*|s390*-*tpf*)
@@ -17827,7 +17833,7 @@ else
lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
lt_status=$lt_dlunknown
cat conftest.$ac_ext _LT_EOF
-#line 17830 configure
+#line 17836 configure
#include confdefs.h
#if HAVE_DLFCN_H
@@ -17933,7 +17939,7 @@ else
lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
lt_status=$lt_dlunknown
cat conftest.$ac_ext _LT_EOF
-#line 17936 configure
+#line 17942 configure
#include confdefs.h
#if HAVE_DLFCN_H
Index: gcc-4_8-branch/libtool.m4
===
--- gcc-4_8-branch.orig/libtool.m42013-12-28 17:41:32.728630383 +0100
+++ gcc-4_8-branch/libtool.m4 2013-12-28 17:50:38.652332731 +0100
@@ -1220,7 +1220,7 @@ ia64-*-hpux*)
rm -rf conftest*
;;
-x86_64-*kfreebsd*-gnu|x86_64-*linux*|ppc*-*linux*|powerpc*-*linux*| \
+x86_64-*kfreebsd*-gnu|x86_64-*linux*|powerpc*-*linux*| \
s390*-*linux*|s390*-*tpf*|sparc*-*linux*)
# Find out which ABI we are using.
echo 'int i;' conftest.$ac_ext
@@ -1241,7 +1241,10 @@ s390*-*linux*|s390*-*tpf*|sparc*-*linux*
;;
esac
;;
- ppc64-*linux*|powerpc64-*linux*)
+ powerpc64le-*linux*)
+ LD=${LD-ld} -m elf32lppclinux
+ ;;
+ powerpc64-*linux*)
LD=${LD-ld} -m elf32ppclinux
;;
s390x-*linux*)
@@ -1260,7 +1263,10 @@ s390*-*linux*|s390*-*tpf*|sparc*-*linux*
x86_64-*linux*)
LD=${LD-ld} -m elf_x86_64
;;
- ppc*-*linux*|powerpc*-*linux*)
+ powerpcle-*linux*)
+ LD=${LD-ld} -m elf64lppc
+ ;;
+ powerpc-*linux*)
LD=${LD-ld} -m elf64ppc
;;
s390*-*linux*|s390*-*tpf*)
Index: gcc-4_8-branch/boehm-gc/configure
Re: [PATCH, doc] Mention nds32*-*-elf in the target specific installation notes.
2014-03-24 14:52 GMT+08:00 Rainer Orth r...@cebitec.uni-bielefeld.de:
Chung-Ju Wu jasonw...@gmail.com writes:
+@anchor{nds32x-x-elf}
+@heading nds32*-*-elf
+Andes NDS32 target.
+
+Use @samp{configure --target=nds32le-elf --enable-languages=c,c++} to
configure
+GCC@ for building a nds32 elf cross-compiler in little endian mode.
+
+Use @samp{configure --target=nds32be-elf --enable-languages=c,c++} to
configure
+GCC@ for building a nds32 elf cross-compiler in big endian mode.
I'd rather not list the full configure lines, but just describe the two
possible targets.
Thanks for the comment.
The revised patch and ChangeLog are as below.
Is it OK for the trunk ?
Index: gcc/ChangeLog
===
--- gcc/ChangeLog (revision 208786)
+++ gcc/ChangeLog (working copy)
@@ -1,3 +1,11 @@
+2014-03-24 Chung-Ju Wu jasonw...@gmail.com
+
+ * doc/install.texi: Document nds32le-*-elf and nds32be-*-elf.
+
2014-03-24 Rainer Orth r...@cebitec.uni-bielefeld.de
* Makefile.in (s-macro_list): Depend on cc1.
Index: gcc/doc/install.texi
===
--- gcc/doc/install.texi(revision 208786)
+++ gcc/doc/install.texi(working copy)
@@ -3144,6 +3144,10 @@
@item
@uref{#mips-sgi-irix6,,mips-sgi-irix6}
@item
+@uref{#nds32le-x-elf,,nds32le-*-elf}
+@item
+@uref{#nds32be-x-elf,,nds32be-*-elf}
+@item
@uref{#powerpc-x-x,,powerpc*-*-*}
@item
@uref{#powerpc-x-darwin,,powerpc-*-darwin*}
@@ -4100,6 +4104,20 @@
@html
hr /
@end html
+@anchor{nds32le-x-elf}
+@heading nds32le-*-elf
+Andes NDS32 target in little endian mode.
+
+@html
+hr /
+@end html
+@anchor{nds32be-x-elf}
+@heading nds32be-*-elf
+Andes NDS32 target in big endian mode.
+
+@html
+hr /
+@end html
@anchor{powerpc-x-x}
@heading powerpc-*-*
You can specify a default version for the @option{-mcpu=@var{cpu_type}}
Best regards,
jasonwucj
Re: [PATCH] PR debug/16063. Add DW_AT_type to DW_TAG_enumeration.
On Mon, 2014-03-24 at 10:26 +0100, Richard Biener wrote: On Sun, Mar 23, 2014 at 12:18 PM, Mark Wielaard m...@redhat.com wrote: Add a new lang-hook that provides the underlying base type of an ENUMERAL_TYPE. Including implementations for C and C++. Use this enum_underlying_base_type lang-hook in dwarf2out.c to add a DW_AT_type base type reference to a DW_TAG_enumeration. Don't we have TREE_TYPE (enum-type) as that type? Thus, can we avoid adding the new langhook? The underlying type is the integral base type of the enum, which, at least for C++, can be different from the tree type of the enum. See also cp/semantics.c (finish_underlying_type) which calculates it in the C++ case. Cheers, Mark
Re: [AArch64 testsuite] Make vect-abs.c C99 compliant
On 24/03/14 10:00, James Greenhalgh wrote: *ping* Jakub pointed out to me recently that obvious patches are OK even in Stage 4, so if I don't hear any objections in 24 hours, I'll push this. Thanks, James OK /Marcus
Re: [PATCH] x86: _mm512_set1_p[sd]
On Mon, Mar 24, 2014 at 1:50 AM, Kirill Yukhin kirill.yuk...@gmail.com wrote: Your patch is correct IMHO, but maybe it worst to add all missing `mm512_set1*' stuff? According to trunk and [1] we're still missing (beside mentioned by you) _mm512_set1_epi16 and _mm512_set1_epi8 broadcasts. Yes, more are missing, but I think those will need new builtins. The _ps and _pd don't require additional instructions. _mm512_set1_epi16 might have to map to vpbroadcastw. _mm512_set1_epi8 might have to map to vpbroadcastb. I haven't seen a way to generate those instructions if needed and so this work was out of scope for now due to time constraints. I agree, they should be added as quickly as possible to avoid releasing headers with incomplete APIs. What is the verdict on checking these changes in? Too late for the next release?
Re: [PATCH] x86: _mm*_undefined_* (for real)
On Mon, Mar 24, 2014 at 2:31 AM, Kirill Yukhin kirill.yuk...@gmail.com wrote: If list of missing intrinsics is big - maybe you could share it? I can help you implementing it. So far only the set1 intrinsics. I'll see whether I can spot more. In general, I think _undefined idea is correct and the patch is doing most important thing - it localizes undef semantics in couple of built-ins. However I don't know which code is optimal to model undef behaviour. Indeed, that's my main objective for now. Then someone with more knowledge of the gcc internals could experiment with the code generation and only have to change a few places. I could make one more change, if wanted, and reduce the number of affected locations to just three. We would only need a builtin to create, say, _mm_undefined_esi128. The other two 128-bit values could be created using a cast which gcc allows just fine. Should I do that? Looks a bit less clean but helps with maintainability IMO. In general, as for the other patch, too late for the next release?
[PATCH, ARM] Enable tail call optimization for long call
This patch enables tail call optimization for long call on arm.
Previously we have too strict check on arm_function_ok_for_sibcall and
be lack of the support on sibcall/sibcall_value expand that long call tail
oppportunities are lost.
OK for next next stage 1?
thanks.
--
Jiong
gcc/
* config/arm/predicates.md (call_insn_operand): Add long_call check.
* config/arm/arm.md (sibcall, sibcall_value): Force the address to reg for
long_call.
* config/aarch64/aarch64.c (arm_function_ok_for_sibcall): Remove long_call
restriction.
gcc/testsuite
gcc.target/arm/tail-long-call.c: New test.
diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index d5f9ff3..8dcdfa8 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -6087,11 +6087,6 @@ arm_function_ok_for_sibcall (tree decl, tree exp)
if (TARGET_VXWORKS_RTP flag_pic !targetm.binds_local_p (decl))
return false;
- /* Cannot tail-call to long calls, since these are out of range of
- a branch instruction. */
- if (decl arm_is_long_call_p (decl))
-return false;
-
/* If we are interworking and the function is not declared static
then we can't tail-call it unless we know that it exists in this
compilation unit (since it might be a Thumb routine). */
diff --git a/gcc/config/arm/arm.md b/gcc/config/arm/arm.md
index 2ddda02..fe285f0 100644
--- a/gcc/config/arm/arm.md
+++ b/gcc/config/arm/arm.md
@@ -9444,8 +9444,10 @@
TARGET_32BIT
{
-if (!REG_P (XEXP (operands[0], 0))
-(GET_CODE (XEXP (operands[0], 0)) != SYMBOL_REF))
+if ((!REG_P (XEXP (operands[0], 0))
+ GET_CODE (XEXP (operands[0], 0)) != SYMBOL_REF)
+ || (GET_CODE (XEXP (operands[0], 0)) == SYMBOL_REF
+ arm_is_long_call_p (SYMBOL_REF_DECL (XEXP (operands[0], 0)
XEXP (operands[0], 0) = force_reg (SImode, XEXP (operands[0], 0));
if (operands[2] == NULL_RTX)
@@ -9462,8 +9464,10 @@
TARGET_32BIT
{
-if (!REG_P (XEXP (operands[1], 0))
- (GET_CODE (XEXP (operands[1],0)) != SYMBOL_REF))
+if ((!REG_P (XEXP (operands[1], 0))
+ GET_CODE (XEXP (operands[1], 0)) != SYMBOL_REF)
+ || (GET_CODE (XEXP (operands[1], 0)) == SYMBOL_REF
+ arm_is_long_call_p (SYMBOL_REF_DECL (XEXP (operands[1], 0)
XEXP (operands[1], 0) = force_reg (SImode, XEXP (operands[1], 0));
if (operands[3] == NULL_RTX)
diff --git a/gcc/config/arm/predicates.md b/gcc/config/arm/predicates.md
index ce5c9a8..3673343 100644
--- a/gcc/config/arm/predicates.md
+++ b/gcc/config/arm/predicates.md
@@ -673,5 +673,6 @@
(match_code reg 0)))
(define_predicate call_insn_operand
- (ior (match_code symbol_ref)
+ (ior (and (match_code symbol_ref)
+ (match_test !arm_is_long_call_p (SYMBOL_REF_DECL (op
(match_operand 0 s_register_operand)))
diff --git a/gcc/testsuite/gcc.target/arm/tail-long-call.c b/gcc/testsuite/gcc.target/arm/tail-long-call.c
new file mode 100644
index 000..9b27468
--- /dev/null
+++ b/gcc/testsuite/gcc.target/arm/tail-long-call.c
@@ -0,0 +1,12 @@
+/* { dg-skip-if need at least armv5te { *-*-* } { -march=armv[234]* -mthumb } { } } */
+/* { dg-options -O2 -march=armv5te -marm } */
+/* { dg-final { scan-assembler bx } } */
+/* { dg-final { scan-assembler-not blx } } */
+
+int lcal (int) __attribute__ ((long_call));
+
+int
+dec (int a)
+{
+ return lcal (a);
+}
Re: [PATCH] x86: _mm512_set1_p[sd]
On Mon, Mar 24, 2014 at 12:13 PM, Ulrich Drepper drep...@gmail.com wrote: On Mon, Mar 24, 2014 at 1:50 AM, Kirill Yukhin kirill.yuk...@gmail.com wrote: Your patch is correct IMHO, but maybe it worst to add all missing `mm512_set1*' stuff? According to trunk and [1] we're still missing (beside mentioned by you) _mm512_set1_epi16 and _mm512_set1_epi8 broadcasts. Yes, more are missing, but I think those will need new builtins. The _ps and _pd don't require additional instructions. _mm512_set1_epi16 might have to map to vpbroadcastw. _mm512_set1_epi8 might have to map to vpbroadcastb. I haven't seen a way to generate those instructions if needed and so this work was out of scope for now due to time constraints. I agree, they should be added as quickly as possible to avoid releasing headers with incomplete APIs. What is the verdict on checking these changes in? Too late for the next release? This kind of changes can also be made for 4.9.1 for example. Richard.
Re: [RFA jit] initialize input_location
Dave == David Malcolm dmalcolm-h+wxahxf7alqt0dzr+a...@public.gmane.org writes: Dave Given this declaration in input.c: Dave location_t input_location; Dave then assigning 0 is a faithful way of resetting it to its initial state. Dave That said, 0 feels like a magic number. Would it better to assign Dave UNKNOWN_LOCATION to it? which is 0, c.f. input.h: Dave #define UNKNOWN_LOCATION ((source_location) 0) Dave If so, perhaps the declaration in input.c should gain an initializer to Dave the same value? (shouldn't affect the code, since it's 0 either way, Dave but perhaps it's more readable?) Sounds reasonable to me. How about the appended? Tom commit 79ce51eaf41ce7b0e90407245b7cad33ada6887b Author: Tom Tromey tro...@redhat.com Date: Thu Mar 20 08:51:25 2014 -0600 initialize input_location This patch initializes input_location at the same spot where the line table is initialized. Without this, it's possible to crash when emitting a diagnostic in a reinvocation of the compiler, because input_location refers to a location that is no longer valid. diff --git a/gcc/ChangeLog.jit b/gcc/ChangeLog.jit index ee1df88..5145cf9 100644 --- a/gcc/ChangeLog.jit +++ b/gcc/ChangeLog.jit @@ -1,3 +1,8 @@ +2014-03-24 Tom Tromey tro...@redhat.com + + * toplev.c (general_init): Initialize input_location. + * input.c (input_location): Initialize to UNKNOWN_LOCATION. + 2014-03-19 Tom Tromey tro...@redhat.com * timevar.h (auto_timevar): New class. diff --git a/gcc/input.c b/gcc/input.c index a141a92..90a708c 100644 --- a/gcc/input.c +++ b/gcc/input.c @@ -1,5 +1,5 @@ /* Data and functions related to line maps and input files. - Copyright (C) 2004-2013 Free Software Foundation, Inc. + Copyright (C) 2004-2014 Free Software Foundation, Inc. This file is part of GCC. @@ -25,7 +25,7 @@ along with GCC; see the file COPYING3. If not see /* Current position in real source file. */ -location_t input_location; +location_t input_location = UNKNOWN_LOCATION; struct line_maps *line_table; diff --git a/gcc/toplev.c b/gcc/toplev.c index b257ab2..54a884e 100644 --- a/gcc/toplev.c +++ b/gcc/toplev.c @@ -1161,6 +1161,7 @@ general_init (const char *argv0) table. */ init_ggc (); init_stringpool (); + input_location = UNKNOWN_LOCATION; line_table = ggc_alloc_line_maps (); linemap_init (line_table); line_table-reallocator = realloc_for_line_map;
Re: [PATCH AArch64] Fix aarch64_simd_valid_immediate for Bigendian
On 21 March 2014 14:55, Alan Lawrence alan.lawre...@arm.com wrote:
This patch fixes a bug whereby a vector like V8QImode {1,0,1,0,1,0,1,0} can
result in an instruction like
movi v1.4h, 0x1
whereas on bigendian this should be
movi v1.4h, 0x1, lsl 8
Regression tested on aarch64_be-none-elf: no changes in libstdc++, newlib;
no regressions in gcc or g++ and FAIL-PASS as listed below.
Ok for trunk (stage 4) ?
Cheers, Alan
gcc/ChangeLog:
2014-03-21 Alan Lawrence alan.lawre...@arm.com
* config/aarch64/aarch64.c (aarch64_simd_valid_immediate): reverse
order
of elements for bigendian.
s/reverse/Reverse/
This should be fixed now in stage-4, the fix looks straight forward.
If there are no objections from RM's in the next 24 hours go ahead and
commit it.
Cheers
/Marcus
[RFC] Remove PUSH_ARGS_REVERSED from the RTL expander.
Hi,
Consider this testcase:
extern void foo (int a, int b, int c, int d);
void
bar (int b, int c, int d)
{
foo (3, b, c, d);
}
For many ABI's we will have on entry to the function
r0 = b
r1 = c
r2 = d
If we process arguments to the call to foo left-to-right
(PUSH_ARGS_REVERSED == 0) we assign temporaries, and then hard registers
in this order:
t0 = 3
t1 = r0
t2 = r1
t3 = r2
r0 = t0
r1 = t1
r2 = t2
r3 = t3
We can't eliminate any of these temporaries as their live ranges overlap.
However, If we process the arguments right-to-left (PUSH_ARGS_REVERSED == 1),
we get this order:
t0 = 3
t1 = r0
t2 = r1
t3 = r2
r3 = t3
r2 = t2
r1 = t1
r0 = t0
And then we can start eliminating temporaries we don't need and get:
r3 = r2
r2 = r1
r1 = r0
r0 = 3
Which is much neater.
It seems to me that this would probably be of benefit on all targets.
This would be an argument for setting PUSH_ARGS_REVERSED to 1 by default
for all targets. However, this would have a perceivable impact on argument
evaluation order (which is unspecified in C, but people have shown
sensitivity to it changing in the past and we suspect some people may
have built systems relying on the behviour... ho hum...).
However, now that all side effects are handled when we are in SSA
form, it should be possible to refactor calls.c and expr.c as if
PUSH_ARGS_REVERSED were always defined to 1, without changing the
argument evaluation order in gimplify.c.
In this way, we have the best of both worlds; we maintain argument
evaluation order and gain the optimizations given by removing
overlapping live ranges for parameters.
I've bootstrapped and regression tested this on x86, ARM and AArch64 - but
I am well aware these are fairly standard targets, do you have any
suggestions or comments on which targets this change will affect?
If not, is this OK for stage-1?
Thanks,
James
---
gcc/
2014-03-21 James Greenhalgh james.greenha...@arm.com
* calls.c (initialize_argument_information): Always treat
PUSH_ARGS_REVERSED as 1, simplify code accordingly.
(expand_call): Likewise.
(emit_library_call_calue_1): Likewise.
* expr.c (PUSH_ARGS_REVERSED): Do not define.
(emit_push_insn): Always treat PUSH_ARGS_REVERSED as 1, simplify
code accordingly.
diff --git a/gcc/calls.c b/gcc/calls.c
index f392319..2e91918 100644
--- a/gcc/calls.c
+++ b/gcc/calls.c
@@ -1104,8 +1104,6 @@ initialize_argument_information (int num_actuals ATTRIBUTE_UNUSED,
{
CUMULATIVE_ARGS *args_so_far_pnt = get_cumulative_args (args_so_far);
location_t loc = EXPR_LOCATION (exp);
- /* 1 if scanning parms front to back, -1 if scanning back to front. */
- int inc;
/* Count arg position in order args appear. */
int argpos;
@@ -1116,22 +1114,9 @@ initialize_argument_information (int num_actuals ATTRIBUTE_UNUSED,
args_size-var = 0;
/* In this loop, we consider args in the order they are written.
- We fill up ARGS from the front or from the back if necessary
- so that in any case the first arg to be pushed ends up at the front. */
+ We fill up ARGS from the back. */
- if (PUSH_ARGS_REVERSED)
-{
- i = num_actuals - 1, inc = -1;
- /* In this case, must reverse order of args
- so that we compute and push the last arg first. */
-}
- else
-{
- i = 0, inc = 1;
-}
-
- /* First fill in the actual arguments in the ARGS array, splitting
- complex arguments if necessary. */
+ i = num_actuals - 1;
{
int j = i;
call_expr_arg_iterator iter;
@@ -1140,7 +1125,7 @@ initialize_argument_information (int num_actuals ATTRIBUTE_UNUSED,
if (struct_value_addr_value)
{
args[j].tree_value = struct_value_addr_value;
- j += inc;
+ j--;
}
FOR_EACH_CALL_EXPR_ARG (arg, iter, exp)
{
@@ -1152,17 +1137,17 @@ initialize_argument_information (int num_actuals ATTRIBUTE_UNUSED,
{
tree subtype = TREE_TYPE (argtype);
args[j].tree_value = build1 (REALPART_EXPR, subtype, arg);
- j += inc;
+ j--;
args[j].tree_value = build1 (IMAGPART_EXPR, subtype, arg);
}
else
args[j].tree_value = arg;
- j += inc;
+ j--;
}
}
/* I counts args in order (to be) pushed; ARGPOS counts in order written. */
- for (argpos = 0; argpos num_actuals; i += inc, argpos++)
+ for (argpos = 0; argpos num_actuals; i--, argpos++)
{
tree type = TREE_TYPE (args[i].tree_value);
int unsignedp;
@@ -2952,9 +2937,8 @@ expand_call (tree exp, rtx target, int ignore)
compute_argument_addresses (args, argblock, num_actuals);
- /* If we push args individually in reverse order, perform stack alignment
- before the first push (the last arg). */
- if (PUSH_ARGS_REVERSED argblock == 0
+ /* Perform stack alignment before the first push (the last arg). */
+ if (argblock == 0
adjusted_args_size.constant reg_parm_stack_space
Re: [Fortran][PATCH][gomp4]: Transform OpenACC loop directive
Hi Tobias!
Thanks a lot for your review!
I fixed my patch.
On 20.03.2014 00:16, Tobias Burnus wrote:
* !$acc cache() - parsing supported, but then aborting with a
not-implemented error
* OpenACC 2.0a additions.
Am I right?
Not exactly, in addition to cache directive there are also subarrays
(array sections in terms of OpenMP) to be implemented from OpenACC 1.0.
Also, the support of OpenACC 2.0 is not full (remain ROUTINE and ATOMIC
directives and lots of clauses).
For DO CONCURRENT, it is not.
I always forget about this kind of loops.
I think we should really consider to reject DO CONCURRENT with a not
permitted; it is currently not explicitly supported by OpenACC; I
think we can still worry about it, when it will be explicitly added to
OpenACC.
I don't think so.
Issues with DO CONCURRENT:
* You use code-ext.iterator-var - that's fine with DO but not with
DO CONCURRENT, which uses a code-ext.forall_iterator
Fixed.
* Do concurrent also handles multiple variables in a single statement,
such as:
integer :: i, j, b(3,5)
DO CONCURRENT(i=1:3, j=1:5:2)
b(i, j) = -42
END DO
end
For each variable in the statement single for loop is generated. Example
!$acc loop
DO CONCURRENT(i=1:3, j=1:5:2)
b(i, j) = -42
END DO
become
#pragma acc loop collapse(2)
for (i = 1; i 3; i++)
for (count.0 = 0; count.0 = 2; count.0++)
{
j = count.0*2 + 1;
b[j-1,i-1] = -42;
}
* And do concurrent also supports masks:
logical :: my_mask(3)
integer :: i, b(3)
b(i) = [5, 5, 2]
my_mask = [.true., .false., .true.]
do concurrent (i=1:3, b(i) == 5 .and. my_mask(i))
b(i) = -42
end do
end
This is doable: generate mask conditions inside of the deepest for loop
(see applied patch). So, GENERIC of your example will be like:
#pragma acc loop collapse(1)
for (i = 1; i 3; i++)
{
if (b[i-1] == 5 my_mask[i-1])
{
b[i-1] = -42;
}
}
Is it OK now?
--
Ilmir.
From 50c0eef6f0a48fa05ab5de8924376a75fb23aca6 Mon Sep 17 00:00:00 2001
From: Ilmir Usmanov i.usma...@samsung.com
Date: Sat, 22 Mar 2014 18:54:17 +0400
Subject: [PATCH] Transform OpenACC loop directive to GENERIC
---
* gcc/fortran/trans-openmp.c (gfc_trans_oacc_loop): New function.
(gfc_trans_oacc_combined_directive): Call it.
(gfc_trans_oacc_directive): Likewise.
(gfc_trans_oacc_loop_generate_for): New helper function.
(gfc_trans_oacc_loop_generate_mask_conds): Likewise.
* gcc/tree-pretty-print (dump_omp_clause): Fix WORKER and VECTOR.
* gcc/omp-low.c (scan_sharing_clauses): Reject OpenACC loop clauses.
gcc/testsuite/gfortran.dg/goacc/
* loop-tree.f95: New test.
* loop-4.f95: Likewise.
diff --git a/gcc/fortran/trans-openmp.c b/gcc/fortran/trans-openmp.c
index 29364f4..e4a4f9a 100644
--- a/gcc/fortran/trans-openmp.c
+++ b/gcc/fortran/trans-openmp.c
@@ -1571,11 +1571,304 @@ typedef struct dovar_init_d {
tree init;
} dovar_init;
+/* Helper function to generate a single for loop. */
+static void
+gfc_trans_oacc_loop_generate_for (stmtblock_t *pblock, gfc_se *se,
+ gfc_expr *var_expr, gfc_expr *start_expr,
+ gfc_expr *end_expr, gfc_expr *step_expr,
+ int i, tree *init, tree *cond, tree *incr,
+ vecdovar_init* inits)
+{
+ int simple = 0;
+ tree dovar, from, to, step, type, tmp, count = NULL_TREE;
+
+ /* Evaluate all the expressions. */
+ gfc_init_se (se, NULL);
+ gfc_conv_expr_lhs (se, var_expr);
+ gfc_add_block_to_block (pblock, se-pre);
+ dovar = se-expr;
+ type = TREE_TYPE (dovar);
+ gcc_assert (TREE_CODE (type) == INTEGER_TYPE);
+
+ gfc_init_se (se, NULL);
+ gfc_conv_expr_val (se, start_expr);
+ gfc_add_block_to_block (pblock, se-pre);
+ from = gfc_evaluate_now (se-expr, pblock);
+
+ gfc_init_se (se, NULL);
+ gfc_conv_expr_val (se, end_expr);
+ gfc_add_block_to_block (pblock, se-pre);
+ to = gfc_evaluate_now (se-expr, pblock);
+
+ gfc_init_se (se, NULL);
+ gfc_conv_expr_val (se, step_expr);
+ gfc_add_block_to_block (pblock, se-pre);
+ step = gfc_evaluate_now (se-expr, pblock);
+
+ /* Special case simple loops. */
+ if (TREE_CODE (dovar) == VAR_DECL)
+{
+ if (integer_onep (step))
+ simple = 1;
+ else if (tree_int_cst_equal (step, integer_minus_one_node))
+ simple = -1;
+}
+
+ /* Loop body. */
+ if (simple)
+{
+ TREE_VEC_ELT (*init, i) = build2_v (MODIFY_EXPR, dovar, from);
+ /* The condition should not be folded. */
+ TREE_VEC_ELT (*cond, i) = build2_loc (input_location, simple 0
+ ? LE_EXPR : GE_EXPR,
+ boolean_type_node, dovar, to);
+ TREE_VEC_ELT (*incr, i) = fold_build2_loc (input_location, PLUS_EXPR,
+ type, dovar, step);
+ TREE_VEC_ELT (*incr, i) = fold_build2_loc (input_location,
+ MODIFY_EXPR,
+ type, dovar,
+ TREE_VEC_ELT (*incr, i));
+}
+ else
+{
+ /* STEP is not 1 or -1. Use:
+ for (count = 0; count (to + step - from) / step; count++)
+ {
+ dovar = from + count * step;
+ body;
+ cycle_label:;
+ } */
+
Re: [RFC] Remove PUSH_ARGS_REVERSED from the RTL expander.
On Mon, Mar 24, 2014 at 12:44 PM, James Greenhalgh
james.greenha...@arm.com wrote:
Hi,
Consider this testcase:
extern void foo (int a, int b, int c, int d);
void
bar (int b, int c, int d)
{
foo (3, b, c, d);
}
For many ABI's we will have on entry to the function
r0 = b
r1 = c
r2 = d
If we process arguments to the call to foo left-to-right
(PUSH_ARGS_REVERSED == 0) we assign temporaries, and then hard registers
in this order:
t0 = 3
t1 = r0
t2 = r1
t3 = r2
r0 = t0
r1 = t1
r2 = t2
r3 = t3
We can't eliminate any of these temporaries as their live ranges overlap.
However, If we process the arguments right-to-left (PUSH_ARGS_REVERSED == 1),
we get this order:
t0 = 3
t1 = r0
t2 = r1
t3 = r2
r3 = t3
r2 = t2
r1 = t1
r0 = t0
And then we can start eliminating temporaries we don't need and get:
r3 = r2
r2 = r1
r1 = r0
r0 = 3
Which is much neater.
It seems to me that this would probably be of benefit on all targets.
This would be an argument for setting PUSH_ARGS_REVERSED to 1 by default
for all targets. However, this would have a perceivable impact on argument
evaluation order (which is unspecified in C, but people have shown
sensitivity to it changing in the past and we suspect some people may
have built systems relying on the behviour... ho hum...).
However, now that all side effects are handled when we are in SSA
form, it should be possible to refactor calls.c and expr.c as if
PUSH_ARGS_REVERSED were always defined to 1, without changing the
argument evaluation order in gimplify.c.
In this way, we have the best of both worlds; we maintain argument
evaluation order and gain the optimizations given by removing
overlapping live ranges for parameters.
I've bootstrapped and regression tested this on x86, ARM and AArch64 - but
I am well aware these are fairly standard targets, do you have any
suggestions or comments on which targets this change will affect?
If not, is this OK for stage-1?
Maybe somebody remembers why we have both paths. I'd rather
make gimplification independent of this as well, choosing either
variant.
Do you have any hard numbers to compare? Say cc1 code size,
when comparing PUSH_ARGS_REVERSED 1 vs 0?
Thanks,
Richard.
Thanks,
James
---
gcc/
2014-03-21 James Greenhalgh james.greenha...@arm.com
* calls.c (initialize_argument_information): Always treat
PUSH_ARGS_REVERSED as 1, simplify code accordingly.
(expand_call): Likewise.
(emit_library_call_calue_1): Likewise.
* expr.c (PUSH_ARGS_REVERSED): Do not define.
(emit_push_insn): Always treat PUSH_ARGS_REVERSED as 1, simplify
code accordingly.
Re: [AArch64] Logical vector shift right conformance
On Thu, Mar 20, 2014 at 12:59:27PM +, Marcus Shawcroft wrote: On 25 February 2014 11:58, Alex Velenko alex.vele...@arm.com wrote: Hi, This patch fixes a bug in vshr_n_u64 and vshrd_n_u64 intrinsic behavior in case of shift by 64. Shift by 64 is strictly defined in ACLE to use ushr instruction intended by those intrinsics. The testcase provided also tests the behavior for intrinsics mentioned above with values other then 64. Besides, the test checks that an illeagal ushr shift by 0 is not generated, expecting the test to compile and run correctly generating instructions other than ushr. The patch was tested for LE and BE with no regressions. Is given patch ok for stage-4? I think this is OK for stage-4, but leave 24h before committing to allow the RM's opportunity to object / comment. I've committed this on Alex' behalf as revision 208789. Thanks, James
Re: [PATCH, doc] Add myself as NDS32 port contributor in the documentation.
On Mon, 24 Mar 2014, Chung-Ju Wu wrote: I would like to add an item to describe myself as nds32 port contributor. The plaintext ChangeLog and patch are as below. Bootstrapped and the webpage can be successfully built via 'make html'. Is it OK for trunk? +2014-03-24 Chung-Ju Wu jasonw...@gmail.com + + * doc/contrib.texi: Add myself as Andes nds32 port contributor. Yep, absolutely. Gerald
Re: [PATCH] x86: _mm512_set1_p[sd]
Hello! On Mon, Mar 24, 2014 at 12:13 PM, Ulrich Drepper drep...@gmail.com wrote: Your patch is correct IMHO, but maybe it worst to add all missing `mm512_set1*' stuff? According to trunk and [1] we're still missing (beside mentioned by you) _mm512_set1_epi16 and _mm512_set1_epi8 broadcasts. Yes, more are missing, but I think those will need new builtins. The _ps and _pd don't require additional instructions. _mm512_set1_epi16 might have to map to vpbroadcastw. _mm512_set1_epi8 might have to map to vpbroadcastb. I haven't seen a way to generate those instructions if needed and so this work was out of scope for now due to time constraints. I agree, they should be added as quickly as possible to avoid releasing headers with incomplete APIs. What is the verdict on checking these changes in? Too late for the next release? This kind of changes can also be made for 4.9.1 for example. OTOH, these changes are isolated to intrinsic header files, and we have quite extensive testsuite for these. I see no problem to check-in these changes even at this stage. So, if there is no better solution I propose to check these changes in, since the benefit to users outweight (minor) risk. Would this be OK from RM POV, also weighting in benefits to users? Uros
Re: [PATCH] x86: _mm512_set1_p[sd]
On Mon, Mar 24, 2014 at 1:25 PM, Uros Bizjak ubiz...@gmail.com wrote: Hello! On Mon, Mar 24, 2014 at 12:13 PM, Ulrich Drepper drep...@gmail.com wrote: Your patch is correct IMHO, but maybe it worst to add all missing `mm512_set1*' stuff? According to trunk and [1] we're still missing (beside mentioned by you) _mm512_set1_epi16 and _mm512_set1_epi8 broadcasts. Yes, more are missing, but I think those will need new builtins. The _ps and _pd don't require additional instructions. _mm512_set1_epi16 might have to map to vpbroadcastw. _mm512_set1_epi8 might have to map to vpbroadcastb. I haven't seen a way to generate those instructions if needed and so this work was out of scope for now due to time constraints. I agree, they should be added as quickly as possible to avoid releasing headers with incomplete APIs. What is the verdict on checking these changes in? Too late for the next release? This kind of changes can also be made for 4.9.1 for example. OTOH, these changes are isolated to intrinsic header files, and we have quite extensive testsuite for these. I see no problem to check-in these changes even at this stage. So, if there is no better solution I propose to check these changes in, since the benefit to users outweight (minor) risk. Would this be OK from RM POV, also weighting in benefits to users? Yes, sure. I've just meant that it's ok to do more work for 4.9.1, too. Richard. Uros
Re: [PATCH] x86: _mm512_set1_p[sd]
On Mon, Mar 24, 2014 at 01:33:11PM +0100, Richard Biener wrote:
On Mon, Mar 24, 2014 at 1:25 PM, Uros Bizjak ubiz...@gmail.com wrote:
Hello!
On Mon, Mar 24, 2014 at 12:13 PM, Ulrich Drepper drep...@gmail.com wrote:
Your patch is correct IMHO, but maybe it worst to add all missing
`mm512_set1*' stuff?
According to trunk and [1] we're still missing (beside mentioned by you)
_mm512_set1_epi16 and _mm512_set1_epi8 broadcasts.
Yes, more are missing, but I think those will need new builtins. The
_ps and _pd don't require additional instructions.
_mm512_set1_epi16 might have to map to vpbroadcastw. _mm512_set1_epi8
might have to map to vpbroadcastb. I haven't seen a way to generate
those instructions if needed and so this work was out of scope for now
due to time constraints. I agree, they should be added as quickly as
possible to avoid releasing headers with incomplete APIs.
What is the verdict on checking these changes in? Too late for the
next release?
This kind of changes can also be made for 4.9.1 for example.
OTOH, these changes are isolated to intrinsic header files, and we
have quite extensive testsuite for these. I see no problem to check-in
these changes even at this stage.
So, if there is no better solution I propose to check these changes
in, since the benefit to users outweight (minor) risk. Would this be
OK from RM POV, also weighting in benefits to users?
Yes, sure. I've just meant that it's ok to do more work for 4.9.1, too.
But, if for say _mm512_set1_epi8 you have no intrinsics, just do something
similar to what _mm256_set_epi8 and _mm256_set1_epi8 do, the compiler should
be smart enough to recognize those as broadcasts.
The following is recognized well:
typedef char v32qi __attribute__((vector_size (32)));
v32qi foo (char a)
{
return (v32qi) { a, a, a, a, a, a, a, a, a, a, a, a, a, a, a, a, a, a, a, a,
a, a, a, a, a, a, a, a, a, a, a, a };
}
This isn't:
typedef char v64qi __attribute__((vector_size (64)));
v64qi foo (char a)
{
return (v64qi) { a, a, a, a, a, a, a, a, a, a, a, a, a, a, a, a, a, a, a, a,
a, a, a, a, a, a, a, a, a, a, a, a, a, a, a, a, a, a, a, a, a, a, a, a, a, a,
a, a, a, a, a, a, a, a, a, a, a, a, a, a, a, a, a, a };
}
But I believe it has been discussed already that the V32HImode and V64QImode
support is incomplete in 4.9. While I think there are no direct broadcasts
for these modes, one can e.g. use AVX2 broadcasts and then duplicate into
the 512-bit mode.
See http://gcc.gnu.org/ml/gcc-patches/2014-01/msg00757.html
Jakub
Re: [RFC] Remove PUSH_ARGS_REVERSED from the RTL expander.
Hi, On Mon, 24 Mar 2014, Richard Biener wrote: Maybe somebody remembers why we have both paths. I'd rather make gimplification independent of this as well, choosing either variant. I can't say why we have the !PUSH_ARGS_REVERSED path (so I guess that's the way that initially was there, before the distinction was made), but the PUSH_ARGS_REVERSED==1 path is important when you have push instructions and arguments grow in the opposite direction of the stack. The latter is the case for almost all targets, so as soon as you have push instructions (and no ACCUMULATE_OUTGOING_ARGS) you'll want to have PUSH_ARGS_REVERSED==1 as well. I guess the !PUSH_ARGS_REVERSED path only has advantages for the few targets where stack and args grow the same way and that use push instructions for argument passing, which currently are none. pa-64 does have same-direction arguments and stack (both upward), but doesn't use push, and the only other ARGS_GROW_DOWNWARD (pa-32bit and stormy16) also have !STACK_GROWS_DOWNWARD, so again opposite direction. Without push instructions or with ACCUMULATE_OUTGOING_ARGS I guess it doesn't matter much for parameters passed in memory (the offsets simply will be N to 0 instead of 0 to N), and for register arguments there's a slight advantage for PUSH_ARGS_REVERSED==1 for the usual case of same-ordered arguments passed down, like in James' example. Do you have any hard numbers to compare? Say cc1 code size, when comparing PUSH_ARGS_REVERSED 1 vs 0? If we'd agree on only one way, then it must be PUSH_ARGS_REVERSED==1. That would be a change in argument gimplification (and hence eval) order for many targets, and could result in unexpected side-effects for invalid code, like James said. IMO no reason to not try that in stage 1, though. Ciao, Michael.
Please revert the patches in bug #54040 and #59346 and special case x32
In reply to the thread ending with:
http://gcc.gnu.org/ml/gcc-patches/2013-11/msg02069.html
and bugs:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54040
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59346
Changing s-osinte-posix.adb
- tv_nsec = long (Long_Long_Integer (F * 10#1#E9)));
+ tv_nsec = time_t (Long_Long_Integer (F * 10#1#E9)));
breaks the build for kFreeBSD and Hurd too (in addition to hpux and solaris).
Note that POSIX specified tv_nsec to be long (i.e. 64 bit), see:
http://pubs.opengroup.org/onlinepubs/009695299/basedefs/time.h.html
The time.h header shall declare the structure timespec, which has at
least the following members:
time_t tv_secSeconds.
longtv_nsec Nanoseconds.
Additionally Linux/kFreeBSD/Hurd all defines struct timespec in time.h as
follows:
/* POSIX.1b structure for a time value. This is like a `struct timeval'
but
has nanoseconds instead of microseconds. */
struct timespec
{
__time_t tv_sec;/* Seconds. */
__syscall_slong_t tv_nsec; /* Nanoseconds. */
};
So defining tv_nsec to be time_t is completely wrong. The problem seems
to be present only for the x32 architecture, so why not make a special-case
solution for that arch. Obviously x32 is non-POSIX compliant since long
is 32 bits, resulting in tv_nsec being 32 bits where it needs to be 64
bits. Isn't it possible to handle the differences for x32 with a
s-osinte-linux-x32.ads file, even with s-osinte-posix.adb stays intact?
Then ther changes would be limited to:
* s-linux-x32.ads: New file.
* s-osprim-x32.adb: Likewise.
* gcc-interface/Makefile.in (LIBGNAT_TARGET_PAIRS): Replace
s-linux.ads with s-linux-x32.ads, s-osprim-posix.adb with
s-osprim-x32.adb for x32.
and the rest would be obsolete:
* s-linux.ads (time_t): New type.
* s-linux-alpha.ads (time_t): Likewise.
* s-linux-hppa.ads (time_t): Likewise.
* s-linux-mipsel.ads (time_t): Likewise.
* s-linux-sparc.ads (time_t): Likewise.
* s-osinte-linux.ads (time_t): Mark it private. Replace long
with System.Linux.time_t.
(timespec): Replace long with time_t.
* s-osinte-posix.adb (To_Timespec): Likewise.
* s-taprop-linux.adb (timeval): Replace C.long with
System.OS_Interface.time_t.
and
* s-osinte-hpux.ads (timespec): Change type of tv_nsec field to time_t.
* s-osinte-kfreebsd-gnu.ads (timespec): Likewise.
* s-osinte-solaris-posix.ads (timespec): Likewise.
Possible content in s-osinte-linux-x32.ads would be:
type tv_nsec_t is private;
type tv_nsec_t is new Long_Long_Integer;
type timespec is record
tv_sec : time_t;
tv_nsec : tv_nsec_t;
end record;
pragma Convention (C, timespec);
Re: [committed] Fix failure of gcc.dg/tree-prof/pr59003.c on hppa*-*-hpux*
On 3/24/2014 2:48 AM, Rainer Orth wrote:
John David Anglin dave.ang...@bell.net writes:
Index: gcc.dg/tree-prof/pr59003.c
===
--- gcc.dg/tree-prof/pr59003.c (revision 208769)
+++ gcc.dg/tree-prof/pr59003.c (working copy)
@@ -1,6 +1,7 @@
/* PR target/59003 */
/* { dg-options -O2 } */
/* { dg-options -O2 -mtune=amdfam10 { target i?86-*-* x86_64-*-* } } */
+/* { dg-options -O2 -fno-common { target hppa*-*-hpux* } } */
Better handled with dg-additional-options rather than duplicating
dg-options. No need to change though, since the x86 entry already used
the less preferred style.
I already tried it. dg-additional-options isn't supported in tree-prof.
Dave
--
John David Anglindave.ang...@bell.net
Re: [committed] Fix failure of gcc.dg/tree-prof/pr59003.c on hppa*-*-hpux*
John David Anglin dave.ang...@bell.net writes:
On 3/24/2014 2:48 AM, Rainer Orth wrote:
John David Anglin dave.ang...@bell.net writes:
Index: gcc.dg/tree-prof/pr59003.c
===
--- gcc.dg/tree-prof/pr59003.c (revision 208769)
+++ gcc.dg/tree-prof/pr59003.c (working copy)
@@ -1,6 +1,7 @@
/* PR target/59003 */
/* { dg-options -O2 } */
/* { dg-options -O2 -mtune=amdfam10 { target i?86-*-* x86_64-*-* } } */
+/* { dg-options -O2 -fno-common { target hppa*-*-hpux* } } */
Better handled with dg-additional-options rather than duplicating
dg-options. No need to change though, since the x86 entry already used
the less preferred style.
I already tried it. dg-additional-options isn't supported in tree-prof.
It may well be that just accepting it in profopt.exp (and compat.exp and
lto.exp and plugin-support.exp that all have copies of that code ;-)
works.
I'll give it a try.
Rainer
--
-
Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [committed] Skip gcc.dg/torture/pr60092.c on 32-bit hpux
On 3/24/2014 2:45 AM, Rainer Orth wrote:
John David Anglin dave.ang...@bell.net writes:
Index: gcc.dg/torture/pr60092.c
===
--- gcc.dg/torture/pr60092.c(revision 208769)
+++ gcc.dg/torture/pr60092.c(working copy)
@@ -1,5 +1,6 @@
/* { dg-do run } */
/* { dg-require-weak } */
+/* { dg-skip-if No undefined weak { hppa*-*-hpux* { ! lp64 } } { * } {
} } */
Please omit those default args to dg-skip-if. Besides, it seems we
should have a separate undefined_weak (or whatever) keyword for this,
rather than listing targets explicitly. But that's certainly not 4.9
material.
I agree. I'll see about removing the default arguments. There are a
bunch of tests
with the same dg-skip-if statement.
Dave
--
John David Anglindave.ang...@bell.net
Re: [committed] Skip gcc.dg/torture/pr60092.c on 32-bit hpux
John David Anglin dave.ang...@bell.net writes:
On 3/24/2014 2:45 AM, Rainer Orth wrote:
John David Anglin dave.ang...@bell.net writes:
Index: gcc.dg/torture/pr60092.c
===
--- gcc.dg/torture/pr60092.c(revision 208769)
+++ gcc.dg/torture/pr60092.c(working copy)
@@ -1,5 +1,6 @@
/* { dg-do run } */
/* { dg-require-weak } */
+/* { dg-skip-if No undefined weak { hppa*-*-hpux* { ! lp64 } } {
* } { } } */
Please omit those default args to dg-skip-if. Besides, it seems we
should have a separate undefined_weak (or whatever) keyword for this,
rather than listing targets explicitly. But that's certainly not 4.9
material.
I agree. I'll see about removing the default arguments. There are a bunch
of tests
Thanks.
with the same dg-skip-if statement.
I know. I mean to make a pass over the whole testsuite removing those
(now superfluous) default args. This stuff tends to be just copied
around, so it will resurface over and over again. Same for other stuff:
our testsuite is riddled with copy-and-paste programming ;-)
Rainer
--
-
Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [PATCH, PR 59176] Mark zombie call graph nodes to remove verifier false positive
Hi, On Fri, Mar 21, 2014 at 09:40:39PM +0100, Jan Hubicka wrote: On Thu, 20 Mar 2014, Martin Jambor wrote: Hi, On Thu, Mar 20, 2014 at 07:40:56PM +0100, Jakub Jelinek wrote: On Thu, Mar 20, 2014 at 05:07:32PM +0100, Martin Jambor wrote: in the PR, verifier claims an edge is pointing to a wrong declaration even though it has successfully verified the edge multiple times before. The reason is that symtab_remove_unreachable_nodes decides to remove the body of a node and also clear any information that it is an alias of another in the process (more detailed analysis in comment #9 of the bug). In bugzilla Honza wrote that silencing the verifier is the way to go. Either we can dedicate a new flag in each cgraph_node or symtab_node just for the purpose of verification or do something more hackish like the patch below which re-uses the former_clone_of field for this purpose. Since clones are always private nodes, they should always either survive removal of unreachable nodes or be completely killed by it and should never enter the in_border zombie state. Therefore their former_clone_of must always be NULL. So I added a new special value, error_mark_node, to mark this zombie state and taught the verifier to be happy with such nodes. Bootstrapped and tested on x86_64-linux. What do you think? Don't we have like 22 spare bits in cgraph_node and 20 spare bits in symtab_node? I'd find it clearer if you just used a new flag to mark the zombie nodes. Though, I'll let Richard or Honza to decide, don't feel strongly about it. I guess you are right, here is the proper version which is currently undergoing bootstrap and testing. I agree with Jakub, the following variant is ok. With the extra bit, you probably will need to LTO pickle it, too. Oops, that omission is a mistake. I'd like to blame it on quilt but it is more probable I simply forgot. I will commit the patch below as obvious after it passes a bootstrap. I would go with just clerning the thunk flag: this makes thunk to behave like external function that is safe to do. No, no thunks are involved here, it is an alias and the alias flag is cleared and was even before I fixed PR 60419. The problem is exactly that after symtab_remove_unreachable_nodes clears the flag (and the associated reference), the verifier sees just an ordinary symbol, now seemingly unrelated to the edge destination (or the node it is cloned from). (I am back in civilization from Alaska camping, will catch up with email early next week) Well, if camping in Alaska was not punishable by sever email backlog, life would not be fair at all. Thanks, Martin 2014-03-24 Martin Jambor mjam...@suse.cz PR ipa/59176 * lto-cgraph.c (lto_output_node): Stream body_removed flag. (lto_output_varpool_node): Likewise. (input_overwrite_node): Likewise. (input_varpool_node): Likewise. Index: src/gcc/lto-cgraph.c === --- src.orig/gcc/lto-cgraph.c +++ src/gcc/lto-cgraph.c @@ -500,6 +500,7 @@ lto_output_node (struct lto_simple_outpu bp_pack_value (bp, node-force_output, 1); bp_pack_value (bp, node-forced_by_abi, 1); bp_pack_value (bp, node-unique_name, 1); + bp_pack_value (bp, node-body_removed, 1); bp_pack_value (bp, node-address_taken, 1); bp_pack_value (bp, tag == LTO_symtab_analyzed_node symtab_get_symbol_partitioning_class (node) == SYMBOL_PARTITION @@ -560,6 +561,7 @@ lto_output_varpool_node (struct lto_simp bp_pack_value (bp, node-force_output, 1); bp_pack_value (bp, node-forced_by_abi, 1); bp_pack_value (bp, node-unique_name, 1); + bp_pack_value (bp, node-body_removed, 1); bp_pack_value (bp, node-definition, 1); alias_p = node-alias (!boundary_p || node-weakref); bp_pack_value (bp, alias_p, 1); @@ -969,6 +971,7 @@ input_overwrite_node (struct lto_file_de node-force_output = bp_unpack_value (bp, 1); node-forced_by_abi = bp_unpack_value (bp, 1); node-unique_name = bp_unpack_value (bp, 1); + node-body_removed = bp_unpack_value (bp, 1); node-address_taken = bp_unpack_value (bp, 1); node-used_from_other_partition = bp_unpack_value (bp, 1); node-lowered = bp_unpack_value (bp, 1); @@ -1147,6 +1150,7 @@ input_varpool_node (struct lto_file_decl node-force_output = bp_unpack_value (bp, 1); node-forced_by_abi = bp_unpack_value (bp, 1); node-unique_name = bp_unpack_value (bp, 1); + node-body_removed = bp_unpack_value (bp, 1); node-definition = bp_unpack_value (bp, 1); node-alias = bp_unpack_value (bp, 1); node-weakref = bp_unpack_value (bp, 1);
Re: [committed] Fix failure of gcc.dg/tree-prof/pr59003.c on hppa*-*-hpux*
John David Anglin dave.ang...@bell.net writes: I already tried it. dg-additional-options isn't supported in tree-prof. Shouldn't be hard to fix. Andreas. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 And now for something completely different.
Re: [PATCH] x86: _mm*_undefined_* (for real)
Hello! 2014-03-19 Ulrich Drepper drep...@gmail.com * config/i386/avxintrin.h (_mm256_undefined_si256): Define. (_mm256_undefined_ps): Define. (_mm256_undefined_pd): Define. * config/i386/emmintrin.h (_mm_undefined_si128): Define. (_mm_undefined_pd): Define. * config/i386/xmmintrin.h (_mm_undefined_ps): Define. * config/i386/avx512fintrin.h (_mm512_undefined_si512): Define. (_mm512_undefined_ps): Define. (_mm512_undefined_pd): Define. Use _mm*_undefined_*. * config/i386/avx2intrin.h: Use _mm*_undefined_*. Based on Kirill's feedback, the patch is OK for mainline. Thanks, Uros.
Re: [PATCH] x86: _mm512_set1_p[sd]
Hello! Another set of functions missing are those to set all elements of a 512-bit vector to the same float or double value. I think the patch below uses the optimal code sequence for that. The patch requires the previous patch introducing _mm*_undefined_*. 2014-03-19 Ulrich Drepper drep...@gmail.com * config/i386/avx512fintrin.h: Define _mm512_set1_ps and _mm512_set1_pd. Based on Kirill's feedback, the patch is OK for mainline. Thanks, Uros.
Re: [PATCH, doc] Mention nds32*-*-elf in the target specific installation notes.
On Mon, 24 Mar 2014, Chung-Ju Wu wrote: +2014-03-24 Chung-Ju Wu jasonw...@gmail.com + + * doc/install.texi: Document nds32le-*-elf and nds32be-*-elf. Looks good to me. (The new patch avoids elf which I believe should have been ELF, by the way.) Gerald
Re: [PATCH] Fix PR c++/60627
OK. Jason
Re: [PATCH] PR debug/16063. Add DW_AT_type to DW_TAG_enumeration.
gcc/cp/ * dwarf2out.c (gen_enumeration_type_die): Add DW_AT_type if enum_underlying_base_type defined and DWARF version 3. * langhooks.h (struct lang_hooks_for_types): Add enum_underlying_base_type. * langhooks-def.h (LANG_HOOKS_ENUM_UNDERLYING_BASE_TYPE): New define. (LANG_HOOKS_FOR_TYPES_INITIALIZER): Add new lang hook. This should be the ChangeLog entry for cp/cp-lang.c. -cary
Re: Disable accumulate-outgoing-args for Generic and Buldozers
On Thu, Jan 23, 2014 at 3:16 PM, Jan Hubicka hubi...@ucw.cz wrote: * config/i38/x86-tune.def: Disable X86_TUNE_ACCUMULATE_OUTGOING_ARGS for generic and recent AMD chips The ChangeLog reads: 2014-01-22 Jan Hubicka j...@suse.cz * config/i386/x86-tune.def (X86_TUNE_ACCUMULATE_OUTGOING_ARGS): Enable for generic and recent AMD targets. Very confusing... Sorry, will fix it. I still see: 2014-01-22 Jan Hubicka hubi...@ucw.cz * config/i386/x86-tune.def (X86_TUNE_ACCUMULATE_OUTGOING_ARGS): Enable for generic and recent AMD targets. We should also update comments: FIXME: the flags is incorrectly enabled for amdfam10, Bulldozer, Bobcat and Generic. This is because disabling it causes large regression on mgrid due to IRA limitation leading to unecessary use of the frame pointer in 32bit mode. */ -- H.J.
[PATCH][ARM] Handle FMA code in rtx costs.
Hi all,
This patch adds proper rtx costing logic for floating point fma operations on
arm. It also handles the fma+neg combinations that can be expressed with
vfms,vfnma or vfnms instructions.
Not much else to say here...
Tested and boostrapped on arm-none-linux-gnueabihf.
Ok for next stage1?
Thanks,
Kyrill
2014-03-24 Kyrylo Tkachov kyrylo.tkac...@arm.com
* config/arm/arm.c (arm_new_rtx_costs): Handle FMA.commit 9cebc525c432e4a87ead5b513b70c99dff6628c8
Author: Kyrylo Tkachov kyrylo.tkac...@arm.com
Date: Thu Mar 20 09:13:06 2014 +
[ARM] Cost FMA operations properly.
diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index 5619ebd..e7a0530 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -10673,6 +10673,36 @@ arm_new_rtx_costs (rtx x, enum rtx_code code, enum rtx_code outer_code,
*cost = LIBCALL_COST (1);
return false;
+case FMA:
+ if (TARGET_32BIT TARGET_HARD_FLOAT TARGET_FMA)
+{
+ rtx op0 = XEXP (x, 0);
+ rtx op1 = XEXP (x, 1);
+ rtx op2 = XEXP (x, 2);
+
+ *cost = COSTS_N_INSNS (1);
+
+ /* vfms or vfnma. */
+ if (GET_CODE (op0) == NEG)
+op0 = XEXP (op0, 0);
+
+ /* vfnms or vfnma. */
+ if (GET_CODE (op2) == NEG)
+op2 = XEXP (op2, 0);
+
+ *cost += rtx_cost (op0, FMA, 0, speed_p);
+ *cost += rtx_cost (op1, FMA, 1, speed_p);
+ *cost += rtx_cost (op2, FMA, 2, speed_p);
+
+ if (speed_p)
+*cost += extra_cost-fp[mode ==DFmode].fma;
+
+ return true;
+}
+
+ *cost = LIBCALL_COST (1);
+ return false;
+
case FIX:
case UNSIGNED_FIX:
if (TARGET_HARD_FLOAT)
Re: [PATCH] Fix PR59626, _FORTIFY_SOURCE wrappers and LTO
Currently a _lot_ of packages fail to build with LTO because LTO
messes up fortify wrappers by replacing the call to the alias with
the symbol itself, making the wrapper look like infinitely
recursing.
The following patch fixes this by dropping the bodies of
DECL_EXTERN always-inline functions on the floor before IPA
(and when doing LTO). IMHO we should at some point do this
unconditional on LTO as the early inliner is supposed to
remove all references to always-inline functions.
I'm not 100% sure about the cgraph API use to drop the function
body, but at least it seems to work ;) I'm not sure if we want
to restrict the set of functions to apply this even more than
just those with always-inline and DECL_EXTERNAL set?
Now double-checking with a fortified LTO bootstrap.
Ok for trunk?
Thanks,
Richard.
2014-03-24 Richard Biener rguent...@suse.de
PR lto/59626
* passes.c (ipa_write_summaries): Drop function bodies of
extern always-inline functions.
I think it is probably better to drop these during unreachable function removal
same way as we drop extern inlines after inlining (just use cgraph_state check
to
see if we are past early inlining). I will make patch this afternoon.
Why do you need to remove the always_inline attribute? And how do I do fortified
LTO bootstrap? :)
Honza
* gcc.dg/lto/pr59626_0.c: New testcase.
* gcc.dg/lto/pr59626_1.c: Likewise.
Index: gcc/passes.c
===
*** gcc/passes.c (revision 208745)
--- gcc/passes.c (working copy)
*** ipa_write_summaries (void)
*** 2390,2404
if (cgraph_function_with_gimple_body_p (node))
{
! /* When streaming out references to statements as part of some IPA
! pass summary, the statements need to have uids assigned and the
! following does that for all the IPA passes here. Naturally, this
! ordering then matches the one IPA-passes get in their stmt_fixup
! hooks. */
!
! push_cfun (DECL_STRUCT_FUNCTION (node-decl));
! renumber_gimple_stmt_uids ();
! pop_cfun ();
}
if (node-definition)
lto_set_symtab_encoder_in_partition (encoder, node);
--- 2396,2427
if (cgraph_function_with_gimple_body_p (node))
{
! if (DECL_EXTERNAL (node-decl)
!lookup_attribute (always_inline,
!DECL_ATTRIBUTES (node-decl)) != NULL)
! {
! /* We mess up uses of extern always-inline wrappers that
! end up calling an alias to itself like glibc _FORTIFY_SOURCE
! wrappers. Simply drop the bodies of the extern inlines
! here to avoid that. */
! cgraph_release_function_body (node);
! node-analyzed = false;
! node-definition = false;
! DECL_ATTRIBUTES (node-decl)
! = remove_attribute (always_inline,
! DECL_ATTRIBUTES (node-decl));
! }
! else
! {
! /* When streaming out references to statements as part of some
! IPA pass summary, the statements need to have uids assigned
! and the following does that for all the IPA passes here.
! Naturally, this ordering then matches the one IPA-passes get
! in their stmt_fixup hooks. */
! push_cfun (DECL_STRUCT_FUNCTION (node-decl));
! renumber_gimple_stmt_uids ();
! pop_cfun ();
! }
}
if (node-definition)
lto_set_symtab_encoder_in_partition (encoder, node);
Index: gcc/testsuite/gcc.dg/lto/pr59626_0.c
===
*** gcc/testsuite/gcc.dg/lto/pr59626_0.c (revision 0)
--- gcc/testsuite/gcc.dg/lto/pr59626_0.c (working copy)
***
*** 0
--- 1,15
+ /* { dg-lto-do run } */
+
+ int __atoi (const char *) __asm__(atoi);
+ extern inline __attribute__((always_inline,gnu_inline))
+ int atoi (const char *x)
+ {
+ return __atoi (x);
+ }
+
+ int bar (int (*)(const char *));
+
+ int main()
+ {
+ return bar (atoi);
+ }
Index: gcc/testsuite/gcc.dg/lto/pr59626_1.c
===
*** gcc/testsuite/gcc.dg/lto/pr59626_1.c (revision 0)
--- gcc/testsuite/gcc.dg/lto/pr59626_1.c (working copy)
***
*** 0
--- 1,4
+ int bar (int (*fn)(const char *))
+ {
+ return fn (0);
+ }
[PATCH][ARM] Handle simple SImode PLUS and MINUS operations in rtx costs
Hi all,
I noticed that we don't handle simple reg-to-reg arithmetic operations in the
arm rtx cost functions. We should be adding the cost of alu.arith to the costs
of the operands. This patch does that. Since we don't have any cost tables yet
that have a non-zero value for that field it shouldn't affect code-gen for any
current cores.
Bootstrapped and tested on arm-none-linux-gnueabihf.
Ok for next stage1?
Thanks,
Kyrill
2014-03-24 Kyrylo Tkachov kyrylo.tkac...@arm.com
* config/arm/arm.c (arm_new_rtx_costs): Handle reg-to-reg PLUS
and MINUS RTXs.diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index bf5d1b2..3102b67 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -9428,6 +9428,14 @@ arm_new_rtx_costs (rtx x, enum rtx_code code, enum rtx_code outer_code,
*cost += rtx_cost (XEXP (x, 1), code, 1, speed_p);
return true;
}
+ else if (REG_P (XEXP (x, 0)))
+ {
+ *cost += rtx_cost (XEXP (x, 0), code, 0, speed_p)
+ + rtx_cost (XEXP (x, 1), code, 1, speed_p);
+ if (speed_p)
+ *cost += extra_cost-alu.arith;
+ return true;
+ }
return false;
}
@@ -9663,6 +9671,14 @@ arm_new_rtx_costs (rtx x, enum rtx_code code, enum rtx_code outer_code,
*cost += rtx_cost (XEXP (x, 0), PLUS, 0, speed_p);
return true;
}
+ else if (REG_P (XEXP (x, 1)))
+ {
+ *cost += rtx_cost (XEXP (x, 0), PLUS, 0, speed_p)
+ + rtx_cost (XEXP (x, 1), PLUS, 1, speed_p);
+ if (speed_p)
+ *cost += extra_cost-alu.arith;
+ return true;
+ }
return false;
}
Re: [C++ patch] for C++/52369
OK, thanks. Jason
Re: [PATCH] Fix PR c++/60573
On 03/18/2014 10:46 PM, Adam Butcher wrote: - while (scope-kind == sk_class - !TYPE_BEING_DEFINED (scope-this_entity)) Does it work to just change TYPE_BEING_DEFINED to currently_open_class? Jason
Re: [PATCH, PR 59176] Mark zombie call graph nodes to remove verifier false positive
Hi, On Fri, Mar 21, 2014 at 09:40:39PM +0100, Jan Hubicka wrote: On Thu, 20 Mar 2014, Martin Jambor wrote: Hi, On Thu, Mar 20, 2014 at 07:40:56PM +0100, Jakub Jelinek wrote: On Thu, Mar 20, 2014 at 05:07:32PM +0100, Martin Jambor wrote: in the PR, verifier claims an edge is pointing to a wrong declaration even though it has successfully verified the edge multiple times before. The reason is that symtab_remove_unreachable_nodes decides to remove the body of a node and also clear any information that it is an alias of another in the process (more detailed analysis in comment #9 of the bug). In bugzilla Honza wrote that silencing the verifier is the way to go. Either we can dedicate a new flag in each cgraph_node or symtab_node just for the purpose of verification or do something more hackish like the patch below which re-uses the former_clone_of field for this purpose. Since clones are always private nodes, they should always either survive removal of unreachable nodes or be completely killed by it and should never enter the in_border zombie state. Therefore their former_clone_of must always be NULL. So I added a new special value, error_mark_node, to mark this zombie state and taught the verifier to be happy with such nodes. Bootstrapped and tested on x86_64-linux. What do you think? Don't we have like 22 spare bits in cgraph_node and 20 spare bits in symtab_node? I'd find it clearer if you just used a new flag to mark the zombie nodes. Though, I'll let Richard or Honza to decide, don't feel strongly about it. I guess you are right, here is the proper version which is currently undergoing bootstrap and testing. I agree with Jakub, the following variant is ok. With the extra bit, you probably will need to LTO pickle it, too. Oops, that omission is a mistake. I'd like to blame it on quilt but it is more probable I simply forgot. I will commit the patch below as obvious after it passes a bootstrap. I would go with just clerning the thunk flag: this makes thunk to behave like external function that is safe to do. No, no thunks are involved here, it is an alias and the alias flag is cleared and was even before I fixed PR 60419. The problem is exactly that after symtab_remove_unreachable_nodes clears the flag (and the associated reference), the verifier sees just an ordinary symbol, now seemingly unrelated to the edge destination (or the node it is cloned from). (I am back in civilization from Alaska camping, will catch up with email early next week) Well, if camping in Alaska was not punishable by sever email backlog, life would not be fair at all. Thanks, Martin 2014-03-24 Martin Jambor mjam...@suse.cz PR ipa/59176 * lto-cgraph.c (lto_output_node): Stream body_removed flag. (lto_output_varpool_node): Likewise. (input_overwrite_node): Likewise. (input_varpool_node): Likewise. Hmm, that looks OK then. I guess eventually we will need to retire that cgraph verfier check, since it is harder and harder to keep track of all types of redirections we do... But it is useful one, so lets keep it alive for a bit longer. Honza
Re: [PATCH] BZ60501: Add addptr optab
I agree with Vlad that we're better off with Andreas' patch than without,
since
computing addresses is going to be 99% of what reload/LRA needs to do.
I also agree with Eric that some better commentary would be nice.
Ok. I've applied the following patch.
Bye,
-Andreas-
2014-03-24 Andreas Krebbel andreas.kreb...@de.ibm.com
PR rtl-optimization/60501
* optabs.def (addptr3_optab): New optab.
* optabs.c (gen_addptr3_insn, have_addptr3_insn): New function.
* doc/md.texi (addptrm3): Document new RTL standard expander.
* expr.h (gen_addptr3_insn, have_addptr3_insn): Add prototypes.
* lra.c (emit_add3_insn): Use the addptr pattern if available.
* config/s390/s390.md (addptrdi3, addptrsi3): New expanders.
diff --git a/gcc/config/s390/s390.md b/gcc/config/s390/s390.md
index 76902b5..7d9d1ad 100644
--- a/gcc/config/s390/s390.md
+++ b/gcc/config/s390/s390.md
@@ -5034,6 +5034,57 @@
[(set_attr op_type RRer,RXE)
(set_attr type fsimpmode)])
+;
+; Pointer add instruction patterns
+;
+
+; This will match *la_64
+(define_expand addptrdi3
+ [(set (match_operand:DI 0 register_operand )
+(plus:DI (match_operand:DI 1 register_operand )
+(match_operand:DI 2 nonmemory_operand )))]
+ TARGET_64BIT
+{
+ HOST_WIDE_INT c = INTVAL (operands[2]);
+
+ if (GET_CODE (operands[2]) == CONST_INT)
+{
+ if (!CONST_OK_FOR_CONSTRAINT_P (c, 'K', K)
+ !CONST_OK_FOR_CONSTRAINT_P (c, 'O', Os))
+{
+ operands[2] = force_const_mem (DImode, operands[2]);
+ operands[2] = force_reg (DImode, operands[2]);
+}
+ else if (!DISP_IN_RANGE (INTVAL (operands[2])))
+operands[2] = force_reg (DImode, operands[2]);
+}
+})
+
+; For 31 bit we have to prevent the generated pattern from matching
+; normal ADDs since la only does a 31 bit add. This is supposed to
+; match force_la_31.
+(define_expand addptrsi3
+ [(parallel
+[(set (match_operand:SI 0 register_operand )
+ (plus:SI (match_operand:SI 1 register_operand )
+ (match_operand:SI 2 nonmemory_operand )))
+ (use (const_int 0))])]
+ !TARGET_64BIT
+{
+ HOST_WIDE_INT c = INTVAL (operands[2]);
+
+ if (GET_CODE (operands[2]) == CONST_INT)
+{
+ if (!CONST_OK_FOR_CONSTRAINT_P (c, 'K', K)
+ !CONST_OK_FOR_CONSTRAINT_P (c, 'O', Os))
+{
+ operands[2] = force_const_mem (SImode, operands[2]);
+ operands[2] = force_reg (SImode, operands[2]);
+}
+ else if (!DISP_IN_RANGE (INTVAL (operands[2])))
+operands[2] = force_reg (SImode, operands[2]);
+}
+})
;;
;;- Subtract instructions.
diff --git a/gcc/doc/md.texi b/gcc/doc/md.texi
index 746acc2..85fd4b9 100644
--- a/gcc/doc/md.texi
+++ b/gcc/doc/md.texi
@@ -4720,6 +4720,17 @@ Add operand 2 and operand 1, storing the result in
operand 0. All operands
must have mode @var{m}. This can be used even on two-address machines, by
means of constraints requiring operands 1 and 0 to be the same location.
+@cindex @code{addptr@var{m}3} instruction pattern
+@item @samp{addptr@var{m}3}
+Like @code{add@var{m}3} but is guaranteed to only be used for address
+calculations. The expanded code is not allowed to clobber the
+condition code. It only needs to be defined if @code{add@var{m}3}
+sets the condition code. If adds used for address calculations and
+normal adds are not compatible it is required to expand a distinct
+pattern (e.g. using an unspec). The pattern is used by LRA to emit
+address calculations. @code{add@var{m}3} is used if
+@code{addptr@var{m}3} is not defined.
+
@cindex @code{ssadd@var{m}3} instruction pattern
@cindex @code{usadd@var{m}3} instruction pattern
@cindex @code{sub@var{m}3} instruction pattern
diff --git a/gcc/expr.h b/gcc/expr.h
index 5111f06..524da67 100644
--- a/gcc/expr.h
+++ b/gcc/expr.h
@@ -180,10 +180,12 @@ extern void emit_libcall_block (rtx, rtx, rtx, rtx);
Likewise for subtraction and for just copying. */
extern rtx gen_add2_insn (rtx, rtx);
extern rtx gen_add3_insn (rtx, rtx, rtx);
+extern rtx gen_addptr3_insn (rtx, rtx, rtx);
extern rtx gen_sub2_insn (rtx, rtx);
extern rtx gen_sub3_insn (rtx, rtx, rtx);
extern rtx gen_move_insn (rtx, rtx);
extern int have_add2_insn (rtx, rtx);
+extern int have_addptr3_insn (rtx, rtx, rtx);
extern int have_sub2_insn (rtx, rtx);
/* Emit a pair of rtl insns to compare two rtx's and to jump
diff --git a/gcc/lra.c b/gcc/lra.c
index 77074e2..c1b92d8 100644
--- a/gcc/lra.c
+++ b/gcc/lra.c
@@ -254,6 +254,19 @@ emit_add3_insn (rtx x, rtx y, rtx z)
rtx insn, last;
last = get_last_insn ();
+
+ if (have_addptr3_insn (x, y, z))
+{
+ insn = gen_addptr3_insn (x, y, z);
+
+ /* If the target provides an addptr pattern it hopefully does
+for a reason. So falling back to the normal add would be
+a bug. */
+ lra_assert (insn != NULL_RTX);
+ emit_insn (insn);
+ return insn;
Re: [Patch, AArch64] Fix shuffle for big-endian.
Further to that - all looks good after one-liner http://gcc.gnu.org/ml/gcc-patches/2014-03/msg01142.html has gone in. (Without that, enabling the code in Tejas' patch causes a regression in gcc.dg/torture/vshuf-v4hi.c as loading a vector constant goes wrong). I'll send a patch to enable this and fix up the testsuite shortly... Cheers, Alan Alan Lawrence wrote: I've been doing some local testing using this patch as a basis for some of my own work on NEON intrinsics, and it seems good to me. A couple of points: (1) Re. the comment that If two vectors, we end up with a wierd mixed-endian mode on NEON: firstly wierd should be spelt weird; secondly, if I understand right, this comment belongs with the next if (!d-one_vector_p...) rather than the if (BYTES_BIG_ENDIAN) before which it's written. (2) as you say, this code is not exercised, unless you do something to remove the 'if (BYTES_BIG_ENDIAN) return false;' earlier in that same function. Can I politely suggest you do that here in this patch? (3) In my own regression testing, with const_vec_perm enabled on big_endian, I see 2*PASS-FAIL, namely gcc.dg/vect/vect-114.c scan-tree-dump-times vect vectorized 0 loops 1 gcc.dg/vect/vect-114.c -flto -ffat-lto-objects scan-tree-dump-times vect vectorized 0 loops 1 These are essentially noise, but the noise is removed and I see no other problems, if (after this patch) I re-enable the testsuite's vect_perm target selector for aarch64 big-endian (testsuite/lib/target-supports.exp). Would you like a separate patch for that or roll it in here? Cheers, Alan Tejas Belagod wrote: Hi, When a shuffle of more than one input happens, on NEON we end up with a 'mixed-endian' format in the register list which TBL operates on. We don't make this correction in RTL and therefore the shuffle operation gets it incorrect. Here is a patch that fixes-up the index table in the selector rtx in RTL to also be mixed-endian to reflect what's happening on NEON. As trunk stands, this patch will not be exercised as constant vector permute for Big-endian is disabled. I've tested this by locally enabling const vec_perm and it fixes the some regressions we have on big-endian: aarch64_be-none-elf: FAIL-PASS: gcc.c-torture/execute/loop-11.c execution, -O3 -fomit-frame-pointer FAIL-PASS: gcc.c-torture/execute/loop-11.c execution, -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions FAIL-PASS: gcc.c-torture/execute/loop-11.c execution, -O3 -fomit-frame-pointer -funroll-loops FAIL-PASS: gcc.c-torture/execute/loop-11.c execution, -O3 -g FAIL-PASS: gcc.dg/torture/vector-shuffle1.c -O0 execution test FAIL-PASS: gcc.dg/torture/vshuf-v16qi.c -O2 execution test FAIL-PASS: gcc.dg/torture/vshuf-v2df.c -O2 execution test FAIL-PASS: gcc.dg/torture/vshuf-v2di.c -O2 execution test FAIL-PASS: gcc.dg/torture/vshuf-v2sf.c -O2 execution test FAIL-PASS: gcc.dg/torture/vshuf-v2si.c -O2 execution test FAIL-PASS: gcc.dg/torture/vshuf-v4sf.c -O2 execution test FAIL-PASS: gcc.dg/torture/vshuf-v4si.c -O2 execution test FAIL-PASS: gcc.dg/torture/vshuf-v8hi.c -O2 execution test FAIL-PASS: gcc.dg/torture/vshuf-v8qi.c -O2 execution test FAIL-PASS: gcc.dg/vect/vect-114.c -flto -ffat-lto-objects execution test FAIL-PASS: gcc.dg/vect/vect-114.c execution test FAIL-PASS: gcc.dg/vect/vect-15.c -flto -ffat-lto-objects execution test FAIL-PASS: gcc.dg/vect/vect-15.c execution test Also regressed on aarch64-none-elf. OK for stage-1? Thanks, Tejas. 2014-02-21 Tejas Belagod tejas.bela...@arm.com gcc/ * config/aarch64/aarch64.c (aarch64_evpc_tbl): Fix index vector for big-endian when dealing with more than one input shuffle vector.
Re: [C++ PATCH] Fix -std=c++11 OpenMP UDR handling (PR c++/60331)
On 03/18/2014 11:16 AM, Jakub Jelinek wrote: Jason, do you have better ideas how to fix this? Better would be to return false from potential_constant_expression_1 for DECL_EXPR; just add another case to the various _STMT tree codes. Jason
Re: [RFA jit] initialize input_location
On Mon, 2014-03-24 at 05:29 -0600, Tom Tromey wrote: Dave == David Malcolm dmalcolm-h+wxahxf7alqt0dzr+a...@public.gmane.org writes: Dave Given this declaration in input.c: Dave location_t input_location; Dave then assigning 0 is a faithful way of resetting it to its initial state. Dave That said, 0 feels like a magic number. Would it better to assign Dave UNKNOWN_LOCATION to it? which is 0, c.f. input.h: Dave #define UNKNOWN_LOCATION ((source_location) 0) Dave If so, perhaps the declaration in input.c should gain an initializer to Dave the same value? (shouldn't affect the code, since it's 0 either way, Dave but perhaps it's more readable?) Sounds reasonable to me. How about the appended? Tom commit 79ce51eaf41ce7b0e90407245b7cad33ada6887b Author: Tom Tromey tro...@redhat.com Date: Thu Mar 20 08:51:25 2014 -0600 initialize input_location This patch initializes input_location at the same spot where the line table is initialized. Without this, it's possible to crash when emitting a diagnostic in a reinvocation of the compiler, because input_location refers to a location that is no longer valid. diff --git a/gcc/ChangeLog.jit b/gcc/ChangeLog.jit index ee1df88..5145cf9 100644 --- a/gcc/ChangeLog.jit +++ b/gcc/ChangeLog.jit @@ -1,3 +1,8 @@ +2014-03-24 Tom Tromey tro...@redhat.com + + * toplev.c (general_init): Initialize input_location. + * input.c (input_location): Initialize to UNKNOWN_LOCATION. + 2014-03-19 Tom Tromey tro...@redhat.com * timevar.h (auto_timevar): New class. diff --git a/gcc/input.c b/gcc/input.c index a141a92..90a708c 100644 --- a/gcc/input.c +++ b/gcc/input.c @@ -1,5 +1,5 @@ /* Data and functions related to line maps and input files. - Copyright (C) 2004-2013 Free Software Foundation, Inc. + Copyright (C) 2004-2014 Free Software Foundation, Inc. This file is part of GCC. @@ -25,7 +25,7 @@ along with GCC; see the file COPYING3. If not see /* Current position in real source file. */ -location_t input_location; +location_t input_location = UNKNOWN_LOCATION; struct line_maps *line_table; diff --git a/gcc/toplev.c b/gcc/toplev.c index b257ab2..54a884e 100644 --- a/gcc/toplev.c +++ b/gcc/toplev.c @@ -1161,6 +1161,7 @@ general_init (const char *argv0) table. */ init_ggc (); init_stringpool (); + input_location = UNKNOWN_LOCATION; line_table = ggc_alloc_line_maps (); linemap_init (line_table); line_table-reallocator = realloc_for_line_map; Thanks. Feel free to push this to the dmalcolm/jit branch.
Re: [Patch, AArch64] Fix shuffle for big-endian.
On 02/21/2014 08:30 AM, Tejas Belagod wrote:
+ /* If two vectors, we end up with a wierd mixed-endian mode on NEON.
*/
+ if (BYTES_BIG_ENDIAN)
+ {
+ if (!d-one_vector_p d-perm[i] nunits)
+ {
+ /* Extract the offset. */
+ elt = d-perm[i] (nunits - 1);
+ /* Reverse the top half. */
+ elt = nunits - 1 - elt;
+ /* Offset it by the bottom half. */
+ elt += nunits;
+ }
+ else
+ elt = nunits - 1 - d-perm[i];
+ }
Isn't this just
elt = d-perm[i] ^ (nunits - 1);
all the time? I.e. invert the index within the word,
but leave the word index (nunits) unchanged.
r~
Re: [RFC] Remove PUSH_ARGS_REVERSED from the RTL expander.
On Mon, Mar 24, 2014 at 11:54:49AM +, Richard Biener wrote:
On Mon, Mar 24, 2014 at 12:44 PM, James Greenhalgh
james.greenha...@arm.com wrote:
Hi,
Consider this testcase:
extern void foo (int a, int b, int c, int d);
void
bar (int b, int c, int d)
{
foo (3, b, c, d);
}
For many ABI's we will have on entry to the function
r0 = b
r1 = c
r2 = d
If we process arguments to the call to foo left-to-right
(PUSH_ARGS_REVERSED == 0) we assign temporaries, and then hard registers
in this order:
t0 = 3
t1 = r0
t2 = r1
t3 = r2
r0 = t0
r1 = t1
r2 = t2
r3 = t3
We can't eliminate any of these temporaries as their live ranges overlap.
However, If we process the arguments right-to-left (PUSH_ARGS_REVERSED ==
1),
we get this order:
t0 = 3
t1 = r0
t2 = r1
t3 = r2
r3 = t3
r2 = t2
r1 = t1
r0 = t0
And then we can start eliminating temporaries we don't need and get:
r3 = r2
r2 = r1
r1 = r0
r0 = 3
Which is much neater.
It seems to me that this would probably be of benefit on all targets.
This would be an argument for setting PUSH_ARGS_REVERSED to 1 by default
for all targets. However, this would have a perceivable impact on argument
evaluation order (which is unspecified in C, but people have shown
sensitivity to it changing in the past and we suspect some people may
have built systems relying on the behviour... ho hum...).
However, now that all side effects are handled when we are in SSA
form, it should be possible to refactor calls.c and expr.c as if
PUSH_ARGS_REVERSED were always defined to 1, without changing the
argument evaluation order in gimplify.c.
In this way, we have the best of both worlds; we maintain argument
evaluation order and gain the optimizations given by removing
overlapping live ranges for parameters.
I've bootstrapped and regression tested this on x86, ARM and AArch64 - but
I am well aware these are fairly standard targets, do you have any
suggestions or comments on which targets this change will affect?
If not, is this OK for stage-1?
Maybe somebody remembers why we have both paths. I'd rather
make gimplification independent of this as well, choosing either
variant.
Do you have any hard numbers to compare? Say cc1 code size,
when comparing PUSH_ARGS_REVERSED 1 vs 0?
Sure, here is the output of size for AArch64 and ARM. Both of these targets
have PUSH_ARGS_REVERSED == 0. i386 results are not interesting (on the order
of tens of bytes), as PUSH_ARGS_REVERSED == 1 for that target.
trunk is revision 208685
patched is revision 208685 with this patch applied.
AArch64:
textdata bss dec hex filename
14546902 82424 781944 15411270 eb2846 trunk/gcc/cc1
14423510 82424 781944 15287878 e94646 patched/gcc/cc1
16721485 82480 805000 17608965 10cb105 trunk/gcc/cc1plus
16564613 82480 805000 17452093 10a4c3d patched/gcc/cc1plus
724550 7904 80744 813198c688etrunk/gcc/gfortran
722606 7904 80744 811254c60f6patched/gcc/gfortran
ARM:
textdata bss dec hex filename
15176835 31880 694132 15902847 f2a87f trunk/gcc/cc1
15171939 31880 694124 15897943 f29557 patched/gcc/cc1
17255818 31916 706404 17994138 112919a trunk/gcc/cc1plus
17250418 31916 706396 17988730 1127c7a patched/gcc/cc1plus
666307 4824 26780 697911aa637trunk/gcc/gfortran
664887 4824 26780 696491aa0abpatched/gcc/gfortran
AArch64 benefits more from the optimization, but there is also an
improvement for ARM.
Thanks,
James
---
gcc/
2014-03-21 James Greenhalgh james.greenha...@arm.com
* calls.c (initialize_argument_information): Always treat
PUSH_ARGS_REVERSED as 1, simplify code accordingly.
(expand_call): Likewise.
(emit_library_call_calue_1): Likewise.
* expr.c (PUSH_ARGS_REVERSED): Do not define.
(emit_push_insn): Always treat PUSH_ARGS_REVERSED as 1, simplify
code accordingly.
std::rethrow_exception is broken
There is a lot of code in libsupc++/eh_* that relies on
__cxa_exception and __cxa_dependent_exception having similar layouts,
so tricks like this work:
static inline void*
__gxx_caught_object(_Unwind_Exception* eo)
{
// Bad as it looks, this actually works for dependent exceptions too.
__cxa_exception* header = __get_exception_header_from_ue (eo);
return header-adjustedPtr;
}
The idea is that although the eo might be a pointer to the
unwindHeader member of either __cxa_exception or
__cxa_dependent_exception, the adjustedPtr member will be always be at
the same location relative to the unwindHeader member, so it Just
Works.
Except it doesn't.
offsetof(__cxa_exception, unwindHeader) == 80
offsetof(__cxa_dependent_exception, unwindHeader) == 80
offsetof(__cxa_exception, adjustedPtr) == 72
offsetof(__cxa_dependent_exception, adjustedPtr) == 64
This is the cause of PR 60612, and means we need to fix a lot of code
by explicitly checking the exception class (see attached patch for a
partial fix doing that in two places) or we need to change the layout
of __cxa_dependent_exception (and then add some tests to verify the
assumptions implicit in the code!)
I don't think this is all fixable in time for 4.9.0, but the attached
patch fixes one part of the problem, so I'm probably going to commit
it and then work on a more complete fix later.
commit 0e783c3897f1d1905bd64129e6eb9902a523626a
Author: Jonathan Wakely jwak...@redhat.com
Date: Mon Mar 24 12:30:20 2014 +
PR libstdc++/60612
* libsupc++/eh_call.cc (__cxa_call_terminate): Handle dependent
exceptions.
* libsupc++/eh_personality.cc (__cxa_call_unexpected): Likewise.
* libsupc++/unwind-cxx.h: Fix typos in comments.
* testsuite/18_support/exception_ptr/60612-terminate.cc: New.
* testsuite/18_support/exception_ptr/60612-unexpected.cc: New.
diff --git a/libstdc++-v3/libsupc++/eh_call.cc
b/libstdc++-v3/libsupc++/eh_call.cc
index 7677692..ac75813 100644
--- a/libstdc++-v3/libsupc++/eh_call.cc
+++ b/libstdc++-v3/libsupc++/eh_call.cc
@@ -48,10 +48,12 @@ __cxa_call_terminate(_Unwind_Exception* ue_header) throw ()
// exception. */
if (__is_gxx_exception_class(ue_header-exception_class))
{
- __cxa_exception* xh;
-
- xh = __get_exception_header_from_ue(ue_header);
- __terminate(xh-terminateHandler);
+ std::terminate_handler th;
+ if (__is_dependent_exception(ue_header-exception_class))
+ th = __get_dependent_exception_from_ue(ue_header)-terminateHandler;
+ else
+ th = __get_exception_header_from_ue(ue_header)-terminateHandler;
+ __terminate(th);
}
}
/* Call the global routine if we don't have anything better. */
diff --git a/libstdc++-v3/libsupc++/eh_personality.cc
b/libstdc++-v3/libsupc++/eh_personality.cc
index f315a83..698dc7d 100644
--- a/libstdc++-v3/libsupc++/eh_personality.cc
+++ b/libstdc++-v3/libsupc++/eh_personality.cc
@@ -737,20 +737,35 @@ __cxa_call_unexpected (void *exc_obj_in)
} end_catch_protect_obj;
lsda_header_info info;
- __cxa_exception *xh = __get_exception_header_from_ue (exc_obj);
const unsigned char *xh_lsda;
_Unwind_Sword xh_switch_value;
std::terminate_handler xh_terminate_handler;
-
+ std::unexpected_handler xh_unexpected_handler;
// If the unexpectedHandler rethrows the exception (e.g. to categorize it),
// it will clobber data about the current handler. So copy the data out now.
- xh_lsda = xh-languageSpecificData;
- xh_switch_value = xh-handlerSwitchValue;
- xh_terminate_handler = xh-terminateHandler;
- info.ttype_base = (_Unwind_Ptr) xh-catchTemp;
+ if (__is_dependent_exception(exc_obj-exception_class))
+{
+ __cxa_dependent_exception *xh = __get_dependent_exception_from_ue
(exc_obj);
+
+ xh_lsda = xh-languageSpecificData;
+ xh_switch_value = xh-handlerSwitchValue;
+ xh_terminate_handler = xh-terminateHandler;
+ xh_unexpected_handler = xh-unexpectedHandler;
+ info.ttype_base = (_Unwind_Ptr) xh-catchTemp;
+}
+ else
+{
+ __cxa_exception *xh = __get_exception_header_from_ue (exc_obj);
+
+ xh_lsda = xh-languageSpecificData;
+ xh_switch_value = xh-handlerSwitchValue;
+ xh_terminate_handler = xh-terminateHandler;
+ xh_unexpected_handler = xh-unexpectedHandler;
+ info.ttype_base = (_Unwind_Ptr) xh-catchTemp;
+}
__try
-{ __unexpected (xh-unexpectedHandler); }
+{ __unexpected (xh_unexpected_handler); }
__catch(...)
{
// Get the exception thrown from unexpected.
diff --git a/libstdc++-v3/libsupc++/unwind-cxx.h
b/libstdc++-v3/libsupc++/unwind-cxx.h
index a7df603..1ca6d94 100644
--- a/libstdc++-v3/libsupc++/unwind-cxx.h
+++ b/libstdc++-v3/libsupc++/unwind-cxx.h
@@ -81,7 +81,7 @@ struct __cxa_exception
// Stack of exceptions in cleanups.
__cxa_exception* nextPropagatingException;
- // The nuber of active cleanup handlers
Re: [PATCH] Update libstdc++ baseline_symbols.txt for {i?86,x86_64,s390,s390x,ppc,ppc64}-linux
On 24/03/14 20:20 +0100, Jakub Jelinek wrote: Hi! This patch updates baseline_symbols.txt to what I've grabbed from trunk builds as of today on various targets. Verified the additions are the same (just sizes of some objects double from 32-bit to 64-bit targets). In addition to that, it removes the TLS lines that are intentionally filtered away from all the other baseline_symbols.txt (the point is to not get abi_check errors if somebody configures without tls). Ok for trunk? Yes, thanks.
Re: [PATCH] Fix PR c++/60573
On 2014-03-24 17:23, Jason Merrill wrote: On 03/18/2014 10:46 PM, Adam Butcher wrote: - while (scope-kind == sk_class - !TYPE_BEING_DEFINED (scope-this_entity)) Does it work to just change TYPE_BEING_DEFINED to currently_open_class? No. The object referred to by 'scope-this_entity' is the same for each of the two levels, so unless there's something else I can pass to 'currently_open_class', the result will be equivalent; the issue is that the class being referred to *is* being defined, but I need to skip over the second class-scope for that type to arrive at the defining scope level. Adam
Re: [RFC] Remove PUSH_ARGS_REVERSED from the RTL expander.
On 03/24/2014 06:23 AM, Michael Matz wrote: I can't say why we have the !PUSH_ARGS_REVERSED path (so I guess that's the way that initially was there, before the distinction was made), but the PUSH_ARGS_REVERSED==1 path is important when you have push instructions and arguments grow in the opposite direction of the stack. The latter is the case for almost all targets, so as soon as you have push instructions (and no ACCUMULATE_OUTGOING_ARGS) you'll want to have PUSH_ARGS_REVERSED==1 as well. I guess the !PUSH_ARGS_REVERSED path only has advantages for the few targets where stack and args grow the same way and that use push instructions for argument passing, which currently are none. pa-64 does have same-direction arguments and stack (both upward), but doesn't use push, and the only other ARGS_GROW_DOWNWARD (pa-32bit and stormy16) also have !STACK_GROWS_DOWNWARD, so again opposite direction. See http://en.wikipedia.org/wiki/X86_calling_conventions#pascal Since we don't actually support this anymore, we can certainly tidy this up. r~
Re: C++ PATCHes to run testsuite in C++14 mode
2014-03-07 22:43 GMT+01:00 Jason Merrill ja...@redhat.com:
The first patch changes the C++ testsuite to run in C++14 mode as well as
C++98 and C++11.
As a result, specifying { target c++11 } matches c++11 and c++1y mode.
{ target c++1y } matches c++1y only, and { target c++98 } matches c++98 only.
Is that correct ?
I have noticed that a lot of testcases have been changed so that {
target c++98 } is now written as { target { ! c++11 } }.
Why was it needed ?
The second patch splits up the running of dg.exp to avoid it running longer
than libstdc++ in parallel testing.
Incidentally, how does it affect testing time ?
--
Fabien
Build *PING* Re: [Build, Driver] Add -lcilkrts for -fcilkplus
*PING* for the build part as the driver part has been already approved. http://gcc.gnu.org/ml/gcc-patches/2014-03/msg00492.html Also pinging another one-line libcilkrts/Makefile.am patch: http://gcc.gnu.org/ml/gcc-patches/2014-03/msg0.html On March 11, 2014, Tobias Burnus wrote: When using Cilk Plus (-fcilkplus), it makes sense to automatically link the run-time library (-lcilkrts). This patch mimics libgomp by adding a .spec file; I am not 100% sure whether the .spec file is needed, but the pthread tests in libgomp imply that it makes sense. (libgomp also checks for -lrt for the high-performance timers, a check which is not required for libcilkrts.) Bootstrapped on x86-64-gnu-linux. OK for the trunk? Tobias
[PATCH] Fix PR c++/60626
PR c++/60626
* parser.c (cp_parser_init_declarator): Handle erroneous generic type
usage in non-functions with pushed scope.
PR c++/60626
* g++.dg/cpp1y/pr60626.C: New testcase.
---
gcc/cp/parser.c | 9 -
gcc/testsuite/g++.dg/cpp1y/pr60626.C | 7 +++
2 files changed, 15 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/g++.dg/cpp1y/pr60626.C
diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index efb7b39..49fb731 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -16823,7 +16823,14 @@ cp_parser_init_declarator (cp_parser* parser,
been issued. */
if (parser-fully_implicit_function_template_p)
if (!function_declarator_p (declarator))
- finish_fully_implicit_template (parser, /*member_decl_opt=*/0);
+ {
+ if (pushed_scope)
+ {
+ pop_scope (pushed_scope);
+ pushed_scope = 0;
+ }
+ finish_fully_implicit_template (parser, /*member_decl_opt=*/0);
+ }
/* For an in-class declaration, use `grokfield' to create the
declaration. */
diff --git a/gcc/testsuite/g++.dg/cpp1y/pr60626.C
b/gcc/testsuite/g++.dg/cpp1y/pr60626.C
new file mode 100644
index 000..39ea438
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1y/pr60626.C
@@ -0,0 +1,7 @@
+// PR c++/60626
+// { dg-do compile { target c++1y } }
+// { dg-options }
+
+struct A {};
+
+void (*A::p)(auto) = 0; // { dg-error static member|non-template }
--
1.9.0
[Patch, Fortran] PR60576 Fix out-of-bounds problem
This patch fixes part of the problems of the PR. The problem is that one
assigns an array descriptor to an assumed-rank array descriptor. The
latter has for BT_CLASS the size of max_dim (reason: we have first the
data array and than vtab). With true, one takes the TREE_TYPE from
the LHS (i.e. the assumed-rank variable) and as the type determines how
many bytes the range assignment copies, one reads max_dimension elements
from the RHS array - which can be too much.
Testcase: Already in the testsuite, even if it only fails under special
conditions.
Build and regtested on x86-64-gnu-linux.
OK for the trunk and 4.8?
Tobias
PS: I haven't investigated the issues Jakub is seeing. With valgrind,
they do not pop up and my attempt to build with all checking enabled,
failed with configure or compile errors.
2014-03-25 Mikael Morin mik...@gcc.gnu.org
Tobias Burnus bur...@net-b.de
PR fortran/
* trans-expr.c (gfc_conv_derived_to_class): Avoid
generation of out-of-bounds range expr.
diff --git a/gcc/fortran/trans-expr.c b/gcc/fortran/trans-expr.c
index f5350bb..30931a3 100644
--- a/gcc/fortran/trans-expr.c
+++ b/gcc/fortran/trans-expr.c
@@ -424,7 +426,11 @@ gfc_conv_derived_to_class (gfc_se *parmse, gfc_expr *e,
gfc_conv_expr_descriptor (parmse, e);
if (e-rank != class_ts.u.derived-components-as-rank)
- class_array_data_assign (block, ctree, parmse-expr, true);
+ {
+ gcc_assert (class_ts.u.derived-components-as-type
+ == AS_ASSUMED_RANK);
+ class_array_data_assign (block, ctree, parmse-expr, false);
+ }
else
{
if (gfc_expr_attr (e).codimension)
[Patch, Fortran] PR58880 - Fix ICE with finalizers
Hi all,
this patch fixes a problem with the conversion of scalars to
descriptors. There one assigns the address of the scalar to the
base_address field of the descriptor. The ICE occurred when the RHS (the
scalar) wasn't a pointer.
It does not fully solve the PR as for some reasons the finalization
wrapper is not generated - which causes link errors or ICEs (see PR).
Build and regtested on x86-64-gnu-linux.
OK for the (4.9) trunk?
Tobias
2014-03-25 Tobias Burnus bur...@net-b.de
PR fortran/58880
* trans-expr.c (gfc_conv_scalar_to_descriptor): Fix handling
of nonpointers.
2014-03-25 Tobias Burnus bur...@net-b.de
PR fortran/58880
* gfortran.dg/finalize_24.f90: New.
diff --git a/gcc/fortran/trans-expr.c b/gcc/fortran/trans-expr.c
index f5350bb..30931a3 100644
--- a/gcc/fortran/trans-expr.c
+++ b/gcc/fortran/trans-expr.c
@@ -69,14 +69,16 @@ gfc_conv_scalar_to_descriptor (gfc_se *se, tree scalar, symbol_attribute attr)
type = get_scalar_to_descriptor_type (scalar, attr);
desc = gfc_create_var (type, desc);
DECL_ARTIFICIAL (desc) = 1;
+
+ if (!POINTER_TYPE_P (TREE_TYPE (scalar)))
+scalar = gfc_build_addr_expr (NULL_TREE, scalar);
gfc_add_modify (se-pre, gfc_conv_descriptor_dtype (desc),
gfc_get_dtype (type));
gfc_conv_descriptor_data_set (se-pre, desc, scalar);
/* Copy pointer address back - but only if it could have changed and
if the actual argument is a pointer and not, e.g., NULL(). */
- if ((attr.pointer || attr.allocatable)
-attr.intent != INTENT_IN POINTER_TYPE_P (TREE_TYPE (scalar)))
+ if ((attr.pointer || attr.allocatable) attr.intent != INTENT_IN)
gfc_add_modify (se-post, scalar,
fold_convert (TREE_TYPE (scalar),
gfc_conv_descriptor_data_get (desc)));
diff --git a/gcc/testsuite/gfortran.dg/finalize_24.f90 b/gcc/testsuite/gfortran.dg/finalize_24.f90
new file mode 100644
index 000..2a21858
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/finalize_24.f90
@@ -0,0 +1,28 @@
+! { dg-do compile }
+!
+! PR fortran/58880
+!
+! Contributed by Andrew Benson
+!
+
+module gn
+ type sl
+ integer, allocatable, dimension(:) :: lv
+ contains
+ final :: sld
+ end type sl
+ type :: nde
+ type(sl) :: r
+ end type nde
+contains
+ subroutine ndm(s)
+type(nde), intent(inout) :: s
+type(nde):: i
+i=s
+ end subroutine ndm
+ subroutine sld(s)
+implicit none
+type(sl), intent(inout) :: s
+return
+ end subroutine sld
+end module gn
Re: [PATCH] Fix PR59626, _FORTIFY_SOURCE wrappers and LTO
Currently a _lot_ of packages fail to build with LTO because LTO messes up fortify wrappers by replacing the call to the alias with the symbol itself, making the wrapper look like infinitely recursing. The following patch fixes this by dropping the bodies of DECL_EXTERN always-inline functions on the floor before IPA (and when doing LTO). IMHO we should at some point do this unconditional on LTO as the early inliner is supposed to remove all references to always-inline functions. I'm not 100% sure about the cgraph API use to drop the function body, but at least it seems to work ;) I'm not sure if we want to restrict the set of functions to apply this even more than just those with always-inline and DECL_EXTERNAL set? Now double-checking with a fortified LTO bootstrap. Ok for trunk? Thanks, Richard. 2014-03-24 Richard Biener rguent...@suse.de PR lto/59626 * passes.c (ipa_write_summaries): Drop function bodies of extern always-inline functions. * gcc.dg/lto/pr59626_0.c: New testcase. * gcc.dg/lto/pr59626_1.c: Likewise. Hi, do you see some problem with this approach? Unlike in dropping for ipa_write_summaries it drops just after early optimizations and it is done unconditonally. I see it kills every cross module inlining of extern inlines, but so does your patch. This may make difference for C++ implicit extern inlines (keyed functions) where I can imagine users both to declare them always inline and then call indirectly... I do it unconditionally because I do not like much of idea of making the LTO and non-LTO pipelines diverging even more. Honza Index: ipa.c === --- ipa.c (revision 208798) +++ ipa.c (working copy) @@ -139,7 +139,10 @@ process_references (struct ipa_ref_list if (node-definition !node-in_other_partition ((!DECL_EXTERNAL (node-decl) || node-alias) - || (before_inlining_p + || (((before_inlining_p +(cgraph_state CGRAPH_STATE_IPA_SSA + || !lookup_attribute (always_inline, + DECL_ATTRIBUTES (node-decl) /* We use variable constructors during late complation for constant folding. Keep references alive so partitioning knows about potential references. */ @@ -191,7 +194,10 @@ walk_polymorphic_call_targets (pointer_s /* Prior inlining, keep alive bodies of possible targets for devirtualization. */ if (n-definition - before_inlining_p) + (before_inlining_p + (cgraph_state CGRAPH_STATE_IPA_SSA + || !lookup_attribute (always_inline, +DECL_ATTRIBUTES (n-decl) pointer_set_insert (reachable, n); /* Even after inlining we want to keep the possible targets in the
Re: C++ PATCHes to run testsuite in C++14 mode
On 03/24/2014 05:06 PM, Fabien Chêne wrote:
2014-03-07 22:43 GMT+01:00 Jason Merrill ja...@redhat.com:
The first patch changes the C++ testsuite to run in C++14 mode as well as
C++98 and C++11.
As a result, specifying { target c++11 } matches c++11 and c++1y mode.
{ target c++1y } matches c++1y only, and { target c++98 } matches c++98 only.
Is that correct ?
Everything is intended to mean C++XX and up now. But c++98 isn't
defined, since it would be meaningless. And so it isn't used in tests
either. So for c++98 only you can use c++98_only or { ! c++11 }.
The second patch splits up the running of dg.exp to avoid it running longer
than libstdc++ in parallel testing.
Incidentally, how does it affect testing time ?
On a highly parallel system, it doesn't affect testing time because one
of the chunks of libstdc++ tests still takes longer than any of the
chunks of g++ tests.
Jason
Re: [PATCH][AARCH64]PR60034
If I understand gcc/rtl.h correctly, SYMBOL_REF_ANCHOR_P (sym) is
required for anchor SYMBOL_REFS. SYMBOL_REF_BLOCK (sym) != NULL is
probably redundant. This can probably become an gcc_assert
(SYMBOL_REF_BLOCK (sym)) instead.
I agree with your interpretation of the code and comments in rtl.h. I
also accept that SYMBOL_REF_ANCHOR_P() is sufficient to resolve the
test case. However I'm wondering why we need to constraint the test
down to SYMBOL_REF_ANCHOR_P(). At this point in the code we are
trying to find alignment of the object, if we have a SYMBOL_REF_BLOCK
then we can get the block alignment irrespective of
SYMBOL_REF_ANCHOR_P().
Thanks for the explanation. Is the attached patch looks OK ?
Thanks,
Kugan
gcc/
2014-03-25 Kugan Vivekanandarajah kug...@linaro.org
PR target/60034
* aarch64/aarch64.c (aarch64_classify_address): Fix alignment for
section anchor.
gcc/testsuite/
2014-03-25 Kugan Vivekanandarajah kug...@linaro.org
PR target/60034
* gcc.target/aarch64/pr60034.c: New file.
diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index 57b6645..7d2d10c 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -3193,6 +3193,9 @@ aarch64_classify_address (struct aarch64_address_info
*info,
}
else if (SYMBOL_REF_DECL (sym))
align = DECL_ALIGN (SYMBOL_REF_DECL (sym));
+ else if (SYMBOL_REF_HAS_BLOCK_INFO_P (sym)
+ SYMBOL_REF_BLOCK (sym) != NULL)
+ align = SYMBOL_REF_BLOCK (sym)-alignment;
else
align = BITS_PER_UNIT;
diff --git a/gcc/testsuite/gcc.target/aarch64/pr60034.c
b/gcc/testsuite/gcc.target/aarch64/pr60034.c
index e69de29..ab7e7f4 100644
--- a/gcc/testsuite/gcc.target/aarch64/pr60034.c
+++ b/gcc/testsuite/gcc.target/aarch64/pr60034.c
@@ -0,0 +1,10 @@
+/* { dg-do compile } */
+/* { dg-options -std=gnu99 -O } */
+
+static unsigned long global_max_fast;
+
+void __libc_mallopt (int param_number, int value)
+{
+ __asm__ __volatile__ (# %[_SDT_A21] :: [_SDT_A21] nor
((global_max_fast)));
+ global_max_fast = 1;
+}
