[PATCH] pr 63325 - make fold ignore decl_with_vis.symtab_node
From: Trevor Saunders tbsaunde+...@tbsaunde.org
Hi,
fold calls symtab_node::get_create () which can change this field from NULL to
point to a new object. It doesn't seem to really matter when the object gets
created and I don't think it changes any properties of the tree object. So I
think it makes sense to do here what we do for similar members and leave it out
of the checksum.
bootstrapped + regtested x86_64-linux-gnu, ok?
Trev
gcc/
* fold-const.c (fold_checksum_tree): Don't include
expr.decl_with_vis.symtab_node in the checksum.
diff --git a/gcc/fold-const.c b/gcc/fold-const.c
index b1cbfac..88aa20e 100644
--- a/gcc/fold-const.c
+++ b/gcc/fold-const.c
@@ -14065,11 +14065,12 @@ fold_checksum_tree (const_tree expr, struct md5_ctx
*ctx,
*slot = expr;
code = TREE_CODE (expr);
if (TREE_CODE_CLASS (code) == tcc_declaration
- DECL_ASSEMBLER_NAME_SET_P (expr))
+ HAS_DECL_ASSEMBLER_NAME_P (expr))
{
- /* Allow DECL_ASSEMBLER_NAME to be modified. */
+ /* Allow DECL_ASSEMBLER_NAME and symtab_node to be modified. */
memcpy ((char *) buf, expr, tree_size (expr));
SET_DECL_ASSEMBLER_NAME ((tree)buf, NULL);
+ buf.decl_with_vis.symtab_node = NULL;
expr = (tree) buf;
}
else if (TREE_CODE_CLASS (code) == tcc_type
--
2.1.4
Re: [PING]: [PATCH]: Conditionally include target specific files while building TSAN
On Thu, Jan 22, 2015 at 5:03 PM, Jakub Jelinek ja...@redhat.com wrote: On Thu, Jan 22, 2015 at 07:30:50PM +0530, Venkataramanan Kumar wrote: ping. Forgot to mention, GCC bootstraps and regression testing passed on x86_64. Well, without a change from upstream to guard the HACKY_CALL and actual tsan port to non-x86_64 this patch doesn't solve anything. I've just committed that change upstream: http://llvm.org/viewvc/llvm-project?view=revisionrevision=226829 Now we need to summon +Kostya to update gcc version of runtime.
Re: [patch] gcc fstack-protector-explicit
On Wed, Jan 21, 2015 at 10:07:14AM +0100, Rainer Orth wrote:
Ok for mainline once that has been done?
Thanks.
Rainer
2015-01-20 Rainer Orth r...@cebitec.uni-bielefeld.de
* gcc.c (LINK_SSP_SPEC): Handle -fstack-protector-explicit.
Ok.
Though wonder if for the TARGET_LIBC_PROVIDES_SSP case LINK_SSP_SPEC
shouldn't be
#define LINK_SSP_SPEC
{fstack-protector|fstack-protector-strong|fstack-protector-explicit|fstack-protector-all:}
and
gcc/config/freebsd.h:
#define LINK_SSP_SPEC %{fstack-protector|fstack-protector-all:-lssp_nonshared}
should be changed too (adding both -string and -explicit).
# HG changeset patch
# Parent 32ee1d2fb4ac6498d6363a1841482f8c9fa521d7
Handle -fstack-protector-explicit in LINK_SSP_SPEC
diff --git a/gcc/gcc.c b/gcc/gcc.c
--- a/gcc/gcc.c
+++ b/gcc/gcc.c
@@ -730,7 +730,7 @@ proper position among the other output f
#ifdef TARGET_LIBC_PROVIDES_SSP
#define LINK_SSP_SPEC %{fstack-protector:}
#else
-#define LINK_SSP_SPEC
%{fstack-protector|fstack-protector-strong|fstack-protector-all:-lssp_nonshared
-lssp}
+#define LINK_SSP_SPEC
%{fstack-protector|fstack-protector-strong|fstack-protector-explicit|fstack-protector-all:-lssp_nonshared
-lssp}
#endif
#endif
Jakub
Re: [PING]: [PATCH]: Conditionally include target specific files while building TSAN
On Thu, Jan 22, 2015 at 07:30:50PM +0530, Venkataramanan Kumar wrote: ping. Forgot to mention, GCC bootstraps and regression testing passed on x86_64. Well, without a change from upstream to guard the HACKY_CALL and actual tsan port to non-x86_64 this patch doesn't solve anything. Jakub
Re: [PATCH] toplev.c: Process the failure when read fails for random_seed
On 01/22/2015 02:46 AM, Mike Stump wrote: On Jan 21, 2015, at 1:54 AM, Chen Gang S gang.c...@sunrus.com.cn wrote: On 1/6/15 04:07, Jeff Law wrote: * toplev.c (init_local_tick): Process the failure when read fails for random_seed. This is fine for the trunk. Please install. I am not familiar with the related working flow, who should install this patch? Anyone with write privileges can do this. You can request installation of the patch with the magic phrase: I don’t have write access yet nor is my paperwork compete, can someone install this for me? This will prompt a volunteer to step forward and help get it installed. When they are done, they will say, installed, close any related bug report and if they are nice, tell you the commit number for the work. You can then update your tree, build and test and ensure the work is as you wanted it. Once it hits the trunk, you’re done. If the patch is important enough for a back-port, you can ask people to consider a back port, once the work has been proven on the trunk for a week or two. OK, thanks, for me, this is only a trivial patch (not urgent). So I can understand why it is still pending. And if possible, could you help install this patch when you have time? :-) Thanks. -- Open, share, and attitude like air, water, and life which God blessed.
Re: [PATCH v3] gcc/ubsan.c: Use 'pretty_print' for 'pretty_name' to avoid memory overflow
On 11/24/2014 04:24 PM, Jakub Jelinek wrote: On Mon, Nov 24, 2014 at 04:28:10PM +0800, Chen Gang wrote: On 11/24/14 15:41, Jakub Jelinek wrote: On Sun, Nov 23, 2014 at 09:13:27AM +0800, Chen Gang wrote: [...] +else + pp_wide_int(pretty_name, + wi::add (wi::to_widest (TYPE_MAX_VALUE (dom)), 1), + TYPE_SIGN (TREE_TYPE (dom))); Space still missing before ( (and reindenting the following 2 lines). Oh, thanks, if necessary to send patch v4, please let me know. No, just fix it up before checking in. Hello Maintainers: At present, I don’t have write access yet nor is my paperwork compete, could someone help install it for me? Thanks. -- Chen Gang Open share and attitude like air water and life which God blessed -- Open, share, and attitude like air, water, and life which God blessed.
[PING]: [PATCH]: Conditionally include target specific files while building TSAN
ping. Forgot to mention, GCC bootstraps and regression testing passed on x86_64. regards, Venkat. On 20 January 2015 at 18:51, Venkataramanan Kumar venkataramanan.ku...@linaro.org wrote: Hi all, This patch changes make file and configure under libsanitizer, to separate out X86_64 specific file tsan_rtl_amd64.S from getting build for targets other than X86_64. Ok for trunk? Please review. regards, Venkat, ChangeLog 2015-01-19 Venkataramanan Kumar venkataramanan.ku...@linaro.org * configure.ac (TSAN_TARGET_DEPENDENT_OBJECTS): Define. * configure: Regenerate. * tsan/Makefile.am (EXTRA_libtsan_la_SOURCES): Define, (libtsan_la_DEPENDENCIES): Likewise. * Makefile.in: Regenerate. * asan/Makefile.in: Regenerate. * interception/Makefile.in: Regenerate. * libbacktrace/Makefile.in: Regenerate. * lsan/Makefile.in: Regenerate. * sanitizer_common/Makefile.in: Regenerate. * tsan/Makefile.in: Regenerate. * ubsan/Makefile.in: Regenerate.
[PING] : [RFC] Tighten memory type assumption in RTL combiner pass.
ping. Segher do you any comments from your side.
regards,
Venkat.
On 14 January 2015 at 16:57, Venkataramanan Kumar
venkataramanan.ku...@linaro.org 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.
regards,
Venkat.
Re: [PATCH 2/4] match.pd: Add x ~(x y) - x ~y pattern
On Thu, Jan 22 2015, Richard Biener richard.guent...@gmail.com wrote: On Wed, Jan 21, 2015 at 9:00 PM, Marc Glisse marc.gli...@inria.fr wrote: Hello, (sorry for the broken thread, for some reason I haven't received any email from gcc since about 10am, I'll investigate later) +/* x ~(x y) - x ~y */ +(simplify + (bit_and:c @0 (bit_not (bit_and:c@2 @0 @1))) + (if (TREE_CODE (@2) != SSA_NAME || has_single_use (@2)) + (bit_and @0 (bit_not @1 Wouldn't it make more sense to put @2 on bit_not? If bit_and is used multiple times, the transformation is neutral so it should be done as a canonicalization. On the other hand, if bit_not is used multiple times, the transformation adds an extra bit_not (which might be free when there is an andn insn). So I believe the 2 main options are: - move @2 on the bit_not - don't test has_single_use at all I tend to favor not testing has_single_use at all. Does this apply only to this pattern, to this pattern and its dual (3/4), or to all four? Rasmus
Re: [PING]: [PATCH]: Conditionally include target specific files while building TSAN
On Thu, Jan 22, 2015 at 06:16:53PM +0400, Dmitry Vyukov wrote: On Thu, Jan 22, 2015 at 5:03 PM, Jakub Jelinek ja...@redhat.com wrote: On Thu, Jan 22, 2015 at 07:30:50PM +0530, Venkataramanan Kumar wrote: ping. Forgot to mention, GCC bootstraps and regression testing passed on x86_64. Well, without a change from upstream to guard the HACKY_CALL and actual tsan port to non-x86_64 this patch doesn't solve anything. I've just committed that change upstream: http://llvm.org/viewvc/llvm-project?view=revisionrevision=226829 Now we need to summon +Kostya to update gcc version of runtime. I'll just cherry pick that, we are too late in the GCC release cycle. Once GCC 5 branches, of course another merge will be desirable. Thus the configure/Makefile patch is ok too, but please fix up the ChangeLog formatting (e.g. two spaces before instead of one, tab indentation, no unnecessary wrapping). That said, I'd strongly prefer if asan is fixed for aarch64 first before you consider enabling tsan on aarch64, otherwise you add something that will fail miserably on many aarch64 configurations. Jakub
Re: [[ARM/AArch64][testsuite] 03/36] Add vmax, vmin, vhadd, vhsub and vrhadd tests.
On 22 January 2015 at 12:19, Tejas Belagod tejas.bela...@arm.com wrote: On 21/01/15 15:07, Christophe Lyon wrote: On 19 January 2015 at 17:54, Marcus Shawcroft marcus.shawcr...@gmail.com wrote: On 19 January 2015 at 15:43, Christophe Lyon christophe.l...@linaro.org wrote: On 19 January 2015 at 14:29, Marcus Shawcroft marcus.shawcr...@gmail.com wrote: On 16 January 2015 at 17:52, Christophe Lyon christophe.l...@linaro.org wrote: OK provided, as per the previous couple, that we don;t regression or introduce new fails on aarch64[_be] or aarch32. This patch shows failures on aarch64 and aarch64_be for vmax and vmin when the input is -NaN. It's a corner case, and my reading of the ARM ARM is that the result should the same as on aarch32. I haven't had time to look at it in more details though. So, not OK? They should have the same behaviour in aarch32 and aarch64. Did you test on HW or a model? I ran the tests on qemu for aarch32 and aarch64-linux, and on the foundation model for aarch64*-elf. Leave this one out until we understand why it fails. /Marcus I've looked at this a bit more. We have fmaxv0.4s, v0.4s, v1.4s where v0 is a vector of -NaN (0xffc0) and v1 is a vector of 1. The output is still -NaN (0xffc0), while the test expects defaultNaN (0x7fc0). In the AArch32 execution state, Advanced SIMD FP arithmetic always uses the DefaultNaN setting regardless of the DN-bit value in the FPSCR. In AArch64 execution state, result of Advanced SIMD FP arithmetic operations depend on the value of the DN-bit i.e. either propagate the input NaN or generate DefaultNaN depending on the value of DN. Maybe I'm using an outdated doc. On page 2282 of ARMv8 ARM rev C, I can see only the latter (no diff between aarch32 and aarch64 in FPProcessNan pseudo-code) If you're running your test in the AArch64 execution state, you'd want to define the DN bit and modify the expected results accordingly or have the test poll at runtime what the DN-bit is set to and check expected results dynamically. Makes sense, I hadn't noticed the different aarch64 spec here. I think the test already has expected behaviour for AArch32 execution state by expecting DefaultNaN regardless. Yes. I have executed the test under GDB on AArch64 HW, and noticed that fpcr was 0. I forced it to have DN==1: set $fpcr=0x100 but this didn't change the result. Does setting fpcr.dn under gdb actually work? It should. Possibly a bug, patches welcome :-). :-)
[Committed] S/390: Fix typo in atomic code iterator
Hi, I've committed the following bugfix which fixes an obvious typo in the atomic code attribute. Due to this the load and or instructions was not used. Committed to 4.9 branch and mainline. Bye, -Andreas- 2015-01-22 Andreas Krebbel andreas.kreb...@de.ibm.com * config/s390/s390.md (atomic code attribute): Fix typo ior - or. diff --git a/gcc/config/s390/s390.md b/gcc/config/s390/s390.md index fab1898..90f6fc9 100644 --- a/gcc/config/s390/s390.md +++ b/gcc/config/s390/s390.md @@ -417,7 +417,7 @@ ;; This iterator and attribute allow to combine most atomic operations. (define_code_iterator ATOMIC [and ior xor plus minus mult]) (define_code_iterator ATOMIC_Z196 [and ior xor plus]) -(define_code_attr atomic [(and and) (ior ior) (xor xor) +(define_code_attr atomic [(and and) (ior or) (xor xor) (plus add) (minus sub) (mult nand)]) (define_code_attr noxa [(and n) (ior o) (xor x) (plus a)])
Re: [PATCH] libgcc: unwind-dw2-fde.h: Use (const fde *) instead of (char *) to avoid qualifier warning
On 10/08/2014 10:52 PM, Richard Henderson wrote: On 10/08/2014 03:47 AM, Chen Gang wrote: It passes make -k check under Darwin x86_64. 2014-10-07 Chen Gang gang.chen.5...@gmail.com * unwind-dw2-fde.h (last_fde): Use (const fde *) instead of (char *) to avoid qualifier warning by 'xgcc' compiling. Ok. Hello Maintainers: At present, I don’t have write access yet nor is my paperwork compete, could someone help install it for me? Thanks. -- Chen Gang Open share and attitude like air water and life which God blessed -- Open, share, and attitude like air, water, and life which God blessed.
Re: [PING]: [PATCH]: Conditionally include target specific files while building TSAN
Hi Jakub, Thank you for the reply. Yes there is no functional change. I got some comments in PR63850 about pushing a patch since is GCC only change. Ok I will wait for LLVM merge of TSAN which needs this patch. regards, Venkat. On 22 January 2015 at 19:33, Jakub Jelinek ja...@redhat.com wrote: On Thu, Jan 22, 2015 at 07:30:50PM +0530, Venkataramanan Kumar wrote: ping. Forgot to mention, GCC bootstraps and regression testing passed on x86_64. Well, without a change from upstream to guard the HACKY_CALL and actual tsan port to non-x86_64 this patch doesn't solve anything. Jakub
Re: [build] libatomic, libgfortran: Use automake-1.11.1 to sync with the rest
ping As trunk is in stage 4, is there some accepted custom to re-run all the third party generators, to avoid different versions of generated code across the final release? Thanks! /haubi/ On 01/04/2015 08:20 PM, Michael Haubenwallner wrote: (CC'ing build machinery maintainers, maybe I should have done this initially) Am 2014-12-31 um 11:45 schrieb Janne Blomqvist: On Fri, Dec 19, 2014 at 2:56 PM, Michael Haubenwallner michael.haubenwall...@ssi-schaefer.com wrote: On the way to prepare some (aix) libtool patch for toplevel libtool.m4 I've discovered that different versions of automake were used to generate files across various libs: most libs: automake-1.11.1 libatomic r211747: automake-1.11.6 libgfortran r204654: automake-1.11.3 r215741: automake-1.11.6 Doesn't feel like there were specific reasons to use newer versions, but OTOH I've failed to find some docs on which versions to use, so I'd be fine with updating others to 1.11.6 instead as well. I'm far from an autotools expert, but one justification for updating to 1.11.6 would be CVE-2012-3386, see https://lists.gnu.org/archive/html/automake/2012-07/msg00023.html . Whatever version we end up choosing, the docs should say it so that there won't be such misconceptions in the future, IMHO. IMHO, changing an autotool's version in general should be up to (review by) the build machinery maintainers. And it should be done across the whole tree, not just for various subdirectories. However, each update listed here feels like happened by accident, using the version installed on the more or less up-to-date host OS. Am 2014-12-28 um 05:20 schrieb Bernd Edlinger: On Fri, 19 Dec 2014 13:56:50, Michael Haubenwallner wrote: text above Michael proposes to change everything to automake-1.11.1. But the helper files missing and friends were updated to automake-1.14.1 by: 2014-11-16 Jan-Benedict Glaw jbg...@lug-owl.de * compile: Sync with upstream Automake. * depcomp: Ditto. * install-sh: Ditto. * missing: Ditto. * mkinstalldirs: Ditto. * ylwrap: Ditto. Actually I thought that was in preparation to move everything to automake 1.14.1 If I see that right, calling automake without parameters does not touch these helper files, but automake --add-missing --copy --force-missing would replace them with the copy from the automake installation additionally to just rewriting the Makefile.in. I think we should have all automake files from the same version, either 1.11.1 or 1.14.1. What do you think? Updating to 1.14 might require more work like updating some .in files as well. I've seen automake-1.11 being explicitly used, so for now we really want 1.11.6 eventually? /haubi/
Re: [PATCH 2/4] match.pd: Add x ~(x y) - x ~y pattern
On Wed, Jan 21, 2015 at 9:00 PM, Marc Glisse marc.gli...@inria.fr wrote: Hello, (sorry for the broken thread, for some reason I haven't received any email from gcc since about 10am, I'll investigate later) +/* x ~(x y) - x ~y */ +(simplify + (bit_and:c @0 (bit_not (bit_and:c@2 @0 @1))) + (if (TREE_CODE (@2) != SSA_NAME || has_single_use (@2)) + (bit_and @0 (bit_not @1 Wouldn't it make more sense to put @2 on bit_not? If bit_and is used multiple times, the transformation is neutral so it should be done as a canonicalization. On the other hand, if bit_not is used multiple times, the transformation adds an extra bit_not (which might be free when there is an andn insn). So I believe the 2 main options are: - move @2 on the bit_not - don't test has_single_use at all I tend to favor not testing has_single_use at all. Richard. -- Marc Glisse
[PATCH] Add new target h8300-*-linux
Add h8300-*-linux target for h8300 linux kernel and userland.
h8300-*-elf is some difference of standard elf.
h8300-*-linux is compatible of standard elf rules.
Thanks.
diff --git a/gcc/config.gcc b/gcc/config.gcc
index 9d3fa57..acbbbe1 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -1190,6 +1190,10 @@ h8300-*-elf*)
tmake_file=h8300/t-h8300
tm_file=h8300/h8300.h dbxelf.h elfos.h newlib-stdint.h h8300/elf.h
;;
+h8300-*-linux*)
+ tmake_file=${tmake_file} h8300/t-h8300 h8300/t-linux
+ tm_file=h8300/linux.h dbxelf.h elfos.h linux.h
+ ;;
hppa*64*-*-linux*)
target_cpu_default=MASK_PA_11|MASK_PA_20
tm_file=pa/pa64-start.h ${tm_file} dbxelf.h elfos.h gnu-user.h linux.h
\
diff --git a/gcc/config/h8300/h8300.c b/gcc/config/h8300/h8300.c
index e7ed03a..4ec8516 100644
--- a/gcc/config/h8300/h8300.c
+++ b/gcc/config/h8300/h8300.c
@@ -359,11 +359,13 @@ h8300_option_override (void)
target_flags |= MASK_H8300S_1;
}
+#ifndef __h8300_linux__
if (TARGET_H8300 TARGET_INT32)
{
error (-mint32 is not supported for H8300 and H8300L targets);
target_flags ^= MASK_INT32;
}
+#endif
if ((!TARGET_H8300STARGET_EXR) (!TARGET_H8300SX TARGET_EXR))
{
diff --git a/gcc/config/h8300/linux.h b/gcc/config/h8300/linux.h
new file mode 100644
index 000..1cdfcf5
--- /dev/null
+++ b/gcc/config/h8300/linux.h
@@ -0,0 +1,784 @@
+/* Definitions of target machine for GNU compiler.
+ Renesas H8/300 (linux variant)
+ Copyright (C) 2015
+ Free Software Foundation, Inc.
+ Contributed by Yoshinori Sato ys...@users.sourceforge.jp
+
+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_H8300_H
+#define GCC_H8300_H
+
+#define __h8300_linux__
+
+/* Which CPU to compile for.
+ We use int for CPU_TYPE to avoid lots of casts. */
+#if 0 /* defined in insn-attr.h, here for documentation */
+enum attr_cpu { CPU_H8300, CPU_H8300H };
+#endif
+extern int cpu_type;
+
+/* Various globals defined in h8300.c. */
+
+extern const char *h8_push_op, *h8_pop_op, *h8_mov_op;
+extern const char * const *h8_reg_names;
+
+/* Target CPU builtins. */
+#define TARGET_CPU_CPP_BUILTINS() \
+ do \
+{ \
+ if (TARGET_H8300H) \
+ { \
+ builtin_define (__H8300H__);\
+ builtin_assert (cpu=h8300h);\
+ builtin_assert (machine=h8300h);\
+ if (TARGET_NORMAL_MODE) \
+ { \
+ builtin_define (__NORMAL_MODE__); \
+ } \
+ } \
+ else if (TARGET_H8300SX) \
+ { \
+ builtin_define (__H8300SX__); \
+ if (TARGET_NORMAL_MODE) \
+ { \
+ builtin_define (__NORMAL_MODE__); \
+ } \
+ } \
+ else if (TARGET_H8300S) \
+ { \
+ builtin_define (__H8300S__);\
+ builtin_assert (cpu=h8300s);\
+ builtin_assert (machine=h8300s);\
+ if (TARGET_NORMAL_MODE) \
+ { \
+ builtin_define (__NORMAL_MODE__); \
+ } \
+ } \
+ else \
+ { \
+ builtin_define (__H8300__); \
+ builtin_assert (cpu=h8300); \
+ builtin_assert (machine=h8300); \
+ } \
+ GNU_USER_TARGET_OS_CPP_BUILTINS(); \
+} \
+ while (0)
+
RE: [MIPS] fix CRT_CALL_STATIC_FUNCTION macro
This is a follow-up to a change [1] in glibc. It fixes the issue [2] when jal can not reach a target in different region. It has been tested with DejaGnu for mips32/o32, mips64/n32 and mips64/n64. Let me know what you think. So to confirm, the issue is non-pic crt calling an init routine beyond the current 256 MB region? Otherwise for PIC the issue is dealt with by the assembler with the JAL sym being expanded to a load from the got and indirect call through t9. Previously t9 would not have been set up for the callee if the code was built non-pic (as it would just use a JAL). That would have made the setup of gp somewhat pointless in the CRT_CALL_STATIC_FUNCTION code. I am therefore a little confused by the existing code that sets up GP but then it seemingly is not used unless built for PIC. I need a little time to consider this further. Catherine may comment in the meantime. Thanks, Matthew
Re: [PATCH] Fix inlining checks wrt optimize attribute
Hi Richard,
I thought one of my current issue would be solved by this patch, but it
is not : I have some inlining failures with the attribute target on ARM.
(e.g inline-3.c) where obvious early inline fails with because we fail
into the last can_inline_edge_p case:
opt_for_fn (callee-decl, optimize)
= opt_for_fn (caller-decl, optimize)))
when callee and caller are both -O2 and
targetm.target_option.can_inline_p was true, they should be inlined as
in the general case (no DECL_FUNCTION_SPECIFIC_OPTIMIZATION)
I'm currently testing this additional change:
Index: ipa-inline.c
===
--- ipa-inline.c(revision 219989)
+++ ipa-inline.c(working copy)
@@ -489,7 +489,7 @@
else if (opt_for_fn (callee-decl, optimize_size)
opt_for_fn (caller-decl, optimize_size)
|| (opt_for_fn (callee-decl, optimize)
- = opt_for_fn (caller-decl, optimize)))
+ opt_for_fn (caller-decl, optimize)))
{
if (estimate_edge_time (e)
= 20 + inline_edge_summary (e)-call_stmt_time)
Since this is a hot topic for you, I though you would have useful
comments on this before I ask for a commit (when stage 4 close) ?
Cheers
Christian
On 01/22/2015 10:24 AM, Richard Biener wrote:
As said in the other thread - this makes sure we don't perform inlining
that might end up generating invalid code. It also preserves
user-provided optimize attributes more properly.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
Richard.
2015-01-22 Richard Biener rguent...@suse.de
* ipa-inline.c (can_inline_edge_p): Disable inlining of edges
with IL incompatible options. Properly honor user optimize
attributes.
Index: gcc/ipa-inline.c
===
--- gcc/ipa-inline.c(revision 219929)
+++ gcc/ipa-inline.c(working copy)
@@ -404,17 +404,56 @@ can_inline_edge_p (struct cgraph_edge *e
optimization attribute. */
else if (caller_tree != callee_tree)
{
- /* gcc.dg/pr43564.c. Look at forced inline even in -O0. */
- if (DECL_DISREGARD_INLINE_LIMITS (callee-decl))
+ /* There are some options that change IL semantics which means
+ we cannot inline in these cases for correctness reason.
+Not even for always_inline declared functions. */
+ /* Strictly speaking only when the callee contains signed integer
+ math where overflow is undefined. */
+ if ((opt_for_fn (e-caller-decl, flag_strict_overflow)
+ != opt_for_fn (e-caller-decl, flag_strict_overflow))
+ || (opt_for_fn (e-caller-decl, flag_wrapv)
+ != opt_for_fn (e-caller-decl, flag_wrapv))
+ || (opt_for_fn (e-caller-decl, flag_trapv)
+ != opt_for_fn (e-caller-decl, flag_trapv))
+ /* Strictly speaking only when the callee contains memory
+accesses that are not using alias-set zero anyway. */
+ || (opt_for_fn (e-caller-decl, flag_strict_aliasing)
+ != opt_for_fn (e-caller-decl, flag_strict_aliasing))
+ /* Strictly speaking only when the callee uses FP math. */
+ || (opt_for_fn (e-caller-decl, flag_rounding_math)
+ != opt_for_fn (e-caller-decl, flag_rounding_math))
+ || (opt_for_fn (e-caller-decl, flag_trapping_math)
+ != opt_for_fn (e-caller-decl, flag_trapping_math))
+ || (opt_for_fn (e-caller-decl, flag_unsafe_math_optimizations)
+ != opt_for_fn (e-caller-decl, flag_unsafe_math_optimizations))
+ || (opt_for_fn (e-caller-decl, flag_finite_math_only)
+ != opt_for_fn (e-caller-decl, flag_finite_math_only))
+ || (opt_for_fn (e-caller-decl, flag_signaling_nans)
+ != opt_for_fn (e-caller-decl, flag_signaling_nans))
+ || (opt_for_fn (e-caller-decl, flag_cx_limited_range)
+ != opt_for_fn (e-caller-decl, flag_cx_limited_range))
+ || (opt_for_fn (e-caller-decl, flag_signed_zeros)
+ != opt_for_fn (e-caller-decl, flag_signed_zeros))
+ || (opt_for_fn (e-caller-decl, flag_associative_math)
+ != opt_for_fn (e-caller-decl, flag_associative_math))
+ || (opt_for_fn (e-caller-decl, flag_reciprocal_math)
+ != opt_for_fn (e-caller-decl, flag_reciprocal_math))
+ /* Strictly speaking only when the callee contains function
+calls that may end up setting errno. */
+ || (opt_for_fn (e-caller-decl, flag_errno_math)
+ != opt_for_fn (e-caller-decl, flag_errno_math)))
+ {
+ e-inline_failed = CIF_OPTIMIZATION_MISMATCH;
+ inlinable = false;
+ }
+ /* gcc.dg/pr43564.c. Apply user-forced inline even at -O0. */
+ else if (DECL_DISREGARD_INLINE_LIMITS (callee-decl)
+ lookup_attribute (always_inline,
+
Ping: [PATCH, ARM, testsuite] Improve scd42-1.c for UAL
Ping -Original Message- From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-ow...@gcc.gnu.org] On Behalf Of Tony Liu Sent: Thursday, January 15, 2015 8:10 PM To: gcc-patches@gcc.gnu.org Cc: Ramana Radhakrishnan; Richard Earnshaw Subject: [PATCH, ARM, testsuite] Improve scd42-1.c for UAL Hi, This is the patch to improve the test case gcc.target/arm/scd42-1.c for both UAL and non-UAL. It now checks UAL format assembly code for Thumb1 and Thumb2 while non-UAL format assembly code for ARM mode. With this patch, the test passes for both cases. Thanks, Tony 2015-01-15 Tony Liu tony@arm.com * gcc.target/arm/scd42-1.c: Improve the check for UAL and non-UAL cases.
[PATCH, driver/64690] Fix -freport-bug issue with comments.
Hi,
As -freport-bug dumps also the error output into the file as /* ... */
comment, there is a problem if that text includes /* or */ character
sequences.
This patch fixes this by not wrapping error output with /* ... */, but
comment out each line with C++ style comments instead.
Tested on PR64688 testcase with added /* */ before last line, bootstrap
in progress.
Ok to commit if bootstrap succeed?
-Maxim
gcc/ChangeLog:
2015-01-22 Max Ostapenko m.ostape...@partner.samsung.com
PR driver/64690
* gcc.c (insert_comments): New function.
(try_generate_repro): Call it.
(append_text): Removed.
diff --git a/gcc/gcc.c b/gcc/gcc.c
index 52d0521..6d3939c 100644
--- a/gcc/gcc.c
+++ b/gcc/gcc.c
@@ -6487,6 +6487,28 @@ out:
return status;
}
+/* This routine reads lines from IN file, adds C++ style comments
+ at the begining of each line and writes result into OUT. */
+
+static void
+insert_comments (const char *file_in, const char *file_out)
+{
+ FILE *in = fopen (file_in, rb);
+ FILE *out = fopen (file_out, wb);
+ char line[256];
+ fputs (// , out);
+ while (fgets (line, sizeof (line), in))
+{
+ fputs (line, out);
+ if (strchr (line, '\n'))
+ {
+ fputs (// , out);
+ }
+}
+ fclose (in);
+ fclose (out);
+}
+
/* This routine adds preprocessed source code into the given ERR_FILE.
To do this, it adds -E to NEW_ARGV and execute RUN_ATTEMPT routine to
add information in report file. RUN_ATTEMPT should return
@@ -6523,19 +6545,6 @@ do_report_bug (const char **new_argv, const int nargs,
}
}
-/* Append string STR to file FILE. */
-
-static void
-append_text (char *file, const char *str)
-{
- int fd = open (file, O_RDWR | O_APPEND);
- if (fd 0)
-return;
-
- write (fd, str, strlen (str));
- close (fd);
-}
-
/* Try to reproduce ICE. If bug is reproducible, generate report .err file
containing GCC configuration, backtrace, compiler's command line options
and preprocessed source code. */
@@ -6598,16 +6607,10 @@ try_generate_repro (const char **argv)
emit_system_info = 1;
}
- if (emit_system_info)
- append_text (temp_stderr_files[attempt], /*\n);
-
status = run_attempt (new_argv, temp_stdout_files[attempt],
temp_stderr_files[attempt], emit_system_info,
append);
- if (emit_system_info)
- append_text (temp_stderr_files[attempt], */\n);
-
if (status != ATTEMPT_STATUS_ICE)
{
fnotice (stderr, The bug is not reproducible, so it is
@@ -6619,11 +6622,17 @@ try_generate_repro (const char **argv)
if (!check_repro (temp_stdout_files, temp_stderr_files))
goto out;
- /* In final attempt we append compiler options and preprocesssed code to last
- generated .err file with configuration and backtrace. */
- do_report_bug (new_argv, nargs,
- temp_stderr_files[RETRY_ICE_ATTEMPTS - 1],
- temp_stdout_files[RETRY_ICE_ATTEMPTS - 1]);
+ {
+/* Insert commented out backtrace into report file. */
+char **stderr_commented = temp_stdout_files[RETRY_ICE_ATTEMPTS - 1];
+insert_comments (temp_stderr_files[RETRY_ICE_ATTEMPTS - 1],
+ *stderr_commented);
+
+/* In final attempt we append compiler options and preprocesssed code to last
+ generated .out file with configuration and backtrace. */
+char **output = temp_stdout_files[RETRY_ICE_ATTEMPTS - 1];
+do_report_bug (new_argv, nargs, stderr_commented, output);
+ }
out:
for (i = 0; i RETRY_ICE_ATTEMPTS * 2; i++)
Re: [PATCH, driver/64690] Fix -freport-bug issue with comments.
On Thu, Jan 22, 2015 at 12:25:20PM +0400, Maxim Ostapenko wrote:
gcc/ChangeLog:
2015-01-22 Max Ostapenko m.ostape...@partner.samsung.com
PR driver/64690
* gcc.c (insert_comments): New function.
(try_generate_repro): Call it.
(append_text): Removed.
diff --git a/gcc/gcc.c b/gcc/gcc.c
index 52d0521..6d3939c 100644
--- a/gcc/gcc.c
+++ b/gcc/gcc.c
@@ -6487,6 +6487,28 @@ out:
return status;
}
+/* This routine reads lines from IN file, adds C++ style comments
+ at the begining of each line and writes result into OUT. */
+
+static void
+insert_comments (const char *file_in, const char *file_out)
+{
+ FILE *in = fopen (file_in, rb);
+ FILE *out = fopen (file_out, wb);
+ char line[256];
+ fputs (// , out);
+ while (fgets (line, sizeof (line), in))
+{
+ fputs (line, out);
+ if (strchr (line, '\n'))
+ {
+ fputs (// , out);
+ }
Please don't put {}s around single line if body.
Also, if file_in ends with a newline, won't that mean an extra // will be
printed?
So what about
bool add_comment = true;
while (fgets (line, sizeof (line, in))
{
if (add_comment)
fputs (// , out);
add_comment = strchr (line, '\n') != NULL;
}
?
Otherwise LGTM.
Jakub
[PATCH] Fix inlining checks wrt optimize attribute
As said in the other thread - this makes sure we don't perform inlining
that might end up generating invalid code. It also preserves
user-provided optimize attributes more properly.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
Richard.
2015-01-22 Richard Biener rguent...@suse.de
* ipa-inline.c (can_inline_edge_p): Disable inlining of edges
with IL incompatible options. Properly honor user optimize
attributes.
Index: gcc/ipa-inline.c
===
--- gcc/ipa-inline.c(revision 219929)
+++ gcc/ipa-inline.c(working copy)
@@ -404,17 +404,56 @@ can_inline_edge_p (struct cgraph_edge *e
optimization attribute. */
else if (caller_tree != callee_tree)
{
- /* gcc.dg/pr43564.c. Look at forced inline even in -O0. */
- if (DECL_DISREGARD_INLINE_LIMITS (callee-decl))
+ /* There are some options that change IL semantics which means
+ we cannot inline in these cases for correctness reason.
+Not even for always_inline declared functions. */
+ /* Strictly speaking only when the callee contains signed integer
+ math where overflow is undefined. */
+ if ((opt_for_fn (e-caller-decl, flag_strict_overflow)
+ != opt_for_fn (e-caller-decl, flag_strict_overflow))
+ || (opt_for_fn (e-caller-decl, flag_wrapv)
+ != opt_for_fn (e-caller-decl, flag_wrapv))
+ || (opt_for_fn (e-caller-decl, flag_trapv)
+ != opt_for_fn (e-caller-decl, flag_trapv))
+ /* Strictly speaking only when the callee contains memory
+accesses that are not using alias-set zero anyway. */
+ || (opt_for_fn (e-caller-decl, flag_strict_aliasing)
+ != opt_for_fn (e-caller-decl, flag_strict_aliasing))
+ /* Strictly speaking only when the callee uses FP math. */
+ || (opt_for_fn (e-caller-decl, flag_rounding_math)
+ != opt_for_fn (e-caller-decl, flag_rounding_math))
+ || (opt_for_fn (e-caller-decl, flag_trapping_math)
+ != opt_for_fn (e-caller-decl, flag_trapping_math))
+ || (opt_for_fn (e-caller-decl, flag_unsafe_math_optimizations)
+ != opt_for_fn (e-caller-decl, flag_unsafe_math_optimizations))
+ || (opt_for_fn (e-caller-decl, flag_finite_math_only)
+ != opt_for_fn (e-caller-decl, flag_finite_math_only))
+ || (opt_for_fn (e-caller-decl, flag_signaling_nans)
+ != opt_for_fn (e-caller-decl, flag_signaling_nans))
+ || (opt_for_fn (e-caller-decl, flag_cx_limited_range)
+ != opt_for_fn (e-caller-decl, flag_cx_limited_range))
+ || (opt_for_fn (e-caller-decl, flag_signed_zeros)
+ != opt_for_fn (e-caller-decl, flag_signed_zeros))
+ || (opt_for_fn (e-caller-decl, flag_associative_math)
+ != opt_for_fn (e-caller-decl, flag_associative_math))
+ || (opt_for_fn (e-caller-decl, flag_reciprocal_math)
+ != opt_for_fn (e-caller-decl, flag_reciprocal_math))
+ /* Strictly speaking only when the callee contains function
+calls that may end up setting errno. */
+ || (opt_for_fn (e-caller-decl, flag_errno_math)
+ != opt_for_fn (e-caller-decl, flag_errno_math)))
+ {
+ e-inline_failed = CIF_OPTIMIZATION_MISMATCH;
+ inlinable = false;
+ }
+ /* gcc.dg/pr43564.c. Apply user-forced inline even at -O0. */
+ else if (DECL_DISREGARD_INLINE_LIMITS (callee-decl)
+ lookup_attribute (always_inline,
+ DECL_ATTRIBUTES (callee-decl)))
;
- /* When user added an attribute, honnor it. */
- else if ((lookup_attribute (optimize, DECL_ATTRIBUTES (caller-decl))
- || lookup_attribute (optimize,
-DECL_ATTRIBUTES (callee-decl)))
- ((opt_for_fn (caller-decl, optimize)
- opt_for_fn (callee-decl, optimize))
- || (opt_for_fn (caller-decl, optimize_size)
- != opt_for_fn (callee-decl, optimize_size
+ /* When user added an attribute to the callee honor it. */
+ else if (lookup_attribute (optimize, DECL_ATTRIBUTES (callee-decl))
+ opts_for_fn (caller-decl) != opts_for_fn (callee-decl))
{
e-inline_failed = CIF_OPTIMIZATION_MISMATCH;
inlinable = false;
[libcpp PATCH] Resolve DR#412 - unevaluated #elif (PR preprocessor/60570)
As discussed in the PR, this patch partially reverts Tom's change
in r136209. (The is_if argument to _cpp_parse_expr is kept for the
sake of diagnostics.)
The change made sense at that time, but now we have DR#412 resolved.
This DR deals with the case where we have an #elif conditional that
doesn't have to be evaluated:
#if 1
int i;
#elif 1/0
#endif
and this DR says that such #elifs should be skipped.
This change is deliberately not conditioned on any standard version.
Jason, Joseph, does it make sense to put this into GCC 5, or should it wait
for GCC 6? Since this change makes the preprocessor more permissive, it
should hurt nobody.
Bootstrapped/regtested on x86_64-linux, ok for trunk?
2015-01-22 Marek Polacek pola...@redhat.com
DR#412
PR preprocessor/60570
* directives.c (do_elif): Don't evaluate #elif conditionals
when they don't need to be.
* gcc.dg/cpp/pr36320.c: Turn dg-error into dg-bogus.
* gcc.dg/cpp/pr60570.c: New test.
diff --git gcc/gcc/testsuite/gcc.dg/cpp/pr36320.c
gcc/gcc/testsuite/gcc.dg/cpp/pr36320.c
index d136a69..cc2baa7 100644
--- gcc/gcc/testsuite/gcc.dg/cpp/pr36320.c
+++ gcc/gcc/testsuite/gcc.dg/cpp/pr36320.c
@@ -1,8 +1,8 @@
/* PR 36320 - #elif still requires valid expression. */
-
+/* DR#412: #elif doesn't have to be valid expression (PR60570). */
/* { dg-do preprocess } */
int z;
#if 1
-#elif /* { dg-error with no expression } */
+#elif /* { dg-bogus with no expression } */
#endif
diff --git gcc/gcc/testsuite/gcc.dg/cpp/pr60570.c
gcc/gcc/testsuite/gcc.dg/cpp/pr60570.c
index e69de29..4755206 100644
--- gcc/gcc/testsuite/gcc.dg/cpp/pr60570.c
+++ gcc/gcc/testsuite/gcc.dg/cpp/pr60570.c
@@ -0,0 +1,48 @@
+/* PR preprocessor/60570 */
+/* { dg-do preprocess } */
+
+#if 1
+int i;
+#elif 1/0
+#endif
+
+#if 1
+int j;
+#elif
+#endif
+
+#if 0
+#elif 1/0 /* { dg-error division by zero } */
+int k;
+#endif
+
+#if 0
+#elif /* { dg-error with no expression } */
+int n;
+#endif
+
+#if 1
+# if 1
+int l;
+# elif 1/0
+# endif
+#endif
+
+#if 1
+# if 1
+int l;
+# elif
+# endif
+#endif
+
+#if 1
+# if 0
+# elif 1/0 /* { dg-error division by zero } */
+# endif
+#endif
+
+#if 1
+# if 0
+# elif /* { dg-error with no expression } */
+# endif
+#endif
diff --git gcc/libcpp/directives.c gcc/libcpp/directives.c
index ab4f15c..37cd109 100644
--- gcc/libcpp/directives.c
+++ gcc/libcpp/directives.c
@@ -2036,23 +2036,16 @@ do_elif (cpp_reader *pfile)
}
ifs-type = T_ELIF;
- if (! ifs-was_skipping)
+ /* See DR#412: Only the first group whose control condition
+evaluates to true (nonzero) is processed; any following groups
+are skipped and their controlling directives are processed as
+if they were in a group that is skipped. */
+ if (ifs-skip_elses)
+ pfile-state.skipping = 1;
+ else
{
- bool value;
- /* The standard mandates that the expression be parsed even
-if we are skipping elses at this point -- the lexical
-restrictions on #elif only apply to skipped groups, but
-this group is not being skipped. Temporarily set
-skipping to false to get lexer warnings. */
- pfile-state.skipping = 0;
- value = _cpp_parse_expr (pfile, false);
- if (ifs-skip_elses)
- pfile-state.skipping = 1;
- else
- {
- pfile-state.skipping = ! value;
- ifs-skip_elses = value;
- }
+ pfile-state.skipping = ! _cpp_parse_expr (pfile, false);
+ ifs-skip_elses = ! pfile-state.skipping;
}
/* Invalidate any controlling macro. */
Marek
Re: [PATCH] Fix inlining checks wrt optimize attribute
On Thu, 22 Jan 2015, Christian Bruel wrote:
Hi Richard,
I thought one of my current issue would be solved by this patch, but it is not
: I have some inlining failures with the attribute target on ARM. (e.g
inline-3.c) where obvious early inline fails with because we fail into the
last can_inline_edge_p case:
opt_for_fn (callee-decl, optimize)
= opt_for_fn (caller-decl, optimize)))
when callee and caller are both -O2 and targetm.target_option.can_inline_p was
true, they should be inlined as in the general case (no
DECL_FUNCTION_SPECIFIC_OPTIMIZATION)
I'm currently testing this additional change:
Index: ipa-inline.c
===
--- ipa-inline.c (revision 219989)
+++ ipa-inline.c (working copy)
@@ -489,7 +489,7 @@
else if (opt_for_fn (callee-decl, optimize_size)
opt_for_fn (caller-decl, optimize_size)
|| (opt_for_fn (callee-decl, optimize)
-= opt_for_fn (caller-decl, optimize)))
+ opt_for_fn (caller-decl, optimize)))
{
if (estimate_edge_time (e)
= 20 + inline_edge_summary (e)-call_stmt_time)
Since this is a hot topic for you, I though you would have useful comments on
this before I ask for a commit (when stage 4 close) ?
Yeah - the above looks like an obvious change to me. Thus,
approved if it passes bootstrap/regtest.
Thanks,
Richard.
Cheers
Christian
On 01/22/2015 10:24 AM, Richard Biener wrote:
As said in the other thread - this makes sure we don't perform inlining
that might end up generating invalid code. It also preserves
user-provided optimize attributes more properly.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
Richard.
2015-01-22 Richard Biener rguent...@suse.de
* ipa-inline.c (can_inline_edge_p): Disable inlining of edges
with IL incompatible options. Properly honor user optimize
attributes.
Index: gcc/ipa-inline.c
===
--- gcc/ipa-inline.c(revision 219929)
+++ gcc/ipa-inline.c(working copy)
@@ -404,17 +404,56 @@ can_inline_edge_p (struct cgraph_edge *e
optimization attribute. */
else if (caller_tree != callee_tree)
{
- /* gcc.dg/pr43564.c. Look at forced inline even in -O0. */
- if (DECL_DISREGARD_INLINE_LIMITS (callee-decl))
+ /* There are some options that change IL semantics which means
+ we cannot inline in these cases for correctness reason.
+Not even for always_inline declared functions. */
+ /* Strictly speaking only when the callee contains signed integer
+ math where overflow is undefined. */
+ if ((opt_for_fn (e-caller-decl, flag_strict_overflow)
+ != opt_for_fn (e-caller-decl, flag_strict_overflow))
+ || (opt_for_fn (e-caller-decl, flag_wrapv)
+ != opt_for_fn (e-caller-decl, flag_wrapv))
+ || (opt_for_fn (e-caller-decl, flag_trapv)
+ != opt_for_fn (e-caller-decl, flag_trapv))
+ /* Strictly speaking only when the callee contains memory
+accesses that are not using alias-set zero anyway. */
+ || (opt_for_fn (e-caller-decl, flag_strict_aliasing)
+ != opt_for_fn (e-caller-decl, flag_strict_aliasing))
+ /* Strictly speaking only when the callee uses FP math. */
+ || (opt_for_fn (e-caller-decl, flag_rounding_math)
+ != opt_for_fn (e-caller-decl, flag_rounding_math))
+ || (opt_for_fn (e-caller-decl, flag_trapping_math)
+ != opt_for_fn (e-caller-decl, flag_trapping_math))
+ || (opt_for_fn (e-caller-decl, flag_unsafe_math_optimizations)
+ != opt_for_fn (e-caller-decl, flag_unsafe_math_optimizations))
+ || (opt_for_fn (e-caller-decl, flag_finite_math_only)
+ != opt_for_fn (e-caller-decl, flag_finite_math_only))
+ || (opt_for_fn (e-caller-decl, flag_signaling_nans)
+ != opt_for_fn (e-caller-decl, flag_signaling_nans))
+ || (opt_for_fn (e-caller-decl, flag_cx_limited_range)
+ != opt_for_fn (e-caller-decl, flag_cx_limited_range))
+ || (opt_for_fn (e-caller-decl, flag_signed_zeros)
+ != opt_for_fn (e-caller-decl, flag_signed_zeros))
+ || (opt_for_fn (e-caller-decl, flag_associative_math)
+ != opt_for_fn (e-caller-decl, flag_associative_math))
+ || (opt_for_fn (e-caller-decl, flag_reciprocal_math)
+ != opt_for_fn (e-caller-decl, flag_reciprocal_math))
+ /* Strictly speaking only when the callee contains function
+calls that may end up setting errno. */
+ || (opt_for_fn (e-caller-decl, flag_errno_math)
+ != opt_for_fn (e-caller-decl, flag_errno_math)))
+ {
+ e-inline_failed = CIF_OPTIMIZATION_MISMATCH;
+ inlinable = false;
+ }
+ /*
Re: [wwwdocs] Mention ipa-ICF and auto-FDO
On 21 January 2015 at 22:58, Jan Hubicka hubi...@ucw.cz wrote: Hi, these two rather noticeable features are not mentioned. Honza Index: changes.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-5/changes.html,v retrieving revision 1.69 diff -u -r1.69 changes.html --- changes.html20 Jan 2015 16:37:54 - 1.69 +++ changes.html21 Jan 2015 21:57:30 - @@ -35,7 +35,15 @@ ul liInter-procedural optimization improvements: ul - liThe devirtualization pass was significantly improved by adding + liNew identical code folding pass (controled via code-fipa-icf/code). s/controled/controlled/g thanks,
Re: [wwwdocs] Mention ipa-ICF and auto-FDO
Hi Honza, On 21/01/15 21:58, Jan Hubicka wrote: Hi, these two rather noticeable features are not mentioned. Honza Index: changes.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-5/changes.html,v retrieving revision 1.69 diff -u -r1.69 changes.html --- changes.html20 Jan 2015 16:37:54 - 1.69 +++ changes.html21 Jan 2015 21:57:30 - @@ -35,7 +35,15 @@ ul liInter-procedural optimization improvements: ul - liThe devirtualization pass was significantly improved by adding + liNew identical code folding pass (controled via code-fipa-icf/code). +Compared to the identical code folding performed by Gold linker this +pass does not require function sections. It also performs merging +pre-inline so inter-procedural optimizations are aware of the +code re-use. On the other hand not all unifications performed +by linker are doable by GCC pass; the GCC pass must honnor s/honnor/honor/ +aliasing information. During link-time optimization of Firefox, +the pass unify about 29000 functions that is 10% overall/li I think it should be unifies about 29000... + liDevirtualization pass was significantly improved by adding better support for speculative devirtualization and dynamic type detection. About 50% of virtual calls in Firefox are speculatively devirtualized during link-time optimization./li @@ -72,6 +80,11 @@ /ul/li liFeedback directed optimization improvements: ul + liNew auto-FDO mode that use profiles collected by low overhead s/use/uses/ Cheers, Kyrill + profiling tools (perf) instead of more expensive program + instrumentation (via code-fprofile-generate/code). SPEC2006 + benchmarks improve by 4.7% with auto-FDO and by 7.3% with + traditional feedback directed optimization. liProfile precision was improved in presence of C++ inline and extern inline functions./li liNew codegcov-tool/code to manipulate profiles./li
Re: [PATCH] PR 64722: fix corruption of %ebx on 32-bit i386 with libgccjit
On 01/22/2015 09:34 AM, David Malcolm wrote: gcc/ChangeLog: PR 64722 * emit-rtl.c (init_emit_regs): Set pic_offset_table_rtx to NULL_RTX before testing PIC_OFFSET_TABLE_REGNUM, since the latter may be affected by the former (e.g. on i686). Ok. r~
Re: [PATCH 0/4][ARM Intrinsics][RFTesting] Add missing float16x8_t type, and float16x[48] intrinsics
Thanks, Christophe - that's helpful, I'm getting a few tests working now. Ramana/Richard, any thoughts on which way you'd like to add the float16 tests, with preprocessor directives (I believe the relevant is #if __ARM_FP 2) or in separate files=Dejagnu testcases? Thanks, Alan Christophe Lyon wrote: On 16 January 2015 at 18:22, Alan Lawrence alan.lawre...@arm.com wrote: These add all the V[48]HFmode insns and corresponding intrinsics for ARM. Depends on the two patches at https://gcc.gnu.org/ml/gcc-patches/2015-01/msg01422.html . Unfortunately I don't at present have a testsuite. I've done some testing both manually and on a large internal testsuite for Neon/ACLE intrinsics, but I'm wondering if anyone has anything they might be able to contribute? Christophe, perhaps you can give me some pointers, how might one add float16 to the advsimd-intrinsics testsuite / how easy would this be? I don't expect this to be difficult. I have some support already in my testsuite at https://gitorious.org/arm-neon-tests For instance, if you look at ref_vld1.c, you'll that GCC's vld1.c test needs to have something like: #if defined(__ARM_FP16_FORMAT_IEEE) DECL_VARIABLE(vector, float, 16, 4); DECL_VARIABLE(vector, float, 16, 8); #endif ... #if defined(__ARM_FP16_FORMAT_IEEE) TEST_VLD1(vector, buffer, , float, f, 16, 4); TEST_VLD1(vector, buffer, q, float, f, 16, 8); #endif as well as a similar fragment with the expected results. I didn't add it yet because I was waiting for the support in GCC to be complete :-) I discussed this briefly with Ramana when I started contributing my tests. However, it might be better to add such tests in a dedicated file (e.g. vld1-fp16.c) protected by some dejagnu directive to check that the effective target does support fp16, and without the #ifdef. Cross-tested check-gcc on arm-none-eabi Bootstrapped on arm-none-linux-gnueabihf cortex-a15 Christophe.
Re: [PATCH, i386] Fix PR 64688, ICE: Max. number of generated reload insns per insn is achieved (90)
On Thu, Jan 22, 2015 at 3:41 PM, Uros Bizjak ubiz...@gmail.com wrote: Attached patch fixes PR 64688. Operand constraints were wrong for reg-to-vec targets. The patch also fixes PR 64477. Whoops, I have regtested wrong compiler. The patch introduced some AVX2 regressions. Following patch is also needed, otherwise vec_dup post-reload splitter creates invalid pattern that involves general reg for reg-to-vec targets. --cut here-- Index: config/i386/sse.md === --- config/i386/sse.md (revision 220004) +++ config/i386/sse.md (working copy) @@ -16711,7 +16711,7 @@ [V32QI V16QI V16HI V8HI V8SI V4SI]) (define_insn *vec_dupmode - [(set (match_operand:AVX2_VEC_DUP_MODE 0 register_operand =x,x,x) + [(set (match_operand:AVX2_VEC_DUP_MODE 0 register_operand =x,x,Yi) (vec_duplicate:AVX2_VEC_DUP_MODE (match_operand:ssescalarmode 1 nonimmediate_operand m,x,$r)))] TARGET_AVX2 --cut here-- Sorry for the breakage, will be fixed ASAP. Uros.
Re: [PATCH] Don't check for optab for 16bit bswap
On 01/21/2015 11:52 PM, Richard Biener wrote: On January 21, 2015 10:23:56 PM CET, Richard Henderson r...@redhat.com wrote: On 12/29/2014 06:04 AM, Thomas Preud'homme wrote: Since 16bit byteswap can be done via an 8 bit rotation (and it is the canonical form), the check for an optab only serves to prevent the bswap optimization for targets that don't have a 16bit byteswap (but do have a rotation instruction). See PR63259 (comments 6 and onwards) for more details. I question the choice to have rotate be the canonical form. Doesn't this make things more complicated for targets that don't have rotate? Or, equivalently, no 16-bit rotate? That would seem to cover 99% of all 32-bit risc machines. I was asking for the generic expander to consider bswapHI. Rotates are certainly more likely to get combined with sth else. Maybe. Alternately, don't we canonicalize byte-swapping memory ops as (set (reg:HI) (bswap:HI (mem:HI))) (set (mem:HI) (bswap:HI (reg:HI))) Certainly this is true for powerpc. (It appears that both sparc and s390 are missing similar patterns, despite having instructions that can perform this operation...) r~ r~
Re: [PATCH PR64557] get_addr in true_dependence_1 cannot handle VALUE inside an expr
On Thu, Jan 22, 2015 at 7:04 PM, Jeff Law l...@redhat.com wrote: Thanks for the review. Comments addressed and patch committed. The problem exists on gcc-4_9 too. Is it ok for gcc-4_9-branch? Will wait another day to commit it to gcc-4_9 if it is ok. Yes, if the patch from Uros was backported to 4.9, then this patch should get backported as well. The failure mode if this bug gets triggered will likely be hard to identify, so I'd rather not have to do that :-) Thanks also from my side. I have to say to my defense, that my patch patched horrible bitrotten code that unnecessarily marked many operands as aliasing. The patches were extensively tested and I hope that this was the only fallout. Uros.
Re: [PATCH] pr 63325 - make fold ignore decl_with_vis.symtab_node
On Thu, Jan 22, 2015 at 06:02:06AM -0500, tbsaunde+...@tbsaunde.org wrote:
From: Trevor Saunders tbsaunde+...@tbsaunde.org
Hi,
fold calls symtab_node::get_create () which can change this field from NULL to
point to a new object. It doesn't seem to really matter when the object gets
created and I don't think it changes any properties of the tree object. So I
think it makes sense to do here what we do for similar members and leave it
out
of the checksum.
bootstrapped + regtested x86_64-linux-gnu, ok?
Trev
gcc/
* fold-const.c (fold_checksum_tree): Don't include
expr.decl_with_vis.symtab_node in the checksum.
Ok, thanks.
--- a/gcc/fold-const.c
+++ b/gcc/fold-const.c
@@ -14065,11 +14065,12 @@ fold_checksum_tree (const_tree expr, struct md5_ctx
*ctx,
*slot = expr;
code = TREE_CODE (expr);
if (TREE_CODE_CLASS (code) == tcc_declaration
- DECL_ASSEMBLER_NAME_SET_P (expr))
+ HAS_DECL_ASSEMBLER_NAME_P (expr))
{
- /* Allow DECL_ASSEMBLER_NAME to be modified. */
+ /* Allow DECL_ASSEMBLER_NAME and symtab_node to be modified. */
memcpy ((char *) buf, expr, tree_size (expr));
SET_DECL_ASSEMBLER_NAME ((tree)buf, NULL);
+ buf.decl_with_vis.symtab_node = NULL;
Wonder why we don't have an accessor macro for this in tree.h.
decl_with_vis is implementation detail.
Jakub
Re: [[ARM/AArch64][testsuite] 03/36] Add vmax, vmin, vhadd, vhsub and vrhadd tests.
On 21/01/15 15:07, Christophe Lyon wrote: On 19 January 2015 at 17:54, Marcus Shawcroft marcus.shawcr...@gmail.com wrote: On 19 January 2015 at 15:43, Christophe Lyon christophe.l...@linaro.org wrote: On 19 January 2015 at 14:29, Marcus Shawcroft marcus.shawcr...@gmail.com wrote: On 16 January 2015 at 17:52, Christophe Lyon christophe.l...@linaro.org wrote: OK provided, as per the previous couple, that we don;t regression or introduce new fails on aarch64[_be] or aarch32. This patch shows failures on aarch64 and aarch64_be for vmax and vmin when the input is -NaN. It's a corner case, and my reading of the ARM ARM is that the result should the same as on aarch32. I haven't had time to look at it in more details though. So, not OK? They should have the same behaviour in aarch32 and aarch64. Did you test on HW or a model? I ran the tests on qemu for aarch32 and aarch64-linux, and on the foundation model for aarch64*-elf. Leave this one out until we understand why it fails. /Marcus I've looked at this a bit more. We have fmaxv0.4s, v0.4s, v1.4s where v0 is a vector of -NaN (0xffc0) and v1 is a vector of 1. The output is still -NaN (0xffc0), while the test expects defaultNaN (0x7fc0). In the AArch32 execution state, Advanced SIMD FP arithmetic always uses the DefaultNaN setting regardless of the DN-bit value in the FPSCR. In AArch64 execution state, result of Advanced SIMD FP arithmetic operations depend on the value of the DN-bit i.e. either propagate the input NaN or generate DefaultNaN depending on the value of DN. If you're running your test in the AArch64 execution state, you'd want to define the DN bit and modify the expected results accordingly or have the test poll at runtime what the DN-bit is set to and check expected results dynamically. I think the test already has expected behaviour for AArch32 execution state by expecting DefaultNaN regardless. I have executed the test under GDB on AArch64 HW, and noticed that fpcr was 0. I forced it to have DN==1: set $fpcr=0x100 but this didn't change the result. Does setting fpcr.dn under gdb actually work? It should. Possibly a bug, patches welcome :-). Tejas.
Re: [PATCH] libgcc: unwind-dw2-fde.h: Use (const fde *) instead of (char *) to avoid qualifier warning
On 01/22/15 06:32, Chen Gang S wrote: 2014-10-07 Chen Ganggang.chen.5...@gmail.com * unwind-dw2-fde.h (last_fde): Use (const fde *) instead of (char *) to avoid qualifier warning by 'xgcc' compiling. Patch applied on your behalf. Thanks, Jeff
[ping] Re: [patch, rfc] fix warning building libssp in C11 mode
ping now that C11 mode is the default, can we avoid the warning? On 10/17/2014 12:14 PM, Matthias Klose wrote: Building libssp in C11 mode shows a warning for 64bit configurations, ../../../src/libssp/gets-chk.c:62:12: warning: return makes pointer from integer without a cast [-Wint-conversion] Currently working around by adding a prototype in gets-chk.c, conditionally defined by the inverted condition found in glibc's stdio.h. Is there a better approach? Matthias
[PATCH] Fix PR64728
The following fixes PR64728 - with the change to aggressively
propagate uninitialized abnormal SSA names we have to avoid
coalescing that with anything (we'll just expand it to whatever
the rest of the args was coalesced with).
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
Richard.
2015-01-22 Richard Biener rguent...@suse.de
PR middle-end/64728
* tree-ssa-coalesce.c (coalesce_partitions): Do not perform
abnormal coalescing on undefined SSA names.
* gcc.dg/torture/pr64728.c: New testcase.
Index: gcc/testsuite/gcc.dg/torture/pr64728.c
===
--- gcc/testsuite/gcc.dg/torture/pr64728.c (revision 0)
+++ gcc/testsuite/gcc.dg/torture/pr64728.c (working copy)
@@ -0,0 +1,27 @@
+/* { dg-do compile } */
+
+#include setjmp.h
+
+jmp_buf a;
+int b, d;
+void baz (long);
+
+static void
+bar (long *x)
+{
+ if (d)
+*x = b;
+}
+
+void
+foo ()
+{
+ baz (0);
+ if (setjmp (a))
+{
+ long c;
+ bar (c);
+ baz (c);
+}
+ baz (0);
+}
Index: gcc/tree-ssa-coalesce.c
===
--- gcc/tree-ssa-coalesce.c (revision 219994)
+++ gcc/tree-ssa-coalesce.c (working copy)
@@ -1213,8 +1213,13 @@ coalesce_partitions (var_map map, ssa_co
gsi_next (gsi))
{
gphi *phi = gsi.phi ();
+ tree arg = PHI_ARG_DEF (phi, e-dest_idx);
+ if (SSA_NAME_IS_DEFAULT_DEF (arg)
+(!SSA_NAME_VAR (arg)
+ || TREE_CODE (SSA_NAME_VAR (arg)) != PARM_DECL))
+ continue;
+
tree res = PHI_RESULT (phi);
- tree arg = PHI_ARG_DEF (phi, e-dest_idx);
int v1 = SSA_NAME_VERSION (res);
int v2 = SSA_NAME_VERSION (arg);
Re: [patch, libobjc] export __objc_get_forward_imp, get_imp again
On 01/22/2015 12:56 AM, Andrew Pinski wrote:
On Wed, Jan 21, 2015 at 8:51 AM, Jakub Jelinek ja...@redhat.com wrote:
On Wed, Jan 21, 2015 at 08:41:46AM -0800, pins...@gmail.com wrote:
On Jan 21, 2015, at 1:02 AM, Matthias Klose d...@ubuntu.com wrote:
__objc_get_forward_imp and get_imp were exported in libobjc since GCC 4.1,
for
some reason these are not exported anymore in GCC 5 (both declared
inline). So
either export these as before, or don't export them and bump the soname.
The
latter seems to be unwanted, and at least gnustep-base is using the get_imp
function. So better keep the references in GCC 5?
Is this an intended change in GCC 5 to not to export inline methods
anymore?
Just remove the inline instead.
The comments like:
/* The new name of get_imp(). */
IMP
class_getMethodImplementation (Class class_, SEL selector)
{
if (class_ == Nil || selector == NULL)
return NULL;
/* get_imp is inlined, so we're good. */
return get_imp (class_, selector);
}
don't make me very confident in such a change.
The extern prototypes really work with both -std=gnu89 and -std=gnu11 and
thus will at least keep status quo.
Let's do that then.
get_imp was renamed to class_getMethodImplementation, which is exported from
objc/runtime.h. GNUstep-base uses get_imp to define it's own
class_getMethodImplementation, so get_imp isn't really needed. So either make
the two functions inline, and don't export them, or declare the prototypes. For
the latter I would suggest objc-private/runtime.h (class_getMethodImplementation
is declared in objc/runtime.h).
Matthias
[patch] Do not call const_binop on MEM_EXPR
Hi,
const_binop is now invoked on MEM_EXPR, which doesn't make much sense given
the assertion at the end:
/* Make sure type and arg0 have the same saturating flag. */
gcc_checking_assert (TYPE_SATURATING (type)
== TYPE_SATURATING (TREE_TYPE (arg1)));
Tested on x86_64-suse-linux, OK for the mainline?
2015-01-22 Eric Botcazou ebotca...@adacore.com
* fold-const.c (fold_binary_loc): Do not call const_binop on MEM_REF.
--
Eric BotcazouIndex: fold-const.c
===
--- fold-const.c (revision 219928)
+++ fold-const.c (working copy)
@@ -9884,7 +9884,7 @@ fold_binary_loc (location_t loc,
/* Note that TREE_CONSTANT isn't enough: static var addresses are
constant but we can't do arithmetic on them. */
- if (CONSTANT_CLASS_P (arg0) CONSTANT_CLASS_P (arg1))
+ if (code != MEM_REF CONSTANT_CLASS_P (arg0) CONSTANT_CLASS_P (arg1))
{
tem = const_binop (code, type, arg0, arg1);
if (tem != NULL_TREE)
Re: [PATCH v3] gcc/ubsan.c: Use 'pretty_print' for 'pretty_name' to avoid memory overflow
On 01/22/15 06:15, Chen Gang S wrote: On 11/24/2014 04:24 PM, Jakub Jelinek wrote: On Mon, Nov 24, 2014 at 04:28:10PM +0800, Chen Gang wrote: On 11/24/14 15:41, Jakub Jelinek wrote: On Sun, Nov 23, 2014 at 09:13:27AM +0800, Chen Gang wrote: [...] + else + pp_wide_int(pretty_name, + wi::add (wi::to_widest (TYPE_MAX_VALUE (dom)), 1), + TYPE_SIGN (TREE_TYPE (dom))); Space still missing before ( (and reindenting the following 2 lines). Oh, thanks, if necessary to send patch v4, please let me know. No, just fix it up before checking in. Hello Maintainers: At present, I don’t have write access yet nor is my paperwork compete, could someone help install it for me? I fixed the formatting nit Jakub pointed out and installed the patch on your behalf. Thanks, Jeff
Re: [patch] Do not call const_binop on MEM_EXPR
On Thu, Jan 22, 2015 at 3:36 PM, Eric Botcazou ebotca...@adacore.com wrote: Hi, const_binop is now invoked on MEM_EXPR, which doesn't make much sense given the assertion at the end: /* Make sure type and arg0 have the same saturating flag. */ gcc_checking_assert (TYPE_SATURATING (type) == TYPE_SATURATING (TREE_TYPE (arg1))); Tested on x86_64-suse-linux, OK for the mainline? I'd prefer a if (TREE_CODE_CLASS (code) != tcc_binary) return NULL_TREE; before the above assert. That matches what the code did before my reorg. Ok with that change. Thanks, Richard. 2015-01-22 Eric Botcazou ebotca...@adacore.com * fold-const.c (fold_binary_loc): Do not call const_binop on MEM_REF. -- Eric Botcazou
Re: [PING] : [RFC] Tighten memory type assumption in RTL combiner pass.
On Thu, Jan 22, 2015 at 07:29:28PM +0530, Venkataramanan Kumar wrote: ping. Segher do you any comments from your side. I agree combine should not transform shifts into multiplication (except in addresses, where it is canonical). I haven't looked at the actual patch in detail though, it will have to wait until stage1, it is not fixing a regression and it affects all targets. Segher
Re: [[ARM/AArch64][testsuite] 05/36] Add vldX_dup test.
LGTM. Thanks, I should mention that this test fails on aarch64_be, because of pending Alan's patches. A few big-endian fixes were checked in last night. Do you mean this? r219957 | rsandifo | 2015-01-21 17:53:04 + (Wed, 21 Jan 2015) | 6 lines gcc/ 2015-01-25 Alan Hayward alan.hayw...@arm.com * rtlanal.c (subreg_get_info): Exit early for simple and common cases. Thanks, Tejas.
Re: [[ARM/AArch64][testsuite] 03/36] Add vmax, vmin, vhadd, vhsub and vrhadd tests.
On 22 January 2015 at 16:22, Tejas Belagod tejas.bela...@arm.com wrote: On 22/01/15 14:28, Christophe Lyon wrote: On 22 January 2015 at 12:19, Tejas Belagod tejas.bela...@arm.com wrote: On 21/01/15 15:07, Christophe Lyon wrote: On 19 January 2015 at 17:54, Marcus Shawcroft marcus.shawcr...@gmail.com wrote: On 19 January 2015 at 15:43, Christophe Lyon christophe.l...@linaro.org wrote: On 19 January 2015 at 14:29, Marcus Shawcroft marcus.shawcr...@gmail.com wrote: On 16 January 2015 at 17:52, Christophe Lyon christophe.l...@linaro.org wrote: OK provided, as per the previous couple, that we don;t regression or introduce new fails on aarch64[_be] or aarch32. This patch shows failures on aarch64 and aarch64_be for vmax and vmin when the input is -NaN. It's a corner case, and my reading of the ARM ARM is that the result should the same as on aarch32. I haven't had time to look at it in more details though. So, not OK? They should have the same behaviour in aarch32 and aarch64. Did you test on HW or a model? I ran the tests on qemu for aarch32 and aarch64-linux, and on the foundation model for aarch64*-elf. Leave this one out until we understand why it fails. /Marcus I've looked at this a bit more. We have fmaxv0.4s, v0.4s, v1.4s where v0 is a vector of -NaN (0xffc0) and v1 is a vector of 1. The output is still -NaN (0xffc0), while the test expects defaultNaN (0x7fc0). In the AArch32 execution state, Advanced SIMD FP arithmetic always uses the DefaultNaN setting regardless of the DN-bit value in the FPSCR. In AArch64 execution state, result of Advanced SIMD FP arithmetic operations depend on the value of the DN-bit i.e. either propagate the input NaN or generate DefaultNaN depending on the value of DN. Maybe I'm using an outdated doc. On page 2282 of ARMv8 ARM rev C, I can see only the latter (no diff between aarch32 and aarch64 in FPProcessNan pseudo-code) If you see pg. 4005 in the same doc(rev C), you'll see the FPSCR spec - under DN: The value of this bit only controls scalar floating-point arithmetic. Advanced SIMD arithmetic always uses the Default NaN setting, regardless of the value of the DN bit. Also on page 3180 for the description of VMAX(vector FP), it says: * max(+0.0, -0.0) = +0.0 * If any input is a NaN, the corresponding result element is the default NaN. Oops I was looking at FMAX (vector) pg 936. The pseudocode for FPMax () on pg. 3180 passes StandardFPSCRValue() to FPMax() which is on pg. 2285 // StandardFPSCRValue() // FPCRType StandardFPSCRValue() return ‘0’ : FPSCR.AHP : ‘11’ Here bit-25(FPSCR.DN) is set to 1. So, we should get defaultNaN too on aarch64, and no need to try to force DN to 1 in gdb? What can be wrong? Thanks, Tejas. If you're running your test in the AArch64 execution state, you'd want to define the DN bit and modify the expected results accordingly or have the test poll at runtime what the DN-bit is set to and check expected results dynamically. Makes sense, I hadn't noticed the different aarch64 spec here. I think the test already has expected behaviour for AArch32 execution state by expecting DefaultNaN regardless. Yes. I have executed the test under GDB on AArch64 HW, and noticed that fpcr was 0. I forced it to have DN==1: set $fpcr=0x100 but this didn't change the result. Does setting fpcr.dn under gdb actually work? It should. Possibly a bug, patches welcome :-). :-)
Re: [PATCH: toplev.c] PR jit/64721: don't install signal-handlers when running within libgccjit
On Wed, Jan 21, 2015 at 05:44:03PM -0500, David Malcolm wrote: Don't install signal handlers in toplev.c if we're called from libgccjit, only install them if we're called from main.c, thus avoiding touching process-wide state from a shared library (see the PR for details of how this is currently leading to SIGSEGV on errors in make check-jit). Is this one sufficiently obvious to still be applicable in stage 4? (assuming bootstrap?) gcc/ChangeLog: PR jit/64721 * main.c (main): Construct toplev instances with init_signals=true. * toplev.c (general_init): Add param init_signals, and use it to conditionalize the calls to signal and host_hooks.extra_signals. (toplev::toplev): Add param init_signals. (toplev::main): When invoking general_init, pass m_init_signals to control whether signal-handlers are installed. * toplev.h (toplev::toplev): Add param init_signals. (toplev::m_init_signals): New field. gcc/jit/ChangeLog: PR jit/64721 * jit-playback.c (gcc::jit::playback::context::compile): Construct toplev instances with init_signals=false. Ok for stage4. Jakub
Re: [Patch, Fortran] PR64726 Fix OpenACC's parallel/kernel loop
On 01/22/2015 12:08 PM, Tobias Burnus wrote: parallel/kernel loop is handled by the function being patched (an assert ensures that no other directives end here). The first part of the function handles the parallel and kernel part, the loop itself should be handled by the called function. However, it currently passes the kernel/parallel loop op on, instead of only the loop part. That fails in the called function in an assert. Build and regtested on x86-64-gnu-linux. OK for the trunk? It looks OK to me. In fact, I have an identical patch in our internal branch and I don't know why it didn't make its way upstream or at least into gomp-4_0-branch. Maybe it got lost after stage 1 closed. Sorry about that. Cesar
[SH] [libstdc++] Workaround for PR 29366
Hi,
The attached patch is a temporary workaround for PR 29366. We've been
having support for various atomics on SH for a while, but libstdc++'s
configury makes it impossible to use when doing a cross build (PR
53579). Even if that worked, if I'm not mistaken,
config/cpu/sh/atomicity.h overrides all of that and replaces it with its
own SH4A atomics or a lock based implementation for everything non-SH4A.
The patch works OK on sh-elf, and as far as I can see there should be no
problems on sh*-linux configs, too. I will commit the patch if there
are no objections in 48h.
Cheers,
Oleg
libstdc++-v4/ChangeLog:
PR target/29366
* config/cpu/sh/atomicity.h (__exchange_and_add, __atomic_add):
Remove SH4A inline asm and lock based implementations and use
the defaults from ext/atomicity.h.
Index: libstdc++-v3/config/cpu/sh/atomicity.h
===
--- libstdc++-v3/config/cpu/sh/atomicity.h (revision 219824)
+++ libstdc++-v3/config/cpu/sh/atomicity.h (working copy)
@@ -22,87 +22,14 @@
// see the files COPYING3 and COPYING.RUNTIME respectively. If not, see
// http://www.gnu.org/licenses/.
-#ifdef __SH4A__
+// Use the default atomicity stuff, which will use __atomic* builtins
+// if threads are available, or the *_single functions on single-thread
+// configurations.
+// Actually we wouldn't need this header at all, but because of PR 53579
+// libstdc++'s configury will not pickup the -matomic-model= option when
+// set in the environment. This makes it impossible to enable the proper
+// atomic model on SH without modifying GCC itself, because libstdc++ always
+// thinks the target doesn't do any atomics and uses the default mutex based
+// implementation from cpu/generic/atomicity/mutex.
#include ext/atomicity.h
-
-namespace __gnu_cxx _GLIBCXX_VISIBILITY(default)
-{
-_GLIBCXX_BEGIN_NAMESPACE_VERSION
-
- typedef int _Atomic_word;
-
- _Atomic_word
- __attribute__ ((__unused__))
- __exchange_and_add (volatile _Atomic_word* __mem, int __val) throw ()
- {
-_Atomic_word __result;
-
-__asm__ __volatile__
- (0:\n
- \tmovli.l\t@%2,r0\n
- \tmov\tr0,%1\n
- \tadd\t%3,r0\n
- \tmovco.l\tr0,@%2\n
- \tbf\t0b
- : +m (*__mem), =r (__result)
- : r (__mem), rI08 (__val)
- : r0);
-
-return __result;
- }
-
-
- void
- __attribute__ ((__unused__))
- __atomic_add (volatile _Atomic_word* __mem, int __val) throw ()
- {
-asm(0:\n
- \tmovli.l\t@%1,r0\n
- \tadd\t%2,r0\n
- \tmovco.l\tr0,@%1\n
- \tbf\t0b
- : +m (*__mem)
- : r (__mem), rI08 (__val)
- : r0);
- }
-
-_GLIBCXX_END_NAMESPACE_VERSION
-} // namespace
-
-#else /* !__SH4A__ */
-
-/* This is generic/atomicity.h */
-
-#include ext/atomicity.h
-#include ext/concurrence.h
-
-namespace
-{
- __gnu_cxx::__mutex atomic_mutex;
-} // anonymous namespace
-
-namespace __gnu_cxx _GLIBCXX_VISIBILITY(default)
-{
-_GLIBCXX_BEGIN_NAMESPACE_VERSION
-
- _Atomic_word
- __attribute__ ((__unused__))
- __exchange_and_add(volatile _Atomic_word* __mem, int __val) throw ()
- {
-__gnu_cxx::__scoped_lock sentry(atomic_mutex);
-_Atomic_word __result;
-__result = *__mem;
-*__mem += __val;
-return __result;
- }
-
- void
- __attribute__ ((__unused__))
- __atomic_add(volatile _Atomic_word* __mem, int __val) throw ()
- { __exchange_and_add(__mem, __val); }
-
-_GLIBCXX_END_NAMESPACE_VERSION
-} // namespace
-
-#endif /* !__SH4A__ */
[PATCH, i386] Fix PR 64688, ICE: Max. number of generated reload insns per insn is achieved (90)
Hello!
Attached patch fixes PR 64688. Operand constraints were wrong for
reg-to-vec targets.
The patch also fixes PR 64477.
2015-22-01 Uros Bizjak ubiz...@gmail.com
PR target/64688
PR target/64477
* config/i386/sse.md (vec_setmode_0): Use (Yi/r/C) constraints
for alternative 3.
testsuite/ChangeLog:
2015-22-01 Uros Bizjak ubiz...@gmail.com
PR target/64688
* g++.dg/pr64688.C: New test.
Bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.
Committed to mainline, will be backported to release branches.
Uros.
Index: testsuite/g++.dg/pr64688.C
===
--- testsuite/g++.dg/pr64688.C (revision 0)
+++ testsuite/g++.dg/pr64688.C (revision 0)
@@ -0,0 +1,71 @@
+// { dg-do compile { target i?86-*-* x86_64-*-* } }
+// { dg-options -std=c++11 -O3 -march=westmere }
+
+template typename T struct A { typedef typename T::next type; };
+template typename struct B;
+template typename T struct N : T {};
+template int N struct C {
+ static const int value = N;
+ typedef CN + 1 next;
+};
+template typename Sequence
+struct R : Ntypename Btypename Sequence::tag::template PSequence {};
+template typename Base struct O : Base {
+ typedef typename Atypename Base::size::type size;
+};
+template typename = int struct D {
+ typedef int tag;
+ typedef C0 size;
+};
+template struct Bint {
+ template typename struct P : OOOD::size {};
+};
+template typename struct F;
+template typename struct G;
+template typename, typename, int struct H;
+template typename Element, typename Layout struct HElement, Layout, 3 {};
+template int, typename E, typename L, int N unsigned char at_c(HE, L, N) {}
+template typename class I;
+template typename class J;
+template typename class K;
+template typename, typename struct Q;
+struct L {
+ typedef Qunsigned char, FOOOD *type;
+};
+template typename XIterator struct M { typedef KJIXIterator view_t; };
+template typename, typename
+struct Q : Hunsigned, Fint, ROOOD::value {};
+template typename Iterator struct GIIterator { typedef Iterator type; };
+template typename class J {
+public:
+ typedef GIQunsigned, int *::type x_iterator;
+};
+template typename class K {
+public:
+ Jint::x_iterator row_begin(int);
+};
+template typename Op void measure_time(Op p1) { p1(); }
+template typename, typename struct fill_nongil_t;
+template typename T, typename P
+struct fill_nongil_tKJIQT, FOOOD *, P {
+ typedef KJIQT, FOOOD * View;
+ View _v;
+ P _p;
+ fill_nongil_t(View, P);
+ void operator()() {
+T *first = (T *)_v.row_begin(0);
+T last;
+while (first != last) {
+ first[0] = first[1] = at_c1(_p);
+ first[2] = at_c2(_p);
+ first += 3;
+}
+ }
+};
+template typename, typename void test_fill(int) {
+ ML::type::view_t __trans_tmp_1;
+ measure_time(fill_nongil_tKJIQunsigned char, FOOOD *,
+ Qunsigned char, FOOOD(
+ __trans_tmp_1, Qunsigned char, FOOOD()));
+}
+void performance_testtest_method() { test_fillKint, Qunsigned, int(0); }
Index: config/i386/sse.md
===
--- config/i386/sse.md (revision 219987)
+++ config/i386/sse.md (working copy)
@@ -6391,11 +6391,11 @@
;; see comment above inline_secondary_memory_needed function in i386.c
(define_insn vec_setmode_0
[(set (match_operand:VI4F_128 0 nonimmediate_operand
- =Yr,*v,v,v ,x,x,v,Yr ,*x ,x ,m ,m ,m)
+ =Yr,*v,v,Yi,x,x,v,Yr ,*x ,x ,m ,m ,m)
(vec_merge:VI4F_128
(vec_duplicate:VI4F_128
(match_operand:ssescalarmode 2 general_operand
- Yr,*v,m,*r,m,x,v,*rm,*rm,*rm,!x,!*re,!*fF))
+ Yr,*v,m,r ,m,x,v,*rm,*rm,*rm,!x,!*re,!*fF))
(match_operand:VI4F_128 1 vector_move_operand
C , C,C,C ,C,0,v,0 ,0 ,x ,0 ,0 ,0)
(const_int 1)))]
Re: [[ARM/AArch64][testsuite] 03/36] Add vmax, vmin, vhadd, vhsub and vrhadd tests.
On 22/01/15 14:28, Christophe Lyon wrote: On 22 January 2015 at 12:19, Tejas Belagod tejas.bela...@arm.com wrote: On 21/01/15 15:07, Christophe Lyon wrote: On 19 January 2015 at 17:54, Marcus Shawcroft marcus.shawcr...@gmail.com wrote: On 19 January 2015 at 15:43, Christophe Lyon christophe.l...@linaro.org wrote: On 19 January 2015 at 14:29, Marcus Shawcroft marcus.shawcr...@gmail.com wrote: On 16 January 2015 at 17:52, Christophe Lyon christophe.l...@linaro.org wrote: OK provided, as per the previous couple, that we don;t regression or introduce new fails on aarch64[_be] or aarch32. This patch shows failures on aarch64 and aarch64_be for vmax and vmin when the input is -NaN. It's a corner case, and my reading of the ARM ARM is that the result should the same as on aarch32. I haven't had time to look at it in more details though. So, not OK? They should have the same behaviour in aarch32 and aarch64. Did you test on HW or a model? I ran the tests on qemu for aarch32 and aarch64-linux, and on the foundation model for aarch64*-elf. Leave this one out until we understand why it fails. /Marcus I've looked at this a bit more. We have fmaxv0.4s, v0.4s, v1.4s where v0 is a vector of -NaN (0xffc0) and v1 is a vector of 1. The output is still -NaN (0xffc0), while the test expects defaultNaN (0x7fc0). In the AArch32 execution state, Advanced SIMD FP arithmetic always uses the DefaultNaN setting regardless of the DN-bit value in the FPSCR. In AArch64 execution state, result of Advanced SIMD FP arithmetic operations depend on the value of the DN-bit i.e. either propagate the input NaN or generate DefaultNaN depending on the value of DN. Maybe I'm using an outdated doc. On page 2282 of ARMv8 ARM rev C, I can see only the latter (no diff between aarch32 and aarch64 in FPProcessNan pseudo-code) If you see pg. 4005 in the same doc(rev C), you'll see the FPSCR spec - under DN: The value of this bit only controls scalar floating-point arithmetic. Advanced SIMD arithmetic always uses the Default NaN setting, regardless of the value of the DN bit. Also on page 3180 for the description of VMAX(vector FP), it says: * max(+0.0, -0.0) = +0.0 * If any input is a NaN, the corresponding result element is the default NaN. The pseudocode for FPMax () on pg. 3180 passes StandardFPSCRValue() to FPMax() which is on pg. 2285 // StandardFPSCRValue() // FPCRType StandardFPSCRValue() return ‘0’ : FPSCR.AHP : ‘11’ Here bit-25(FPSCR.DN) is set to 1. Thanks, Tejas. If you're running your test in the AArch64 execution state, you'd want to define the DN bit and modify the expected results accordingly or have the test poll at runtime what the DN-bit is set to and check expected results dynamically. Makes sense, I hadn't noticed the different aarch64 spec here. I think the test already has expected behaviour for AArch32 execution state by expecting DefaultNaN regardless. Yes. I have executed the test under GDB on AArch64 HW, and noticed that fpcr was 0. I forced it to have DN==1: set $fpcr=0x100 but this didn't change the result. Does setting fpcr.dn under gdb actually work? It should. Possibly a bug, patches welcome :-). :-)
RE: [MIPS] fix CRT_CALL_STATIC_FUNCTION macro
This is a case when _init () function has to jump to __do_global_ctors_aux, but __do_global_ctors_aux is too far away, so the target address is shortened to fit in jal, and __do_global_ctors_aux is not reached. Regards, Petar -Original Message- From: Matthew Fortune [mailto:matthew.fort...@imgtec.com] Sent: Thursday, January 22, 2015 9:36 AM To: Petar Jovanovic; gcc-patches@gcc.gnu.org Cc: Petar Jovanovic Subject: RE: [MIPS] fix CRT_CALL_STATIC_FUNCTION macro This is a follow-up to a change [1] in glibc. It fixes the issue [2] when jal can not reach a target in different region. It has been tested with DejaGnu for mips32/o32, mips64/n32 and mips64/n64. Let me know what you think. So to confirm, the issue is non-pic crt calling an init routine beyond the current 256 MB region? Otherwise for PIC the issue is dealt with by the assembler with the JAL sym being expanded to a load from the got and indirect call through t9. Previously t9 would not have been set up for the callee if the code was built non-pic (as it would just use a JAL). That would have made the setup of gp somewhat pointless in the CRT_CALL_STATIC_FUNCTION code. I am therefore a little confused by the existing code that sets up GP but then it seemingly is not used unless built for PIC. I need a little time to consider this further. Catherine may comment in the meantime. Thanks, Matthew
Re: [Patch, Fortran, OOP] PR 60922: [4.9/5 regression] Memory leak with allocatable CLASS components
Ping! 2015-01-18 11:46 GMT+01:00 Janus Weil ja...@gcc.gnu.org: Hi all, the attached patch is close to trivial and fixes a memory-leak regression that appeared after the implementation of finalization. My suspicion it that it's simply a copy'n'paste error, where the wrong attribute was copied from very similar code a few lines above, but I'd like to have that confirmed by the original author (which should be Tobias). Regtested on x86_64-unknown-linux-gnu. Ok for trunk and 4.9? Cheers, Janus 2015-01-18 Janus Weil ja...@gcc.gnu.org PR fortran/60922 * class.c (finalize_component): Apply the check for 'fini_coarray' only to coarray components. 2015-01-18 Janus Weil ja...@gcc.gnu.org PR fortran/60922 * gfortran.dg/class_allocate_17.f90: Extended.
Re: flatten expr.h (version 2)
Thanks, moved them to expmed.h. Boostrapped on x86_64-unknown-linux-gnu with languages: all, testing in progress. Build on all targets in config-list.mk in progress. Assuming it goes fine, OK to commit ? You can install it under the obvious rule once successfully tested. -- Eric Botcazou
Re: [libcpp PATCH] Resolve DR#412 - unevaluated #elif (PR preprocessor/60570)
On Thu, 22 Jan 2015, Marek Polacek wrote: As discussed in the PR, this patch partially reverts Tom's change in r136209. (The is_if argument to _cpp_parse_expr is kept for the sake of diagnostics.) The change made sense at that time, but now we have DR#412 resolved. This DR deals with the case where we have an #elif conditional that doesn't have to be evaluated: #if 1 int i; #elif 1/0 #endif and this DR says that such #elifs should be skipped. This change is deliberately not conditioned on any standard version. Jason, Joseph, does it make sense to put this into GCC 5, or should it wait for GCC 6? Since this change makes the preprocessor more permissive, it should hurt nobody. Bootstrapped/regtested on x86_64-linux, ok for trunk? OK for GCC 5. -- Joseph S. Myers jos...@codesourcery.com
Re: [patch, libbacktrace/libsanitizer] fix multilib builds
On Thu, Jan 22, 2015 at 3:44 PM, Matthias Klose d...@ubuntu.com wrote:
However for the libbacktrace and the libsanitizer builds, the
AM_ENABLE_MULTILIB
macro is included way too late. Scan the generated configure file for
cross_compiling and see that the above snippet is added after the failing
checks. The fix seems to be simple, just move the AM_ENABLE_MULTILIB macro up
so
that the cross_compiling value is corrected before it is tested. This is
what
the patch is doing.
However ... for every runtime library there is still something wrong, at least
one linker check in the generated configure is done before the expansion of
the
AM_ENABLE_MULTILIB macro. I'm not trying to fix that with this patch ...
autoconf offers a AC_REQUIRE macro, so AM_ENABLE_MULTILIB should add one to
ensure that this macros is always expanded before the first check for
cross_compiling, but I'm not sure which one.
Small patch, but took me some time to find out :-/
This patch should go to trunk and all active branches. Ok to check in?
The libbacktrace library is unusual because we build it for both the
host and the target. When building for the host, we do not want to
multilib it--that would make no sense. You've moved the
AM_ENABLE_MULTILIB out of the test -n ${with_target_subdir}; don't
do that.
It's fine with me if you move AM_ENABLE_MULTILIB earlier as long as
you keep the test.
Probably a build maintainer should take a look at this patch.
Ian
Re: [PING] : [RFC] Tighten memory type assumption in RTL combiner pass.
Thank you Segher, I will send an updated patch for stage 1. regards, Venkat. On 22 January 2015 at 21:46, Segher Boessenkool seg...@kernel.crashing.org wrote: On Thu, Jan 22, 2015 at 07:29:28PM +0530, Venkataramanan Kumar wrote: ping. Segher do you any comments from your side. I agree combine should not transform shifts into multiplication (except in addresses, where it is canonical). I haven't looked at the actual patch in detail though, it will have to wait until stage1, it is not fixing a regression and it affects all targets. Segher
Re: [SH] Introduce treg_set_expr
On Thu, 2015-01-22 at 01:51 +0100, Oleg Endo wrote:
On Tue, 2015-01-20 at 20:05 +0900, Kaz Kojima wrote:
Oleg Endo oleg.e...@t-online.de wrote:
The updated treg_set_expr patch is attached, which should fix the GBR
issues. Tests here OK.
Kaz, could you please try again?
New tests that FAIL:
libgomp.fortran/udr14.f90 -O3 -g (internal compiler error)
libgomp.fortran/udr14.f90 -O3 -g (test for excess errors)
Old tests that passed, that have disappeared: (Eeek!)
gcc.target/sh/pr49263-1.c scan-assembler-not bclr
gcc.target/sh/pr49263-1.c scan-assembler-times extu 1
gcc.target/sh/pr49263-2.c scan-assembler-times -129 2
gcc.target/sh/pr49263-2.c scan-assembler-times extu 1
That's OK. The patch removes the xfail markers from already committed
tests.
For the new ICE, libgomp tests log says:
/exp/ldroot/dodes/LOCAL/trunk/libgomp/testsuite/libgomp.fortran/udr14.f90:15:0:
internal compiler error: in maybe_record_trace_start, at dwarf2cfi.c:2318
0x8384ad6 maybe_record_trace_start
../../LOCAL/trunk/gcc/dwarf2cfi.c:2318
0x8385023 scan_trace
../../LOCAL/trunk/gcc/dwarf2cfi.c:2496
0x8385b35 create_cfi_notes
../../LOCAL/trunk/gcc/dwarf2cfi.c:2650
0x8385b35 execute_dwarf2_frame
../../LOCAL/trunk/gcc/dwarf2cfi.c:3006
0x8385b35 execute
../../LOCAL/trunk/gcc/dwarf2cfi.c:3486
Please submit a full bug report,
...
./f951 udr14.f90 -g -O3 -fopenmp -o xxx.s can reproduce this ICE.
That's .. ugh..
Without -g it compiles fine. The resulting code is pretty much the same
as without the patch. The only thing that combines/splits differently
are the few comparisons and movrt_negc pattern uses. With the patch the
magic constant '-1' is not shared that often anymore. This is a known
issue and small 'regression' of the patch (but a general problem on SH).
Anyway, this has nothing to do with debug info.
dwarf2cfi.c's last words are:
Processing trace 45 : start at code_label 723
saw edge from trace 45 to 46 (via fallthru 0)
and the RTL there looks like this:
(note 3417 3416 3418 (var_location x (nil)) NOTE_INSN_VAR_LOCATION)
(note 3418 3417 723 (var_location y (nil)) NOTE_INSN_VAR_LOCATION)
(code_label 723 3418 724 6 [1 uses])
(note 724 723 3569 [bb 54] NOTE_INSN_BASIC_BLOCK)
(code_label 3569 724 727 103 [1 uses])
(insn 727 3569 3661 (set (reg:SI 147 t)
(ge:SI (reg:SI 1 r1 [orig:286 D.1466 ] [286])
(reg:SI 2 r2 [orig:284 D.1466 ] [284]))) udr14.f90:35 15
{cmpgesi_t}
(nil))
It looks like the SH reorg pass is creating this. The compiled code
with the patch applied (without -g) also shows some constant pool
placement differences, which are done by the SH reorg pass.
Increasing the size of define_insn_and_split movrt_negc from 2 to 4
makes the problem go away with the patch.
Without the patch the ICE can be triggered by increasing the size of
define_insn_and_split movrt_negc from 2 to 3.
I guess this is a latent bug/problem of SH reorg (maybe PR 59189) or the
dwarf2cfi.c code (maybe PR 64602).
I have created PR 64736 for this issue.
I will install this the patch from
https://gcc.gnu.org/ml/gcc-patches/2015-01/msg01743.html
in 24h if there are no further objections.
Cheers,
Oleg
Re: [PATCH] Fix generation of m32c target (PR 50928)
OK for trunk. OK for 4.9 branch if it's OK with the release manager. Do you need someone to apply it for you?
Re: [PATCH] Add new target h8300-*-linux
On Thu, 22 Jan 2015, Yoshinori Sato wrote:
+h8300-*-linux*)
+ tmake_file=${tmake_file} h8300/t-h8300 h8300/t-linux
+ tm_file=h8300/linux.h dbxelf.h elfos.h linux.h
Toplevel linux.h should always be used together with gnu-user.h and
glibc-stdint.h.
+#define __h8300_linux__
This macro is in the implementation namespace, so should not be defined on
the host. Macros for communication between one part of the host code and
another should be in the user namespace, e.g. H8300_LINUX.
--
Joseph S. Myers
jos...@codesourcery.com
[patch, libbacktrace/libsanitizer] fix multilib builds
In the past I had some issues on various linux platforms to build some multilib
configurations, all not building libbacktrace and libsanitizer, seen on powerpc,
ix86 and x86_64. All fail like
Running configure in multilib subdir x32
pwd: /«PKGBUILDDIR»/build/i586-linux-gnu
configure: creating cache ./config.cache
checking build system type... i586-pc-linux-gnu
checking host system type... i586-pc-linux-gnu
checking target system type... i586-pc-linux-gnu
checking for i586-linux-gnu-gcc... /«PKGBUILDDIR»/build/./gcc/xgcc
-B/«PKGBUILDDIR»/build/./gcc/ -B/usr/i586-linux-gnu/bin/
-B/usr/i586-linux-gnu/lib/ -isystem /usr/i586-linux-gnu/include -isystem
/usr/i586-linux-gnu/sys-include -isystem /«PKGBUILDDIR»/build/sys-include -mx32
checking for C compiler default output file name... a.out
checking whether the C compiler works... configure: error: in
`/«PKGBUILDDIR»/build/i586-linux-gnu/x32/libbacktrace':
configure: error: cannot run C compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details.
The issue here is that the kernel used for the build is not configured for x32,
and I'm trying to build x32 multilibs. The same thing happens when trying to
build 64bit multilibs on powerpc, s390 or ix86 kernels, not being able to
execute 64bit binaries. The autoconf generated configury assumes that it should
be able to execute any multilib built binary, however config/multi.m4 knows
better about this ...
# Even if the default multilib is not a cross compilation,
# it may be that some of the other multilibs are.
if test $cross_compiling = no test $multilib = yes \
test x${with_multisubdir} != x ; then
cross_compiling=maybe
fi
However for the libbacktrace and the libsanitizer builds, the AM_ENABLE_MULTILIB
macro is included way too late. Scan the generated configure file for
cross_compiling and see that the above snippet is added after the failing
checks. The fix seems to be simple, just move the AM_ENABLE_MULTILIB macro up so
that the cross_compiling value is corrected before it is tested. This is what
the patch is doing.
However ... for every runtime library there is still something wrong, at least
one linker check in the generated configure is done before the expansion of the
AM_ENABLE_MULTILIB macro. I'm not trying to fix that with this patch ...
autoconf offers a AC_REQUIRE macro, so AM_ENABLE_MULTILIB should add one to
ensure that this macros is always expanded before the first check for
cross_compiling, but I'm not sure which one.
Small patch, but took me some time to find out :-/
This patch should go to trunk and all active branches. Ok to check in?
Matthias
--- a/src/libbacktrace/configure.ac
+++ b/src/libbacktrace/configure.ac
@@ -34,6 +34,8 @@
AC_CONFIG_SRCDIR(backtrace.h)
AC_CONFIG_HEADER(config.h)
+AM_ENABLE_MULTILIB(, ..)
+
AC_CANONICAL_SYSTEM
target_alias=${target_alias-$host_alias}
@@ -83,7 +85,6 @@
if test -n ${with_target_subdir}; then
# We are compiling a GCC library. We can assume that the unwind
# library exists.
- AM_ENABLE_MULTILIB(, ..)
BACKTRACE_FILE=backtrace.lo simple.lo
else
AC_CHECK_HEADER([unwind.h],
--- a/src/libsanitizer/configure.ac
+++ b/src/libsanitizer/configure.ac
@@ -5,6 +5,8 @@
AC_INIT(package-unused, version-unused, libsanitizer)
AC_CONFIG_SRCDIR([include/sanitizer/common_interface_defs.h])
+AM_ENABLE_MULTILIB(, ..)
+
AC_MSG_CHECKING([for --enable-version-specific-runtime-libs])
AC_ARG_ENABLE(version-specific-runtime-libs,
[ --enable-version-specific-runtime-libsSpecify that runtime libraries should be installed in a compiler-specific directory ],
@@ -26,7 +28,6 @@
GCC_LIBSTDCXX_RAW_CXX_FLAGS
AM_INIT_AUTOMAKE(foreign no-dist)
-AM_ENABLE_MULTILIB(, ..)
AM_MAINTAINER_MODE
# Calculate toolexeclibdir
Re: [PATCH 2/2] Add patch for debugging compiler ICEs.
On Fri, Sep 26, 2014 at 1:04 AM, Maxim Ostapenko m.ostape...@partner.samsung.com wrote: Thank you all for your help! Done in r215633. -Maxim On 09/25/2014 11:05 PM, Jeff Law wrote: On 09/23/14 01:14, Maxim Ostapenko wrote: 2014-09-04 Jakub Jelinekja...@redhat.com Max Ostapenkom.ostape...@partner.samsung.com * common.opt: New option. * doc/invoke.texi: Describe new option. * gcc.c (execute): Don't free first string early, but at the end of the function. Call retry_ice if compiler exited with ICE_EXIT_CODE. (main): Factor out common code. (print_configuration): New function. (files_equal_p): Likewise. (check_repro): Likewise. (run_attempt): Likewise. (do_report_bug): Likewise. (append_text): Likewise. (try_generate_repro): Likewise Approved. Please install. Any particular reason for extra blank line: if (! strncmp (version_string, compiler_version, n) compiler_version[n] == 0) fnotice (file, gcc version %s %s\n\n, version_string, pkgversion_string); else fnotice (file, gcc driver version %s %sexecuting gcc version %s\n\n, version_string, pkgversion_string, compiler_version); I opened: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64737 -- H.J.
RE: [PATCH] Don't check for optab for 16bit bswap
From: Richard Henderson [mailto:r...@redhat.com] Sent: Friday, January 23, 2015 2:43 AM On 01/21/2015 11:52 PM, Richard Biener wrote: I was asking for the generic expander to consider bswapHI. Rotates are certainly more likely to get combined with sth else. Maybe. Alternately, don't we canonicalize byte-swapping memory ops as (set (reg:HI) (bswap:HI (mem:HI))) (set (mem:HI) (bswap:HI (reg:HI))) Given the expmed.c bit I pasted, I'd say that's how it would be canonicalized in RTL form yes. I think Richard was referring to combination at GIMPLE level but that expander should expand to bswapHI to not break expectations. Best regards, Thomas
Re: [PATCH] Fix scheduling undeterminism from sorting with DEBUG_INSNs
On Jan 22, 2015, at 8:11 PM, Jeff Law l...@redhat.com wrote: On 01/19/15 06:07, Maxim Kuvyrkov wrote: The underlying problem is that the order in which elements of ready_list are compared matters to the final result. This is because rank_for_schedule sorting heuristic establishes a partial order on the set of instructions, and it can happen that with 3 instructions A, B and C: AB, BC, CA. In this situation the order in which qsort compares the elements affects the final result, it can be either ABC or BCA or CAB. So how precisely do we get A B, B C and C A? Unless I'm missing something, that seems to be an extremely bad result from rank_for_schedule. This happens when all 3 instructions have (1) same priority, and (2) only two of the three instructions are comparable on a selective heuristic. Selective means that a heuristic only applies to a subset of instructions, e.g., comparing speculative instructions among themselves (ia64), or comparing memory operations among themselves (what ached auto-prefetcher model does). Let's say that A and B are memory instructions and A B as decided by autoprefetcher heuristic. C is not a memory instruction, and its rank resolved by comparing number of forward dependencies to those of A and B. Specifically, B has less forward dependencies than C, so B C, but A has more forward dependencies than C, so C A. Code-quality-wise, this quirk of rank_for_schedule is harmless, since it occurs only for very similarly-ranked instructions. The problem appears only when length of ready_list changes (due to DEBUG_INSNs) as that can cause different pairs of instructions to be compared. -- Maxim Kuvyrkov www.linaro.org
[Patch, Fortran] PR64726 Fix OpenACC's parallel/kernel loop
parallel/kernel loop is handled by the function being patched (an
assert ensures that no other directives end here). The first part of the
function handles the parallel and kernel part, the loop itself should be
handled by the called function. However, it currently passes the
kernel/parallel loop op on, instead of only the loop part. That
fails in the called function in an assert.
Build and regtested on x86-64-gnu-linux.
OK for the trunk?
Tobias
2015-01-22 Tobias Burnus bur...@net-b.de
PR fortran/64726
* trans-openmp.c (gfc_trans_oacc_combined_directive): Fix
loop generation.
2015-01-22 Tobias Burnus bur...@net-b.de
PR fortran/64726
* gfortran.dg/goacc/combined_loop.f90: New.
diff --git a/gcc/fortran/trans-openmp.c b/gcc/fortran/trans-openmp.c
index fe47a96..cdd1885 100644
--- a/gcc/fortran/trans-openmp.c
+++ b/gcc/fortran/trans-openmp.c
@@ -3438,7 +3438,7 @@ gfc_trans_oacc_combined_directive (gfc_code *code)
pblock = block;
else
pushlevel ();
- stmt = gfc_trans_omp_do (code, code-op, pblock, loop_clauses, NULL);
+ stmt = gfc_trans_omp_do (code, EXEC_OACC_LOOP, pblock, loop_clauses, NULL);
if (TREE_CODE (stmt) != BIND_EXPR)
stmt = build3_v (BIND_EXPR, NULL, stmt, poplevel (1, 0));
else
diff --git a/gcc/testsuite/gfortran.dg/goacc/combined_loop.f90 b/gcc/testsuite/gfortran.dg/goacc/combined_loop.f90
new file mode 100644
index 000..b8be649
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/goacc/combined_loop.f90
@@ -0,0 +1,12 @@
+! { dg-do compile }
+!
+! PR fortran/64726
+!
+subroutine oacc1()
+ implicit none
+ integer :: i
+ integer :: a
+ !$acc parallel loop reduction(+:a) ! { dg-excess-errors sorry, unimplemented: directive not yet implemented }
+ do i = 1,5
+ enddo
+end subroutine oacc1
Fix thiko when maintaining priority heap
Hi,
this patch fixes problem noticed by HJ about matinenance of the heap.
I doubt it really fixed the underlying correctness issue of the PR mentioned.
Bootstrapped/regtested x86_64-linux, comitted.
Honza
Index: ChangeLog
===
--- ChangeLog (revision 220010)
+++ ChangeLog (working copy)
@@ -1,3 +1,10 @@
+2015-01-22 Jan Hubicka hubi...@ucw.cz
+ H.J. Lu hongjiu...@intel.com
+
+ PR ipa/64694
+ * ipa-inline.c (inline_small_functions): Fix thinko in maintenance of
+ heap.
+
2015-01-22 Wei Mi w...@google.com
PR rtl-optimization/64557
Index: ipa-inline.c
===
--- ipa-inline.c(revision 219969)
+++ ipa-inline.c(working copy)
@@ -1755,7 +1755,7 @@ inline_small_functions (void)
#endif
if (current_badness != badness)
{
- if (edge_heap.min () badness edge_heap.min_key ())
+ if (edge_heap.min () current_badness edge_heap.min_key ())
{
edge-aux = edge_heap.insert (current_badness, edge);
continue;
[PATCH] PR 64722: fix corruption of %ebx on 32-bit i386 with libgccjit
Much of the jit testsuite currently segfaults on i686, after
two in-process iterations. In odd-numbered iterations,
gcc_jit_context_compile generates correct code, but on
even-numbered iterations, the generated code trashes the
%ebx register, leading to SIGSEGV back at the call site when
setting up iteration 3.
The root cause is due to missing state cleanup when repeatedly
invoking the compiler in-process.
The issue manifests in emit-rtl.c:init_emit_regs, at
this initialization:
if ((unsigned) PIC_OFFSET_TABLE_REGNUM != INVALID_REGNUM)
pic_offset_table_rtx = gen_raw_REG (Pmode, PIC_OFFSET_TABLE_REGNUM);
else
pic_offset_table_rtx = NULL_RTX;
On 32-bit i386 fPIC the definition PIC_OFFSET_TABLE_REGNUM itself
depends on pic_offset_table_rtx, and hence the above initialization
code cycles between switching pic_offset_table_rtx from NULL to
non-NULL (on odd-numbered iterations), then switching it back from
non-NULL to NULL (on even-numbered iterations). In the latter case,
this leads to generated code that's supposedly fPIC, but erroneously
doesn't bother saving %ebx.
The simple fix is to set pic_offset_table_rtx to NULL_RTX before
testing PIC_OFFSET_TABLE_REGNUM (and thus making the else clause
redundant). A more involved fix might be for the JIT to only
initialize RTL once, but doing so seems higher risk.
Tested with make check-jit on i686; with this, all testcases pass
(with the usual 5 in-process iterations).
Bootstrapregrtest in progress.
OK for trunk if it passes?
gcc/ChangeLog:
PR 64722
* emit-rtl.c (init_emit_regs): Set pic_offset_table_rtx to
NULL_RTX before testing PIC_OFFSET_TABLE_REGNUM, since the
latter may be affected by the former (e.g. on i686).
---
gcc/emit-rtl.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/gcc/emit-rtl.c b/gcc/emit-rtl.c
index df85366..483eacb 100644
--- a/gcc/emit-rtl.c
+++ b/gcc/emit-rtl.c
@@ -5872,10 +5872,9 @@ init_emit_regs (void)
= gen_raw_REG (Pmode, RETURN_ADDRESS_POINTER_REGNUM);
#endif
+ pic_offset_table_rtx = NULL_RTX;
if ((unsigned) PIC_OFFSET_TABLE_REGNUM != INVALID_REGNUM)
pic_offset_table_rtx = gen_raw_REG (Pmode, PIC_OFFSET_TABLE_REGNUM);
- else
-pic_offset_table_rtx = NULL_RTX;
for (i = 0; i (int) MAX_MACHINE_MODE; i++)
{
--
1.8.5.3
Re: [Patch, Fortran, OOP] PR 60922: [4.9/5 regression] Memory leak with allocatable CLASS components
Dear Janus, As it happens I loaded this patch up last night to see if I could plug the last leak in my patch for PR63205, which is making heavy use of the default finalizers. It seemed to do the job. As you said in the PR it appears to be a typo and really is obvious. I can canfirm that it bootstraps and regtests OK. Good for 4.9 and 5.0 Thanks for the patch Paul On 22 January 2015 at 16:37, Janus Weil ja...@gcc.gnu.org wrote: Ping! 2015-01-18 11:46 GMT+01:00 Janus Weil ja...@gcc.gnu.org: Hi all, the attached patch is close to trivial and fixes a memory-leak regression that appeared after the implementation of finalization. My suspicion it that it's simply a copy'n'paste error, where the wrong attribute was copied from very similar code a few lines above, but I'd like to have that confirmed by the original author (which should be Tobias). Regtested on x86_64-unknown-linux-gnu. Ok for trunk and 4.9? Cheers, Janus 2015-01-18 Janus Weil ja...@gcc.gnu.org PR fortran/60922 * class.c (finalize_component): Apply the check for 'fini_coarray' only to coarray components. 2015-01-18 Janus Weil ja...@gcc.gnu.org PR fortran/60922 * gfortran.dg/class_allocate_17.f90: Extended. -- Outside of a dog, a book is a man's best friend. Inside of a dog it's too dark to read. Groucho Marx
Re: [PATCH] toplev.c: Process the failure when read fails for random_seed
On 01/22/15 04:55, Chen Gang S wrote: On 01/22/2015 02:46 AM, Mike Stump wrote: On Jan 21, 2015, at 1:54 AM, Chen Gang S gang.c...@sunrus.com.cn wrote: On 1/6/15 04:07, Jeff Law wrote: * toplev.c (init_local_tick): Process the failure when read fails for random_seed. This is fine for the trunk. Please install. I am not familiar with the related working flow, who should install this patch? Anyone with write privileges can do this. You can request installation of the patch with the magic phrase: I don’t have write access yet nor is my paperwork compete, can someone install this for me? This will prompt a volunteer to step forward and help get it installed. When they are done, they will say, installed, close any related bug report and if they are nice, tell you the commit number for the work. You can then update your tree, build and test and ensure the work is as you wanted it. Once it hits the trunk, you’re done. If the patch is important enough for a back-port, you can ask people to consider a back port, once the work has been proven on the trunk for a week or two. OK, thanks, for me, this is only a trivial patch (not urgent). So I can understand why it is still pending. And if possible, could you help install this patch when you have time? Installed on your behalf. Jeff
Go patch committed: avoid infinite loop when reporting initialization loop
This patch by Chris Manghane fixes the Go frontend to avoid an
infinite loop when reporting an initialization loop. This is Go issue
7558. Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu.
Committed to mainline.
Ian
diff -r 4a641c29091f go/gogo.cc
--- a/go/gogo.ccWed Jan 21 20:07:40 2015 -0800
+++ b/go/gogo.ccThu Jan 22 08:43:48 2015 -0800
@@ -1089,6 +1089,7 @@
// variable initializations that depend on it.
typedef std::mapVar_init, std::setVar_init* Init_deps;
Init_deps init_deps;
+ bool init_loop = false;
for (Var_inits::iterator p1 = var_inits-begin();
p1 != var_inits-end();
++p1)
@@ -1137,14 +1138,15 @@
p2var-message_name().c_str());
inform(p2-var()-location(), %qs defined here,
p2var-message_name().c_str());
- p2 = var_inits-end();
+ init_loop = true;
+ break;
}
}
}
}
// If there are no dependencies then the declaration order is sorted.
- if (!init_deps.empty())
+ if (!init_deps.empty() !init_loop)
{
// Otherwise, sort variable initializations by emitting all variables
with
// no dependencies in declaration order. VAR_INITS is already in
Re: [PATCH] Fix scheduling undeterminism from sorting with DEBUG_INSNs
On 01/19/15 06:07, Maxim Kuvyrkov wrote: The underlying problem is that the order in which elements of ready_list are compared matters to the final result. This is because rank_for_schedule sorting heuristic establishes a partial order on the set of instructions, and it can happen that with 3 instructions A, B and C: AB, BC, CA. In this situation the order in which qsort compares the elements affects the final result, it can be either ABC or BCA or CAB. So how precisely do we get A B, B C and C A? Unless I'm missing something, that seems to be an extremely bad result from rank_for_schedule. Jeff
Re: [patch] gcc fstack-protector-explicit
On 01/22/15 05:37, Jakub Jelinek wrote:
On Wed, Jan 21, 2015 at 10:07:14AM +0100, Rainer Orth wrote:
Ok for mainline once that has been done?
Thanks.
Rainer
2015-01-20 Rainer Orth r...@cebitec.uni-bielefeld.de
* gcc.c (LINK_SSP_SPEC): Handle -fstack-protector-explicit.
Ok.
Though wonder if for the TARGET_LIBC_PROVIDES_SSP case LINK_SSP_SPEC
shouldn't be
#define LINK_SSP_SPEC
{fstack-protector|fstack-protector-strong|fstack-protector-explicit|fstack-protector-all:}
and
gcc/config/freebsd.h:
#define LINK_SSP_SPEC %{fstack-protector|fstack-protector-all:-lssp_nonshared}
should be changed too (adding both -string and -explicit).
Ranier, sorry about the breakage on Solaris.
WRT other LINK_SPECs, yea, they all need to check the 4 variants of
-fstack-protector-whatever and if any are found, link in libssp.
Patch to fix that pre-approved.
jeff
Re: [PATCH] Add new target h8300-*-linux
On 01/22/15 01:38, Yoshinori Sato wrote:
Add h8300-*-linux target for h8300 linux kernel and userland.
h8300-*-elf is some difference of standard elf.
h8300-*-linux is compatible of standard elf rules.
It seems to me that you should have linux.h just define things that are
specific to the linux port rather than copying huge amounts of h8300.h.
diff --git a/gcc/config/h8300/h8300.c b/gcc/config/h8300/h8300.c
index e7ed03a..4ec8516 100644
--- a/gcc/config/h8300/h8300.c
+++ b/gcc/config/h8300/h8300.c
@@ -359,11 +359,13 @@ h8300_option_override (void)
target_flags |= MASK_H8300S_1;
}
+#ifndef __h8300_linux__
if (TARGET_H8300 TARGET_INT32)
{
error (-mint32 is not supported for H8300 and H8300L targets);
target_flags ^= MASK_INT32;
}
+#endif
On precisely what targets is Linux going to be supported on the H8
series? Presumably it's going to be some H8/S variants and newer?
--- /dev/null
+++ b/gcc/config/h8300/linux.h
This really should just be overriding any generic definitions in h8300.h
rather than copying most of that file. I didn't read through this in
any detail as it's unacceptable as-is.
Presumably you're using the standard ABI (parameter passing, register
usage, etc).
Presumably you're requiring 32 bit integers?
diff --git a/gcc/config/h8300/t-linux b/gcc/config/h8300/t-linux
new file mode 100644
index 000..ac8b0cb
--- /dev/null
+++ b/gcc/config/h8300/t-linux
@@ -0,0 +1,20 @@
+# Copyright (C) 2015 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/.
+
+MULTILIB_OPTIONS = mh/ms/msx
+MULTILIB_DIRNAMES = h8300h h8300s h8sx
So are you really going to support Linux on the old H8/300H? Is there
enough address space on that target for it to work (my recollection of
these processors is fading, but IIRC the H8/300H had a rather limited
address space.
index 4bfa7be..e3abc89 100644
--- a/libgcc/config/h8300/lib1funcs.S
+++ b/libgcc/config/h8300/lib1funcs.S
@@ -84,6 +84,12 @@ see the files COPYING3 and COPYING.RUNTIME respectively. If
not, see
#define A3E e3
#endif
+#define CONCAT(A,B) A##B
+#define LABEL0(U,X)CONCAT(U,__##X)
+#define LABEL0_DEF(U,X)CONCAT(U,__##X##:)
+#define LABEL_DEF(X) LABEL0_DEF(__USER_LABEL_PREFIX__,X)
+#define LABEL(X) LABEL0(__USER_LABEL_PREFIX__,X)
+
#ifdef __H8300H__
#ifdef __NORMAL_MODE__
.h8300hn
@@ -111,8 +117,8 @@ see the files COPYING3 and COPYING.RUNTIME respectively.
If not, see
#ifdef __H8300__
.section .text
.align 2
- .global ___cmpsi2
-___cmpsi2:
+ .global LABEL(cmpsi2)
+LABEL_DEF(cmpsi2)
Presumably this is to get consistency in the namespace and ensure that
USER_LABEL_PREFIX is honored?
You're going to need a copyright assignment with the FSF. You should
get that process started so that when the next stage1 development cycle
opens up, you'll be in a position where we can legally accept your
contributions.
The patch will need a ChangeLog entry. See gcc/ChangeLog for examples.
Remember the ChangeLog merely describes what changed, not why. If
something needs a why explanation, then that explanation belongs in
the code itself.
Jeff
Re: [PATCH PR64557] get_addr in true_dependence_1 cannot handle VALUE inside an expr
On 01/22/15 11:00, Wei Mi wrote: Thanks for the review. Comments addressed and patch committed. The problem exists on gcc-4_9 too. Is it ok for gcc-4_9-branch? Will wait another day to commit it to gcc-4_9 if it is ok. Yes, if the patch from Uros was backported to 4.9, then this patch should get backported as well. The failure mode if this bug gets triggered will likely be hard to identify, so I'd rather not have to do that :-) jeff
Re: [PATCH] PR 64722: fix corruption of %ebx on 32-bit i386 with libgccjit
On Thu, Jan 22, 2015 at 12:34:37PM -0500, David Malcolm wrote: Much of the jit testsuite currently segfaults on i686, after two in-process iterations. In odd-numbered iterations, gcc_jit_context_compile generates correct code, but on even-numbered iterations, the generated code trashes the %ebx register, leading to SIGSEGV back at the call site when setting up iteration 3. The root cause is due to missing state cleanup when repeatedly invoking the compiler in-process. The issue manifests in emit-rtl.c:init_emit_regs, at this initialization: if ((unsigned) PIC_OFFSET_TABLE_REGNUM != INVALID_REGNUM) pic_offset_table_rtx = gen_raw_REG (Pmode, PIC_OFFSET_TABLE_REGNUM); else pic_offset_table_rtx = NULL_RTX; On 32-bit i386 fPIC the definition PIC_OFFSET_TABLE_REGNUM itself depends on pic_offset_table_rtx, and hence the above initialization code cycles between switching pic_offset_table_rtx from NULL to non-NULL (on odd-numbered iterations), then switching it back from non-NULL to NULL (on even-numbered iterations). In the latter case, this leads to generated code that's supposedly fPIC, but erroneously doesn't bother saving %ebx. The simple fix is to set pic_offset_table_rtx to NULL_RTX before testing PIC_OFFSET_TABLE_REGNUM (and thus making the else clause redundant). A more involved fix might be for the JIT to only initialize RTL once, but doing so seems higher risk. Tested with make check-jit on i686; with this, all testcases pass (with the usual 5 in-process iterations). Bootstrapregrtest in progress. OK for trunk if it passes? gcc/ChangeLog: PR 64722 Please use PR jit/64722 * emit-rtl.c (init_emit_regs): Set pic_offset_table_rtx to NULL_RTX before testing PIC_OFFSET_TABLE_REGNUM, since the latter may be affected by the former (e.g. on i686). Just wanted to note that I've bootstrapped/regtested the same patch successfully on x86_64-linux and i686-linux. Jakub
[PATCH] Use chain_next on struct dw_loc_descr_node for GTY (PR debug/64511)
Hi!
The latest testcase from the PR ICEs on running out of stack during GC
collection, because we have a long chain of dw_loc_descr_nodes.
Am not adding the testcase to the testsuite because it looks too costly.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2015-01-22 Jakub Jelinek ja...@redhat.com
PR debug/64511
* dwarf2out.c (struct dw_loc_descr_node): Add chain_next
GTY markup.
--- gcc/dwarf2out.h.jj 2015-01-05 13:07:14.0 +0100
+++ gcc/dwarf2out.h 2015-01-22 14:58:52.448204612 +0100
@@ -205,7 +205,7 @@ struct GTY(()) dw_val_node {
/* Locations in memory are described using a sequence of stack machine
operations. */
-struct GTY(()) dw_loc_descr_node {
+struct GTY((chain_next (%h.dw_loc_next))) dw_loc_descr_node {
dw_loc_descr_ref dw_loc_next;
ENUM_BITFIELD (dwarf_location_atom) dw_loc_opc : 8;
/* Used to distinguish DW_OP_addr with a direct symbol relocation
Jakub
[PATCH] Update BBs in cleanup_barriers pass (PR rtl-optimization/61058)
Hi!
While the cleanup_barriers runs after cleaning up BLOCK_FOR_INSNs,
some targets like i?86/x86_64 choose to populate it again during machine
reorg and some target don't free it at the end of machine reorg.
This patch updates cleanup_barrier pass, so that it adjusts basic block
boundaries and BLOCK_FOR_INSNs in that case, so that we don't crash during
final pass.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2015-01-22 Jakub Jelinek ja...@redhat.com
PR rtl-optimization/61058
* jump.c (cleanup_barriers): Update basic block boundaries
if BLOCK_FOR_INSN is non-NULL on PREV.
* gcc.dg/pr61058.c: New test.
--- gcc/jump.c.jj 2015-01-15 20:25:30.0 +0100
+++ gcc/jump.c 2015-01-22 16:32:11.677709401 +0100
@@ -168,7 +168,27 @@ cleanup_barriers (void)
if (BARRIER_P (prev))
delete_insn (insn);
else if (prev != PREV_INSN (insn))
- reorder_insns_nobb (insn, insn, prev);
+ {
+ basic_block bb = BLOCK_FOR_INSN (prev);
+ rtx_insn *end = PREV_INSN (insn);
+ reorder_insns_nobb (insn, insn, prev);
+ if (bb)
+ {
+ /* If the backend called in machine reorg compute_bb_for_insn
+and didn't free_bb_for_insn again, preserve basic block
+boundaries. Move the end of basic block to PREV since
+it is followed by a barrier now, and clear BLOCK_FOR_INSN
+on the following notes. */
+ BB_END (bb) = prev;
+ do
+ {
+ prev = NEXT_INSN (prev);
+ if (prev != insn BLOCK_FOR_INSN (prev) == bb)
+ BLOCK_FOR_INSN (prev) = NULL;
+ }
+ while (prev != end);
+ }
+ }
}
}
return 0;
--- gcc/testsuite/gcc.dg/pr61058.c.jj 2015-01-22 16:19:16.507023479 +0100
+++ gcc/testsuite/gcc.dg/pr61058.c 2015-01-22 16:19:16.507023479 +0100
@@ -0,0 +1,10 @@
+/* PR rtl-optimization/61058 */
+/* { dg-do compile } */
+/* { dg-options } */
+/* { dg-additional-options -fno-asynchronous-unwind-tables -mtune=atom {
target i?86-*-* x86_64-*-* } } */
+
+void
+foo (void)
+{
+ __builtin_unreachable ();
+}
Jakub
Re: [PATCH, i386] Fix PR 64688, ICE: Max. number of generated reload insns per insn is achieved (90)
On Thu, Jan 22, 2015 at 7:37 PM, Uros Bizjak ubiz...@gmail.com wrote:
Attached patch fixes PR 64688. Operand constraints were wrong for
reg-to-vec targets.
The patch also fixes PR 64477.
Whoops, I have regtested wrong compiler. The patch introduced some
AVX2 regressions. Following patch is also needed, otherwise vec_dup
post-reload splitter creates invalid pattern that involves general reg
for reg-to-vec targets.
Now fixed, attached is the complete patch.
2015-22-01 Uros Bizjak ubiz...@gmail.com
PR target/64688
PR target/64477
* config/i386/sse.md (vec_setmode_0): Use (Yi/r/C) constraints
for alternative 3.
(*vec_dupmode): Use (Yi/$r) constraints for alternative 1.
Bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.
Committed to mainline SVN.
Uros.
Index: config/i386/sse.md
===
--- config/i386/sse.md (revision 219987)
+++ config/i386/sse.md (working copy)
@@ -6391,11 +6391,11 @@
;; see comment above inline_secondary_memory_needed function in i386.c
(define_insn vec_setmode_0
[(set (match_operand:VI4F_128 0 nonimmediate_operand
- =Yr,*v,v,v ,x,x,v,Yr ,*x ,x ,m ,m ,m)
+ =Yr,*v,v,Yi,x,x,v,Yr ,*x ,x ,m ,m ,m)
(vec_merge:VI4F_128
(vec_duplicate:VI4F_128
(match_operand:ssescalarmode 2 general_operand
- Yr,*v,m,*r,m,x,v,*rm,*rm,*rm,!x,!*re,!*fF))
+ Yr,*v,m,r ,m,x,v,*rm,*rm,*rm,!x,!*re,!*fF))
(match_operand:VI4F_128 1 vector_move_operand
C , C,C,C ,C,0,v,0 ,0 ,x ,0 ,0 ,0)
(const_int 1)))]
@@ -16711,7 +16711,7 @@
[V32QI V16QI V16HI V8HI V8SI V4SI])
(define_insn *vec_dupmode
- [(set (match_operand:AVX2_VEC_DUP_MODE 0 register_operand =x,x,x)
+ [(set (match_operand:AVX2_VEC_DUP_MODE 0 register_operand =x,x,Yi)
(vec_duplicate:AVX2_VEC_DUP_MODE
(match_operand:ssescalarmode 1 nonimmediate_operand m,x,$r)))]
TARGET_AVX2
[PATCH] Don't emit backtrace from driver upon fatal compiler signals
Hi!
As has been noted several times in the past, and most recently e.g. in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64511#c13
generating backtrace from internal_error call in driver's execute is
undesirable, there is nothing wrong in the driver, the problem is that
the compiler crashed. This confuses lots of people.
The following patch avoids printing backtrace in that case.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2015-01-22 Jakub Jelinek ja...@redhat.com
* diagnostic-core.h (internal_error_no_backtrace): New prototype.
* diagnostic.def (DK_ICE_NOBT): New kind.
* diagnostic.c (diagnostic_action_after_output): Handle DK_ICE_NOBT
like DK_ICE, but never print backtrace.
(diagnostic_report_diagnostic): Handle DK_ICE_NOBT like DK_ICE.
(internal_error_no_backtrace): New function.
* gcc.c (execute): Use internal_error_no_backtrace instead of
internal_error.
fortran/
* gfc-diagnostic.def (DK_ICE_NOBT): New kind.
--- gcc/diagnostic-core.h.jj2015-01-05 13:07:13.0 +0100
+++ gcc/diagnostic-core.h 2015-01-22 09:09:09.352920684 +0100
@@ -56,6 +56,8 @@ extern const char *trim_filename (const
#endif
extern void internal_error (const char *, ...) ATTRIBUTE_GCC_DIAG(1,2)
ATTRIBUTE_NORETURN;
+extern void internal_error_no_backtrace (const char *, ...)
+ ATTRIBUTE_GCC_DIAG(1,2) ATTRIBUTE_NORETURN;
/* Pass one of the OPT_W* from options.h as the first parameter. */
extern bool warning (int, const char *, ...) ATTRIBUTE_GCC_DIAG(2,3);
extern bool warning_n (location_t, int, int, const char *, const char *, ...)
--- gcc/diagnostic.def.jj 2015-01-05 13:07:13.0 +0100
+++ gcc/diagnostic.def 2015-01-22 09:01:48.575490585 +0100
@@ -45,3 +45,6 @@ DEFINE_DIAGNOSTIC_KIND (DK_PERMERROR, p
/* This one is just for counting DK_WARNING promoted to DK_ERROR
due to -Werror and -Werror=warning. */
DEFINE_DIAGNOSTIC_KIND (DK_WERROR, error: , NULL)
+/* This is like DK_ICE, but backtrace is not printed. Used in the driver
+ when reporting fatal signal in the compiler. */
+DEFINE_DIAGNOSTIC_KIND (DK_ICE_NOBT, internal compiler error: , error)
--- gcc/diagnostic.c.jj 2015-01-05 13:07:15.0 +0100
+++ gcc/diagnostic.c2015-01-22 09:13:34.166407314 +0100
@@ -518,9 +518,11 @@ diagnostic_action_after_output (diagnost
break;
case DK_ICE:
+case DK_ICE_NOBT:
{
- struct backtrace_state *state =
- backtrace_create_state (NULL, 0, bt_err_callback, NULL);
+ struct backtrace_state *state = NULL;
+ if (diag_kind == DK_ICE)
+ state = backtrace_create_state (NULL, 0, bt_err_callback, NULL);
int count = 0;
if (state != NULL)
backtrace_full (state, 2, bt_callback, bt_err_callback,
@@ -739,7 +741,8 @@ diagnostic_report_diagnostic (diagnostic
/* If we're reporting an ICE in the middle of some other error,
try to flush out the previous error, then let this one
through. Don't do this more than once. */
- if (diagnostic-kind == DK_ICE context-lock == 1)
+ if ((diagnostic-kind == DK_ICE || diagnostic-kind == DK_ICE_NOBT)
+ context-lock == 1)
pp_newline_and_flush (context-printer);
else
error_recursion (context);
@@ -812,7 +815,7 @@ diagnostic_report_diagnostic (diagnostic
context-lock++;
- if (diagnostic-kind == DK_ICE)
+ if (diagnostic-kind == DK_ICE || diagnostic-kind == DK_ICE_NOBT)
{
#ifndef ENABLE_CHECKING
/* When not checking, ICEs are converted to fatal errors when an
@@ -1237,6 +1240,23 @@ internal_error (const char *gmsgid, ...)
report_diagnostic (diagnostic);
va_end (ap);
+ gcc_unreachable ();
+}
+
+/* Like internal_error, but no backtrace will be printed. Used when
+ the internal error does not happen at the current location, but happened
+ somewhere else. */
+void
+internal_error_no_backtrace (const char *gmsgid, ...)
+{
+ diagnostic_info diagnostic;
+ va_list ap;
+
+ va_start (ap, gmsgid);
+ diagnostic_set_info (diagnostic, gmsgid, ap, input_location, DK_ICE_NOBT);
+ report_diagnostic (diagnostic);
+ va_end (ap);
+
gcc_unreachable ();
}
--- gcc/gcc.c.jj2015-01-15 23:39:03.0 +0100
+++ gcc/gcc.c 2015-01-22 09:06:03.565111399 +0100
@@ -2909,8 +2909,9 @@ execute (void)
}
else
#endif
- internal_error (%s (program %s),
- strsignal (WTERMSIG (status)), commands[i].prog);
+ internal_error_no_backtrace (%s (program %s),
+ strsignal (WTERMSIG (status)),
+ commands[i].prog);
}
else if (WIFEXITED (status)
WEXITSTATUS (status) = MIN_FATAL_STATUS)
--- gcc/fortran/gfc-diagnostic.def.jj 2015-01-05 13:07:19.0 +0100
+++ gcc/fortran/gfc-diagnostic.def 2015-01-22
Re: [PING]: [PATCH]: Conditionally include target specific files while building TSAN
On Thu, Jan 22, 2015 at 06:16:53PM +0400, Dmitry Vyukov wrote: On Thu, Jan 22, 2015 at 5:03 PM, Jakub Jelinek ja...@redhat.com wrote: On Thu, Jan 22, 2015 at 07:30:50PM +0530, Venkataramanan Kumar wrote: ping. Forgot to mention, GCC bootstraps and regression testing passed on x86_64. Well, without a change from upstream to guard the HACKY_CALL and actual tsan port to non-x86_64 this patch doesn't solve anything. I've just committed that change upstream: http://llvm.org/viewvc/llvm-project?view=revisionrevision=226829 Now we need to summon +Kostya to update gcc version of runtime. Here is what I've committed: 2015-01-22 Jakub Jelinek ja...@redhat.com * tsan/tsan_rtl.h: Cherry pick upstream r226829. --- libsanitizer/tsan/tsan_rtl.h(revision 226828) +++ libsanitizer/tsan/tsan_rtl.h(revision 226829) @@ -679,7 +679,7 @@ void AcquireReleaseImpl(ThreadState *thr // The trick is that the call preserves all registers and the compiler // does not treat it as a call. // If it does not work for you, use normal call. -#if TSAN_DEBUG == 0 +#if TSAN_DEBUG == 0 defined(__x86_64__) // The caller may not create the stack frame for itself at all, // so we create a reserve stack frame for it (1024b must be enough). #define HACKY_CALL(f) \ Jakub
Re: [patch] gcc fstack-protector-explicit
On Thu, Jan 22, 2015 at 09:35:45AM -0700, Jeff Law wrote:
Though wonder if for the TARGET_LIBC_PROVIDES_SSP case LINK_SSP_SPEC
shouldn't be
#define LINK_SSP_SPEC
{fstack-protector|fstack-protector-strong|fstack-protector-explicit|fstack-protector-all:}
and
gcc/config/freebsd.h:
#define LINK_SSP_SPEC
%{fstack-protector|fstack-protector-all:-lssp_nonshared}
should be changed too (adding both -string and -explicit).
Ranier, sorry about the breakage on Solaris.
WRT other LINK_SPECs, yea, they all need to check the 4 variants of
-fstack-protector-whatever and if any are found, link in libssp.
Patch to fix that pre-approved.
Here is what I've committed.
2015-01-22 Rainer Orth r...@cebitec.uni-bielefeld.de
Jakub Jelinek ja...@redhat.com
* gcc.c (LINK_SSP_SPEC): Handle -fstack-protector-explicit
for !TARGET_LIBC_PROVIDES_SSP version and
-fstack-protector-{all,strong,explicit} otherwise.
* config/freebsd.h (LINK_SSP_SPEC): Handle
-fstack-protector-{strong,explicit}.
--- gcc/gcc.c.jj2015-01-22 11:59:32.0 +0100
+++ gcc/gcc.c 2015-01-22 17:42:17.965531999 +0100
@@ -728,9 +728,12 @@ proper position among the other output f
#ifndef LINK_SSP_SPEC
#ifdef TARGET_LIBC_PROVIDES_SSP
-#define LINK_SSP_SPEC %{fstack-protector:}
+#define LINK_SSP_SPEC %{fstack-protector|fstack-protector-all \
+ |fstack-protector-strong|fstack-protector-explicit:}
#else
-#define LINK_SSP_SPEC
%{fstack-protector|fstack-protector-strong|fstack-protector-all:-lssp_nonshared
-lssp}
+#define LINK_SSP_SPEC %{fstack-protector|fstack-protector-all \
+ |fstack-protector-strong|fstack-protector-explicit \
+ :-lssp_nonshared -lssp}
#endif
#endif
--- gcc/config/freebsd.h.jj 2015-01-05 13:07:15.0 +0100
+++ gcc/config/freebsd.h2015-01-22 17:43:12.504603764 +0100
@@ -49,7 +49,9 @@ along with GCC; see the file COPYING3.
#endif
#ifdef TARGET_LIBC_PROVIDES_SSP
-#define LINK_SSP_SPEC
%{fstack-protector|fstack-protector-all:-lssp_nonshared}
+#define LINK_SSP_SPEC %{fstack-protector|fstack-protector-all \
+ |fstack-protector-strong|fstack-protector-explicit \
+ :-lssp_nonshared}
#endif
#undef TARGET_LIBC_HAS_FUNCTION
Jakub
Re: [PATCH] toplev.c: Process the failure when read fails for random_seed
On 01/23/2015 03:53 AM, Jeff Law wrote: On 01/22/15 12:42, Chen Gang S wrote: Thank you very much for your help applying the 3 patches. :-) No problem. After finish the assignment working flow, I guess, I may have the write access, then can finish these kinds of trivial patches by myself (will not always bother other members any more). Exactly. They'll still need review/approval, but once approved, you'll be able to commit them yourself. OK, thanks. I guess that is Write After Approval maintainer role. And I want to consult: for passing assignment working flow, must I make a patch which contents much code lines? (At present, my patches are all trivial patch). If really need a patch which contents enough code lines, please let me know, and I shall try. Thanks. -- Open, share, and attitude like air, water, and life which God blessed.
Re: [ping] Re: [patch, rfc] fix warning building libssp in C11 mode
On 01/22/15 08:45, Matthias Klose wrote: ping now that C11 mode is the default, can we avoid the warning? Ick. Part of me wants to say drop the gets intercepting and just issue some kind of error for C11 mode. Part of me wants to ignore the issue and accept the warning. Part of me wants to look at the two paths where we call gets and punt them somehow. But in the end, adding the prototype is probably best, though I'm sure some lame-o system will have a ever-so-slightly different prototype that will cause a build failure. Part of me would like to just punt until gcc-6 when fallout would be lighter. But ISTM that without a proper prototype in place, we could get wrong code here on 64 bit platforms. So, I guess go forward with the prototype. We may have to adjust the guard further if other platforms fail to build. jeff
Re: [PATCH PR64557] get_addr in true_dependence_1 cannot handle VALUE inside an expr
On 01/21/15 15:32, Wei Mi wrote: Hi, The patch is to address the bug here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64557 It is to call get_addr for VALUE before forming a mem_addr expr with the VALUE and an offset. This is to avoid the problem that get_addr can only handle VALUE but cannot handle an expr like: (VALUE + offset). With the fix, find_base_term can always get the base of the original addr. bootstrap and regression test on x86_64-linux-gnu are ok. regression tests on aarch64-linux-gnu and powerpc64-linux-gnu are also ok. Is it ok for trunk? Thanks, Wei. gcc/ChangeLog: 2015-01-21 Wei Mi w...@google.com * dse.c (record_store): Call get_addr for mem_addr. (check_mem_read_rtx): Likewise. Please add a PR marker to the ChangeLog entry. A testcase would be great, but from reading the PR that doesn't seem possible without some heroic efforts. OK with the PR marker and a comment before the two calls indicating why those two calls are necessary. jeff
Re: [PATCH] Workaround -Wmaybe-uninitialized false positives during profiledbootstrap
On 01/19/15 11:30, Martin Liška wrote: On 01/19/2015 03:48 PM, Jakub Jelinek wrote: On Mon, Jan 19, 2015 at 03:44:20PM +0100, Martin Liška wrote: There's a bunch of another places that emit false positives. With following patch, I am able to run profiledbootstrap on x86_64-linux-pc and ppc64-linux-pc. I don't know what we consider standard and where we allow warnings and thus require --disable-werror, so will defer to Richard. --- a/gcc/tree.h +++ b/gcc/tree.h @@ -3050,6 +3050,11 @@ tree_int_cst_elt_check (tree __t, int __i, return CONST_CAST_TREE (__t)-int_cst.val[__i]; } +/* Workaround -Wstrict-overflow false positive during profiledbootstrap. */ + +#pragma GCC diagnostic push +#pragma GCC diagnostic ignored -Wstrict-overflow Just I wonder if this shouldn't be guarded by GCC_VERSION = something that actually supports those. Thank you Jakub, you are right that this feature was added in 4.4 ([1]). I send a new version of the patch. Thanks, Martin [1] https://gcc.gnu.org/gcc-4.4/changes.html + inline tree * tree_vec_elt_check (tree __t, int __i, const char *__f, int __l, const char *__g) @@ -3061,6 +3066,8 @@ tree_vec_elt_check (tree __t, int __i, return CONST_CAST_TREE (__t)-vec.a[__i]; } +#pragma GCC diagnostic pop + inline tree * omp_clause_elt_check (tree __t, int __i, const char *__f, int __l, const char *__g) Jakub 0001-Remove-false-positives-for-warnings-that-break-LTO-p.patch From d3fb9b15c2ac00e2e265925b2e822e1e20dc39af Mon Sep 17 00:00:00 2001 From: mliskamli...@suse.cz Date: Mon, 19 Jan 2015 13:30:53 +0100 Subject: [PATCH] Remove false positives for warnings that break LTO profiled bootstrap. gcc/ChangeLog: 2015-01-19 Martin Liskamli...@suse.cz * tree.h (tree_vec_elt_check): Workaround -Wstrict-overflow false positive during profiledbootstrap. gcc/fortran/ChangeLog: 2015-01-19 Martin Liskamli...@suse.cz * decl.c (attr_decl1): Workaround -Wmaybe-uninitialized false positive during profiledbootstrap by initializing them. * matchexp.c (match_mult_operand): Likewise. * module.c (write_atom): Likewise. (read_module): Likewise. OK for the trunk. Thanks for marking these as working around -Wmaybe-uninitialized false positives. I'm going to assume that the initializer value you selected was a good one. Jeff
Re: [PATCH PR64557] get_addr in true_dependence_1 cannot handle VALUE inside an expr
Thanks for the review. Comments addressed and patch committed. The problem exists on gcc-4_9 too. Is it ok for gcc-4_9-branch? Will wait another day to commit it to gcc-4_9 if it is ok. Thanks, Wei. On Thu, Jan 22, 2015 at 9:39 AM, Jeff Law l...@redhat.com wrote: On 01/21/15 15:32, Wei Mi wrote: Hi, The patch is to address the bug here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64557 It is to call get_addr for VALUE before forming a mem_addr expr with the VALUE and an offset. This is to avoid the problem that get_addr can only handle VALUE but cannot handle an expr like: (VALUE + offset). With the fix, find_base_term can always get the base of the original addr. bootstrap and regression test on x86_64-linux-gnu are ok. regression tests on aarch64-linux-gnu and powerpc64-linux-gnu are also ok. Is it ok for trunk? Thanks, Wei. gcc/ChangeLog: 2015-01-21 Wei Mi w...@google.com * dse.c (record_store): Call get_addr for mem_addr. (check_mem_read_rtx): Likewise. Please add a PR marker to the ChangeLog entry. A testcase would be great, but from reading the PR that doesn't seem possible without some heroic efforts. OK with the PR marker and a comment before the two calls indicating why those two calls are necessary. jeff
Re: flatten expr.h (version 2)
On 21 January 2015 at 23:18, Eric Botcazou ebotca...@adacore.com wrote: Thanks. I had wrongly made eliminate_constant_term() static, reverted that change and it builds on all targets in config-list.mk. Committed as r219655 (hopefully nothing breaks!). Any particular reason why store_bit_field, extract_bit_field, extract_low_bits expand_mult and expand_mult_highpart_adjust are declared in emit-rtl.h? Thanks, moved them to expmed.h. Boostrapped on x86_64-unknown-linux-gnu with languages: all, testing in progress. Build on all targets in config-list.mk in progress. Assuming it goes fine, OK to commit ? Thanks, Prathamesh -- Eric Botcazou 2015-01-22 Prathamesh Kulkarni prathamesh.kulka...@linaro.org * emit-rtl.h (store_bit_field): Move prototype to expmed.h. (extract_bit_field): Likewise. (extract_low_bits): Likewise. (expand_mult): Likewise. (expand_mult_highpart_adjust): Likewise. Index: gcc/emit-rtl.h === --- gcc/emit-rtl.h (revision 219882) +++ gcc/emit-rtl.h (working copy) @@ -189,17 +189,4 @@ MODE and adjusted by OFFSET. */ extern rtx widen_memory_access (rtx, machine_mode, HOST_WIDE_INT); -extern void store_bit_field (rtx, unsigned HOST_WIDE_INT, - unsigned HOST_WIDE_INT, - unsigned HOST_WIDE_INT, - unsigned HOST_WIDE_INT, - machine_mode, rtx); -extern rtx extract_bit_field (rtx, unsigned HOST_WIDE_INT, - unsigned HOST_WIDE_INT, int, rtx, - machine_mode, machine_mode); -extern rtx extract_low_bits (machine_mode, machine_mode, rtx); -extern rtx expand_mult (machine_mode, rtx, rtx, rtx, int); -extern rtx expand_mult_highpart_adjust (machine_mode, rtx, rtx, rtx, rtx, int); - - #endif /* GCC_EMIT_RTL_H */ Index: gcc/expmed.h === --- gcc/expmed.h (revision 219882) +++ gcc/expmed.h (working copy) @@ -703,4 +703,16 @@ rtx, int); #endif +extern void store_bit_field (rtx, unsigned HOST_WIDE_INT, + unsigned HOST_WIDE_INT, + unsigned HOST_WIDE_INT, + unsigned HOST_WIDE_INT, + machine_mode, rtx); +extern rtx extract_bit_field (rtx, unsigned HOST_WIDE_INT, + unsigned HOST_WIDE_INT, int, rtx, + machine_mode, machine_mode); +extern rtx extract_low_bits (machine_mode, machine_mode, rtx); +extern rtx expand_mult (machine_mode, rtx, rtx, rtx, int); +extern rtx expand_mult_highpart_adjust (machine_mode, rtx, rtx, rtx, rtx, int); + #endif // EXPMED_H
Re: [[ARM/AArch64][testsuite] 05/36] Add vldX_dup test.
On 22 January 2015 at 17:17, Tejas Belagod tejas.bela...@arm.com wrote: LGTM. Thanks, I should mention that this test fails on aarch64_be, because of pending Alan's patches. A few big-endian fixes were checked in last night. Do you mean this? r219957 | rsandifo | 2015-01-21 17:53:04 + (Wed, 21 Jan 2015) | 6 lines gcc/ 2015-01-25 Alan Hayward alan.hayw...@arm.com * rtlanal.c (subreg_get_info): Exit early for simple and common cases. Yes. I committed my test as r219914 and saw my automatic validation results as FAIL for aarch64_be. I expect them to move to PASS when r219957 will be validated. If not, I'll let you know :-) Thanks, Tejas.
[PATCH][PR 52076 P3 regression] Improve m68k xor and bit insertion
Just knocking out another m68k issue since I've got my little aranym
setup running.
This BZ is a quality of code regression relative to very old versions of
GCC for two code sequences.
First, setting a bitfield to all ones. Right now we're doing this via
moveq/bfins. It's a 6 byte sequence and uses a register. We can do
better using or.b imm,ea which is a 4 byte sequence with no scratch
register needed. The trick here is to detect that we're setting a field
to all ones and rewriting the RTL to look like insv_bfset_reg during the
insv expander. That in turn looks nice to combine which combines it
with the memory references into the or.b insn.
The second sequence is turning a single bit on within a bitfield. At
some point GCC stopped using a single or.[bw] and instead generated a
movb imm,scr; or.l scr,ea, which is two bytes longer than the or.[bw]
imm,ea and uses a scratch register. At some unknown point since the
report was filed, we changed movb imm,scr into moveq imm,scr. That
brought the code sequence back to parity WRT size. We still use an
unnecessary scratch and I'm sure the two sequences run at different
speeds depending on the cpu variant in use.
Further testing showed that xor of a single bit in a bitfield was
generating poor code. Tweaking the constraints fixed it to behave like
ior and.
With that small xor issue fixed, the sequences we generate are the same
size as direct manipulation via [or|eor|and].[bw]. Selecting between
the same sized sequences based on target processor's characteristics
probably isn't worth the effort and I'm not considering that part of
this BZ.
Tested by building m68k-elf as a cross, then running the m68k.exp
testsuite and by an ongoing bootstrap on m68k linux (into stage2
libraries right now, not expecting problems).
Installed on the trunk.
commit 2384fd2cc186c1de5b65db282ef8c67674e851df
Author: Jeff Law l...@redhat.com
Date: Thu Jan 22 14:21:21 2015 -0700
PR target/52076
* config/m68k/m68k.md (xorsi3_internal): Twiddle constraints to
improve code density for small immediate to memory case.
(insv): Better handle bitfield assignments when the field is
being set to all ones.
* config/m68k/predicates.md (reg_or_pow2_m1_operand): New
operand predicate.
PR target/52076
* gcc.target/m68k/pr52076-1.c: New test.
* gcc.target/m68k/pr52076-2.c: New test.
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index c166933..ae5e9a5 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,13 @@
+2015-01-22 Jeff Law l...@redhat.com
+
+ PR target/52076
+ * config/m68k/m68k.md (xorsi3_internal): Twiddle constraints to
+ improve code density for small immediate to memory case.
+ (insv): Better handle bitfield assignments when the field is
+ being set to all ones.
+ * config/m68k/predicates.md (reg_or_pow2_m1_operand): New
+ operand predicate.
+
2015-01-22 Rainer Orth r...@cebitec.uni-bielefeld.de
Jakub Jelinek ja...@redhat.com
diff --git a/gcc/config/m68k/.m68k.md.swp b/gcc/config/m68k/.m68k.md.swp
new file mode 100755
index 000..36d7681
Binary files /dev/null and b/gcc/config/m68k/.m68k.md.swp differ
diff --git a/gcc/config/m68k/m68k.md b/gcc/config/m68k/m68k.md
index d34ad1d..6bb296e 100644
--- a/gcc/config/m68k/m68k.md
+++ b/gcc/config/m68k/m68k.md
@@ -3838,9 +3838,9 @@
)
(define_insn xorsi3_internal
- [(set (match_operand:SI 0 nonimmediate_operand =do,m)
- (xor:SI (match_operand:SI 1 general_operand %0,0)
-(match_operand:SI 2 general_operand di,dKT)))]
+ [(set (match_operand:SI 0 nonimmediate_operand =d,o,m)
+ (xor:SI (match_operand:SI 1 general_operand %0, 0,0)
+(match_operand:SI 2 general_operand di,dK,dKT)))]
!TARGET_COLDFIRE
{
@@ -5583,9 +5583,20 @@
[(set (zero_extract:SI (match_operand:SI 0 nonimmediate_operand )
(match_operand:SI 1 const_int_operand )
(match_operand:SI 2 const_int_operand ))
- (match_operand:SI 3 register_operand ))]
+ (match_operand:SI 3 reg_or_pow2_m1_operand ))]
TARGET_68020 TARGET_BITFIELD
- )
+
+{
+ /* Special case initializing a field to all ones. */
+ if (GET_CODE (operands[3]) == CONST_INT)
+{
+ if (exact_log2 (INTVAL (operands[3]) + 1) != INTVAL (operands[1]))
+ operands[3] = force_reg (SImode, operands[3]);
+ else
+ operands[3] = constm1_rtx;
+
+}
+})
(define_insn *insv_bfins_mem
[(set (zero_extract:SI (match_operand:QI 0 memory_operand +o)
diff --git a/gcc/config/m68k/predicates.md b/gcc/config/m68k/predicates.md
index a7b5c42..c652f10 100644
--- a/gcc/config/m68k/predicates.md
+++ b/gcc/config/m68k/predicates.md
@@ -244,3 +244,16 @@
|| reload_in_progress
|| reload_completed));
})
+
+;; Used to detect when an operand is either a register
+;; or a constant
Re: [Patch, Fortran] PR64726 Fix OpenACC's parallel/kernel loop
Cesar Philippidis wrote: It looks OK to me. In fact, I have an identical patch in our internal branch and I don't know why it didn't make its way upstream or at least into gomp-4_0-branch. Maybe it got lost after stage 1 closed. I have now committed it as Rev. 220028. Tobias
Re: [PATCH] Don't emit backtrace from driver upon fatal compiler signals
Ian Lance Taylor i...@golang.org writes: On Thu, Jan 22, 2015 at 12:35 PM, Jakub Jelinek ja...@redhat.com wrote: 2015-01-22 Jakub Jelinek ja...@redhat.com * diagnostic-core.h (internal_error_no_backtrace): New prototype. * diagnostic.def (DK_ICE_NOBT): New kind. * diagnostic.c (diagnostic_action_after_output): Handle DK_ICE_NOBT like DK_ICE, but never print backtrace. (diagnostic_report_diagnostic): Handle DK_ICE_NOBT like DK_ICE. (internal_error_no_backtrace): New function. * gcc.c (execute): Use internal_error_no_backtrace instead of internal_error. fortran/ * gfc-diagnostic.def (DK_ICE_NOBT): New kind. This is OK. FWIW, this is fine from me too, Thanks for taking care of this. Indeed. Cheers, -- Dodji
