[PATCH] rs6000: Fix TARGET_PROMOTE_FUNCTION_MODE
As the existing comment explains, we should always promote function
arguments and return values. However, notwithstanding its name,
default_promote_function_mode_always_promote does not always promote.
Importantly, it does not for libcalls. This makes ftrapv-[12].c fail
with 64-bit ABIs.
This patch introduces an rs6000_promote_function_mode that _does_
always promote, fixing this.
Tested as usual (c,c++,fortran,ada; -m32,-m32/-mpowerpc64,-m64,-m64/-mlra).
Is this okay for mainline?
Segher
2015-01-08 Segher Boessenkool seg...@kernel.crashing.org
gcc/
* config/rs6000/rs6000.c (TARGET_PROMOTE_FUNCTION_MODE): Implement
as rs6000_promote_function_mode. Move comment to there.
(rs6000_promote_function_mode): New function.
---
gcc/config/rs6000/rs6000.c | 17 ++---
1 file changed, 14 insertions(+), 3 deletions(-)
index e2bfcd6..66a1399 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -1498,10 +1498,8 @@ static const struct attribute_spec
rs6000_attribute_table[] =
#undef TARGET_MEMBER_TYPE_FORCES_BLK
#define TARGET_MEMBER_TYPE_FORCES_BLK rs6000_member_type_forces_blk
-/* On rs6000, function arguments are promoted, as are function return
- values. */
#undef TARGET_PROMOTE_FUNCTION_MODE
-#define TARGET_PROMOTE_FUNCTION_MODE
default_promote_function_mode_always_promote
+#define TARGET_PROMOTE_FUNCTION_MODE rs6000_promote_function_mode
#undef TARGET_RETURN_IN_MEMORY
#define TARGET_RETURN_IN_MEMORY rs6000_return_in_memory
@@ -9295,6 +9293,19 @@ init_cumulative_args (CUMULATIVE_ARGS *cum, tree fntype,
}
}
+/* On rs6000, function arguments are promoted, as are function return
+ values. */
+static machine_mode
+rs6000_promote_function_mode (const_tree, machine_mode mode, int *,
+ const_tree, int)
+{
+ if (GET_MODE_CLASS (mode) == MODE_INT
+ GET_MODE_SIZE (mode) GET_MODE_SIZE (Pmode))
+return Pmode;
+
+ return mode;
+}
+
/* Return true if TYPE must be passed on the stack and not in registers. */
static bool
--
1.8.1.4
Re: [Patch docs 2/5] Update Instruction Patterns in md.texi
On Thu, Jan 08, 2015 at 03:00:02PM -0700, Jeff Law wrote:
On 01/06/15 04:21, James Greenhalgh wrote:
-A @code{define_insn} is an RTL expression containing four or five
operands:
+A @code{define_insn} contains either four or five components:
How about
A @code{define_insn} contains the following components:
@enumerate
@item
-An optional name. The presence of a name indicate that this instruction
-pattern can perform a certain standard job for the RTL-generation
-pass of the compiler. This pass knows certain names and will use
-the instruction patterns with those names, if the names are defined
-in the machine description.
-
-The absence of a name is indicated by writing an empty string
-where the name should go. Nameless instruction patterns are never
-used for generating RTL code, but they may permit several simpler insns
-to be combined later on.
-
-Names that are not thus known and used in RTL-generation have no
-effect; they are equivalent to no name at all.
+The @dfn{insn name}: When expanding from gimple to RTL, and when
performing
+optimizations, the compiler looks for patterns with certain names,
IIRC reload looks for specific named patterns as well. There may be
other places that look for standard named patterns.
Which makes me wonder how hard we should try to nail this down. Maybe
something along the lines of passes which generate new insns may look
for standard names.
This whole business with standard names isn't specific to define_insn
(also define_insn_and_split and define_expand), so perhaps it should
be moved elsewhere?
Patterns with names that start with a '*' behave like nameless patterns
as well (except where the name is printed, like in dump files). This
should be mentioned in the same place too I think (it currently is
mentioned _somewhere_ I think, but I cannot find it, hrm).
Segher
Re: [Ada] Fix bootstrapping on darwin9/10 (PR ada/64349).
On 8 Jan 2015, at 13:52, Tristan Gingold wrote: On 08 Jan 2015, at 13:49, Iain Sandoe i...@codesourcery.com wrote: Hi Tristan, On 7 Jan 2015, at 10:15, Arnaud Charlet wrote: Use _NSGetEnviron to get environment. Tested on x86_64-pc-linux-gnu, committed on trunk 2015-01-07 Tristan Gingold ging...@adacore.com PR ada/64349 * env.c (__gnat_environ): Adjust for darwin9/darwin10. difs.txt So my original patch assumed that, while it was not legal to use environ from a shlib, it is legal to use _NSGetEnviron () from an application ... .. and, OK fine, I see the point about ! defined (__arm__) .. but a few other comments. ISTM that there's a partial implementation to distinguish between IN_RTS and application? Yes you're right. The added code should have been added after the #endif for IN_RTS. How about this? It uses the interface where needed, avoids it for main exes and gets rid of the negative conditional (which IMO makes the code a little more readable). Iain P.S. this is not Darwin9/10 - specific the only reason it doesn't fail on Darwin = 11 is because they default to -undefined dynamic_lookup .. and so find the symbol from the exe. ada: PR ada/64349 * env.c (__gnat_environ): Adjust environ access for Darwin. Index: gcc/ada/env.c === --- gcc/ada/env.c (revision 219325) +++ gcc/ada/env.c (working copy) @@ -215,12 +215,12 @@ #elif defined (sun) extern char **_environ; return _environ; -#elif ! (defined (__vxworks)) - extern char **environ; +#elif defined (IN_RTS) defined (__APPLE__) !defined (__arm__) + return *_NSGetEnviron (); +#elif defined (__vxworks) return environ; -#elif defined (__APPLE__) !defined (__arm__) - return *_NSGetEnviron (); #else + extern char **environ; return environ; #endif }
Re: [Patch docs 1/5] Update the first section of md.texi
On Thu, Jan 08, 2015 at 02:43:27PM -0700, Jeff Law wrote:
A section that describes the lexical structure and syntax of .md files?
Seems reasonable. However, is that too heavyweight?
ISTM we have, effectively 3 items.
Directives that start with an open-paren and end with their associated
close paren. ANything in between those parens is governed by the
documentation for the specific directive.
Outside a directive we can lines with are empty or contain just
whitespace. These lines are effectively ignored.
Also outside a directive are lines that start with ';;'. From the ';;'
to the end of line are comments and ignored.
Empty lines are whitespace. Comments are whitespace (two kinds of
comments: ;commentEOL/EOF (single semi-colon!), as well as C-style
/*comments*/).
At the top level, you have optional whitespace '(' opt ws name
whatever that kind of thing wants opt ws ')'; repeat; opt ws.
whatever is constrained by just a few things: anything starting with
'' is parsed as a string (i.e. until a non-quoted second ''); everything
starting with '{' is parsed as a C block (i.e. until a matching '}'),
and outside of those the parens have to match.
Oh, and name can contain much more than just alphanumerics, but we
really shouldn't document that ;-)
Segher
[PATCH] testsuite/lib/target-supports.exp: Fix check_effective_target_lto
Hi!
Currently check_effective_target_lto properly works only in gcc/testsuite/ dir,
since it checks for ENABLE_LTO, which is defined in gcc/configure.ac.
But it doesn't work in other subdirectories, e.g. in libgomp/testsuite/.
This patch fixes it.
make check and check-target-libgomp passed with/without --disable-lto on
x86_64-linux. OK for trunk?
gcc/testsuite/
* lib/target-supports.exp (check_effective_target_lto): Check for -flto
option support instead of ENABLE_LTO define from configure.
diff --git a/gcc/testsuite/lib/target-supports.exp
b/gcc/testsuite/lib/target-supports.exp
index 119d2c5..4140505 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -5729,11 +5729,12 @@ proc check_effective_target_gld { } {
# (LTO) support.
proc check_effective_target_lto { } {
-global ENABLE_LTO
if { [istarget nvptx-*-*] } {
return 0;
}
-return [info exists ENABLE_LTO]
+return [check_no_compiler_messages lto object {
+ void foo (void) { }
+} -flto]
}
# Return 1 if -mx32 -maddress-mode=short can compile, 0 otherwise.
-- Ilya
Re: [doc] fix documentation of -fvtable-verify and related options
On 01/08/15 15:08, Sandra Loosemore wrote: This patch cleans up the documentation of -fvtable-verify, -fvtv-debug, and -fvtv-counts. The substantive change is to correct the location of the debug log files per discussion here: https://gcc.gnu.org/ml/gcc/2015-01/msg00029.html but I ended up doing a pretty much total rewrite of the text to fix various markup problems, issues with agreement of verb tense and plurals, usage of terms like runtime, etc. I think this particular patch goes a little beyond an obvious fix, so I have not committed it yet. But, I don't want it to get lost in the shuffle, so I propose to do so in a few days if I don't hear any objection or request for more time to review it meanwhile. -Sandra 2015-01-08 Sandra Loosemore san...@codesourcery.com gcc/ * doc/invoke.texi ([-fvtable-verify]): Copy-edit and fix markup. ([-fvtv-debug], [-fvtv-counts]): Likewise. Correct location of log files. This is fine. I did note that in some places you use run time and others run-time. Not sure if you want those to be consistent or not. Ok for the trunk. If you want to make run time vs run-time consistent one way or the other consider it preapproved. CHeers, Jeff
Re: [PATCH] libobjc: Properly handle classes without instance variables in class_copyIvarList ().
On Wed, Dec 24, 2014 at 9:28 AM, Dimitris Papavasiliou dpapa...@gmail.com wrote: Hello, The attached patch fixes an issue reported a couple of years ago in Bug 51891 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51891). The problem is caused because classes without instance variables have no ivar list at all, so that their ivars pointer is NULL, but the code in class_copyIvarList () is unaware of this. That this is in fact so can be easily verified by checking the code of class_addIvar in the same source file, where the ivars list is allocated when the first ivar is added. The code there also checks for a NULL ivars pointer. The patch also adds a simple test-case for this issue. I think that the ChangeLog entry should be something along the lines of: 2014-12-24 Dimitris Papavasiliou dpapa...@gmail.com PR libobjc/51891 * libobjc/ivars.c: Add a check for classes without instance variables, which have a NULL ivar list pointer. * gcc/testsuite/objc.dg/gnu-api-2-class.m: Add a test case for the above change. I hope I got the formatting right. I've run make -k check-objc and all tests pass without problems. Let me know if there are any problems, or if I can do anything else to facilitate the acceptance of the patch. This is ok. Thanks, Andrew Regards, Dimitris
[PATCH] rs6000: Fix recip tests for -m32 -mpowerpc64
This fixes gcc.target/powerpc/recip-[67].c with -m32 -mpowerpc64. Tested etc.; okay for mainline? Segher 2015-01-08 Segher Boessenkool seg...@kernel.crashing.org gcc/testsuite/ * gcc.target/powerpc/recip-test.h (_ARCH_PPC64): Use __LP64__ instead. --- gcc/testsuite/gcc.target/powerpc/recip-test.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gcc/testsuite/gcc.target/powerpc/recip-test.h b/gcc/testsuite/gcc.target/powerpc/recip-test.h index 7a42df5..0c60671 100644 --- a/gcc/testsuite/gcc.target/powerpc/recip-test.h +++ b/gcc/testsuite/gcc.target/powerpc/recip-test.h @@ -1,6 +1,6 @@ /* Check reciprocal estimate functions for accuracy. */ -#ifdef _ARCH_PPC64 +#ifdef __LP64__ typedef unsigned long uns64_t; #define UNUM64(x) x ## L -- 1.8.1.4
RE: [Patch, ARM/Thumb1]Add a Thumb1 insn pattern to legalize the instruction that moves pc to low register
-Original Message-
From: Richard Earnshaw
Sent: Monday, December 08, 2014 7:31 PM
To: Terry Guo; gcc-patches@gcc.gnu.org
Cc: Ramana Radhakrishnan
Subject: Re: [Patch, ARM/Thumb1]Add a Thumb1 insn pattern to legalize the
instruction that moves pc to low register
On 08/12/14 08:24, Terry Guo wrote:
Hi there,
When compile below simple code:
terguo01@terry-pc01:mtpcs-frame$ cat test.c int main(void) {
return 0;
}
I got ICE with option -mtpcs-leaf-frame (no error if remove this
option).
terguo01@terry-pc01:mtpcs-frame$
/work/terguo01/tools/gcc-arm-none-eabi-5_0-2014q4/bin/arm-none-eabi-
gc
c -mtpcs-leaf-frame test.c -c -mcpu=cortex-m0plus -mthumb -da
test.c: In function 'main':
test.c:4:1: error: unrecognizable insn:
}
^
(insn 20 19 21 (set (reg:SI 2 r2)
(reg:SI 15 pc)) test.c:2 -1
(nil))
test.c:4:1: internal compiler error: in extract_insn, at recog.c:2327
Please submit a full bug report, with preprocessed source if
appropriate.
See http://gcc.gnu.org/bugs.html\ for instructions.
This RTL is generated in function thumb1_expand_prologue. The expected
insn pattern is thumb1_movsi_insn in thumb1.md. And instruction like
mov r2, pc
is a legal instruction. Because gcc returns NO_REG for PC register, so
no valid pattern to match instruction that move pc to low register.
This patch intends to add a new insn pattern to legalize such thing.
Tested with GCC regression test. No regression. Is it OK to trunk?
BR,
Terry
2014-12-08 Terry Guo terry@arm.com
* config/arm/predicates.md (pc_register): New to match PC register.
* config/arm/thumb1.md (*thumb1_movpc_insn): New insn pattern.
gcc/testsuite/ChangeLog:
2014-12-08 Terry Guo terry@arm.com
* gcc.target/arm/thumb1-mov-pc.c: New test.
thumb1-move-pc-v1.txt
diff --git a/gcc/config/arm/predicates.md
b/gcc/config/arm/predicates.md index 032808c..c5ef5ed 100644
--- a/gcc/config/arm/predicates.md
+++ b/gcc/config/arm/predicates.md
@@ -361,6 +361,10 @@
(and (match_code smin,smax,umin,umax)
(match_test mode == GET_MODE (op
+(define_special_predicate pc_register
+ (and (match_code reg)
+ (match_test REGNO (op) == PC_REGNUM)))
+
(define_special_predicate cc_register
(and (match_code reg)
(and (match_test REGNO (op) == CC_REGNUM) diff --git
a/gcc/config/arm/thumb1.md b/gcc/config/arm/thumb1.md index
ddedc39..8e6057c 100644
--- a/gcc/config/arm/thumb1.md
+++ b/gcc/config/arm/thumb1.md
@@ -1780,6 +1780,16 @@
)
+(define_insn *thumb1_movpc_insn
+ [(set (match_operand:SI 0 low_register_operand)
This needs constraints.
The constraint is used now. Is this one OK?
BR,
Terry
2015-01-09 Terry Guo terry@arm.com
* config/arm/thumb1.md (*thumb1_movpc_insn): New insn pattern.diff --git a/gcc/config/arm/thumb1.md b/gcc/config/arm/thumb1.md
index 2208ae6..e04 100644
--- a/gcc/config/arm/thumb1.md
+++ b/gcc/config/arm/thumb1.md
@@ -1753,6 +1753,16 @@
)
+(define_insn *thumb1_movpc_insn
+ [(set (match_operand:SI 0 s_register_operand =l)
+ (reg:SI PC_REGNUM))]
+ TARGET_THUMB1
+ mov\\t%0, pc
+ [(set_attr length 2)
+ (set_attr conds nocond)
+ (set_attr type mov_reg)]
+)
+
;; NB never uses BX.
(define_insn *thumb1_tablejump
[(set (pc) (match_operand:SI 0 register_operand l*r))
Re: [PING] Add refers_to_regno_p overload to simplify callers
On 01/05/15 15:06, Oleg Endo wrote: Though I think further patches of this nature should probably wait until stage1 reopens. Also for non-functional stuff like changing more return values / args from int to bool where it's obvious? Yea, we're supposed to be locking things down in preparation for a release. While I like cleaning up this kind of thing, the priority for the project is the upcoming release. Others may have differing opinions here. So I'm not going to object if someone else wants to approve such changes. As for myself, I'll just queue them up for review once gcc-6 development opens. jeff
Re: [PATCH] libobjc: Properly handle classes without instance variables in class_copyIvarList ().
On Thu, Jan 8, 2015 at 9:35 PM, Jeff Law l...@redhat.com wrote: On 01/05/15 14:18, Mike Stump wrote: On Dec 24, 2014, at 9:28 AM, Dimitris Papavasiliou dpapa...@gmail.com wrote: The attached patch fixes an issue reported a couple of years ago in Bug 51891 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51891). The problem is caused because classes without instance variables have no ivar list at all, so that their ivars pointer is NULL, but the code in class_copyIvarList () is unaware of this. That this is in fact so can be easily verified by checking the code of class_addIvar in the same source file, where the ivars list is allocated when the first ivar is added. The code there also checks for a NULL ivars pointer. The patch also adds a simple test-case for this issue. I think that the ChangeLog entry should be something along the lines of: 2014-12-24 Dimitris Papavasiliou dpapa...@gmail.com PR libobjc/51891 * libobjc/ivars.c: Add a check for classes without instance variables, which have a NULL ivar list pointer. * gcc/testsuite/objc.dg/gnu-api-2-class.m: Add a test case for the above change. I hope I got the formatting right. I've run make -k check-objc and all tests pass without problems. Let me know if there are any problems, or if I can do anything else to facilitate the acceptance of the patch. Regards, Dimitris So, Andrew is the reviewer for libobjc. I’m not. I don’t have any issue with it. Do you want to be a reviewer for libobjc? I don't think the load there is high, but having someone else who cares about the code is always a good thing. I am a reviewer for libobjc, I had missed this patch when it came in due to the low traffic of libobjc patches and working on other projects at the time. I had marked as something I needed to review but I did not get around to it until now. Thanks, Andrew jeff
Re: [PATCH] LRA: Fix caller-save store/restore instruction for large mode
On Fri, Jan 9, 2015 at 6:03 AM, Jeff Law l...@redhat.com wrote: On 01/08/15 08:58, Kito Cheng wrote: Hi Jeff: After discussion with Bin, he prefer just use gcc.c-torture/execute/scal-to-vec1.c instead of introduce new one, do you have any further comment on this patch? Ah, if there's an existing test, then we certainly don't need a new one. Hi, according to the review comments, I applied the new version patch on behalf of Kito (because of no write access) as revision 219375. Thanks, bin
Re: [PING][PATCH][1-3] New configure options that make the compiler use -fPIE and -pie as default option
On 31/12/14 07:23, Magnus Granberg wrote: fredag 14 november 2014 23.31.48 skrev Magnus Granberg: måndag 10 november 2014 21.26.39 skrev Magnus Granberg: Rainer Thanks Rainer for the nits and comments. Have updated the patches and Changelogs. But i still use PIE_DRIVER_SELF_SPECS, do you have a ide where move it so i don't need to duplicate that stuff or how to do it? Magnus G 2014-11-10 Magnus Granberg zo...@gentoo.org /gcc * config/gnu-user.h (PIE_DRIVER_SELF_SPECS) and (GNU_DRIVER_SELF_SPECS): Define. * config/i386/gnu-user-common.h (DRIVER_SELF_SPECS): Define * configure.ac: Add new option. * configure, config.in: Rebuild. * Makefile.in (ALL_CFLAGS) and (ALL_CXXFLAGS): Disable PIE. * doc/install.texi: New configure option. * doc/invoke.texi: Add note to PIE. * doc/sourcebuild.texi: New effective target. gcc/testsuite * gcc/default-pie.c: New test * gcc.dg/tree-ssa/ssa-store-ccp-3.c: Skip if default_pie * g++.dg/other/anon5.C: Skip if default_pie * lib/target-supports.exp (check_effective_target_default_pie): New proc. /libgcc * Makefile.in (CRTSTUFF_CFLAGS): Disable PIE. Can this be included for GCC 5 ? /Magnus G. One more ping on this. The patches where sent before stage 1 closed but i did't get any feed back from it Have updete the patchses for gcc 5.0 20141228 snapshot. Bootstrapped and tested on x86_64-unknown-linux-gnu (Gentoo) /Magnus I'm giving this a further ping as my distribution has interest in these patches. Thanks! 2014-12-30 Magnus Granberg zo...@gentoo.org /gcc * config/gnu-user.h (PIE_DRIVER_SELF_SPECS): Define. * config/i386/gnu-user-common.h (DRIVER_SELF_SPECS): Define and add PIE_DRIVER_SELF_SPECS. * configure.ac: Add new option. * configure, config.in: Rebuild. * Makefile.in (ALL_CFLAGS) and (ALL_CXXFLAGS): Disable PIE. * doc/install.texi: New configure option. * doc/invoke.texi: Add note to PIE. * doc/sourcebuild.texi: New effective target. gcc/testsuite * gcc/default-pie.c: New test * gcc.dg/tree-ssa/ssa-store-ccp-3.c: Skip if default_pie * g++.dg/other/anon5.C: Skip if default_pie * lib/target-supports.exp (check_effective_target_default_pie): New proc. /libgcc * Makefile.in (CRTSTUFF_CFLAGS): Disable PIE.
Re: [PATCH] IPA ICF: add comparison for target and optimization nodes
On 01/07/15 04:38, Martin Liška wrote: Hello. Following patch adds support for target and optimization nodes comparison, which is based on Honza's newly added infrastructure. Apart from that, there's a small hunk that corrects formatting and removes unnecessary call to a comparison function. Hope it can be applied as one patch. Tested on x86_64-linux-pc without any new regression introduction. Ready for trunk? Thank you, Martin 0001-IPA-ICF-target-and-optimization-flags-comparison.patch From 393eaa47c8aef9a91a1c635016f23ca2f5aa25e4 Mon Sep 17 00:00:00 2001 From: mliskamli...@suse.cz Date: Tue, 6 Jan 2015 15:06:18 +0100 Subject: [PATCH] IPA ICF: target and optimization flags comparison. gcc/ChangeLog: 2015-01-06 Martin Liskamli...@suse.cz * cgraphunit.c (cgraph_node::create_wrapper): Fix level of indentation. * ipa-icf.c (sem_function::equals_private): Add support for target and (sem_item_optimizer::merge_classes): Remove redundant function comparison. optimization flags comparison. * tree.h (target_opts_for_fn): New function. Looks like the changelog is a bit goof'd with lines intermixed. Patch itself is good for the trunk. It'd be nice if you could add a testcase as well. Jeff
Re: [PATCH] Fix for PR ipa/64503
On 01/07/15 03:55, Uros Bizjak wrote: On Tue, Jan 6, 2015 at 7:25 PM, Uros Bizjak ubiz...@gmail.com wrote: There's suggested patch for PR ipa/64503 that was tested on x86_64 and it works. I would like to ask Uros to test it on an aplha machine before we install the patch. Yes, this works for me on all IPA tests that were failing previously [1]. I am restarting the bootstrap + regtest, it will take ~10 hours, but I don't expect any surprises there. The patch was bootstrapped and regression tested on alphaev68-linux-gnu [2] and everything was OK. [2] https://gcc.gnu.org/ml/gcc-testresults/2015-01/msg00577.html I'll approve the patch. scalbln is part of the ISO C standard as well as IEEE 1003.1, so I think we can rely on it. If there's a host without, then we'll have to figure something out if/when the issue is reported. jeff
Re: Patch ping
On 01/05/15 14:39, Jakub Jelinek wrote: On Mon, Jan 05, 2015 at 02:27:41PM -0700, Jeff Law wrote: On 01/05/15 06:53, Jakub Jelinek wrote: Hi! I'd like to ping 3 patches: http://gcc.gnu.org/ml/gcc-patches/2014-12/msg01519.html - PR64344 - -fsanitize=float-cast-overflow fix - the C FE part is approved, but not the sanitizer bits outside of the FE OK. http://gcc.gnu.org/ml/gcc-patches/2014-12/msg01271.html - PR64265 - tsan support for exceptions OK. http://gcc.gnu.org/ml/gcc-patches/2014-12/msg00297.html - -fsanitize=vptr support How is this different from vtable pointer verification that we already support? Is there some reason we can't just use that instead? I don't now the current vtable pointer verification too much, but my understanding of it is that it is hardly usable, because e.g. it requires libstdc++ to be rebuilt with the verification enabled, otherwise you can't verify stuff, and that means a performance penalty even for code you don't want to verify. Unlike that, -fsanitize=vptr is lightweight, and you only rebuild with it what you want and can have other code kept as is, not recompiled. OK. I'd forgotten about the recompile libstdc++ aspect. Sigh. The language independent stuff looks reasonable to me -- you know this code better than I, so it was just a cursory look. Jason should ack the C++ bits. jeff
Re: [PATCH] libobjc: Properly handle classes without instance variables in class_copyIvarList ().
On 01/05/15 14:18, Mike Stump wrote: On Dec 24, 2014, at 9:28 AM, Dimitris Papavasiliou dpapa...@gmail.com wrote: The attached patch fixes an issue reported a couple of years ago in Bug 51891 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51891). The problem is caused because classes without instance variables have no ivar list at all, so that their ivars pointer is NULL, but the code in class_copyIvarList () is unaware of this. That this is in fact so can be easily verified by checking the code of class_addIvar in the same source file, where the ivars list is allocated when the first ivar is added. The code there also checks for a NULL ivars pointer. The patch also adds a simple test-case for this issue. I think that the ChangeLog entry should be something along the lines of: 2014-12-24 Dimitris Papavasiliou dpapa...@gmail.com PR libobjc/51891 * libobjc/ivars.c: Add a check for classes without instance variables, which have a NULL ivar list pointer. * gcc/testsuite/objc.dg/gnu-api-2-class.m: Add a test case for the above change. I hope I got the formatting right. I've run make -k check-objc and all tests pass without problems. Let me know if there are any problems, or if I can do anything else to facilitate the acceptance of the patch. Regards, Dimitris So, Andrew is the reviewer for libobjc. I’m not. I don’t have any issue with it. Do you want to be a reviewer for libobjc? I don't think the load there is high, but having someone else who cares about the code is always a good thing. jeff
Re: [PATCH][rtlanal.c][BE][1/2] Fix vector load/stores to not use ld1/st1
On 12/12/14 04:07, Alan Hayward wrote: [Cleaning this thread up to submit patch again, with better explanation] This patch causes subreg_get_info() to exit early in the simple cases where we are extracting a whole register from a multi register. In aarch64 for Big Endian we were producing a subreg of a OImode (256bits) from a CImode (384bits) This would hit the following assert in subreg_get_info: gcc_assert ((GET_MODE_SIZE (xmode) % GET_MODE_SIZE (ymode)) == 0); This is a rule we should be able to relax a little - if the subreg we want fits into a whole register then this is a valid result and can be easily detected earlier in the function. This has the bonus that we should be slightly reducing the execution time for more common cases, for example a subreg of 64bits from 256bits. This patch is required for the second part of the patch, which is aarch64 specific, and fixes up aarch64 Big Endian movoi/ci/xi. This second part has already been approved. This patch will apply cleanly by itself and no regressions were seen when testing aarch64 and x86_64 on make check. Cheers, Alan Changelog: 2014-11-14 Alan Hayward alan.hayw...@arm.com * rtlanal.c (subreg_get_info): Exit early for simple and common cases ChangeLog nit. Should be: * rtlanal.c (subreg_get_info): Exit early for simple and common cases. With ChangeLog fixed, this patch is OK for the trunk. If you have a testcase, please submit it as well. Thanks for your patience, Jeff
Re: [PATCH/expand] PR64011 Adjust bitsize when partial overflow happen for big-endian
On 12/30/14 03:21, Jiong Wang wrote: PR64011 is actually a general problem on all target support bit insertion instructions. we overflow check at the start of store_bit_field_1, but that only check the situation where the field lies completely outside the register, while there do have situation where the field lies partly in the register, we need to adjust bitsize for this partial overflow situation. Without this fix, pr48335-2.c on big-endian will broken on those arch support bit insert instruction, like arm, aarch64. the testcase is just pr48335-2.c, before this patch is will ICE on arm and = generate invalid assembly on AArch64. after this patch, problem gone away. ok for trunk? bootstrap OK on x86-64 aarch64. no regression on x86-64 thanks. gcc/ PR64011 * expmed.c (store_bit_field_using_insv): Adjust bitsize when there is partial overflow. Why adjust here the size of the stored field? Doesn't this end up storing less information? If those bits are still within the object, even if the object is by some means living in a mixture of registers and memory, then don't we need to set them all? If those bits are outside the object, then isn't the source simply broken because it's writing data outside the bounds of the given object? Am I missing something here? jeff
Re: [PATCH] Fix for PR64081 in RTL loop unroller
On 12/19/14 03:20, Zamyatin, Igor wrote:
Hi!
This is an attempt to extend RTL unroller to allow cases like mentioned in the
PR -
namely when loop has duplicated exit blocks and back edges.
Bootstrapped and regtested on x86_64, also checking wide range of benchmarks -
spec2K, spec2006, EEMBC
Is it ok for trunk in case if no testing issues?
Thanks,
Igor
Changelog:
Gcc:
2014-12-19 Igor Zamyatin igor.zamya...@intel.com
PR rtl-optimization/64081
* loop-iv.c (def_pred_latch_p): New function.
(latch_dominating_def): Allow specific cases with non-single
definitions.
(iv_get_reaching_def): Likewise.
(check_complex_exit_p): New function.
(check_simple_exit): Use check_complex_exit_p to allow certain cases
with exits not executing on any iteration.
Testsuite:
2014-12-19 Igor Zamyatin igor.zamya...@intel.com
PR rtl-optimization/64081
* gcc.dg/pr64081.c: New test.
diff --git a/gcc/loop-iv.c b/gcc/loop-iv.c
index f55cea2..d5d48f1 100644
--- a/gcc/loop-iv.c
+++ b/gcc/loop-iv.c
/* Finds the definition of REG that dominates loop latch and stores
it to DEF. Returns false if there is not a single definition
- dominating the latch. If REG has no definition in loop, DEF
+ dominating the latch or all defs are same and they are on different
+ predecessors of loop latch. If REG has no definition in loop, DEF
is set to NULL and true is returned. */
Is it really sufficient here to verify that all the defs are on latch
predecessors, what about the case where there is a predecessor without a
def. How do you guarantee domination in that case?
ISTM that given the structure for the code you're writing that you'd
want to verify that in the event of multiple definitions that all of
them appear on immediate predecessors of the latch *and* that each
immediate predecessor has a definition.
static bool
latch_dominating_def (rtx reg, df_ref *def)
{
df_ref single_rd = NULL, adef;
- unsigned regno = REGNO (reg);
+ unsigned regno = REGNO (reg), def_num = 0;
struct df_rd_bb_info *bb_info = DF_RD_BB_INFO (current_loop-latch);
for (adef = DF_REG_DEF_CHAIN (regno); adef; adef = DF_REF_NEXT_REG (adef))
{
+ /* Initialize this to true for the very first iteration when
+SINGLE_RD is NULL. */
+ bool def_pred_latch = true;
+
if (!bitmap_bit_p (df-blocks_to_analyze, DF_REF_BBNO (adef))
|| !bitmap_bit_p (bb_info-out, DF_REF_ID (adef)))
continue;
- /* More than one reaching definition. */
+ /* More than one reaching definition is ok in case definitions are
+in predecessors of latch block and those definitions are the same.
+Probably this could be relaxed and check for sub-dominance instead
+predecessor. */
if (single_rd)
- return false;
-
- if (!just_once_each_iteration_p (current_loop, DF_REF_BB (adef)))
- return false;
+ {
+ def_num++;
+ if (!(def_pred_latch = def_pred_latch_p (adef))
+ || !rtx_equal_p( PATTERN (DF_REF_INSN (single_rd)),
Whitespace nit here. Whitespace goes before the open paren for the
function call, not after.
@@ -351,10 +384,10 @@ latch_dominating_def (rtx reg, df_ref *def)
static enum iv_grd_result
iv_get_reaching_def (rtx_insn *insn, rtx reg, df_ref *def)
And in this routine, you appear to do both checks. ie, each def is on
an immediate predecessor and each immediate predecessor has a def. Is
there some reason why iv_get_reaching_def has the stronger check while
latch_dominating_def does not?
jeff
Re: [PATCHv2] New check and updates in check_GNU_style script
On 12/11/14 03:24, Yury Gribov wrote: Hi all, Attached patch adds new check (all blocks of 8 spaces are replaced with tabs) to contrib/check_GNU_style.sh. It also changes the script to allow reading patches from stdin and strengthens the Dot, space, space, new sentence. check. Is this ok to commit? Yes. This is fine. Thanks and sorry for the delay, jeff
Re: [Patch docs 1/5] Update the first section of md.texi
On 01/06/15 11:55, Joseph Myers wrote:
On Tue, 6 Jan 2015, James Greenhalgh wrote:
-The @file{.md} file for a target machine contains a pattern for each
-instruction that the target machine supports (or at least each instruction
-that is worth telling the compiler about). It may also contain comments.
-A semicolon causes the rest of the line to be a comment, unless the semicolon
-is inside a quoted string.
A detailed description of the syntax of a .md file does not belong in an
introduction. It is a deficiency of this patch set that this text is not
added back elsewhere. Do you have any suggestions of where the text could
sensibly go?
A section that describes the lexical structure and syntax of .md files?
Seems reasonable. However, is that too heavyweight?
ISTM we have, effectively 3 items.
Directives that start with an open-paren and end with their associated
close paren. ANything in between those parens is governed by the
documentation for the specific directive.
Outside a directive we can lines with are empty or contain just
whitespace. These lines are effectively ignored.
Also outside a directive are lines that start with ';;'. From the ';;'
to the end of line are comments and ignored.
@@ -54,50 +54,60 @@ See the next chapter for information on the C header file.
@node Overview
@section Overview of How the Machine Description is Used
-There are three main conversions that happen in the compiler:
+There are four main conversions that happen in the compiler:
The previous text is inaccurate.
It would seem better not to give a specific number (just as we've tried to
keep down the number of references in the web pages to a particular
version control system).
Agreed. It's bound to get out of date as some point.
I prefer the text below. We lose without regard for the RTL template or
operand constraints, but this is contradictory anyway, as the RTL template
is used when expanding a define_insn.
I believe the point of without regard for the RTL template or operand
constraints is that when e.g. expanding addition of two SImode values,
the RTL template from the addsi3 pattern is inserted blindly, even if that
RTL looks nothing like RTL for an addition; nothing looks for an (add:SI)
pattern, or generates such RTL if it's not what the RTL for addsi3 looks
like.
Right, but the next paragraph expands on things a bit and I think is
sufficient that we can drop the without regard for the RTL template.
So perhaps take that out, but leave the without regard for the operand
constraints.
Jeff
Re: Patch RFA: Support for building Go tools
On Jan 8, 2015, at 1:35 PM, Ian Lance Taylor i...@golang.org wrote: This patch adds support to the GCC tree for building tools that are used with Go. There are two external used tools (go, gofmt) and one tool used internally by go (cgo). This patch is pure machinery, with no source code. The tools are not built by default, only when go is enabled using --enable-languages. For the moment the tools are also not built when building a cross-compiler, although I hope to change that when I figure out what is needed. When you add support for cross, please also make sure that Canadian cross works too. Thanks, Andrew The tools work just as they do when built for the gc compiler, only they use gccgo instead of gc. For documentation on these tools and what they do see http://golang.org/cmd/go , http://golang.org/cmd/gofmt , http://golang.org/cmd/cgo . This patch parallels the mechanism used in the existing gnattools directory for building Ada tools. Could the build machinery maintainers please take a look and let me know if this is OK? Thanks. Lynn, please also take a look and see if this works for you. The first attachment is the real changes for review. The second attachment is a compressed patch for the generated files, for convenience for anybody who wants to try this out. Ian foo.txt foo1.txt.bz2
[PATCH, committed] jit: New API entrypoint: gcc_jit_context_get_last_error
This is of use when writing bindings for higher-level languages that support exception-handling. An example of using this is: https://bitbucket.org/pypy/pypy/commits/6b48e7ef126a50f0bd181f59a827244e0b3e2a00 where I use it in my experimental PyPy backend in order to raise meaningful RPython exceptions whenever I do something bogus that leads to a NULL back from the libgccjit API. This makes it *much* easier to track down problems when developing client code that uses libgccjit. Committed to trunk as r219363. gcc/jit/ChangeLog: * docs/topics/contexts.rst (Error-handling): Document new entrypoint gcc_jit_context_get_last_error. * docs/_build/texinfo/libgccjit.texi: Regenerate. * jit-recording.c (gcc::jit::recording::context::context): Initialize new fields m_last_error_str and m_owns_last_error_str. (gcc::jit::recording::context::~context): Clean up m_last_error_str, if needed. (gcc::jit::recording::context::add_error_va): Update m_last_error_str and m_owns_last_error_str, freeing the old value if appropriate. (gcc::jit::recording::context::get_last_error): New function. * jit-recording.h (gcc::jit::recording::context::get_last_error): New function. (gcc::jit::recording::context): New fields m_last_error_str and m_owns_last_error_str. * libgccjit.c (gcc_jit_context_get_last_error): New function. * libgccjit.h (gcc_jit_context_get_last_error): New declaration. * libgccjit.map (gcc_jit_context_get_last_error): New function. gcc/testsuite/ChangeLog: * jit.dg/test-error-block-in-wrong-function.c (verify_code): Verify the result of gcc_jit_context_get_last_error. * jit.dg/test-error-null-passed-to-api.c (verify_code): Likewise. --- gcc/jit/docs/topics/contexts.rst | 18 ++- gcc/jit/jit-recording.c| 27 +++--- gcc/jit/jit-recording.h| 6 + gcc/jit/libgccjit.c| 14 +++ gcc/jit/libgccjit.h| 10 gcc/jit/libgccjit.map | 1 + .../jit.dg/test-error-block-in-wrong-function.c| 3 +++ .../jit.dg/test-error-null-passed-to-api.c | 2 ++ 8 files changed, 77 insertions(+), 4 deletions(-) diff --git a/gcc/jit/docs/topics/contexts.rst b/gcc/jit/docs/topics/contexts.rst index 6099c69..3dc313c 100644 --- a/gcc/jit/docs/topics/contexts.rst +++ b/gcc/jit/docs/topics/contexts.rst @@ -123,7 +123,9 @@ In general, if an error occurs when using an API entrypoint, the entrypoint returns NULL. You don't have to check everywhere for NULL results, since the API handles a NULL being passed in for any argument by issuing another error. This typically leads to a cascade of -followup error messages, but is safe (albeit verbose). +followup error messages, but is safe (albeit verbose). The first error +message is usually the one to pay attention to, since it is likely to +be responsible for all of the rest: .. function:: const char *\ gcc_jit_context_get_first_error (gcc_jit_context *ctxt) @@ -135,6 +137,20 @@ followup error messages, but is safe (albeit verbose). If no errors occurred, this will be NULL. +If you are wrapping the C API for a higher-level language that supports +exception-handling, you may instead by interested in the last error that +occurred on the context, so that you can embed this in an exception: + +.. function:: const char *\ + gcc_jit_context_get_last_error (gcc_jit_context *ctxt) + + Returns the last error message that occurred on the context. + + The returned string is valid for the rest of the lifetime of the + context. + + If no errors occurred, this will be NULL. + Debugging - diff --git a/gcc/jit/jit-recording.c b/gcc/jit/jit-recording.c index a872063..a9ff300 100644 --- a/gcc/jit/jit-recording.c +++ b/gcc/jit/jit-recording.c @@ -175,6 +175,8 @@ recording::context::context (context *parent_ctxt) m_error_count (0), m_first_error_str (NULL), m_owns_first_error_str (false), +m_last_error_str (NULL), +m_owns_last_error_str (false), m_mementos (), m_compound_types (), m_functions (), @@ -230,6 +232,10 @@ recording::context::~context () if (m_owns_first_error_str) free (m_first_error_str); + + if (m_owns_last_error_str) +if (m_last_error_str != m_first_error_str) + free (m_last_error_str); } /* Add the given mememto to the list of those tracked by this @@ -984,9 +990,12 @@ recording::context::add_error_va (location *loc, const char *fmt, va_list ap) m_first_error_str = const_cast char * (errmsg); m_owns_first_error_str = has_ownership; } - else -if (has_ownership) - free (malloced_msg); + + if (m_owns_last_error_str) +if (m_last_error_str !=
Re: [Patch docs 2/5] Update Instruction Patterns in md.texi
On 01/06/15 04:21, James Greenhalgh wrote:
Hi,
This patch updates the second section of md.texi - Everything about
Patterns.
I was aiming to:
* Remove outdated details of the compiler.
* Remove long or obscure words that, while accurate, only served to
obfuscate a simple idea.
* Refer to similar things in a consistent fashion - in particular
trying to keep consistent use of insn and pattern.
* Remove superflous examples, or waffling.
OK?
Thanks,
James
---
2015-01-06 James Greenhalghjames.greenha...@arm.com
* doc/md.texi (Instruction Patterns): Update text.
(Example): Update text.
0002-Patch-docs-2-5-Update-Instruction-Patterns-in-md.tex.patch
diff --git a/gcc/doc/md.texi b/gcc/doc/md.texi
index 0277f14..b852981 100644
--- a/gcc/doc/md.texi
+++ b/gcc/doc/md.texi
@@ -115,85 +115,98 @@ emit the final assembly code. For this purpose, names
are ignored. All
@cindex instruction patterns
@findex define_insn
-Each instruction pattern contains an incomplete RTL expression, with pieces
-to be filled in later, operand constraints that restrict how the pieces can
-be filled in, and an output pattern or C code to generate the assembler
-output, all wrapped up in a @code{define_insn} expression.
+A @code{define_insn} expression is used to define instruction patterns
+to which insns may be matched. A @code{define_insn} expression contains
+an incomplete RTL expression, with pieces to be filled in later, operand
+constraints that restrict how the pieces can be filled in, and an output
+template or C code to generate the assembler output.
-A @code{define_insn} is an RTL expression containing four or five operands:
+A @code{define_insn} contains either four or five components:
How about
A @code{define_insn} contains the following components:
@enumerate
@item
-An optional name. The presence of a name indicate that this instruction
-pattern can perform a certain standard job for the RTL-generation
-pass of the compiler. This pass knows certain names and will use
-the instruction patterns with those names, if the names are defined
-in the machine description.
-
-The absence of a name is indicated by writing an empty string
-where the name should go. Nameless instruction patterns are never
-used for generating RTL code, but they may permit several simpler insns
-to be combined later on.
-
-Names that are not thus known and used in RTL-generation have no
-effect; they are equivalent to no name at all.
+The @dfn{insn name}: When expanding from gimple to RTL, and when performing
+optimizations, the compiler looks for patterns with certain names,
IIRC reload looks for specific named patterns as well. There may be
other places that look for standard named patterns.
Which makes me wonder how hard we should try to nail this down. Maybe
something along the lines of passes which generate new insns may look
for standard names.
+collectively known as the standard pattern names (@pxref{Standard Names}).
+The target-independent infrastructure in the compiler which references
+these names is generally accessed through the interfaces defined
+in @code{optabs.c}.
Hmm, I'm not sure I'd call out optabs.c here because looking up standard
names happens all over the place.
+
+Names that are not listed as one of the standard pattern names are not
+used directly by the target-independent code. However, machine
+descriptions may themselves make use of named patterns in
+@code{define_expand} or @code{define_split} expressions.
make use of named patterns when generating insns or something similar?
In theory that covers us if we have other define_foo things that want
to look at named patterns in the future.
+
+It is also possible to define a nameless instruction pattern. This uses
+an empty string in place of the name. Nameless instruction patterns cannot
+be used when generating RTL code, but they may be matched against during
+the combine and split passes of the compiler.
Wouldn't necessarily call out combine here -- nameless patterns could be
matched anytime RTL is changed. Just changing an operand from a
constant to a register or vice-versa may trigger the use of a nameless
pattern.
+
+Where names are given to instruction patterns, these must be unique
+in the machine description file.
We can have multiple .md files, so probably unique across the machine
description files for the given target.
@item
-The @dfn{output template}: a string that says how to output matching
-insns as assembler code. @samp{%} in this string specifies where
-to substitute the value of an operand. @xref{Output Template}.
+The @dfn{output template} or @dfn{output statement}: This is either
+a string, or a fragment of C code which returns a string.
-When simple substitution isn't general enough, you can specify a piece
-of C code to compute the output. @xref{Output Statement}.
+If it is a string, that string forms the output template and defines how
+a matched
Re: [PATCH] LRA: Fix caller-save store/restore instruction for large mode
On 01/08/15 08:58, Kito Cheng wrote: Hi Jeff: After discussion with Bin, he prefer just use gcc.c-torture/execute/scal-to-vec1.c instead of introduce new one, do you have any further comment on this patch? Ah, if there's an existing test, then we certainly don't need a new one. Jeff
Re: [PATCH, Libatomic, Darwin] Initial libatomic port for *darwin*.
Jack,
I haven't had time to look at the outstanding issues, and won't realistically
before stage3 ends - so I don't suppose it will be eligible for GCC5 :(
Iain
On 8 Jan 2015, at 21:56, Jack Howarth wrote:
Iain,
Were you planning to try to get this committed before stage4 or
will it have to wait for the next major gcc release?
Jack
On Thu, Nov 13, 2014 at 3:34 PM, Iain Sandoe i...@codesourcery.com wrote:
Hello Richard, Joseph,
Thanks for your reviews,
On 13 Nov 2014, at 07:40, Richard Henderson wrote:
On 11/12/2014 10:18 PM, Iain Sandoe wrote:
# ifndef USE_ATOMIC
#define USE_ATOMIC 1
# endif
Why would USE_ATOMIC be defined previously?
This was left-over from a mode where I allowed the User to jam the mode to
OSSpinLocks to test the performance.
I apologise, [weak excuse follows] with the turbulence of Darwin on trunk,
my trunk version of the patch had got behind my 4.9 one. (most of the work
has been hammered out there while we try to get bootstrap restored).
re-synced and retested with a patched trunk that bootstraps with some
band-aid.
inline static void LockUnlock(uint32_t *l) {
__atomic_store_4((_Atomic(uint32_t)*)l, 0, __ATOMIC_RELEASE);
}
Gnu coding style, please. All through the file here.
Fixed.
# define LOCK_SIZE sizeof(uint32_t)
# define NLOCKS (PAGE_SIZE / LOCK_SIZE)
static uint32_t locks[NLOCKS];
Um, surely not LOCK_SIZE, but CACHELINE_SIZE. It's the granularity of the
target region that's at issue, not the size of the lock itself.
The algorithm I've used is intentionally different from the pthreads-based
posix one, here's the rationale, as I see it:
/* Algorithm motivations.
Layout Assumptions:
o Darwin has a number of sub-targets with common atomic types that have no
'native' in-line handling, but are smaller than a cache-line.
E.G. PPC32 needs locking for = 8byte quantities, X86/m32 for =16.
o The _Atomic alignment of a natural type is no greater than the type
size.
o There are no special guarantees about the alignment of _Atomic aggregates
other than those determined by the psABI.
o There are no guarantees that placement of an entity won't cause it to
straddle a cache-line boundary.
o Realistic User code will likely place several _Atomic qualified types in
close proximity (such that they fall within the same cache-line).
Similarly, arrays of _Atomic qualified items.
Performance Assumptions:
o Collisions of address hashes for items (which make up the lock keys)
constitute the largest performance issue.
o We want to avoid unnecessary flushing of [lock table] cache-line(s) when
items are accessed.
Implementation:
We maintain a table of locks, each lock being 4 bytes (at present).
This choice of lock size gives some measure of equality in hash-collision
statistics between the 'atomic' and 'OSSpinLock' implementations, since the
lock size is fixed at 4 bytes for the latter.
The table occupies one physical page, and we attempt to align it to a
page boundary, appropriately.
For entities that need a lock, with sizes one cache line:
Each entity that requires a lock, chooses the lock to use from the table
on
the basis of a hash determined by its size and address. The lower
log2(size)
address bits are discarded on the assumption that the alignment of entities
will not be smaller than their size.
CHECKME: this is not verified for aggregates; it might be something that
could/should be enforced from the front ends (since _Atomic types are
allowed to have increased alignment c.f. 'normal').
For entities that need a lock, with sizes = one cacheline_size:
We assume that the entity alignment = log2(cacheline_size) and discard
log2(cacheline_size) bits from the address.
We then apply size/cacheline_size locks to cover the entity.
The idea is that this will typically result in distinct hash keys for items
placed close together. The keys are mangled further such that the size is
included in the hash.
Finally, to attempt to make it such that the lock table entries are accessed
in a scattered manner,to avoid repeated cacheline flushes, the hash is
rearranged to attempt to maximise the most noise in the upper bits.
*/
NOTE that the CHECKME above doesn't put us in any worse position than the
pthreads implementation (likely slightly better since we have a smaller
granularity with the current scheme).
#if USE_ATOMIC
LockLock (locks[addr_hash (ptr, 1)]);
#else
OSSpinLockLock(locks[addr_hash (ptr, 1)]);
#endif
Better to #define LockLock OSSpinLockLock within the area above, so as to
avoid the ifdefs here.
done.
Thoughts on the rationale - or OK now?
thanks
Iain
I'm not aware of any other PRs that relate, but will do a final scan through
and ask around the darwin folks.
libatomic:
PR target/59305
* config/darwin/host-config.h
[PATCH, committed] libgccjit.h: Fix description of struct gcc_jit_context
libgccjit.h's description of gcc_jit_context talks about contexts
having two states: before vs after compilation. This hasn't been the
case for a long time, and it's long been possible to compile a context
more than once, getting a different gcc_jit_result each time (assuming
no errors happen).
Fix the comment.
Committed to trunk as r219366.
gcc/jit/ChangeLog:
* libgccjit.h (struct gcc_jit_context): Rewrite the descriptive
comment.
---
gcc/jit/libgccjit.h | 19 +++
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/gcc/jit/libgccjit.h b/gcc/jit/libgccjit.h
index 91ca409..7603033 100644
--- a/gcc/jit/libgccjit.h
+++ b/gcc/jit/libgccjit.h
@@ -31,16 +31,19 @@ extern C {
**/
/* All structs within the API are opaque. */
-/* A gcc_jit_context encapsulates the state of a compilation. It goes
- through two states:
+/* A gcc_jit_context encapsulates the state of a compilation.
+ You can set up options on it, and add types, functions and code, using
+ the API below.
- (1) initial, during which you can set up options on it, and add
- types, functions and code, using the API below.
- Invoking gcc_jit_context_compile on it transitions it to the
- after compilation state.
+ Invoking gcc_jit_context_compile on it gives you a gcc_jit_result *
+ (or NULL).
- (2) after compilation, when you can call gcc_jit_context_release to
- clean up. */
+ You can call gcc_jit_context_compile repeatedly on one context, giving
+ multiple independent results.
+
+ Eventually you can call gcc_jit_context_release to clean up the
+ context; any results created from it are still usable, and should be
+ cleaned up via gcc_jit_result_release. */
typedef struct gcc_jit_context gcc_jit_context;
/* A gcc_jit_result encapsulates the result of a compilation. */
--
1.8.5.3
Re: [ping**3] Re: [patch, ARM] Add support for crtfastmath.o
On 12/17/2014 03:21 PM, Sandra Loosemore wrote: On 12/07/2014 01:52 PM, Sandra Loosemore wrote: On 11/08/2014 08:57 AM, Sandra Loosemore wrote: 2014-11-08 Sandra Loosemore san...@codesourcery.com Chris Jones chr...@nvidia.com Joshua Conner jcon...@nvidia.com gcc/ * config/arm/unknown-elf.h (STARTFILE_SPEC): Add conditional linking of crtfastmath.o. * config/arm/linux-eabi.h (STARTFILE_SPEC): Likewise. libgcc/ * config.host (arm*-*-linux*): Add support for crtfastmath.o. (arm*-*-uclinux*): Likewise. (arm*-*-eabi* | arm*-*-rtems*): Likewise. * config/arm/crtfastmath.c: New file. Ping? https://gcc.gnu.org/ml/gcc-patches/2014-11/msg00711.html Ping again? And ping again Can somebody please review this before stage 4 starts and it is too late to get it into GCC 5? This is really a very straightforward change and is pretty much identical to what other targets (including aarch64) already do. -Sandra
Re: [RFA:] Fix test-suite regressions from PR62250 due to -latomic always added
On Jan 7, 2015, at 6:32 PM, Hans-Peter Nilsson hans-peter.nils...@axis.com wrote: PR62250 (r219171) was about some fortran tests that used atomic operations but failing on systems where -latomic is required. The fix was to always add -latomic. That caused test-suite regressions for targets that don't have libatomic, but where the required operations are built-in (no separate PR entered, the fix below seemed simple enough). Ok to commit? Ok.
Re: [PATCH, Libatomic, Darwin] Initial libatomic port for *darwin*.
Iain,
Were you planning to try to get this committed before stage4 or
will it have to wait for the next major gcc release?
Jack
On Thu, Nov 13, 2014 at 3:34 PM, Iain Sandoe i...@codesourcery.com wrote:
Hello Richard, Joseph,
Thanks for your reviews,
On 13 Nov 2014, at 07:40, Richard Henderson wrote:
On 11/12/2014 10:18 PM, Iain Sandoe wrote:
# ifndef USE_ATOMIC
#define USE_ATOMIC 1
# endif
Why would USE_ATOMIC be defined previously?
This was left-over from a mode where I allowed the User to jam the mode to
OSSpinLocks to test the performance.
I apologise, [weak excuse follows] with the turbulence of Darwin on trunk, my
trunk version of the patch had got behind my 4.9 one. (most of the work has
been hammered out there while we try to get bootstrap restored).
re-synced and retested with a patched trunk that bootstraps with some
band-aid.
inline static void LockUnlock(uint32_t *l) {
__atomic_store_4((_Atomic(uint32_t)*)l, 0, __ATOMIC_RELEASE);
}
Gnu coding style, please. All through the file here.
Fixed.
# define LOCK_SIZE sizeof(uint32_t)
# define NLOCKS (PAGE_SIZE / LOCK_SIZE)
static uint32_t locks[NLOCKS];
Um, surely not LOCK_SIZE, but CACHELINE_SIZE. It's the granularity of the
target region that's at issue, not the size of the lock itself.
The algorithm I've used is intentionally different from the pthreads-based
posix one, here's the rationale, as I see it:
/* Algorithm motivations.
Layout Assumptions:
o Darwin has a number of sub-targets with common atomic types that have no
'native' in-line handling, but are smaller than a cache-line.
E.G. PPC32 needs locking for = 8byte quantities, X86/m32 for =16.
o The _Atomic alignment of a natural type is no greater than the type
size.
o There are no special guarantees about the alignment of _Atomic aggregates
other than those determined by the psABI.
o There are no guarantees that placement of an entity won't cause it to
straddle a cache-line boundary.
o Realistic User code will likely place several _Atomic qualified types in
close proximity (such that they fall within the same cache-line).
Similarly, arrays of _Atomic qualified items.
Performance Assumptions:
o Collisions of address hashes for items (which make up the lock keys)
constitute the largest performance issue.
o We want to avoid unnecessary flushing of [lock table] cache-line(s) when
items are accessed.
Implementation:
We maintain a table of locks, each lock being 4 bytes (at present).
This choice of lock size gives some measure of equality in hash-collision
statistics between the 'atomic' and 'OSSpinLock' implementations, since the
lock size is fixed at 4 bytes for the latter.
The table occupies one physical page, and we attempt to align it to a
page boundary, appropriately.
For entities that need a lock, with sizes one cache line:
Each entity that requires a lock, chooses the lock to use from the table
on
the basis of a hash determined by its size and address. The lower
log2(size)
address bits are discarded on the assumption that the alignment of entities
will not be smaller than their size.
CHECKME: this is not verified for aggregates; it might be something that
could/should be enforced from the front ends (since _Atomic types are
allowed to have increased alignment c.f. 'normal').
For entities that need a lock, with sizes = one cacheline_size:
We assume that the entity alignment = log2(cacheline_size) and discard
log2(cacheline_size) bits from the address.
We then apply size/cacheline_size locks to cover the entity.
The idea is that this will typically result in distinct hash keys for items
placed close together. The keys are mangled further such that the size is
included in the hash.
Finally, to attempt to make it such that the lock table entries are accessed
in a scattered manner,to avoid repeated cacheline flushes, the hash is
rearranged to attempt to maximise the most noise in the upper bits.
*/
NOTE that the CHECKME above doesn't put us in any worse position than the
pthreads implementation (likely slightly better since we have a smaller
granularity with the current scheme).
#if USE_ATOMIC
LockLock (locks[addr_hash (ptr, 1)]);
#else
OSSpinLockLock(locks[addr_hash (ptr, 1)]);
#endif
Better to #define LockLock OSSpinLockLock within the area above, so as to
avoid the ifdefs here.
done.
Thoughts on the rationale - or OK now?
thanks
Iain
I'm not aware of any other PRs that relate, but will do a final scan through
and ask around the darwin folks.
libatomic:
PR target/59305
* config/darwin/host-config.h New.
* config/darwin/lock.c New.
* configure.tgt (DEFAULT_X86_CPU): New, (target): New entry for
darwin.
Re: [PATCH] Fix sporadic failure in g++.dg/tsan/aligned_vs_unaligned_race.C
On Jan 8, 2015, at 1:27 PM, Jakub Jelinek ja...@redhat.com wrote: Any objections to approving it now? LGTM. Patch is Ok. If you could send the clang folks a heads up, I’ve love to see them adopt the style.
[doc] fix documentation of -fvtable-verify and related options
This patch cleans up the documentation of -fvtable-verify, -fvtv-debug,
and -fvtv-counts. The substantive change is to correct the location of
the debug log files per discussion here:
https://gcc.gnu.org/ml/gcc/2015-01/msg00029.html
but I ended up doing a pretty much total rewrite of the text to fix
various markup problems, issues with agreement of verb tense and
plurals, usage of terms like runtime, etc.
I think this particular patch goes a little beyond an obvious fix, so I
have not committed it yet. But, I don't want it to get lost in the
shuffle, so I propose to do so in a few days if I don't hear any
objection or request for more time to review it meanwhile.
-Sandra
2015-01-08 Sandra Loosemore san...@codesourcery.com
gcc/
* doc/invoke.texi ([-fvtable-verify]): Copy-edit and fix markup.
([-fvtv-debug], [-fvtv-counts]): Likewise. Correct location
of log files.
Index: gcc/doc/invoke.texi
===
--- gcc/doc/invoke.texi (revision 219335)
+++ gcc/doc/invoke.texi (working copy)
@@ -2440,35 +2440,38 @@ violation of the ODR to define types wit
@item -fvtable-verify=@r{[}std@r{|}preinit@r{|}none@r{]}
@opindex fvtable-verify
Turn on (or off, if using @option{-fvtable-verify=none}) the security
-feature that verifies at runtime, for every virtual call that is made, that
+feature that verifies at run time, for every virtual call, that
the vtable pointer through which the call is made is valid for the type of
the object, and has not been corrupted or overwritten. If an invalid vtable
-pointer is detected (at runtime), an error is reported and execution of the
+pointer is detected at run time, an error is reported and execution of the
program is immediately halted.
-This option causes runtime data structures to be built, at program start up,
-for verifying the vtable pointers. The options @code{std} and @code{preinit}
+This option causes run-time data structures to be built at program startup,
+which are used for verifying the vtable pointers.
+The options @samp{std} and @samp{preinit}
control the timing of when these data structures are built. In both cases the
-data structures are built before execution reaches 'main'. The
-@option{-fvtable-verify=std} causes these data structure to be built after the
+data structures are built before execution reaches @code{main}. Using
+@option{-fvtable-verify=std} causes the data structures to be built after
shared libraries have been loaded and initialized.
-@option{-fvtable-verify=preinit} causes them to be built before the shared
+@option{-fvtable-verify=preinit} causes them to be built before shared
libraries have been loaded and initialized.
-If this option appears multiple times in the compiler line, with different
-values specified, 'none' takes highest priority over both 'std' and
-'preinit'; 'preinit' takes priority over 'std'.
+If this option appears multiple times in the command line with different
+values specified, @samp{none} takes highest priority over both @samp{std} and
+@samp{preinit}; @samp{preinit} takes priority over @samp{std}.
@item -fvtv-debug
@opindex fvtv-debug
-Causes debug versions of the runtime functions for the vtable verification
-feature to be called. This assumes the @option{-fvtable-verify=std} or
-@option{-fvtable-verify=preinit} has been used. This flag also causes the
-compiler to keep track of which vtable pointers it found for each class, and
-record that information in the file ``vtv_set_ptr_data.log'', in the dump
-file directory on the user's machine.
+When used in conjunction with @option{-fvtable-verify=std} or
+@option{-fvtable-verify=preinit}, causes debug versions of the
+runtime functions for the vtable verification feature to be called.
+This flag also causes the compiler to log information about which
+vtable pointers it finds for each class.
+This information is written to a file named @file{vtv_set_ptr_data.log}
+in the directory named by the environment variable @env{VTV_LOGS_DIR}
+if that is defined or the current working directory otherwise.
-Note: This feature APPENDS data to the log file. If you want a fresh log
+Note: This feature @emph{appends} data to the log file. If you want a fresh log
file, be sure to delete any existing one.
@item -fvtv-counts
@@ -2476,15 +2479,17 @@ file, be sure to delete any existing one
This is a debugging flag. When used in conjunction with
@option{-fvtable-verify=std} or @option{-fvtable-verify=preinit}, this
causes the compiler to keep track of the total number of virtual calls
-it encountered and the number of verifications it inserted. It also
-counts the number of calls to certain runtime library functions
-that it inserts. This information, for each compilation unit, is written
-to a file named ``vtv_count_data.log'', in the dump_file directory on
-the user's machine. It also counts the size of the vtable pointer sets
-for
Re: [ping**2] Re: [patch, arm] align saved FP regs on stack
On 12/17/2014 03:18 PM, Sandra Loosemore wrote: On 11/14/2014 05:46 PM, Sandra Loosemore wrote: 2014-11-14 Sandra Loosemore san...@codesourcery.com Joshua Conner jcon...@nvidia.com Chris Jones chr...@nvidia.com gcc/ * doc/invoke.texi (Option Summary): Add -malign-saved-fp-regs. (ARM options): Document it. * config/arm/arm.h (arm_stack_offsets): Add fp_regs_padding field. * config/arm/arm.opt (malign-saved-fp-regs): New option. * config/arm/arm.c (add_dummy_register_save_p): New function, split from... (arm_get_frame_offsets): Here. Use this logic also for aligning saved VFP coprocessor registers if possible. (arm_expand_prologue): Add explicit padding for saved VFP registers. (arm_expand_epilogue): Undo explicit padding for saved VFP registers. Ping? https://gcc.gnu.org/ml/gcc-patches/2014-11/msg01914.html Ping again? This patch was posted during stage 1; can somebody review this before Stage 4 starts and it's too late to get it in GCC 5? -Sandra
Re: [Patch, libstdc++/64239] Use std::swap instead of swap in regex
On 08/01/15 11:44 -0800, Tim Shen wrote: On Wed, Jan 7, 2015 at 4:39 AM, Jonathan Wakely jwak...@redhat.com wrote: No blank line here in the ChangeLog. Done. This is swapping iterators, which can be user-defined types, so it should support finding a swap function by ADL, i.e. Done. Also, there should be a new test, since apparently we don't have any test that tries to call match_results::swap(match_results). Done. Thanks - OK for trunk and 4.9.
RE: [PATCH] Fix sporadic failure in g++.dg/tsan/aligned_vs_unaligned_race.C
On Thu, 8 Jan 2015 14:05:32, Mike Stump wrote: On Jan 8, 2015, at 1:27 PM, Jakub Jelinek ja...@redhat.com wrote: Any objections to approving it now? LGTM. Patch is Ok. If you could send the clang folks a heads up, I’ve love to see them adopt the style. Thanks, I am glad that we finally have a working solution. Checked in as https://gcc.gnu.org/viewcvs/gcc?view=revisionrevision=219367 Dmitry, would you like to use that solution also in the clang tree, instead of sleep(1) and %deflake ? Thanks Bernd.
Re: [RFC PATCH 8/9] [SH] Add splitter to addsi3_compact
On Thu, 2014-12-18 at 10:04 +0900, Kaz Kojima wrote:
This patch is discussed in PR55212
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212#c65
and is to make LRA's register elimination work well on SH.
The problem is SH has very limited add instructions only and expands
rA := rB + N to (set rA (const_int N)) and (set rA (plus rA rB))
instead of (set rA (plus rB (const_int N))). It seems that the former
combination isn't good for LRA's register elimination pass. The patch
adds splitter to addsi3_compact insn so that LRA can see the latter
rtl.
--
* config/sh/predicates.md (arith_or_int_operand): New predicate.
* config/sh/sh.md (addsi3): Use arith_or_int_operand for operand 2.
Return fail if operands[0] and operands[1] are overlap when
operands[2] is integer constant.
(*addsi3_compact): Make it define_insn_and_split which splits
reg0 := reg1 + constant to reg0 = constant and reg0 := reg0 + reg1.
I've noticed that this change tends to produce code like ...
mov #123,rA
...
add rA,rB
It's a bit better to do:
mov rB,rA
...
add #123,rA
if the constant fits into #imm8. The attached patch does that.
Tested with make -k check RUNTESTFLAGS=--target_board=sh-sim
\{-m2/-ml,-m2/-mb,-m2a/-mb,-m4/-ml,-m4/-mb,-m4a/-ml,-m4a/-mb}
and no new failures. CSiBE shows a couple of cases where code size
decreases. Committed as r219341.
Cheers,
Oleg
gcc/ChangeLog:
PR target/55212
* config/sh/sh.md (*addsi3_compact): Emit reg-reg copy instead of
constant load if constant operand fits into I08.
Index: gcc/config/sh/sh.md
===
--- gcc/config/sh/sh.md (revision 219339)
+++ gcc/config/sh/sh.md (working copy)
@@ -2061,8 +2061,9 @@
;; The problem is that LRA expects something like
;;(set rA (plus rB (const_int N)))
;; to work. We can do that, but we have to split out an additional reg-reg
-;; copy before the actual add insn. Use u constraint for that case to avoid
-;; the invalid value in the stack pointer.
+;; copy or constant load before the actual add insn.
+;; Use u constraint for that case to avoid the invalid value in the stack
+;; pointer.
(define_insn_and_split *addsi3_compact
[(set (match_operand:SI 0 arith_reg_dest =r,u)
(plus:SI (match_operand:SI 1 arith_operand %0,r)
@@ -2078,7 +2079,11 @@
! reg_overlap_mentioned_p (operands[0], operands[1])
[(set (match_dup 0) (match_dup 2))
(set (match_dup 0) (plus:SI (match_dup 0) (match_dup 1)))]
-
+{
+ /* Prefer 'mov r0,r1; add #imm8,r1' over 'mov #imm8,r1; add r0,r1' */
+ if (satisfies_constraint_I08 (operands[2]))
+std::swap (operands[1], operands[2]);
+}
[(set_attr type arith)])
;; -
[SH][committed] Don't emit tstsi_t insn with const_int as first operand
Hi,
While doing some other work on the tst insns, I ran into the issue that
in sh-mem.cc the tstsi_t insn is emitted with the const_int operand
being the first operand. Normally reload fixes this afterwards, but
let's not stress that.
Tested with make -k check RUNTESTFLAGS=--target_board=sh-sim
\{-m2/-ml,-m2/-mb,-m2a/-mb,-m4/-ml,-m4/-mb,-m4a/-ml,-m4a/-mb}
and no new failures. Committed as r219342.
Cheers,
Oleg
gcc/ChangeLog:
* config/sh/sh-mem.cc: Use constant as second operand when emitting
tstsi_t insns.
Index: gcc/config/sh/sh-mem.cc
===
--- gcc/config/sh/sh-mem.cc (revision 219292)
+++ gcc/config/sh/sh-mem.cc (working copy)
@@ -228,7 +228,7 @@
if (align 4)
{
emit_insn (gen_iorsi3 (tmp1, s1_addr, s2_addr));
- emit_insn (gen_tstsi_t (GEN_INT (3), tmp1));
+ emit_insn (gen_tstsi_t (tmp1, GEN_INT (3)));
jump = emit_jump_insn (gen_branch_false (L_loop_byte));
add_int_reg_note (jump, REG_BR_PROB, prob_likely);
}
@@ -373,7 +373,7 @@
if (align 4)
{
emit_insn (gen_iorsi3 (tmp1, s1_addr, s2_addr));
- emit_insn (gen_tstsi_t (GEN_INT (3), tmp1));
+ emit_insn (gen_tstsi_t (tmp1, GEN_INT (3)));
jump = emit_jump_insn (gen_branch_false (L_loop_byte));
add_int_reg_note (jump, REG_BR_PROB, prob_likely);
}
@@ -581,7 +581,7 @@
if (align 4)
{
- emit_insn (gen_tstsi_t (GEN_INT (3), current_addr));
+ emit_insn (gen_tstsi_t (current_addr, GEN_INT (3)));
jump = emit_jump_insn (gen_branch_false (L_loop_byte));
add_int_reg_note (jump, REG_BR_PROB, prob_likely);
}
@@ -673,7 +673,7 @@
if (align 4)
{
- emit_insn (gen_tstsi_t (GEN_INT (3), dest_addr));
+ emit_insn (gen_tstsi_t (dest_addr, GEN_INT (3)));
jump = emit_jump_insn (gen_branch_false (L_loop_byte));
add_int_reg_note (jump, REG_BR_PROB, prob_likely);
}
Re: [debug-early] reuse variable DIEs and fix their context
On Sat, Dec 20, 2014 at 5:49 AM, Aldy Hernandez al...@redhat.com wrote: On 12/19/14 11:03, Jason Merrill wrote: First of all, my bad Richard. I vaguely remember you mentioning something about Java, but it was early enough in the project that I had no idea what you were talking about. Thanks for your patience. It looks like java aliases are still using assemble_alias directly; switching to using same_body aliases like thunks and such should handle the issue. Ah, I see. Attached is a patch against _MAINLINE_ that fixes the issue I am seeing, without introducing any regressions. Well, I think it's a bit late now (but only affects Java, so...). Jasons call. Would it be crazy to ask for permission to commit this into mainline, and avoiding dragging this along on the branch? If not, I have a similar patch for the branch I can commit there. Let me know. Thanks for fixing this! Richard. Thanks for everyone's input. Aldy
[RFC PATCH] Handle sequence in reg_set_p
Hi,
Currently reg_set_p doesn't handle sequence rtx, which I've identified
as the root cause of PR 64479. There is another alternative fix for the
PR, but I'd like to get some comments regarding letting reg_set_p also
handle sequence rtx:
Index: gcc/rtlanal.c
===
--- gcc/rtlanal.c (revision 218544)
+++ gcc/rtlanal.c (working copy)
@@ -875,17 +875,24 @@
{
/* We can be passed an insn or part of one. If we are passed an insn,
check if a side-effect of the insn clobbers REG. */
- if (INSN_P (insn)
- (FIND_REG_INC_NOTE (insn, reg)
- || (CALL_P (insn)
- ((REG_P (reg)
- REGNO (reg) FIRST_PSEUDO_REGISTER
- overlaps_hard_reg_set_p (regs_invalidated_by_call,
- GET_MODE (reg), REGNO (reg)))
- || MEM_P (reg)
- || find_reg_fusage (insn, CLOBBER, reg)
-return 1;
+ if (INSN_P (insn) FIND_REG_INC_NOTE (insn, reg))
+return true;
+ /* After delay slot handling, call and branch insns might be in a
+ sequence. Check all the elements there. */
+ if (INSN_P (insn) GET_CODE (PATTERN (insn)) == SEQUENCE)
+for (int i = 0; i XVECLEN (PATTERN (insn), 0); ++i)
+ if (reg_set_p (reg, XVECEXP (PATTERN (insn), 0, i)))
+ return true;
+
+ if (CALL_P (insn)
+ ((REG_P (reg) REGNO (reg) FIRST_PSEUDO_REGISTER
+ overlaps_hard_reg_set_p (regs_invalidated_by_call,
+ GET_MODE (reg), REGNO (reg)))
+ || MEM_P (reg)
+ || find_reg_fusage (insn, CLOBBER, reg)))
+ return true;
+
return set_of (reg, insn) != NULL_RTX;
}
Would that be OK to do if it passes testing, or is there something that
could potentially/obviously blow up?
Cheers,
Oleg
Re: [PATCH v3] Use strtoll instead of atoll in gcov-tool.c
On Sat, Dec 20, 2014 at 11:51 PM, John David Anglin dave.ang...@bell.net wrote: Ping. Ok. Thanks, Richard. On 24-Nov-14, at 7:38 PM, John David Anglin wrote: On 15-Sep-14, at 5:40 AM, Richard Biener wrote: Let's wait for other opinions. We now have implementations of strtol and strtoll in libiberty. So, it's better to use these than atoll. As suggested by Jakub, the patch now falls back to int64_t if the host doesn't have long long. Tested on hppa2.0w-hpux11.11 and hppa64-hp-hpux11.11. Okay for trunk? Dave -- John David Anglin dave.ang...@bell.net gcov-tool.c.d.3 Dave -- John David Anglin dave.ang...@bell.net
Re: [match-and-simplify] Remove printing for expression
On Sun, 21 Dec 2014, Prathamesh Kulkarni wrote: Hi, I removed printing for expression: from print_matches. I think it is out of place tvim here and we call print_matches after lowering. OK to commit ? Hum, it's now a very simple wrapper around print_operand - why not replace the two callers with its content? Thanks, Richard. Thanks, Prathamesh -- Richard Biener rguent...@suse.de SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton HRB 21284 (AG Nuernberg)
Re: #pragma GCC unroll support
On Mon, Dec 22, 2014 at 10:13 PM, Mike Stump mikest...@comcast.net wrote: So, I have a rough cut of a new feature to add pragma GCC unroll support to gcc. It is safe wrt the test suite and code-gen, but there are some corners that I need help or suggestions on how to round off nicely. Things to think about, can we put this in even if we have TODO support for C++ template support? I think that is only 2-5 lines away from completion, but one needs to play peak-a-boo with some data (the unroll count) and I wanted to let pt fingers decide where to hide the data. See RANGE_FOR_IVDEP for how I want to do it. Can I increase the size of all annotations to 3 from 2? It seemed safer, easier than trying to subdivide it. Sure. But I'd make the 2nd operand optional (thus use NULL_TREE, not integer_zero_node for existing builds). You also need to check that 'unroll' fits in the target integer_type_node (consider AVR!) and otherwise diagnose it. The 'unroll' member in struct loop should be unsigned (or you need to document what negative values are supposed to mean). It also should be smaller than int (struct loop may be heavily used), possibly short or even (un)signed char(?). @@ -341,7 +341,10 @@ tree_estimate_loop_size (struct loop *lo if (likely_eliminated || likely_eliminated_last) size-last_iteration_eliminated_by_peeling += num; } - if ((size-overall * 3 / 2 - size-eliminated_by_peeling + /* A loop that we want to unroll is never too large. */ + if (loop-unroll 0) + ; but if we end up unrolling more than loop-unroll then it may be too large? That is this check should be in the caller, not here. I think you miss updating copy_loop_info (and places where we don't use that but still copy loops somehow). I didn’t engineer ivdeps and unroll together. Does it sound reasonable to allow both to be used at the same time on the same loop? If so, I can add the two other cases, presently I just handle one of them then the loop. Yes. Fortran support is left to the fortran people, if they want to do it. I wired it up tantalizingly close for them to complete. See ICK in the code. I was unsure how to resolve that code. Does unroll 8 mean that the loop is repeated 8 times? Up to you to define - what do other compilers do for #pragma unroll 0 and #pragma unroll 1? Can I turn on peeling in try_peel_loop by simply wanted to do it for 1 loop? ? I support using -1 for a directive that says, don’t peel, don’t unroll. As a UI issue, I think this is wrong. I want to to be either 0 or 1, those two seem better. But, not sure which is the right one of the two. Which number says, don’t unroll, I’m smarter than you think. #pragma unroll 0 or #pragma nounroll what do other compilers do? If we have a loop that we know can only be unroll 7 times, and the user says unroll 8, should we unroll it 7 times? Presently I do. The other option, is to ignore the directive when we know it is non-sensicle. Yes, unroll 7 times. Yes, I’m aware that this isn’t the right phase for this, but such are business cycles. It would not go in until we reenter stage 1. I see no value in trying to squeeze it in past stage 1. The interesting parts are mostly frontend stuff, the middle-end bits look fine apart from the above issues (it feels like you need to add too many checks for loop-unroll in the peeler...) Richard.
Re: [Ada] Fix bootstrapping on darwin9/10 (PR ada/64349).
Hi Tristan, On 7 Jan 2015, at 10:15, Arnaud Charlet wrote: Use _NSGetEnviron to get environment. Tested on x86_64-pc-linux-gnu, committed on trunk 2015-01-07 Tristan Gingold ging...@adacore.com PR ada/64349 * env.c (__gnat_environ): Adjust for darwin9/darwin10. difs.txt So my original patch assumed that, while it was not legal to use environ from a shlib, it is legal to use _NSGetEnviron () from an application ... .. and, OK fine, I see the point about ! defined (__arm__) .. but a few other comments. ISTM that there's a partial implementation to distinguish between IN_RTS and application? Index: env.c === --- env.c (revision 219191) +++ env.c (working copy) @@ -44,6 +44,12 @@ #include stdlib.h #endif +#if defined (__APPLE__) !defined (__arm__) +/* On Darwin, _NSGetEnviron must be used for shared libraries; but it is not + available on iOS. */ +#include crt_externs.h +#endif + This definition ^ fires for IN_RTS ... ... but there's no definition of _NSGetEnviron in the other branch unless it happens to get pulled in via config.h / system.h - I don't know that this is guaranteed, do you? #if defined (__vxworks) #if defined (__RTP__) /* On VxWorks 6 Real-Time process mode, environ is defined in unistd.h. */ @@ -212,6 +218,8 @@ #elif ! (defined (__vxworks)) extern char **environ; return environ; ^ I don't expect __vxworks to be defined for a Darwin compiler ... .. so not sure what the code below will achieve. +#elif defined (__APPLE__) !defined (__arm__) + return *_NSGetEnviron (); ^ here you use _NSGetEnviron () unconditionally (see comment re. IN_RTS). #else return environ; #endif If we want to distinguish between in IN_RTS and application maybe sth pseudo-code like: if IN_RTS if apple ! arm include crt_externals.h define environ (*_ _NSGetEnviron ()) end else if apple and ! arm extern C char ** environ; end end .. amend the vxworks case ... +#elif defined (__APPLE__) !defined (__arm__) + return environ; Am I missing some point here? Iain
Re: [C++ Patch] PR 60753
OK. Jason
Re: [4.8] Request to backport patch to the 4.8 branch
On Wed, 24 Dec 2014, Bin.Cheng wrote:
On Wed, Dec 24, 2014 at 4:35 PM, zhangjian bamvor.zhangj...@huawei.com
wrote:
Hi, guys
I encounter a gcc failure when I build mysql on opensuse[1]
5.6.17/storage/perfschema/pfs_account.cc:320:1: error: could not split insn
[ 1245s] }
[ 1245s] ^
[ 1245s] (insn 482 1770 1461 (parallel [
[ 1245s] (set (reg:SI 1 x1 [orig:167 D.16835 ] [167])
[ 1245s] (mem/v:SI (reg/f:DI 0 x0 [orig:166 D.16844 ]
[166]) [-1 S4 A32]))
[ 1245s] (set (mem/v:SI (reg/f:DI 0 x0 [orig:166 D.16844 ]
[166]) [-1 S4 A32])
[ 1245s] (unspec_volatile:SI [
[ 1245s] (ior:SI (mem/v:SI (reg/f:DI 0 x0 [orig:166
D.16844 ] [166]) [-1 S4 A32])
[ 1245s] (const_int 0 [0]))
[ 1245s] (const_int 5 [0x5])
[ 1245s] ] UNSPECV_ATOMIC_OP))
[ 1245s] (clobber (reg:CC 66 cc))
[ 1245s] (clobber (reg:SI 4 x4))
[ 1245s] (clobber (reg:SI 3 x3))
[ 1245s] ])
/home/abuild/rpmbuild/BUILD/mysql-5.6.17/include/my_atomic.h:217 1814
{atomic_fetch_orsi}
[ 1245s] (expr_list:REG_UNUSED (reg:CC 66 cc)
[ 1245s] (expr_list:REG_UNUSED (reg:SI 4 x4)
[ 1245s] (expr_list:REG_UNUSED (reg:SI 3 x3)
[ 1245s] (nil)
[ 1245s]
/home/abuild/rpmbuild/BUILD/mysql-5.6.17/storage/perfschema/pfs_account.cc:320:1:
internal compiler error: in final_scan_insn, at final.c:2897
Ihis bug could be fixed by Michael's patch(r217076):
2014-11-04 Michael Collison michael.colli...@linaro.org
* config/aarch64/iterators.md (lconst_atomic): New mode attribute
to support constraints for CONST_INT in atomic operations.
* config/aarch64/atomics.md
(atomic_atomic_optabmode): Use lconst_atomic constraint.
(atomic_nandmode): Likewise.
(atomic_fetch_atomic_optabmode): Likewise.
(atomic_fetch_nandmode): Likewise.
(atomic_atomic_optab_fetchmode): Likewise.
(atomic_nand_fetchmode): Likewise.
Michael's patch could be applied on the top of gcc 4.8 branch except the
gcc/ChangeLog.
Is it possible backport this patch to gcc 4.8 branch?
I am new to here, I am not sure if I need send the patch with modified
ChangeLog. Sorry if I break the rules.
Hi,
Since the patch applies to 4.8 smoothly, and you already provided the
revision number, I don't think an additional patch is needed. But is
the original patch for an existing bug? And what's about gcc 4_9
branch? Maybe you can create a PR against 4.8 (or 4.9) for tracking.
Another problem is you may need to wait for a while since it's holiday
time.
The 4.9 branch also doesn't have this patch, so it needs to be applied
there, too. It's of course up to the AARCH64 maintainers to decide.
Generally please always think of the FSF release branches when fixing
bugs (not only about your linaro branches).
Thanks,
Richard.
Thanks,
bin
regards
bamvor
[1] https://bugzilla.opensuse.org/show_bug.cgi?id=896667
--
Richard Biener rguent...@suse.de
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Jennifer Guild,
Dilip Upmanyu, Graham Norton HRB 21284 (AG Nuernberg)
[patch committed SH] Fix PR target/64533
I've committed the attached patch to fix PR target/64533 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64533 which is a 5.0 regression. Splitting rA := rB + N to rA := N and rA := rA + rB isn't safe when rA is the stack pointer. If someone interrupts between these 2 set insns, we could see a bad value in the stack pointer. I've got a few sporadic and unreproducible errors in libjava testsuite on sh-linux because of this. The attached one liner is to avoid that splitting when rA is the stack pointer. Tested on sh4-unknown-linux-gnu with no new failures. Regards, kaz -- 2015-01-08 Kaz Kojima kkoj...@gcc.gnu.org PR target/64533 * config/sh/sh.md (*addsi3_compact): Use u constraint instead of r for the second alternative of the destination operand. diff --git a/gcc/config/sh/sh.md b/gcc/config/sh/sh.md index 37d2a20..6e0b97f 100644 --- a/gcc/config/sh/sh.md +++ b/gcc/config/sh/sh.md @@ -2061,9 +2061,10 @@ ;; The problem is that LRA expects something like ;;(set rA (plus rB (const_int N))) ;; to work. We can do that, but we have to split out an additional reg-reg -;; copy before the actual add insn. +;; copy before the actual add insn. Use u constraint for that case to avoid +;; the invalid value in the stack pointer. (define_insn_and_split *addsi3_compact - [(set (match_operand:SI 0 arith_reg_dest =r,r) + [(set (match_operand:SI 0 arith_reg_dest =r,u) (plus:SI (match_operand:SI 1 arith_operand %0,r) (match_operand:SI 2 arith_or_int_operand rI08,rn)))] TARGET_SH1
Re: [PATCH] Don't make all MEM_REFs with TREE_READONLY arguments TREE_READONLY (PR sanitizer/64336)
On Tue, 6 Jan 2015, Jakub Jelinek wrote:
On Wed, Dec 17, 2014 at 03:28:15PM +0100, Richard Biener wrote:
On Wed, 17 Dec 2014, Jakub Jelinek wrote:
Hi!
MEM_REF (the only tcc_reference code with 2 operands) has TREE_READONLY
set
whenever all the arguments are TREE_READONLY, which is wrong, if the
pointer/reference is read-only, it doesn't say anything about whether
what it points to is also read-only.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok
for
trunk?
Thinking about this some more I think that we should instead do sth like
read_only = 1;
side_effects = TREE_SIDE_EFFECTS (t);
if (code == MEM_REF)
{
if (TREE_CODE (arg0) == ADDR_EXPR)
{
tree t = arg0;
PROCESS_ARG (0);
}
else
read_only = 0;
This doesn't work, PROCESS_ARG among other things assigns the arguments,
computing the flags is just one thing. So the above would crash if arg0 is
NULL (also happens), and if it is ADDR_EXPR would attempt to assign
TREE_OPERANDS (arg0, 0) = arg0; and otherwise leave the argument NULL.
Here is a new version of the patch, the flags should be preinitialized to
0 by make_node_stat, so can be assigned for *MEM_REFs only if arg0 is
ADDR_EXPR, 0 is right otherwise for both flags. In generic code MEM_REF
is the only 2 operand tcc_reference, but C++ FE has some further ones,
so I need to keep the old TREE_THIS_VOLATILE assignment. There are no
5 operand tcc_references beyond TARGET_MEM_REF, but I'd keep it this way
as is anyway.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
Ok.
Thanks,
Richard.
2015-01-06 Jakub Jelinek ja...@redhat.com
PR sanitizer/64336
* tree.c (build2_stat): Fix up initialization of TREE_READONLY
and TREE_THIS_VOLATILE for MEM_REFs.
(build5_stat): Fix up initialization of TREE_READONLY and
TREE_THIS_VOLATILE for TARGET_MEM_REFs.
--- gcc/tree.c.jj 2015-01-05 13:07:15.0 +0100
+++ gcc/tree.c2015-01-06 12:33:46.466016025 +0100
@@ -4358,12 +4358,24 @@ build2_stat (enum tree_code code, tree t
PROCESS_ARG (0);
PROCESS_ARG (1);
- TREE_READONLY (t) = read_only;
- TREE_CONSTANT (t) = constant;
TREE_SIDE_EFFECTS (t) = side_effects;
- TREE_THIS_VOLATILE (t)
-= (TREE_CODE_CLASS (code) == tcc_reference
-arg0 TREE_THIS_VOLATILE (arg0));
+ if (code == MEM_REF)
+{
+ if (arg0 TREE_CODE (arg0) == ADDR_EXPR)
+ {
+ tree o = TREE_OPERAND (arg0, 0);
+ TREE_READONLY (t) = TREE_READONLY (o);
+ TREE_THIS_VOLATILE (t) = TREE_THIS_VOLATILE (o);
+ }
+}
+ else
+{
+ TREE_READONLY (t) = read_only;
+ TREE_CONSTANT (t) = constant;
+ TREE_THIS_VOLATILE (t)
+ = (TREE_CODE_CLASS (code) == tcc_reference
+ arg0 TREE_THIS_VOLATILE (arg0));
+}
return t;
}
@@ -4458,9 +4470,19 @@ build5_stat (enum tree_code code, tree t
PROCESS_ARG (4);
TREE_SIDE_EFFECTS (t) = side_effects;
- TREE_THIS_VOLATILE (t)
-= (TREE_CODE_CLASS (code) == tcc_reference
-arg0 TREE_THIS_VOLATILE (arg0));
+ if (code == TARGET_MEM_REF)
+{
+ if (arg0 TREE_CODE (arg0) == ADDR_EXPR)
+ {
+ tree o = TREE_OPERAND (arg0, 0);
+ TREE_READONLY (t) = TREE_READONLY (o);
+ TREE_THIS_VOLATILE (t) = TREE_THIS_VOLATILE (o);
+ }
+}
+ else
+TREE_THIS_VOLATILE (t)
+ = (TREE_CODE_CLASS (code) == tcc_reference
+ arg0 TREE_THIS_VOLATILE (arg0));
return t;
}
Jakub
--
Richard Biener rguent...@suse.de
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Jennifer Guild,
Dilip Upmanyu, Graham Norton HRB 21284 (AG Nuernberg)
Re: RFC: C++ PATCH to do bounds sanitation for VLA initialization
On Wed, Jan 07, 2015 at 11:56:58PM -0500, Jason Merrill wrote:
My recent patch to remove the C++ VLA semantics that didn't make it into
C++14 missed a couple of spots. While I was looking at that I noticed that
we weren't sanitizing VLA initialization, which we ought to do; this patch
implements that. Marek, does my choice of VLA|BOUNDS make sense to you?
I think that should be just BOUNDS. VLA sanitization will still catch
the case if the size of a VLA is not positive, e.g.
int i = -1;
int a[i] = { 1, 2, 3};
Marek
[hsa] Fix wrong conversion ode and verification fallout
Hi,
the following patch fixes three different minor problems. It makes us
produce the rounding flag required by HSAIL specification when
converting an integer to a floating point type, not ICE on an
invariant in a return gimple statement and relax verification so that
it is OK with HSA SSA names originating from default-def gimple SSA
names which are not parameters not having a definition.
Committed to the branch. Thanks,
Martin
2015-01-08 Martin Liska mli...@suse.cz
Martin Jambor mjam...@suse.cz
* hsa-brig.c (emit_cvt_insn): Add near rounding for integer to
float conversion instruction.
* hsa-gen.c (hsa_op_reg::verify): Accept registers corresponding to
default definition SSA_NAMEs.
(gen_hsa_insns_for_return): Use the correct hsa operand creation
function.
diff --git a/gcc/hsa-brig.c b/gcc/hsa-brig.c
index 45972b6..0de9aab 100644
--- a/gcc/hsa-brig.c
+++ b/gcc/hsa-brig.c
@@ -1264,8 +1264,10 @@ emit_cvt_insn (hsa_insn_basic *insn)
/* float to smaller float requires a rounding setting (we default
to 'near'. */
- if (float_type_p (insn-type) float_type_p (srctype)
- (insn-type BRIG_TYPE_BASE_MASK) (srctype BRIG_TYPE_BASE_MASK))
+ if (float_type_p (insn-type)
+ (!float_type_p (srctype)
+ || ((insn-type BRIG_TYPE_BASE_MASK)
+ (srctype BRIG_TYPE_BASE_MASK
repr.modifier = BRIG_ROUND_FLOAT_NEAR_EVEN;
else
repr.modifier = 0;
diff --git a/gcc/hsa-gen.c b/gcc/hsa-gen.c
index 273af15..58247d3 100644
--- a/gcc/hsa-gen.c
+++ b/gcc/hsa-gen.c
@@ -585,7 +585,15 @@ hsa_alloc_immed_op (tree tree_val)
void
hsa_op_reg::verify ()
{
- gcc_checking_assert (def_insn);
+ /* Verify that each HSA register has a definition assigned.
+ Exceptions are VAR_DECL and PARM_DECL that are a default
+ definition. */
+ gcc_checking_assert (def_insn
+ || (gimple_ssa != NULL
+ (!SSA_NAME_VAR (gimple_ssa)
+ || (TREE_CODE (SSA_NAME_VAR (gimple_ssa))
+ != PARM_DECL))
+ SSA_NAME_IS_DEFAULT_DEF (gimple_ssa)));
}
/* Allocate, clear and return a hsa_op_reg. */
@@ -1785,7 +1793,8 @@ gen_hsa_insns_for_return (gimple stmt, hsa_bb *hbb,
{
/* Store of return value. */
hsa_insn_mem *mem = hsa_alloc_mem_insn ();
- hsa_op_reg *src = hsa_reg_for_gimple_ssa (retval, ssa_map);
+ hsa_op_base *src = hsa_reg_or_immed_for_gimple_op (retval, hbb, ssa_map,
+mem);
hsa_op_address *addr = hsa_alloc_addr_op (hsa_cfun.output_arg, NULL, 0);
mem-opcode = BRIG_OPCODE_ST;
[patch] Use std::__bool_constant instead of duplicating it
This is a tiny patch to use the new __bool_constant helper in
hashtable_policy.h instead of defining another identical alias.
Tested x86_64-linux, committed to trunk.
commit 3fa3e0af59fa4371f61e95eeaab240d3b974b62e
Author: Jonathan Wakely jwak...@redhat.com
Date: Wed Apr 16 18:20:30 2014 +0100
* include/bits/hashtable_policy.h: Use __bool_constant.
diff --git a/libstdc++-v3/include/bits/hashtable_policy.h b/libstdc++-v3/include/bits/hashtable_policy.h
index 1251ef0..14bcca6 100644
--- a/libstdc++-v3/include/bits/hashtable_policy.h
+++ b/libstdc++-v3/include/bits/hashtable_policy.h
@@ -81,7 +81,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
// Helper type used to detect whether the hash functor is noexcept.
template typename _Key, typename _Hash
-struct __is_noexcept_hash : std::integral_constantbool,
+struct __is_noexcept_hash : std::__bool_constant
noexcept(declvalconst _Hash()(declvalconst _Key()))
{ };
@@ -211,9 +211,6 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
templatebool _Cache_hash_code, bool _Constant_iterators, bool _Unique_keys
struct _Hashtable_traits
{
- templatebool _Cond
- using __bool_constant = integral_constantbool, _Cond;
-
using __hash_cached = __bool_constant_Cache_hash_code;
using __constant_iterators = __bool_constant_Constant_iterators;
using __unique_keys = __bool_constant_Unique_keys;
Re: [RFA:] Fix test-suite regressions from PR62250 due to -latomic always added
On 2015-01-07, at 9:32 PM, Hans-Peter Nilsson wrote: gcc/testsuite: PR testsuite/62250 * lib/target-supports.exp (check_effective_target_libatomic_available): New. * gfortran.dg/coarray/caf.exp: Only add -latomic for targets that match effective-target libatomic_available. * gfortran.dg/coarray_lib_comm_1.f90: Similar. Works for me on hppa64-hp-hpux11.11. Dave -- John David Anglin dave.ang...@bell.net
Re: [gofrontend-dev] [PATCH 1/2, libgo] Add reflection support to gccgo for ppc64, ppc64le in gcc 4.9
If this change is not included, in the gcc go testsuite, the recover.go
testcase fails with this error:
panic: reflect.makeMethodValue not implemented for ppc64le
when running this test:
func test9reflect1() {
f := reflect.ValueOf(T1{}).Method(0).Interface().(func())
defer f()
panic(9)
}
Also as was noted below, some level of reflection support is needed to
build Docker. I was given this patch by someone in IBM trying to build
Docker on Power who told me it was needed (but didn't really know the
details). There is interest in trying to get Docker to build with gcc
4.9 because 5.0 won't be available in distros for a while yet. I was
told that the minimal reflection support provided by this patch was
enough to get it to build. But if a simple workaround in the Docker
source will make it work that might be sufficient. I'll find out. Thanks.
On 01/07/2015 07:20 PM, Ian Lance Taylor wrote:
On Wed, Jan 7, 2015 at 4:39 PM, Michael Hudson-Doyle
michael.hud...@canonical.com wrote:
Ian Lance Taylor i...@golang.org writes:
On Wed, Jan 7, 2015 at 9:26 AM, Lynn A. Boger
labo...@linux.vnet.ibm.com wrote:
In libgo/go/reflect/makefunc.go, calls to MakeFunc, makeMethodValue and
makeValueMethod will panic if called when GOARCH is ppc64 or ppc64le.
Right, I'm just saying that almost no code actually does that. I just
tried a web search and found no uses other than examples of how to use
it. I'm sure there are a few, but not many.
There is a somewhat hidden one in Docker:
https://github.com/docker/docker/blob/master/api/client/cli.go#L64
(it is also possible to patch docker to do this differently, of course).
Ah, so that is why it matters.
Perhaps you could talk Docker into replace the return statement with
return func(a ...string) error {
return
method.CallSlice([]reflect.Value{reflect.ValueOf(a)})[0].Interface().(error)
}, true
It would probably be just as efficient.
Ian
Re: [Ada] Fix bootstrapping on darwin9/10 (PR ada/64349).
On 08 Jan 2015, at 13:49, Iain Sandoe i...@codesourcery.com wrote: Hi Tristan, On 7 Jan 2015, at 10:15, Arnaud Charlet wrote: Use _NSGetEnviron to get environment. Tested on x86_64-pc-linux-gnu, committed on trunk 2015-01-07 Tristan Gingold ging...@adacore.com PR ada/64349 * env.c (__gnat_environ): Adjust for darwin9/darwin10. difs.txt So my original patch assumed that, while it was not legal to use environ from a shlib, it is legal to use _NSGetEnviron () from an application ... .. and, OK fine, I see the point about ! defined (__arm__) .. but a few other comments. ISTM that there's a partial implementation to distinguish between IN_RTS and application? Yes you're right. The added code should have been added after the #endif for IN_RTS. I will fix that. Current code should compile, possibly with warnings. Tristan.
Re: LTO streaming of TARGET_OPTIMIZE_NODE
On Thu, Nov 20, 2014 at 01:27:08PM +0100, Bernd Schmidt wrote:
On 11/13/2014 05:06 AM, Jan Hubicka wrote:
this patch adds infrastructure for proper streaming and merging of
TREE_TARGET_OPTION.
This breaks the offloading path via LTO since it introduces an
incompatibility in LTO format between host and offload machine.
A very quick patch to fix it is below - the OpenACC testcase I was using
seems to be working again with this. Thoughts, suggestions?
I actually think this patch makes a lot of sense. Target option nodes
by definition are target specific, generally there is no mapping between
host and offloading target features. So, the host target options
are not useful to the offloading target. And, because the amount of bits
streamed is also target specific, say x86_64 will have different and
incompatible cl_target_option_stream_{out,in} from nvptx, and even
for Intel MIC offloading it doesn't make much sense, what CPU is certain
function targetting doesn't necessarily have any relation to the Intel MIC
that will offload it.
I agree the strcmp (section_name_prefix, LTO_SECTION_NAME_PREFIX) == 0
checks in the patch aren't very nice, that could be replaced by
some bool flag alongside of section_name_prefix that would be set
where section_name_prefix is set:
cgraphunit.c: section_name_prefix = OFFLOAD_SECTION_NAME_PREFIX;
cgraphunit.c: section_name_prefix = LTO_SECTION_NAME_PREFIX;
lto-streamer.c:const char *section_name_prefix = LTO_SECTION_NAME_PREFIX;
lto/lto.c:section_name_prefix = OFFLOAD_SECTION_NAME_PREFIX;
(call it say bool lto_stream_offload_p ?).
Also note that the patch fixes all the current regressions in Intel MIC
(emulated) offloading caused by the r218767
Jakub
[PATCH] Small step towards tree-ssa-strlen improvements (PR tree-optimization/63989)
Hi!
This patch is a small step towards fixing that PR that I had sitting on my
disk for quite a while, but didn't get to further steps so far.
I'll try to at least get to the multibyte memcpy/memmove expanded as
load followed by store, if the '\0' is known not to appear at all, or
known to appear on the last byte, or on the first byte during stage4,
but this part is self-contained enough that it should go in independently.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2015-01-08 Jakub Jelinek ja...@redhat.com
PR tree-optimization/63989
* params.def (PARAM_MAX_TRACKED_STRLENS): Increment default
from 1000 to 1.
* tree-ssa-strlen.c (get_strinfo): Moved earlier.
(get_stridx): If we don't have a record for certain SSA_NAME,
but it is POINTER_PLUS_EXPR of some SSA_NAME we do with
constant offset, call get_stridx_plus_constant.
(get_stridx_plus_constant): New function.
(zero_length_string): Don't use get_stridx here.
* gcc.dg/strlenopt-27.c: New test.
--- gcc/params.def.jj 2015-01-06 16:14:11.439103073 +0100
+++ gcc/params.def 2015-01-08 18:23:36.305200712 +0100
@@ -1078,7 +1078,7 @@ DEFPARAM (PARAM_MAX_TRACKED_STRLENS,
max-tracked-strlens,
Maximum number of strings for which strlen optimization pass will
track string lengths,
- 1000, 0, 0)
+ 1, 0, 0)
/* Keep this in sync with the sched_pressure_algorithm enum. */
DEFPARAM (PARAM_SCHED_PRESSURE_ALGORITHM,
--- gcc/tree-ssa-strlen.c.jj2015-01-06 16:14:11.379104086 +0100
+++ gcc/tree-ssa-strlen.c 2015-01-08 18:41:42.351763774 +0100
@@ -181,6 +181,18 @@ struct laststmt_struct
int stridx;
} laststmt;
+static int get_stridx_plus_constant (strinfo, HOST_WIDE_INT, tree);
+
+/* Return strinfo vector entry IDX. */
+
+static inline strinfo
+get_strinfo (int idx)
+{
+ if (vec_safe_length (stridx_to_strinfo) = (unsigned int) idx)
+return NULL;
+ return (*stridx_to_strinfo)[idx];
+}
+
/* Helper function for get_stridx. */
static int
@@ -219,7 +231,43 @@ get_stridx (tree exp)
tree s, o;
if (TREE_CODE (exp) == SSA_NAME)
-return ssa_ver_to_stridx[SSA_NAME_VERSION (exp)];
+{
+ if (ssa_ver_to_stridx[SSA_NAME_VERSION (exp)])
+ return ssa_ver_to_stridx[SSA_NAME_VERSION (exp)];
+ int i;
+ tree e = exp;
+ HOST_WIDE_INT off = 0;
+ for (i = 0; i 5; i++)
+ {
+ gimple def_stmt = SSA_NAME_DEF_STMT (e);
+ if (!is_gimple_assign (def_stmt)
+ || gimple_assign_rhs_code (def_stmt) != POINTER_PLUS_EXPR)
+ return 0;
+ tree rhs1 = gimple_assign_rhs1 (def_stmt);
+ tree rhs2 = gimple_assign_rhs2 (def_stmt);
+ if (TREE_CODE (rhs1) != SSA_NAME
+ || !tree_fits_shwi_p (rhs2))
+ return 0;
+ HOST_WIDE_INT this_off = tree_to_shwi (rhs2);
+ if (this_off 0)
+ return 0;
+ off = (unsigned HOST_WIDE_INT) off + this_off;
+ if (off 0)
+ return 0;
+ if (ssa_ver_to_stridx[SSA_NAME_VERSION (rhs1)])
+ {
+ strinfo si
+ = get_strinfo (ssa_ver_to_stridx[SSA_NAME_VERSION (rhs1)]);
+ if (si
+ si-length
+ TREE_CODE (si-length) == INTEGER_CST
+ compare_tree_int (si-length, off) != -1)
+ return get_stridx_plus_constant (si, off, exp);
+ }
+ e = rhs1;
+ }
+ return 0;
+}
if (TREE_CODE (exp) == ADDR_EXPR)
{
@@ -388,16 +436,6 @@ free_strinfo (strinfo si)
pool_free (strinfo_pool, si);
}
-/* Return strinfo vector entry IDX. */
-
-static inline strinfo
-get_strinfo (int idx)
-{
- if (vec_safe_length (stridx_to_strinfo) = (unsigned int) idx)
-return NULL;
- return (*stridx_to_strinfo)[idx];
-}
-
/* Set strinfo in the vector entry IDX to SI. */
static inline void
@@ -555,7 +593,7 @@ maybe_invalidate (gimple stmt)
return nonempty;
}
-/* Unshare strinfo record SI, if it has recount 1 or
+/* Unshare strinfo record SI, if it has refcount 1 or
if stridx_to_strinfo vector is shared with some other
bbs. */
@@ -605,6 +643,82 @@ verify_related_strinfos (strinfo origsi)
return si;
}
+/* Attempt to create a new strinfo for BASESI + OFF, or find existing
+ strinfo if there is any. Return it's idx, or 0 if no strinfo has
+ been created. */
+
+static int
+get_stridx_plus_constant (strinfo basesi, HOST_WIDE_INT off, tree ptr)
+{
+ gcc_checking_assert (TREE_CODE (ptr) == SSA_NAME);
+
+ if (SSA_NAME_OCCURS_IN_ABNORMAL_PHI (ptr))
+return 0;
+
+ if (basesi-length == NULL_TREE
+ || TREE_CODE (basesi-length) != INTEGER_CST
+ || compare_tree_int (basesi-length, off) == -1
+ || !tree_fits_shwi_p (basesi-length))
+return 0;
+
+ HOST_WIDE_INT len = tree_to_shwi (basesi-length) - off;
+ strinfo si = basesi, chainsi;
+ if
Re: [Patch, Fortran] Fix previous patch
Paul Richard Thomas wrote: It looks to me as if you had to do a fair amount of detective work there! The patch is OK for trunk. Thanks for the review - which didn't make it to mailing list for some reasons (text+HTML email?). Committed as Rev. 219354 Tobias Thanks for your efforts Paul On 7 January 2015 at 22:37, Tobias Burnus bur...@net-b.de mailto:bur...@net-b.de wrote: Early PING: https://gcc.gnu.org/ml/gcc-patches/2015-01/msg00090.html Tobias Burnus wrote: Attached is a regtested patch, which fixes the issue. Additionally, the variable visibility (TREE_PUBLIC) is now depending on the private attribute (copied from the module var generation) and I mark the tree as DECL_NONALIASED. The former I also did for proc-pointers, which is an unrelated patch. Build and regtested on x86-64-gnu-linux. OK for the trunk? Dominique d'Humières wrote: Compilation with the new patch fails with ../../work/gcc/fortran/trans-decl.c: In function 'void gfc_build_qualified_array(tree, gfc_symbol*)': ../../work/gcc/fortran/trans-decl.c:855:25: error: 'cur_module' was not declared in this scope gfc_module_add_decl (cur_module, token); Which shows that w/o compiling and testing, one (usually) cannot write patches. Solution is to move the declaration up in the file. However, it turned out that that's not sufficient: the pushdecl is required. Tobias Le 3 janv. 2015 à 23:30, Tobias Burnus bur...@net-b.de mailto:bur...@net-b.de a écrit : Dominique d'Humières wrote: From a quick test, with the patch I still see the error with -m32 It helps if one actually adds the decl. The following (still untested) should help. I also marked the token as nonaliasing (it really should!) and added for proc pointers the tree-public optimization. Tobias foo.diff -- Outside of a dog, a book is a man's best friend. Inside of a dog it's too dark to read. Groucho Marx
Re: [PATCH] Fix ix86_expand_int_movcc (PR target/64338)
On Thu, Jan 8, 2015 at 6:09 PM, Jakub Jelinek ja...@redhat.com wrote:
Hi!
The recent ifcvt changes result in movcc being attempted with
comparisons like (ltgt (reg:CCFPU flags) (const_int 0)).
I see several issues with the current ix86_expand_int_movcc code:
1) the code was unprepared to handle *reverse_condition* failures
(returns of UNKNOWN)
2) for CCFP/CCFPU modes, I think it should be treated like scalar
float comparisons, ix86_reverse_condition seems to do the job here
3) compare_code in the second hunk was a dead computation, because
the variable is not used afterwards until it is unconditionally overwritten
(set to UNKNOWN).
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2015-01-08 Jakub Jelinek ja...@redhat.com
PR target/64338
* config/i386/i386.c (ix86_expand_int_movcc): Don't reverse
compare_code when it is unconditionally overwritten afterwards.
Use ix86_reverse_condition instead of reverse_condition. Don't
change code if *reverse_condition* returned UNKNOWN and don't
swap ct/cf and negate diff in that case.
* g++.dg/opt/pr64338.C: New test.
OK with two small nits inline.
Thanks,
Uros.
--- gcc/config/i386/i386.c.jj 2015-01-06 09:14:05.0 +0100
+++ gcc/config/i386/i386.c 2015-01-07 09:59:09.297790590 +0100
@@ -20830,9 +20830,7 @@ ix86_expand_int_movcc (rtx operands[])
if (diff 0)
{
machine_mode cmp_mode = GET_MODE (op0);
-
- std::swap (ct, cf);
- diff = -diff;
+ enum rtx_code new_code;
if (SCALAR_FLOAT_MODE_P (cmp_mode))
{
@@ -20842,13 +20840,15 @@ ix86_expand_int_movcc (rtx operands[])
is not valid in general (we may convert non-trapping
condition
to trapping one), however on i386 we currently emit all
comparisons unordered. */
- compare_code = reverse_condition_maybe_unordered (compare_code);
- code = reverse_condition_maybe_unordered (code);
+ new_code = reverse_condition_maybe_unordered (code);
}
else
+ new_code = ix86_reverse_condition (code, cmp_mode);
+ if (new_code != UNKNOWN)
{
- compare_code = reverse_condition (compare_code);
- code = reverse_condition (code);
+ code = new_code;
+ std::swap (ct, cf);
+ diff = -diff;
Please put std::swap at the top, above code= assignment. Cosmetic, but
I noticed this during std::swap conversion. ;)
}
}
@@ -20986,9 +20986,7 @@ ix86_expand_int_movcc (rtx operands[])
if (cf == 0)
{
machine_mode cmp_mode = GET_MODE (op0);
-
- cf = ct;
- ct = 0;
+ enum rtx_code new_code;
if (SCALAR_FLOAT_MODE_P (cmp_mode))
{
@@ -20998,14 +20996,21 @@ ix86_expand_int_movcc (rtx operands[])
that is not valid in general (we may convert non-trapping
condition to trapping one), however on i386 we currently
emit all comparisons unordered. */
- code = reverse_condition_maybe_unordered (code);
+ new_code = reverse_condition_maybe_unordered (code);
}
else
{
- code = reverse_condition (code);
- if (compare_code != UNKNOWN)
+ new_code = ix86_reverse_condition (code, cmp_mode);
+ if (compare_code != UNKNOWN new_code != UNKNOWN)
compare_code = reverse_condition (compare_code);
}
+
+ if (new_code != UNKNOWN)
+ {
+ code = new_code;
+ cf = ct;
+ ct = 0;
+ }
}
if (compare_code != UNKNOWN)
--- gcc/testsuite/g++.dg/opt/pr64338.C.jj 2015-01-07 10:18:04.740275018
+0100
+++ gcc/testsuite/g++.dg/opt/pr64338.C 2015-01-07 10:17:50.0 +0100
@@ -0,0 +1,29 @@
+// PR target/64338
+// { dg-do compile }
+// { dg-options -O2 }
+// { dg-additional-options -mtune=generic -march=i586 { target { {
i?86-*-* x86_64-*-* } ia32 } } }
Please use -mtune=i686, generic tuning setting changes over time ...
+enum O {};
+struct A { A (); };
+struct B { int fn1 (); };
+struct C { struct D; D *fn2 (); void fn3 (); int fn4 (); };
+struct F { void fn5 (const int = 0); };
+struct G { F *fn6 (); };
+struct H { int h; };
+struct C::D { friend class C; G *fn7 (); };
+O a;
+
+void
+C::fn3 ()
+{
+ int b = a;
+ H c;
+ if (b)
+fn2 ()-fn7 ()-fn6 ()-fn5 ();
+ double d;
+ if (fn4 ())
+d = c.h 0;
+ A e (b ? A () : A ());
+ B f;
+ f.fn1 () d fn2 ();
+}
Jakub
Re: [PATCH 1/4] Add mkoffload for Intel MIC
On Thu, Jan 8, 2015 at 6:59 AM, Thomas Schwinge tho...@codesourcery.com wrote:
Hi!
On Mon, 22 Dec 2014 12:28:20 +0100, Jakub Jelinek ja...@redhat.com wrote:
On Mon, Dec 22, 2014 at 12:25:32PM +0100, Thomas Schwinge wrote:
On Wed, 22 Oct 2014 22:57:01 +0400, Ilya Verbin iver...@gmail.com wrote:
--- /dev/null
+++ b/gcc/config/i386/intelmic-mkoffload.c
@@ -0,0 +1,541 @@
+/* Offload image generation tool for Intel MIC devices.
+/* Shows if we should compile binaries for i386 instead of x86-64. */
+bool target_ilp32 = false;
My linker defaults to 32-bit x86, so I explicitly have to switch to
64-bit x86_64 mode; OK to commit the following, to always explicitly
specify what is wanted?
gcc/config/i386/intelmic-mkoffload.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
Ok with proper ChangeLog entry.
Committed to trunk in r219345:
commit c049b358f961f72d0c0cf61a707e9a5855b12b28
Author: tschwinge tschwinge@138bc75d-0d04-0410-961f-82ee72b054a4
Date: Thu Jan 8 14:58:45 2015 +
intelmic-mkoffload: Deal with linker defaulting to 32-bit x86 mode.
... which explicitly has to be switched into 64-bit x86_64 mode.
gcc/
* config/i386/intelmic-mkoffload.c (compile_for_target): Always
add -m32 or -m64 to argv_obstack.
(generate_host_descr_file): Likewise, when invoking host_compiler.
(main): Always add -m elf_i386 or -m elf_x86_64 when invoking
ld.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@219345
138bc75d-0d04-0410-961f-82ee72b054a4
---
gcc/ChangeLog| 8
gcc/config/i386/intelmic-mkoffload.c | 12
2 files changed, 16 insertions(+), 4 deletions(-)
diff --git gcc/ChangeLog gcc/ChangeLog
index bee5f1e..01b6cc6 100644
--- gcc/ChangeLog
+++ gcc/ChangeLog
@@ -1,3 +1,11 @@
+2015-01-08 Thomas Schwinge tho...@codesourcery.com
+
+ * config/i386/intelmic-mkoffload.c (compile_for_target): Always
+ add -m32 or -m64 to argv_obstack.
+ (generate_host_descr_file): Likewise, when invoking host_compiler.
+ (main): Always add -m elf_i386 or -m elf_x86_64 when invoking
+ ld.
+
2015-01-08 Oleg Endo olege...@gcc.gnu.org
* config/sh/sh-mem.cc: Use constant as second operand when emitting
diff --git gcc/config/i386/intelmic-mkoffload.c
gcc/config/i386/intelmic-mkoffload.c
index c3d2b23..23bc955 100644
--- gcc/config/i386/intelmic-mkoffload.c
+++ gcc/config/i386/intelmic-mkoffload.c
@@ -191,6 +191,8 @@ compile_for_target (struct obstack *argv_obstack)
{
if (target_ilp32)
obstack_ptr_grow (argv_obstack, -m32);
+ else
+obstack_ptr_grow (argv_obstack, -m64);
obstack_ptr_grow (argv_obstack, NULL);
char **argv = XOBFINISH (argv_obstack, char **);
@@ -355,6 +357,8 @@ generate_host_descr_file (const char *host_compiler)
new_argv[new_argc++] = -shared;
if (target_ilp32)
new_argv[new_argc++] = -m32;
+ else
+new_argv[new_argc++] = -m64;
new_argv[new_argc++] = src_filename;
new_argv[new_argc++] = -o;
new_argv[new_argc++] = obj_filename;
@@ -511,11 +515,11 @@ main (int argc, char **argv)
unsigned new_argc = 0;
const char *new_argv[9];
new_argv[new_argc++] = ld;
+ new_argv[new_argc++] = -m;
if (target_ilp32)
-{
- new_argv[new_argc++] = -m;
- new_argv[new_argc++] = elf_i386;
-}
+new_argv[new_argc++] = elf_i386;
+ else
+new_argv[new_argc++] = elf_x86_64;
new_argv[new_argc++] = --relocatable;
new_argv[new_argc++] = host_descr_filename;
new_argv[new_argc++] = target_so_filename;
Should we also handle x32?
--
H.J.
[Patch, Fortran] PR64522 - reinstate truncation diagnostic
For fixed-form source code, it is not unusual that after the 72 columns,
comments are added - like sequence numbers with punch cards or later
code comments.
For free-form source code, that's very uncommon - especially as several
compilers do not honour the line limit of 132 characters (with default
settings).
Until and including GCC 4.4, gfortran was warning (unconditionally) when
free-form lines exceeded the line limit and got truncated. When some
additional diagnostic was introduced (PR39229, r151258, 2009-08-31), this
feature got lost. (Found by Andre - thanks!)
I think think it makes sense to have some diagnostic in this case. Either
by re-instating the warning or even by printing an error.
This patch does the latter by using the warning infrastructure.
For fixed-form source code, the result is as before:
* No warning by default
* -Wline-truncation (and -Wall) show a warning
* -Werror and -Werror=line-truncation turn it into an error
For free-form source code, the result was as above; it is now:
* By default, an error is printed ([-Werror=line-truncation])
* Using -Wall, -Wline-truncation, -Werror and -Werror=line-truncation
also yield an error.
* -Wno-error=line-truncation and -Wno-error turn the error into a
warning
* -Wno-line-truncation and -Wno-all silence the warning as well.
Build and regtested on x86-64-gnu-linux.
OK for the trunk? Or should only a warning be printed?
For GCC 4.8/4.9: Should we backport the patch (only printing the
warning, not the behaviour change)? Or given that the warning was
lost in 4.5, would it be sufficient to just modify the trunk?
Tobias
2015-01-08 Tobias Burnus bur...@net-b.de
PR fortran/64522
* invoke.texi (Wline-truncation): Document new behaviour.
* lang.opt (Wline-truncation): Add Init(-1).
* options.c (gfc_post_options): If -Wline-truncation is unset,
enable it for free-form source files; for the latter, also use
-Werror=line-truncation, unless -Wno-error has been specified.
2015-01-08 Tobias Burnus bur...@net-b.de
PR fortran/64522
* gfortran.dg/line_length_5.f90: Change dg-warning to dg-error
and add dg-excess-errors.
* gfortran.dg/line_length_6.f90: New.
* gfortran.dg/line_length_7.f90: New.
* gfortran.dg/line_length_8.f90: New.
* gfortran.dg/line_length_9.f90: New.
* gfortran.dg/line_length_10.f90: New.
* gfortran.dg/line_length_11.f90: New.
diff --git a/gcc/fortran/invoke.texi b/gcc/fortran/invoke.texi
index 4cf36e8..39bc479 100644
--- a/gcc/fortran/invoke.texi
+++ b/gcc/fortran/invoke.texi
@@ -790,7 +790,9 @@ Warn when a character assignment will truncate the assigned string.
@opindex @code{Wline-truncation}
@cindex warnings, line truncation
Warn when a source code line will be truncated. This option is
-implied by @option{-Wall}.
+implied by @option{-Wall}. For free-form source code, the default is
+@option{-Werror=line-truncation} such that truncations are reported as
+error.
@item -Wconversion
@opindex @code{Wconversion}
diff --git a/gcc/fortran/lang.opt b/gcc/fortran/lang.opt
index c4ebbe7..530ec97 100644
--- a/gcc/fortran/lang.opt
+++ b/gcc/fortran/lang.opt
@@ -250,7 +250,7 @@ Fortran Warning Var(warn_implicit_procedure)
Warn about called procedures not explicitly declared
Wline-truncation
-Fortran Warning Var(warn_line_truncation) LangEnabledBy(Fortran,Wall)
+Fortran Warning Var(warn_line_truncation) LangEnabledBy(Fortran,Wall) Init(-1)
Warn about truncated source lines
Wintrinsics-std
diff --git a/gcc/fortran/options.c b/gcc/fortran/options.c
index 24b13c1..70d4fa5 100644
--- a/gcc/fortran/options.c
+++ b/gcc/fortran/options.c
@@ -305,7 +305,20 @@ gfc_post_options (const char **pfilename)
in free form);
else if (gfc_option.flag_d_lines == 1)
gfc_warning_now (%-fd-lines-as-code% has no effect in free form);
+
+ if (warn_line_truncation == -1)
+ warn_line_truncation = 1;
+
+ /* Enable -Werror=line-truncation when -Werror and -Wno-error have
+ not been set. */
+ if (warn_line_truncation !global_options_set.x_warnings_are_errors
+ (global_dc-classify_diagnostic[OPT_Wline_truncation] ==
+ DK_UNSPECIFIED))
+ diagnostic_classify_diagnostic (global_dc, OPT_Wline_truncation,
+ DK_ERROR, UNKNOWN_LOCATION);
}
+ else if (warn_line_truncation == -1)
+warn_line_truncation = 0;
/* If -pedantic, warn about the use of GNU extensions. */
if (pedantic (gfc_option.allow_std GFC_STD_GNU) != 0)
diff --git a/gcc/testsuite/gfortran.dg/line_length_10.f90 b/gcc/testsuite/gfortran.dg/line_length_10.f90
new file mode 100644
index 000..390e9a1
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/line_length_10.f90
@@ -0,0 +1,8 @@
+! { dg-do compile }
+! { dg-options -Wno-line-truncation }
+!
+! By default, for free-form source code: Error out
+! But due to the explicit -Wno-line-truncation, compile w/o warning
+!
+ print *, 1
Re: [PATCH 3/4] Add libgomp plugin for Intel MIC
Hi!
On Fri, 12 Dec 2014 10:42:30 +0100, I wrote:
On Mon, 10 Nov 2014 17:30:38 +0300, Ilya Verbin iver...@gmail.com wrote:
--- /dev/null
+++ b/liboffloadmic/plugin/Makefile.am
@@ -0,0 +1,123 @@
+# Plugin for offload execution on Intel MIC devices.
+ AM_LDFLAGS = -L$(liboffload_dir)/.libs -L$(libgomp_dir)/.libs
-loffloadmic_target -lcoi_device -lmyo-service -lgomp -rdynamic
Given that this plugin wishes to link against libgomp, don't we have to
make sure that libgomp has actually been built before that is attempted,
and the following (untested) patch would be required?
As shown by a »make -j1« build: yes, we have to. As obvious, committed
to trunk in r219344:
commit fb5eef67f6b041cd0bc4f1f8d62c1a000d59f497
Author: tschwinge tschwinge@138bc75d-0d04-0410-961f-82ee72b054a4
Date: Thu Jan 8 14:46:22 2015 +
liboffloadmic/plugin: Depend on libgomp being built.
[...]
Making all in plugin
make[6]: Entering directory
`[...]/build-gcc-offload-x86_64-intelmicemul-linux-gnu/x86_64-intelmicemul-linux-gnu/32/liboffloadmic/plugin'
[...]
[...]/build-gcc-offload-x86_64-intelmicemul-linux-gnu/./gcc/xg++
-B[...]/build-gcc-offload-x86_64-intelmicemul-linux-gnu/./gcc/ -nostdinc++
-nostdinc++
-I[...]/build-gcc-offload-x86_64-intelmicemul-linux-gnu/x86_64-intelmicemul-linux-gnu/32/libstdc++-v3/include/x86_64-intelmicemul-linux-gnu
-I[...]/build-gcc-offload-x86_64-intelmicemul-linux-gnu/x86_64-intelmicemul-linux-gnu/32/libstdc++-v3/include
-I[...]/source-gcc/libstdc++-v3/libsupc++
-I[...]/source-gcc/libstdc++-v3/include/backward
-I[...]/source-gcc/libstdc++-v3/testsuite/util
-L[...]/build-gcc-offload-x86_64-intelmicemul-linux-gnu/x86_64-intelmicemul-linux-gnu/32/libstdc++-v3/src
-L[...]/build-gcc-offload-x86_64-intelmicemul-linux-gnu/x86_64-intelmicemul-linux-gnu/32/libstdc++-v3/src/.libs
-L[...]/build-gcc-offload-x86_64-intelmicemul-linux-gnu/x86_64-intelmicemul-linux-gnu/32/libstdc++-v3/libsupc++/.libs
-B/x86_64-intelmicemul-linux-gnu/bin/ -B/x86_64-intelmicemul-linux-gnu/lib/
-isystem /x86_64-intelmicemul-linux-gnu/include -isystem
/x86_64-intelmicemul-linux-gnu/sys-include -m32 -L./../.libs
-L./../../libgomp/.libs -loffloadmic_target -lcoi_device -lmyo-service -lgomp
-rdynamic ../ofldbegin.o offload_target_main.o ../ofldend.o -o
offload_target_main
/usr/bin/ld: cannot find -lgomp
collect2: error: ld returned 1 exit status
* Makefile.def (dependencies) all-target-liboffloadmic: Depend on
all-target-libgomp.
* Makefile.in: Regenerate.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@219344
138bc75d-0d04-0410-961f-82ee72b054a4
---
ChangeLog| 6 ++
Makefile.def | 2 +-
Makefile.in | 2 +-
3 files changed, 8 insertions(+), 2 deletions(-)
diff --git ChangeLog ChangeLog
index 325f4cc..9012087 100644
--- ChangeLog
+++ ChangeLog
@@ -1,3 +1,9 @@
+2015-01-08 Thomas Schwinge tho...@codesourcery.com
+
+ * Makefile.def (dependencies) all-target-liboffloadmic: Depend on
+ all-target-libgomp.
+ * Makefile.in: Regenerate.
+
2015-01-06 Eric Botcazou ebotca...@adacore.com
* MAINTAINERS (CPU Port Maintainers): Add myself for Visium port.
diff --git Makefile.def Makefile.def
index ffab409..15ab613 100644
--- Makefile.def
+++ Makefile.def
@@ -551,7 +551,7 @@ dependencies = { module=configure-target-libvtv;
on=all-target-libstdc++-v3; };
// generated by the libgomp configure. Unfortunately, due to the use of
// recursive make, we can't be that specific.
dependencies = { module=all-target-libstdc++-v3; on=configure-target-libgomp;
};
-dependencies = { module=all-target-liboffloadmic; on=configure-target-libgomp;
};
+dependencies = { module=all-target-liboffloadmic; on=all-target-libgomp; };
dependencies = { module=install-target-libgo; on=install-target-libatomic; };
dependencies = { module=install-target-libgfortran;
on=install-target-libquadmath; };
diff --git Makefile.in Makefile.in
index 7355bf1..428898a 100644
--- Makefile.in
+++ Makefile.in
@@ -48893,7 +48893,7 @@ all-stage3-target-libstdc++-v3:
maybe-configure-stage3-target-libgomp
all-stage4-target-libstdc++-v3: maybe-configure-stage4-target-libgomp
all-stageprofile-target-libstdc++-v3:
maybe-configure-stageprofile-target-libgomp
all-stagefeedback-target-libstdc++-v3:
maybe-configure-stagefeedback-target-libgomp
-all-target-liboffloadmic: maybe-configure-target-libgomp
+all-target-liboffloadmic: maybe-all-target-libgomp
install-target-libgo: maybe-install-target-libatomic
install-target-libgfortran: maybe-install-target-libquadmath
install-target-libgfortran: maybe-install-target-libgcc
Grüße,
Thomas
signature.asc
Description: PGP signature
Re: [debug-early] reuse variable DIEs and fix their context
Jason suggested keeping it in the branch since it doesn't fix any regressions, so it's living there for now. AldyOn Jan 8, 2015 4:24 AM, Richard Biener richard.guent...@gmail.com wrote: On Sat, Dec 20, 2014 at 5:49 AM, Aldy Hernandez al...@redhat.com wrote: On 12/19/14 11:03, Jason Merrill wrote: First of all, my bad Richard. I vaguely remember you mentioning something about Java, but it was early enough in the project that I had no idea what you were talking about. Thanks for your patience. It looks like java aliases are still using assemble_alias directly; switching to using same_body aliases like thunks and such should handle the issue. Ah, I see. Attached is a patch against _MAINLINE_ that fixes the issue I am seeing, without introducing any regressions. Well, I think it's a bit late now (but only affects Java, so...). Jasons call. Would it be crazy to ask for permission to commit this into mainline, and avoiding dragging this along on the branch? If not, I have a similar patch for the branch I can commit there. Let me know. Thanks for fixing this! Richard. Thanks for everyone's input. Aldy
Re: OMP builtins in offloading (was: [PATCH 1/4] Add mkoffload for Intel MIC)
Hi! On Fri, 26 Dec 2014 16:22:43 +0300, Ilya Verbin iver...@gmail.com wrote: On 22 Dec 12:26, Jakub Jelinek wrote: On Mon, Dec 22, 2014 at 12:20:58PM +0100, Thomas Schwinge wrote: What is the reason that you're adding -fopenmp here? I assume it is that otherwise you'd get tree streaming errors because of different builtins configurations, like this? If that is the only reason to add -fopenmp there, can we then instead do the following? gcc/builtins.def | 8 ++-- gcc/config/i386/intelmic-mkoffload.c | 1 - 2 files changed, 6 insertions(+), 3 deletions(-) If Ilya confirms that is the sole reason, I'm fine with this change. Please write ChangeLog entry for it. Ok to me. Committed to trunk in r219346: commit 752cfdfdd758616a0fee3071d33e4add83f34a51 Author: tschwinge tschwinge@138bc75d-0d04-0410-961f-82ee72b054a4 Date: Thu Jan 8 15:41:13 2015 + Make sure that OMP builtins are available in offloading compilers. gcc/ * builtins.def (DEF_GOMP_BUILTIN): Also consider flag_offload_abi for registering builtins. * config/i386/intelmic-mkoffload.c (prepare_target_image): Don't add -fopenmp to the argv_obstack used when invoking compile_for_target. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@219346 138bc75d-0d04-0410-961f-82ee72b054a4 --- gcc/ChangeLog| 6 ++ gcc/builtins.def | 5 - gcc/config/i386/intelmic-mkoffload.c | 1 - 3 files changed, 10 insertions(+), 2 deletions(-) diff --git gcc/ChangeLog gcc/ChangeLog index 01b6cc6..5bc6591 100644 --- gcc/ChangeLog +++ gcc/ChangeLog @@ -1,5 +1,11 @@ 2015-01-08 Thomas Schwinge tho...@codesourcery.com + * builtins.def (DEF_GOMP_BUILTIN): Also consider flag_offload_abi + for registering builtins. + * config/i386/intelmic-mkoffload.c (prepare_target_image): Don't + add -fopenmp to the argv_obstack used when invoking + compile_for_target. + * config/i386/intelmic-mkoffload.c (compile_for_target): Always add -m32 or -m64 to argv_obstack. (generate_host_descr_file): Likewise, when invoking host_compiler. diff --git gcc/builtins.def gcc/builtins.def index 28b1646..5a7ed10 100644 --- gcc/builtins.def +++ gcc/builtins.def @@ -148,11 +148,14 @@ along with GCC; see the file COPYING3. If not see /* Builtin used by the implementation of GNU OpenMP. None of these are actually implemented in the compiler; they're all in libgomp. */ +/* These builtins also need to be enabled in offloading compilers invoked from + mkoffload; for that purpose, we're checking the -foffload-abi flag here. */ #undef DEF_GOMP_BUILTIN #define DEF_GOMP_BUILTIN(ENUM, NAME, TYPE, ATTRS) \ DEF_BUILTIN (ENUM, __builtin_ NAME, BUILT_IN_NORMAL, TYPE, TYPE,\ false, true, true, ATTRS, false, \ - (flag_openmp || flag_tree_parallelize_loops)) + (flag_openmp || flag_tree_parallelize_loops \ + || flag_offload_abi != OFFLOAD_ABI_UNSET)) /* Builtin used by implementation of Cilk Plus. Most of these are decomposed by the compiler but a few are implemented in libcilkrts. */ diff --git gcc/config/i386/intelmic-mkoffload.c gcc/config/i386/intelmic-mkoffload.c index 23bc955..050f2e6 100644 --- gcc/config/i386/intelmic-mkoffload.c +++ gcc/config/i386/intelmic-mkoffload.c @@ -390,7 +390,6 @@ prepare_target_image (const char *target_compiler, int argc, char **argv) obstack_init (argv_obstack); obstack_ptr_grow (argv_obstack, target_compiler); obstack_ptr_grow (argv_obstack, -xlto); - obstack_ptr_grow (argv_obstack, -fopenmp); obstack_ptr_grow (argv_obstack, -shared); obstack_ptr_grow (argv_obstack, -fPIC); obstack_ptr_grow (argv_obstack, opt1); Grüße, Thomas pgpqURc0TjfBG.pgp Description: PGP signature
Re: [PATCH][ARM][4.9]Backport Fix definition of __ARM_SIZEOF_WCHAR_T
On 07/01/15 13:53, Renlin Li wrote: Hi all, This is a backport patch for https://gcc.gnu.org/viewcvs/gcc?view=revisionrevision=213864 arm-none-eabi regression test has been done, no new issues. Okay for branch 4.9? gcc/ChangeLog Fix PR target/61413 Backport from mainline. 2014-08-12 Ramana Radhakrishnan ramana.radhakrish...@arm.com PR target/61413 * config/arm/arm.h (TARGET_CPU_CPP_BUILTINS): Fix definition of __ARM_SIZEOF_WCHAR_T. backport.patch diff --git a/gcc/config/arm/arm.h b/gcc/config/arm/arm.h index c0f2184..2eb 100644 --- a/gcc/config/arm/arm.h +++ b/gcc/config/arm/arm.h @@ -74,8 +74,8 @@ extern char arm_arch_name[]; builtin_define_with_int_value ( \ __ARM_SIZEOF_MINIMAL_ENUM, \ flag_short_enums ? 1 : 4);\ - builtin_define_with_int_value ( \ - __ARM_SIZEOF_WCHAR_T, WCHAR_TYPE_SIZE); \ + builtin_define_type_sizeof (__ARM_SIZEOF_WCHAR_T, \ + wchar_type_node); \ if (TARGET_ARM_ARCH_PROFILE)\ builtin_define_with_int_value ( \ __ARM_ARCH_PROFILE, TARGET_ARM_ARCH_PROFILE); \ OK. R.
Re: [gofrontend-dev] [PATCH 1/2, libgo] Add reflection support to gccgo for ppc64, ppc64le in gcc 4.9
On Thu, Jan 8, 2015 at 5:44 AM, Lynn A. Boger labo...@linux.vnet.ibm.com wrote: Also as was noted below, some level of reflection support is needed to build Docker. Sorry to be so pedantic, but I'm just trying to clarify that you keep saying reflection support, but reflection support is there. What is missing is a miniscule rarely used part of the reflect package, namely support for reflect.MakeFunc, and, it's true, calling reflect.ValueOf, then Method or MethodByName, then Interface. Ian
[PATCH] Fix ix86_expand_int_movcc (PR target/64338)
Hi!
The recent ifcvt changes result in movcc being attempted with
comparisons like (ltgt (reg:CCFPU flags) (const_int 0)).
I see several issues with the current ix86_expand_int_movcc code:
1) the code was unprepared to handle *reverse_condition* failures
(returns of UNKNOWN)
2) for CCFP/CCFPU modes, I think it should be treated like scalar
float comparisons, ix86_reverse_condition seems to do the job here
3) compare_code in the second hunk was a dead computation, because
the variable is not used afterwards until it is unconditionally overwritten
(set to UNKNOWN).
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2015-01-08 Jakub Jelinek ja...@redhat.com
PR target/64338
* config/i386/i386.c (ix86_expand_int_movcc): Don't reverse
compare_code when it is unconditionally overwritten afterwards.
Use ix86_reverse_condition instead of reverse_condition. Don't
change code if *reverse_condition* returned UNKNOWN and don't
swap ct/cf and negate diff in that case.
* g++.dg/opt/pr64338.C: New test.
--- gcc/config/i386/i386.c.jj 2015-01-06 09:14:05.0 +0100
+++ gcc/config/i386/i386.c 2015-01-07 09:59:09.297790590 +0100
@@ -20830,9 +20830,7 @@ ix86_expand_int_movcc (rtx operands[])
if (diff 0)
{
machine_mode cmp_mode = GET_MODE (op0);
-
- std::swap (ct, cf);
- diff = -diff;
+ enum rtx_code new_code;
if (SCALAR_FLOAT_MODE_P (cmp_mode))
{
@@ -20842,13 +20840,15 @@ ix86_expand_int_movcc (rtx operands[])
is not valid in general (we may convert non-trapping condition
to trapping one), however on i386 we currently emit all
comparisons unordered. */
- compare_code = reverse_condition_maybe_unordered (compare_code);
- code = reverse_condition_maybe_unordered (code);
+ new_code = reverse_condition_maybe_unordered (code);
}
else
+ new_code = ix86_reverse_condition (code, cmp_mode);
+ if (new_code != UNKNOWN)
{
- compare_code = reverse_condition (compare_code);
- code = reverse_condition (code);
+ code = new_code;
+ std::swap (ct, cf);
+ diff = -diff;
}
}
@@ -20986,9 +20986,7 @@ ix86_expand_int_movcc (rtx operands[])
if (cf == 0)
{
machine_mode cmp_mode = GET_MODE (op0);
-
- cf = ct;
- ct = 0;
+ enum rtx_code new_code;
if (SCALAR_FLOAT_MODE_P (cmp_mode))
{
@@ -20998,14 +20996,21 @@ ix86_expand_int_movcc (rtx operands[])
that is not valid in general (we may convert non-trapping
condition to trapping one), however on i386 we currently
emit all comparisons unordered. */
- code = reverse_condition_maybe_unordered (code);
+ new_code = reverse_condition_maybe_unordered (code);
}
else
{
- code = reverse_condition (code);
- if (compare_code != UNKNOWN)
+ new_code = ix86_reverse_condition (code, cmp_mode);
+ if (compare_code != UNKNOWN new_code != UNKNOWN)
compare_code = reverse_condition (compare_code);
}
+
+ if (new_code != UNKNOWN)
+ {
+ code = new_code;
+ cf = ct;
+ ct = 0;
+ }
}
if (compare_code != UNKNOWN)
--- gcc/testsuite/g++.dg/opt/pr64338.C.jj 2015-01-07 10:18:04.740275018
+0100
+++ gcc/testsuite/g++.dg/opt/pr64338.C 2015-01-07 10:17:50.0 +0100
@@ -0,0 +1,29 @@
+// PR target/64338
+// { dg-do compile }
+// { dg-options -O2 }
+// { dg-additional-options -mtune=generic -march=i586 { target { { i?86-*-*
x86_64-*-* } ia32 } } }
+
+enum O {};
+struct A { A (); };
+struct B { int fn1 (); };
+struct C { struct D; D *fn2 (); void fn3 (); int fn4 (); };
+struct F { void fn5 (const int = 0); };
+struct G { F *fn6 (); };
+struct H { int h; };
+struct C::D { friend class C; G *fn7 (); };
+O a;
+
+void
+C::fn3 ()
+{
+ int b = a;
+ H c;
+ if (b)
+fn2 ()-fn7 ()-fn6 ()-fn5 ();
+ double d;
+ if (fn4 ())
+d = c.h 0;
+ A e (b ? A () : A ());
+ B f;
+ f.fn1 () d fn2 ();
+}
Jakub
Re: [PATCH 1/4] Add mkoffload for Intel MIC
Hi!
On Mon, 22 Dec 2014 12:28:20 +0100, Jakub Jelinek ja...@redhat.com wrote:
On Mon, Dec 22, 2014 at 12:25:32PM +0100, Thomas Schwinge wrote:
On Wed, 22 Oct 2014 22:57:01 +0400, Ilya Verbin iver...@gmail.com wrote:
--- /dev/null
+++ b/gcc/config/i386/intelmic-mkoffload.c
@@ -0,0 +1,541 @@
+/* Offload image generation tool for Intel MIC devices.
+/* Shows if we should compile binaries for i386 instead of x86-64. */
+bool target_ilp32 = false;
My linker defaults to 32-bit x86, so I explicitly have to switch to
64-bit x86_64 mode; OK to commit the following, to always explicitly
specify what is wanted?
gcc/config/i386/intelmic-mkoffload.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
Ok with proper ChangeLog entry.
Committed to trunk in r219345:
commit c049b358f961f72d0c0cf61a707e9a5855b12b28
Author: tschwinge tschwinge@138bc75d-0d04-0410-961f-82ee72b054a4
Date: Thu Jan 8 14:58:45 2015 +
intelmic-mkoffload: Deal with linker defaulting to 32-bit x86 mode.
... which explicitly has to be switched into 64-bit x86_64 mode.
gcc/
* config/i386/intelmic-mkoffload.c (compile_for_target): Always
add -m32 or -m64 to argv_obstack.
(generate_host_descr_file): Likewise, when invoking host_compiler.
(main): Always add -m elf_i386 or -m elf_x86_64 when invoking
ld.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@219345
138bc75d-0d04-0410-961f-82ee72b054a4
---
gcc/ChangeLog| 8
gcc/config/i386/intelmic-mkoffload.c | 12
2 files changed, 16 insertions(+), 4 deletions(-)
diff --git gcc/ChangeLog gcc/ChangeLog
index bee5f1e..01b6cc6 100644
--- gcc/ChangeLog
+++ gcc/ChangeLog
@@ -1,3 +1,11 @@
+2015-01-08 Thomas Schwinge tho...@codesourcery.com
+
+ * config/i386/intelmic-mkoffload.c (compile_for_target): Always
+ add -m32 or -m64 to argv_obstack.
+ (generate_host_descr_file): Likewise, when invoking host_compiler.
+ (main): Always add -m elf_i386 or -m elf_x86_64 when invoking
+ ld.
+
2015-01-08 Oleg Endo olege...@gcc.gnu.org
* config/sh/sh-mem.cc: Use constant as second operand when emitting
diff --git gcc/config/i386/intelmic-mkoffload.c
gcc/config/i386/intelmic-mkoffload.c
index c3d2b23..23bc955 100644
--- gcc/config/i386/intelmic-mkoffload.c
+++ gcc/config/i386/intelmic-mkoffload.c
@@ -191,6 +191,8 @@ compile_for_target (struct obstack *argv_obstack)
{
if (target_ilp32)
obstack_ptr_grow (argv_obstack, -m32);
+ else
+obstack_ptr_grow (argv_obstack, -m64);
obstack_ptr_grow (argv_obstack, NULL);
char **argv = XOBFINISH (argv_obstack, char **);
@@ -355,6 +357,8 @@ generate_host_descr_file (const char *host_compiler)
new_argv[new_argc++] = -shared;
if (target_ilp32)
new_argv[new_argc++] = -m32;
+ else
+new_argv[new_argc++] = -m64;
new_argv[new_argc++] = src_filename;
new_argv[new_argc++] = -o;
new_argv[new_argc++] = obj_filename;
@@ -511,11 +515,11 @@ main (int argc, char **argv)
unsigned new_argc = 0;
const char *new_argv[9];
new_argv[new_argc++] = ld;
+ new_argv[new_argc++] = -m;
if (target_ilp32)
-{
- new_argv[new_argc++] = -m;
- new_argv[new_argc++] = elf_i386;
-}
+new_argv[new_argc++] = elf_i386;
+ else
+new_argv[new_argc++] = elf_x86_64;
new_argv[new_argc++] = --relocatable;
new_argv[new_argc++] = host_descr_filename;
new_argv[new_argc++] = target_so_filename;
Grüße,
Thomas
pgp5yt6PE7GDH.pgp
Description: PGP signature
Re: OMP builtins in offloading (was: [PATCH 1/4] Add mkoffload for Intel MIC)
On Thu, Jan 08, 2015 at 07:32:13PM +0300, Ilya Verbin wrote: On 08 Jan 16:49, Jakub Jelinek wrote: BTW, today when looking at the TARGET_OPTION_NODE streaming caused regressions, I've discovered that it is very hard to debug issues in the offloading compiler. Would be nice if -save-temps -v printed enough information that it is actually possible to reproduce it, e.g. while mkoffload command is printed, one can't cut and paste it easily, because some env vars are required and those aren't printed in the -v dump. I agree, this should be improved. Unfortunately, I didn't have time so far. Similarly, the lto1 offloading compiler invocation is not printed, and It can be printed by -foffload=-save-temps -v, or should we pass through these options from host to offload compiler by default? Certainly not if they weren't passed by the user to the host compiler. But if they have been passed, it might be useful, having to add -save-temps -v to too many spaces is annoying. And it would be really nice to print the essential env vars mkoffload is relying on, like: var1=value1 var2=value2 ./mkoffload /tmp/@ccABCDEF Jakub
Re: [patch] libstdc++/60132 deprecate C++0x has_trivial_xxx traits
On 08/01/15 16:24 +, Jonathan Wakely wrote: Now that we provide the std::is_trivially_xxxible traits we don't need to keep the has_trivial_xxx ones from the earlier C++0x drafts. This patch marks them as deprecated so we can remove them in future. I'll update the changes.html notes too. Here's the patch for the web page. Index: gcc-5/changes.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-5/changes.html,v retrieving revision 1.56 diff -u -r1.56 changes.html --- gcc-5/changes.html 31 Dec 2014 17:25:22 - 1.56 +++ gcc-5/changes.html 8 Jan 2015 16:46:11 - @@ -20,6 +20,14 @@ CLooG library, only ISL version 0.14 (recommended) or 0.12.2. The installation manual contains more information about requirements to build GCC./li +liThe non-standard type traits +codehas_trivial_default_constructor/code, +codehas_trivial_copy_constructor/code and +codehas_trivial_copy_assign/code have been deprecated and will +be removed in a future version. The standard traits +codeis_trivially_default_constructible/code, +codeis_trivially_copy_constructible/code and +codeis_trivially_copy_assignable/code should be used instead./li /ul h2 id=generalGeneral Optimizer Improvements/h2 @@ -320,7 +328,7 @@ liNew random number distributions codelogistic_distribution/code and codeuniform_on_sphere_distribution/code as extensions./li lia href=https://sourceware.org/gdb/current/onlinedocs/gdb/Xmethods-In-Python.html;GDB - Xmethods/a for Sequence Containers and codestd::unique_ptr/code;/li + Xmethods/a for containers and codestd::unique_ptr/code;/li /ul h3 id=fortranFortran/h3
Re: [PATCH] Fix for PR ipa/64503
On Wed, Jan 07, 2015 at 01:43:59PM +0100, Uros Bizjak wrote: Hello! There's suggested patch for PR ipa/64503 that was tested on x86_64 and it works. I would like to ask Uros to test it on an aplha machine before we install the patch. Yes, this works for me on all IPA tests that were failing previously [1]. I am restarting the bootstrap + regtest, it will take ~10 hours, but I don't expect any surprises there. The patch was bootstrapped and regression tested on alphaev68-linux-gnu [2] and everything was OK. Thanks for testing. May I take this as approval of the patch. I don't know, if you have a permission to accept my patch ;) Unfortunately, I have no approval power here. Luckilly, I know someone who has ;) I don't know how portable scalbnl actually is in reality, so it would be nice to hear from port maintainers whether say newlib, android, darwin, cygwin, aix etc. have it. Jakub
Re: [PATCH 1/4] Add mkoffload for Intel MIC
Hi!
On Thu, 8 Jan 2015 07:02:19 -0800, H.J. Lu hjl.to...@gmail.com wrote:
On Thu, Jan 8, 2015 at 6:59 AM, Thomas Schwinge tho...@codesourcery.com
wrote:
commit c049b358f961f72d0c0cf61a707e9a5855b12b28
Author: tschwinge tschwinge@138bc75d-0d04-0410-961f-82ee72b054a4
Date: Thu Jan 8 14:58:45 2015 +
intelmic-mkoffload: Deal with linker defaulting to 32-bit x86 mode.
... which explicitly has to be switched into 64-bit x86_64 mode.
gcc/
* config/i386/intelmic-mkoffload.c (compile_for_target): Always
add -m32 or -m64 to argv_obstack.
(generate_host_descr_file): Likewise, when invoking host_compiler.
(main): Always add -m elf_i386 or -m elf_x86_64 when invoking
ld.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@219345
138bc75d-0d04-0410-961f-82ee72b054a4
--- gcc/config/i386/intelmic-mkoffload.c
+++ gcc/config/i386/intelmic-mkoffload.c
@@ -191,6 +191,8 @@ compile_for_target (struct obstack *argv_obstack)
{
if (target_ilp32)
obstack_ptr_grow (argv_obstack, -m32);
+ else
+obstack_ptr_grow (argv_obstack, -m64);
obstack_ptr_grow (argv_obstack, NULL);
char **argv = XOBFINISH (argv_obstack, char **);
@@ -355,6 +357,8 @@ generate_host_descr_file (const char *host_compiler)
new_argv[new_argc++] = -shared;
if (target_ilp32)
new_argv[new_argc++] = -m32;
+ else
+new_argv[new_argc++] = -m64;
new_argv[new_argc++] = src_filename;
new_argv[new_argc++] = -o;
new_argv[new_argc++] = obj_filename;
@@ -511,11 +515,11 @@ main (int argc, char **argv)
unsigned new_argc = 0;
const char *new_argv[9];
new_argv[new_argc++] = ld;
+ new_argv[new_argc++] = -m;
if (target_ilp32)
-{
- new_argv[new_argc++] = -m;
- new_argv[new_argc++] = elf_i386;
-}
+new_argv[new_argc++] = elf_i386;
+ else
+new_argv[new_argc++] = elf_x86_64;
new_argv[new_argc++] = --relocatable;
new_argv[new_argc++] = host_descr_filename;
new_argv[new_argc++] = target_so_filename;
Should we also handle x32?
Yes, probably, but following the standards you've been setting,
http://news.gmane.org/find-root.php?message_id=%3Calpine.DEB.2.10.1412151845470.4719%40digraph.polyomino.org.uk%3E,
I only made it work for the case I've been interested in. ;-)
(Half-smiley, half-serious...)
Grüße,
Thomas
pgpRdf5qin_61.pgp
Description: PGP signature
[patch] libstdc++/60132 deprecate C++0x has_trivial_xxx traits
Now that we provide the std::is_trivially_xxxible traits we don't need
to keep the has_trivial_xxx ones from the earlier C++0x drafts. This
patch marks them as deprecated so we can remove them in future.
I'll update the changes.html notes too.
Tested x86_64-linux, committed to trunk.
commit 2caec20dcc7f702f3c1e5c4f4e3943948ce3c5a9
Author: Jonathan Wakely jwak...@redhat.com
Date: Tue Dec 2 16:49:41 2014 +
PR libstdc++/60132
* include/std/type_traits (has_trivial_default_constructor,
has_trivial_copy_constructor, has_trivial_copy_assign): Add deprecated
attribute.
* testsuite/20_util/has_trivial_copy_assign/requirements/
explicit_instantiation.cc: Use -Wno-deprecated.
* testsuite/20_util/has_trivial_copy_assign/requirements/typedefs.cc:
Likewise.
* testsuite/20_util/has_trivial_copy_assign/value.cc: Likewise.
* testsuite/20_util/has_trivial_copy_constructor/requirements/
explicit_instantiation.cc: Likewise.
* testsuite/20_util/has_trivial_copy_constructor/requirements/
typedefs.cc: Likewise.
* testsuite/20_util/has_trivial_copy_constructor/value.cc: Likewise.
* testsuite/20_util/has_trivial_default_constructor/requirements/
explicit_instantiation.c: Likewise.
* testsuite/20_util/has_trivial_default_constructor/requirements/
typedefs.cc: Likewise.
* testsuite/20_util/has_trivial_default_constructor/value.cc:
Likewise.
* testsuite/20_util/pair/requirements/dr801.cc: Replace deprecated
trait.
* testsuite/20_util/tuple/requirements/dr801.cc: Likewise.
* testsuite/util/testsuite_common_types.h: Likewise.
diff --git a/libstdc++-v3/include/std/type_traits b/libstdc++-v3/include/std/type_traits
index 4397c16..03e198a 100644
--- a/libstdc++-v3/include/std/type_traits
+++ b/libstdc++-v3/include/std/type_traits
@@ -1382,19 +1382,19 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
templatetypename _Tp
struct has_trivial_default_constructor
: public integral_constantbool, __has_trivial_constructor(_Tp)
-{ };
+{ } _GLIBCXX_DEPRECATED;
/// has_trivial_copy_constructor (temporary legacy)
templatetypename _Tp
struct has_trivial_copy_constructor
: public integral_constantbool, __has_trivial_copy(_Tp)
-{ };
+{ } _GLIBCXX_DEPRECATED;
/// has_trivial_copy_assign (temporary legacy)
templatetypename _Tp
struct has_trivial_copy_assign
: public integral_constantbool, __has_trivial_assign(_Tp)
-{ };
+{ } _GLIBCXX_DEPRECATED;
/// has_virtual_destructor
templatetypename _Tp
diff --git a/libstdc++-v3/testsuite/20_util/has_trivial_copy_assign/requirements/explicit_instantiation.cc b/libstdc++-v3/testsuite/20_util/has_trivial_copy_assign/requirements/explicit_instantiation.cc
index 19b4c99..1b2c02b 100644
--- a/libstdc++-v3/testsuite/20_util/has_trivial_copy_assign/requirements/explicit_instantiation.cc
+++ b/libstdc++-v3/testsuite/20_util/has_trivial_copy_assign/requirements/explicit_instantiation.cc
@@ -1,4 +1,4 @@
-// { dg-options -std=gnu++11 }
+// { dg-options -std=gnu++11 -Wno-deprecated }
// { dg-do compile }
// 2010-06-08 Paolo Carlini paolo.carl...@oracle.com
diff --git a/libstdc++-v3/testsuite/20_util/has_trivial_copy_assign/requirements/typedefs.cc b/libstdc++-v3/testsuite/20_util/has_trivial_copy_assign/requirements/typedefs.cc
index 3044ec3..c5fd5ec 100644
--- a/libstdc++-v3/testsuite/20_util/has_trivial_copy_assign/requirements/typedefs.cc
+++ b/libstdc++-v3/testsuite/20_util/has_trivial_copy_assign/requirements/typedefs.cc
@@ -1,4 +1,4 @@
-// { dg-options -std=gnu++11 }
+// { dg-options -std=gnu++11 -Wno-deprecated }
// 2010-06-08 Paolo Carlini paolo.carl...@oracle.com
//
// Copyright (C) 2010-2015 Free Software Foundation, Inc.
diff --git a/libstdc++-v3/testsuite/20_util/has_trivial_copy_assign/value.cc b/libstdc++-v3/testsuite/20_util/has_trivial_copy_assign/value.cc
index 1cfafaa..bd778ad 100644
--- a/libstdc++-v3/testsuite/20_util/has_trivial_copy_assign/value.cc
+++ b/libstdc++-v3/testsuite/20_util/has_trivial_copy_assign/value.cc
@@ -1,4 +1,4 @@
-// { dg-options -std=gnu++11 }
+// { dg-options -std=gnu++11 -Wno-deprecated }
// { dg-do compile }
// 2010-06-08 Paolo Carlini paolo.carl...@oracle.com
diff --git a/libstdc++-v3/testsuite/20_util/has_trivial_copy_constructor/requirements/explicit_instantiation.cc b/libstdc++-v3/testsuite/20_util/has_trivial_copy_constructor/requirements/explicit_instantiation.cc
index 0e28a4f..6517852 100644
--- a/libstdc++-v3/testsuite/20_util/has_trivial_copy_constructor/requirements/explicit_instantiation.cc
+++ b/libstdc++-v3/testsuite/20_util/has_trivial_copy_constructor/requirements/explicit_instantiation.cc
@@ -1,4 +1,4 @@
-// { dg-options -std=gnu++11 }
+// { dg-options -std=gnu++11 -Wno-deprecated }
// { dg-do compile }
// 2007-04-30 Benjamin Kosnik b...@redhat.com
diff --git a/libstdc++-v3/testsuite/20_util/has_trivial_copy_constructor/requirements/typedefs.cc
Re: [PATCH][ARM] FreeBSD ARM support, EABI, v3
On 29/12/14 18:44, Andreas Tobler wrote:
All,
here is the third attempt to support ARM with FreeBSD.
In the meantime we found another issue in the unwinder where I had to
adapt some stuff.
The unwind_phase2_forced function in libgcc calls a stop_fn function.
This stop_fn is in FreeBSD's libthr implementation and is called
thread_unwind_stop. This thread_unwind_stop is a generic function used
on all FreeBSD archs.
The issue is now that this thread_unwind_stop expects a double int for
the exception_class, like on every other arch. For ARM EABI this
exception_class is an array of char which is passed in one register as
pointer vs. two registers for a double int.
To solve this issue we defined the exception_class as double integer for
FreeBSD.
This adaptation reduced the failure count in libstdc++ by about 40 fails.
I build and test this port on a regular basis and I post the results to
the usual place.
I'd appreciate some feedback and if possible an ACK if ok for trunk.
Thank you,
Andreas
Here the previous posts to this subject:
First version:
https://gcc.gnu.org/ml/gcc-patches/2014-11/msg00029.html
Second version:
https://gcc.gnu.org/ml/gcc-patches/2014-11/msg03427.html
toplevel:
* configure.ac: Don't add ${libgcj} for arm*-*-freebsd*.
* configure: Regenerate.
gcc:
* config.gcc (arm*-*-freebsd*): New configuration.
* config/arm/freebsd.h: New file.
* config.host: Add extra components for arm*-*-freebsd*.
* config/arm/arm.h: Introduce MAX_SYNC_LIBFUNC_SIZE.
* config/arm/arm.c (arm_init_libfuncs): Use MAX_SYNC_LIBFUNC_SIZE.
* ginclude/unwind-arm-common.h (_Uwind_Control_Block): Define
exception_class as double integer for FreeBSD ARM.
(_Unwind_Exception): Define _Unwind_Exception_Class as double integer
for FreeBSD ARM.
libgcc:
* config.host (arm*-*-freebsd*): Add new configuration for
arm*-*-freebsd*.
* config/arm/freebsd-atomic.c: New file.
* config/arm/t-freebsd: Likewise.
* config/arm/unwind-arm.h: Add __FreeBSD__ to the list of
'PC-relative indirect' OS's.
libatomic:
* configure.tgt: Exclude arm*-*-freebsd* from try_ifunc.
libstdc++-v3:
* configure.host: Add arm*-*-freebsd* port_specific_symbol_files.
* libsupc++/unwind-cxx.h (__is_gxx_exception_class,
__is_dependent_exception): Exclude FreeBSD ARM from the
__ARM_EABI_UNWINDER__ ifdef.
Umm, sorry, just seen this update to the previous patch.
The changes to the exception unwinding look a bit more involved. Could
you separate that out into a separate patch, so that it's easier to see
what you're changing?
R.
gcc5_fbsd_arm_20141230-1.diff
Index: configure
===
--- configure (revision 219100)
+++ configure (working copy)
@@ -3425,6 +3425,9 @@
alpha*-*-*vms*)
noconfigdirs=$noconfigdirs ${libgcj}
;;
+ arm*-*-freebsd*)
+noconfigdirs=$noconfigdirs ${libgcj}
+;;
arm-wince-pe)
noconfigdirs=$noconfigdirs ${libgcj}
;;
Index: configure.ac
===
--- configure.ac (revision 219100)
+++ configure.ac (working copy)
@@ -779,6 +779,9 @@
alpha*-*-*vms*)
noconfigdirs=$noconfigdirs ${libgcj}
;;
+ arm*-*-freebsd*)
+noconfigdirs=$noconfigdirs ${libgcj}
+;;
arm-wince-pe)
noconfigdirs=$noconfigdirs ${libgcj}
;;
Index: gcc/config/arm/arm.c
===
--- gcc/config/arm/arm.c (revision 219100)
+++ gcc/config/arm/arm.c (working copy)
@@ -2160,7 +2160,7 @@
{
/* For Linux, we have access to kernel support for atomic operations. */
if (arm_abi == ARM_ABI_AAPCS_LINUX)
-init_sync_libfuncs (2 * UNITS_PER_WORD);
+init_sync_libfuncs (MAX_SYNC_LIBFUNC_SIZE);
/* There are no special library functions unless we are using the
ARM BPABI. */
Index: gcc/config/arm/arm.h
===
--- gcc/config/arm/arm.h (revision 219100)
+++ gcc/config/arm/arm.h (working copy)
@@ -766,6 +766,11 @@
#define PCC_BITFIELD_TYPE_MATTERS TARGET_AAPCS_BASED
#endif
+/* The maximum size of the sync library functions supported. */
+#ifndef MAX_SYNC_LIBFUNC_SIZE
+#define MAX_SYNC_LIBFUNC_SIZE (2 * UNITS_PER_WORD);
+#endif
+
/* Standard register usage. */
Index: gcc/config/arm/freebsd.h
===
--- gcc/config/arm/freebsd.h (revision 0)
+++ gcc/config/arm/freebsd.h (working copy)
@@ -0,0 +1,180 @@
+/* Definitions of target machine for GNU compiler, FreeBSD/arm version.
+ Copyright (C) 2002-2014 Free Software Foundation, Inc.
+ Contributed by Wasabi Systems, Inc.
+
+ This file is
Re: OMP builtins in offloading (was: [PATCH 1/4] Add mkoffload for Intel MIC)
Hi! On Thu, Jan 08, 2015 at 04:41:50PM +0100, Thomas Schwinge wrote: On Fri, 26 Dec 2014 16:22:43 +0300, Ilya Verbin iver...@gmail.com wrote: BTW, today when looking at the TARGET_OPTION_NODE streaming caused regressions, I've discovered that it is very hard to debug issues in the offloading compiler. Would be nice if -save-temps -v printed enough information that it is actually possible to reproduce it, e.g. while mkoffload command is printed, one can't cut and paste it easily, because some env vars are required and those aren't printed in the -v dump. Similarly, the lto1 offloading compiler invocation is not printed, and wrapping offloading compiler's lto1 into a script that runs gdb on it doesn't work, because stdout/stderr (and stdin) is redirected. This is something that can be solved during stage4, but would be really nice if it wasn't terribly hard to debug stuff. Jakub
Re: [PATCH] LRA: Fix caller-save store/restore instruction for large mode
Hi Jeff:
After discussion with Bin, he prefer just use
gcc.c-torture/execute/scal-to-vec1.c
instead of introduce new one, do you have any further comment on this patch?
On Thu, Jan 8, 2015 at 9:29 AM, Bin.Cheng amker.ch...@gmail.com wrote:
On Wed, Jan 7, 2015 at 8:28 PM, Kito Cheng kito.ch...@gmail.com wrote:
Hi Bin:
It's 2 more line than gcc.c-torture/execute/scal-to-vec1.c since it's
need specific compilation
flag and specific target to reproduce this issue,
and it's can't reproduce by normal testing flow with
arm-*-linux-gnueabi (due to lack -fPIC flag),
so I prefer duplicate this case into gcc.target/arm/ :)
/* { dg-do compile } */
/* { dg-options -O3 -fPIC -marm -mcpu=cortex-a8 } */
Not really, we generally want to avoid cpu related options in testcase
since it introduces conflict option failures when testing against
specific processor, e.g. testing against Cortex-M profile processors.
Thanks,
bin
On Wed, Jan 7, 2015 at 4:50 PM, Bin.Cheng amker.ch...@gmail.com wrote:
On Wed, Jan 7, 2015 at 4:03 PM, Kito Cheng kito.ch...@gmail.com wrote:
Hi Jeff:
It's updated patch,bootstrapped and run regression tested on arm-eabi,
arm-none-linux-uclibcgnueabi, x86_64-unknown-linux-gnu and nds32le-elf
without introducing regression.
Thanks for your review :)
2015-01-07 Kito Cheng k...@0xlab.org
PR target/64348
* lra-constraints.c (split_reg): Fix caller-save store/restore
instruction generation.
Thanks for fixing the issue.
The PR is against existing testcase failure
gcc.c-torture/execute/scal-to-vec1.c. Unless we can create a new
case, there is no need to include same case twice I think? Or we can
mention the PR number in the original test case?
Thanks,
bin
From 98f58cca618a99e282c7add2ecbe59002c867c60 Mon Sep 17 00:00:00 2001
From: Kito Cheng k...@andestech.com
Date: Thu, 29 May 2014 23:53:23 +0800
Subject: [PATCH] Fix caller-save store/restore instruction for large mode in
lra
- The original code assume store/restore will always have only
one insn, it's will fail if you split in move pattern!!!
---
gcc/lra-constraints.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/gcc/lra-constraints.c b/gcc/lra-constraints.c
index 96b10a1..f8bc12f 100644
--- a/gcc/lra-constraints.c
+++ b/gcc/lra-constraints.c
@@ -4918,15 +4918,14 @@ split_reg (bool before_p, int original_regno, rtx_insn *insn,
reg_renumber[REGNO (new_reg)] = hard_regno;
}
save = emit_spill_move (true, new_reg, original_reg);
- if (NEXT_INSN (save) != NULL_RTX)
+ if (NEXT_INSN (save) != NULL_RTX !call_save_p)
{
- lra_assert (! call_save_p);
if (lra_dump_file != NULL)
{
fprintf
(lra_dump_file,
- Rejecting split %d-%d resulting in 2 %s save insns:\n,
- original_regno, REGNO (new_reg), call_save_p ? call : );
+ Rejecting split %d-%d resulting in 2 save insns:\n,
+ original_regno, REGNO (new_reg));
dump_rtl_slim (lra_dump_file, save, NULL, -1, 0);
fprintf (lra_dump_file,
\n);
@@ -4934,15 +4933,14 @@ split_reg (bool before_p, int original_regno, rtx_insn *insn,
return false;
}
restore = emit_spill_move (false, new_reg, original_reg);
- if (NEXT_INSN (restore) != NULL_RTX)
+ if (NEXT_INSN (restore) != NULL_RTX !call_save_p)
{
- lra_assert (! call_save_p);
if (lra_dump_file != NULL)
{
fprintf (lra_dump_file,
Rejecting split %d-%d
- resulting in 2 %s restore insns:\n,
- original_regno, REGNO (new_reg), call_save_p ? call : );
+ resulting in 2 restore insns:\n,
+ original_regno, REGNO (new_reg));
dump_rtl_slim (lra_dump_file, restore, NULL, -1, 0);
fprintf (lra_dump_file,
\n);
--
1.8.3.1.549.g1f3a412
Re: OMP builtins in offloading (was: [PATCH 1/4] Add mkoffload for Intel MIC)
On 08 Jan 16:49, Jakub Jelinek wrote: BTW, today when looking at the TARGET_OPTION_NODE streaming caused regressions, I've discovered that it is very hard to debug issues in the offloading compiler. Would be nice if -save-temps -v printed enough information that it is actually possible to reproduce it, e.g. while mkoffload command is printed, one can't cut and paste it easily, because some env vars are required and those aren't printed in the -v dump. I agree, this should be improved. Unfortunately, I didn't have time so far. Similarly, the lto1 offloading compiler invocation is not printed, and It can be printed by -foffload=-save-temps -v, or should we pass through these options from host to offload compiler by default? wrapping offloading compiler's lto1 into a script that runs gdb on it doesn't work, because stdout/stderr (and stdin) is redirected. This is something that can be solved during stage4, but would be really nice if it wasn't terribly hard to debug stuff. -- Ilya
Re: [PATCH 4/4] OpenMP 4.0 offloading to Intel MIC: non-fallback testing
Hi!
On Fri, 26 Dec 2014 22:15:24 +0300, Ilya Verbin iver...@gmail.com wrote:
On 22 Dec 12:48, Thomas Schwinge wrote:
Here is a patch to correctly match intelmic in $offload_targets; OK to
commit, I assume? I suppose I'm the first one to ever do build-tree
testing? (Jakub?)
OK, thanks.
I verified this case some time ago, but missed when it started failing, since
tests just become UNSUPPORTED or PASSED with host fallback, rather than
FAILing.
Yeah. (I diff the *.sum files, so I do see such regressions.) Committed
to trunk in r219348:
commit b21c795fa27f6fcefdb38d1bc50f1d1634f4e0b3
Author: tschwinge tschwinge@138bc75d-0d04-0410-961f-82ee72b054a4
Date: Thu Jan 8 16:01:24 2015 +
libgomp: Fix intelmic offloading in build-tree testing.
libgomp/
* testsuite/lib/libgomp.exp (libgomp_init): Correctly match
intelmic in $offload_targets.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@219348
138bc75d-0d04-0410-961f-82ee72b054a4
---
libgomp/ChangeLog | 5 +
libgomp/testsuite/lib/libgomp.exp | 3 +--
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git libgomp/ChangeLog libgomp/ChangeLog
index afbde87..beecba9 100644
--- libgomp/ChangeLog
+++ libgomp/ChangeLog
@@ -1,3 +1,8 @@
+2015-01-08 Thomas Schwinge tho...@codesourcery.com
+
+ * testsuite/lib/libgomp.exp (libgomp_init): Correctly match
+ intelmic in $offload_targets.
+
2015-01-05 Jakub Jelinek ja...@redhat.com
Update copyright years.
diff --git libgomp/testsuite/lib/libgomp.exp libgomp/testsuite/lib/libgomp.exp
index ff22f10..2d6f822 100644
--- libgomp/testsuite/lib/libgomp.exp
+++ libgomp/testsuite/lib/libgomp.exp
@@ -115,8 +115,7 @@ proc libgomp_init { args } {
# Add liboffloadmic build directory in LD_LIBRARY_PATH to support
# non-fallback testing for Intel MIC targets
-if { [string match *-intelmic-* $offload_targets]
- || [string match *-intelmicemul-* $offload_targets] } {
+if { [string match *,intelmic,* ,$offload_targets,] } {
append always_ld_library_path :${blddir}/../liboffloadmic/.libs
append always_ld_library_path :${blddir}/../liboffloadmic/plugin/.libs
# libstdc++ is required by liboffloadmic
Here is a patch to fix 32-bit x86 Intel MIC offloading; OK to commit, I
assume?
OK, thanks.
Committed to trunk in r219349:
commit 49b6c472197cbb443c55cc1064de5b24384bbf7f
Author: tschwinge tschwinge@138bc75d-0d04-0410-961f-82ee72b054a4
Date: Thu Jan 8 16:01:37 2015 +
libgomp: Fix 32-bit x86 Intel MIC offloading testing.
[...]
spawn [...]/build-gcc/gcc/xgcc -B[...]/build-gcc/gcc/
[...]/source-gcc/libgomp/testsuite/libgomp.c/examples-4/e.50.1.c
-B[...]/build-gcc/x86_64-unknown-linux-gnu/32/libgomp/
-B[...]/build-gcc/x86_64-unknown-linux-gnu/32/libgomp/.libs
-I[...]/build-gcc/x86_64-unknown-linux-gnu/32/libgomp
-I[...]/source-gcc/libgomp/testsuite/.. -march=i486 -fmessage-length=0
-fno-diagnostics-show-caret -fdiagnostics-color=never
-B[...]/install/offload-x86_64-intelmicemul-linux-gnu/libexec/gcc/x86_64-unknown-linux-gnu/5.0.0
-B[...]/install/offload-x86_64-intelmicemul-linux-gnu/bin -fopenmp -O2
-L[...]/build-gcc/x86_64-unknown-linux-gnu/32/libgomp/.libs -lm -m32 -o
./e.50.1.exe
PASS: libgomp.c/examples-4/e.50.1.c (test for excess errors)
Setting LD_LIBRARY_PATH to
.:[...]/build-gcc/x86_64-unknown-linux-gnu/32/libgomp/.libs:[...]/build-gcc/x86_64-unknown-linux-gnu/32/libgomp/../liboffloadmic/.libs:[...]/build-gcc/x86_64-unknown-linux-gnu/32/libgomp/../liboffloadmic/plugin/.libs:[...]/build-gcc/x86_64-unknown-linux-gnu/32/libgomp/../libstdc++-v3/src/.libs:[...]/install/offload-x86_64-intelmicemul-linux-gnu/lib64:[...]/install/offload-x86_64-intelmicemul-linux-gnu/lib:[...]/build-gcc/gcc:[...]/build-gcc/gcc/32:.:[...]/build-gcc/x86_64-unknown-linux-gnu/32/libgomp/.libs:[...]/build-gcc/x86_64-unknown-linux-gnu/32/libgomp/../liboffloadmic/.libs:[...]/build-gcc/x86_64-unknown-linux-gnu/32/libgomp/../liboffloadmic/plugin/.libs:[...]/build-gcc/x86_64-unknown-linux-gnu/32/libgomp/../libstdc++-v3/src/.libs:[...]/install/offload-x86_64-intelmicemul-linux-gnu/lib64:[...]/install/offload-x86_64-intelmicemul-linux-gnu/lib:[...]/build-gcc/gcc:[...]/build-gcc/gcc/32:[...]/build-gcc/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs:[...]/build-gcc/x86_64-unknown-linux-gnu/libsanitizer/.libs:[...]/build-gcc/x86_64-unknown-linux-gnu/libvtv/.libs:[...]/build-gcc/x86_64-unknown-linux-gnu/libcilkrts/.libs:[...]/build-gcc/x86_64-unknown-linux-gnu/liboffloadmic/.libs:[...]/build-gcc/x86_64-unknown-linux-gnu/libssp/.libs:[...]/build-gcc/x86_64-unknown-linux-gnu/libgomp/.libs:[...]/build-gcc/x86_64-unknown-linux-gnu/libitm/.libs:[...]/build-gcc/x86_64-unknown-linux-gnu/libatomic/.libs:[...]/build-gcc/./gcc:[...]/build-gcc/./prev-gcc
spawn [open ...]
/tmp/offload_WCXKRZ/offload_target_main: error while loading shared
libraries:
Re: [gofrontend-dev] [PATCH 1/2, libgo] Add reflection support to gccgo for ppc64, ppc64le in gcc 4.9
The only bugs I am aware of when using reflection on ppc64 ppc64le in gcc 4.9 are in the gccgo testcase recover.go and what is needed to build Docker. When I run the gccgo testsuite and see a failing testcase with a panic message saying that a function is not implemented it makes me think some major pieces are missing so that is why I've used that phrase. Also I noticed that the libgo/go/reflect/all_test.go testcase is not running some tests when GOARCH is ppc64 or ppc64le, and if those are enabled they fail. So some might call those bugs or unimplemented features or missing support. To me, a message saying that something is not implemented is considered missing support even though it might be minor. The information I received from those who had attempted to build Docker on ppc64le in gcc 4.9 said that it needed reflection and it wasn't there and this patch was used to make it work. I hope that answers your question? I have not done a thorough testing/investigation of reflection in gccgo 4.9 on Power and my statement refers only on the above information. On 01/08/2015 08:53 AM, Ian Lance Taylor wrote: On Thu, Jan 8, 2015 at 5:44 AM, Lynn A. Boger labo...@linux.vnet.ibm.com wrote:I Also as was noted below, some level of reflection support is needed to build Docker. Sorry to be so pedantic, but I'm just trying to clarify that you keep saying reflection support, but reflection support is there. What is missing is a miniscule rarely used part of the reflect package, namely support for reflect.MakeFunc, and, it's true, calling reflect.ValueOf, then Method or MethodByName, then Interface. Ian
Re: [PATCH] Fix for PR ipa/64503
On Thu, Jan 8, 2015 at 6:04 PM, Jakub Jelinek ja...@redhat.com wrote: On Wed, Jan 07, 2015 at 01:43:59PM +0100, Uros Bizjak wrote: Hello! There's suggested patch for PR ipa/64503 that was tested on x86_64 and it works. I would like to ask Uros to test it on an aplha machine before we install the patch. Yes, this works for me on all IPA tests that were failing previously [1]. I am restarting the bootstrap + regtest, it will take ~10 hours, but I don't expect any surprises there. The patch was bootstrapped and regression tested on alphaev68-linux-gnu [2] and everything was OK. Thanks for testing. May I take this as approval of the patch. I don't know, if you have a permission to accept my patch ;) Unfortunately, I have no approval power here. Luckilly, I know someone who has ;) I don't know how portable scalbnl actually is in reality, so it would be nice to hear from port maintainers whether say newlib, android, darwin, cygwin, aix etc. have it. Newlib has it. Other than that: exp2(), exp2f(), exp2l(): _XOPEN_SOURCE = 600 || _ISOC99_SOURCE || _POSIX_C_SOURCE = 200112L; or cc -std=c99 scalbln(), scalblnf(), scalblnl(): _XOPEN_SOURCE = 600 || _ISOC99_SOURCE || _POSIX_C_SOURCE = 200112L; or cc -std=c99 Since we are replacing exp2 with scalbln, we have the same requirements as before, at least we won't regress here. Uros.
Re: [PATCH] Fix for PR ipa/64503
On Thu, Jan 08, 2015 at 07:42:32PM +0100, Uros Bizjak wrote: I don't know how portable scalbnl actually is in reality, so it would be nice to hear from port maintainers whether say newlib, android, darwin, cygwin, aix etc. have it. Newlib has it. Other than that: exp2(), exp2f(), exp2l(): _XOPEN_SOURCE = 600 || _ISOC99_SOURCE || _POSIX_C_SOURCE = 200112L; or cc -std=c99 scalbln(), scalblnf(), scalblnl(): _XOPEN_SOURCE = 600 || _ISOC99_SOURCE || _POSIX_C_SOURCE = 200112L; or cc -std=c99 Since we are replacing exp2 with scalbln, we have the same requirements as before, at least we won't regress here. The patch is ok then. If it is missing somewhere, we can always check for it in configure and add a val *= pow (2.0, exp); fallback that should be more portable. Jakub
Re: [PATCH] Fix sporadic failure in g++.dg/tsan/aligned_vs_unaligned_race.C
On Jan 7, 2015, at 12:23 AM, Jakub Jelinek ja...@redhat.com wrote:
I'm fine with adding the no_sanitize_thread attribute, the patch LGTM
Thanks, I checked it in, the doc seemed trivial enough.
* tsan.c (pass_tsan::gate): Add no_sanitize_thread support.
(pass_tsan_O0::gate): Likewise.
* extend.texi (Function Attributes): Add no_sanitize_thread
documentation.
c-family:
* c-common.c (c_common_attribute_table): Add no_sanitize_thread.
Index: doc/extend.texi
===
--- doc/extend.texi (revision 219354)
+++ doc/extend.texi (revision 219355)
@@ -2205,6 +2205,7 @@ attributes are currently defined for fun
@code{returns_nonnull}, @code{gnu_inline},
@code{externally_visible}, @code{hot}, @code{cold}, @code{artificial},
@code{no_sanitize_address}, @code{no_address_safety_analysis},
+@code{no_sanitize_thread},
@code{no_sanitize_undefined}, @code{no_reorder}, @code{bnd_legacy},
@code{bnd_instrument},
@code{error} and @code{warning}.
@@ -3721,6 +3722,12 @@ The @code{no_address_safety_analysis} is
@code{no_sanitize_address} attribute, new code should use
@code{no_sanitize_address}.
+@item no_sanitize_thread
+@cindex @code{no_sanitize_thread} function attribute
+The @code{no_sanitize_thread} attribute on functions is used
+to inform the compiler that it should not instrument memory accesses
+in the function when compiling with the @option{-fsanitize=thread} option.
+
@item no_sanitize_undefined
@cindex @code{no_sanitize_undefined} function attribute
The @code{no_sanitize_undefined} attribute on functions is used
Index: c-family/c-common.c
===
--- c-family/c-common.c (revision 219354)
+++ c-family/c-common.c (revision 219355)
@@ -764,6 +764,9 @@ const struct attribute_spec c_common_att
{ no_sanitize_address,0, 0, true, false, false,
handle_no_sanitize_address_attribute,
false },
+ { no_sanitize_thread, 0, 0, true, false, false,
+ handle_no_sanitize_address_attribute,
+ false },
{ no_sanitize_undefined, 0, 0, true, false, false,
handle_no_sanitize_undefined_attribute,
false },
Index: tsan.c
===
--- tsan.c (revision 219354)
+++ tsan.c (revision 219355)
@@ -868,7 +868,9 @@ public:
opt_pass * clone () { return new pass_tsan (m_ctxt); }
virtual bool gate (function *)
{
- return (flag_sanitize SANITIZE_THREAD) != 0;
+ return ((flag_sanitize SANITIZE_THREAD) != 0
+ !lookup_attribute (no_sanitize_thread,
+DECL_ATTRIBUTES (current_function_decl)));
}
virtual unsigned int execute (function *) { return tsan_pass (); }
@@ -908,7 +910,9 @@ public:
/* opt_pass methods: */
virtual bool gate (function *)
{
- return (flag_sanitize SANITIZE_THREAD) != 0 !optimize;
+ return ((flag_sanitize SANITIZE_THREAD) != 0 !optimize
+ !lookup_attribute (no_sanitize_thread,
+ DECL_ATTRIBUTES (current_function_decl)));
}
virtual unsigned int execute (function *) { return tsan_pass (); }
Re: [PATCH] Fix ix86_expand_int_movcc (PR target/64338)
On Thu, Jan 08, 2015 at 07:37:44PM +0100, Uros Bizjak wrote:
Please put std::swap at the top, above code= assignment. Cosmetic, but
I noticed this during std::swap conversion. ;)
Ok. Put there also the diff = -diff; assignment and cf = ct; ct = 0; swap
to keep the order that used to be there before.
--- gcc/testsuite/g++.dg/opt/pr64338.C.jj 2015-01-07
10:18:04.740275018 +0100
+++ gcc/testsuite/g++.dg/opt/pr64338.C 2015-01-07 10:17:50.0 +0100
@@ -0,0 +1,29 @@
+// PR target/64338
+// { dg-do compile }
+// { dg-options -O2 }
+// { dg-additional-options -mtune=generic -march=i586 { target { {
i?86-*-* x86_64-*-* } ia32 } } }
Please use -mtune=i686, generic tuning setting changes over time ...
That doesn't ICE without the patch, so I've changed it to -mtune=nehalem
instead. So, here is what I've checked in.
2015-01-08 Jakub Jelinek ja...@redhat.com
PR target/64338
* config/i386/i386.c (ix86_expand_int_movcc): Don't reverse
compare_code when it is unconditionally overwritten afterwards.
Use ix86_reverse_condition instead of reverse_condition. Don't
change code if *reverse_condition* returned UNKNOWN and don't
swap ct/cf and negate diff in that case.
* g++.dg/opt/pr64338.C: New test.
--- gcc/config/i386/i386.c.jj 2015-01-08 10:19:00.337260146 +0100
+++ gcc/config/i386/i386.c 2015-01-08 20:09:30.716001199 +0100
@@ -20830,9 +20830,7 @@ ix86_expand_int_movcc (rtx operands[])
if (diff 0)
{
machine_mode cmp_mode = GET_MODE (op0);
-
- std::swap (ct, cf);
- diff = -diff;
+ enum rtx_code new_code;
if (SCALAR_FLOAT_MODE_P (cmp_mode))
{
@@ -20842,13 +20840,15 @@ ix86_expand_int_movcc (rtx operands[])
is not valid in general (we may convert non-trapping condition
to trapping one), however on i386 we currently emit all
comparisons unordered. */
- compare_code = reverse_condition_maybe_unordered (compare_code);
- code = reverse_condition_maybe_unordered (code);
+ new_code = reverse_condition_maybe_unordered (code);
}
else
+ new_code = ix86_reverse_condition (code, cmp_mode);
+ if (new_code != UNKNOWN)
{
- compare_code = reverse_condition (compare_code);
- code = reverse_condition (code);
+ std::swap (ct, cf);
+ diff = -diff;
+ code = new_code;
}
}
@@ -20986,9 +20986,7 @@ ix86_expand_int_movcc (rtx operands[])
if (cf == 0)
{
machine_mode cmp_mode = GET_MODE (op0);
-
- cf = ct;
- ct = 0;
+ enum rtx_code new_code;
if (SCALAR_FLOAT_MODE_P (cmp_mode))
{
@@ -20998,14 +20996,21 @@ ix86_expand_int_movcc (rtx operands[])
that is not valid in general (we may convert non-trapping
condition to trapping one), however on i386 we currently
emit all comparisons unordered. */
- code = reverse_condition_maybe_unordered (code);
+ new_code = reverse_condition_maybe_unordered (code);
}
else
{
- code = reverse_condition (code);
- if (compare_code != UNKNOWN)
+ new_code = ix86_reverse_condition (code, cmp_mode);
+ if (compare_code != UNKNOWN new_code != UNKNOWN)
compare_code = reverse_condition (compare_code);
}
+
+ if (new_code != UNKNOWN)
+ {
+ cf = ct;
+ ct = 0;
+ code = new_code;
+ }
}
if (compare_code != UNKNOWN)
--- gcc/testsuite/g++.dg/opt/pr64338.C.jj 2015-01-08 20:07:09.790383489
+0100
+++ gcc/testsuite/g++.dg/opt/pr64338.C 2015-01-08 20:11:26.756039590 +0100
@@ -0,0 +1,29 @@
+// PR target/64338
+// { dg-do compile }
+// { dg-options -O2 }
+// { dg-additional-options -mtune=nehalem -march=i586 { target { { i?86-*-*
x86_64-*-* } ia32 } } }
+
+enum O {};
+struct A { A (); };
+struct B { int fn1 (); };
+struct C { struct D; D *fn2 (); void fn3 (); int fn4 (); };
+struct F { void fn5 (const int = 0); };
+struct G { F *fn6 (); };
+struct H { int h; };
+struct C::D { friend class C; G *fn7 (); };
+O a;
+
+void
+C::fn3 ()
+{
+ int b = a;
+ H c;
+ if (b)
+fn2 ()-fn7 ()-fn6 ()-fn5 ();
+ double d;
+ if (fn4 ())
+d = c.h 0;
+ A e (b ? A () : A ());
+ B f;
+ f.fn1 () d fn2 ();
+}
Jakub
Re: [PATCH][ARM] FreeBSD arm support, EABI, v2
On 08.01.15 17:22, Richard Earnshaw wrote:
On 27/11/14 20:56, Andreas Tobler wrote:
Hi all,
this is the second attempt.
I reworked the issues Richard mentioned in the previous review.
I also found one issue which will break build/bootstrap if I pass
--enable-gnu-indirect-function, also fixed.
One thing which came up is the way we generate code for the
armv6*-*-freebsd* triplet versus the arm-*-freebsd* triplet.
I think the thing which confuses is the fact that we have only two fixed
triplets where we build a complete OS with. Means the whole OS is built
with the same optimization, not only the kernel or one binary.
For the armv6* we want to benefit from the cpu's functionality by
default. We build all __ARM_ARCH = 6 with TARGET_CPU_arm1176jzs,
on the other hand all __ARM_ARCH =5 will be built with TARGET_CPU_arm9.
Now who becomes arm-*-freebsd* and who becomes armv6*-*-freebsd*?
As tried above, we only know two triplets, so __ARM_ARCH = 6 becomes
armv6*-*-freebsd* and __ARM_ARCH =5 becomes arm-*-freebsd*.
armv8 is not yet in the portfolio and it will become something
different, either arm64 or aarch64, I do not know.
I'd like to keep this since our system compilers, clang and gcc-4.2.1
behave the same.
If we have to change here, we would confuse people quite a lot.
The whole thing is FreeBSD specific and does not touch others.
As usual, bootstrapped, cross compiled, tested.
Ok for trunk?
TIA,
Andreas
toplevel:
* configure.ac: Don't add ${libgcj} for arm*-*-freebsd*.
* configure: Regenerate.
gcc:
* config.gcc (arm*-*-freebsd*): New configuration.
* config/arm/freebsd.h: New file.
* config.host: Add extra components for arm*-*-freebsd*.
* config/arm/arm.h: Introduce MAX_SYNC_LIBFUNC_SIZE.
* config/arm/arm.c (arm_init_libfuncs): Use MAX_SYNC_LIBFUNC_SIZE.
libgcc:
* config.host (arm*-*-freebsd*): Add new configuration for
arm*-*-freebsd*.
* config/arm/freebsd-atomic.c: New file.
* config/arm/t-freebsd: Likewise.
* config/arm/unwind-arm.h: Add __FreeBSD__ to the list of
'PC-relative indirect' OS's.
libatomic:
* configure.tgt: Exclude arm*-*-freebsd* from try_ifunc.
libstdc++-v3:
* configure.host: Add arm*-*-freebsd* port_specific_symbol_files.
Sorry for the delay in responding, I've been OoO quite a bit over the
last month or so and not had much time for patch reviewing.
Thank you for the review. Also being very busy, I know what you're
talking about.
This is OK to go in. Most of the patch is now in OS specific files and
thus not really relevant to the CPU maintenance.
One item I do think you may need to think about is the definition of
SUBTARGET_EXTRA_LINK_SPEC. This picks the linker emulation setting.
But it's a build-time choice and seems to ignore a run-time -mbig-endian
or -mlittle-endian choice on the command line. Is this selection even
necessary? I don't remember ever having to do it on other OS ports -
the linker just picks the correct emulation based on the first object
file in the link list.
I don't think this is necessary. Certainly not yet. Might become a
future issue.
I also got your second mail.
If you're ok with, I'll commit the first hunk and send the undwind
update as separate patch again for review?
Thanks,
Andreas
Re: [Ping] Port of VTV for Cygwin and MinGW
A short recap again: Latest patch, changelog and a test program (further information about the program in the mail): https://gcc.gnu.org/ml/gcc-patches/2014-11/msg03368.html Approved: * gcc/config/i386/* * libgcc/* * libstdc++-v3/* * libvtv/* (Some changes made to three of these files. Listed in 'Not approved'.) Not approved: For the following two files I added checks, if TARGET_PECOFF is defined ( https://gcc.gnu.org/ml/gcc-patches/2014-10/msg00815.html ) * gcc/cp/vtable-class-hierarchy.c * gcc/varasm.c Reasons for changes in the following files stated in https://gcc.gnu.org/ml/gcc-patches/2014-10/msg00815.html and in the mail of the latest patch. Removed implementation of mprotect. * libvtv/vtv_malloc.cc Added extern C to the prototype of mprotect. * libvtv/vtv_malloc.h Exchanged call to TerminateProcess with call to abort in __fortify_fail. * libvtv/vtv_rts.cc Has been removed from the most recent patch. Just listed for completeness. * libiberty/obstack.c Regards, Patrick
Re: RFA: PATCH to factor out no_sanitize_undefined attribute check
On Thu, Jan 08, 2015 at 03:57:17PM -0500, Jason Merrill wrote: I noticed that we were repeating the same long test in lots of places and factored it out into a separate function. I'm not attached to the name. Tested x86_64-pc-linux-gnu, OK for trunk? As the predicate is very simple, wouldn't it be better to make it inline function in ubsan.h? I don't feel too strongly about it, so ok either way. commit 5a5f850a4d40a25cc3b1fc0120e844b1ac3f3eb0 Author: Jason Merrill ja...@redhat.com Date: Wed Jan 7 17:29:36 2015 -0500 gcc/ * ubsan.c (do_ubsan_in_current_function): New. (pass_ubsan::gate): Use it. * ubsan.h: Declare it. * convert.c (convert_to_integer): Use it. gcc/c-family/ * c-ubsan.c (ubsan_maybe_instrument_array_ref): Use do_ubsan_in_current_function. (ubsan_maybe_instrument_reference_or_call): Likewise. * c-ubsan.h: Declare it. gcc/cp/ * cp-gimplify.c (cp_genericize): Use do_ubsan_in_current_function. * decl.c (compute_array_index_type): Likewise. * init.c (build_vec_init): Likewise. * typeck.c (cp_build_binary_op): Likewise. Jakub
Re: [PATCH] Fix sporadic failure in g++.dg/tsan/aligned_vs_unaligned_race.C
On Jan 8, 2015, at 11:29 AM, Jakub Jelinek ja...@redhat.com wrote: I disagree. Busy waiting of this kind is not appropriate for the test suite, What busy waiting, there is none in the last version of the patch? tsan can't intercept the calls that you do through dlsym, because you explicitly bypass tsan in that case. Ah, yes, right, I had pthread_barrier_wait on the brain, sorry. The direct use of it would be problematic. The dlopen use of it, is safe. So, that removes the objection I had to his patch. Jakub, since he has a complete solution to the problem submitted with all the test cases fixed, I think it should go in. Any objections to approving it now?
Re: [PATCH] Small step towards tree-ssa-strlen improvements (PR tree-optimization/63989)
On 01/08/15 10:47, Jakub Jelinek wrote: Hi! This patch is a small step towards fixing that PR that I had sitting on my disk for quite a while, but didn't get to further steps so far. I'll try to at least get to the multibyte memcpy/memmove expanded as load followed by store, if the '\0' is known not to appear at all, or known to appear on the last byte, or on the first byte during stage4, but this part is self-contained enough that it should go in independently. Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? 2015-01-08 Jakub Jelinek ja...@redhat.com PR tree-optimization/63989 * params.def (PARAM_MAX_TRACKED_STRLENS): Increment default from 1000 to 1. * tree-ssa-strlen.c (get_strinfo): Moved earlier. (get_stridx): If we don't have a record for certain SSA_NAME, but it is POINTER_PLUS_EXPR of some SSA_NAME we do with constant offset, call get_stridx_plus_constant. (get_stridx_plus_constant): New function. (zero_length_string): Don't use get_stridx here. * gcc.dg/strlenopt-27.c: New test. I'll assume that cranking up MAX_TRACKED_STRLENS isn't a significant compile-time hit. OK for the trunk. jeff
Re: [PATCH] LRA: Fix caller-save store/restore instruction for large mode
On 01/08/15 08:58, Kito Cheng wrote: Hi Jeff: After discussion with Bin, he prefer just use gcc.c-torture/execute/scal-to-vec1.c instead of introduce new one, do you have any further comment on this patch? If you can use the existing test, then that's good for me. I believe that was the last question and that everything has been approved, right? jeff
Re: [RFC PATCH] Handle sequence in reg_set_p
On 01/08/15 05:23, Oleg Endo wrote:
Hi,
Currently reg_set_p doesn't handle sequence rtx, which I've identified
as the root cause of PR 64479. There is another alternative fix for the
PR, but I'd like to get some comments regarding letting reg_set_p also
handle sequence rtx:
Index: gcc/rtlanal.c
===
--- gcc/rtlanal.c (revision 218544)
+++ gcc/rtlanal.c (working copy)
@@ -875,17 +875,24 @@
{
/* We can be passed an insn or part of one. If we are passed an insn,
check if a side-effect of the insn clobbers REG. */
- if (INSN_P (insn)
- (FIND_REG_INC_NOTE (insn, reg)
- || (CALL_P (insn)
- ((REG_P (reg)
- REGNO (reg) FIRST_PSEUDO_REGISTER
- overlaps_hard_reg_set_p (regs_invalidated_by_call,
- GET_MODE (reg), REGNO (reg)))
- || MEM_P (reg)
- || find_reg_fusage (insn, CLOBBER, reg)
-return 1;
+ if (INSN_P (insn) FIND_REG_INC_NOTE (insn, reg))
+return true;
+ /* After delay slot handling, call and branch insns might be in a
+ sequence. Check all the elements there. */
+ if (INSN_P (insn) GET_CODE (PATTERN (insn)) == SEQUENCE)
+for (int i = 0; i XVECLEN (PATTERN (insn), 0); ++i)
+ if (reg_set_p (reg, XVECEXP (PATTERN (insn), 0, i)))
+ return true;
+
+ if (CALL_P (insn)
+ ((REG_P (reg) REGNO (reg) FIRST_PSEUDO_REGISTER
+ overlaps_hard_reg_set_p (regs_invalidated_by_call,
+ GET_MODE (reg), REGNO (reg)))
+ || MEM_P (reg)
+ || find_reg_fusage (insn, CLOBBER, reg)))
+ return true;
+
return set_of (reg, insn) != NULL_RTX;
}
Would that be OK to do if it passes testing, or is there something that
could potentially/obviously blow up?
It looks reasonable to me.
Any particular reason why the SEQUENCE handling isn't done first, then
the REG_INC and CALL insn handling? I'd probably explicitly return
false if we had a sequence and none of its elements returned true.
There's no need to check anything on the toplevel SEQUENCE to the best
of my knowledge.
jeff
Re: [PATCH] Fix up DSE - PR middle-end/64388, target/55023
On 01/06/15 07:08, Jakub Jelinek wrote:
Hi!
On Mon, Jan 05, 2015 at 10:31:17PM +0100, Jakub Jelinek wrote:
Or you could e.g. do the
if (HARD_FRAME_POINTER_IS_ARG_POINTER
!reload_completed
SIBLING_CALL_P (insn))
{ add_wild_read (bb_info); return; }
case first, then compute const_call and memset_call,
if (const_call || memset_call)
{ current_big_block }
else if (reload_completed SIBLING_CALL_P (insn))
add_wild_read (bb_info);
else
add_non_frame_wild_read (bb_info);
That way, you would not punish const/memset calls unnecessarily after reload
when they are sibling calls.
So what about this way? Even for the HARD_FRAME_POINTER_IS_ARG_POINTER
before reload case, there is no reason for wild read IMHO, just setting
frame_read should do all that is necessary. Bootstrapped/regtested on
x86_64-linux and i686-linux, tested on the pr55023 testcase with cross
to hppa-linux. Ok for trunk?
2015-01-06 Jakub Jelinek ja...@redhat.com
PR target/55023
PR middle-end/64388
* dse.c (struct insn_info): Mention frame_read set also
before reload for tail calls on some targets.
(scan_insn): Revert 2014-12-22 change. Set frame_read
also before reload for tail calls if
HARD_FRAME_POINTER_IS_ARG_POINTER. Call add_wild_read
instead of add_non_frame_wild_read for non-const/memset
tail calls after reload.
OK with the typo John pointed out fixed.
jeff
Re: [PATCH][ARM] FreeBSD ARM support, EABI, v3
On 08.01.15 17:27, Richard Earnshaw wrote:
On 29/12/14 18:44, Andreas Tobler wrote:
All,
here is the third attempt to support ARM with FreeBSD.
In the meantime we found another issue in the unwinder where I had to
adapt some stuff.
The unwind_phase2_forced function in libgcc calls a stop_fn function.
This stop_fn is in FreeBSD's libthr implementation and is called
thread_unwind_stop. This thread_unwind_stop is a generic function used
on all FreeBSD archs.
The issue is now that this thread_unwind_stop expects a double int for
the exception_class, like on every other arch. For ARM EABI this
exception_class is an array of char which is passed in one register as
pointer vs. two registers for a double int.
To solve this issue we defined the exception_class as double integer for
FreeBSD.
This adaptation reduced the failure count in libstdc++ by about 40 fails.
I build and test this port on a regular basis and I post the results to
the usual place.
...
Umm, sorry, just seen this update to the previous patch.
The changes to the exception unwinding look a bit more involved. Could
you separate that out into a separate patch, so that it's easier to see
what you're changing?
Ok, here the mentioned part as separate diff. The comments are above.
The CL below :)
Thank you very much!
Andreas
gcc:
* ginclude/unwind-arm-common.h (_Uwind_Control_Block): Define
exception_class as double integer for FreeBSD ARM.
(_Unwind_Exception): Define _Unwind_Exception_Class as double integer
for FreeBSD ARM.
libstc++-v3:
* libsupc++/unwind-cxx.h (__is_gxx_exception_class,
__is_dependent_exception): Exclude FreeBSD ARM from the
__ARM_EABI_UNWINDER__ ifdef.
Index: gcc/ginclude/unwind-arm-common.h
===
--- gcc/ginclude/unwind-arm-common.h(revision 219357)
+++ gcc/ginclude/unwind-arm-common.h(working copy)
@@ -82,7 +82,11 @@
struct _Unwind_Control_Block
{
+#ifdef __FreeBSD__
+ unsigned exception_class __attribute__((__mode__(__DI__)));
+#else
char exception_class[8];
+#endif
void (*exception_cleanup)(_Unwind_Reason_Code, _Unwind_Control_Block *);
/* Unwinder cache, private fields for the unwinder's use */
struct
@@ -181,7 +185,11 @@
/* Support functions for the PR. */
#define _Unwind_Exception _Unwind_Control_Block
+#ifdef __FreeBSD__
+ typedef unsigned _Unwind_Exception_Class __attribute__((__mode__(__DI__)));
+#else
typedef char _Unwind_Exception_Class[8];
+#endif
void * _Unwind_GetLanguageSpecificData (_Unwind_Context *);
_Unwind_Ptr _Unwind_GetRegionStart (_Unwind_Context *);
Index: libstdc++-v3/libsupc++/unwind-cxx.h
===
--- libstdc++-v3/libsupc++/unwind-cxx.h (revision 219357)
+++ libstdc++-v3/libsupc++/unwind-cxx.h (working copy)
@@ -235,7 +235,7 @@
return reinterpret_cast__cxa_dependent_exception *(exc + 1) - 1;
}
-#ifdef __ARM_EABI_UNWINDER__
+#if defined (__ARM_EABI_UNWINDER__) !defined (__FreeBSD__)
static inline bool
__is_gxx_exception_class(_Unwind_Exception_Class c)
{
@@ -309,13 +309,7 @@
c[6] = 'R';
c[7] = '\0';
}
-
-static inline void*
-__gxx_caught_object(_Unwind_Exception* eo)
-{
- return (void*)eo-barrier_cache.bitpattern[0];
-}
-#else // !__ARM_EABI_UNWINDER__
+#else // !__ARM_EABI_UNWINDER__ || __FreeBSD__
// This is the primary exception class we report -- GNUCC++\0.
const _Unwind_Exception_Class __gxx_primary_exception_class
= _Unwind_Exception_Class) 'G'
@@ -339,6 +333,16 @@
8 | (_Unwind_Exception_Class) '+')
8 | (_Unwind_Exception_Class) '\x01');
+const _Unwind_Exception_Class __gxx_forced_unwind_class
+= _Unwind_Exception_Class) 'G'
+ 8 | (_Unwind_Exception_Class) 'N')
+8 | (_Unwind_Exception_Class) 'U')
+ 8 | (_Unwind_Exception_Class) 'C')
+ 8 | (_Unwind_Exception_Class) 'F')
+ 8 | (_Unwind_Exception_Class) 'O')
+8 | (_Unwind_Exception_Class) 'R')
+ 8 | (_Unwind_Exception_Class) '\0');
+
static inline bool
__is_gxx_exception_class(_Unwind_Exception_Class c)
{
@@ -346,6 +350,12 @@
|| c == __gxx_dependent_exception_class;
}
+static inline bool
+__is_gxx_forced_unwind_class(_Unwind_Exception_Class c)
+{
+ return c == __gxx_forced_unwind_class;
+}
+
// Only checks for primary or dependent, but not that it is a C++ exception at
// all.
static inline bool
@@ -357,7 +367,18 @@
#define __GXX_INIT_PRIMARY_EXCEPTION_CLASS(c) c = __gxx_primary_exception_class
#define __GXX_INIT_DEPENDENT_EXCEPTION_CLASS(c) \
c = __gxx_dependent_exception_class
+#define __GXX_INIT_FORCED_UNWIND_CLASS(c) c = __gxx_forced_unwind_class
+#endif // __ARM_EABI_UNWINDER__ !__FreeBSD__
+#ifdef __ARM_EABI_UNWINDER__
+static inline void*
+__gxx_caught_object(_Unwind_Exception* eo)
+{
+return (void*)eo-barrier_cache.bitpattern[0];
+}
+
+#else //
RFA: PATCH to factor out no_sanitize_undefined attribute check
I noticed that we were repeating the same long test in lots of places
and factored it out into a separate function. I'm not attached to the name.
Tested x86_64-pc-linux-gnu, OK for trunk?
commit 5a5f850a4d40a25cc3b1fc0120e844b1ac3f3eb0
Author: Jason Merrill ja...@redhat.com
Date: Wed Jan 7 17:29:36 2015 -0500
gcc/
* ubsan.c (do_ubsan_in_current_function): New.
(pass_ubsan::gate): Use it.
* ubsan.h: Declare it.
* convert.c (convert_to_integer): Use it.
gcc/c-family/
* c-ubsan.c (ubsan_maybe_instrument_array_ref): Use
do_ubsan_in_current_function.
(ubsan_maybe_instrument_reference_or_call): Likewise.
* c-ubsan.h: Declare it.
gcc/cp/
* cp-gimplify.c (cp_genericize): Use do_ubsan_in_current_function.
* decl.c (compute_array_index_type): Likewise.
* init.c (build_vec_init): Likewise.
* typeck.c (cp_build_binary_op): Likewise.
diff --git a/gcc/c-family/c-ubsan.c b/gcc/c-family/c-ubsan.c
index f2db494..c195c7f 100644
--- a/gcc/c-family/c-ubsan.c
+++ b/gcc/c-family/c-ubsan.c
@@ -364,9 +364,7 @@ void
ubsan_maybe_instrument_array_ref (tree *expr_p, bool ignore_off_by_one)
{
if (!ubsan_array_ref_instrumented_p (*expr_p)
- current_function_decl != NULL_TREE
- !lookup_attribute (no_sanitize_undefined,
- DECL_ATTRIBUTES (current_function_decl)))
+ do_ubsan_in_current_function ())
{
tree op0 = TREE_OPERAND (*expr_p, 0);
tree op1 = TREE_OPERAND (*expr_p, 1);
@@ -386,9 +384,7 @@ static tree
ubsan_maybe_instrument_reference_or_call (location_t loc, tree op, tree ptype,
enum ubsan_null_ckind ckind)
{
- if (current_function_decl == NULL_TREE
- || lookup_attribute (no_sanitize_undefined,
- DECL_ATTRIBUTES (current_function_decl)))
+ if (!do_ubsan_in_current_function ())
return NULL_TREE;
tree type = TREE_TYPE (ptype);
diff --git a/gcc/c-family/c-ubsan.h b/gcc/c-family/c-ubsan.h
index b1fe5f1..fb379c8 100644
--- a/gcc/c-family/c-ubsan.h
+++ b/gcc/c-family/c-ubsan.h
@@ -31,4 +31,7 @@ extern void ubsan_maybe_instrument_array_ref (tree *, bool);
extern void ubsan_maybe_instrument_reference (tree);
extern void ubsan_maybe_instrument_member_call (tree, bool);
+/* Declare this here as well as in ubsan.h. */
+extern bool do_ubsan_in_current_function (void);
+
#endif /* GCC_C_UBSAN_H */
diff --git a/gcc/convert.c b/gcc/convert.c
index 0491986..fc1b93c 100644
--- a/gcc/convert.c
+++ b/gcc/convert.c
@@ -885,9 +885,7 @@ convert_to_integer (tree type, tree expr)
case REAL_TYPE:
if (flag_sanitize SANITIZE_FLOAT_CAST
- current_function_decl != NULL_TREE
- !lookup_attribute (no_sanitize_undefined,
-DECL_ATTRIBUTES (current_function_decl)))
+ do_ubsan_in_current_function ())
{
expr = save_expr (expr);
tree check = ubsan_instrument_float_cast (loc, type, expr, expr);
diff --git a/gcc/cp/cp-gimplify.c b/gcc/cp/cp-gimplify.c
index a23076f..33dce29 100644
--- a/gcc/cp/cp-gimplify.c
+++ b/gcc/cp/cp-gimplify.c
@@ -1350,9 +1350,7 @@ cp_genericize (tree fndecl)
cp_genericize_tree (DECL_SAVED_TREE (fndecl));
if (flag_sanitize SANITIZE_RETURN
- current_function_decl != NULL_TREE
- !lookup_attribute (no_sanitize_undefined,
- DECL_ATTRIBUTES (current_function_decl)))
+ do_ubsan_in_current_function ())
cp_ubsan_maybe_instrument_return (fndecl);
/* Do everything else. */
diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index 2fea106..c0fc009 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -8602,10 +8602,7 @@ compute_array_index_type (tree name, tree size, tsubst_flags_t complain)
stabilize_vla_size (itype);
if (flag_sanitize SANITIZE_VLA
- current_function_decl != NULL_TREE
- !lookup_attribute (no_sanitize_undefined,
-DECL_ATTRIBUTES
-(current_function_decl)))
+ do_ubsan_in_current_function ())
{
/* We have to add 1 -- in the ubsan routine we generate
LE_EXPR rather than LT_EXPR. */
diff --git a/gcc/cp/init.c b/gcc/cp/init.c
index 6f32492..3bd470b 100644
--- a/gcc/cp/init.c
+++ b/gcc/cp/init.c
@@ -3575,10 +3575,7 @@ build_vec_init (tree base, tree maxindex, tree init,
/* Don't check an array new when -fno-exceptions. */
}
else if (flag_sanitize SANITIZE_BOUNDS
- current_function_decl
- !lookup_attribute (no_sanitize_undefined,
- DECL_ATTRIBUTES
- (current_function_decl)))
+ do_ubsan_in_current_function ())
{
/* Make sure the last element of the initializer is in bounds. */
finish_expr_stmt
diff --git a/gcc/cp/typeck.c b/gcc/cp/typeck.c
index b4af8b0..fb0ffd1 100644
--- a/gcc/cp/typeck.c
+++ b/gcc/cp/typeck.c
@@ -4973,9 +4973,7 @@ cp_build_binary_op (location_t location,
if ((flag_sanitize (SANITIZE_SHIFT | SANITIZE_DIVIDE
| SANITIZE_FLOAT_DIVIDE))
!processing_template_decl
- current_function_decl != 0
- !lookup_attribute (no_sanitize_undefined,
-
Re: [PATCH] Fix sporadic failure in g++.dg/tsan/aligned_vs_unaligned_race.C
On Thu, Jan 08, 2015 at 01:07:02PM -0800, Mike Stump wrote: On Jan 8, 2015, at 11:29 AM, Jakub Jelinek ja...@redhat.com wrote: I disagree. Busy waiting of this kind is not appropriate for the test suite, What busy waiting, there is none in the last version of the patch? It was still while (... != i - 1), wasn't it? While pthread_barrier_wait/futex would typically only wake you up when needed. tsan can't intercept the calls that you do through dlsym, because you explicitly bypass tsan in that case. Ah, yes, right, I had pthread_barrier_wait on the brain, sorry. The direct use of it would be problematic. The dlopen use of it, is safe. So, that removes the objection I had to his patch. Jakub, since he has a complete solution to the problem submitted with all the test cases fixed, I think it should go in. Any objections to approving it now? LGTM. Jakub
Patch RFA: Support for building Go tools
This patch adds support to the GCC tree for building tools that are
used with Go. There are two external used tools (go, gofmt) and one
tool used internally by go (cgo). This patch is pure machinery, with
no source code. The tools are not built by default, only when go is
enabled using --enable-languages. For the moment the tools are also
not built when building a cross-compiler, although I hope to change
that when I figure out what is needed.
The tools work just as they do when built for the gc compiler, only
they use gccgo instead of gc. For documentation on these tools and
what they do see http://golang.org/cmd/go ,
http://golang.org/cmd/gofmt , http://golang.org/cmd/cgo .
This patch parallels the mechanism used in the existing gnattools
directory for building Ada tools.
Could the build machinery maintainers please take a look and let me
know if this is OK? Thanks.
Lynn, please also take a look and see if this works for you.
The first attachment is the real changes for review. The second
attachment is a compressed patch for the generated files, for
convenience for anybody who wants to try this out.
Ian
Index: Makefile.def
===
--- Makefile.def(revision 219358)
+++ Makefile.def(working copy)
@@ -120,6 +120,7 @@ host_modules= { module= lto-plugin; boot
extra_configure_flags='--enable-shared
@extra_linker_plugin_flags@ @extra_linker_plugin_configure_flags@';
extra_make_flags='@extra_linker_plugin_flags@'; };
host_modules= { module= libcc1; extra_configure_flags=--enable-shared; };
+host_modules= { module= gotools; };
target_modules = { module= libstdc++-v3;
bootstrap=true;
@@ -363,6 +364,8 @@ dependencies = { module=all-lto-plugin;
dependencies = { module=configure-libcc1; on=configure-gcc; };
dependencies = { module=all-libcc1; on=all-gcc; };
+dependencies = { module=all-gotools; on=all-target-libgo; };
+
dependencies = { module=all-utils; on=all-libiberty; };
dependencies = { module=configure-mpfr; on=all-gmp; };
Index: configure.ac
===
--- configure.ac(revision 219358)
+++ configure.ac(working copy)
@@ -140,7 +140,7 @@ host_libs=intl libiberty opcodes bfd re
# binutils, gas and ld appear in that order because it makes sense to run
# make check in that particular order.
# If --enable-gold is used, gold may replace ld.
-host_tools=texinfo flex bison binutils gas ld fixincludes gcc cgen sid sim
gdb gprof etc expect dejagnu m4 utils guile fastjar gnattools libcc1
+host_tools=texinfo flex bison binutils gas ld fixincludes gcc cgen sid sim
gdb gprof etc expect dejagnu m4 utils guile fastjar gnattools libcc1 gotools
# libgcj represents the runtime libraries only used by gcj.
libgcj=target-libffi \
Index: gcc/go/config-lang.in
===
--- gcc/go/config-lang.in (revision 219358)
+++ gcc/go/config-lang.in (working copy)
@@ -29,6 +29,7 @@ language=go
compilers=go1\$(exeext)
target_libs=target-libgo target-libffi target-libbacktrace
+lang_dirs=gotools
# The Go frontend is written in C++, so we need to build the C++
# compiler during stage 1.
Index: gotools/Makefile.am
===
--- gotools/Makefile.am (revision 0)
+++ gotools/Makefile.am (working copy)
@@ -0,0 +1,114 @@
+# Makefile for gotools
+# Copyright 2015 Free Software Foundation, Inc.
+#
+# This file is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 3 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; see the file COPYING3. If not see
+# http://www.gnu.org/licenses/.
+
+ACLOCAL_AMFLAGS = -I ./config -I ../config
+
+gcc_version := $(shell $(GCC_FOR_TARGET) -dumpversion)
+
+libexecsubdir = $(libexecdir)/gcc/$(target_noncanonical)/$(gcc_version)
+
+mkinstalldirs = $(SHELL) $(toplevel_srcdir)/mkinstalldirs
+PWD_COMMAND = $${PWDCMD-pwd}
+STAMP = echo timestamp
+
+libgodir = ../$(target_noncanonical)/libgo
+LIBGODEP = $(libgodir)/libgo.la
+
+GOCFLAGS = $(CFLAGS_FOR_TARGET)
+GOCOMPILE = $(GOC) $(GOCFLAGS)
+
+AM_LDFLAGS = -L $(libgodir) -L $(libgodir)/.libs -static-libgo
+GOLINK = $(GOC) $(AM_GOCFLAGS) $(LDFLAGS) $(AM_LDFLAGS) -o $@
+
+cmdsrcdir = $(srcdir)/../libgo/go/cmd
+
+go_cmd_go_files = \
+ $(cmdsrcdir)/go/build.go \
+ $(cmdsrcdir)/go/clean.go \
+ $(cmdsrcdir)/go/main.go \
+
Re: [Patch, libstdc++/64239] Use std::swap instead of swap in regex
On Wed, Jan 7, 2015 at 4:39 AM, Jonathan Wakely jwak...@redhat.com wrote:
No blank line here in the ChangeLog.
Done.
This is swapping iterators, which can be user-defined types, so it
should support finding a swap function by ADL, i.e.
Done.
Also, there should be a new test, since apparently we don't have any
test that tries to call match_results::swap(match_results).
Done.
--
Regards,
Tim Shen
commit 90118704de6214d9a9ce5d82fea8d364d758bc60
Author: timshen tims...@google.com
Date: Tue Jan 6 19:30:27 2015 -0800
PR libstdc++/64239
* include/bits/regex.h (match_results::swap): Use std::swap
instead of swap.
* include/bits/regex_compiler.tcc (_Compiler::_M_quantifier):
Likewise.
* testsuite/28_regex/match_results/swap.cc: New testcase.
diff --git a/libstdc++-v3/include/bits/regex.h
b/libstdc++-v3/include/bits/regex.h
index 9b7ed8c..52c2384 100644
--- a/libstdc++-v3/include/bits/regex.h
+++ b/libstdc++-v3/include/bits/regex.h
@@ -1863,6 +1863,7 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
void
swap(match_results __that)
{
+ using std::swap;
_Base_type::swap(__that);
swap(_M_begin, __that._M_begin);
}
diff --git a/libstdc++-v3/include/bits/regex_compiler.tcc
b/libstdc++-v3/include/bits/regex_compiler.tcc
index 57bafa3..33d7118 100644
--- a/libstdc++-v3/include/bits/regex_compiler.tcc
+++ b/libstdc++-v3/include/bits/regex_compiler.tcc
@@ -276,7 +276,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
{
auto __tmp = (*_M_nfa)[__stack.top()];
__stack.pop();
- swap(__tmp._M_next, __tmp._M_alt);
+ std::swap(__tmp._M_next, __tmp._M_alt);
}
}
_M_stack.push(__e);
diff --git a/libstdc++-v3/testsuite/28_regex/match_results/swap.cc
b/libstdc++-v3/testsuite/28_regex/match_results/swap.cc
new file mode 100644
index 000..18248c1
--- /dev/null
+++ b/libstdc++-v3/testsuite/28_regex/match_results/swap.cc
@@ -0,0 +1,43 @@
+// { dg-options -std=gnu++11 }
+
+//
+// Copyright (C) 2015 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library. This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+//
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+// GNU General Public License for more details.
+//
+// You should have received a copy of the GNU General Public License along
+// with this library; see the file COPYING3. If not see
+// http://www.gnu.org/licenses/.
+
+#include regex
+#include testsuite_hooks.h
+
+void
+test01()
+{
+ bool test __attribute__((unused)) = true;
+
+ std::cmatch m;
+ std::regex_match(a, m, std::regex(a));
+ std::cmatch mm1 = m, mm2;
+ mm1.swap(mm2);
+ VERIFY(m == mm2);
+ std::swap(mm1, mm2);
+ VERIFY(m == mm1);
+}
+
+int
+main()
+{
+ test01();
+ return 0;
+}
[PATCH, committed] New jit API entrypoint: gcc_jit_context_set_logfile
When attempting to debug libgccjit embedded inside PyPy I found I needed a detailed log that tracked the various activity within the library. This commit adds a new API entrypoint: gcc_jit_context_set_logfile allowing detailed information to be logged to a FILE *, with logging being mostly a no-op for the default case where no logfile has been enabled. An example logfile can be seen as part of the commit, appearing in the Internals documentation. As well as for debugging, this may be of use for newcomers to libgccjit's internals, to see how it fits together. Committed to trunk as r219357. gcc/jit/ChangeLog: * Make-lang.in (jit_OBJS): Add jit/jit-logging.o. * docs/internals/index.rst (Overview of code structure): Mention gcc_jit_context_set_logfile, and embed the example logfile. * docs/internals/test-hello-world.exe.log.txt: New file: example of a logfile. * docs/topics/contexts.rst (Debugging): Add documentation for gcc_jit_context_set_logfile. * docs/_build/texinfo/libgccjit.texi: Regenerate. * dummy-frontend.c: Include jit-logging.h. (jit_langhook_init): Assert that there is an active playback context. If it has a logger, log entry/exit to this function. (jit_langhook_write_globals): Likewise. * jit-common.h (gcc::jit::logger): New forward declaration. * jit-logging.c: New file. * jit-logging.h: New file. * jit-playback.c: Include jit-logging.h. (gcc::jit::playback::context::context): Initialize the log_user base class from the recording context's logger (if any). Use JIT_LOG_SCOPE to log entry/exit from the function body. (gcc::jit::playback::context::~context): Use JIT_LOG_SCOPE to log entry/exit from the function body. (gcc::jit::playback::build_stmt_list): Likewise. (gcc::jit::playback::function::postprocess): Likewise. (gcc::jit::playback::context::compile): Likewise. Log the entry/exit to toplev::main and toplev::finalize. Log the fake argv passed to toplev::main. (gcc::jit::playback::context::acquire_mutex): Use JIT_LOG_SCOPE to log entry/exit from the function body. (gcc::jit::playback::context::release_mutex): Likewise. (gcc::jit::playback::context::make_fake_args): Likewise. (gcc::jit::playback::context::extract_any_requested_dumps): Likewise. (gcc::jit::playback::context::convert_to_dso): Likewise. Also, log the arguments that the driver is invoked with. (gcc::jit::playback::context::dlopen_built_dso): Likewise. Pass the logger to the result object. (gcc::jit::playback::context::replay): Use JIT_LOG_SCOPE to log entry/exit from the function body. (gcc::jit::playback::context::dump_generated_code): Likewise. (gcc::jit::playback::context::handle_locations): Likewise. * jit-playback.h (gcc::jit::playback::context): Make this be a subclass of gcc::jit::log_user. * jit-recording.c: Include jit-logging.h. (gcc::jit::recording::context::context: Initialize the logger to NULL for root contexts, or to the parent's logger for child contexts. (gcc::jit::recording::context::~context): Use JIT_LOG_SCOPE to log entry/exit from the function body. (gcc::jit::recording::context::replay_into): Likewise. (gcc::jit::recording::context::disassociate_from_playback): Likewise. (gcc::jit::recording::context::compile): Likewise. (recording::context::add_error_va): Likewise. Also, log the error. (gcc::jit::recording::context::validate): Use JIT_LOG_SCOPE to log entry/exit from the function body. * jit-recording.h: Include jit-logging.h. (gcc::jit::recording::context): Make this be a subclass of gcc::jit::log_user. * jit-result.c: Include jit-common.h and jit-logging.h. (gcc::jit::result::result): Add logger param, recording it. Use JIT_LOG_SCOPE to log entry/exit from the function body. (gcc::jit::result::~result(): Use JIT_LOG_SCOPE to log entry/exit from the function body. (gcc::jit::result::get_code): Likewise. * jit-result.h (gcc::jit::result): Make this be a subclass of gcc::jit::log_user. (gcc::jit::result::result): Add logger parameter. * libgccjit++.h (gccjit::context::set_logfile): New function. * libgccjit.c: Include jit-logging.h. (gcc_jit_context_acquire): Log the context. (gcc_jit_context_release): Use JIT_LOG_FUNC to log entry/exit from the function body, and log the context. (gcc_jit_context_new_child_context): Likewise, logging both contexts. (gcc_jit_context_new_location): Use JIT_LOG_FUNC to log entry/exit from the function body. (gcc_jit_context_get_type): Likewise.
Re: [PATCH] Fix for PR ipa/64503
On Jan 8, 2015, at 9:04 AM, Jakub Jelinek ja...@redhat.com wrote: I don't know how portable scalbnl actually is in reality, so it would be nice to hear from port maintainers whether say newlib, android, darwin, cygwin, aix etc. have it. darwin has it.
Re: [PATCH, fortran] PR fortran/60255 Deferred character length
Dear Andre, Thanks for the patch. As I have said to you, off list, I think that the _size field in the vtable should contain the kind information and that the _len field should carry the length of the string in bytes. I think that it is better to optimise array access this way than to avoid the division in evaluating LEN (). I am happy to accept contrary opinions from the others. I do not believe that the bind_c issue is an issue. Your patch correctly deals with it IMHO. Subject to the above change in the value of _len, I think that your patch is OK for trunk. With best regards Paul On 4 January 2015 at 13:40, Andre Vehreschild ve...@gmx.de wrote: Hi Janus, hi Paul, hi Tobias, Janus: During code review, I found that I had the code in gfc_get_len_component() duplicated. So I now reintroduced and documented the routine making is more commonly usable and added more documentation. The call sites are now simplify.c (gfc_simplify_len) and trans-expr.c (gfc_trans_pointer_assignment). Attached is the reworked version of the patch. Paul, Tobias: Can one of you have a look at line 253 of the patch? I need some expertise on the bind_c behavior. My patch needs the check for is_bind_c added in trans_expr.c (gfc_conv_expr) to prevent mistyping an associated variable in a select type() during the conv. Background: This code fragment taken from the testcase in the patch: MODULE m contains subroutine bar (arg, res) class(*) :: arg character(100) :: res select type (w = arg) type is (character(*)) write (res, '(I2)') len(w) end select end subroutine END MODULE has the conditions required for line trans-expr.c:6630 of gfc_conv_expr when the associate variable w is converted. This transforms the type of the associate variable to something unexpected in the further processing leading to some issues during fortraning. Janus told me, that the f90_type has been abused for some other things (unlimited polymorphic treatment). Although I believe that reading the comments above the if in question, the check I had to enhance is treating bind_c stuff (see the threads content for more). I would feel safer when one of you gfortran gurus can have a look and given an opinion, whether the change is problematic. I couldn't figure why w is resolved to meet the criteria (any ideas). Btw, all regtest are ok reporting no issues at all. Bootstraps and regtests ok on x86_64-linux-gnu Regards, Andre On Sat, 3 Jan 2015 16:45:07 +0100 Janus Weil ja...@gcc.gnu.org wrote: Hi Andre, For the second one (in gfc_conv_expr), I don't directly see how it's related to deferred char-len. Why is this change needed? That change is needed, because in some rare case where an associated variable in a select type () is used, then the type and f90_type match the condition while them not really being in a bind_c context. Therefore I have added the check for bind_c. Btw, I now have removed the TODO, because that case is covered by the regression tests. I don't understand how f90_type can be BT_VOID without being in a BIND_C context, but I'm not really a ISO_C_BINDING expert. Which test case is the one that triggered this? This case is triggered by the test-case in the patch, where in the select type (w = arg) in module m routine bar the w meets the criteria to make the condition become true. The type of w is then fixed and gfortran would terminate, because the type of w would be set be and BT_INTEGER. I tried to backtrace where this is coming from, but to no success. In the resolve () of the select type it looks all quite ok, but in the trans stage the criteria are met. Most intriguing to me is, that in the condition we are talking about the type of w and f90_type of the derived class' ts (expr-ts.u.derived-ts.f90_type) of w is examined. But expr-ts.u.derived-ts does not describe the type of w, but of the class w is associate with __STAR... So I am not quite sure how to fix this, if this really needs fixing. When I understand you right, then f90_type should only be set in a bind_c context, so adding that check wouldn't hurt, right? Yes, in principle adding the check for attr.bind_c looks ok to me (alternatively one could also check for attr.unlimited_polymorphic). I think originally BT_VOID was indeed only used in a bind_c context, but recently it has also been 'hijacked' for unlimited polymorphism, e.g. for the STAR symbol and some of the components of the intrinsic vtabs. What I don't really understand is why these problems are triggered by your patch now and have not crept up earlier in other use-cases of CLASS(*). 3) The function 'gfc_get_len_component' that you're introducing is only called in a single place. Do you expect this to be useful in other places in the future, or could one remove the function and insert the code inline? In one of the first versions it
Re: [PATCH] Fix sporadic failure in g++.dg/tsan/aligned_vs_unaligned_race.C
On Jan 7, 2015, at 2:44 PM, Bernd Edlinger bernd.edlin...@hotmail.de wrote: Here is a new patch, that uses this method on all tsan tests, which seem to depend on sleep(1), and which have unstable results because of that. OK for trunk? No. So, I think this is wrong. The problem is that any synchronizing primitive can trapped by tsan and added to the analysis, and if it resolves the race, then it should change the analysis that tsan produces. The point of the atomic set, load primitives and volatile, the code-gen is a single instruction that tsan by definition, won’t now, or ever instrument because we tell it explicitly, don’t with no_sanitize_thread. Since gcc now supports no_sanitize_thread, I don’t know of any reason why the test cases should not now be fixed to use step.
Re: [PATCH] Fix sporadic failure in g++.dg/tsan/aligned_vs_unaligned_race.C
On Thu, Jan 08, 2015 at 11:24:21AM -0800, Mike Stump wrote: On Jan 7, 2015, at 2:44 PM, Bernd Edlinger bernd.edlin...@hotmail.de wrote: Here is a new patch, that uses this method on all tsan tests, which seem to depend on sleep(1), and which have unstable results because of that. OK for trunk? No. So, I think this is wrong. The problem is that any synchronizing primitive can trapped by tsan and added to the analysis, and if it resolves the race, then it should change the analysis that tsan produces. I disagree. Busy waiting of this kind is not appropriate for the testsuite, we burn already way too much time and adding to that is undesirable. tsan can't intercept the calls that you do through dlsym, because you explicitly bypass tsan in that case. The point of the atomic set, load primitives and volatile, the code-gen is a single instruction that tsan by definition, won’t now, or ever instrument because we tell it explicitly, don’t with no_sanitize_thread. Since gcc now supports no_sanitize_thread, I don’t know of any reason why the test cases should not now be fixed to use step. See above. Jakub
