Re: [Patch, AArch64, testsuite] PR63971: Revert test_frame_* patch.
On Jan 14, 2015, at 3:50 AM, Tejas Belagod tejas.bela...@arm.com wrote: As agreed here (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63971), please can I reverse Andrew's patch out(https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02916.html)? Ok. Unless someone objects to a reversion like this, when the author of a patch says it should be reverted… that’s all the approval it needs, though, people can always ask for a review for any reason they want.
Re: [PATCH/expand] PR64011 Adjust bitsize when partial overflow happen for big-endian
On 15/01/15 03:51, Jeff Law wrote:
On 01/14/15 15:31, Jiong Wang wrote:
agree, and I think the truncation is needed otherwise there may have ICE
on some target.
and I found current gcc LOCATION info is very good !
have done an experimental hack on at expand_assignment: 4931 where the
tree is expanded,
gcc could give quite useful accurate warning based on tree LOCATION info.
./cc1 -O2 -mbig-endian pr48335-2.c
pr48335-2.c: In function ‘f5’:
pr48335-2.c:19:29: warning: overflow here !
((U *)((char *) s.d + 1))[3] = x;
^
while we need to add warning at store_bit_field_using_insv where
there is no accurate LOCATION info. but looks like it's acceptable?
pr48335-2.c:19:33: warning: overflow here !
((U *)((char *) s.d + 1))[3] = x;
^
Yes, I think we're on the right track now -- warn and truncate the the
insertion.
I just scanned our set of warning flags to see if this would fit nicely
under any of the existing flags, and it doesn't. I guess putting it
under -Wextra is probably best for now.
I think the warning text should indicate that the statement will write
outside the bounds of the destination object or something along those lines.
thanks for suggestions. patch updated
the warning message is as the following:
./cc1 -O2 pr48335-2.c -Wextra
pr48335-2.c: In function ‘f5’:
pr48335-2.c:19:33: warning: write of 16bit data outside the bound of
destination object, data truncated into 8bit [-Wextra]
((U *)((char *) s.d + 1))[3] = x;
^
x86-64 bootstrap regress ok.
ok for trunk?
one other thing is I found using of insv maybe sub-optimal in some situation.
for example, even before my patch, modify type of U to char so there is no
overflow.
use BFI will cost one more fmov (cc1 -O2 test.c), maybe this is caused by bfi
only
support integer type, which may cause extra reg copy when there are both float
int type.
// comment out the if (maybe_expand_insn in store_bit_field_using_insv
// to fall back to other code path
f5:
uxtbw0, w0
stp x29, x30, [sp, -16]!
fmovs0, wzr
fmovs1, w0
add x29, sp, 0
bl bar
ldp x29, x30, [sp], 16
ret
// BFI version
f5:
fmovs0, wzr
stp x29, x30, [sp, -16]!
add x29, sp, 0
fmovw1, s0
bfi w1, w0, 0, 8
fmovs1, w1
bl bar
ldp x29, x30, [sp], 16
ret
Thanks.
gcc/
PR64011
* expmed.c (store_bit_field_using_insv): Warn and truncate bitsize when
there is
partial overflow.
diff --git a/gcc/expmed.c b/gcc/expmed.c
index 0304e46..176c317 100644
--- a/gcc/expmed.c
+++ b/gcc/expmed.c
@@ -535,6 +535,21 @@ store_bit_field_using_insv (const extraction_insn *insv, rtx op0,
copy_back = true;
}
+ /* There are similar 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 partialy 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
+ etc. */
+ if (bitsize + bitnum unit bitnum unit)
+{
+ warning (OPT_Wextra, write of HOST_WIDE_INT_PRINT_UNSIGNEDbit data
+ outside the bound of destination object, data truncated into
+ HOST_WIDE_INT_PRINT_UNSIGNEDbit, bitsize, unit - bitnum);
+ bitsize = unit - bitnum;
+}
+
/* If BITS_BIG_ENDIAN is zero on a BYTES_BIG_ENDIAN machine, we count
backwards from the size of the unit we are inserting into.
Otherwise, we count bits from the most significant on a
Re: [testsuite] Fix plugin test for bareboard ports
On Jan 15, 2015, at 7:28 AM, Eric Botcazou ebotca...@adacore.com wrote: The attached patch fixes it by ensuring that LTO_TORTURE_OPTIONS is computed after set_ld_library_path_env_vars is invoked (this procedure invokes in turn set_gcc_exec_prefix_env_var), both in c-torture.exp and in gcc-dg.exp. OK for the mainline? Ok. Watch for fallout and/or comments from lto people.
Re: [PATCH] Fix PR testsuite/64605
On Jan 15, 2015, at 8:14 AM, Ilya Verbin iver...@gmail.com wrote: The problem is that gcc-dg.exp calls check_effective_target_lto, which calls libatomic_target_compile. Therefore gcc-dg.exp should be loaded only after the definition of libatomic_target_compile. However, a similar exp file in other tree (libitm/testsuite/lib/libitm.exp) doesn't contain any explicit 'load_gcc_lib gcc-dg.exp' at all, but it loads gcc-dg.exp implicitly. So I'm not sure whether this patch is correct. So, can you try the itm version of this? If that works, Ok.
Re: [Patch] Missing plugin header files
On 15 January 2015 at 14:14, Richard Biener richard.guent...@gmail.com wrote: On Wed, Jan 14, 2015 at 10:43 PM, Steve Ellcey sell...@imgtec.com wrote: I tried compiling an empty plugin that just included gcc-plugin.h and plugin-version.h and found that these header files were included from gcc-plugin.h but not in the list of header files to be copied to the plugin include directory. OK to checkin? Ok. Thanks, Richard. Steve Ellcey sell...@imgtec.com 2015-01-14 Steve Ellcey sell...@mips.com * Makefile.in (PLUGIN_HEADERS): Add dominance.h, cfg.h, cfgrtl.h, cfganal.h, cfgbuild.h, cfgcleanup.h, lcm.h, builtins.def, chkp-builtins.def, and pass-instances.def Should pass-instances.def be removed from ChangeLog since it was already present in PLUGIN_HEADERS ? Thanks, Prathamesh diff --git a/gcc/Makefile.in b/gcc/Makefile.in index 44a4214..abe2d0d 100644 --- a/gcc/Makefile.in +++ b/gcc/Makefile.in @@ -3228,7 +3228,8 @@ PLUGIN_HEADERS = $(TREE_H) $(CONFIG_H) $(SYSTEM_H) coretypes.h $(TM_H) \ tree-ssa-loop.h tree-ssa-loop-ivopts.h tree-ssa-loop-manip.h \ tree-ssa-loop-niter.h tree-ssa-ter.h tree-ssa-threadedge.h \ tree-ssa-threadupdate.h inchash.h wide-int.h signop.h hash-map.h \ - hash-set.h pass-instances.def + hash-set.h dominance.h cfg.h cfgrtl.h cfganal.h cfgbuild.h cfgcleanup.h \ + lcm.h builtins.def chkp-builtins.def pass-instances.def # generate the 'build fragment' b-header-vars s-header-vars: Makefile
Rename unroll_[1-5].c
So, I wanted to add some unrolling test cases and found that we had unroll-1.c and unroll_[1-5].c. :-( - is the standard, and picking numbers sequential from 1, with a - before the number is standard. No reason to deviate in this case. I’ve fixed this by renaming the test cases like so: * gcc.dg/unroll_1.c: Rename gcc.dg/unroll_[1-5].c to unroll-[2-6]. * gcc.dg/unroll_2.c: Likewise. * gcc.dg/unroll_3.c: Likewise. * gcc.dg/unroll_4.c: Likewise. * gcc.dg/unroll_5.c: Likewise.
Re: [PATCH/expand] PR64011 Adjust bitsize when partial overflow happen for big-endian
On 01/15/15 09:27, Jiong Wang wrote: On 15/01/15 03:51, Jeff Law wrote: On 01/14/15 15:31, Jiong Wang wrote: agree, and I think the truncation is needed otherwise there may have ICE on some target. and I found current gcc LOCATION info is very good ! have done an experimental hack on at expand_assignment: 4931 where the tree is expanded, gcc could give quite useful accurate warning based on tree LOCATION info. ./cc1 -O2 -mbig-endian pr48335-2.c pr48335-2.c: In function ‘f5’: pr48335-2.c:19:29: warning: overflow here ! ((U *)((char *) s.d + 1))[3] = x; ^ while we need to add warning at store_bit_field_using_insv where there is no accurate LOCATION info. but looks like it's acceptable? pr48335-2.c:19:33: warning: overflow here ! ((U *)((char *) s.d + 1))[3] = x; ^ Yes, I think we're on the right track now -- warn and truncate the the insertion. I just scanned our set of warning flags to see if this would fit nicely under any of the existing flags, and it doesn't. I guess putting it under -Wextra is probably best for now. I think the warning text should indicate that the statement will write outside the bounds of the destination object or something along those lines. thanks for suggestions. patch updated the warning message is as the following: ./cc1 -O2 pr48335-2.c -Wextra pr48335-2.c: In function ‘f5’: pr48335-2.c:19:33: warning: write of 16bit data outside the bound of destination object, data truncated into 8bit [-Wextra] ((U *)((char *) s.d + 1))[3] = x; ^ x86-64 bootstrap regress ok. ok for trunk? one other thing is I found using of insv maybe sub-optimal in some situation. for example, even before my patch, modify type of U to char so there is no overflow. use BFI will cost one more fmov (cc1 -O2 test.c), maybe this is caused by bfi only support integer type, which may cause extra reg copy when there are both float int type. // comment out the if (maybe_expand_insn in store_bit_field_using_insv // to fall back to other code path f5: uxtbw0, w0 stp x29, x30, [sp, -16]! fmovs0, wzr fmovs1, w0 add x29, sp, 0 bl bar ldp x29, x30, [sp], 16 ret // BFI version f5: fmovs0, wzr stp x29, x30, [sp, -16]! add x29, sp, 0 fmovw1, s0 bfi w1, w0, 0, 8 fmovs1, w1 bl bar ldp x29, x30, [sp], 16 ret Thanks. gcc/ PR64011 * expmed.c (store_bit_field_using_insv): Warn and truncate bitsize when there is partial overflow. OK for the trunk. Please install. Thanks, Jeff
Re: Another ptx offloading patch
On 11/20/14 05:33, Bernd Schmidt wrote: Now that I've managed to put together and test all the submitted OpenACC patches I found there was one piece missing. The problem is that omp-low on the host likes to generate function names like _main._omp_fn. On ptx, the dot is not allowed in identifiers, so we have to rewrite this to use a dollar sign. The patch below does this at the lto-read stage. Bootstrapped on x86_64-linux, ok if testing is successful? Was expecting Richi or Honza to review this... They certainly know the LTO bits far better than I. Or have you ultimately addressed this issue some other way? jeff
Re: [COMMITTED] Merge libffi with upstream
On Thu, Jan 15, 2015 at 8:40 AM, Rainer Orth
r...@cebitec.uni-bielefeld.de wrote:
Richard Henderson r...@redhat.com writes:
Upstream libffi has added support for Go closures (using the static chain),
and support for complex numbers. Perhaps less relevant is new support for
arc, microblaze, moxie, nios, and or1k targets.
Without additional changes for Go, this merge has little effect. Within the
gcc tree libffi is primarily used by libjava.
Tested with no regressions on {i686,x86_64,ppc64,s390x,aarch64,alpha}-linux.
Due to upstream breakage, and difficulty debugging on Darwin,
{i686,x86_64}-darwin retains copies of the existing sources and thus remains
100% unchanged. Since libgo doesn't support darwin, this should cause no
immediate problems.
The patch introduced massive problems on Solaris, both SPARC and x86:
* on Solaris/SPARC, /bin/as requires
.type fn,#function
instead of @function. I've simply commented the affected lines in
src/sparc/v[89].S to make progress.
* /bin/as doesn't support .macro/.endm. I'm using preprocessor macros
instead to implement E in src/sparc/v[89].S and src/x86/{sysv,
unix64}.S.
* Solaris/x86 /bin/as doesn't support .org, so I've just disabled the
uses in src/x86/{sysv, unix64}.S, as on Darwin.
* Solaris/x86 /bin/as has different COMDAT syntax; I've disabled it for
the moment.
* Solaris/x86 needs to use EH_FRAME_FLAGS so manually and compiler
generated .eh_frame sections match, otherwise libffi.so fails to link:
ld: fatal: file src/.libs/prep_cif.o; section [16].eh_frame and file
src/x86/.libs/sysv.o; section [9].eh_frame have incompatibile attributes and
cannot be merged into a single output section
* Yet unfixed for Solaris/SPARC /bin/as:
as: v8.s, line 128: error: invalid digit in radix 10
as seems to only understand single-digit labels
as: v8.s, line 140: error: statement syntax
as: v8.s, line 157: error: unknown opcode .rept
as: v8.s, line 157: error: statement syntax
as: v8.s, line 163: error: unknown opcode .endr
as: v8.s, line 163: error: statement syntax
and knows nothing about .rept/.endr
Here are the hacks I've used to make some progress:
I think we should
1. Revert the libffi merge patch.
2. Create a GCC integration branch from the merge commit
in libffi git repo
3. Apply all GCC customization changes to the GCC integration
branch.
4. Copy the the GCC integration branch to gcc/libffi, NOT the
unmodified libffi commit.
--
H.J.
Re: [PATCH, RFC] LRA subreg handling
On 01/15/15 03:13, Robert Suchanek wrote: Robert, can you look at reload.c::reload_inner_reg_of_subreg and verify that the comment just before its return statement is effectively the situation you're in. There are certainly cases where a SUBREG needs to be treated as an in-out operand. We walked through them eons ago when we were poking at SSA for RTL. But the details have long since faded from memory. The comment pretty much applies to my situation. The only difference I can see is that reload would have had hard registers at this point. In the testcase, LRA does not have hard registers assigned to the concerned pseudo(s), thus, it can't rely on the information in hard_regno_nregs to check if the number of registers in INNER is different to the number of words in INNER. The differences (hard vs pseudo regs) are primarily an implementation detail. I was really looking to see if there was existing code which would turn an output reload into an in-out reload for these subregs. The in-out nature of certain subregs is something I've personally stumbled over in various contexts (for example, this also came up during RTL-SSA investigations years ago). Jeff
Re: [PATCH, AARCH64] Fix ICE in CCMP (PR64015)
On 12/15/2014 12:41 AM, Zhenqiang Chen wrote:
+(define_expand cmpmode
+ [(set (match_operand 0 cc_register )
+(match_operator:CC 1 aarch64_comparison_operator
+ [(match_operand:GPI 2 register_operand )
+ (match_operand:GPI 3 aarch64_plus_operand )]))]
+
+
+ operands[1] = gen_rtx_fmt_ee (COMPARE, SELECT_CC_MODE (GET_CODE
(operands[1]),
+ operands[2],
+ operands[3]),
+ operands[2], operands[3]);
+
+)
Use { } not for the C portion.
Otherwise ok.
r~
[PATCH] Fix PR64068 and PR64559
Hello.
This is Honsa's patch that I've just tested on x86_64-linux-pc. The patch is
preapproved by Honza
and is going to be installed.
Thanks,
Martin
From 84b6878f168802516febfbd00252f56f965b9666 Mon Sep 17 00:00:00 2001
From: mliska mli...@suse.cz
Date: Thu, 15 Jan 2015 17:20:00 +0100
Subject: [PATCH] Fix for PR64068 and PR64559.
gcc/testsuite/ChangeLog:
2015-01-15 Martin Liska mli...@suse.cz
* g++.dg/ipa/pr64068.C: New test.
* gcc.dg/ipa/PR64559.c: New test.
gcc/ChangeLog:
2015-01-15 Jan Hubicka hubi...@ucw.cz
PR ipa/64068
PR ipa/64559
* ipa.c (symbol_table::remove_unreachable_nodes):
Do not put abstract origins into boundary.
---
gcc/ipa.c | 1 -
gcc/testsuite/g++.dg/ipa/pr64068.C | 49 ++
gcc/testsuite/gcc.dg/ipa/PR64559.c | 39 ++
3 files changed, 88 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/g++.dg/ipa/pr64068.C
create mode 100644 gcc/testsuite/gcc.dg/ipa/PR64559.c
diff --git a/gcc/ipa.c b/gcc/ipa.c
index df96515..3626417 100644
--- a/gcc/ipa.c
+++ b/gcc/ipa.c
@@ -400,7 +400,6 @@ symbol_table::remove_unreachable_nodes (FILE *file)
n = n-next_sibling_clone)
if (n-decl == DECL_ABSTRACT_ORIGIN (node-decl))
n-used_as_abstract_origin = true;
- enqueue_node (origin_node, first, reachable);
}
}
/* If any symbol in a comdat group is reachable, force
diff --git a/gcc/testsuite/g++.dg/ipa/pr64068.C b/gcc/testsuite/g++.dg/ipa/pr64068.C
new file mode 100644
index 000..9528883
--- /dev/null
+++ b/gcc/testsuite/g++.dg/ipa/pr64068.C
@@ -0,0 +1,49 @@
+/* { dg-do compile } */
+/* { dg-options -O2 } */
+
+typedef int PROV_ENUMALGS_EX, PCCRYPT_OID_INFO;
+class A {
+ int m_fn2();
+ virtual bool m_fn1(PCCRYPT_OID_INFO);
+};
+int fn1();
+void fn2();
+int A::m_fn2() { m_fn1(0); }
+
+bool fn3() {
+ for (;;) {
+if (fn1()) {
+ if (fn1() != 259)
+fn2();
+ break;
+}
+return 1;
+ }
+ return 0;
+}
+
+class B {
+public:
+ B() { fn3(); }
+};
+class C : A {
+ bool m_fn1(PCCRYPT_OID_INFO) { m_fn3(); }
+ int isSupportedByProvider_algId;
+ PROV_ENUMALGS_EX isSupportedByProvider_outEnumAlgs;
+ PROV_ENUMALGS_EX isSupportedByProvider_enumAlgs;
+ bool m_fn3() {
+while (1) {
+ if (fn1()) {
+if (fn1() != 259)
+ fn2();
+break;
+ }
+ if (isSupportedByProvider_algId)
+isSupportedByProvider_outEnumAlgs = isSupportedByProvider_enumAlgs;
+ return 1;
+}
+return 0;
+ }
+};
+
+void fn4() { B(); }
diff --git a/gcc/testsuite/gcc.dg/ipa/PR64559.c b/gcc/testsuite/gcc.dg/ipa/PR64559.c
new file mode 100644
index 000..463afdc
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/ipa/PR64559.c
@@ -0,0 +1,39 @@
+/* { dg-do compile } */
+/* { dg-options -Os } */
+
+int a, b, c, d;
+
+struct S
+{
+ int f0;
+};
+
+static int
+fn1 (int p)
+{
+ return p == 0 || a;
+}
+
+static int
+fn2 ()
+{
+ d = fn1 (c);
+ return 0;
+}
+
+static int
+fn3 (struct S p)
+{
+ p.f0 || fn2 ();
+ if (fn1 (1))
+b = 0;
+ return 0;
+}
+
+int
+main ()
+{
+ struct S e = { 1 };
+ fn3 (e);
+ return 0;
+}
--
2.1.2
Re: [COMMITTED] Merge libffi with upstream
On 01/15/2015 08:54 AM, H.J. Lu wrote:
On Thu, Jan 15, 2015 at 8:40 AM, Rainer Orth
r...@cebitec.uni-bielefeld.de wrote:
Richard Henderson r...@redhat.com writes:
Upstream libffi has added support for Go closures (using the static chain),
and support for complex numbers. Perhaps less relevant is new support for
arc, microblaze, moxie, nios, and or1k targets.
Without additional changes for Go, this merge has little effect. Within the
gcc tree libffi is primarily used by libjava.
Tested with no regressions on {i686,x86_64,ppc64,s390x,aarch64,alpha}-linux.
Due to upstream breakage, and difficulty debugging on Darwin,
{i686,x86_64}-darwin retains copies of the existing sources and thus remains
100% unchanged. Since libgo doesn't support darwin, this should cause no
immediate problems.
The patch introduced massive problems on Solaris, both SPARC and x86:
* on Solaris/SPARC, /bin/as requires
.type fn,#function
instead of @function. I've simply commented the affected lines in
src/sparc/v[89].S to make progress.
* /bin/as doesn't support .macro/.endm. I'm using preprocessor macros
instead to implement E in src/sparc/v[89].S and src/x86/{sysv,
unix64}.S.
* Solaris/x86 /bin/as doesn't support .org, so I've just disabled the
uses in src/x86/{sysv, unix64}.S, as on Darwin.
* Solaris/x86 /bin/as has different COMDAT syntax; I've disabled it for
the moment.
* Solaris/x86 needs to use EH_FRAME_FLAGS so manually and compiler
generated .eh_frame sections match, otherwise libffi.so fails to link:
ld: fatal: file src/.libs/prep_cif.o; section [16].eh_frame and file
src/x86/.libs/sysv.o; section [9].eh_frame have incompatibile attributes and
cannot be merged into a single output section
* Yet unfixed for Solaris/SPARC /bin/as:
as: v8.s, line 128: error: invalid digit in radix 10
as seems to only understand single-digit labels
as: v8.s, line 140: error: statement syntax
as: v8.s, line 157: error: unknown opcode .rept
as: v8.s, line 157: error: statement syntax
as: v8.s, line 163: error: unknown opcode .endr
as: v8.s, line 163: error: statement syntax
and knows nothing about .rept/.endr
Here are the hacks I've used to make some progress:
I think we should
1. Revert the libffi merge patch.
2. Create a GCC integration branch from the merge commit
in libffi git repo
How's that going to help? The build infrastructure is totally different.
That and the fact that extremely few people test upstream libffi.
4. Copy the the GCC integration branch to gcc/libffi, NOT the
unmodified libffi commit.
I beg your pardon?
r~
Re: [PATCH] Fix PR testsuite/64605
On 15 Jan 09:40, Mike Stump wrote:
On Jan 15, 2015, at 8:14 AM, Ilya Verbin iver...@gmail.com wrote:
The problem is that gcc-dg.exp calls check_effective_target_lto, which calls
libatomic_target_compile. Therefore gcc-dg.exp should be loaded only after
the
definition of libatomic_target_compile.
However, a similar exp file in other tree (libitm/testsuite/lib/libitm.exp)
doesn't contain any explicit 'load_gcc_lib gcc-dg.exp' at all, but it loads
gcc-dg.exp implicitly. So I'm not sure whether this patch is correct.
So, can you try the itm version of this? If that works, Ok.
If I just remove 'load_gcc_lib gcc-dg.exp' from libatomic.exp, like this is done
in libitm.exp, it will not work:
$ make check-target-libatomic
...
ERROR: (DejaGnu) proc gcc-dg-test-1 libatomic_target_compile
../../../../gcc/libatomic/testsuite/libatomic.c/atomic-compare-exchange-1.c run
{ -g} does not exist.
Note that gcc-dg-test-1 is defined in gcc-dg.exp, so it's somehow automatically
loaded for libitm and other libs, but non loaded for libatomic.
-- Ilya
Re: [PATCH] Reenable CSE of non-volatile inline asm (PR rtl-optimization/63637)
On 01/15/15 01:13, Jakub Jelinek wrote: The glibc barriers are supposedly something that can be CSEd (one barrier instead of two consecutive barriers is enough), but certainly not moved across any loads/stores in between. In the kernel case, the enable/disable probably wouldn't allow even CSE. So I'm with Jeff that we should treat memory at least as unspecified read and write, and whether we can CSE them if there are no memory loads/stores in between them can be discussed (most likely the kernel would be safe even in that case, because those usually don't nest and appear in pairs, or act as barriers (like the glibc case), or read from segment registers (guess again ok to be CSEd with no intervening loads/stores). In 4.9 backport I'd prefer not to CSE them at all though, stay conservative. My vote would be to go conservative. For gcc6 consider allowing a memory tag in the inputs and outputs to specify a read of any memory location and write of any memory location respectively. A memory tag in the clobbers would maintain the conservative behaviour. jeff
Re: [PATCH 4/4] OpenMP 4.0 offloading to Intel MIC: non-fallback testing
On 22 Dec 13:35, Jakub Jelinek wrote:
On Mon, Dec 22, 2014 at 12:48:08PM +0100, Thomas Schwinge wrote:
In my understanding, we'd like to support the modes that either all
compilers are installed (which is what a user will be using), or all are
tested from their build trees. Or, do we also have to support the mode
that only the offloading compilers are installed, but the target
(offloading host) compiler is not? (Doesn't make much sense to me.)
All 3 of these, yes.
The nothing is installed yet mode supposedly doesn't work properly on the
trunk yet (and is what I'd like to use e.g. in distro rpm builds), the
offloading
compilers installed, host is not is useful that you actually test the host
compiler
before installing, and that supposedly works on the trunk, the all installed
testing
I've never used myself, but some people are using it.
This patch enables 'make check-target-libgomp' with noninstalled offloading
compilers. It creates gcc/accel/target/ directory in the build tree of the
offloading compiler, this allows lto-wrapper to find corresponding mkoffload in
case if there is more than one offloading compiler. Is this approach ok?
I don't like changes in config.gcc and t-intelmic, probably there is a better
way to create a link?
diff --git a/gcc/config.gcc b/gcc/config.gcc
index 0dfc08f..76eef6f 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -4369,7 +4369,7 @@ fi
case ${target} in
i[34567]86-*-* | x86_64-*-*)
if test x$enable_as_accelerator = xyes; then
- extra_programs=mkoffload\$(exeext)
+ extra_programs=mkoffload\$(exeext)
accel/${target_noncanonical}/mkoffload$(exeext)
fi
;;
esac
diff --git a/gcc/config/i386/intelmic-mkoffload.c
b/gcc/config/i386/intelmic-mkoffload.c
index 8e490ff..41807cf 100644
--- a/gcc/config/i386/intelmic-mkoffload.c
+++ b/gcc/config/i386/intelmic-mkoffload.c
@@ -45,6 +45,11 @@ const char *temp_files[MAX_NUM_TEMPS];
/* Shows if we should compile binaries for i386 instead of x86-64. */
bool target_ilp32 = false;
+/* An optional prefix for the target compiler, which is required when target
+ compiler is not installed. */
+char *optional_target_path = NULL;
+
+
/* Delete tempfiles and exit function. */
void
tool_cleanup (bool from_signal ATTRIBUTE_UNUSED)
@@ -151,14 +156,18 @@ access_check (const char *name, int mode)
return access (name, mode);
}
-/* Find target compiler using a path from COLLECT_GCC or COMPILER_PATH. */
+/* Find target compiler using a path from COLLECT_GCC, COMPILER_PATH, or a path
+ relative to ARGV0. */
static char *
-find_target_compiler (const char *name)
+find_target_compiler (const char *argv0)
{
bool found = false;
char **paths = NULL;
unsigned n_paths, i;
+ const char *current_path;
const char *collect_path = dirname (ASTRDUP (getenv (COLLECT_GCC)));
+ const char *name
+= DEFAULT_REAL_TARGET_MACHINE -accel- DEFAULT_TARGET_MACHINE -gcc;
size_t len = strlen (collect_path) + 1 + strlen (name) + 1;
char *target_compiler = XNEWVEC (char, len);
sprintf (target_compiler, %s/%s, collect_path, name);
@@ -177,13 +186,28 @@ find_target_compiler (const char *name)
if (access_check (target_compiler, X_OK) == 0)
{
found = true;
- break;
+ goto out;
}
}
+ /* If installed compiler wasn't found, try to find a non-installed compiler,
+ using a path relative to mkoffload. */
+ current_path = dirname (ASTRDUP (argv0));
+ len = strlen (current_path) + sizeof (/../../) - 1;
+ target_compiler = XRESIZEVEC (char, target_compiler, len + sizeof (xgcc));
+ sprintf (target_compiler, %s/../../xgcc, current_path);
+ if (access_check (target_compiler, X_OK) == 0)
+{
+ optional_target_path = XNEWVEC (char, len + sizeof (-B));
+ sprintf (optional_target_path, -B%s/../../, current_path);
+ found = true;
+}
+
out:
free_array_of_ptrs ((void **) paths, n_paths);
- return found ? target_compiler : NULL;
+ if (!found)
+fatal_error (offload compiler %s not found, name);
+ return target_compiler;
}
static void
@@ -193,6 +217,10 @@ compile_for_target (struct obstack *argv_obstack)
obstack_ptr_grow (argv_obstack, -m32);
else
obstack_ptr_grow (argv_obstack, -m64);
+
+ if (optional_target_path)
+obstack_ptr_grow (argv_obstack, optional_target_path);
+
obstack_ptr_grow (argv_obstack, NULL);
char **argv = XOBFINISH (argv_obstack, char **);
@@ -492,11 +520,7 @@ main (int argc, char **argv)
if (!host_compiler)
fatal_error (COLLECT_GCC must be set);
- const char *target_driver_name
-= DEFAULT_REAL_TARGET_MACHINE -accel- DEFAULT_TARGET_MACHINE -gcc;
- char *target_compiler = find_target_compiler (target_driver_name);
- if (target_compiler == NULL)
-fatal_error (offload compiler %s not found, target_driver_name);
+ char *target_compiler = find_target_compiler (argv[0]);
/* We may be called with all the
Re: PATCH: PR libitm/64360: libitm.c/stackundo.c fails with -fpic
On 01/15/15 05:23, H.J. Lu wrote: Hi, libitm.c/stackundo.c fails with -fpic since test1 and test2 may be preempted with -fpic. This patch makes those 2 functions static. Tested on Linux/x86. OK for trunk? Thanks. H.J. diff --git a/libitm/ChangeLog b/libitm/ChangeLog index 74e2940..e46819c 100644 --- a/libitm/ChangeLog +++ b/libitm/ChangeLog @@ -1,3 +1,9 @@ +2015-01-15 H.J. Lu hongjiu...@intel.com + + PR libitm/64360 + * libitm.c/stackundo.c (test2): Make it static. + (test1): Likewise. OK. Jeff
Re: [Patch, Fortran, F03] PR 58023: ICE on invalid with bad PPC declaration
2015-01-15 14:22 GMT+01:00 Mikael Morin mikael.mo...@sfr.fr: the attached patch fixes an ICE-on-invalid problem with procedure-pointer components by making sure that we continue resolving all components of a derived type, even after an error is thrown. Does the fonction return false as before, whenever an error has been issued? I have the feeling it doesn't any more with the patch. yeah, you're right. The attached new version fixes that. Better? Yes, OK. Thanks. Committed as r219676. Thanks for reviewing! Cheers, Janus
Re: [PATCH 4/4] OpenMP 4.0 offloading to Intel MIC: non-fallback testing
On Thu, Jan 15, 2015 at 09:55:40PM +0300, Ilya Verbin wrote: This patch enables 'make check-target-libgomp' with noninstalled offloading compilers. It creates gcc/accel/target/ directory in the build tree of the offloading compiler, this allows lto-wrapper to find corresponding mkoffload in case if there is more than one offloading compiler. Is this approach ok? I don't like changes in config.gcc and t-intelmic, probably there is a better way to create a link? Let's wait until Thomas hopefully checks in the OpenACC merge in order not to make him work even harder. I'll look at your patch afterwards. Jakub
Re: [PATCH] Avoid -Werror=format-security errors in libcpp
On 01/15/15 04:19, Jakub Jelinek wrote:
Hi!
With the addition of build libcpp, my build failed because of distro default
flags of -Werror=format-security.
The first hunk is I think no big deal, making it const makes the warning
go away.
The second hunk is more controversial, as even making message const doesn't
help with the warning. There is another option of using %s and
_( instead of N_ in message, or just keep it as is and I can keep the second
hunk as local hack.
Thoughts on this?
2015-01-15 Jakub Jelinek ja...@redhat.com
* macro.c (create_iso_definition): Make paste_op_error_msg var
const.
* expr.c (cpp_classify_number): Avoid -Wformat-security warning.
I'd go with the patch as-is. Approved.
jeff
--- libcpp/macro.c.jj 2015-01-14 11:01:34.0 +0100
+++ libcpp/macro.c 2015-01-14 14:22:19.286949884 +0100
@@ -2947,7 +2947,7 @@ create_iso_definition (cpp_reader *pfile
cpp_token *token;
const cpp_token *ctoken;
bool following_paste_op = false;
- const char *paste_op_error_msg =
+ const char *const paste_op_error_msg =
N_('##' cannot appear at either end of a macro expansion);
unsigned int num_extra_tokens = 0;
--- libcpp/expr.c.jj2015-01-14 11:01:34.0 +0100
+++ libcpp/expr.c 2015-01-14 14:35:52.851002344 +0100
@@ -672,16 +672,17 @@ cpp_classify_number (cpp_reader *pfile,
if ((result CPP_N_WIDTH) == CPP_N_LARGE
CPP_OPTION (pfile, cpp_warn_long_long))
{
- const char *message = CPP_OPTION (pfile, cplusplus)
- ? N_(use of C++11 long long integer constant)
- : N_(use of C99 long long integer constant);
-
if (CPP_OPTION (pfile, c99))
cpp_warning_with_line (pfile, CPP_W_LONG_LONG, virtual_location,
- 0, message);
+ 0, CPP_OPTION (pfile, cplusplus)
+ ? use of C++11 long long integer
constant
+ : use of C99 long long integer
constant);
else
cpp_pedwarning_with_line (pfile, CPP_W_LONG_LONG,
- virtual_location, 0, message);
+ virtual_location, 0,
+ CPP_OPTION (pfile, cplusplus)
+ ? use of C++11 long long integer
constant
+ : use of C99 long long integer
constant);
}
result |= CPP_N_INTEGER;
Jakub
Re: libgo patch committed: Update to Go 1.4
On Thu, Jan 15, 2015 at 01:58:43PM +0100, Richard Biener wrote:
[ 5286s] ../../../libgo/go/reflect/makefuncgo_s390x.go:323:5: error: expected
';
' or '}' or newline
[ 5286s]} else {
[ 5286s] ^
Bet that
} else {
line should have been replaced with
default:
Jakub
Re: [COMMITTED] Merge libffi with upstream
On Thu, Jan 15, 2015 at 9:19 AM, Richard Henderson r...@redhat.com wrote:
On 01/15/2015 08:54 AM, H.J. Lu wrote:
On Thu, Jan 15, 2015 at 8:40 AM, Rainer Orth
r...@cebitec.uni-bielefeld.de wrote:
Richard Henderson r...@redhat.com writes:
Upstream libffi has added support for Go closures (using the static chain),
and support for complex numbers. Perhaps less relevant is new support for
arc, microblaze, moxie, nios, and or1k targets.
Without additional changes for Go, this merge has little effect. Within
the
gcc tree libffi is primarily used by libjava.
Tested with no regressions on
{i686,x86_64,ppc64,s390x,aarch64,alpha}-linux.
Due to upstream breakage, and difficulty debugging on Darwin,
{i686,x86_64}-darwin retains copies of the existing sources and thus
remains
100% unchanged. Since libgo doesn't support darwin, this should cause no
immediate problems.
The patch introduced massive problems on Solaris, both SPARC and x86:
* on Solaris/SPARC, /bin/as requires
.type fn,#function
instead of @function. I've simply commented the affected lines in
src/sparc/v[89].S to make progress.
* /bin/as doesn't support .macro/.endm. I'm using preprocessor macros
instead to implement E in src/sparc/v[89].S and src/x86/{sysv,
unix64}.S.
* Solaris/x86 /bin/as doesn't support .org, so I've just disabled the
uses in src/x86/{sysv, unix64}.S, as on Darwin.
* Solaris/x86 /bin/as has different COMDAT syntax; I've disabled it for
the moment.
* Solaris/x86 needs to use EH_FRAME_FLAGS so manually and compiler
generated .eh_frame sections match, otherwise libffi.so fails to link:
ld: fatal: file src/.libs/prep_cif.o; section [16].eh_frame and file
src/x86/.libs/sysv.o; section [9].eh_frame have incompatibile attributes
and cannot be merged into a single output section
* Yet unfixed for Solaris/SPARC /bin/as:
as: v8.s, line 128: error: invalid digit in radix 10
as seems to only understand single-digit labels
as: v8.s, line 140: error: statement syntax
as: v8.s, line 157: error: unknown opcode .rept
as: v8.s, line 157: error: statement syntax
as: v8.s, line 163: error: unknown opcode .endr
as: v8.s, line 163: error: statement syntax
and knows nothing about .rept/.endr
Here are the hacks I've used to make some progress:
I think we should
1. Revert the libffi merge patch.
2. Create a GCC integration branch from the merge commit
in libffi git repo
How's that going to help? The build infrastructure is totally different.
That and the fact that extremely few people test upstream libffi.
It is to make sure that all GCC customization changes don't
get lost when merging with upstream. I am willing to work on
this and create a GCC patch to combine steps 1-4.
4. Copy the the GCC integration branch to gcc/libffi, NOT the
unmodified libffi commit.
I beg your pardon?
r~
--
H.J.
Re: [PATCH] IPA ICF: add comparison for target and optimization nodes
On 01/15/15 09:20, Rainer Orth wrote: Martin Liška mli...@suse.cz writes: On 01/07/2015 12:38 PM, 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 Hello. Apart from the previous patch, I would like to install following patch which introduces new dump functions related to target and optimization nodes. These functions dump just different flags. Patch has been tested on x86_64-linux-pc. Unfortunately, this patch breaks Solaris/SPARC bootstrap: options-save.c:3267:34: error: unused parameter 'indent' [-Werror=unused-parameter] int indent, ^ options-save.c:3268:55: error: unused parameter 'ptr1' [-Werror=unused-parameter] struct cl_target_option *ptr1, ^ options-save.c:3269:55: error: unused parameter 'ptr2' [-Werror=unused-parameter] struct cl_target_option *ptr2) ^ The following patch fixes this and allow the bootstrap to continue. 2015-01-15 Rainer Orth r...@cebitec.uni-bielefeld.de * optc-save-gen.awk (cl_target_option_print_diff): Mark indent, ptr1, ptr2 unused. Ok for mainline? OK. jeff
Re: [PATCH] Disable -fuse-caller-save when -pg is active
On 01/05/15 21:01, Hans-Peter Nilsson wrote: On Fri, 14 Nov 2014, Radovan Obradovic wrote: index eb37bfe..ddaf8e0 100644 --- a/gcc/toplev.c +++ b/gcc/toplev.c @@ -1605,6 +1612,11 @@ process_options (void) /* Save the current optimization options. */ optimization_default_node = build_optimization_node (global_options); optimization_current_node = optimization_default_node; + + /* Disable use caller save optimization if profiler is active or port + does not emit prologue and epilogue as RTL. */ + if (profile_flag || !HAVE_prologue || !HAVE_epilogue) +flag_use_caller_save = 0; } This seems wrong. Why disable caller-save regardless of profile_flag; is there some long-standing bug in caller-save for old targets? It's actually -fipa-ra, use-caller-save was the initial name for the option and everyone agreed it was poorly named. The problem is that with -fipa-ra we analyze the generated RTL to determine register usage. We later use that information to optimize register allocation in callers. That works fine and good except for cases where we're emitting code textually rather than via RTL. That happens with profiling, textual prologue or textual epilogue. Thus the test is correct. Jeff
Rename gcc.dg/inline_[1-4].c
Similar to the unroll_1.c change. * gcc.dg/inline_1.c: Rename gcc.dg/inline_[1-4].c to inline-3[6-9].c. * gcc.dg/inline_2.c: Likewise. * gcc.dg/inline_3.c: Likewise. * gcc.dg/inline_4.c: Likewise.
Fix ARM bootstrap - xgene tune params
The recent xgene tuning parameters merge broke the ARM bootstrap, since the tables have been extended by an additional parameter giving: gcc/config/arm/arm.c:1932:1: error: missing initializer for member 'tune_params::fuseable_ops' [-Werror=missing-field-initializers] }; ^ Fixed as below. I've no idea if this is the optimial behaviour for Xgene parts, but it preserves the previous behaviour of the compiler before this pass was added. I'll let those who really know decide whether a more comprehensive change is needed. R. 2015-01-15 Richard Earnshaw rearn...@arm.com * arm.c (arm_xgene_tune): Add default initializer for instruction fusion.diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c index a2cce8e..c106843 100644 --- a/gcc/config/arm/arm.c +++ b/gcc/config/arm/arm.c @@ -1928,7 +1928,8 @@ const struct tune_params arm_xgene1_tune = false, /* Prefer Neon for 64-bits bitops. */ true, true, /* Prefer 32-bit encodings. */ false, /* Prefer Neon for stringops. */ - 32 /* Maximum insns to inline memset. */ + 32, /* Maximum insns to inline memset. */ + ARM_FUSE_NOTHING /* Fuseable pairs of instructions. */ }; /* Branches can be dual-issued on Cortex-A5, so conditional execution is
Re: [PATCH] -fsanitize=vptr instrumentation (take 3)
OK, sorry for the delay. Jason
Re: [testsuite] PATCH: Ignore additional messages on Linux/x86 with PIE
On Thu, Jan 15, 2015 at 8:30 AM, H.J. Lu hjl.to...@gmail.com wrote: On Thu, Jan 15, 2015 at 8:24 AM, Mike Stump mikest...@comcast.net wrote: So, I was hoping that someone would step forward and review this. I’d like for a reviewer to consider, is this the type of error messages we want to vend to the poor user? It strikes me as, well, icky. Should -fPIE imply -fPIC? It is an optimization: https://gcc.gnu.org/ml/gcc-cvs/2014-12/msg00206.html If linker supports copy reloc in PIE, we turn off PIC for the data access. Since the symbol is undefined in this case, linker complains. FYI, I opened a linker bug: https://sourceware.org/bugzilla/show_bug.cgi?id=17847 I will suppress the second linker message. -- H.J.
Re: [COMMITTED] Merge libffi with upstream
On 01/15/2015 08:40 AM, Rainer Orth wrote:
The patch introduced massive problems on Solaris, both SPARC and x86:
* on Solaris/SPARC, /bin/as requires
.type fn,#function
instead of @function. I've simply commented the affected lines in
src/sparc/v[89].S to make progress.
* /bin/as doesn't support .macro/.endm. I'm using preprocessor macros
instead to implement E in src/sparc/v[89].S and src/x86/{sysv,
unix64}.S.
* Solaris/x86 /bin/as doesn't support .org, so I've just disabled the
uses in src/x86/{sysv, unix64}.S, as on Darwin.
* Solaris/x86 /bin/as has different COMDAT syntax; I've disabled it for
the moment.
I hate old assemblers...
* Solaris/x86 needs to use EH_FRAME_FLAGS so manually and compiler
generated .eh_frame sections match, otherwise libffi.so fails to link:
Fair enough, that's a simple error.
as: v8.s, line 128: error: invalid digit in radix 10
as seems to only understand single-digit labels
Easy enough to work around, I guess.
as: v8.s, line 140: error: statement syntax
as: v8.s, line 157: error: unknown opcode .rept
as: v8.s, line 157: error: statement syntax
as: v8.s, line 163: error: unknown opcode .endr
as: v8.s, line 163: error: statement syntax
and knows nothing about .rept/.endr
Ug. More preprocessor magic, I guess.
r~
Re: C++ PATCH for c++/64356 and libstdc++/58777 (constexpr pointer arithmetic)
Oops, got a bit excessive with the copy/paste. commit 4203eda52ae9eefc618d3819a3c468841bf2910b Author: Jason Merrill ja...@redhat.com Date: Wed Jan 14 23:58:50 2015 -0500 PR c++/64356 * constexpr.c (cxx_eval_binary_expression): Fix pasto. diff --git a/gcc/cp/constexpr.c b/gcc/cp/constexpr.c index e27a892..943ecbf 100644 --- a/gcc/cp/constexpr.c +++ b/gcc/cp/constexpr.c @@ -1624,7 +1624,7 @@ cxx_eval_binary_expression (const constexpr_ctx *ctx, tree t, rhs = cxx_eval_constant_expression (ctx, orig_rhs, /*lval*/false, non_constant_p, overflow_p); if (!ptr) -VERIFY_CONSTANT (lhs); +VERIFY_CONSTANT (rhs); location_t loc = EXPR_LOCATION (t); enum tree_code code = TREE_CODE (t); @@ -1640,7 +1640,7 @@ cxx_eval_binary_expression (const constexpr_ctx *ctx, tree t, else if (cxx_eval_check_shift_p (loc, ctx, code, type, lhs, rhs)) *non_constant_p = true; if (!ptr) -VERIFY_CONSTANT (lhs); +VERIFY_CONSTANT (r); return r; }
Re: [Patch] Missing plugin header files
2015-01-14 Steve Ellcey sell...@mips.com * Makefile.in (PLUGIN_HEADERS): Add dominance.h, cfg.h, cfgrtl.h, cfganal.h, cfgbuild.h, cfgcleanup.h, lcm.h, builtins.def, chkp-builtins.def, and pass-instances.def Should pass-instances.def be removed from ChangeLog since it was already present in PLUGIN_HEADERS ? Thanks, Prathamesh Looks like a cut-n-paste error on my part when I copied the file names from Makefile.in to ChangeLog. I will fix the ChangeLog entry. Steve Ellcey
[PATCH]Enable gcc/testsuite/gcc.dg/builtin-apply2.c for aarch64
Hi all,
This test is applicable to aarch64 target. This patch will remove
aarch64 from skip target list.
Verified that it passes for aarch64-none-elf and aarch64-none-linux-gnu
target.
Okay for trunk?
gcc/testsuite/ChangeLog:
2015-01-15 Renlin Li renlin...@arm.com
* gcc.dg/builtin-apply2.c: Remove aarch64 target from skip list.
diff --git a/gcc/testsuite/gcc.dg/builtin-apply2.c b/gcc/testsuite/gcc.dg/builtin-apply2.c
index d666fcc..b6cbe39 100644
--- a/gcc/testsuite/gcc.dg/builtin-apply2.c
+++ b/gcc/testsuite/gcc.dg/builtin-apply2.c
@@ -1,6 +1,6 @@
/* { dg-do run } */
/* { dg-require-effective-target untyped_assembly } */
-/* { dg-skip-if Variadic funcs have all args on stack. Normal funcs have args in registers. { aarch64*-*-* avr-*-* nds32*-*-* } { * } { } } */
+/* { dg-skip-if Variadic funcs have all args on stack. Normal funcs have args in registers. { avr-*-* nds32*-*-* } { * } { } } */
/* { dg-skip-if Variadic funcs use Base AAPCS. Normal funcs use VFP variant. { arm*-*-* arm_hf_eabi } { * } { } } */
/* PR target/12503 */
[PATCH 4.8/4.9] Backport of PR lto/63704
Hello.
Following patch is a backport of PR lto/63704 for GCC 4.8 and 4.9 branches.
Richi preapproved me the patch and I've run regtests on x86_64-linux-pc.
I'm going to install the patch.
Thanks,
Martin
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 779fef7..ab916b8 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,10 @@
+2015-01-15 Richard Biener rguent...@suse.de
+ Martin Liska mli...@suse.cz
+
+ PR middle-end/63704
+ * alias.c (mems_in_disjoint_alias_sets_p): Remove assert
+ and instead return false when !fstrict-aliasing.
+
2014-10-21 Jakub Jelinek ja...@redhat.com
PR tree-optimization/63563
diff --git a/gcc/alias.c b/gcc/alias.c
index 434ae7a..79a3560 100644
--- a/gcc/alias.c
+++ b/gcc/alias.c
@@ -383,17 +383,9 @@ get_alias_set_entry (alias_set_type alias_set)
static inline int
mems_in_disjoint_alias_sets_p (const_rtx mem1, const_rtx mem2)
{
-/* Perform a basic sanity check. Namely, that there are no alias sets
- if we're not using strict aliasing. This helps to catch bugs
- whereby someone uses PUT_CODE, but doesn't clear MEM_ALIAS_SET, or
- where a MEM is allocated in some way other than by the use of
- gen_rtx_MEM, and the MEM_ALIAS_SET is not cleared. If we begin to
- use alias sets to indicate that spilled registers cannot alias each
- other, we might need to remove this check. */
- gcc_assert (flag_strict_aliasing
- || (!MEM_ALIAS_SET (mem1) !MEM_ALIAS_SET (mem2)));
-
- return ! alias_sets_conflict_p (MEM_ALIAS_SET (mem1), MEM_ALIAS_SET (mem2));
+ return (flag_strict_aliasing
+ ! alias_sets_conflict_p (MEM_ALIAS_SET (mem1),
+ MEM_ALIAS_SET (mem2)));
}
/* Insert the NODE into the splay tree given by DATA. Used by
Re: [PATCH 5/5] rs6000: Do not allow TImode with -m32 -mpowerpc64
On Wed, Jan 14, 2015 at 8:14 PM, Segher Boessenkool seg...@kernel.crashing.org wrote: This fixes 141 FAILs. -mpowerpc64 does not change the ABI, but default_scalar_mode_supported_p does not know that, and allows TImode for -m32 -mpowerpc64. This fixes it. Okay for mainline? 2015-01-14 Segher Boessenkool seg...@kernel.crashing.org gcc/ * config/rs6000/rs6000.c (rs6000_scalar_mode_supported_p): Disallow TImode for TARGET_32BIT. Okay. Would you please add a comment that efficient TImode arithmetic requires carry to explain the TARGET_32BIT relationship? We can think about providing TImode logical operations in 32 bit, in the long run. Thanks, David
Re: [testsuite] PATCH: Ignore additional messages on Linux/x86 with PIE
So, I was hoping that someone would step forward and review this. I’d like for
a reviewer to consider, is this the type of error messages we want to vend to
the poor user? It strikes me as, well, icky. Should -fPIE imply -fPIC?
Exclusive of that issue, the patch is fine.
On Jan 11, 2015, at 4:23 PM, H.J. Lu hjl.to...@gmail.com wrote:
g++.dg/other/anon5.C is expected to fail to link. On Linux/x86 with PIE,
there are additional messages linker:
[hjl@gnu-tools-1 gcc]$ g++ -fPIE -pie
/export/gnu/import/git/sources/gcc/gcc/testsuite/g++.dg/other/anon5.C
/tmp/ccwg53fj.o: In function `f()': anon5.C:(.text+0x7): undefined reference
to `(anonymous namespace)::c::t'
/usr/local/bin/ld: /tmp/ccwg53fj.o: relocation R_X86_64_PC32 against
undefined symbol `_ZN12_GLOBAL__N_11c1tE' can not be used when making a
shared object; recompile with -fPIC
/usr/local/bin/ld: final link failed: Bad value
collect2: error: ld returned 1 exit status
[hjl@gnu-tools-1 gcc]$
This patch ignores additional messages on Linux/x86 with PIE. OK for
trunk?
Thanks.
H.J.
---
gcc/testsuite/g++.dg/other/anon5.C | 2 ++
1 file changed, 2 insertions(+)
2015-01-11 H.J. Lu hongjiu...@intel.com
* g++.dg/other/anon5.C: Ignore additional messages on Linux/x86
with PIE.
diff --git a/gcc/testsuite/g++.dg/other/anon5.C
b/gcc/testsuite/g++.dg/other/anon5.C
index 81e9def..4e4cc44 100644
--- a/gcc/testsuite/g++.dg/other/anon5.C
+++ b/gcc/testsuite/g++.dg/other/anon5.C
@@ -3,6 +3,8 @@
// { dg-options -g }
// Ignore additional message on powerpc-ibm-aix
// { dg-prune-output obtain more information } */
+// Ignore additional messages on Linux/x86 with PIE
+// { dg-prune-output Bad value } */
namespace {
struct c
Re: [testsuite] PATCH: Ignore additional messages on Linux/x86 with PIE
On Thu, Jan 15, 2015 at 8:24 AM, Mike Stump mikest...@comcast.net wrote:
So, I was hoping that someone would step forward and review this. I’d like
for a reviewer to consider, is this the type of error messages we want to
vend to the poor user? It strikes me as, well, icky. Should -fPIE imply
-fPIC?
It is an optimization:
https://gcc.gnu.org/ml/gcc-cvs/2014-12/msg00206.html
If linker supports copy reloc in PIE, we turn off PIC for the data access.
Since the symbol is undefined in this case, linker complains.
Exclusive of that issue, the patch is fine.
I will check it in.
Thanks.
On Jan 11, 2015, at 4:23 PM, H.J. Lu hjl.to...@gmail.com wrote:
g++.dg/other/anon5.C is expected to fail to link. On Linux/x86 with PIE,
there are additional messages linker:
[hjl@gnu-tools-1 gcc]$ g++ -fPIE -pie
/export/gnu/import/git/sources/gcc/gcc/testsuite/g++.dg/other/anon5.C
/tmp/ccwg53fj.o: In function `f()': anon5.C:(.text+0x7): undefined reference
to `(anonymous namespace)::c::t'
/usr/local/bin/ld: /tmp/ccwg53fj.o: relocation R_X86_64_PC32 against
undefined symbol `_ZN12_GLOBAL__N_11c1tE' can not be used when making a
shared object; recompile with -fPIC
/usr/local/bin/ld: final link failed: Bad value
collect2: error: ld returned 1 exit status
[hjl@gnu-tools-1 gcc]$
This patch ignores additional messages on Linux/x86 with PIE. OK for
trunk?
Thanks.
H.J.
---
gcc/testsuite/g++.dg/other/anon5.C | 2 ++
1 file changed, 2 insertions(+)
2015-01-11 H.J. Lu hongjiu...@intel.com
* g++.dg/other/anon5.C: Ignore additional messages on Linux/x86
with PIE.
diff --git a/gcc/testsuite/g++.dg/other/anon5.C
b/gcc/testsuite/g++.dg/other/anon5.C
index 81e9def..4e4cc44 100644
--- a/gcc/testsuite/g++.dg/other/anon5.C
+++ b/gcc/testsuite/g++.dg/other/anon5.C
@@ -3,6 +3,8 @@
// { dg-options -g }
// Ignore additional message on powerpc-ibm-aix
// { dg-prune-output obtain more information } */
+// Ignore additional messages on Linux/x86 with PIE
+// { dg-prune-output Bad value } */
namespace {
struct c
--
H.J.
Re: libgo patch committed: Update to Go 1.4
Ian Lance Taylor i...@golang.org writes:
I've committed a patch to libgo to update it to the Go 1.4 release,
except for the runtime package. Much of the runtime package was
rewritten in Go, and it does not really affect users of the library,
so I've postponed that complex merge. All the other packages are
updated. A few minor compiler changes were required, as well as a few
changes to the runtime packages required for other changes. The
testsuite script was changed to add support for the new TestMain
function, which is used by one or two of the standard packages.
As usual with libgo updates the entire patch is too large to attach
here. I've attached the changes to configuration/build files and the
runtime package.
Note that the type descriptor format has changed very very slightly to
include an additional flag. This means that all existing Go files
must be recompiled in order to work with this updated libgo. I will
bump the libgo version number shortly.
Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu.
Committed to mainline.
This (and perhaps the previous gotools) patch broke Solaris bootstrap:
/vol/gcc/src/hg/trunk/local/libgo/go/net/tcpsockopt_unix.go:23:73: error:
reference to undefined identifier 'syscall.TCP_KEEPINTVL'
if err := syscall.SetsockoptInt(fd.sysfd, syscall.IPPROTO_TCP,
syscall.TCP_KEEPINTVL, secs); err != nil {
/vol/gcc/src/hg/trunk/local/libgo/go/net/tcpsockopt_unix.go:26:103: error:
reference to undefined identifier 'syscall.TCP_KEEPIDLE'
return os.NewSyscallError(setsockopt, syscall.SetsockoptInt(fd.sysfd,
syscall.IPPROTO_TCP, syscall.TCP_KEEPIDLE, secs))
make[4]: *** [net.lo] Error 1
The following patch fixes this:
diff --git a/libgo/mksysinfo.sh b/libgo/mksysinfo.sh
--- a/libgo/mksysinfo.sh
+++ b/libgo/mksysinfo.sh
@@ -340,7 +340,7 @@ grep '^const _SHUT_' gen-sysinfo.go |
sed -e 's/^\(const \)_\(SHUT[^= ]*\)\(.*\)$/\1\2 = _\2/' ${OUT}
# The net package requires some const definitions.
-for m in IP_PKTINFO IPV6_V6ONLY IPPROTO_IPV6 IPV6_JOIN_GROUP IPV6_LEAVE_GROUP IPV6_TCLASS SO_REUSEPORT; do
+for m in IP_PKTINFO IPV6_V6ONLY IPPROTO_IPV6 IPV6_JOIN_GROUP IPV6_LEAVE_GROUP IPV6_TCLASS SO_REUSEPORT TCP_KEEPINTVL TCP_KEEPIDLE; do
if ! grep ^const $m ${OUT} /dev/null 21; then
echo const $m = 0 ${OUT}
fi
Apart from that, bootstrap fails in gotools: due to the use of
-static-libgo, all commands there fail to link since the socket
functions are missing. It seems like $LIBS from libgo needs to be added
somewhere, but I'm unsure how best to handle this. To make any progress
at all, I've just manually added -lsocket -lnsl to gotools/Makefile
(AM_LDFLAGS).
Rainer
--
-
Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [PATCH] IPA ICF: add comparison for target and optimization nodes
Martin Liška mli...@suse.cz writes:
On 01/07/2015 12:38 PM, 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
Hello.
Apart from the previous patch, I would like to install following patch
which introduces
new dump functions related to target and optimization nodes. These
functions dump just
different flags.
Patch has been tested on x86_64-linux-pc.
Unfortunately, this patch breaks Solaris/SPARC bootstrap:
options-save.c:3267:34: error: unused parameter 'indent'
[-Werror=unused-parameter]
int indent,
^
options-save.c:3268:55: error: unused parameter 'ptr1'
[-Werror=unused-parameter]
struct cl_target_option *ptr1,
^
options-save.c:3269:55: error: unused parameter 'ptr2'
[-Werror=unused-parameter]
struct cl_target_option *ptr2)
^
The following patch fixes this and allow the bootstrap to continue.
2015-01-15 Rainer Orth r...@cebitec.uni-bielefeld.de
* optc-save-gen.awk (cl_target_option_print_diff): Mark indent,
ptr1, ptr2 unused.
diff --git a/gcc/optc-save-gen.awk b/gcc/optc-save-gen.awk
--- a/gcc/optc-save-gen.awk
+++ b/gcc/optc-save-gen.awk
@@ -505,9 +505,9 @@ print ;
print /* Print different target option variables from structures provided as arguments. */;
print void;
print cl_target_option_print_diff (FILE *file,;
-print int indent,;
-print struct cl_target_option *ptr1,;
-print struct cl_target_option *ptr2);
+print int indent ATTRIBUTE_UNUSED,;
+print struct cl_target_option *ptr1 ATTRIBUTE_UNUSED,;
+print struct cl_target_option *ptr2 ATTRIBUTE_UNUSED);
print {;
print fputs (\\\n\, file);;
Ok for mainline?
Rainer
--
-
Rainer Orth, Center for Biotechnology, Bielefeld University
[testsuite] Fix plugin test for bareboard ports
Hi,
if you run a test for a bareboard port, e.g. arm-eabi or visium-elf, you'll
see in gcc.log:
Running /home/eric/svn/gcc/gcc/testsuite/gcc.dg/dg.exp ...
Executing on host: /home/eric/build/gcc/arm-eabi/gcc/xgcc -
B/home/eric/build/gcc/arm-eabi/gcc/ linker_plugin14260.c -fno-diagnostics-
show-caret -fdiagnostics-color=never -flto -fuse-linker-plugin -lm-o
linker_plugin14260.exe(timeout = 300)
spawn /home/eric/build/gcc/arm-eabi/gcc/xgcc -B/home/eric/build/gcc/arm-
eabi/gcc/ linker_plugin14260.c -fno-diagnostics-show-caret -fdiagnostics-
color=never -flto -fuse-linker-plugin -lm -o linker_plugin14260.exe
/home/eric/install/gcc/arm-eabi/bin/ld: cannot find crt0.o: No such file or
directory
collect2: error: ld returned 1 exit status
compiler exited with status 1
Failure of the plugin test will in turn cause gcc.c-torture/compile/pr61848.c
to fail in LTO mode:
FAIL: gcc.c-torture/compile/pr61848.c -O2 -flto scan-assembler mysection
FAIL: gcc.c-torture/compile/pr61848.c -O2 -flto -flto-partition=none scan-
assembler mysection
because of the fat/thin LTO object mismatch.
The attached patch fixes it by ensuring that LTO_TORTURE_OPTIONS is computed
after set_ld_library_path_env_vars is invoked (this procedure invokes in turn
set_gcc_exec_prefix_env_var), both in c-torture.exp and in gcc-dg.exp.
Tested on x86_64-suse-linux and visium-elf, OK for the mainline?
2015-01-15 Eric Botcazou ebotca...@adacore.com
* lib/c-torture.exp: Compute LTO_TORTURE_OPTIONS after the environment
is set up.
* lib/gcc-dg.exp: Likewise.
--
Eric BotcazouIndex: lib/gcc-dg.exp
===
--- lib/gcc-dg.exp (revision 219578)
+++ lib/gcc-dg.exp (working copy)
@@ -72,7 +72,14 @@ if [info exists ADDITIONAL_TORTURE_OPTIO
[concat $DG_TORTURE_OPTIONS $ADDITIONAL_TORTURE_OPTIONS]
}
-set LTO_TORTURE_OPTIONS
+global orig_environment_saved
+
+# This file may be sourced, so don't override environment settings
+# that have been previously setup.
+if { $orig_environment_saved == 0 } {
+append ld_library_path [gcc-set-multilib-library-path $GCC_UNDER_TEST]
+set_ld_library_path_env_vars
+}
# Some torture-options cause intermediate code output, unusable for
# testing using e.g. scan-assembler. In this variable are the options
@@ -80,6 +87,7 @@ set LTO_TORTURE_OPTIONS
global gcc_force_conventional_output
set gcc_force_conventional_output
+set LTO_TORTURE_OPTIONS
if [check_effective_target_lto] {
# When having plugin test both slim and fat LTO and plugin/nonplugin
# path.
@@ -97,15 +105,6 @@ if [check_effective_target_lto] {
}
}
-global orig_environment_saved
-
-# This file may be sourced, so don't override environment settings
-# that have been previously setup.
-if { $orig_environment_saved == 0 } {
-append ld_library_path [gcc-set-multilib-library-path $GCC_UNDER_TEST]
-set_ld_library_path_env_vars
-}
-
# Define gcc callbacks for dg.exp.
proc gcc-dg-test-1 { target_compile prog do_what extra_tool_flags } {
Index: lib/c-torture.exp
===
--- lib/c-torture.exp (revision 219578)
+++ lib/c-torture.exp (working copy)
@@ -51,6 +51,20 @@ if [info exists ADDITIONAL_TORTURE_OPTIO
[concat $C_TORTURE_OPTIONS $ADDITIONAL_TORTURE_OPTIONS]
}
+global GCC_UNDER_TEST
+if ![info exists GCC_UNDER_TEST] {
+set GCC_UNDER_TEST [find_gcc]
+}
+
+global orig_environment_saved
+
+# This file may be sourced, so don't override environment settings
+# that have been previously setup.
+if { $orig_environment_saved == 0 } {
+append ld_library_path [gcc-set-multilib-library-path $GCC_UNDER_TEST]
+set_ld_library_path_env_vars
+}
+
set LTO_TORTURE_OPTIONS
if [check_effective_target_lto] {
# When having plugin test both slim and fat LTO and plugin/nonplugin
@@ -68,20 +82,6 @@ if [check_effective_target_lto] {
}
}
-global GCC_UNDER_TEST
-if ![info exists GCC_UNDER_TEST] {
-set GCC_UNDER_TEST [find_gcc]
-}
-
-global orig_environment_saved
-
-# This file may be sourced, so don't override environment settings
-# that have been previously setup.
-if { $orig_environment_saved == 0 } {
-append ld_library_path [gcc-set-multilib-library-path $GCC_UNDER_TEST]
-set_ld_library_path_env_vars
-}
-
#
# c-torture-compile -- runs the Tege C-torture test
#
[PATCH] Fix PR testsuite/64605
Hi!
This patch fixes 'make check-target-libatomic'.
The problem is that gcc-dg.exp calls check_effective_target_lto, which calls
libatomic_target_compile. Therefore gcc-dg.exp should be loaded only after the
definition of libatomic_target_compile.
However, a similar exp file in other tree (libitm/testsuite/lib/libitm.exp)
doesn't contain any explicit 'load_gcc_lib gcc-dg.exp' at all, but it loads
gcc-dg.exp implicitly. So I'm not sure whether this patch is correct.
Could someone familiar with DejaGnu please review it?
diff --git a/libatomic/testsuite/lib/libatomic.exp
b/libatomic/testsuite/lib/libatomic.exp
index 28cbaa8..b95032a 100644
--- a/libatomic/testsuite/lib/libatomic.exp
+++ b/libatomic/testsuite/lib/libatomic.exp
@@ -23,6 +23,11 @@ proc load_gcc_lib { filename } {
}
load_lib dg.exp
+
+# Required to use gcc-dg.exp - however, the latter should NOT be
+# loaded until ${tool}_target_compile is defined since it uses that
+# to determine default LTO options.
+
load_gcc_lib file-format.exp
load_gcc_lib target-supports.exp
load_gcc_lib target-utils.exp
@@ -40,7 +45,6 @@ load_gcc_lib torture-options.exp
load_gcc_lib timeout.exp
load_gcc_lib timeout-dg.exp
load_gcc_lib fortran-modules.exp
-load_gcc_lib gcc-dg.exp
set dg-do-what-default run
@@ -219,3 +223,5 @@ proc libatomic_option_proc { option } {
return 0
}
}
+
+load_gcc_lib gcc-dg.exp
Thanks,
-- Ilya
Re: [COMMITTED] Merge libffi with upstream
Richard Henderson r...@redhat.com writes:
Upstream libffi has added support for Go closures (using the static chain),
and support for complex numbers. Perhaps less relevant is new support for
arc, microblaze, moxie, nios, and or1k targets.
Without additional changes for Go, this merge has little effect. Within the
gcc tree libffi is primarily used by libjava.
Tested with no regressions on {i686,x86_64,ppc64,s390x,aarch64,alpha}-linux.
Due to upstream breakage, and difficulty debugging on Darwin,
{i686,x86_64}-darwin retains copies of the existing sources and thus remains
100% unchanged. Since libgo doesn't support darwin, this should cause no
immediate problems.
The patch introduced massive problems on Solaris, both SPARC and x86:
* on Solaris/SPARC, /bin/as requires
.type fn,#function
instead of @function. I've simply commented the affected lines in
src/sparc/v[89].S to make progress.
* /bin/as doesn't support .macro/.endm. I'm using preprocessor macros
instead to implement E in src/sparc/v[89].S and src/x86/{sysv,
unix64}.S.
* Solaris/x86 /bin/as doesn't support .org, so I've just disabled the
uses in src/x86/{sysv, unix64}.S, as on Darwin.
* Solaris/x86 /bin/as has different COMDAT syntax; I've disabled it for
the moment.
* Solaris/x86 needs to use EH_FRAME_FLAGS so manually and compiler
generated .eh_frame sections match, otherwise libffi.so fails to link:
ld: fatal: file src/.libs/prep_cif.o; section [16].eh_frame and file
src/x86/.libs/sysv.o; section [9].eh_frame have incompatibile attributes and
cannot be merged into a single output section
* Yet unfixed for Solaris/SPARC /bin/as:
as: v8.s, line 128: error: invalid digit in radix 10
as seems to only understand single-digit labels
as: v8.s, line 140: error: statement syntax
as: v8.s, line 157: error: unknown opcode .rept
as: v8.s, line 157: error: statement syntax
as: v8.s, line 163: error: unknown opcode .endr
as: v8.s, line 163: error: statement syntax
and knows nothing about .rept/.endr
Here are the hacks I've used to make some progress:
diff --git a/libffi/src/sparc/v8.S b/libffi/src/sparc/v8.S
--- a/libffi/src/sparc/v8.S
+++ b/libffi/src/sparc/v8.S
@@ -48,7 +48,9 @@
#ifndef __GNUC__
.align 8
.globl C(ffi_flush_icache)
+#if !(defined(__sun__) defined(__svr4__))
.type C(ffi_flush_icache),@function
+#endif
FFI_HIDDEN(C(ffi_flush_icache))
C(ffi_flush_icache):
@@ -66,14 +68,17 @@ 1: iflush %o0
.size C(ffi_flush_icache), . - C(ffi_flush_icache)
#endif
-.macro E index
- .align 16
- .org 2b + \index * 16
-.endm
+#if defined(__sun__) defined(__svr4__)
+# define E(INDEX) .align 16
+#else
+# define E(INDEX) .align 16; .org 2b + INDEX * 16
+#endif
.align 8
.globl C(ffi_call_v8)
+#if !(defined(__sun__) defined(__svr4__))
.type C(ffi_call_v8),@function
+#endif
FFI_HIDDEN(C(ffi_call_v8))
C(ffi_call_v8):
@@ -114,71 +119,71 @@ 1: add %o7, %l0, %o7 ! o7 = 0b + ret_typ
! Note that each entry is 4 insns, enforced by the E macro.
.align 16
2:
-E SPARC_RET_VOID
+E(SPARC_RET_VOID)
ret
restore
-E SPARC_RET_STRUCT
+E(SPARC_RET_STRUCT)
unimp
-E SPARC_RET_UINT8
+E(SPARC_RET_UINT8)
and %o0, 0xff, %o0
st %o0, [%i2]
ret
restore
-E SPARC_RET_SINT8
+E(SPARC_RET_SINT8)
sll %o0, 24, %o0
b 7f
sra %o0, 24, %o0
-E SPARC_RET_UINT16
+E(SPARC_RET_UINT16)
sll %o0, 16, %o0
b 7f
srl %o0, 16, %o0
-E SPARC_RET_SINT16
+E(SPARC_RET_SINT16)
sll %o0, 16, %o0
b 7f
sra %o0, 16, %o0
-E SPARC_RET_UINT32
+E(SPARC_RET_UINT32)
7: st %o0, [%i2]
ret
restore
-E SP_V8_RET_CPLX16
+E(SP_V8_RET_CPLX16)
sth %o0, [%i2+2]
b 9f
srl %o0, 16, %o0
-E SPARC_RET_INT64
+E(SPARC_RET_INT64)
st %o0, [%i2]
st %o1, [%i2+4]
ret
restore
-E SPARC_RET_INT128
+E(SPARC_RET_INT128)
std %o0, [%i2]
std %o2, [%i2+8]
ret
restore
-E SPARC_RET_F_8
+E(SPARC_RET_F_8)
st %f7, [%i2+7*4]
nop
st %f6, [%i2+6*4]
nop
-E SPARC_RET_F_6
+E(SPARC_RET_F_6)
st %f5, [%i2+5*4]
nop
st %f4, [%i2+4*4]
nop
-E SPARC_RET_F_4
+E(SPARC_RET_F_4)
st %f3, [%i2+3*4]
nop
st %f2, [%i2+2*4]
nop
-E SPARC_RET_F_2
+E(SPARC_RET_F_2)
st %f1, [%i2+4]
st %f0, [%i2]
ret
restore
-E SP_V8_RET_CPLX8
+E(SP_V8_RET_CPLX8)
stb %o0, [%i2+1]
b 10f
srl %o0, 8, %o0
-E SPARC_RET_F_1
+E(SPARC_RET_F_1)
st %f0, [%i2]
ret
restore
@@ -231,7 +236,9 @@ 2:
.align 8
.globl C(ffi_go_closure_v8)
+#if !(defined(__sun__) defined(__svr4__))
.type C(ffi_go_closure_v8),@function
+#endif
FFI_HIDDEN(C(ffi_go_closure_v8))
C(ffi_go_closure_v8):
@@ -249,7 +256,9 @@ C(ffi_go_closure_v8):
.align 8
.globl C(ffi_closure_v8)
+#if !(defined(__sun__) defined(__svr4__))
.type C(ffi_closure_v8),@function
+#endif
FFI_HIDDEN(C(ffi_closure_v8))
C(ffi_closure_v8):
@@ -285,70 +294,70 @@ 1: sll %o0, 4, %o0 ! o0 = o0 * 16
! Note that each entry is 4 insns, enforced by the E macro.
.align 16
2:
-E SPARC_RET_VOID
+E(SPARC_RET_VOID)
ret
restore
-E SPARC_RET_STRUCT
Re: [PATCH, AARCH64] Fix ICE in CCMP (PR64015)
On 15/12/14 08:41, Zhenqiang Chen wrote:
-Original Message-
From: Richard Henderson [mailto:r...@redhat.com]
Sent: Saturday, December 13, 2014 3:26 AM
To: Zhenqiang Chen
Cc: Marcus Shawcroft; gcc-patches@gcc.gnu.org
Subject: Re: [PATCH, AARCH64] Fix ICE in CCMP (PR64015)
- tree lhs = gimple_assign_lhs (g);
enum machine_mode mode = TYPE_MODE (TREE_TYPE (lhs));
rtx target = gen_reg_rtx (mode);
+
+ start_sequence ();
tmp = emit_cstore (target, icode, NE, cc_mode, cc_mode,
0, tmp, const0_rtx, 1, mode);
if (tmp)
- return tmp;
+ {
+ rtx seq = get_insns ();
+ end_sequence ();
+ emit_insn (prep_seq);
+ emit_insn (gen_seq);
+ emit_insn (seq);
+ return tmp;
+ }
+ end_sequence ();
Given that you're already doing delete_insns_since (last) at the end of this
function, I don't think you need a new sequence around the emit_cstore.
Just
emit_insn (prep_seq);
emit_insn (gen_seq);
tmp = emit_cstore (...);
if (tmp)
return tmp;
Updated.
+ int unsignedp = code == LTU || code == LEU || code == GTU || code
+ == GEU;
You don't need to examine the code, you can look at the argument:
TYPE_UNSIGNED (TREE_TYPE (treeop0))
Updated.
+ op0 = prepare_operand (icode, op0, 2, op_mode, cmp_mode,
+ unsignedp);
+ op1 = prepare_operand (icode, op1, 3, op_mode, cmp_mode,
+ unsignedp); if (!op0 || !op1)
+{
+ end_sequence ();
+ return NULL_RTX;
+}
+ *prep_seq = get_insns ();
+ end_sequence ();
+
+ cmp = gen_rtx_fmt_ee ((enum rtx_code) code, cmp_mode, op0, op1);
+ target = gen_rtx_REG (CCmode, CC_REGNUM);
+
+ create_output_operand (ops[0], target, CCmode);
+ create_fixed_operand (ops[1], cmp); create_fixed_operand (ops[2],
+ op0); create_fixed_operand (ops[3], op1);
Hmm. With so many fixed operands, I think you may be better off not
creating the cmpmode expander in the first place. Just inline the
SELECT_CC_MODE and everything right here.
In the patch, I use prepare_operand (icode, op0, 2, ...) to do the operand MODE
conversion (from HI/QI to SI), which needs a cmpmode expander. Without it, I
have to add additional codes to do the conversion (as it in previous patch, which
leads to PR64015).
Ping~,
verified this patch will pass speck2k6 build without ICE anymore.
Thanks!
-Zhenqiang
Re: [RFC] POWER8 default for PPC64LE
On Wed, 2015-01-14 at 13:36 -0700, Jeff Law wrote: On 01/14/15 13:32, David Edelsohn wrote: The PPC64LE ABI specifies POWER8 ISA as the minimum hardware requierment. Currently, Linux distributions are building the toolchain using --with-cpu=power7 or power8, as they wish. GCC defaults to essentially the POWER4 ISA. The appended patch changes the default for PPC64LE to POWER8 (ISA 2.7). 32-bit PPC SVR4 is not really defined, but it is left unchanged with no minimum ISA. The default ISA can be overridden using --with-cpu= and we presume that Linux distributions and users will continue to configure as they require for their deployment. * config/rs6000/default64.h (TARGET_DEFAULT) [LITTLE_ENDIAN]: Use ISA 2.7 (POWER8). Given you've got a new ABI in play here, seems like the perfect time to bump the default ISA to something reasonable. Agreed. Given the new ABI requires POWER8 as the minimum, I think this patch is a no brainer. Peter
Re: [PATCH, RFC] LRA subreg handling
On 14/01/15 02:20 PM, Robert Suchanek wrote:
Hi Vladimir,
An issue has been identified with LRA when running CPU2006 h264ref benchmark.
I'll try to describe what the issue is and a fix applied as it is very
difficult to reproduce it and it is next to impossible to create a narrowed
testcase on top of the source code restrictions.
The concerned LRA code in lra-constraints.c is the following:
if (GET_CODE (*loc) == SUBREG)
{
reg = SUBREG_REG (*loc);
byte = SUBREG_BYTE (*loc);
if (REG_P (reg)
/* Strict_low_part requires reload the register not
the sub-register. */
(curr_static_id-operand[i].strict_low
|| (GET_MODE_SIZE (mode)
= GET_MODE_SIZE (GET_MODE (reg))
(hard_regno
= get_try_hard_regno (REGNO (reg))) = 0
(simplify_subreg_regno
(hard_regno,
GET_MODE (reg), byte, mode) 0)
(goal_alt[i] == NO_REGS
|| (simplify_subreg_regno
(ira_class_hard_regs[goal_alt[i]][0],
GET_MODE (reg), byte, mode) = 0
{
loc = SUBREG_REG (*loc);
mode = GET_MODE (*loc);
}
}
The above works just fine when we deal with strict_low_part or a subreg
smaller than a word.
However, multi-word operations that were emitted as a sequence of operations
on word sized parts of the DImode register appears to expose a problem with
LRA e.g. '(set (subreg: SI (reg: DI)) ...)'.
LRA does not realize that it actually uses the other halve of the DI-mode
register leading to a situation where it modifies one halve of the result and
spills the whole register with the other halve undefined.
In the dump I can see the following:
Creating newreg=1552 from oldreg=521, assigning class GR_REGS to r1552
1487: r1552:DI#4=r1404:SI+r1509:SI
REG_DEAD r1509:SI
REG_DEAD r1404:SI
Inserting insn reload after:
1735: r521:DI=r1552:DI
There is nothing in the dump that sets r1552:DI#0 nor a reload is inserted
to load the value before modifying it but it is spilled.
As it is a multi-word register, the split pass emits an additional instruction
to load the whole 64-bit value but since one halve was modified, only
register $20 appears in the live-in set. In contrast to $20, $21 is being used
but not added to the live-in set.
...
;; live in 4 [$4] 6 [$6] 7 [$7] 10 [$10] 11 [$11] 12 [$12] 13 [$13]
[$14] 15 [$15] 16 [$16] 17 [$17] 20 [$20] 22 [$22] 23 [$23] 24 [$24] 25 [$25]
29 [$sp] 30 [$fp] 31 [$31] 52 [$f20] 79 [$fakec]
...
(insn 1788 1077 1789 80 (set (reg:SI 20 $20 [orig:521 distortion ] [521])
(mem/c:SI (plus:SI (reg/f:SI 29 $sp)
(const_int 40 [0x28])) [16 %sfp+40 S4 A64])) rdopt.c:257 288
{*movsi_internal}
(nil))
(insn 1789 1788 1743 80 (set (reg:SI 21 $21 [ distortion+4 ])
(mem/c:SI (plus:SI (reg/f:SI 29 $sp)
(const_int 44 [0x2c])) [16 %sfp+44 S4 A32])) rdopt.c:257 288
{*movsi_internal}
(nil))
...
The potential fix for this is to promote the type of a subreg OP_OUT to
OP_INOUT
to treat the pseudo register (r1552 in this case) as input and LRA will be
forced
to insert a reload before modifying its contents.
Handling of strict_low_part case is fine as the operand is described in the
MD pattern
as IN_OUT through modifiers.
With the above change in place, we get a reload before assignment:
Creating newreg=1552 from oldreg=521, assigning class GR_REGS to r1552
1487: r1552:DI#4=r1404:SI+r1509:SI
REG_DEAD r1509:SI
REG_DEAD r1404:SI
Inserting insn reload before:
1735: r1552:DI=r521:DI
Inserting insn reload after:
1736: r521:DI=r1552:DI
and the benchmark happily passes the runtime check.
The question is whether changing the type to OP_INOUT is the correct and
valid fix?
Regards,
Robert
2015-01-14 Robert Suchanek robert.sucha...@imgtec.com
gcc/
* lra-constraints.c (curr_insn_transform): Change the type of a reload
pseudo to OP_INOUT.
---
gcc/lra-constraints.c |1 +
1 file changed, 1 insertion(+)
diff --git a/gcc/lra-constraints.c b/gcc/lra-constraints.c
index ec28b7f..018968b 100644
--- a/gcc/lra-constraints.c
+++ b/gcc/lra-constraints.c
@@ -3798,6 +3798,7 @@ curr_insn_transform (void)
(ira_class_hard_regs[goal_alt[i]][0],
GET_MODE (reg), byte, mode) = 0)
{
+ type = OP_INOUT;
loc = SUBREG_REG (*loc);
mode = GET_MODE (*loc);
}
Robert, thanks for working on the issue. Your approach is in the right
direction. But I believe the change should be
if (type == OP_OUT)
type = OP_INOUT;
Otherwise, I will generate still a right code but an additional insn
which will not go away later.
With this
Re: [PATCH] IPA ICF: add comparison for target and optimization nodes
On 01/15/2015 05:20 PM, Rainer Orth wrote: Martin Liška mli...@suse.cz writes: On 01/07/2015 12:38 PM, 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 Hello. Apart from the previous patch, I would like to install following patch which introduces new dump functions related to target and optimization nodes. These functions dump just different flags. Patch has been tested on x86_64-linux-pc. Unfortunately, this patch breaks Solaris/SPARC bootstrap: options-save.c:3267:34: error: unused parameter 'indent' [-Werror=unused-parameter] int indent, ^ options-save.c:3268:55: error: unused parameter 'ptr1' [-Werror=unused-parameter] struct cl_target_option *ptr1, ^ options-save.c:3269:55: error: unused parameter 'ptr2' [-Werror=unused-parameter] struct cl_target_option *ptr2) ^ The following patch fixes this and allow the bootstrap to continue. 2015-01-15 Rainer Orth r...@cebitec.uni-bielefeld.de * optc-save-gen.awk (cl_target_option_print_diff): Mark indent, ptr1, ptr2 unused. Ok for mainline? Rainer Hello Rainer. Thank you for the patch. Martin
Re: [PATCH] Fix for PR64081 in RTL loop unroller
On 01/15/15 09:36, Zamyatin, Igor wrote: On 01/13/15 11:01, Zamyatin, Igor wrote: 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. Yes, do you think it's better to check exactly immediate predecessors? I'd use the same structure that you have in iv_get_reaching_def. If there was a reasonable way to factor that test into a single function and call it from both places that would be even better. Not sure it's possible to merge DF_REG_DEF_CHAIN walk and DF_REF_CHAIN walk... OK. Just use the same overall structure if we can't pull the test out into a single function that could be called from both places. jeff
Re: [Ping] Port of VTV for Cygwin and MinGW
On Wed, Jan 14, 2015 at 11:54 PM, Patrick Wollgast patrick.wollg...@rub.de wrote: Is there something I'm still supposed to do, since I don't have write access and this was the last part missing an OK? Somebody with write access will need to commit the patch for you. You should send a new clean patch including all the changes, along with updated ChangeLog entries. Ian
RE: [PATCH] Fix for PR64081 in RTL loop unroller
On 01/13/15 11:01, Zamyatin, Igor wrote: 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. Yes, do you think it's better to check exactly immediate predecessors? I'd use the same structure that you have in iv_get_reaching_def. If there was a reasonable way to factor that test into a single function and call it from both places that would be even better. Not sure it's possible to merge DF_REG_DEF_CHAIN walk and DF_REF_CHAIN walk... Thanks, Igor Jeff
Re: [PATCH 3/3, ARM, libgcc, ping6] Code size optimization for the fmul/fdiv and dmul/ddiv function in libgcc
On Jan 14, 2015, at 6:52 AM, Richard Earnshaw rearn...@arm.com wrote: On 14/01/15 11:57, Thomas Preud'homme wrote: Ping? I'm OK with this, but I think you also need a generic testsuite maintainer to go over the target independent parts. Ok.
Re: Fix ARM bootstrap - xgene tune params
Richard, Thanks for catching this. Your change is optimal for X-Gene 1. —Phil. On 15 Jan 2015, at 19:51, Richard Earnshaw rearn...@arm.com wrote: The recent xgene tuning parameters merge broke the ARM bootstrap, since the tables have been extended by an additional parameter giving: gcc/config/arm/arm.c:1932:1: error: missing initializer for member 'tune_params::fuseable_ops' [-Werror=missing-field-initializers] }; ^ Fixed as below. I've no idea if this is the optimial behaviour for Xgene parts, but it preserves the previous behaviour of the compiler before this pass was added. I'll let those who really know decide whether a more comprehensive change is needed. R. 2015-01-15 Richard Earnshaw rearn...@arm.com * arm.c (arm_xgene_tune): Add default initializer for instruction fusion.xgene.patch
Stage 3 RFC: using jit for ahead-of-time compilation
Release managers: given that this only touches the jit, and that the jit is off by default, any objections if I go ahead and commit this? It's a late-breaking feature, but the jit as a whole is new, and I think the following is a big win, so I'd like to proceed with this in stage 3 (i.e. in the next 24 hours). There are docs and testcases. New jit API entrypoint: gcc_jit_context_compile_to_file This patch adds a way to use libgccjit for ahead-of-time compilation. I noticed that given the postprocessing steps the jit has to take to turn the .s file into in-memory code (invoke driver to convert to a .so and then dlopen), that it's not much of a leap to support compiling the .s file into objects, dynamic libraries, and executables. Doing so seems like a big win from a feature standpoint: people with pre-existing frontend code who want a backend can then plug in libgccjit and have a compiler, without needing to write it as a GCC frontend, or use LLVM. jit becomes something of a misnomer for this use-case. As an experiment, I used this technique to add a compiler for the language I'll refer to as brainf (ahem), and wrote this up for the libgccjit tutorial (it's all in the patch); prebuilt HTML can be seen at: https://dmalcolm.fedorapeople.org/gcc/libgccjit-api-docs-wip/intro/tutorial05.html The main things that are missing are: * specifying libraries to link against (Uli had some ideas about this) * cross-compilation support (needs some deeper work, especially the test suite, so deferrable to gcc 6, I guess) but the feature is useful with the patch as-is. The new test cases take jit.sum's # of expected passes from 7514 to 7571. gcc/jit/ChangeLog: * docs/cp/topics/results.rst: Rename to... * docs/cp/topics/compilation.rst: ...this, and add section on ahead-of-time compilation. * docs/cp/topics/index.rst: Update for renaming of results.rst to compilation.rst. * docs/examples/emit-alphabet.bf: New file, a sample brainf script. * docs/examples/tut05-bf.c: New file, implementing a compiler for brainf. * docs/internals/test-hello-world.exe.log.txt: Update to reflect changes to logger output. * docs/intro/index.rst: Add tutorial05.rst * docs/intro/tutorial05.rst: New file. * docs/topics/results.rst: Rename to... * docs/topics/compilation.rst: ...this, and add section on ahead-of-time compilation. * docs/topics/index.rst: Update for renaming of results.rst to compilation.rst. * jit-playback.c (gcc::jit::playback::context::compile): Convert return type from result * to void. Move the code to convert to dso and dlopen the result to a new pure virtual postprocess method. (gcc::jit::playback::compile_to_memory::compile_to_memory): New function. (gcc::jit::playback::compile_to_memory::postprocess): New function, based on playback::context::compile. (gcc::jit::playback::compile_to_file::compile_to_file): New function. (gcc::jit::playback::compile_to_file::postprocess): New function. (gcc::jit::playback::compile_to_file::copy_file): New function. (gcc::jit::playback::context::convert_to_dso): Move internals to... (gcc::jit::playback::context::invoke_driver): New method. Add -shared and -c options to driver's argv as needed. * jit-playback.h: Include timevar.h. (gcc::jit::playback::context::compile): Convert return type from result * to void. (gcc::jit::playback::context::postprocess): New pure virtual function, making this an abstract base class. (gcc::jit::playback::context::get_tempdir): New accessor. (gcc::jit::playback::context::invoke_driver): New function. (class gcc::jit::playback::compile_to_memory): New subclass of playback::context. (class gcc::jit::playback::compile_to_file): Likewise. * jit-recording.c (gcc::jit::recording::context::compile): Use a playback::compile_to_memory, and extract its result. (gcc::jit::recording::context::compile_to_file): New function. * jit-recording.h (gcc::jit::recording::context::compile_to_file): New function. * libgccjit++.h (gccjit::context::compile_to_file): New method. * libgccjit.c (gcc_jit_context_compile): Update log message to clarify that this is an in-memory compile. (gcc_jit_context_compile_to_file): New function. * libgccjit.h (gcc_jit_context): Clarify that you can compile a context more than once, and that you can compile to a file as well as to memory. (gcc_jit_result): Clarify that this is the result of an in-memory compilation. (gcc_jit_context_compile): Clarify that you can compile, and that this is an in-memory compilation. (enum gcc_jit_output_kind): New enum.
Re: libgo patch committed: Update to Go 1.4
On Thu, Jan 15, 2015 at 8:30 AM, Rainer Orth
r...@cebitec.uni-bielefeld.de wrote:
This (and perhaps the previous gotools) patch broke Solaris bootstrap:
/vol/gcc/src/hg/trunk/local/libgo/go/net/tcpsockopt_unix.go:23:73: error:
reference to undefined identifier 'syscall.TCP_KEEPINTVL'
if err := syscall.SetsockoptInt(fd.sysfd, syscall.IPPROTO_TCP,
syscall.TCP_KEEPINTVL, secs); err != nil {
/vol/gcc/src/hg/trunk/local/libgo/go/net/tcpsockopt_unix.go:26:103: error:
reference to undefined identifier 'syscall.TCP_KEEPIDLE'
return os.NewSyscallError(setsockopt, syscall.SetsockoptInt(fd.sysfd,
syscall.IPPROTO_TCP, syscall.TCP_KEEPIDLE, secs))
make[4]: *** [net.lo] Error 1
The following patch fixes this:
That's interesting--would you mind looking into this just a bit more?
What version of Solaris was this? In the gc version of the library,
those symbols are defined for Solaris. TCP_KEEPINTVL is 0x24 and
TCP_KEEPIDLE is 0x22. I just want to make sure that they are really
not defined on your system, and the problem is not that mksysinfo is
somehow failing to handle the definition.
Ian
Re: [PATCH] Avoid -Werror=format-security errors in libcpp
On Thu, 15 Jan 2015, Jakub Jelinek wrote:
--- libcpp/expr.c.jj 2015-01-14 11:01:34.0 +0100
+++ libcpp/expr.c 2015-01-14 14:35:52.851002344 +0100
@@ -672,16 +672,17 @@ cpp_classify_number (cpp_reader *pfile,
if ((result CPP_N_WIDTH) == CPP_N_LARGE
CPP_OPTION (pfile, cpp_warn_long_long))
{
- const char *message = CPP_OPTION (pfile, cplusplus)
- ? N_(use of C++11 long long integer constant)
- : N_(use of C99 long long integer constant);
-
if (CPP_OPTION (pfile, c99))
cpp_warning_with_line (pfile, CPP_W_LONG_LONG, virtual_location,
-0, message);
+0, CPP_OPTION (pfile, cplusplus)
+ ? use of C++11 long long integer
constant
+ : use of C99 long long integer
constant);
else
cpp_pedwarning_with_line (pfile, CPP_W_LONG_LONG,
- virtual_location, 0, message);
+ virtual_location, 0,
+ CPP_OPTION (pfile, cplusplus)
+ ? use of C++11 long long integer
constant
+ : use of C99 long long integer
constant);
I think this sort of thing needs N_() on both messages so that they both
get extracted for translation.
--
Joseph S. Myers
jos...@codesourcery.com
Re: libgo patch committed: Update to Go 1.4
On Thu, Jan 15, 2015 at 9:45 AM, Jakub Jelinek ja...@redhat.com wrote:
On Thu, Jan 15, 2015 at 01:58:43PM +0100, Richard Biener wrote:
[ 5286s] ../../../libgo/go/reflect/makefuncgo_s390x.go:323:5: error:
expected ';
' or '}' or newline
[ 5286s]} else {
[ 5286s] ^
Bet that
} else {
line should have been replaced with
default:
Indeed. I committed that patch, and actually tested that the file at
least compiled. Committed to mainline.
Ian
diff -r a8a14eba5197 libgo/go/reflect/makefuncgo_s390x.go
--- a/libgo/go/reflect/makefuncgo_s390x.go Wed Jan 14 16:52:08 2015 -0800
+++ b/libgo/go/reflect/makefuncgo_s390x.go Thu Jan 15 12:41:04 2015 -0800
@@ -320,7 +320,7 @@
switch v.Kind() {
case Ptr, UnsafePointer, Chan, Func, Map:
w = uintptr(v.pointer())
- } else {
+ default:
memmove(unsafe.Pointer(w), v.ptr, v.typ.size)
if ret_off_reg != 0 {
w = s390xReloadForRegister(
Re: [PATCH] Fix PR c++/59366 A friend function template defined in a class is found without ADL
Applied, thanks. Jason
Re: [PATCH] Fix PR testsuite/64605
On Jan 15, 2015, at 11:54 AM, Ilya Verbin iver...@gmail.com wrote: On 15 Jan 11:20, Mike Stump wrote: On Jan 15, 2015, at 9:53 AM, Ilya Verbin iver...@gmail.com wrote: If I just remove 'load_gcc_lib gcc-dg.exp' from libatomic.exp, like this is done in libitm.exp, it will not work: Ok, original patch is fine. Oh, I see, it's loaded by libitm/testsuite/libitm.c/c.exp, so I changed the patch for consistency. Here is the final version, OK to commit? Ok. That version looks better. Thanks for finding that bit.
Re: Stage3 closing soon, call for patch pings
On Thu, Jan 15, 2015 at 1:04 PM, Jeff Law l...@redhat.com wrote: Stage3 is closing rapidly. I've drained my queue of patches I was tracking for gcc-5.However, note that I don't track everything. If it's a patch for a backend, language other than C or seemingly has another maintainer that's engaged in review, then I haven't been tracking the patch. So this is my final call for patch pings. I've got some bandwidth and may be able to look at a few patches that have otherwise stalled. This one was updated yesterday: https://gcc.gnu.org/ml/gcc-patches/2015-01/msg00956.html I guess it won't hurt to list it here. --- H.J.
Re: [Patch] Missing plugin header files
On 16 January 2015 at 00:00, Steve Ellcey sell...@imgtec.com wrote: 2015-01-14 Steve Ellcey sell...@mips.com * Makefile.in (PLUGIN_HEADERS): Add dominance.h, cfg.h, cfgrtl.h, cfganal.h, cfgbuild.h, cfgcleanup.h, lcm.h, builtins.def, chkp-builtins.def, and pass-instances.def Should pass-instances.def be removed from ChangeLog since it was already present in PLUGIN_HEADERS ? Thanks, Prathamesh Looks like a cut-n-paste error on my part when I copied the file names from Makefile.in to ChangeLog. I will fix the ChangeLog entry. Thanks for the patch, I missed to put headers in PLUGIN_HEADERS after putting includes in gcc-plugin.h. -:( Regards, Prathamesh Steve Ellcey
[PATCH, committed] remove duplicate contents explow.h, dojump.h
r219655 added two files explow.h, dojump.h with duplicated contents,
silly mistake from my side. The attached patch removes duplicate
contents. Committed (r219680) as obvious.
Thanks,
Prathamesh
2015-01-15 Prathamesh Kulkarni prathamesh.kulka...@linaro.org
* explow.h: Remove duplicate contents.
* dojump.h: Likewise.
Index: gcc/dojump.h
===
--- gcc/dojump.h (revision 219679)
+++ gcc/dojump.h (working copy)
@@ -76,159 +76,3 @@
enum rtx_code *, enum rtx_code *);
#endif /* GCC_DOJUMP_H */
-/* Export function prototypes from dojump.c.
- Copyright (C) 2015-2016 Free Software Foundation, Inc.
-
-This file is part of GCC.
-
-GCC 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.
-
-GCC 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 GCC; see the file COPYING3. If not see
-http://www.gnu.org/licenses/. */
-
-#ifndef GCC_DOJUMP_H
-#define GCC_DOJUMP_H
-
-/* At the start of a function, record that we have no previously-pushed
- arguments waiting to be popped. */
-extern void init_pending_stack_adjust (void);
-
-/* Discard any pending stack adjustment. */
-extern void discard_pending_stack_adjust (void);
-
-/* When exiting from function, if safe, clear out any pending stack adjust
- so the adjustment won't get done. */
-extern void clear_pending_stack_adjust (void);
-
-/* Pop any previously-pushed arguments that have not been popped yet. */
-extern void do_pending_stack_adjust (void);
-
-/* Struct for saving/restoring of pending_stack_adjust/stack_pointer_delta
- values. */
-
-struct saved_pending_stack_adjust
-{
- /* Saved value of pending_stack_adjust. */
- int x_pending_stack_adjust;
-
- /* Saved value of stack_pointer_delta. */
- int x_stack_pointer_delta;
-};
-
-/* Remember pending_stack_adjust/stack_pointer_delta.
- To be used around code that may call do_pending_stack_adjust (),
- but the generated code could be discarded e.g. using delete_insns_since. */
-
-extern void save_pending_stack_adjust (saved_pending_stack_adjust *);
-
-/* Restore the saved pending_stack_adjust/stack_pointer_delta. */
-
-extern void restore_pending_stack_adjust (saved_pending_stack_adjust *);
-
-/* Generate code to evaluate EXP and jump to LABEL if the value is zero. */
-extern void jumpifnot (tree, rtx, int);
-extern void jumpifnot_1 (enum tree_code, tree, tree, rtx, int);
-
-/* Generate code to evaluate EXP and jump to LABEL if the value is nonzero. */
-extern void jumpif (tree, rtx, int);
-extern void jumpif_1 (enum tree_code, tree, tree, rtx, int);
-
-/* Generate code to evaluate EXP and jump to IF_FALSE_LABEL if
- the result is zero, or IF_TRUE_LABEL if the result is one. */
-extern void do_jump (tree, rtx, rtx, int);
-extern void do_jump_1 (enum tree_code, tree, tree, rtx, rtx, int);
-
-extern void do_compare_rtx_and_jump (rtx, rtx, enum rtx_code, int,
- machine_mode, rtx, rtx, rtx, int);
-
-extern bool split_comparison (enum rtx_code, machine_mode,
- enum rtx_code *, enum rtx_code *);
-
-#endif /* GCC_DOJUMP_H */
-/* Export function prototypes from dojump.c.
- Copyright (C) 2015-2016 Free Software Foundation, Inc.
-
-This file is part of GCC.
-
-GCC 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.
-
-GCC 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 GCC; see the file COPYING3. If not see
-http://www.gnu.org/licenses/. */
-
-#ifndef GCC_DOJUMP_H
-#define GCC_DOJUMP_H
-
-/* At the start of a function, record that we have no previously-pushed
- arguments waiting to be popped. */
-extern void init_pending_stack_adjust (void);
-
-/* Discard any pending stack adjustment. */
-extern void discard_pending_stack_adjust (void);
-
-/* When exiting from function, if safe, clear out any pending stack adjust
- so the adjustment won't get done. */
-extern void clear_pending_stack_adjust (void);
-
-/* Pop any previously-pushed arguments that have not been popped yet. */
-extern void do_pending_stack_adjust (void);
-
-/* Struct for saving/restoring of pending_stack_adjust/stack_pointer_delta
- values. */
-
-struct saved_pending_stack_adjust
-{
- /* Saved
Re: [PATCH] Fix PR testsuite/64605
On 15 Jan 11:20, Mike Stump wrote:
On Jan 15, 2015, at 9:53 AM, Ilya Verbin iver...@gmail.com wrote:
If I just remove 'load_gcc_lib gcc-dg.exp' from libatomic.exp, like this is
done
in libitm.exp, it will not work:
Ok, original patch is fine.
Oh, I see, it's loaded by libitm/testsuite/libitm.c/c.exp, so I changed the
patch for consistency. Here is the final version, OK to commit?
PR testsuite/64605
* testsuite/lib/libatomic.exp: Do not load gcc-dg.exp.
* testsuite/libatomic.c/c.exp: Load gcc-dg.exp.
diff --git a/libatomic/testsuite/lib/libatomic.exp
b/libatomic/testsuite/lib/libatomic.exp
index 28cbaa8..0491c18 100644
--- a/libatomic/testsuite/lib/libatomic.exp
+++ b/libatomic/testsuite/lib/libatomic.exp
@@ -23,6 +23,11 @@ proc load_gcc_lib { filename } {
}
load_lib dg.exp
+
+# Required to use gcc-dg.exp - however, the latter should NOT be
+# loaded until ${tool}_target_compile is defined since it uses that
+# to determine default LTO options.
+
load_gcc_lib file-format.exp
load_gcc_lib target-supports.exp
load_gcc_lib target-utils.exp
@@ -40,7 +45,6 @@ load_gcc_lib torture-options.exp
load_gcc_lib timeout.exp
load_gcc_lib timeout-dg.exp
load_gcc_lib fortran-modules.exp
-load_gcc_lib gcc-dg.exp
set dg-do-what-default run
diff --git a/libatomic/testsuite/libatomic.c/c.exp
b/libatomic/testsuite/libatomic.c/c.exp
index 1da3cb1..dbdb5eb 100644
--- a/libatomic/testsuite/libatomic.c/c.exp
+++ b/libatomic/testsuite/libatomic.c/c.exp
@@ -21,6 +21,7 @@ if [info exists lang_test_file] then {
}
load_lib libatomic-dg.exp
+load_gcc_lib gcc-dg.exp
# If a testcase doesn't have special options, use these.
if ![info exists DEFAULT_CFLAGS] then {
-- Ilya
Re: Stage 3 RFC: using jit for ahead-of-time compilation
On Thu, Jan 15, 2015 at 03:05:59PM -0500, David Malcolm wrote: Release managers: given that this only touches the jit, and that the jit is off by default, any objections if I go ahead and commit this? It's a late-breaking feature, but the jit as a whole is new, and I think the following is a big win, so I'd like to proceed with this in stage 3 (i.e. in the next 24 hours). There are docs and testcases. Ok with me. Jakub
[PATCH, committed] jit: prevent ICE with type mismatch in gcc_jit_block_add_assignment_op
gcc_jit_block_add_assignment_op was missing type-checking on the params,
which could lead to an ICE deep inside gimplification in fold-const.c:
10339 gcc_assert (TYPE_PRECISION (atype) == TYPE_PRECISION (type));
Takes jit.sum's # of expected passes from 7494 to 7514.
Committed to trunk as r219681.
(FWIW I generated the test case using
gcc_jit_context_dump_reproducer_to_file and minimized it by hand)
gcc/jit/ChangeLog:
* libgccjit.c (gcc_jit_block_add_assignment_op): Check that the
lvalue and the rvalue are of compatible type.
gcc/testsuite/ChangeLog:
* jit.dg/test-error-mismatching-types-in-assignment-op.c: New
test case.
---
gcc/jit/libgccjit.c| 10
...test-error-mismatching-types-in-assignment-op.c | 64 ++
2 files changed, 74 insertions(+)
create mode 100644
gcc/testsuite/jit.dg/test-error-mismatching-types-in-assignment-op.c
diff --git a/gcc/jit/libgccjit.c b/gcc/jit/libgccjit.c
index a78b3e7..0faf0f9 100644
--- a/gcc/jit/libgccjit.c
+++ b/gcc/jit/libgccjit.c
@@ -1900,6 +1900,16 @@ gcc_jit_block_add_assignment_op (gcc_jit_block *block,
unrecognized value for enum gcc_jit_binary_op: %i,
op);
RETURN_IF_FAIL (rvalue, ctxt, loc, NULL rvalue);
+ RETURN_IF_FAIL_PRINTF4 (
+compatible_types (lvalue-get_type (),
+ rvalue-get_type ()),
+ctxt, loc,
+mismatching types:
+ assignment to %s (type: %s) involving %s (type: %s),
+lvalue-get_debug_string (),
+lvalue-get_type ()-get_debug_string (),
+rvalue-get_debug_string (),
+rvalue-get_type ()-get_debug_string ());
gcc::jit::recording::statement *stmt = block-add_assignment_op (loc,
lvalue, op, rvalue);
diff --git
a/gcc/testsuite/jit.dg/test-error-mismatching-types-in-assignment-op.c
b/gcc/testsuite/jit.dg/test-error-mismatching-types-in-assignment-op.c
new file mode 100644
index 000..c86d334
--- /dev/null
+++ b/gcc/testsuite/jit.dg/test-error-mismatching-types-in-assignment-op.c
@@ -0,0 +1,64 @@
+#include libgccjit.h
+#include harness.h
+
+void
+create_code (gcc_jit_context *ctxt, void *user_data)
+{
+ /* Try to inject the equivalent of:
+static int idx;
+void test_func (void)
+ {
+ idx += (unsigned char)1; // mismatching type
+ }
+ and verify that we don't get an ICE inside gimplification
+ due to the type mismatch. */
+ gcc_jit_type *void_type =
+gcc_jit_context_get_type (ctxt, GCC_JIT_TYPE_VOID);
+ gcc_jit_type *int_type =
+gcc_jit_context_get_type (ctxt, GCC_JIT_TYPE_INT);
+ gcc_jit_type *unsigned_char_type =
+gcc_jit_context_get_type (ctxt, GCC_JIT_TYPE_UNSIGNED_CHAR);
+ gcc_jit_function *test_func =
+gcc_jit_context_new_function (ctxt, /* gcc_jit_context *ctxt */
+ NULL, /* gcc_jit_location *loc */
+ GCC_JIT_FUNCTION_EXPORTED, /* enum
gcc_jit_function_kind kind */
+ void_type, /* gcc_jit_type *return_type */
+ test_func, /* const char *name */
+ 0, /* int num_params */
+ NULL, /* gcc_jit_param **params */
+ 0); /* int is_variadic */
+ gcc_jit_block *block =
+gcc_jit_function_new_block (test_func, initial);
+
+ gcc_jit_rvalue *unsigned_char_1 =
+gcc_jit_context_new_rvalue_from_int (ctxt, /* gcc_jit_context *ctxt */
+ unsigned_char_type, /* gcc_jit_type
*numeric_type */
+ 1); /* int value */
+ gcc_jit_lvalue *idx =
+gcc_jit_context_new_global (ctxt, /* gcc_jit_context *ctxt */
+NULL, /* gcc_jit_location *loc */
+GCC_JIT_GLOBAL_INTERNAL, /* enum
gcc_jit_global_kind kind */
+int_type, /* gcc_jit_type *type */
+idx); /* const char *name */
+
+ gcc_jit_block_add_assignment_op (block, /*gcc_jit_block *block */
+ NULL, /* gcc_jit_location *loc */
+ idx, /* gcc_jit_lvalue *lvalue */
+ GCC_JIT_BINARY_OP_PLUS, /* enum
gcc_jit_binary_op op */
+ unsigned_char_1); /* gcc_jit_rvalue *rvalue
*/
+ gcc_jit_block_end_with_void_return (block, /*gcc_jit_block *block */
+ NULL);
+}
+
+void
+verify_code (gcc_jit_context *ctxt, gcc_jit_result *result)
+{
+ CHECK_VALUE (result, NULL);
+
+ /* Verify that the correct error message was emitted. */
+ CHECK_STRING_VALUE (gcc_jit_context_get_first_error (ctxt),
+ gcc_jit_block_add_assignment_op:
+ mismatching types:
+ assignment to idx (type: int)
+ involving (unsigned char)1 (type: unsigned
Re: Merge current set of OpenACC changes from gomp-4_0-branch
On 01/15/15 13:20, Thomas Schwinge wrote: Hi! In r219682, I have committed to trunk our current set of OpenACC changes, which we had prepared on gomp-4_0-branch. Thanks to everyone who has been contributing! Note that this is an experimental feature, incomplete, and subject to change in future versions of GCC. We shall update -- and keep updated -- https://gcc.gnu.org/wiki/OpenACC, to track the current status. (Please come back to that page in a few days, it has not yet been updated.) Please note that there are still a handful of patches pending (posted weeks ago, need to ping) that are needed for nvptx offloading, so that's not yet functional. Definitely ping them. We're trying hard to get things closed down and knowing what's still out there is very important. jeff
Re: libgo patch committed: Update to Go 1.4
On Thu, Jan 15, 2015 at 8:30 AM, Rainer Orth r...@cebitec.uni-bielefeld.de wrote: Apart from that, bootstrap fails in gotools: due to the use of -static-libgo, all commands there fail to link since the socket functions are missing. It seems like $LIBS from libgo needs to be added somewhere, but I'm unsure how best to handle this. To make any progress at all, I've just manually added -lsocket -lnsl to gotools/Makefile (AM_LDFLAGS). I also don't know what the best way is to handle this. For now I've just added a configure test to check whether the libraries are needed. Based on the libgo build, as far as I can tell, no other libraries should be needed. Ian 2015-01-15 Ian Lance Taylor i...@google.com * configure.ac: Check for networking libraries; see NET_LIBS. * Makefile.am (go$(EXEEXT)): Link against NET_LIBS. (gofmt$(EXEEXT), cgo$(EXEEXT)): Likewise. * configure, Makefile.in: Rebuild. Index: Makefile.am === --- Makefile.am (revision 219627) +++ Makefile.am (working copy) @@ -108,11 +108,11 @@ bin_PROGRAMS = go$(EXEEXT) gofmt$(EXEEXT libexecsub_PROGRAMS = cgo$(EXEEXT) go$(EXEEXT): $(go_cmd_go_files) zdefaultcc.go $(LIBGODEP) - $(GOLINK) $(go_cmd_go_files) zdefaultcc.go + $(GOLINK) $(go_cmd_go_files) zdefaultcc.go $(NET_LIBS) gofmt$(EXEEXT): $(go_cmd_gofmt_files) $(LIBGODEP) - $(GOLINK) $(go_cmd_gofmt_files) + $(GOLINK) $(go_cmd_gofmt_files) $(NET_LIBS) cgo$(EXEEXT): $(go_cmd_cgo_files) zdefaultcc.go $(LIBGODEP) - $(GOLINK) $(go_cmd_cgo_files) zdefaultcc.go + $(GOLINK) $(go_cmd_cgo_files) zdefaultcc.go $(NET_LIBS) else Index: configure.ac === --- configure.ac(revision 219408) +++ configure.ac(working copy) @@ -48,6 +48,37 @@ AC_PROG_GO AM_CONDITIONAL(NATIVE, test $cross_compiling = no) +dnl Test for -lsocket and -lnsl. Copied from libjava/configure.ac. +AC_CACHE_CHECK([for socket libraries], gotools_cv_lib_sockets, + [gotools_cv_lib_sockets= + gotools_check_both=no + AC_CHECK_FUNC(connect, gotools_check_socket=no, gotools_check_socket=yes) + if test $gotools_check_socket = yes; then + unset ac_cv_func_connect + AC_CHECK_LIB(socket, main, gotools_cv_lib_sockets=-lsocket, + gotools_check_both=yes) + fi + if test $gotools_check_both = yes; then + gotools_old_libs=$LIBS + LIBS=$LIBS -lsocket -lnsl + unset ac_cv_func_accept + AC_CHECK_FUNC(accept, + [gotools_check_nsl=no + gotools_cv_lib_sockets=-lsocket -lnsl]) + unset ac_cv_func_accept + LIBS=$gotools_old_libs + fi + unset ac_cv_func_gethostbyname + gotools_old_libs=$LIBS + AC_CHECK_FUNC(gethostbyname, , +[AC_CHECK_LIB(nsl, main, + [gotools_cv_lib_sockets=$gotools_cv_lib_sockets -lnsl])]) + unset ac_cv_func_gethostbyname + LIBS=$gotools_old_libs +]) +NET_LIBS=$gotools_cv_lib_sockets +AC_SUBST(NET_LIBS) + AC_CONFIG_FILES(Makefile) AC_OUTPUT
Re: [PATCH] Fix PR testsuite/64605
On Jan 15, 2015, at 9:53 AM, Ilya Verbin iver...@gmail.com wrote: If I just remove 'load_gcc_lib gcc-dg.exp' from libatomic.exp, like this is done in libitm.exp, it will not work: Ok, original patch is fine.
Re: Stage 3 RFC: using jit for ahead-of-time compilation
On January 15, 2015 9:05:59 PM CET, David Malcolm dmalc...@redhat.com wrote: Release managers: given that this only touches the jit, and that the jit is off by default, any objections if I go ahead and commit this? It's a late-breaking feature, but the jit as a whole is new, and I think the following is a big win, so I'd like to proceed with this in stage 3 (i.e. in the next 24 hours). There are docs and testcases. New jit API entrypoint: gcc_jit_context_compile_to_file This patch adds a way to use libgccjit for ahead-of-time compilation. I noticed that given the postprocessing steps the jit has to take to turn the .s file into in-memory code (invoke driver to convert to a .so and then dlopen), that it's not much of a leap to support compiling the .s file into objects, dynamic libraries, and executables. Doing so seems like a big win from a feature standpoint: people with pre-existing frontend code who want a backend can then plug in libgccjit and have a compiler, without needing to write it as a GCC frontend, or use LLVM. Note that you should make them aware of our runtime license with respect to the eligible compilation process. Which means this is not a way to implement proprietary front ends. Richard. jit becomes something of a misnomer for this use-case. As an experiment, I used this technique to add a compiler for the language I'll refer to as brainf (ahem), and wrote this up for the libgccjit tutorial (it's all in the patch); prebuilt HTML can be seen at: https://dmalcolm.fedorapeople.org/gcc/libgccjit-api-docs-wip/intro/tutorial05.html The main things that are missing are: * specifying libraries to link against (Uli had some ideas about this) * cross-compilation support (needs some deeper work, especially the test suite, so deferrable to gcc 6, I guess) but the feature is useful with the patch as-is. The new test cases take jit.sum's # of expected passes from 7514 to 7571. gcc/jit/ChangeLog: * docs/cp/topics/results.rst: Rename to... * docs/cp/topics/compilation.rst: ...this, and add section on ahead-of-time compilation. * docs/cp/topics/index.rst: Update for renaming of results.rst to compilation.rst. * docs/examples/emit-alphabet.bf: New file, a sample brainf script. * docs/examples/tut05-bf.c: New file, implementing a compiler for brainf. * docs/internals/test-hello-world.exe.log.txt: Update to reflect changes to logger output. * docs/intro/index.rst: Add tutorial05.rst * docs/intro/tutorial05.rst: New file. * docs/topics/results.rst: Rename to... * docs/topics/compilation.rst: ...this, and add section on ahead-of-time compilation. * docs/topics/index.rst: Update for renaming of results.rst to compilation.rst. * jit-playback.c (gcc::jit::playback::context::compile): Convert return type from result * to void. Move the code to convert to dso and dlopen the result to a new pure virtual postprocess method. (gcc::jit::playback::compile_to_memory::compile_to_memory): New function. (gcc::jit::playback::compile_to_memory::postprocess): New function, based on playback::context::compile. (gcc::jit::playback::compile_to_file::compile_to_file): New function. (gcc::jit::playback::compile_to_file::postprocess): New function. (gcc::jit::playback::compile_to_file::copy_file): New function. (gcc::jit::playback::context::convert_to_dso): Move internals to... (gcc::jit::playback::context::invoke_driver): New method. Add -shared and -c options to driver's argv as needed. * jit-playback.h: Include timevar.h. (gcc::jit::playback::context::compile): Convert return type from result * to void. (gcc::jit::playback::context::postprocess): New pure virtual function, making this an abstract base class. (gcc::jit::playback::context::get_tempdir): New accessor. (gcc::jit::playback::context::invoke_driver): New function. (class gcc::jit::playback::compile_to_memory): New subclass of playback::context. (class gcc::jit::playback::compile_to_file): Likewise. * jit-recording.c (gcc::jit::recording::context::compile): Use a playback::compile_to_memory, and extract its result. (gcc::jit::recording::context::compile_to_file): New function. * jit-recording.h (gcc::jit::recording::context::compile_to_file): New function. * libgccjit++.h (gccjit::context::compile_to_file): New method. * libgccjit.c (gcc_jit_context_compile): Update log message to clarify that this is an in-memory compile. (gcc_jit_context_compile_to_file): New function. * libgccjit.h (gcc_jit_context): Clarify that you can compile a context more than once, and that you can compile to a file as well as to memory. (gcc_jit_result): Clarify that this is the
Re: [Ping] Port of VTV for Cygwin and MinGW
On 15.01.2015 17:01, Ian Lance Taylor wrote:
On Wed, Jan 14, 2015 at 11:54 PM, Patrick Wollgast
patrick.wollg...@rub.de wrote:
Is there something I'm still supposed to do, since I don't have write
access and this was the last part missing an OK?
Somebody with write access will need to commit the patch for you. You
should send a new clean patch including all the changes, along with
updated ChangeLog entries.
Ian
For the clean patch I co'ed the latest version of the trunk again and
applied my patch. It applies correctly, except for two changes:
patching file libgcc/Makefile.in
Hunk #1 succeeded at 995 with fuzz 2 (offset 9 lines).
Hunk #2 succeeded at 1020 (offset 17 lines).
# This is a version of crtbegin for -static links.
crtbeginT$(objext): $(srcdir)/crtstuff.c
$(crt_compile) $(CRTSTUFF_T_CFLAGS) -c $ -DCRT_BEGIN
-DCRTSTUFFT_O
endif
ifeq ($(enable_vtable_verify),yes)
# These are used in vtable verification; see comments in source files
for
# more details.
I had to move the endif down, since something was added before
ifeq ($(enable_vtable_verify),yes) inside the if.
# This is a version of crtbegin for -static links.
crtbeginT$(objext): $(srcdir)/crtstuff.c
$(crt_compile) $(CRTSTUFF_T_CFLAGS) -c $ -DCRT_BEGIN
-DCRTSTUFFT_O
# crtoffloadbegin and crtoffloadend contain symbols, that mark the
begin and
# the end of tables with addresses, required for offloading.
crtoffloadbegin$(objext): $(srcdir)/offloadstuff.c
$(crt_compile) $(CRTSTUFF_T_CFLAGS) -c $ -DCRT_BEGIN
crtoffloadend$(objext): $(srcdir)/offloadstuff.c
$(crt_compile) $(CRTSTUFF_T_CFLAGS) -c $ -DCRT_END
endif
ifeq ($(enable_vtable_verify),yes)
# These are used in vtable verification; see comments in source files
for
# more details.
patching file libgcc/config.host
Hunk #1 succeeded at 621 (offset 6 lines).
Hunk #2 succeeded at 640 (offset 6 lines).
Hunk #3 succeeded at 660 (offset 6 lines).
Hunk #4 succeeded at 1198 with fuzz 2 (offset 495 lines).
tmake_file=${tmake_file} ${tmake_eh_file} ${tmake_dlldir_file}
i386/t-slibgcc-cygming i386/t-mingw32 t-dfprules i386/t-crtfm i386/t-chkstk
extra_parts=$extra_parts crtfastmath.o
The last two lines were changed to the following two lines.
tmake_file=${tmake_file} ${tmake_eh_file} ${tmake_dlldir_file}
i386/t-slibgcc-cygming i386/t-cygming i386/t-mingw32 t-dfprules
i386/t-crtfm i386/t-chkstk
extra_parts=$extra_parts crtbegin.o crtend.o crtfastmath.o
And therefore Hunk #4, which follows these lines, wasn't applied correctly.
These two parts were corrected in vtv_cygmin_clean.patch. For
convenience I also added vtv_cygmin_unclean.patch, which is the patch
from my last mail.
Regards,
Patrick
* gcc/config/i386/cygwin.h (STARTFILE_SPEC): Add vtv_start.o,
if -fvtable-verify=preinit/std is used.
* gcc/config/i386/mingw-w64.h (STARTFILE_SPEC): Likewise.
* gcc/config/i386/mingw32.h (STARTFILE_SPEC): Likewise.
* gcc/config/i386/cygwin.h (ENDFILE_SPEC): Add vtv_end.o,
if -fvtable-verify=preinit/std is used.
* gcc/config/i386/mingw32.h (ENDFILE_SPEC): Likewise.
* gcc/config/i386/cygwin.h (LIB_SPEC): Pass -lvtv and -lpsapi,
if -fvtable-verify=preinit/std is used.
* gcc/config/i386/mingw-w64.h (LIB_SPEC): Likewise.
* gcc/config/i386/mingw32.h (LIB_SPEC): Likewise.
* gcc/cp/vtable-class-hierarchy.c (vtv_generate_init_routine): Add
check for not TARGET_PECOFF at the VTV_PREINIT_PRIORITY checks.
* gcc/varasm.c (assemble_variable): Add code to properly set the comdat
section and name for the .vtable_map_vars section in case the
target is PE or COFF.
* libgcc/Makefile.in: Move rules to build vtv_*.o out of the check
for CUSTOM_CRTSTUFF.
* libgcc/config.host (i[34567]86-*-cygwin*, x86_64-*-cygwin*,
i[34567]86-*-mingw*)
(x86_64-*-mingw*): Only add vtv_*.o to extra_parts if enable_vtable_verify.
* libstdc++-v3/acinclude.m4: Define VTV_CYGMIN.
* libstdc++-v3/configure: Regenerate.
* libstdc++-v3/libsupc++/Makefile.am: Add vtv_sources only to
libsupc___la_SOURCES and libsupc__convenience_la_SOURCES if VTV_CYGMIN is
not set.
* libstdc++-v3/libsupc++/Makefile.in: Regenerated.
* libstdc++-v3/libsupc++/vtv_stubs.cc: Add none weak declaration of every
function for Cygwin and MinGW.
* libstdc++-v3/src/Makefile.am: Add libvtv.la to toolexeclib_LTLIBRARIES,
if VTV_CYGMIN is set. Define libvtv_la_SOURCES, libvtv_la_LDFLAGS,
libvtv_la_AM_CXXFLAGS and libvtv_la_LINK if VTV_CYGMIN is set.
* libstdc++-v3/src/Makefile.in: Regenerate.
* libvtv/Makefile.am : Add libvtv.la to toolexeclib_LTLIBRARIES, if VTV_CYGMIN
is set. Define libvtv_la_LIBADD, libvtv_la_LDFLAGS, libvtv_stubs_la_LDFLAGS
and libvtv_stubs_la_SOURCES if VTV_CYGMIN is set. Add obstac.c to
libvtv_la_SOURCES if VTV_CYGMIN is set.
* libvtv/Makefile.in : Regenerate.
* libvtv/aclocal.m4 : Regenerate.
* libvtv/configure : Regenerate.
* libvtv/configure.ac : Add ACX_LT_HOST_FLAGS. Define VTV_CYGMIN.
*
Re: Merge current set of OpenACC changes from gomp-4_0-branch
Hi Thomas,
thanks to you and all others involved for the OpenACC merge.
Attached is a patch which converts for Fortran '%s' into %qs, as
mentioned to before. (It wasn't possible when the original patch was
reviewed as the common diagnostic patches came later.)
Committed as Rev. 219694.
On the Fortran side: Compared with C/C++, support for acc cache seems
to be missing (PR63865, contains draft-patch link). (Other PRs: the
device_resident clause is not supported (PR63859) - I don't know whether
it is supported in C/C++ or not. And there are two ICEs (PR63865,
PR63858).) – Is some work on those planed on your side for GCC 5 or more
likely not?
Tobias
Thomas Schwinge wrote:
In r219682, I have committed to trunk our current set of OpenACC changes,
which we had prepared on gomp-4_0-branch. Thanks to everyone who has
been contributing!
Note that this is an experimental feature, incomplete, and subject to
change in future versions of GCC. We shall update -- and keep updated --
https://gcc.gnu.org/wiki/OpenACC, to track the current status. (Please
come back to that page in a few days, it has not yet been updated.)
Please note that there are still a handful of patches pending (posted
weeks ago, need to ping) that are needed for nvptx offloading, so that's
not yet functional.
Here's the commit log. The patch itself is too big to post inline, so
please find it attached, gzipped.
2015-01-15 Tobias Burnus bur...@net-b.de
* openmp.c (check_symbol_not_pointer, resolve_oacc_data_clauses,
resolve_oacc_deviceptr_clause, resolve_omp_clauses,
gfc_resolve_oacc_declare): Replace '%s' by %qs.
diff --git a/gcc/fortran/openmp.c b/gcc/fortran/openmp.c
index 005739b..422e977 100644
--- a/gcc/fortran/openmp.c
+++ b/gcc/fortran/openmp.c
@@ -1457,7 +1457,7 @@ gfc_match_oacc_routine (void)
if (!sym-attr.external !sym-attr.function !sym-attr.subroutine)
{
gfc_error (Syntax error in !$ACC ROUTINE ( NAME ) at %C, invalid
- function name '%s', sym-name);
+ function name %qs, sym-name);
gfc_current_locus = old_loc;
return MATCH_ERROR;
}
@@ -2649,29 +2649,29 @@ static void
check_symbol_not_pointer (gfc_symbol *sym, locus loc, const char *name)
{
if (sym-ts.type == BT_DERIVED sym-attr.pointer)
-gfc_error (POINTER object '%s' of derived type in %s clause at %L,
+gfc_error (POINTER object %qs of derived type in %s clause at %L,
sym-name, name, loc);
if (sym-ts.type == BT_DERIVED sym-attr.cray_pointer)
-gfc_error (Cray pointer object of derived type '%s' in %s clause at %L,
+gfc_error (Cray pointer object of derived type %qs in %s clause at %L,
sym-name, name, loc);
if (sym-ts.type == BT_DERIVED sym-attr.cray_pointee)
-gfc_error (Cray pointee object of derived type '%s' in %s clause at %L,
+gfc_error (Cray pointee object of derived type %qs in %s clause at %L,
sym-name, name, loc);
if ((sym-ts.type == BT_ASSUMED sym-attr.pointer)
|| (sym-ts.type == BT_CLASS CLASS_DATA (sym)
CLASS_DATA (sym)-attr.pointer))
-gfc_error (POINTER object '%s' of polymorphic type in %s clause at %L,
+gfc_error (POINTER object %qs of polymorphic type in %s clause at %L,
sym-name, name, loc);
if ((sym-ts.type == BT_ASSUMED sym-attr.cray_pointer)
|| (sym-ts.type == BT_CLASS CLASS_DATA (sym)
CLASS_DATA (sym)-attr.cray_pointer))
-gfc_error (Cray pointer object of polymorphic type '%s' in %s clause at %L,
+gfc_error (Cray pointer object of polymorphic type %qs in %s clause at %L,
sym-name, name, loc);
if ((sym-ts.type == BT_ASSUMED sym-attr.cray_pointee)
|| (sym-ts.type == BT_CLASS CLASS_DATA (sym)
CLASS_DATA (sym)-attr.cray_pointee))
-gfc_error (Cray pointee object of polymorphic type '%s' in %s clause at %L,
+gfc_error (Cray pointee object of polymorphic type %qs in %s clause at %L,
sym-name, name, loc);
}
@@ -2681,14 +2681,14 @@ static void
check_array_not_assumed (gfc_symbol *sym, locus loc, const char *name)
{
if (sym-as sym-as-type == AS_ASSUMED_SIZE)
-gfc_error (Assumed size array '%s' in %s clause at %L,
+gfc_error (Assumed size array %qs in %s clause at %L,
sym-name, name, loc);
if (sym-as sym-as-type == AS_ASSUMED_RANK)
-gfc_error (Assumed rank array '%s' in %s clause at %L,
+gfc_error (Assumed rank array %qs in %s clause at %L,
sym-name, name, loc);
if (sym-as sym-as-type == AS_DEFERRED sym-attr.pointer
!sym-attr.contiguous)
-gfc_error (Noncontiguous deferred shape array '%s' in %s clause at %L,
+gfc_error (Noncontiguous deferred shape array %qs in %s clause at %L,
sym-name, name, loc);
}
@@ -2696,12 +2696,12 @@ static void
resolve_oacc_data_clauses (gfc_symbol *sym, locus loc, const char *name)
{
if (sym-ts.type == BT_DERIVED sym-attr.allocatable)
-gfc_error (ALLOCATABLE object '%s' of derived type in %s clause at %L,
+gfc_error
Fix profiledbootstrap with release checking
Hi,
can_remove_node_now_p assumes that the node in question has no direct calls,
this
however is not checked in inline_call that leads to alias to be removed from
comdat group while it should not.
Bootstrapped/regtested x86_64-linux, comitted.
Honza
PR ipa/64612
* ipa-inline-transform.c (can_remove_node_now_p): Fix handling
of comdat locals.
(inline_call): Fix removal of aliases.
Index: ipa-inline-transform.c
===
--- ipa-inline-transform.c (revision 219674)
+++ ipa-inline-transform.c (working copy)
@@ -139,7 +139,7 @@ can_remove_node_now_p (struct cgraph_nod
/* When we see same comdat group, we need to be sure that all
items can be removed. */
- if (!node-same_comdat_group)
+ if (!node-same_comdat_group || !node-externally_visible)
return true;
for (next = dyn_castcgraph_node * (node-same_comdat_group);
next != node; next = dyn_castcgraph_node * (next-same_comdat_group))
@@ -310,7 +310,8 @@ inline_call (struct cgraph_edge *e, bool
while (alias alias != callee)
{
if (!alias-callers
- can_remove_node_now_p (alias, e))
+ can_remove_node_now_p (alias,
+ !e-next_caller !e-prev_caller ? e
: NULL))
{
next_alias = alias-get_alias_target ();
alias-remove ();
Re: Stage3 closing soon, call for patch pings
On 01/15/15 15:34, Nathaniel Smith wrote: On Thu, Jan 15, 2015 at 9:04 PM, Jeff Law l...@redhat.com wrote: Stage3 is closing rapidly. I've drained my queue of patches I was tracking for gcc-5.However, note that I don't track everything. If it's a patch for a backend, language other than C or seemingly has another maintainer that's engaged in review, then I haven't been tracking the patch. So this is my final call for patch pings. I've got some bandwidth and may be able to look at a few patches that have otherwise stalled. I've been pinging this for about a year now in case it's of interest: https://gcc.gnu.org/ml/gcc-patches/2014-10/msg01871.html It fixes a show-stopper for using GOMP in libraries -- currently you cannot use GOMP in any code where you don't control the whole program, b/c it breaks fork(). (GOMP is the only OMP implementation that has this problem.) This is particularly annoying for Python, since it manifests as person A writing a fancy numerical package that happens to use OMP internally (b/c they don't know any better), and then person B trying to use Python's standard 'multiprocessing' library and getting weird hangs and having no idea why. Jakub, myself and management have discussed this issue extensively and those patches specifically. I'm painfully aware of how this affects the ability to utilize numerical packages in Python. The fundamental problem is you're penalizing conformant code to make non-conformant code work. In the last iteration I think the problem was major memory leakage and nobody could see a way to avoid that. It's highly unfortunate that posix, openmp, etc haven't tackled any of the composability problems yet. I heard rumblings that those issues were going to be investigated by openmp back in 2013, but I don't think any significant progress has been made. I don't see any way any of those patches are going to get in. jeff
Re: [PATCH][ARM] FreeBSD ARM support, EABI, v3
On 14.01.15 10:43, Richard Earnshaw wrote: On 13/01/15 21:08, Andreas Tobler wrote: On 13.01.15 11:25, Ramana Radhakrishnan wrote: On Thu, Jan 8, 2015 at 8:51 PM, Andreas Tobler andreast-l...@fgznet.ch wrote: 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. My apologies for the slow response, some other work and then holidays intervened. Np, the only issue which made me hurry was the stage 4 entering this week. From my understanding of the ABI document the implementation is currently as mandated by the ABI. Also this isn't a part of the ABI that's available for the platform (here FreeBSD to manipulate and change as per it's wishes). ARM EHABI is special for software, making FreeBSD more special for ARM appears to be counter intuitive from my point of view. A number of exception unwinding libraries. for e.g. libobjc , libstdc++ all use this implementation of exception_class. Therefore this creates a divergence for the FreeBSD port which is different from everything else. I expect that a number of language run time support libraries that supported the ARM EHABI would be using such an implementation, therefore you need to fix every single implementation of this in every unwinder that supports the ARM EHABI which I expect to have been ported to in a number of libraries already. (I already see this in libobjc and libstdc++ in the GCC tree) Grr ;) I didn't want to hear this answer, but I expected it somehow. My proposal was the least effort for me. The other way round is going to be very hard. Maybe impossible. It is not only FreeBSD which is affected but also llvm and friends. They use for exception_class uint64_t. I have to take a picture how the effort is and if it would be possible to do such a change in FreeBSD and more important in llvm etc. I would rather fix the thread_unwind_stop implementation in libthr for ARM EHABI rather than make this change. It wouldn't be a 'fix' but more a wrapper I think. 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. Thanks for doing this. I'm really glad that FreeBSD is finally moving to EABI. I agree with Ramana on this one, I feel that FreeBSD trying to plough a slightly different furrow is just going to cause major problems for everyone. I don't believe a claim that LLVM can't be made to work with the standard EHABI data structures. It can do this on Linux, so I can't conceive of any reason why it cannot also do so on FreeBSD. Thanks for the feedback, both! I'm busy to get a picture and I come back as soon I have a plan. It is not a technical problem, it is, from my point of view, a distribution issue. Iow, we 'shipped' ABI/API X and we want/have to change to ABI/API Y. So it takes a while till I get the plan :) Andreas
Re: [COMMITTED] Merge libffi with upstream
On Thu, Jan 15, 2015 at 8:40 AM, Rainer Orth
r...@cebitec.uni-bielefeld.de wrote:
Richard Henderson r...@redhat.com writes:
Upstream libffi has added support for Go closures (using the static chain),
and support for complex numbers. Perhaps less relevant is new support for
arc, microblaze, moxie, nios, and or1k targets.
Without additional changes for Go, this merge has little effect. Within the
gcc tree libffi is primarily used by libjava.
Tested with no regressions on {i686,x86_64,ppc64,s390x,aarch64,alpha}-linux.
Due to upstream breakage, and difficulty debugging on Darwin,
{i686,x86_64}-darwin retains copies of the existing sources and thus remains
100% unchanged. Since libgo doesn't support darwin, this should cause no
immediate problems.
The patch introduced massive problems on Solaris, both SPARC and x86:
* on Solaris/SPARC, /bin/as requires
.type fn,#function
instead of @function. I've simply commented the affected lines in
src/sparc/v[89].S to make progress.
* /bin/as doesn't support .macro/.endm. I'm using preprocessor macros
instead to implement E in src/sparc/v[89].S and src/x86/{sysv,
unix64}.S.
* Solaris/x86 /bin/as doesn't support .org, so I've just disabled the
uses in src/x86/{sysv, unix64}.S, as on Darwin.
* Solaris/x86 /bin/as has different COMDAT syntax; I've disabled it for
the moment.
* Solaris/x86 needs to use EH_FRAME_FLAGS so manually and compiler
generated .eh_frame sections match, otherwise libffi.so fails to link:
ld: fatal: file src/.libs/prep_cif.o; section [16].eh_frame and file
src/x86/.libs/sysv.o; section [9].eh_frame have incompatibile attributes and
cannot be merged into a single output section
* Yet unfixed for Solaris/SPARC /bin/as:
as: v8.s, line 128: error: invalid digit in radix 10
as seems to only understand single-digit labels
as: v8.s, line 140: error: statement syntax
as: v8.s, line 157: error: unknown opcode .rept
as: v8.s, line 157: error: statement syntax
as: v8.s, line 163: error: unknown opcode .endr
as: v8.s, line 163: error: statement syntax
and knows nothing about .rept/.endr
Here are the hacks I've used to make some progress:
Some Sparc changes are lost in the merge. I opened:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64618
to tract lost changes.
--
H.J.
Re: [COMMITTED] Merge libffi with upstream
On 01/15/2015 02:47 PM, H.J. Lu wrote:
On Thu, Jan 15, 2015 at 8:40 AM, Rainer Orth
r...@cebitec.uni-bielefeld.de wrote:
Richard Henderson r...@redhat.com writes:
Upstream libffi has added support for Go closures (using the static chain),
and support for complex numbers. Perhaps less relevant is new support for
arc, microblaze, moxie, nios, and or1k targets.
Without additional changes for Go, this merge has little effect. Within the
gcc tree libffi is primarily used by libjava.
Tested with no regressions on {i686,x86_64,ppc64,s390x,aarch64,alpha}-linux.
Due to upstream breakage, and difficulty debugging on Darwin,
{i686,x86_64}-darwin retains copies of the existing sources and thus remains
100% unchanged. Since libgo doesn't support darwin, this should cause no
immediate problems.
The patch introduced massive problems on Solaris, both SPARC and x86:
* on Solaris/SPARC, /bin/as requires
.type fn,#function
instead of @function. I've simply commented the affected lines in
src/sparc/v[89].S to make progress.
* /bin/as doesn't support .macro/.endm. I'm using preprocessor macros
instead to implement E in src/sparc/v[89].S and src/x86/{sysv,
unix64}.S.
* Solaris/x86 /bin/as doesn't support .org, so I've just disabled the
uses in src/x86/{sysv, unix64}.S, as on Darwin.
* Solaris/x86 /bin/as has different COMDAT syntax; I've disabled it for
the moment.
* Solaris/x86 needs to use EH_FRAME_FLAGS so manually and compiler
generated .eh_frame sections match, otherwise libffi.so fails to link:
ld: fatal: file src/.libs/prep_cif.o; section [16].eh_frame and file
src/x86/.libs/sysv.o; section [9].eh_frame have incompatibile attributes and
cannot be merged into a single output section
* Yet unfixed for Solaris/SPARC /bin/as:
as: v8.s, line 128: error: invalid digit in radix 10
as seems to only understand single-digit labels
as: v8.s, line 140: error: statement syntax
as: v8.s, line 157: error: unknown opcode .rept
as: v8.s, line 157: error: statement syntax
as: v8.s, line 163: error: unknown opcode .endr
as: v8.s, line 163: error: statement syntax
and knows nothing about .rept/.endr
Here are the hacks I've used to make some progress:
Some Sparc changes are lost in the merge. I opened:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64618
to tract lost changes.
I'm pretty sure the sparc changes are *not* lost.
In particular, libffi 542e004710e3f1d7c137bba305a16538cd6257d6
merges back
commit be24203d712c030b4091a50f5d84b7372d5c990c
Author: ebotcazou ebotcazou@138bc75d-0d04-0410-961f-82ee72b054a4
Date: Thu Feb 13 16:18:13 2014 +
PR libffi/60073
listed in your new PR.
Your list of changes to libffi in the gcc tree is helpful, but
do not misconstrue all of them as missing.
r~
Re: Patch RFA: Support for building Go tools
On Wed, Jan 14, 2015 at 11:07 AM, Uros Bizjak ubiz...@gmail.com 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. Attached is the patch that enables gotools on alpha/linux. Tested on alpha-linux-gnu, cgo, go and gofmt executables run without problems. Thanks. Committed. Ian
Re: [committed] Update copyright years, part 2
Jakub Jelinek ja...@redhat.com writes: On Tue, Jan 13, 2015 at 05:06:35PM +, Richard Sandiford wrote: Jakub Jelinek ja...@redhat.com writes: Patch too large to attach uncompressed, this has been created with update-copyright.py --this-year. Note, I had to temporarily move away gcc/jit/docs/conf.py, the python script dies on that and leaves almost all files unchanged. Thanks for doing the update. Is the patch below OK to fix the JIT thing? After this change, update-copyright.py --this-year seems to update gcc/jit correctly (including the texinfo files). Richard contrib/ * update-copyright.py (Copyright.__init__): Add a regexp for copyright = u'. (Copyright.update_copyright): Don't add a space before the year in that case. Ok, thanks. For the record, here's the result of running the new script on gcc/jit. Committed as obvious. Thanks, Richard jit-copyright.patch.bz2 Description: BZip2 compressed data
Re: Stage3 closing soon, call for patch pings
On Thu, Jan 15, 2015 at 9:04 PM, Jeff Law l...@redhat.com wrote: Stage3 is closing rapidly. I've drained my queue of patches I was tracking for gcc-5.However, note that I don't track everything. If it's a patch for a backend, language other than C or seemingly has another maintainer that's engaged in review, then I haven't been tracking the patch. So this is my final call for patch pings. I've got some bandwidth and may be able to look at a few patches that have otherwise stalled. I've been pinging this for about a year now in case it's of interest: https://gcc.gnu.org/ml/gcc-patches/2014-10/msg01871.html It fixes a show-stopper for using GOMP in libraries -- currently you cannot use GOMP in any code where you don't control the whole program, b/c it breaks fork(). (GOMP is the only OMP implementation that has this problem.) This is particularly annoying for Python, since it manifests as person A writing a fancy numerical package that happens to use OMP internally (b/c they don't know any better), and then person B trying to use Python's standard 'multiprocessing' library and getting weird hangs and having no idea why. -n -- Nathaniel J. Smith Postdoctoral researcher - Informatics - University of Edinburgh http://vorpus.org
Re: [COMMITTED] Merge libffi with upstream
On Thu, Jan 15, 2015 at 3:00 PM, Richard Henderson r...@redhat.com wrote:
On 01/15/2015 02:47 PM, H.J. Lu wrote:
On Thu, Jan 15, 2015 at 8:40 AM, Rainer Orth
r...@cebitec.uni-bielefeld.de wrote:
Richard Henderson r...@redhat.com writes:
Upstream libffi has added support for Go closures (using the static chain),
and support for complex numbers. Perhaps less relevant is new support for
arc, microblaze, moxie, nios, and or1k targets.
Without additional changes for Go, this merge has little effect. Within
the
gcc tree libffi is primarily used by libjava.
Tested with no regressions on
{i686,x86_64,ppc64,s390x,aarch64,alpha}-linux.
Due to upstream breakage, and difficulty debugging on Darwin,
{i686,x86_64}-darwin retains copies of the existing sources and thus
remains
100% unchanged. Since libgo doesn't support darwin, this should cause no
immediate problems.
The patch introduced massive problems on Solaris, both SPARC and x86:
* on Solaris/SPARC, /bin/as requires
.type fn,#function
instead of @function. I've simply commented the affected lines in
src/sparc/v[89].S to make progress.
* /bin/as doesn't support .macro/.endm. I'm using preprocessor macros
instead to implement E in src/sparc/v[89].S and src/x86/{sysv,
unix64}.S.
* Solaris/x86 /bin/as doesn't support .org, so I've just disabled the
uses in src/x86/{sysv, unix64}.S, as on Darwin.
* Solaris/x86 /bin/as has different COMDAT syntax; I've disabled it for
the moment.
* Solaris/x86 needs to use EH_FRAME_FLAGS so manually and compiler
generated .eh_frame sections match, otherwise libffi.so fails to link:
ld: fatal: file src/.libs/prep_cif.o; section [16].eh_frame and file
src/x86/.libs/sysv.o; section [9].eh_frame have incompatibile attributes
and cannot be merged into a single output section
* Yet unfixed for Solaris/SPARC /bin/as:
as: v8.s, line 128: error: invalid digit in radix 10
as seems to only understand single-digit labels
as: v8.s, line 140: error: statement syntax
as: v8.s, line 157: error: unknown opcode .rept
as: v8.s, line 157: error: statement syntax
as: v8.s, line 163: error: unknown opcode .endr
as: v8.s, line 163: error: statement syntax
and knows nothing about .rept/.endr
Here are the hacks I've used to make some progress:
Some Sparc changes are lost in the merge. I opened:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64618
to tract lost changes.
I'm pretty sure the sparc changes are *not* lost.
In particular, libffi 542e004710e3f1d7c137bba305a16538cd6257d6
merges back
commit be24203d712c030b4091a50f5d84b7372d5c990c
Author: ebotcazou ebotcazou@138bc75d-0d04-0410-961f-82ee72b054a4
Date: Thu Feb 13 16:18:13 2014 +
PR libffi/60073
listed in your new PR.
Your list of changes to libffi in the gcc tree is helpful, but
do not misconstrue all of them as missing.
I could have miscounted.
--
H.J.
Re: Stage3 closing soon, call for patch pings
Hi Jeff,
On Thu, Jan 15, 2015 at 10:50 PM, Jeff Law l...@redhat.com wrote:
On 01/15/15 15:34, Nathaniel Smith wrote:
On Thu, Jan 15, 2015 at 9:04 PM, Jeff Law l...@redhat.com wrote:
Stage3 is closing rapidly. I've drained my queue of patches I was
tracking
for gcc-5.However, note that I don't track everything. If it's a
patch
for a backend, language other than C or seemingly has another maintainer
that's engaged in review, then I haven't been tracking the patch.
So this is my final call for patch pings. I've got some bandwidth and
may
be able to look at a few patches that have otherwise stalled.
I've been pinging this for about a year now in case it's of interest:
https://gcc.gnu.org/ml/gcc-patches/2014-10/msg01871.html
It fixes a show-stopper for using GOMP in libraries -- currently you
cannot use GOMP in any code where you don't control the whole program,
b/c it breaks fork(). (GOMP is the only OMP implementation that has
this problem.) This is particularly annoying for Python, since it
manifests as person A writing a fancy numerical package that happens
to use OMP internally (b/c they don't know any better), and then
person B trying to use Python's standard 'multiprocessing' library and
getting weird hangs and having no idea why.
Jakub, myself and management have discussed this issue extensively and those
patches specifically. I'm painfully aware of how this affects the ability
to utilize numerical packages in Python.
Thanks for the response! I had no idea anyone was paying attention :-).
The fundamental problem is you're penalizing conformant code to make
non-conformant code work. In the last iteration I think the problem was
major memory leakage and nobody could see a way to avoid that.
I'm afraid I'm a bit confused by this part.
In the patch I linked, the costs imposed on conformant programs are:
1) One extra 'int' per thread pool.
2) An increment/decrement pair during each call to fork().
3) A single 'if (__builtin_expect(..., 0)) { ... }' in gomp_team_start.
That's all. There is definitely no memory leakage for conformant code.
There *is* a memory leakage for non-conformant code: if you use OMP in
the parent, then fork, and then use OMP in the child, then without the
patch you get a deadlock; with the patch everything functions
correctly, but the child's COW copies of the parent's thread stacks
are leaked.
There are a few things that somewhat mitigate this in practice.
The main one is just: Leaking is a lot better than crashing. Esp. when
the only other way to fix the crash is to completely rewrite your code
(or some third-party code!) to avoid OMP, which is rather prohibitive.
Of course I'd rather not leak at all, but this isn't really a
situation where one can say well that was a stupid idea so don't do
that -- a memory leak here really is a better outcome than any
currently available alternative, enables use cases that just aren't
possible otherwise, and if OMP fixes its problems later then we can
update our fix to follow.
It's also worth thinking a bit about the magnitude of the problem: In
practice the most common case where an OMP-using program forks and
then the children use OMP is going to be something like Python
multiprocessing, where the child processes form a worker pool. In this
case, the total effective memory leakage is somewhere between 0 and 1
copies of the parents threads -- all the children will share a single
COW copy, and the parent may share some or all of that COW copy as
well, depending on its OMP usage. Conversely, it's very rare to have a
process that forks, then the child uses OMP then forks, then the
grandchild uses OMP then forks, ... etc. Yet this is what would be
required to get an unbounded memory leak here. If you only have a
single level of forking, then each child only has a single leak of
fixed size. There are many many situations where a few megabytes of
overhead are a small price to pay for having a convenient way to
process large datasets.
Does this affect your opinion about this patch, or am I better off
giving up now?
-n
--
Nathaniel J. Smith
Postdoctoral researcher - Informatics - University of Edinburgh
http://vorpus.org
Use static chain and libffi for Go closures
All of this has been posted before.
I believe the ABI change is something we should have for gcc 5.
Yes, the libffi merge has been causing problems (on targets that
don't even support libgo, annoyingly), but missing support for
the new libffi interfaces is easier to remedy in a dot release
than the change from __thread variable to static chain register
for implementing closures.
r~
gcc/go/
* go-gcc.cc (Gcc_backend::call_expression): Add chain_expr argument.
(Gcc_backend::static_chain_variable): New method.
diff --git a/gcc/go/go-gcc.cc b/gcc/go/go-gcc.cc
index d8b80b6..1ce1ff2 100644
--- a/gcc/go/go-gcc.cc
+++ b/gcc/go/go-gcc.cc
@@ -322,7 +322,7 @@ class Gcc_backend : public Backend
Bexpression*
call_expression(Bexpression* fn, const std::vectorBexpression* args,
- Location);
+ Bexpression* static_chain, Location);
// Statements.
@@ -403,6 +403,9 @@ class Gcc_backend : public Backend
Location);
Bvariable*
+ static_chain_variable(Bfunction*, const std::string, Btype*, Location);
+
+ Bvariable*
temporary_variable(Bfunction*, Bblock*, Btype*, Bexpression*, bool,
Location, Bstatement**);
@@ -1808,7 +1811,7 @@ Gcc_backend::array_index_expression(Bexpression* array,
Bexpression* index,
Bexpression*
Gcc_backend::call_expression(Bexpression* fn_expr,
const std::vectorBexpression* fn_args,
- Location location)
+ Bexpression* chain_expr, Location location)
{
tree fn = fn_expr-get_tree();
if (fn == error_mark_node || TREE_TYPE(fn) == error_mark_node)
@@ -1868,6 +1871,9 @@ Gcc_backend::call_expression(Bexpression* fn_expr,
excess_type != NULL_TREE ? excess_type : rettype,
fn, nargs, args);
+ if (chain_expr)
+CALL_EXPR_STATIC_CHAIN (ret) = chain_expr-get_tree();
+
if (excess_type != NULL_TREE)
{
// Calling convert here can undo our excess precision change.
@@ -2489,6 +2495,40 @@ Gcc_backend::parameter_variable(Bfunction* function,
const std::string name,
return new Bvariable(decl);
}
+// Make a static chain variable.
+
+Bvariable*
+Gcc_backend::static_chain_variable(Bfunction* function, const std::string
name,
+ Btype* btype, Location location)
+{
+ tree type_tree = btype-get_tree();
+ if (type_tree == error_mark_node)
+return this-error_variable();
+ tree decl = build_decl(location.gcc_location(), PARM_DECL,
+get_identifier_from_string(name), type_tree);
+ tree fndecl = function-get_tree();
+ DECL_CONTEXT(decl) = fndecl;
+ DECL_ARG_TYPE(decl) = type_tree;
+ TREE_USED(decl) = 1;
+ DECL_ARTIFICIAL(decl) = 1;
+ DECL_IGNORED_P(decl) = 1;
+ TREE_READONLY(decl) = 1;
+
+ struct function *f = DECL_STRUCT_FUNCTION(fndecl);
+ if (f == NULL)
+{
+ push_struct_function(fndecl);
+ pop_cfun();
+ f = DECL_STRUCT_FUNCTION(fndecl);
+}
+ gcc_assert(f-static_chain_decl == NULL);
+ f-static_chain_decl = decl;
+ DECL_STATIC_CHAIN(fndecl) = 1;
+
+ go_preserve_from_gc(decl);
+ return new Bvariable(decl);
+}
+
// Make a temporary variable.
Bvariable*
diff --git a/gcc/go/gofrontend/backend.h b/gcc/go/gofrontend/backend.h
index 46b2a6d..31ed8df 100644
--- a/gcc/go/gofrontend/backend.h
+++ b/gcc/go/gofrontend/backend.h
@@ -375,7 +375,7 @@ class Backend
// Create an expression for a call to FN with ARGS.
virtual Bexpression*
call_expression(Bexpression* fn, const std::vectorBexpression* args,
- Location) = 0;
+ Bexpression* static_chain, Location) = 0;
// Statements.
@@ -529,6 +529,11 @@ class Backend
Btype* type, bool is_address_taken,
Location location) = 0;
+ // Create a static chain parameter. This is the closure parameter.
+ virtual Bvariable*
+ static_chain_variable(Bfunction* function, const std::string name,
+ Btype* type, Location location) = 0;
+
// Create a temporary variable. A temporary variable has no name,
// just a type. We pass in FUNCTION and BLOCK in case they are
// needed. If INIT is not NULL, the variable should be initialized
diff --git a/gcc/go/gofrontend/expressions.cc b/gcc/go/gofrontend/expressions.cc
index 564c5b7..ee8af84 100644
--- a/gcc/go/gofrontend/expressions.cc
+++ b/gcc/go/gofrontend/expressions.cc
@@ -6321,6 +6321,7 @@ Bound_method_expression::create_thunk(Gogo* gogo, const
Method* method,
Variable* cvar = new Variable(closure_type, NULL, false, false, false, loc);
cvar-set_is_used();
+ cvar-set_is_closure();
Named_object* cp = Named_object::make_variable($closure, NULL, cvar);
new_no-func_value()-set_closure_var(cp);
@@ -9328,19 +9329,11 @@ Call_expression::do_get_backend(Translate_context*
context)
fn_args[0] = first_arg-get_backend(context);
[PATCH] Minor date fix in ChangeLog files.
Hi, all, I just happened to notice that there are some incorrect date in ChangeLog files. I guess this can be considered as obvious fix. Committed it as Rev.219704: https://gcc.gnu.org/r219704 Index: gcc/ChangeLog === --- gcc/ChangeLog (revision 219703) +++ gcc/ChangeLog (working copy) @@ -286,7 +286,7 @@ cfganal.h, cfgbuild.h, cfgcleanup.h, lcm.h, cfgloopmanip.h, builtins.def, and chkp-builtins.def. -2014-01-15 David Edelsohn dje@gmail.com +2015-01-15 David Edelsohn dje@gmail.com * config/rs6000/default64.h (TARGET_DEFAULT) [LITTLE_ENDIAN]: Use ISA 2.7 (POWER8). @@ -988,7 +988,7 @@ Do not save lr in case of tail call. * config/arm/thumb2.md (*thumb2_pop_single): New pattern. -2015-01-13 Martin Uecker uec...@eecs.berkeley.edu +2015-01-14 Martin Uecker uec...@eecs.berkeley.edu * tree-vrp.c (check_array_ref): Emit more warnings for warn_array_bounds = 2. @@ -1126,7 +1126,7 @@ (perform_symbolic_merge): This. Also fix computation of the range and end of the symbolic number corresponding to the result of a bitwise OR. -2014-01-13 Richard Biener rguent...@suse.de +2015-01-13 Richard Biener rguent...@suse.de PR tree-optimization/64568 * tree-ssa-forwprop.c (pass_forwprop::execute): Properly Index: gcc/testsuite/ChangeLog === --- gcc/testsuite/ChangeLog (revision 219703) +++ gcc/testsuite/ChangeLog (working copy) @@ -489,7 +489,7 @@ PR tree-optimization/64404 * gcc.dg/vect/pr64404.c: New testcase. -2014-01-13 Richard Biener rguent...@suse.de +2015-01-13 Richard Biener rguent...@suse.de PR tree-optimization/64568 * g++.dg/torture/pr64568.C: New testcase. Best regards, jasonwucj
Re: [PATCH, doc] NDS32: Describe -mcmodel= option instead of -mgp-direct in the documentation.
2015-01-14 17:56 GMT+08:00 Chung-Ju Wu jasonw...@gmail.com: Hi, all, In this patch of nds32 port: https://gcc.gnu.org/ml/gcc-patches/2015-01/msg00799.html Since we have a new option -mcmodel= as substitution for -mgp-direct, we need to update documentation about such change accordingly. The patch is attached and the plaintext ChangeLog is as follow. gcc/ChangeLog 2015-01-14 Chung-Ju Wu jasonw...@gmail.com * doc/invoke.texi (NDS32 Options): Add -mcmodel= option and remove -mgp-direct option. Although these changes are target-specific part, I think it would be better for others to have review comments, if any, on its format and layout. If there is no other comments about this patch, I will commit it into trunk after 24 hours. Committed as Rev. 219706: https://gcc.gnu.org/r219706 Best regards, jasonwucj
Re: [PATCH, doc] NDS32: Remove -mforce-fp-as-gp, -mforbid-fp-as-gp, and -mex9 options from documentation.
2015-01-14 17:58 GMT+08:00 Chung-Ju Wu jasonw...@gmail.com: Hi, all, In this patch of nds32 port: https://gcc.gnu.org/ml/gcc-patches/2015-01/msg00969.html Since we remove the implementation of -mforce-fp-as-gp, -mforbid-fp-as-gp, and -mex9 options, we need to update documentation as well. The patch is attached and the plaintext ChangeLog is as follow. gcc/ChangeLog 2015-01-14 Chung-Ju Wu jasonw...@gmail.com * doc/invoke.texi (NDS32 Options): Remove -mforce-fp-as-gp, -mforbid-fp-as-gp, and -mex9 options. Although these changes are target-specific part, I think it would be better for others to have review comments, if any, on its format and layout. If there is no other comments about this patch, I will commit it into trunk after 24 hours. Committed as Rev. 219707: https://gcc.gnu.org/r219707 Best regards, jasonwucj
Merge to gccgo branch
I merged trunk revision 219701 to the gccgo branch. Ian
Announcing Eric Botcazou as Visium port maintainer
This was really just a formality given Eric's existing maintainer positions ;-) I'm pleased to announce that Eric Botcazou has been appointed as the maintainer for the Visium port. Jeff
Re: Stage3 closing soon, call for patch pings
On 01/15/15 16:43, Nathaniel Smith wrote:
Jakub, myself and management have discussed this issue extensively and those
patches specifically. I'm painfully aware of how this affects the ability
to utilize numerical packages in Python.
Thanks for the response! I had no idea anyone was paying attention :-).
We've got customers that care about this issue, so naturally it gets a
goodly amount of attention up into the management chain.
The fundamental problem is you're penalizing conformant code to make
non-conformant code work. In the last iteration I think the problem was
major memory leakage and nobody could see a way to avoid that.
I'm afraid I'm a bit confused by this part.
I'm going from memory rather than the patch itself (Jakub understands
the technical side of this issue far better than I).
Jakub, can you chime in on Nathaniel's clarifications below? If the
leak is strictly in non-comformant code, that seems much less of a
problem than I recall from our internal discussions.
In the patch I linked, the costs imposed on conformant programs are:
1) One extra 'int' per thread pool.
2) An increment/decrement pair during each call to fork().
3) A single 'if (__builtin_expect(..., 0)) { ... }' in gomp_team_start.
That's all. There is definitely no memory leakage for conformant code.
There *is* a memory leakage for non-conformant code: if you use OMP in
the parent, then fork, and then use OMP in the child, then without the
patch you get a deadlock; with the patch everything functions
correctly, but the child's COW copies of the parent's thread stacks
are leaked.
There are a few things that somewhat mitigate this in practice.
The main one is just: Leaking is a lot better than crashing. Esp. when
the only other way to fix the crash is to completely rewrite your code
(or some third-party code!) to avoid OMP, which is rather prohibitive.
Of course I'd rather not leak at all, but this isn't really a
situation where one can say well that was a stupid idea so don't do
that -- a memory leak here really is a better outcome than any
currently available alternative, enables use cases that just aren't
possible otherwise, and if OMP fixes its problems later then we can
update our fix to follow.
It's also worth thinking a bit about the magnitude of the problem: In
practice the most common case where an OMP-using program forks and
then the children use OMP is going to be something like Python
multiprocessing, where the child processes form a worker pool. In this
case, the total effective memory leakage is somewhere between 0 and 1
copies of the parents threads -- all the children will share a single
COW copy, and the parent may share some or all of that COW copy as
well, depending on its OMP usage. Conversely, it's very rare to have a
process that forks, then the child uses OMP then forks, then the
grandchild uses OMP then forks, ... etc. Yet this is what would be
required to get an unbounded memory leak here. If you only have a
single level of forking, then each child only has a single leak of
fixed size. There are many many situations where a few megabytes of
overhead are a small price to pay for having a convenient way to
process large datasets.
Does this affect your opinion about this patch, or am I better off
giving up now?
-n
Re: [RFC] Tighten memory type assumption in RTL combiner pass.
Hi jeff and Richard
On 15 January 2015 at 03:10, Jeff Law l...@redhat.com wrote:
On 01/14/15 04:27, Venkataramanan Kumar wrote:
Hi all,
When trying to debug GCC combiner pass with the test case in PR63949
ref https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63949 I came across this
code.
This code in make_compound_operation assumes that all PLUS and MINUS
RTX are MEM type for scalar int modes and tries to optimize based on
that assumption.
/* Select the code to be used in recursive calls. Once we are inside an
address, we stay there. If we have a comparison, set to COMPARE,
but once inside, go back to our default of SET. */
next_code = (code == MEM ? MEM
: ((code == PLUS || code == MINUS)
SCALAR_INT_MODE_P (mode)) ? MEM
: ((code == COMPARE || COMPARISON_P (x))
XEXP (x, 1) == const0_rtx) ? COMPARE
: in_code == COMPARE ? SET : in_code);
next_code is passed as in_code via recursive calls to
make_compound_operation. Based on that we are converting shift
pattern to MULT pattern.
case ASHIFT:
/* Convert shifts by constants into multiplications if inside
an address. */
if (in_code == MEM CONST_INT_P (XEXP (x, 1))
INTVAL (XEXP (x, 1)) HOST_BITS_PER_WIDE_INT
INTVAL (XEXP (x, 1)) = 0
SCALAR_INT_MODE_P (mode))
{
Now I tried to tighten it further by adding check to see in_code is
also MEM type.
Not sure if this right thing to do. But this assumption about MEM
seems to be very relaxed before.
diff --git a/gcc/combine.c b/gcc/combine.c
index 101cf35..1353f54 100644
--- a/gcc/combine.c
+++ b/gcc/combine.c
@@ -7696,7 +7696,8 @@ make_compound_operation (rtx x, enum rtx_code
in_code)
next_code = (code == MEM ? MEM
: ((code == PLUS || code == MINUS)
- SCALAR_INT_MODE_P (mode)) ? MEM
+ SCALAR_INT_MODE_P (mode)
+ (in_code == MEM)) ? MEM
: ((code == COMPARE || COMPARISON_P (x))
XEXP (x, 1) == const0_rtx) ? COMPARE
: in_code == COMPARE ? SET : in_code);
This passed bootstrap on x86_64 and GCC tests are not regressing.
On Aarch64 passed bootstrap tests, test case in PR passed, but few
tests failed (failed to generate adds and subs), because there are
patterns (extended adds and subs) based on multiplication only in
Aarch64 backend.
if this change is correct then I may need to add patterns in Aarch64
based on shifts. Not sure about targets also.
Requesting further comments/help about this.
I am looking to get it fixed in stage 1.
So the first question I would ask here is what precisely are you trying to
accomplish? Is there some code where making this change is important or is
it strictly a theoretical problem? If the latter, can we make it concrete
with a well crafted testcase?
jeff
The below test case which I am working on is from the PR63949
int subsi_sxth (int a, short i)
{
/* { dg-final { scan-assembler sub\tw\[0-9\]+,.*sxth #?1 } } */
return a - ((int)i 1);
}
The expression a - ((int)i 1) is not a memory expression.
But combiner assumes that MINUS RTX as memory, and process all RTX
sub expressions with the memory assumption.
While processing ((int)i 1) in the combiner, it first hits this code.
/* See if we have operations between an ASHIFTRT and an ASHIFT.
If so, try to merge the shifts into a SIGN_EXTEND. We could
also do this for some cases of SIGN_EXTRACT, but it doesn't
seem worth the effort; the case checked for occurs on Alpha. */
if (!OBJECT_P (lhs)
! (GET_CODE (lhs) == SUBREG
(OBJECT_P (SUBREG_REG (lhs
CONST_INT_P (rhs)
INTVAL (rhs) HOST_BITS_PER_WIDE_INT
INTVAL (rhs) mode_width
(new_rtx = extract_left_shift (lhs, INTVAL (rhs))) != 0)
new_rtx = make_extraction
(mode,make_compound_operation(
new_rtx,next_code),
0, NULL_RTX, mode_width - INTVAL (rhs),
code == LSHIFTRT, 0, in_code == COMPARE);
The input RTX is
(ashiftrt:SI (ashift:SI (reg:SI 1 x1 [ i ])
(const_int 16 [0x10]))
(const_int 15 [0xf]))
And the function extract_left_shift generates
ashift:SI (reg:SI 1 x1 [ i ])
(const_int 16 [0x10])
Before we call make_extraction, there is another call to
make_compound_operation again which converts ASHIFT to mult RTX.
In make_compound_operation
switch (code)
{
case ASHIFT:
/* Convert shifts by constants into multiplications if inside
an address. */
if (in_code == MEM CONST_INT_P (XEXP (x, 1))
INTVAL (XEXP (x, 1)) HOST_BITS_PER_WIDE_INT
INTVAL (XEXP (x, 1)) = 0
SCALAR_INT_MODE_P (mode))
{
After extraction what we get a sign_extract and an
RE: [PING] [PATCH] Fix parameters of __tsan_vptr_update
Hi, I think I should ping for this patch now: https://gcc.gnu.org/ml/gcc-patches/2015-01/msg00599.html note that by mistake the change log referenced sanitizer.c instead of sanitizer.def, consider that fixed on my local copy. Thanks Bernd. Date: Sun, 11 Jan 2015 14:15:54 +0100 Hi, On Sun, 4 Jan 2015 14:54:56, Bernd Edlinger wrote: Hi Jakub, I think I have found a reasonable test case, see the attached patch file. The use case is: a class that destroys an owned thread in the destructor. The destructor sets the vptr again to thread::vptr but this should _not_ trigger a diagnostic message, when the vptr does not really change. Jakub, this is another test case where the TREE_READONLY prevents the tsan instrumentation. So I had first to install your patch: https://gcc.gnu.org/ml/gcc-patches/2014-12/msg01432.html ... to see the test case fail without my patch. that has been installed in the meantime. The patch installs cleanly on 4.9 and 4.8, however the 4.8 branch has no tsan tests, so I would leave the test case away for 4.8. I found, 4.8 does not have BT_FN_VOID_PTR_PTR, and no tsan tests at all, so it is probably not worth the effort. Boot-strapped and regression-tested on x86_64-linux-gnu OK for trunk and 4.9 + 4.8 branches? Thanks Bernd. I found some test cases in the clang tree, about the __tsan_vptr_update. So I thought I should use these instead of inventing new ones. Attached you'll find an updated patch with one positive and one negative test for vptr races. Tested with x86_64-linux-gnu. OK for trunk and 4.9 after a while? Thanks Bernd.
[committed] MAINTAINERS: add myself to write-after-approval list
2015-01-15 Martin Uecker uec...@eecs.berkeley.edu * MAINTAINERS: (Write After Approval): Add myself. Index: MAINTAINERS === --- MAINTAINERS (Revision 219713) +++ MAINTAINERS (Revision 219714) @@ -576,6 +576,7 @@ Philipp Tomsich philipp.toms...@theobroma-systems.com Konrad Trifunovic konrad.trifuno...@inria.fr Markus Trippelsdorfmar...@trippelsdorf.de +Martin Uecker uec...@eecs.berkeley.edu David Ung dav...@mips.com Neil Vachharajani nvach...@gmail.com Kris Van Hees kris.van.h...@oracle.com
C++ PATCH for c++/63283 (constexpr call with reference parameter in template)
Normally when we see a call to a function with a reference parameter,
we've converted the argument to have reference type as well, so we can
always treat arguments as rvalues in potential_constant_expression. But
with templates we defer the conversions until instantiation time, so we
shouldn't require the argument to be an rvalue constant yet.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit dbb548c7d0adf94504c732f92120c78186834e1b
Author: Jason Merrill ja...@redhat.com
Date: Wed Jan 14 19:34:04 2015 -0500
PR c++/63283
* constexpr.c (potential_constant_expression_1): Handle reference
args in templates.
diff --git a/gcc/cp/constexpr.c b/gcc/cp/constexpr.c
index 1432506..e27a892 100644
--- a/gcc/cp/constexpr.c
+++ b/gcc/cp/constexpr.c
@@ -3881,7 +3881,11 @@ potential_constant_expression_1 (tree t, bool want_rval, bool strict,
for (; i nargs; ++i)
{
tree x = get_nth_callarg (t, i);
- if (!RECUR (x, rval))
+ /* In a template, reference arguments haven't been converted to
+ REFERENCE_TYPE and we might not even know if the parameter
+ is a reference, so accept lvalue constants too. */
+ bool rv = processing_template_decl ? any : rval;
+ if (!RECUR (x, rv))
return false;
}
return true;
diff --git a/gcc/testsuite/g++.dg/cpp0x/constexpr-template8.C b/gcc/testsuite/g++.dg/cpp0x/constexpr-template8.C
new file mode 100644
index 000..7b2b9c7
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/constexpr-template8.C
@@ -0,0 +1,10 @@
+// PR c++/63283
+// { dg-do compile { target c++11 } }
+
+constexpr int array_length(int (array)[3]) { return 3; }
+int a[] = { 1, 2, 3 };
+template typename T int f() {
+ struct { int e[array_length(a)]; } t;
+ return sizeof(t);
+}
+int main() { fvoid(); }
diff --git a/gcc/testsuite/g++.dg/cpp0x/static_assert10.C b/gcc/testsuite/g++.dg/cpp0x/static_assert10.C
index 216f259..e7f728e 100644
--- a/gcc/testsuite/g++.dg/cpp0x/static_assert10.C
+++ b/gcc/testsuite/g++.dg/cpp0x/static_assert10.C
@@ -4,5 +4,5 @@
templatetypename T bool foo(T)
{
int i;
- static_assert(foo(i), Error); // { dg-error non-constant condition|not usable }
+ static_assert(foo(i), Error); // { dg-error non-constant condition|not usable|non-constexpr }
}
Re: [PATCH/expand] PR64011 Adjust bitsize when partial overflow happen for big-endian
On Thu, 15 Jan 2015, Jiong Wang wrote:
+ if (bitsize + bitnum unit bitnum unit)
+{
+ warning (OPT_Wextra, write of HOST_WIDE_INT_PRINT_UNSIGNEDbit data
+outside the bound of destination object, data truncated into
+HOST_WIDE_INT_PRINT_UNSIGNEDbit, bitsize, unit - bitnum);
HOST_WIDE_INT_PRINT_UNSIGNED is a format for printf, not for the GCC
diagnostic functions; in addition, the strings passed to the GCC
diagnostic functions must be string constants, not concatenated with
macros (only with other string constants directly appearing in the
source), so that they can be extracted for translation. You need to use
%wu instead to print an unsigned HOST_WIDE_INT in a GCC diagnostic
function such as warning.
(Also, there should be a hyphen between the number and bit, %wu-bit.)
--
Joseph S. Myers
jos...@codesourcery.com
Work around --enable-checking profiledbootstrap issue
Hi, this patch fixes ICE during profiledbootstrap. The underlying problem is somewhat hard to fix (and not too important), so I will pospone it for next stage1. Honza Index: ChangeLog === --- ChangeLog (revision 219700) +++ ChangeLog (working copy) @@ -1,3 +1,8 @@ +2015-01-15 Jan Hubicka hubi...@ucw.cz + + * ipa-inline.c (inline_small_functions): Work around hints + cache issue. + 2015-01-15 Sandra Loosemore san...@codesourcery.com PR target/59710 Index: ipa-inline.c === --- ipa-inline.c(revision 219700) +++ ipa-inline.c(working copy) @@ -1655,7 +1655,18 @@ inline_small_functions (void) reset_edge_growth_cache (edge); gcc_assert (old_size_est == estimate_edge_size (edge)); gcc_assert (old_time_est == estimate_edge_time (edge)); - gcc_assert (old_hints_est == estimate_edge_hints (edge)); + /* FIXME: + + gcc_assert (old_hints_est == estimate_edge_hints (edge)); + +fails with profile feedback because some hints depends on +maybe_hot_edge_p predicate and because callee gets inlined to other +calls, the edge may become cold. +This ought to be fixed by computing relative probabilities +for given invocation but that will be better done once whole +code is converted to sreals. Disable for now and revert to wrong +value so enable/disable checking paths agree. */ + edge_growth_cache[edge-uid].hints = old_hints_est + 1; /* When updating the edge costs, we only decrease badness in the keys. Increases of badness are handled lazilly; when we see key with out
[nios2, committed] additional -mgpopt choices
This patch is for PR 59710. As noted in that issue, the nios2 backend
only uses GP-relative addressing on objects defined locally to the
translation unit, where it knows definitely that the object is assigned
to the small data section under the current -G setting. Some other
backends also use GP-relative addressing on externally-defined objects
with the assumption that the entire program will be compiled at the same
-G setting. While that can be a Good Thing, it seemed to me that
changing the behavior of -mgpopt incompatibly might cause problems
(especially since it's enabled by default in most cases), so I added an
additional state (-mgpopt=global) to control the new behavior.
While I was at it, I added two more states to -mgpopt= that tell the
compiler to use GP-relative addressing for all data, or for the whole
program (including text). These fell out of a discussion we've been
having internally about producing tighter code for very small programs,
like a bootloader that's guaranteed to have to fit into a 64K internal
memory segment. This was trivial to implement once the -mgpopt option
syntax support for multiple choices was there.
I've committed this after regression-testing on nios2-elf. Sorry to get
this in so late in stage 3; I was hoping to make stage 1 but mainline
trunk builds were broken for a long time by PR64377.
-Sandra
2015-01-15 Sandra Loosemore san...@codesourcery.com
PR target/59710
gcc/
* doc/invoke.texi (Option Summary): Document new Nios II
-mgpopt= syntax.
(Nios II Options): Likewise.
* config/nios2/nios2.opt: Add -mgpopt= option support.
Modify existing -mgpopt and -mno-gpopt options to be aliases.
* config/nios2/nios2-opts.h (enum nios2_gpopt_type): New.
* config/nios2/nios2.c (nios2_option_override): Adjust
-mgpopt defaulting.
(nios2_in_small_data_p): Return true for explicit small data
sections even with -G0.
(nios2_symbol_ref_in_small_data_p): Adjust to handle new -mgpopt=
option choices.
gcc/testsuite/
* gcc.target/nios2/gpopt-all.c: New test case.
* gcc.target/nios2/gpopt-local.c: New test case.
* gcc.target/nios2/gpopt-global.c: New test case.
* gcc.target/nios2/gpopt-data.c: New test case.
* gcc.target/nios2/gpopt-none.c: New test case.
Index: gcc/doc/invoke.texi
===
--- gcc/doc/invoke.texi (revision 219696)
+++ gcc/doc/invoke.texi (working copy)
@@ -869,7 +869,8 @@ Objective-C and Objective-C++ Dialects}.
-mex9 -mctor-dtor -mrelax}
@emph{Nios II Options}
-@gccoptlist{-G @var{num} -mgpopt -mno-gpopt -mel -meb @gol
+@gccoptlist{-G @var{num} -mgpopt=@var{option} -mgpopt -mno-gpopt @gol
+-mel -meb @gol
-mno-bypass-cache -mbypass-cache @gol
-mno-cache-volatile -mcache-volatile @gol
-mno-fast-sw-div -mfast-sw-div @gol
@@ -19214,15 +19215,54 @@ Put global and static objects less than
into the small data or BSS sections instead of the normal data or BSS
sections. The default value of @var{num} is 8.
+@item -mgpopt=@var{option}
@item -mgpopt
@itemx -mno-gpopt
@opindex mgpopt
@opindex mno-gpopt
-Generate (do not generate) GP-relative accesses for objects in the
-small data or BSS sections. The default is @option{-mgpopt} except
-when @option{-fpic} or @option{-fPIC} is specified to generate
-position-independent code. Note that the Nios II ABI does not permit
-GP-relative accesses from shared libraries.
+Generate (do not generate) GP-relative accesses. The following
+@var{option} names are recognized:
+
+@table @samp
+
+@item none
+Do not generate GP-relative accesses.
+
+@item local
+Generate GP-relative accesses for small data objects that are not
+external or weak. Also use GP-relative addressing for objects that
+have been explicitly placed in a small data section via a @code{section}
+attribute.
+
+@item global
+As for @samp{local}, but also generate GP-relative accesses for
+small data objects that are external or weak. If you use this option,
+you must ensure that all parts of your program (including libraries) are
+compiled with the same @option{-G} setting.
+
+@item data
+Generate GP-relative accesses for all data objects in the program. If you
+use this option, the entire data and BSS segments
+of your program must fit in 64K of memory and you must use an appropriate
+linker script to allocate them within the addressible range of the
+global pointer.
+
+@item all
+Generate GP-relative addresses for function pointers as well as data
+pointers. If you use this option, the entire text, data, and BSS segments
+of your program must fit in 64K of memory and you must use an appropriate
+linker script to allocate them within the addressible range of the
+global pointer.
+
+@end table
+
+@option{-mgpopt} is equivalent to @option{-mgpopt=local}, and
+@option{-mno-gpopt} is equivalent to
Re: Stage3 closing soon, call for patch pings
On Fri, Jan 16, 2015 at 5:04 AM, Jeff Law l...@redhat.com wrote: Stage3 is closing rapidly. I've drained my queue of patches I was tracking for gcc-5.However, note that I don't track everything. If it's a patch for a backend, language other than C or seemingly has another maintainer that's engaged in review, then I haven't been tracking the patch. So this is my final call for patch pings. I've got some bandwidth and may be able to look at a few patches that have otherwise stalled. Here is an ARM backend patch, CCing ARM maintainers. https://gcc.gnu.org/ml/gcc-patches/2014-11/msg01383.html Thanks, bin Jeff
libgo patch committed: Change handling of empty structs/arrays for libffi
The recent libffi upgrade caused one of the 32-bit x86 libgo tests to
break. The problem case is a function that returns an empty struct--a
struct with no fields. The libffi library does not recognize the
existence of empty structs, presumably since they can't happen in C.
To work around this, the Go interface to the libffi library changes an
empty struct to void. This normally works fine, but with the new
libffi upgrade it fails for a function that returns an empty struct.
On x86 a function that returns a struct is expected to pop the hidden
pointer when it returns. So when we convert an empty struct to void,
libffi is calling a function that pops the hidden pointer but does not
expect that to happen.
In the older version of libffi, this didn't matter, because the libffi
code for 32-bit x86 used a frame pointer, so the fact that the stack
pointer was wonky when the function returned was ignored as the stack
pointer was immediately replaced by the saved frame pointer. In the
newer version of libffi, the 32-bit x86 code is more efficient and
does not use a frame pointer, and therefore it matters whether libffi
expects the function to pop the hidden pointer or not.
This patch changes libgo to convert an empty to a struct with a single
field of type void. This seems to be enough to get the test cases
working again.
Of course the real fix would be to change libffi to handle empty
types, but as libffi uses size == 0 as a marker for an uninitialized
type, that would be a non-trivial change.
Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu.
Committed to mainline.
Ian
diff -r c8b6adce5fa0 libgo/runtime/go-ffi.c
--- a/libgo/runtime/go-ffi.cThu Jan 15 14:06:38 2015 -0800
+++ b/libgo/runtime/go-ffi.cThu Jan 15 18:43:24 2015 -0800
@@ -52,6 +52,14 @@
ret = (ffi_type *) __go_alloc (sizeof (ffi_type));
ret-type = FFI_TYPE_STRUCT;
len = descriptor-__len;
+ if (len == 0)
+{
+ /* The libffi library won't accept an empty struct. */
+ ret-elements = (ffi_type **) __go_alloc (2 * sizeof (ffi_type *));
+ ret-elements[0] = ffi_type_void;
+ ret-elements[1] = NULL;
+ return ret;
+}
ret-elements = (ffi_type **) __go_alloc ((len + 1) * sizeof (ffi_type *));
element = go_type_to_ffi (descriptor-__element_type);
for (i = 0; i len; ++i)
@@ -92,11 +100,16 @@
int i;
field_count = descriptor-__fields.__count;
- if (field_count == 0) {
-return ffi_type_void;
- }
ret = (ffi_type *) __go_alloc (sizeof (ffi_type));
ret-type = FFI_TYPE_STRUCT;
+ if (field_count == 0)
+{
+ /* The libffi library won't accept an empty struct. */
+ ret-elements = (ffi_type **) __go_alloc (2 * sizeof (ffi_type *));
+ ret-elements[0] = ffi_type_void;
+ ret-elements[1] = NULL;
+ return ret;
+}
fields = (const struct __go_struct_field *) descriptor-__fields.__values;
ret-elements = (ffi_type **) __go_alloc ((field_count + 1)
* sizeof (ffi_type *));
Bump up early-inlining-insns
Hi, after some testing on firefox, SPEC and C++ benchmark I decided to bump up early-inlining-insns somewhat because I find inliner decisions to be considerably more robust this way allowing me to reduce inline-unit-growth. There are several reasons for increasing early-inliner's activity. First it helps to shift work from LTO to compilation stage. Also C++ abstraction penalty is on rise with current coding standards. Finally since last tunning early inliner trottles itself down more for non-leaf functions. Bootstrapped/regtested x86_64-linux, comitted. I will follow with update of inline-unit-growth once testers pick this change up. Honza Index: doc/invoke.texi === --- doc/invoke.texi (revision 219700) +++ doc/invoke.texi (working copy) @@ -10078,7 +10078,7 @@ The default value is 10. @item early-inlining-insns Specify growth that the early inliner can make. In effect it increases the amount of inlining for code having a large abstraction penalty. -The default value is 10. +The default value is 14. @item max-early-inliner-iterations Limit of iterations of the early inliner. This basically bounds Index: params.def === --- params.def (revision 219700) +++ params.def (working copy) @@ -198,7 +198,7 @@ DEFPARAM(PARAM_IPCP_UNIT_GROWTH, DEFPARAM(PARAM_EARLY_INLINING_INSNS, early-inlining-insns, Maximal estimated growth of function body caused by early inlining of single call, -11, 0, 0) +14, 0, 0) DEFPARAM(PARAM_LARGE_STACK_FRAME, large-stack-frame, The size of stack frame to be considered large,
Re: [debug-early] C++ clones and limbo DIEs
On 01/15/2015 09:58 PM, Aldy Hernandez wrote: The attached patch generates early DIEs for the C++ clones in the C++ parser. This strikes me as an unnecessary abstraction violation. + /* Emit debug information for clones. */ + symtab_node *node; + FOR_EACH_DEFINED_SYMBOL (node) +if (DECL_ABSTRACT_ORIGIN (node-decl)) + debug_hooks-early_global_decl (DECL_ABSTRACT_ORIGIN (node-decl)); And I note that you aren't even doing anything with the clone here, which suggests even more strongly that this is not what we want to do. Now back to limbdo_die_list... My approach is to flush the limbo list, generically, after the front-ends have finished, by adding a new early_finish debug hook. This gets rid of any permanence into LTO time. Then I flush it out again, if the middle end (or LTO, etc) has added any limbo DIEs. Can you remove the first flush and just do it in the second place? Jason
[debug-early] C++ clones and limbo DIEs
Hi Jason. Hi Richard.
While adjusting the limbdo_die_list for early debug I noticed we weren't
early generating C++ constructors/destructors. This got me on a detour
of sorts.
I noticed dwarf2out's gen_member_die() disallows generation of clones
earlier, by design:
/* Don't include clones in the member list. */
if (DECL_ABSTRACT_ORIGIN (member))
continue;
I played around trying to disable this feature, but my approach ran
into various walls, and I decided instead to attack it from the
front-end side. The attached patch generates early DIEs for the C++
clones in the C++ parser. I'd be (un)happy to revisit the dwarf2out
approach if it's deemed more appropriate.
Now back to limbdo_die_list... My approach is to flush the limbo list,
generically, after the front-ends have finished, by adding a new
early_finish debug hook. This gets rid of any permanence into LTO
time. Then I flush it out again, if the middle end (or LTO, etc) has
added any limbo DIEs. I wish we didn't need to flush the limbo list
past the compilation proper, but some things like Cilk+ generate
function trees way late in the game, so we end up generating limbo DIEs
past where I'd like to. Please see the comment in the source code.
All in all, this patch should get rid of any middle-end dependence on
the early debug generated limbo DIEs.
Are you happy with this? I'd like to get your input before committing
to this approach.
Thanks.
Aldy
commit cd20df2a48ce4f0d4e64626d61f8f61a810cf742
Author: Aldy Hernandez al...@redhat.com
Date: Wed Jan 14 13:33:40 2015 -0800
* cp/decl2.c (c_parse_final_cleanups): Emit early debug
information for clones.
* dbxout.c (dbx_debug_hooks): Add early_finish field.
(xcoff_debug_hooks): Same.
* sdbout.c (sdb_debug_hooks): Same.
* vmsdbgout.c (vmsdbg_debug_hooks): Same.
* debug.c (do_nothing_debug_hooks): Same.
* debug.h (struct gcc_debug_hooks): Same.
* dwarf2out.c (dwarf2_debug_hooks): Same.
(dwarf2out_finish): Move limbo list handling to...
(dwarf2out_early_finish): ...here.
* toplev.c (compile_file): Call debug_hooks-early_finish.
diff --git a/gcc/cp/decl2.c b/gcc/cp/decl2.c
index 691688b..b9a407a 100644
--- a/gcc/cp/decl2.c
+++ b/gcc/cp/decl2.c
@@ -4737,6 +4737,13 @@ c_parse_final_cleanups (void)
generate initial debug information. */
timevar_stop (TV_PHASE_PARSING);
timevar_start (TV_PHASE_DBGINFO);
+
+ /* Emit debug information for clones. */
+ symtab_node *node;
+ FOR_EACH_DEFINED_SYMBOL (node)
+if (DECL_ABSTRACT_ORIGIN (node-decl))
+ debug_hooks-early_global_decl (DECL_ABSTRACT_ORIGIN (node-decl));
+
walk_namespaces (emit_debug_for_namespace, 0);
if (vec_safe_length (pending_statics) != 0)
{
diff --git a/gcc/dbxout.c b/gcc/dbxout.c
index 430a2eb..202ef8a 100644
--- a/gcc/dbxout.c
+++ b/gcc/dbxout.c
@@ -359,6 +359,7 @@ const struct gcc_debug_hooks dbx_debug_hooks =
dbxout_init,
dbxout_finish,
debug_nothing_void,
+ debug_nothing_void,
debug_nothing_int_charstar,
debug_nothing_int_charstar,
dbxout_start_source_file,
@@ -400,6 +401,7 @@ const struct gcc_debug_hooks xcoff_debug_hooks =
dbxout_init,
dbxout_finish,
debug_nothing_void,
+ debug_nothing_void,
debug_nothing_int_charstar,
debug_nothing_int_charstar,
dbxout_start_source_file,
diff --git a/gcc/debug.c b/gcc/debug.c
index 449d3a1..d0e00c0 100644
--- a/gcc/debug.c
+++ b/gcc/debug.c
@@ -27,6 +27,7 @@ const struct gcc_debug_hooks do_nothing_debug_hooks =
{
debug_nothing_charstar,
debug_nothing_charstar,
+ debug_nothing_void, /* early_finish */
debug_nothing_void,
debug_nothing_int_charstar,
debug_nothing_int_charstar,
diff --git a/gcc/debug.h b/gcc/debug.h
index f9485bc..a8d3f23 100644
--- a/gcc/debug.h
+++ b/gcc/debug.h
@@ -30,6 +30,9 @@ struct gcc_debug_hooks
/* Output debug symbols. */
void (* finish) (const char *main_filename);
+ /* Run cleanups necessary after early debug generation. */
+ void (* early_finish) (void);
+
/* Called from cgraph_optimize before starting to assemble
functions/variables/toplevel asms. */
void (* assembly_start) (void);
diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
index e3ccda2..80d43af 100644
--- a/gcc/dwarf2out.c
+++ b/gcc/dwarf2out.c
@@ -2424,6 +2424,7 @@ build_cfa_aligned_loc (dw_cfa_location *cfa,
static void dwarf2out_init (const char *);
static void dwarf2out_finish (const char *);
+static void dwarf2out_early_finish (void);
static void dwarf2out_assembly_start (void);
static void dwarf2out_define (unsigned int, const char *);
static void dwarf2out_undef (unsigned int, const char *);
@@ -2451,6 +2452,7 @@ const struct gcc_debug_hooks dwarf2_debug_hooks =
{
dwarf2out_init,
dwarf2out_finish,
+ dwarf2out_early_finish,
dwarf2out_assembly_start,
dwarf2out_define,
dwarf2out_undef,
@@ -24739,10 +24741,27 @@
Re: [PATCH] Fix PR64365
On Wed, 14 Jan 2015, Richard Biener wrote:
This fixes an issue in dependence analysis and how we make pointer
dereferences visible to it. Basically dependence analysis works
on indices (assuming we deal with arrays) and thus never needs
sth like an access size (because indices are non-sparse and
different index means a different memory area). Dereferences
breaks this because we present dependence analysis with a
sparse index space. Thus to rule out partially overlapping
accesses we have to make sure to separate bases (only equal
bases get treated this way).
The following ensures this by making the indices multiples of
the access size (and shifting the byte offset modulo the access
size to the base object).
Bootstrap and regtest running on x86_64-unknown-linux-gnu.
I have applied the following variant which also handles NULL
TYPE_SIZE_UNIT and treats those cases less conservative by
simply forcing the index to be always zero.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk
sofar.
Richard.
2015-01-15 Richard Biener rguent...@suse.de
PR middle-end/64365
* tree-data-ref.c (dr_analyze_indices): Make sure that accesses
for MEM_REF access functions with the same base can never partially
overlap.
* gcc.dg/torture/pr64365.c: New testcase.
Index: gcc/tree-data-ref.c
===
--- gcc/tree-data-ref.c (revision 219603)
+++ gcc/tree-data-ref.c (working copy)
@@ -992,6 +994,22 @@ dr_analyze_indices (struct data_referenc
fold_convert (ssizetype, memoff));
memoff = build_int_cst (TREE_TYPE (memoff), 0);
}
+ /* Adjust the offset so it is a multiple of the access type
+size and thus we separate bases that can possibly be used
+to produce partial overlaps (which the access_fn machinery
+cannot handle). */
+ wide_int rem;
+ if (TYPE_SIZE_UNIT (TREE_TYPE (ref))
+ TREE_CODE (TYPE_SIZE_UNIT (TREE_TYPE (ref))) == INTEGER_CST
+ !integer_zerop (TYPE_SIZE_UNIT (TREE_TYPE (ref
+ rem = wi::mod_trunc (off, TYPE_SIZE_UNIT (TREE_TYPE (ref)), SIGNED);
+ else
+ /* If we can't compute the remainder simply force the initial
+ condition to zero. */
+ rem = off;
+ off = wide_int_to_tree (ssizetype, wi::sub (off, rem));
+ memoff = wide_int_to_tree (TREE_TYPE (memoff), rem);
+ /* And finally replace the initial condition. */
access_fn = chrec_replace_initial_condition
(access_fn, fold_convert (orig_type, off));
/* ??? This is still not a suitable base object for
Index: gcc/testsuite/gcc.dg/torture/pr64365.c
===
--- gcc/testsuite/gcc.dg/torture/pr64365.c (revision 0)
+++ gcc/testsuite/gcc.dg/torture/pr64365.c (working copy)
@@ -0,0 +1,37 @@
+/* { dg-do run } */
+/* { dg-require-effective-target int32plus } */
+
+extern void abort (void);
+extern int memcmp (const void * , const void *, __SIZE_TYPE__);
+
+void __attribute__((noinline,noclone))
+foo(int *in)
+{
+ int i;
+ for (i = 62; i = 10; i--)
+{
+ in[i - 8] -= in[i];
+ in[i - 5] += in[i] * 2;
+ in[i - 4] += in[i];
+}
+}
+
+int main()
+{
+ int x[64];
+ int y[64] = { 0, 1, -2380134, -1065336, -1026376, 3264240, 3113534, 2328130,
3632054, 3839634, 2380136, 1065339, 1026380, 1496037, 1397286, 789976, 386408,
450984, 597112, 497464, 262008, 149184, 194768, 231519, 173984, 87753, 60712,
82042, 87502, 60014, 30050, 25550, 33570, 32386, 20464, 10675, 10868, 13329,
11794, 6892, 3988, 4564, 5148, 4228, 2284, 1568, 1848, 1943, 1472, 741, 628,
702, 714, 474, 230, 234, 238, 242, 120, 59, 60, 61, 62, 63 };
+ int i;
+
+ for (i = 0; i 64; ++i)
+{
+ x[i] = i;
+ __asm__ volatile ();
+}
+
+ foo (x);
+
+ if (memcmp (x, y, sizeof (x)) != 0)
+abort ();
+
+ return 0;
+}
Re: [patch] update function comments for lto_symtab_encoder_encode_*
On Wed, Jan 14, 2015 at 5:58 PM, Aldy Hernandez al...@redhat.com wrote: On 01/14/2015 01:06 AM, Richard Biener wrote: Whenever I get to the LTO part of this project, I promise to start documenting things better. This whole thing is a mystery. Well - mostly to me as well ;) I'll let Honza answer this... Ha, you're being too modest! I get the feeling that no one wants to own up to LTO :). So... Would anyone mind if I removed all references of WHOPR in the documentation (doc/lto.texi) and in *most* of the comments in the source? AFAICT, WHOPR has been the default LTO mode since Richard's linker plugin patch here: https://gcc.gnu.org/ml/gcc-patches/2014-03/msg00157.html From what I can see, WHOPR is the default unless no partitions were found, but otherwise there is no way to disable it. It's just confusing to have this nomenclature that is mostly not applicable. You can disable WHOPR with -flto-partition=none, otherwise partitions are always found (thus even if we identify only a single partition we use a separate ltrans process). I obviously wouldn't change actual code, since we're past stage1, but comments/documentation are fair game. Eventually, I'd like to change the code to something like LTO partitioning mode or something (at the next stage1). Would this be acceptable? I'm not sure what you propose to change? The references to WHOPR may be historical (refering to the design document), and re-wording the user-level and internals documentation to make it the default behavior and maybe cite non-whopr mode as optimization in case of a single partition is ok. Note that we still have the issue that we want to exercise both WHOPR and non-WHOPR in the testsuite but all testcases are so small that we'd automagically would use non-WHOPR mode (if such automatism was implemented...). Richard. Aldy
Re: [PATCH] Reenable CSE of non-volatile inline asm (PR rtl-optimization/63637)
On Thu, Jan 15, 2015 at 07:46:18AM +0100, Richard Biener wrote:
That last line means the compiler is free to delete a non-volatile
asm with a memory clobber if that asm is not needed for dataflow. Or
that is how I read it; it is trying to indicate that if you want to
prevent the memory clobber from being deleted (together with the rest
of the asm), you need to make the asm volatile.
So as far as I can see the compiler can CSE two identical
non-volatile
asms with memory clobber just fine. Older GCC (I tried 4.7.2) does
do
this; current mainline doesn't. I think it should.
No, it should not CSE those two cases. That's simply wrong and if an
older version did that optimization, that's a bug.
I think segher has a point here. If the asm with memory clobber would store
to random memory and the point would be to preserve that then the whole
distinction with volatile doesn't make much sense (after all without volatile
we happily DCE such asm if the regular outputs are not needed).
This doesn't mean 'memory' is a well-designed thing, of course. Just its
effects are effectively limited to reads without volatile(?)
Segher's mails talk about memory being a write but not read.
If we even can't agree on what non-volatile memory means, I think
we should treat it more conservatively, because every user (and there are
lots of people using non-volatile asm with memory in the wild) treats it
differently. Just trying to grep for a few:
glibc:
./sysdeps/alpha/bits/atomic.h:# define atomic_full_barrier()__asm (mb : :
: memory);
./sysdeps/alpha/bits/atomic.h:# define atomic_read_barrier()__asm (mb : :
: memory);
./sysdeps/alpha/bits/atomic.h:# define atomic_write_barrier() __asm (wmb :
: : memory);
./sysdeps/sparc/sparc32/bits/atomic.h:# define atomic_full_barrier() __asm (
::: memory)
./sysdeps/powerpc/powerpc32/bits/atomic.h:# define atomic_read_barrier()
__asm (lwsync ::: memory)
./sysdeps/powerpc/powerpc32/bits/atomic.h:# define atomic_read_barrier()
__asm (sync ::: memory)
./sysdeps/powerpc/powerpc64/bits/atomic.h:#define atomic_read_barrier() __asm
(lwsync ::: memory)
./sysdeps/powerpc/bits/atomic.h:#define atomic_full_barrier() __asm (sync
::: memory)
./sysdeps/powerpc/bits/atomic.h:#define atomic_write_barrier() __asm (eieio
::: memory)
./sysdeps/generic/malloc-machine.h:# define atomic_full_barrier() __asm ( :::
memory)
./elf/tst-tlsmod3.c: asm ( ::: memory);
./elf/tst-tlsmod4.c: asm ( ::: memory);
./elf/tst-tlsmod1.c: asm ( ::: memory);
./elf/tst-tlsmod2.c: asm ( ::: memory);
./include/atomic.h:# define atomic_full_barrier() __asm ( ::: memory)
linux kernel:
./arch/arm/mach-omap2/pm24xx.c: asm(mcr p15, 0, %0, c7, c0, 4 : : r (zero)
: memory, cc);
./arch/arm/include/asm/irqflags.h:#define local_fiq_enable() __asm__(cpsie f
@ __stf : : : memory, cc)
./arch/arm/include/asm/irqflags.h:#define local_fiq_disable() __asm__(cpsid f
@ __clf : : : memory, cc)
./arch/x86/include/asm/uaccess_64.h:asm(:::memory);
./arch/x86/include/asm/uaccess_64.h:asm(:::memory);
./arch/x86/include/asm/segment.h: asm(mov %% #seg ,%0:=r (value) :
: memory)
./arch/x86/include/asm/stackprotector.h:asm(mov %0, %%gs : : r
(__KERNEL_STACK_CANARY) : memory);
./arch/arm64/include/asm/irqflags.h:#define local_fiq_enable() asm(msr
daifclr, #1 : : : memory)
./arch/arm64/include/asm/irqflags.h:#define local_fiq_disable() asm(msr
daifset, #1 : : : memory)
./arch/arm64/include/asm/irqflags.h:#define local_async_enable()
asm(msrdaifclr, #4 : : : memory)
./arch/arm64/include/asm/irqflags.h:#define local_async_disable()
asm(msrdaifset, #4 : : : memory)
./arch/tile/lib/memcpy_64.c:__asm__ ( : : :
memory);
./arch/tile/lib/memcpy_64.c:__asm__ ( : : :
memory);
./arch/tile/include/hv/netio_intf.h: __asm__( : : : memory);
./drivers/net/ethernet/sgi/ioc3-eth.c: __asm__(sync ::: memory)
./lib/sha1.c: #define setW(x, val) do { W(x) = (val); __asm__(:::memory);
} while (0)
The glibc barriers are supposedly something that can be CSEd (one barrier
instead of
two consecutive barriers is enough), but certainly not moved across any
loads/stores
in between. In the kernel case, the enable/disable probably wouldn't allow
even CSE.
So I'm with Jeff that we should treat memory at least as unspecified read and
write,
and whether we can CSE them if there are no memory loads/stores in between them
can
be discussed (most likely the kernel would be safe even in that case, because
those
usually don't nest and appear in pairs, or act as barriers (like the glibc
case),
or read from segment registers (guess again ok to be CSEd with no intervening
loads/stores).
In 4.9 backport I'd prefer not to CSE them at all though, stay conservative.
Jakub
