Re: [SH] Introduce treg_set_expr
On Sun, 2015-01-18 at 13:25 +0100, Oleg Endo wrote:
On Sat, 2015-01-17 at 22:40 +0900, Kaz Kojima wrote:
Oleg Endo oleg.e...@t-online.de wrote:
Kaz, could you please test the patch on your sh4-linux setup and report
your findings? Even though it's a bit late, I'd like to get this in for
GCC 5, if it doesn't break too many things.
Looks wrong code problem for tls and atomic constructs.
Here is the result of compare_tests for unpatched/patched
sh4-unknown-linux-gnu compilers:
New tests that FAIL:
...
Thanks. Doesn't look so bad actually. I've expected worse. These are
the two problems:
1) sh_find_extending_set_of_reg (introduced earlier as part of PR 53988)
hits atomic insns, which in fact do a indirect sign extending mem load.
The cmpeqsi_t splitter for const_int 0 then tries to use the value as
sign extended, which wrongly converts an atomic into a simple mem load.
The easy solution is not to report 'sign extended' in
sh_find_extending_set_of_reg for mems that are buried in UNSPEC/UNSPECV
insns. This also revealed a problem of inconsistent return values of
sh_find_set_of_reg. This should be fixed regardless of the
treg_set_expr stuff first. I'll create separate patch for that.
The attached patch fixes this issue.
Tested with
make -k check RUNTESTFLAGS=--target_board=sh-sim
\{-m2/-ml,-m2/-mb,-m2a/-mb,-m4/-ml,-m4/-mb,-m4a/-ml,-m4a/-mb}
Committed as r219864.
Cheers,
Oleg
Index: gcc/config/sh/sh.c
===
--- gcc/config/sh/sh.c (revision 219863)
+++ gcc/config/sh/sh.c (working copy)
@@ -13738,22 +13738,15 @@
/* Return true if the specified insn contains any UNSPECs or
UNSPEC_VOLATILEs. */
static bool
-sh_unspec_insn_p (rtx_insn* insn)
+sh_unspec_insn_p (rtx x)
{
- bool result = false;
+ subrtx_iterator::array_type array;
+ FOR_EACH_SUBRTX (i, array, x, ALL)
+if (*i != NULL
+ (GET_CODE (*i) == UNSPEC || GET_CODE (*i) == UNSPEC_VOLATILE))
+ return true;
- struct note_uses_func
- {
-static void
-func (rtx* x, void* data)
-{
- if (GET_CODE (*x) == UNSPEC || GET_CODE (*x) == UNSPEC_VOLATILE)
- *(static_castbool* (data)) = true;
-}
- };
-
- note_uses (PATTERN (insn), note_uses_func::func, result);
- return result;
+ return false;
}
/* Return true if the register operands of the specified insn are modified
@@ -13770,7 +13763,8 @@
subrtx_iterator::array_type array;
FOR_EACH_SUBRTX (i, array, SET_SRC (s), ALL)
-if ((REG_P (*i) || SUBREG_P (*i)) reg_set_between_p (*i, from, to))
+if (*i != NULL
+ ((REG_P (*i) || SUBREG_P (*i)) reg_set_between_p (*i, from, to)))
return true;
return false;
@@ -13927,7 +13921,7 @@
|| GET_CODE (result.set_src) == ZERO_EXTEND)
{
if (dump_file)
- fprintf (dump_file, sh_find_szexnteded_reg: reg %d is
+ fprintf (dump_file, sh_find_extending_set_of_reg: reg %d is
explicitly sign/zero extended in insn %d\n,
REGNO (reg), INSN_UID (result.insn));
result.from_mode = GET_MODE (XEXP (result.set_src, 0));
@@ -13935,7 +13929,8 @@
}
else if (MEM_P (result.set_src)
(GET_MODE (result.set_src) == QImode
- || GET_MODE (result.set_src) == HImode))
+ || GET_MODE (result.set_src) == HImode)
+ !sh_unspec_insn_p (result.insn))
{
/* On SH QIHImode memory loads always sign extend. However, in
some cases where it seems that the higher bits are not
Index: gcc/config/sh/sh-protos.h
===
--- gcc/config/sh/sh-protos.h (revision 219863)
+++ gcc/config/sh/sh-protos.h (working copy)
@@ -192,11 +192,13 @@
if (!REG_P (reg) || insn == NULL_RTX)
return result;
+ rtx_insn* previnsn = insn;
+
for (result.insn = stepfunc (insn); result.insn != NULL_RTX;
- result.insn = stepfunc (result.insn))
+ previnsn = result.insn, result.insn = stepfunc (result.insn))
{
if (BARRIER_P (result.insn))
- return result;
+ break;
if (!NONJUMP_INSN_P (result.insn))
continue;
if (reg_set_p (reg, result.insn))
@@ -204,7 +206,7 @@
result.set_rtx = set_of (reg, result.insn);
if (result.set_rtx == NULL_RTX || GET_CODE (result.set_rtx) != SET)
- return result;
+ break;
result.set_src = XEXP (result.set_rtx, 1);
@@ -220,10 +222,19 @@
continue;
}
- return result;
+ break;
}
}
+ /* If the loop above stopped at the first insn in the list,
+ result.insn will be null. Use the insn from the previous iteration
+ in this case. */
+ if (result.insn == NULL)
+result.insn = previnsn;
+
+ if (result.set_src != NULL)
+gcc_assert (result.insn != NULL result.set_rtx != NULL);
+
return result;
}
RE: [PATCH,MIPS] Only pass floating-point options to the assembler then
Moore, Catherine catherine_mo...@mentor.com writes:
-Original Message-
From: Matthew Fortune [mailto:matthew.fort...@imgtec.com]
Sent: Monday, January 19, 2015 5:54 PM
To: Moore, Catherine
Cc: 'gcc-patches@gcc.gnu.org' (gcc-patches@gcc.gnu.org)
Subject: RE: [PATCH,MIPS] Only pass floating-point options to the
assembler then
Hi Catherine,
The new behaviour of the GCC driver passing floating point options
like -msoft-float to the assembler is essential for the new o32 ABI
extensions but is a change in behaviour. In particular GCC 5 used
with binutils 2.24 would require a user to fix any hand-crafted code
that made use of floating-point instructions when building for soft-
float.
This patch limits the new behaviour to a combination of GCC and
binutils that both have the new ABI support.
This patch along with parts of several previous patches need
backporting to GCC 4.9 (and GCC 4.8) to enable use of binutils 2.25
with those compilers. The GCC 4.9 patch will be posted shortly.
I'm not sure if you missed this patch last week or if you are unsure
about it?
Since this is about restoring previous behaviour of MIPS GCC when
built alongside binutils = 2.24 I believe this still fits with stage4
criteria.
Hi Matthew,
I didn't miss it, but I wanted to complete some testing with it. Those
tests have now completed and this patch is OK.
Sorry for the delay.
No problem, just getting it resolved early so I can focus on bug hunting
and fixing. Thanks for doing some testing on it.
I'm going to try writing up the main MIPS changes for the GCC 5 changes
webpage. I'll send a list to you once I've been through the code changes.
Thanks,
Matthew
Thanks,
Catherine
gcc/
* config/mips/mips.h (FP_ASM_SPEC): New define.
(ASM_SPEC): Remove floating-point options and use FP_ASM_SPEC
instead.
---
gcc/config/mips/mips.h | 21 ++---
1 file changed, 18 insertions(+), 3 deletions(-)
diff --git a/gcc/config/mips/mips.h b/gcc/config/mips/mips.h index
37d4cb4..ed241fa 100644
--- a/gcc/config/mips/mips.h
+++ b/gcc/config/mips/mips.h
@@ -1243,6 +1243,22 @@ struct mips_cpu_info { %{gcoff*:-mdebug}
%{!gcoff*:-no-mdebug}
#endif
+/* FP_ASM_SPEC represents the floating-point options that must be
passed
+ to the assembler when FPXX support exists. Prior to that point
the
+ assembler could accept the options but were not required for
+ correctness. We only add the options when absolutely necessary
+ because passing -msoft-float to the assembler will cause it to
reject
+ all hard-float instructions which may require some user code to
be
+ updated. */
+
+#ifdef HAVE_AS_DOT_MODULE
+#define FP_ASM_SPEC \
+%{mhard-float} %{msoft-float} \
+%{msingle-float} %{mdouble-float}
+#else
+#define FP_ASM_SPEC
+#endif
+
/* SUBTARGET_ASM_SPEC is always passed to the assembler. It may be
overridden by subtargets. */
@@ -1277,9 +1293,8 @@ struct mips_cpu_info { %{modd-spreg} %{mno-
odd-
spreg} \ %{mshared} %{mno-shared} \ %{msym32} %{mno-sym32} \ -
%{mtune=*} \ -%{mhard-float} %{msoft-float} \ -%{msingle-float}
%{mdouble-float} \
+%{mtune=*} \
+FP_ASM_SPEC \
%(subtarget_asm_spec)
/* Extra switches sometimes passed to the linker. */
--
2.2.1
Re: [Patch, libstdc++/64649] Fix regex_traits::lookup_collatename and regex_traits::lookup_classname
On Mon, Jan 19, 2015 at 3:28 PM, Tim Shen tims...@google.com wrote: I just noticed that if we want to implement it 100% accurately, narrowing down the input string to char string is clearly wrong. Let me take that back, since [22.4.1.1.2].12 requires that do_widen(do_narrow(c,0)) == c, which gives us a chance to use narrow and still be accurate. I think it'll be a quick fix. -- Regards, Tim Shen
Re: [PING] [PATCH] Fix parameters of __tsan_vptr_update
[text-only] On Mon, Jan 19, 2015 at 7:42 AM, Mike Stump mikest...@comcast.net wrote: On Jan 19, 2015, at 12:43 AM, Dmitry Vyukov dvyu...@google.com wrote: I can't really make my mind on this. I would mildly prefer sleep's (if they work reliably!). Let me state it more forcefully. You don't have to convince us here. I'd love to get rid of sleep calls in the tsan test suite -- they are a minor but a constant annoyance. But I also want to keep the tests *very simple*, i.e. 1. Single file w/o any non-system includes, no linking of extra libraries/objects 2. Not too much extra code. (ideally, 1 line for init, 1 line for signal, 1 line for wait) 3. Strictly posix or c++11 (unless we are testing something specific) Your idea with barrier_wait/dlsym sounds interesting, but I can't see the code in this mail thread. What do I miss? sleeps are not now, nor in the history of computing ever been a synchronization primitive, except for hard real time systems. If they were, you would be able to cite a paper that uses them. If I am wrong, I’d welcome a cite. Any failure of sleep to work is a indication that that system is not a real time system, and the entirety of the gcc test suite is non-real time code (unless someone snuck some in while I wasn’t watching). Only a synchronization primitive can make the test cases deterministic, therefore, sleep can never be used as a syntonization primitive in the gcc test suite. Kostya, you had experience with both approaches. What are you thoughts on this? StealthNotification definitely makes tests faster and more reliable. Yep. To me, reliability isn’t a continuum for the gcc test suite. It is binary. It is, or, is not reliable and deterministic. The standard for the gcc test suite is to be realible and deterministic. can't really come up with any objective downsides. he downside is more code in tests. If we can satisfy my definition of *very simple* (above) -- let's do it. not to mention that they waste testing time. We discussed this. With a parallel test runner this is not a problem. I don't say the sleeps are good, I just say that testing time is not an argument against them. Flakiness is. --kcc Nor I.
Re: [PATCH] Fix PR64313
On Mon, 19 Jan 2015, Richard Biener wrote: c/ * c-decl.c (merge_decls): Call set_builtin_decl_declared_p for builtins the user declared correctly. The C front-end change is OK. -- Joseph S. Myers jos...@codesourcery.com
[PATCH] pr 60211 - error out if ivdep pragma is outside a function
From: Trevor Saunders tbsaunde+...@tbsaunde.org
Hi,
not doing $subject caused ICES when we tried to parse statements outside of
functions. Just copy the similar code for other pragmas that effect
statements.
bootstrapped + regtested x86_64-linux-gnu, ok?
Trev
diff --git a/gcc/cp/ChangeLog b/gcc/cp/ChangeLog
index f60141d..d9c3ad6 100644
--- a/gcc/cp/ChangeLog
+++ b/gcc/cp/ChangeLog
@@ -1,3 +1,8 @@
+2015-01-18 Trevor Saunders tsaund...@mozilla.com
+
+ * parser.c (cp_parser_pragma): Check if ivdep pragma is within a
+ function.
+
2015-01-09 Michael Collison michael.colli...@linaro.org
* call.c: Include hash-set.h, machmode.h, vec.h, double-int.h,
diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index 3290dfa..4f02a65 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -32202,6 +32202,13 @@ cp_parser_pragma (cp_parser *parser, enum
pragma_context context)
case PRAGMA_IVDEP:
{
+ if (context == pragma_external)
+ {
+ error_at (pragma_tok-location,
+ %#pragma GCC ivdep% must be inside a function);
+ break;
+ }
+
cp_parser_skip_to_pragma_eol (parser, pragma_tok);
cp_token *tok;
tok = cp_lexer_peek_token (the_parser-lexer);
diff --git a/gcc/testsuite/g++.dg/pr60211.C b/gcc/testsuite/g++.dg/pr60211.C
new file mode 100644
index 000..f00e644
--- /dev/null
+++ b/gcc/testsuite/g++.dg/pr60211.C
@@ -0,0 +1,11 @@
+// { dg-do compile }
+void foo() {}
+int x;
+#pragma GCC ivdep // { dg-error must be inside a function }
+for ( ; ) // { dg-error expected unqualified-id before }
+ ;
+
+ void baz() {}
+#pragma GCC ivdep // { dg-error must be inside a function }
+ for (int x = 0; ) // { dg-error expected unqualified-id before }
+ ;
--
2.1.4
Make branch_cost indpenent of optimize_size
Hi,
this patch makes branch_cost to be stable over optimize_size and optimize
to allow inlining. This is safe because BRANCH_COST macro will use constant of
2 for all branches optimized for size.
Bootstrapped/regtested x86_64-linux, comitted.
PR lto/45375
* i386.c (ix86_option_override_internal): Use ix86_tune_cost
to set branch cost.
Index: config/i386/i386.c
===
--- config/i386/i386.c (revision 219876)
+++ config/i386/i386.c (working copy)
@@ -3919,7 +3919,7 @@ ix86_option_override_internal (bool main
/* Provide default for -mbranch-cost= value. */
if (!opts_set-x_ix86_branch_cost)
-opts-x_ix86_branch_cost = ix86_cost-branch_cost;
+opts-x_ix86_branch_cost = ix86_tune_cost-branch_cost;
if (TARGET_64BIT_P (opts-x_ix86_isa_flags))
{
RE: [PATCH,MIPS] Only pass floating-point options to the assembler then
Hi Catherine,
The new behaviour of the GCC driver passing floating point options like
-msoft-float to the assembler is essential for the new o32 ABI
extensions but is a change in behaviour. In particular GCC 5 used with
binutils 2.24 would require a user to fix any hand-crafted code that
made use of floating-point instructions when building for soft-float.
This patch limits the new behaviour to a combination of GCC and binutils
that both have the new ABI support.
This patch along with parts of several previous patches need backporting
to GCC 4.9 (and GCC 4.8) to enable use of binutils 2.25 with those
compilers. The GCC 4.9 patch will be posted shortly.
I'm not sure if you missed this patch last week or if you are unsure about
it? Since this is about restoring previous behaviour of MIPS GCC when built
alongside binutils = 2.24 I believe this still fits with stage4 criteria.
Thanks,
Matthew
Thanks,
Matthew
gcc/
* config/mips/mips.h (FP_ASM_SPEC): New define.
(ASM_SPEC): Remove floating-point options and use FP_ASM_SPEC
instead.
---
gcc/config/mips/mips.h | 21 ++---
1 file changed, 18 insertions(+), 3 deletions(-)
diff --git a/gcc/config/mips/mips.h b/gcc/config/mips/mips.h index
37d4cb4..ed241fa 100644
--- a/gcc/config/mips/mips.h
+++ b/gcc/config/mips/mips.h
@@ -1243,6 +1243,22 @@ struct mips_cpu_info { %{gcoff*:-mdebug}
%{!gcoff*:-no-mdebug}
#endif
+/* FP_ASM_SPEC represents the floating-point options that must be
passed
+ to the assembler when FPXX support exists. Prior to that point the
+ assembler could accept the options but were not required for
+ correctness. We only add the options when absolutely necessary
+ because passing -msoft-float to the assembler will cause it to
reject
+ all hard-float instructions which may require some user code to be
+ updated. */
+
+#ifdef HAVE_AS_DOT_MODULE
+#define FP_ASM_SPEC \
+%{mhard-float} %{msoft-float} \
+%{msingle-float} %{mdouble-float}
+#else
+#define FP_ASM_SPEC
+#endif
+
/* SUBTARGET_ASM_SPEC is always passed to the assembler. It may be
overridden by subtargets. */
@@ -1277,9 +1293,8 @@ struct mips_cpu_info { %{modd-spreg} %{mno-odd-
spreg} \ %{mshared} %{mno-shared} \ %{msym32} %{mno-sym32} \ -
%{mtune=*} \ -%{mhard-float} %{msoft-float} \ -%{msingle-float}
%{mdouble-float} \
+%{mtune=*} \
+FP_ASM_SPEC \
%(subtarget_asm_spec)
/* Extra switches sometimes passed to the linker. */
--
2.2.1
Re: [PATCH] Re: Stage 3 RFC: using jit for ahead-of-time compilation
On Mon, 2015-01-19 at 10:51 +0100, Richard Biener wrote: On Fri, Jan 16, 2015 at 7:47 PM, David Malcolm dmalc...@redhat.com wrote: On Thu, 2015-01-15 at 22:50 +0100, Richard Biener wrote: On January 15, 2015 9:05:59 PM CET, David Malcolm dmalc...@redhat.com wrote: Release managers: given that this only touches the jit, and that the jit is off by default, any objections if I go ahead and commit this? It's a late-breaking feature, but the jit as a whole is new, and I think the following is a big win, so I'd like to proceed with this in stage 3 (i.e. in the next 24 hours). There are docs and testcases. New jit API entrypoint: gcc_jit_context_compile_to_file This patch adds a way to use libgccjit for ahead-of-time compilation. I noticed that given the postprocessing steps the jit has to take to turn the .s file into in-memory code (invoke driver to convert to a .so and then dlopen), that it's not much of a leap to support compiling the .s file into objects, dynamic libraries, and executables. Doing so seems like a big win from a feature standpoint: people with pre-existing frontend code who want a backend can then plug in libgccjit and have a compiler, without needing to write it as a GCC frontend, or use LLVM. Note that you should make them aware of our runtime license with respect to the eligible compilation process. Which means this is not a way to implement proprietary front ends. Richard. IANAL, but as I understand things, the runtime license is an additional grant of rights that covers certain components of GCC that bear the GCC Runtime Library Exception, allowing them to be used in certain additional ways beyond regular GPLv3-compliance. libgccjit doesn't have that exception; it's GPLv3. Perhaps an argument could be made for libgccjit to have the exception, if the FSF think that that would better serve the FSF's mission; right now, I'm merely trying to provide a technical means to modularity. Assuming the above is correct, anything linked against it needs to be GPLv3-compatible. Hence any such frontend linked against libgccjit would need to be GPLv3-compatible. Attached is a patch (on top of the proposed one below), to clarify the wording in the new tutorial a little, to remind people that such linking needs to be license-compatible (without actually spelling out what the license is, though it's visible at the top of the public header file, libgccjit.h, as GPLv3 or later without the runtime library exception). Are the combined patches OK by you? Yes. Thanks, Richard. Thanks. I've committed the combination of the two patches to trunk as r219876. Sorry about the lateness of this feature. With this commit, gcc now has a brainf*** frontend (albeit one hidden deep in the jit examples dir, and not using the regular frontend machinery). Dave
Re: [Patch, libstdc++/64584, libstdc++/64585] Clear basic_regex after imbue and make assign exception tolerant
On Mon, Jan 19, 2015 at 5:25 AM, Jonathan Wakely jwak...@redhat.com wrote: OK for trunk and 4.9 - thanks. Committed. -- Regards, Tim Shen
Re: [Patch, libstdc++/64649] Fix regex_traits::lookup_collatename and regex_traits::lookup_classname
On Mon, Jan 19, 2015 at 3:52 PM, Tim Shen tims...@google.com wrote:
I think it'll be a quick fix.
Here it is :)
--
Regards,
Tim Shen
commit a2058d87f3b9e2f00a11ae55c2598d00829022cd
Author: timshen tims...@google.com
Date: Mon Jan 19 16:21:10 2015 -0800
PR libstdc++/64649
* include/bits/regex.tcc (regex_traits::lookup_collatename,
regex_traits::lookup_classname): Correctly narrow input chars.
* testsuite/28_regex/traits/wchar_t/user_defined.cc: New testcase.
diff --git a/libstdc++-v3/include/bits/regex.tcc
b/libstdc++-v3/include/bits/regex.tcc
index 3f16e66..aad56e0 100644
--- a/libstdc++-v3/include/bits/regex.tcc
+++ b/libstdc++-v3/include/bits/regex.tcc
@@ -269,7 +269,10 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
DEL,
};
- string __s(__first, __last);
+ string __s;
+ for (; __first != __last; ++__first)
+ __s += __fctyp.narrow(*__first, 0);
+
for (const auto __it : __collatenames)
if (__s == __it)
return string_type(1, __fctyp.widen(
@@ -311,8 +314,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
};
string __s;
- for (auto __cur = __first; __cur != __last; ++__cur)
- __s += __fctyp.narrow(__fctyp.tolower(*__cur), '?');
+ for (; __first != __last; ++__first)
+ __s += __fctyp.narrow(__fctyp.tolower(*__first), 0);
for (const auto __it : __classnames)
if (__s == __it.first)
diff --git a/libstdc++-v3/testsuite/28_regex/traits/wchar_t/user_defined.cc
b/libstdc++-v3/testsuite/28_regex/traits/wchar_t/user_defined.cc
index 16bcd6a..0f55f74 100644
--- a/libstdc++-v3/testsuite/28_regex/traits/wchar_t/user_defined.cc
+++ b/libstdc++-v3/testsuite/28_regex/traits/wchar_t/user_defined.cc
@@ -55,8 +55,32 @@ test01()
VERIFY(!regex_match(L\u2029, re));
}
+struct MyCtype : std::ctypewchar_t
+{
+ char
+ do_narrow(wchar_t c, char dflt) const override
+ {
+if (c = 256)
+ return dflt;
+return ((char)c)+1;
+ }
+};
+
+void
+test02()
+{
+ std::locale loc(std::locale(), new MyCtype);
+ std::regex_traitswchar_t traits;
+ traits.imbue(loc);
+ wchar_t wch = L'p';
+ VERIFY(traits.lookup_collatename(wch, wch+1) == Lq);
+ std::wstring ws = L`kog`; // chars of alpha shifted by 1.
+ VERIFY(traits.lookup_classname(ws.begin(), ws.end()) != 0);
+}
+
int main()
{
test01();
+ test02();
return 0;
}
RE: [PATCH,MIPS] Only pass floating-point options to the assembler then
-Original Message-
From: Matthew Fortune [mailto:matthew.fort...@imgtec.com]
Sent: Monday, January 19, 2015 5:54 PM
To: Moore, Catherine
Cc: 'gcc-patches@gcc.gnu.org' (gcc-patches@gcc.gnu.org)
Subject: RE: [PATCH,MIPS] Only pass floating-point options to the assembler
then
Hi Catherine,
The new behaviour of the GCC driver passing floating point options
like -msoft-float to the assembler is essential for the new o32 ABI
extensions but is a change in behaviour. In particular GCC 5 used with
binutils 2.24 would require a user to fix any hand-crafted code that
made use of floating-point instructions when building for soft-float.
This patch limits the new behaviour to a combination of GCC and
binutils that both have the new ABI support.
This patch along with parts of several previous patches need
backporting to GCC 4.9 (and GCC 4.8) to enable use of binutils 2.25
with those compilers. The GCC 4.9 patch will be posted shortly.
I'm not sure if you missed this patch last week or if you are unsure about it?
Since this is about restoring previous behaviour of MIPS GCC when built
alongside binutils = 2.24 I believe this still fits with stage4 criteria.
Hi Matthew,
I didn't miss it, but I wanted to complete some testing with it. Those tests
have now completed and this patch is OK.
Sorry for the delay.
Thanks,
Catherine
gcc/
* config/mips/mips.h (FP_ASM_SPEC): New define.
(ASM_SPEC): Remove floating-point options and use FP_ASM_SPEC
instead.
---
gcc/config/mips/mips.h | 21 ++---
1 file changed, 18 insertions(+), 3 deletions(-)
diff --git a/gcc/config/mips/mips.h b/gcc/config/mips/mips.h index
37d4cb4..ed241fa 100644
--- a/gcc/config/mips/mips.h
+++ b/gcc/config/mips/mips.h
@@ -1243,6 +1243,22 @@ struct mips_cpu_info { %{gcoff*:-mdebug}
%{!gcoff*:-no-mdebug}
#endif
+/* FP_ASM_SPEC represents the floating-point options that must be
passed
+ to the assembler when FPXX support exists. Prior to that point the
+ assembler could accept the options but were not required for
+ correctness. We only add the options when absolutely necessary
+ because passing -msoft-float to the assembler will cause it to
reject
+ all hard-float instructions which may require some user code to be
+ updated. */
+
+#ifdef HAVE_AS_DOT_MODULE
+#define FP_ASM_SPEC \
+%{mhard-float} %{msoft-float} \
+%{msingle-float} %{mdouble-float}
+#else
+#define FP_ASM_SPEC
+#endif
+
/* SUBTARGET_ASM_SPEC is always passed to the assembler. It may be
overridden by subtargets. */
@@ -1277,9 +1293,8 @@ struct mips_cpu_info { %{modd-spreg} %{mno-
odd-
spreg} \ %{mshared} %{mno-shared} \ %{msym32} %{mno-sym32} \ -
%{mtune=*} \ -%{mhard-float} %{msoft-float} \ -%{msingle-float}
%{mdouble-float} \
+%{mtune=*} \
+FP_ASM_SPEC \
%(subtarget_asm_spec)
/* Extra switches sometimes passed to the linker. */
--
2.2.1
[PATCH] pr 64076 - tolerate different definitions of symbols in lto
From: Trevor Saunders tbsaunde+...@tbsaunde.org
Hi,
when doing an lto link we can have some symbols be ir only and others be
machine code, which trips the assert here. Just adjust the assert to handle
that.
bootstrapped + regtested x86_64-linux-gnu, ok?
Trev
gcc/
* ipa-visibility.c (update_visibility_by_resolution_info): Only
assert when not in lto mode.
---
gcc/ipa-visibility.c | 18 +-
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a/gcc/ipa-visibility.c b/gcc/ipa-visibility.c
index 71894af..0791a1c 100644
--- a/gcc/ipa-visibility.c
+++ b/gcc/ipa-visibility.c
@@ -425,11 +425,19 @@ update_visibility_by_resolution_info (symtab_node * node)
if (node-same_comdat_group)
for (symtab_node *next = node-same_comdat_group;
next != node; next = next-same_comdat_group)
- gcc_assert (!next-externally_visible
- || define == (next-resolution == LDPR_PREVAILING_DEF_IRONLY
- || next-resolution == LDPR_PREVAILING_DEF
- || next-resolution == LDPR_UNDEF
- || next-resolution ==
LDPR_PREVAILING_DEF_IRONLY_EXP));
+ {
+ if (!next-externally_visible)
+ continue;
+
+ bool same_def
+ = define == (next-resolution == LDPR_PREVAILING_DEF_IRONLY
+ || next-resolution == LDPR_PREVAILING_DEF
+ || next-resolution == LDPR_UNDEF
+ || next-resolution == LDPR_PREVAILING_DEF_IRONLY_EXP);
+ gcc_assert (in_lto_p || same_def);
+ if (!same_def)
+ return;
+ }
if (node-same_comdat_group)
for (symtab_node *next = node-same_comdat_group;
--
2.1.4
Re: [patch, Fortran] PR61933 Inquire on Internal Units
ping
This PR has been marked as a regression, so I suppose we ought to get it fixed.
On 01/18/2015 09:10 PM, Jerry DeLisle wrote:
I reopened this PR to do some cleanup and to address a use case presented by
Joost in comment #7 of the subject PR.
The fundamental problem: if the variable containing the unit number in an
INQUIRE statement is of type KIND greater than 4 and the value is outside the
range of a KIND=4 we cannot test for it within the run-time library. Unit
numbers are passed to the run-time in the IOPARM structures as a KIND=4. KIND=8
are cast into the KIND=4. The test case gfortran.dg/negative_unit_int8.f
illustrates a case where a bogus unit number can get passed to the library.
To resolve this previously we built range checks in trans_io.c
(set_parameter_value) that tests the unit numbers and issues an error call to
the run-time library. This is fine for all statements except INQUIRE which
should not give an error. However, we do want to identify such an out-of-range
unit number as not existing.
This patch changes this by renaming the previous set_parameter_value to
set_parameter_value_chk. I then created a new version of set_parameter_value
that does no checking so that it can be used where generating errors is not
needed. I have created two new functions which build code that tests for the
out of range cases specific to INQUIRE. If a bad unit number is found, the UNIT
value in the IOPARM structure is set to -2, a new reserved value. (after this
patch we will have reserved values -3 thru -9 still available for future uses)
The definition of unit existence is adjusted to be any negative unit currently
connected having been created with NEWUNIT and all KIND=4 positive values. A -2
indicating an invalid unit will, by default, return EXISTS=false.
The behind the scenes testing is never seen in user space as shown here with an
-fdump-tree-original example from the negative_unit_int8.f .
For non-INQUIRE cases:
D.3384 = i;
if (D.3384 -2147483647)
{
_gfortran_generate_error (dt_parm.0, 5005, Unit number in I/O
statement too small
[1]{lb: 1 sz: 1});
}
if (D.3384 2147483647)
{
_gfortran_generate_error (dt_parm.0, 5005, Unit number in I/O
statement too large
[1]{lb: 1 sz: 1});
}
dt_parm.0.common.unit = (integer(kind=4)) D.3384;
For the new INQUIRE case:
integer(kind=8) i;
--- snip ---
inquire_parm.4.common.unit = (integer(kind=4)) i;---notice the conversion
to kind=4 here
D.3393 = i;
if (D.3393 0)
{
inquire_parm.4.common.unit = -2;
}
if (D.3393 2147483647)
{
inquire_parm.4.common.unit = -2;
}
When all is acceptable, common.unit is untouched and the normal assignment has
happened. The users variable, in this case i, is untouched as well because of
the temporary D.3393. The IOPARM stucture is also temporary and not used again.
The patch updates the test case mentioned above.
Regression tested on x86-64 and Joost's case in the PR now works as expected.
OK for trunk?
Regards,
Jerry
2015-01-18 Jerry DeLisle jvdeli...@gcc.gnu.org
PR fortran/61933
* trans-io.c (set_parameter_value): Delete use of has_iostat.
Redefine to not generate any runtime error check calls.
(set_parameter_value_chk): Rename of the former
set_parameter_value with the runtimr error checks and fix
whitespace. (gfc_trans_io_inquire_check): New function that
builds a runtime conditional block to set the INQUIRE
common parameter block unit number to -2 when unit numbers
exceed positive KIND=4 limits. (set_parameter_value_inquire):
New function that builds the conditional expressions and calls
gfc_trans_io_inquire_check. (gfc_trans_open): Whitespace. For
unit, use the renamed set_parameter_value_chk.
(gfc_trans_close): Likewise use renamed function.
(build_filepos): Whitespace and use renamed function.
(gfc_trans_inquire): Whitespace and for unit use
set_parameter_value and set_parameter_value_inquire.
(gfc_trans_wait): Remove p-iostat from call to
set_parameter_value. Use new set_parameter_value_chk for unit.
(build_dt): Use the new set_parameter_value without p-iostat
and fix whitespace. Use set_parameter_value_chk for unit.
2015-01-18 Jerry DeLisle jvdeli...@gcc.gnu.org
PR libgfortran/61933
* io/inquire.c (inquire_via_unit): Set existing to true for
any negative unit that is currently connected and any positive
units within range of KIND=4 value. The unit value for any out
of range case that may occur if the user is using a KIND=8 will
have been set to -2 which is reserved and can never be opened,
and therefore the unit does not exist.
[PATCH, ARM] Backport fix for PR59593 (minipool of small values on big endian targets)
Currently on GCC 4.8 and 4.9, constant pool entries for QImode, HImode and
SImode values are filled as 32-bit quantities. This works fine for little
endian system but gives some incorrect results for big endian system when the
value is accessed with a mode smaller than 32-bit in size. Suppose the case of
the value 0x1234 that is accessed as an HImode value. It would be output as 0x0
0x0 0x12 0x34 in a constant pool entry and the 16-bit load that would be done
would lead to the value 0x0 in register.
This patch makes the consttable_1 and consttable_2 pattern available to ARM as
well so that values are output according to their mode.
This is a backport of commit r218118.
*** gcc/ChangeLog ***
2015-01-14 Thomas Preud'homme thomas.preudho...@arm.com
Backport from mainline
2014-11-27 Thomas Preud'homme thomas.preudho...@arm.com
PR target/59593
* config/arm/arm.c (dump_minipool): dispatch to consttable pattern
based on mode size.
* config/arm/arm.md (consttable_1): Make it TARGET_EITHER.
(consttable_2): Make it TARGET_EITHER and move HFmode handling from
consttable_4 to it.
(consttable_4): Move HFmode handling to consttable_2 pattern.
*** gcc/testsuite/ChangeLog ***
2015-01-14 Thomas Preud'homme thomas.preudho...@arm.com
Backport from mainline
2014-11-27 Thomas Preud'homme thomas.preudho...@arm.com
PR target/59593
* gcc.target/arm/constant-pool.c: New test.
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 85372e5..eeaece8 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,16 @@
+2015-01-14 Thomas Preud'homme thomas.preudho...@arm.com
+
+ Backport from mainline
+ 2014-11-27 Thomas Preud'homme thomas.preudho...@arm.com
+
+ PR target/59593
+ * config/arm/arm.c (dump_minipool): dispatch to consttable pattern
+ based on mode size.
+ * config/arm/arm.md (consttable_1): Make it TARGET_EITHER.
+ (consttable_2): Make it TARGET_EITHER and move HFmode handling from
+ consttable_4 to it.
+ (consttable_4): Move HFmode handling to consttable_2 pattern.
+
2015-01-14 Marek Polacek pola...@redhat.com
Backport from mainline
diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index 5e2571c..67ef80b 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -16274,7 +16274,7 @@ dump_minipool (rtx scan)
fputc ('\n', dump_file);
}
- switch (mp-fix_size)
+ switch (GET_MODE_SIZE (mp-mode))
{
#ifdef HAVE_consttable_1
case 1:
diff --git a/gcc/config/arm/arm.md b/gcc/config/arm/arm.md
index 8119387..93b25e9 100644
--- a/gcc/config/arm/arm.md
+++ b/gcc/config/arm/arm.md
@@ -12224,7 +12224,7 @@
(define_insn consttable_1
[(unspec_volatile [(match_operand 0 )] VUNSPEC_POOL_1)]
- TARGET_THUMB1
+ TARGET_EITHER
*
making_const_table = TRUE;
assemble_integer (operands[0], 1, BITS_PER_WORD, 1);
@@ -12237,14 +12237,23 @@
(define_insn consttable_2
[(unspec_volatile [(match_operand 0 )] VUNSPEC_POOL_2)]
- TARGET_THUMB1
+ TARGET_EITHER
*
- making_const_table = TRUE;
- gcc_assert (GET_MODE_CLASS (GET_MODE (operands[0])) != MODE_FLOAT);
- assemble_integer (operands[0], 2, BITS_PER_WORD, 1);
- assemble_zeros (2);
- return \\;
-
+ {
+rtx x = operands[0];
+making_const_table = TRUE;
+switch (GET_MODE_CLASS (GET_MODE (x)))
+ {
+ case MODE_FLOAT:
+ arm_emit_fp16_const (x);
+ break;
+ default:
+ assemble_integer (operands[0], 2, BITS_PER_WORD, 1);
+ assemble_zeros (2);
+ break;
+ }
+return \\;
+ }
[(set_attr length 4)
(set_attr type no_insn)]
)
@@ -12259,15 +12268,12 @@
switch (GET_MODE_CLASS (GET_MODE (x)))
{
case MODE_FLOAT:
- if (GET_MODE (x) == HFmode)
- arm_emit_fp16_const (x);
- else
- {
- REAL_VALUE_TYPE r;
- REAL_VALUE_FROM_CONST_DOUBLE (r, x);
- assemble_real (r, GET_MODE (x), BITS_PER_WORD);
- }
- break;
+ {
+ REAL_VALUE_TYPE r;
+ REAL_VALUE_FROM_CONST_DOUBLE (r, x);
+ assemble_real (r, GET_MODE (x), BITS_PER_WORD);
+ break;
+ }
default:
/* XXX: Sometimes gcc does something really dumb and ends up with
a HIGH in a constant pool entry, usually because it's trying to
diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index 222716d..49d1a73 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,3 +1,11 @@
+2015-01-14 Thomas Preud'homme thomas.preudho...@arm.com
+
+ Backport from mainline
+ 2014-11-27 Thomas Preud'homme thomas.preudho...@arm.com
+
+ PR target/59593
+ * gcc.target/arm/constant-pool.c: New test.
+
2015-01-14 Marek Polacek pola...@redhat.com
Backport from mainline
diff --git a/gcc/testsuite/gcc.target/arm/constant-pool.c
Re: [C++ PATCH, RFC] PR c++/63959, continued
On 19 January 2015 at 21:12, Ville Voutilainen
ville.voutilai...@gmail.com wrote:
On 19 January 2015 at 18:28, Ville Voutilainen
ville.voutilai...@gmail.com wrote:
When I patched the triviality test for volatile types, I missed two cases:
1) volatile members in a class should make the class non-trivial.
2) a volatile class type should itself be non-trivial.
(based on [basic.types]/9, [class]/6, [class.copy]/12 and [class.copy]/25)
I haven't completed testing this yet, I still need to run the full testsuite
to make sure there are no regressions. I'm not sure whether this
can go into gcc5, since we're at stage 4.
Not quite done yet, some tests need adjusting, I will fix them shortly.
Ok, this ended up being a tad more involved than I hoped. Tested on Linux-x64.
I'm copying libstdc++ as well, since I'm mucking with the library tests as well
here. The changes in the library tests from using test_category to using the
traits directly isn't the prettiest thing I've ever done, but the issue is that
no volatile type is trivially_anything, except trivially_destructible,
so test_category
is unsuitable. Please double-check that I didn't miss any test failures, as
this got rather involved, as I said.
/cp
2015-01-20 Ville Voutilainen ville.voutilai...@gmail.com
PR c++/63959
* class.c (check_field_decls): If any field is volatile, make
the class type have complex copy/move operations.
* semantics.c (trait_expr_value): For __has_trivial_destructor,
allow types that are not trivial, but are scalarish and volatile.
* tree.c (trivially_copyable_p): Check CP_TYPE_VOLATILE_P for
class types too.
* tree.c (trivial_type_p): Check CP_TYPE_VOLATILE_P.
/testsuite
2015-01-20 Ville Voutilainen ville.voutilai...@gmail.com
PR c++/63959
* g++.dg/cpp0x/trivial1.C: Adjust.
* g++.dg/ext/is_trivially_constructible1.C: Adjust.
/testsuite
2015-01-20 Ville Voutilainen ville.voutilai...@gmail.com
PR c++/63959
* 20_util/has_trivial_copy_constructor/value.cc: Adjust.
* 20_util/has_trivial_default_constructor/value.cc: Adjust.
* 20_util/is_pod/value.cc: Adjust.
* 20_util/is_trivial/value.cc: Adjust.
diff --git a/gcc/cp/class.c b/gcc/cp/class.c
index edb87fe..529a2bf 100644
--- a/gcc/cp/class.c
+++ b/gcc/cp/class.c
@@ -3717,6 +3717,16 @@ check_field_decls (tree t, tree *access_decls,
if (DECL_INITIAL (x) cxx_dialect cxx14)
CLASSTYPE_NON_AGGREGATE (t) = true;
+ /* If any field is volatile, the structure type has complex copy
+and move operations. */
+ if (CP_TYPE_VOLATILE_P (type))
+ {
+ TYPE_HAS_COMPLEX_COPY_ASSIGN (t) = 1;
+ TYPE_HAS_COMPLEX_MOVE_ASSIGN (t) = 1;
+ TYPE_HAS_COMPLEX_COPY_CTOR (t) = 1;
+ TYPE_HAS_COMPLEX_MOVE_CTOR (t) = 1;
+ }
+
/* If any field is const, the structure type is pseudo-const. */
if (CP_TYPE_CONST_P (type))
{
diff --git a/gcc/cp/semantics.c b/gcc/cp/semantics.c
index 15b8d01..67152cd 100644
--- a/gcc/cp/semantics.c
+++ b/gcc/cp/semantics.c
@@ -7383,7 +7383,9 @@ trait_expr_value (cp_trait_kind kind, tree type1, tree
type2)
case CPTK_HAS_TRIVIAL_DESTRUCTOR:
type1 = strip_array_types (type1);
- return (trivial_type_p (type1) || type_code1 == REFERENCE_TYPE
+ return (trivial_type_p (type1)
+ || (scalarish_type_p (type1) CP_TYPE_VOLATILE_P (type1))
+ || type_code1 == REFERENCE_TYPE
|| (CLASS_TYPE_P (type1)
TYPE_HAS_TRIVIAL_DESTRUCTOR (type1)));
diff --git a/gcc/cp/tree.c b/gcc/cp/tree.c
index 80f2ce6..79be556 100644
--- a/gcc/cp/tree.c
+++ b/gcc/cp/tree.c
@@ -3211,7 +3211,8 @@ trivially_copyable_p (const_tree t)
(!TYPE_HAS_COPY_ASSIGN (t)
|| !TYPE_HAS_COMPLEX_COPY_ASSIGN (t))
!TYPE_HAS_COMPLEX_MOVE_ASSIGN (t)
-TYPE_HAS_TRIVIAL_DESTRUCTOR (t));
+TYPE_HAS_TRIVIAL_DESTRUCTOR (t)
+!CP_TYPE_VOLATILE_P (t));
else
return !CP_TYPE_VOLATILE_P (t) scalarish_type_p (t);
}
@@ -3228,7 +3229,7 @@ trivial_type_p (const_tree t)
return (TYPE_HAS_TRIVIAL_DFLT (t)
trivially_copyable_p (t));
else
-return scalarish_type_p (t);
+return !CP_TYPE_VOLATILE_P (t) scalarish_type_p (t);
}
/* Returns 1 iff type T is a POD type, as defined in [basic.types]. */
diff --git a/gcc/testsuite/g++.dg/cpp0x/trivial1.C
b/gcc/testsuite/g++.dg/cpp0x/trivial1.C
index 3fed570..d0d7b46 100644
--- a/gcc/testsuite/g++.dg/cpp0x/trivial1.C
+++ b/gcc/testsuite/g++.dg/cpp0x/trivial1.C
@@ -18,6 +18,9 @@
#define TRY(expr) static_assert (expr, #expr)
#define YES(type) TRY(std::is_trivialtype::value); \
TRY(std::is_trivialtype[]::value); \
+ TRY(!std::is_trivialconst volatile type::value)
+#define YES2(type) TRY(std::is_trivialtype::value); \
+ TRY(std::is_trivialtype[]::value); \
TRY(std::is_trivialconst volatile type::value)
#define NO(type)
Re: [PATCH] toplev.c: Process the failure when read fails for random_seed
On Mon, 19 Jan 2015, Chen Gang S wrote: On 12/31/2014 06:26 AM, Joseph Myers wrote: On Mon, 29 Dec 2014, Chen Gang S wrote: And in honest, this year what I have done is really not quite well, next year I should be improved: should scanning Bugzilla and try to fix the existing issues (just like another members' suggestions to me). Note that for any substantial patches you'll need to complete the copyright assignment paperwork (I don't see you listed in copyright.list at present). Excuse me, I am not quite familiar with the related working flow, at present, I finished assignment paperwork for binutils and gdb, and I am one of write after approval member for binutils and gdb. Do you mean I need follow the same working flow for gcc, just as for the binutils and gdb? (or only post my assignment is OK?). You need to complete the same assignment form. Start with http://git.savannah.gnu.org/cgit/gnulib.git/plain/doc/Copyright/request-assign.future but this time name GCC as the package. -- Joseph S. Myers jos...@codesourcery.com
Re: [PATCH] Fix scheduling undeterminism from sorting with DEBUG_INSNs
On Jan 19, 2015, at 1:28 PM, Maxim Kuvyrkov maxim.kuvyr...@linaro.org wrote: Yes, the ordering relation is screwed, as you put it. With the number of independent heuristics that rank_for_schedule has to consider there is no other way then to have a screwed ordering. I have not seen a proof that an working comparison routine is impossible. I can’t fathom why anyone would think that. Still perplexed. I don't think we can afford sacrificing code quality to gain independency from number of elements being sorted. A working comparator has nothing to do with the number of elements, so, I can’t fathom why you mention the number of elements. A working comparator should, in theory improve code quality. However, even if it didn’t, that's immaterial. We’d fix the bug irrespective of code quality, just to fix the bug.
Re: Use static chain and libffi for Go closures
On Mon, Jan 19, 2015 at 2:09 PM, Richard Henderson r...@redhat.com wrote: Fixed thus; applying to mainline after build testing a cross tomips64el-linux. Ian, I assume you'll push this upstream? Committed. (It's a little easier for me if I submit patches to the libgo and gcc/go/gofrontend directories.) Ian
Re: [SH] Introduce treg_set_expr
On Sun, 2015-01-18 at 13:25 +0100, Oleg Endo wrote:
On Sat, 2015-01-17 at 22:40 +0900, Kaz Kojima wrote:
Oleg Endo oleg.e...@t-online.de wrote:
Kaz, could you please test the patch on your sh4-linux setup and report
your findings? Even though it's a bit late, I'd like to get this in for
GCC 5, if it doesn't break too many things.
Looks wrong code problem for tls and atomic constructs.
Here is the result of compare_tests for unpatched/patched
sh4-unknown-linux-gnu compilers:
New tests that FAIL:
...
Thanks. Doesn't look so bad actually. I've expected worse. These are
the two problems:
1) sh_find_extending_set_of_reg (introduced earlier as part of PR 53988)
hits atomic insns, which in fact do a indirect sign extending mem load.
The cmpeqsi_t splitter for const_int 0 then tries to use the value as
sign extended, which wrongly converts an atomic into a simple mem load.
The easy solution is not to report 'sign extended' in
sh_find_extending_set_of_reg for mems that are buried in UNSPEC/UNSPECV
insns. This also revealed a problem of inconsistent return values of
sh_find_set_of_reg. This should be fixed regardless of the
treg_set_expr stuff first. I'll create separate patch for that.
The more complex solution would be to somehow convert the atomics so
that the sign extension becomes visible for the following code. Maybe
later.
Should be fixed with r219864.
2) The GBR related insns (e.g. store_gbr, *movmode_gbr_load) use
register_operand as destination. Since register_operand matches
T_REG, a (set (reg:SI T_REG) (gbr something)) will be wrongly matched
by any_treg_expr_to_reg. This should actually have ended in an
unrecognized insn ICE, but then there's the *negtstsi insn, which
results in funny code.
The easy solution for this is to use arith_reg_dest instead of
register_operand in the GBR insns. I'll send around an updated
treg_set_expr patch after 1) is done.
The updated treg_set_expr patch is attached, which should fix the GBR
issues. Tests here OK.
Kaz, could you please try again?
Cheers,
Oleg
Index: gcc/config/sh/sh.md
===
--- gcc/config/sh/sh.md (revision 219864)
+++ gcc/config/sh/sh.md (working copy)
@@ -612,59 +612,200 @@
;; SImode signed integer comparisons
;; -
-;; Various patterns to generate the TST #imm, R0 instruction.
-;; Although this adds some pressure on the R0 register, it can potentially
-;; result in faster code, even if the operand has to be moved to R0 first.
-;; This is because on SH4 TST #imm, R0 and MOV Rm, Rn are both MT group
-;; instructions and thus will be executed in parallel. On SH4A TST #imm, R0
-;; is an EX group instruction but still can be executed in parallel with the
-;; MT group MOV Rm, Rn instruction.
-
-;; Usual TST #imm, R0 patterns for SI, HI and QI
-;; This is usually used for bit patterns other than contiguous bits
-;; and single bits.
-(define_insn tstsi_t
+;; Patterns to generate the tst instruction which are usually formed by
+;; the combine pass.
+;; The canonical form here being used is (eq (and (op) (op)) 0).
+;; For some bit patterns, such as contiguous bits, we also must accept
+;; zero_extract forms. Single bit tests are also handled via zero_extract
+;; patterns in the 'bit field extract patterns' section. All variants
+;; are eventually converted to the 'tstsi_t' insn.
+;; As long as pseudos can be created (before RA), 'tstsi_t' will also accept
+;; constants that won't fit into 8 bits. After having captured the constant
+;; we can decide better whether/how to load it into a register and do other
+;; post-combine optimizations such as bypassing sign/zero extensions.
+(define_insn_and_split tstsi_t
[(set (reg:SI T_REG)
- (eq:SI (and:SI (match_operand:SI 0 logical_operand %z,r)
- (match_operand:SI 1 logical_operand K08,r))
+ (eq:SI (and:SI (match_operand:SI 0 arith_reg_operand %z,r)
+ (match_operand:SI 1 arith_or_int_operand K08,r))
(const_int 0)))]
- TARGET_SH1
+ TARGET_SH1
+(can_create_pseudo_p () || arith_reg_operand (operands[1], SImode)
+ || satisfies_constraint_K08 (operands[1]))
tst %1,%0
+ TARGET_SH1 can_create_pseudo_p () CONST_INT_P (operands[1])
+!sh_in_recog_treg_set_expr ()
+ [(const_int 0)]
+{
+ gcc_assert (CONST_INT_P (operands[1]));
+
+ HOST_WIDE_INT op1val = INTVAL (operands[1]);
+ bool op0_dead_after_this =
+ sh_reg_dead_or_unused_after_insn (curr_insn, REGNO (operands[0]));
+
+ if (optimize)
+{
+ if (dump_file)
+ fprintf (dump_file,
+ tstsi_t: trying to optimize const_int 0x%08x\n,
+ (uint32_t)op1val);
+
+ /* See if we can convert a test with a reg and a constant into
+ something simpler, if the reg is known to be zero or sign
+ extended. */
+ sh_extending_set_of_reg eop0 = sh_find_extending_set_of_reg (operands[0],
+
Re: [SH][committed] Fix PR 64652
On Sun, 2015-01-18 at 19:14 +0100, Oleg Endo wrote:
Hi,
The attached patch fixes PR 64652. Tested with
make -k check-gcc RUNTESTFLAGS=sh-torture.exp --target_board=sh-sim
\{-m2/-ml,-m2/-mb,-m2a/-mb,-m4/-ml,-m4/-mb,-m4a/-ml,-m4a/-mb}
Committed as r219824.
Cheers,
Oleg
gcc/ChangeLog:
PR target/64652
* config/sh/sh.md (udivsi3_i4, divsi3_i4): Make use of sfunc address
reg appear first in the parallel.
gcc/testsuite/ChangeLog:
PR target/64652
* gcc.target/sh/torture/pr64652.c: New.
I forgot to add the unsigned div test case that checks the udivsi3_i4
insn. Committed as r219870.
Cheers,
Oleg
gcc/testsuite/ChangeLog:
PR target/64652
* gcc.target/sh/torture/pr64652.c (test): Rename to test_0.
(test_1): New.
Index: gcc/testsuite/gcc.target/sh/torture/pr64652.c
===
--- gcc/testsuite/gcc.target/sh/torture/pr64652.c (revision 219869)
+++ gcc/testsuite/gcc.target/sh/torture/pr64652.c (working copy)
@@ -4,7 +4,13 @@
/* { dg-skip-if { sh*-*-* } { -m5* } { } } */
int
-test (int a, int b, int c, int d)
+test_0 (int a, int b, int c, int d)
{
return (a / b) + c + d;
}
+
+unsigned int
+test_1 (unsigned int a, unsigned int b, unsigned int c, unsigned int d)
+{
+ return (a / b) + c + d;
+}
Re: [Patch, libstdc++/64649] Fix regex_traits::lookup_collatename and regex_traits::lookup_classname
On Mon, Jan 19, 2015 at 5:23 AM, Jonathan Wakely jwak...@redhat.com wrote: Maybe it's OK, because all the elements of __collatename use ASCII chars which have the same value as wide chars? (Probably not true for all locales). I just noticed that if we want to implement it 100% accurately, narrowing down the input string to char string is clearly wrong, e.g. wchar_t wch = 0x1177; // 0x77, the default narrowed result, is 'w' std::wcout std::regex_traitswchar_t().lookup_collatename(wch, wch+1) L\n; // prints w So the correct approach is widening (and use ctype widen so that users can customize it) all char strings (those statically stored in these two functions), and compare them to the input range. But it seems to be slightly slower, so I wrote this implementation out of instinctively. Maybe people (now including me) always know that anything concerned with locales *are* slow? ;) Your change is definitely an improvement and good enough for now (maybe we should leave the Bugzilla PR open, with a note about the wide char issue, and deal with it after stage4). I'm not sure how emergent we are, so I just go ahead and committed it. As I mentioned above, the right way to do this is widening the expected strings and compare them to the input string. Thanks! -- Regards, Tim Shen
Re: Fix 59828 - Broken assembly on ppc* with two -mcpu= options
On Fri, Jan 17, 2014 at 10:58 PM, Alan Modra amo...@gmail.com wrote:
This patch cures PR59828 by translating all the -mcpu options at once,
in order, to their equivalent assembler -m options by using a new spec
function. In the process this removes some duplication.
All the rhs of -mcpu= options from the command line can be extracted
with %{mcpu=*:%*}, and then passed to a spec function. The new
function was mostly already there in driver-rs6000.c to support
-mcpu=native. However, the new spec function must be called for
non-native configurations, so it's necessary to split driver-rs6000.c
into two files, one for native support, the other always compiled in.
I deliberately omitted converting over aix42.h, aix51.h and aix52.h
because ASM_CPU_SPEC in those files translates -mcpu to different
assembly options than the aix -mcpu=native support. Presumably the
assembler on older versions of aix doesn't understand the newer
options..
Bootstrapped and regression tested powerpc64-linux natively, and
x86_64-linux to powerpc64-linux cross. OK to apply?
PR target/59828
* config/rs6000/driver-rs6000.c (asm_names): Add entries for native.
(translate_cpu_to_asm): New function.
Move everything else to..
* config/rs6000/driver-nat-rs6000.c: ..here. New file.
(host_detect_local_cpu): Make use of translate_cpu_to_asm.
* config/rs6000/rs6000.h (ASM_CPU_SPEC): Likewise.
(translate_cpu_to_asm): Declare.
(EXTRA_SPEC_FUNCTIONS): Add translate_cpu_to_asm.
* config/rs6000/x-rs6000: Adjust for renamed file.
* config/rs6000/t-rs6000: Add driver-rs6000.o rule.
* config/rs6000/aix53.h (ASM_CPU_SPEC): Use translate_cpu_to_asm.
* config/rs6000/aix61.h (ASM_CPU_SPEC): Likewise.
* config.gcc (extra_gcc_objs): Add driver-rs6000.o.
* config.host (host_extra_gcc_objs): Remove driver-rs6000.o, add
driver-nat-rs6000.o.
Alan,
ASM_CPU_SPEC is too fragile a mechanism. I would much prefer to
expand on the .machine directive that I added to
rs6000_file_start(). The initial implementation explicitly avoids
.machine when -mcpu= or --with-cpu= is present as a conservative
start.
It seems much better to select a .machine directive based on the
actual target ISA flag bits enabled than translating CPU command line
options to ASM options. Patches to replace ASM_CPU_SPEC with .machine
and expand functionality for AIX are welcome.
Thanks, David
Re: Use static chain and libffi for Go closures
On Sat, Jan 17, 2015 at 10:34 AM, Uros Bizjak ubiz...@gmail.com wrote: On Sat, Jan 17, 2015 at 12:19 AM, Ian Lance Taylor i...@golang.org wrote: You should also revert alpha specific change to libgo/go/testing/quick/quick_test.go, please see [1] and [2]. [1] https://gcc.gnu.org/ml/gcc-patches/2013-03/msg00038.html [2] https://gcc.gnu.org/ml/gcc-patches/2013-03/msg00038/foo.patch Done like so. Committed to mainline. Thanks! There is another part in runtime/go-ffi.c that looks like it is not necessary anymore with FFI_TARGET_HAS_COMPLEX_TYPE. Attached proto-patch that removes special Complex64 handling survives go regression test for i686 target. However, some of i686 targets don't define FFI_TARGET_HAS_COMPLEX_TYPE, so at least this part should be conditional on !ifndef FFI_TARGET_HAS_COMPLEX_TYPE. Thanks. Committed based on Richard H's later comments. Ian
Re: libgo patch committed: Update to Go 1.4
On Mon, Jan 19, 2015 at 4:17 AM, Rainer Orth r...@cebitec.uni-bielefeld.de wrote: Ian Lance Taylor i...@golang.org writes: On Thu, Jan 15, 2015 at 8:30 AM, Rainer Orth r...@cebitec.uni-bielefeld.de wrote: Apart from that, bootstrap fails in gotools: due to the use of -static-libgo, all commands there fail to link since the socket functions are missing. It seems like $LIBS from libgo needs to be added somewhere, but I'm unsure how best to handle this. To make any progress at all, I've just manually added -lsocket -lnsl to gotools/Makefile (AM_LDFLAGS). I also don't know what the best way is to handle this. For now I've just added a configure test to check whether the libraries are needed. Based on the libgo build, as far as I can tell, no other libraries should be needed. While this is true for Solaris 11, Solaris 10 needs librt for nanosleep, sched_yield and the sem_* functions. The following patch copies the corresponding libgo test and allows gotools to build even on Solaris 10. This is OK to commit with a ChangeLog entry (the gotools directory is not mirrored and lives only in the GCC repository). Thanks. Ian
[committed] Partial libsanitizer aarch64 fix (PR sanitizer/64435)
Hi! I've committed following cherry-pick from upstream. It is not a fully solution for that PR, but does not hurt and let us move to other libsanitizer build failures on aarch64 (and with those fixed/worked around just to find out that asan doesn't work at all on aarch64). 2015-01-19 Jakub Jelinek ja...@redhat.com PR sanitizer/64435 * sanitizer_common/sanitizer_platform_limits_posix.cc: Cherry pick upstream r223925. --- libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc (revision 223924) +++ libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc (revision 223925) @@ -1005,8 +1005,12 @@ CHECK_SIZE_AND_OFFSET(__sysctl_args, new CHECK_TYPE_SIZE(__kernel_uid_t); CHECK_TYPE_SIZE(__kernel_gid_t); + +#if !defined(__aarch64__) CHECK_TYPE_SIZE(__kernel_old_uid_t); CHECK_TYPE_SIZE(__kernel_old_gid_t); +#endif + CHECK_TYPE_SIZE(__kernel_off_t); CHECK_TYPE_SIZE(__kernel_loff_t); CHECK_TYPE_SIZE(__kernel_fd_set); Jakub
Re: [Patch, AArch64, testsuite] PR63971: Revert test_frame_* patch.
On Thu, Jan 15, 2015 at 8:18 AM, Mike Stump mikest...@comcast.net wrote: On Jan 14, 2015, at 3:50 AM, Tejas Belagod tejas.bela...@arm.com wrote: As agreed here (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63971), please can I reverse Andrew's patch out(https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02916.html)? Ok. Unless someone objects to a reversion like this, when the author of a patch says it should be reverted… that’s all the approval it needs, though, people can always ask for a review for any reason they want. And now this reversal needs to be reverted. Because the conditional compare optimization went back in. I figured the optimization would go back in and that is why I did not act on reverting my patch that fast. The conditional compare patch went in a day after this reversal went in ;). Thanks, Andrew
Re: [PING] [PATCH] Fix parameters of __tsan_vptr_update
On Mon, Jan 19, 2015 at 12:43:39PM +0400, Dmitry Vyukov wrote: Hi Bernd, Yes, that email is marked in my inbox. Sorry for not answering earlier. I can't really make my mind on this. I would mildly prefer sleep's (if they work reliably!). Sleeps by definition should not be reliable, not to mention that they waste testing time. Kostya, please chime in. This is equivalent to StealthNotification that we used in old data-race-test test suite: https://code.google.com/p/data-race-test/source/browse/trunk/unittest/test_utils.h#134 Kostya, you had experience with both approaches. What are you thoughts on this? StealthNotification definitely makes tests faster and more reliable. I can't really come up with any objective downsides. Jakub
[PING] [PATCH] [AArch64, NEON] Fix testcases add by r218484
Hi, This is a ping for: https://gcc.gnu.org/ml/gcc-patches/2014-12/msg01328.html OK for the trunk? Thanks.
Re: [PATCH] Fix sporadic failure in g++.dg/tsan/aligned_vs_unaligned_race.C
Long story short. Tsan has a logical data race the core of data race detection algorithm. The race is not a bug, but a deliberate design decision that makes tsan considerably faster. So ironically, if the race memory accesses happen almost simultaneously, tsan can miss the race. Thus we have sleeps. Sleeps vs barrier is being discussed in the Fix parameters of __tsan_vptr_update thread. I would really like to keep llvm and gcc tests in sync as much as possible. On Fri, Jan 9, 2015 at 6:36 PM, Jakub Jelinek ja...@redhat.com wrote: On Fri, Jan 09, 2015 at 04:32:47PM +0100, Bernd Edlinger wrote: Hi, On Thu, 8 Jan 2015 22:27:26, Jakub Jelinek wrote: Any objections to approving it now? LGTM. Jakub would it be OK to apply this patch also to the 4.9 testsuite, except for c-c++-common/tsan/bitfield_race.c and g++.dg/tsan/aligned_vs_unaligned_race.C of course? Yes, but please give Dmitry some time to respond. Jakub
[PING ^ 4] [RFC PATCH, AARCH64] Add support for -mlong-calls option
Patch ping: https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02258.html Any comments, Richard? Thanks.
Re: [PING] [PATCH] Fix parameters of __tsan_vptr_update
On Fri, Jan 16, 2015 at 8:42 PM, Bernd Edlinger bernd.edlin...@hotmail.de wrote: Hi, On Fri, 16 Jan 2015 21:25:42, Dmitry Vyukov wrote: This is just a copy from llvm repo, right? Looks good to me. Thanks. Yes I found these test case in the llvm tree, and just adapted them to work in the gcc test suite. However, here is a small tweak in the positive test: That is we now use a tsan-invisible barrier_wait function instead of the not very reliable sleep(1). barrier_wait is bypassing the tsan interceptor, because it is accessed with dlsym (dlopen (libpthread.so.0, RTLD_LAZY), pthread_barrier_wait). +Kostya Hi Bernd, Yes, that email is marked in my inbox. Sorry for not answering earlier. I can't really make my mind on this. I would mildly prefer sleep's (if they work reliably!). Kostya, please chime in. This is equivalent to StealthNotification that we used in old data-race-test test suite: https://code.google.com/p/data-race-test/source/browse/trunk/unittest/test_utils.h#134 Kostya, you had experience with both approaches. What are you thoughts on this? StealthNotification definitely makes tests faster and more reliable. I can't really come up with any objective downsides. On Fri, Jan 16, 2015 at 10:17 AM, Bernd Edlinger bernd.edlin...@hotmail.de wrote: Hi, I think I should ping for this patch now: https://gcc.gnu.org/ml/gcc-patches/2015-01/msg00599.html note that by mistake the change log referenced sanitizer.c instead of sanitizer.def, consider that fixed on my local copy. Thanks Bernd. Date: Sun, 11 Jan 2015 14:15:54 +0100 Hi, On Sun, 4 Jan 2015 14:54:56, Bernd Edlinger wrote: Hi Jakub, I think I have found a reasonable test case, see the attached patch file. The use case is: a class that destroys an owned thread in the destructor. The destructor sets the vptr again to thread::vptr but this should _not_ trigger a diagnostic message, when the vptr does not really change. Jakub, this is another test case where the TREE_READONLY prevents the tsan instrumentation. So I had first to install your patch: https://gcc.gnu.org/ml/gcc-patches/2014-12/msg01432.html ... to see the test case fail without my patch. that has been installed in the meantime. The patch installs cleanly on 4.9 and 4.8, however the 4.8 branch has no tsan tests, so I would leave the test case away for 4.8. I found, 4.8 does not have BT_FN_VOID_PTR_PTR, and no tsan tests at all, so it is probably not worth the effort. Boot-strapped and regression-tested on x86_64-linux-gnu OK for trunk and 4.9 + 4.8 branches? Thanks Bernd. I found some test cases in the clang tree, about the __tsan_vptr_update. So I thought I should use these instead of inventing new ones. Attached you'll find an updated patch with one positive and one negative test for vptr races. Tested with x86_64-linux-gnu. OK for trunk and 4.9 after a while? Thanks Bernd.
Re: Fix 59828 - Broken assembly on ppc* with two -mcpu= options
On Mon, Jan 19, 2015 at 10:43:29PM -0500, David Edelsohn wrote: On Fri, Jan 17, 2014 at 10:58 PM, Alan Modra amo...@gmail.com wrote: This patch cures PR59828 by translating all the -mcpu options at once, in order, to their equivalent assembler -m options by using a new spec function. In the process this removes some duplication. ASM_CPU_SPEC is too fragile a mechanism. I would much prefer to expand on the .machine directive that I added to rs6000_file_start(). The initial implementation explicitly avoids .machine when -mcpu= or --with-cpu= is present as a conservative start. It seems much better to select a .machine directive based on the actual target ISA flag bits enabled than translating CPU command line options to ASM options. Patches to replace ASM_CPU_SPEC with .machine and expand functionality for AIX are welcome. This might make sense when looking only at gcc, but when considering the whole toolchain I think you'll run into difficulty. gas and other powerpc assemblers have always been invoked with -m options to select the cpu, so if you do away with ASM_CPU_SPEC and rely on .machine then you will be exercising the assembler in a new way. I am sure that this will not work for all powerpc assemblers currently in use. -- Alan Modra Australia Development Lab, IBM
RE: [PING] [PATCH] Fix parameters of __tsan_vptr_update
Hi,
On Mon, 19 Jan 2015 18:49:21, Konstantin Serebryany wrote:
[text-only]
On Mon, Jan 19, 2015 at 7:42 AM, Mike Stump mikest...@comcast.net wrote:
On Jan 19, 2015, at 12:43 AM, Dmitry Vyukov dvyu...@google.com wrote:
I can't really make my mind on this. I would mildly prefer sleep's (if
they work reliably!).
Let me state it more forcefully.
You don't have to convince us here.
I'd love to get rid of sleep calls in the tsan test suite -- they are
a minor but a constant annoyance.
But I also want to keep the tests *very simple*, i.e.
1. Single file w/o any non-system includes, no linking of extra
libraries/objects
2. Not too much extra code. (ideally, 1 line for init, 1 line for
signal, 1 line for wait)
3. Strictly posix or c++11 (unless we are testing something specific)
Your idea with barrier_wait/dlsym sounds interesting, but I can't see
the code in this mail thread.
What do I miss?
We discussed two alternatives to sleep:
1. step function, optionally with sched_yield to make it somewhat less busy
waiting:
__attribute__((no_sanitize_thread))
void step (int i)
{
while (__atomic_load_n (serial, __ATOMIC_ACQUIRE) != i - 1)
sched_yield();
__atomic_store_n (serial, i, __ATOMIC_RELEASE);
}
2. tsan-invisible barriers:
cat tsan_barrier.h
/* TSAN-invisible barriers. Link with -ldl. */
#include pthread.h
#include dlfcn.h
static __typeof(pthread_barrier_wait) *barrier_wait;
static
void barrier_init (pthread_barrier_t *barrier, unsigned count)
{
void *h = dlopen (libpthread.so.0, RTLD_LAZY);
barrier_wait = (__typeof (pthread_barrier_wait) *)
dlsym (h, pthread_barrier_wait);
pthread_barrier_init (barrier, NULL, count);
}
We preferred the second alternative, because it does not do busy waiting.
We include this header file in every positive test case and link with -ldl.
Bernd.
[PATCH, nds32] Committed: Have sibling calls optmization to be performed on nds32 target.
Hi, all, It is reported that the nds32 port on trunk cannot perform sibling call optimization because there are missing sibcall and sibcall_value named patterns. So we define those named patterns to fix the issue. This patch was committed last week before stage 4: https://gcc.gnu.org/r219712 gcc/ChangeLog 2015-01-16 Chung-Ju Wu jasonw...@gmail.com * config/nds32/nds32-protos.h (nds32_expand_epilogue): Change prototype. (nds32_expand_epilogue_v3pop): Likewise. * config/nds32/nds32.md (sibcall): Define this for sibling call optimization. (sibcall_register): Likewise. (sibcall_immediate): Likewise. (sibcall_value): Likewise. (sibcall_value_register): Likewise. (sibcall_value_immediate): Likewise. (sibcall_epilogue): Likewise. (epilogue): Pass false to indicate this is not a sibcall epilogue. * config/nds32/nds32.c (nds32_expand_epilogue): Consider sibcall case. (nds32_expand_epilogue_v3pop): Likewise. Best regards, jasonwucj 0009-Implement-necessary-named-patterns-to-support-siblin.patch Description: Binary data
[PATCH] add includes in config/tilepro/mul-tables.c and config/tilegx/mul-tables.c
Hi, When I committed r219655, I didn't check in tilepro/mul-tables.c since it was auto-generated from config/tilepro/gen-mul-tables.cc. Andrew pointed out to me that this causes the files confi/tilepro/mul-tables.c and config/tilegx/mul-tables.c to show up in svn diff. The attached patch fixes that by putting includes in config/tilepro/mul-tables.c in the order they are present in config/tilepro/gen-mul-tables.cc. The patch won't affect the build since they are generated from gen-mul-tables.cc, the sole point of this patch is to avoid noise in svn diff, so could this be considered similar to a doc-fix ? OK to commit ? Thanks, Prathamesh 2015-01-20 Prathamesh Kulkarni prathamesh.kulka...@linaro.org * config/tilegx/mul-tables.c: Move symtab.h include after coretypes.h include. * config/tilepro/mul-tables.c: Add includes hashtab.h, hash-set.h, vec.h, machmode.h, tm.h, hard-reg-set.h, input.h, function.h, rtl.h, flags.h, statistics.h, double-int.h, real.h, fixed-value.h, alias.h, wide-int.h, inchash.h, tree.h, insn-config.h, expmed.h, dojump.h, explow.h, calls.h, emit-rtl.h, varasm.h, stmt.h. Index: gcc/config/tilegx/mul-tables.c === --- gcc/config/tilegx/mul-tables.c (revision 219679) +++ gcc/config/tilegx/mul-tables.c (working copy) @@ -24,6 +24,7 @@ #include config.h #include system.h #include coretypes.h +#include symtab.h #include hashtab.h #include hash-set.h #include vec.h @@ -39,7 +40,6 @@ #include real.h #include fixed-value.h #include alias.h -#include symtab.h #include wide-int.h #include inchash.h #include tree.h Index: gcc/config/tilepro/mul-tables.c === --- gcc/config/tilepro/mul-tables.c (revision 219679) +++ gcc/config/tilepro/mul-tables.c (working copy) @@ -24,6 +24,33 @@ #include config.h #include system.h #include coretypes.h +#include symtab.h +#include hashtab.h +#include hash-set.h +#include vec.h +#include machmode.h +#include tm.h +#include hard-reg-set.h +#include input.h +#include function.h +#include rtl.h +#include flags.h +#include statistics.h +#include double-int.h +#include real.h +#include fixed-value.h +#include alias.h +#include wide-int.h +#include inchash.h +#include tree.h +#include insn-config.h +#include expmed.h +#include dojump.h +#include explow.h +#include calls.h +#include emit-rtl.h +#include varasm.h +#include stmt.h #include expr.h #include insn-codes.h #include optabs.h
Re: [patch, Fortran] PR61933 Inquire on Internal Units
Hi Jerry, hi all, sorry for the slow patch review. I also still want to review your other inquire patch. Jerry DeLisle wrote: The fundamental problem: if the variable containing the unit number in an INQUIRE statement is of type KIND greater than 4 and the value is outside the range of a KIND=4 we cannot test for it within the run-time library. Unit numbers are passed to the run-time in the IOPARM structures as a KIND=4. KIND=8 are cast into the KIND=4. The test case gfortran.dg/negative_unit_int8.f illustrates a case where a bogus unit number can get passed to the library. Regression tested on x86-64 and Joost's case in the PR now works as expected. OK for trunk? Mostly OK, however, some remarks are below. 2015-01-18 Jerry DeLisle jvdeli...@gcc.gnu.org PR fortran/61933 * trans-io.c (set_parameter_value): Delete use of has_iostat. Redefine to not generate any runtime error check calls. (set_parameter_value_chk): Rename of the former set_parameter_value with the runtimr error checks and fix whitespace. (gfc_trans_io_inquire_check): New function that builds a runtime conditional block to set the INQUIRE common parameter block unit number to -2 when unit numbers exceed positive KIND=4 limits. (set_parameter_value_inquire): New function that builds the conditional expressions and calls gfc_trans_io_inquire_check. (gfc_trans_open): Whitespace. For unit, use the renamed set_parameter_value_chk. (gfc_trans_close): Likewise use renamed function. (build_filepos): Whitespace and use renamed function. (gfc_trans_inquire): Whitespace and for unit use set_parameter_value and set_parameter_value_inquire. (gfc_trans_wait): Remove p-iostat from call to set_parameter_value. Use new set_parameter_value_chk for unit. (build_dt): Use the new set_parameter_value without p-iostat and fix whitespace. Use set_parameter_value_chk for unit. 2015-01-18 Jerry DeLisle jvdeli...@gcc.gnu.org PR libgfortran/61933 * io/inquire.c (inquire_via_unit): Set existing to true for any negative unit that is currently connected and any positive units within range of KIND=4 value. The unit value for any out of range case that may occur if the user is using a KIND=8 will have been set to -2 which is reserved and can never be opened, and therefore the unit does not exist. [...] + /* The unit number -2 is reserved. No units can ever have this + value. It is used here to signal to the runtime library that the + inquire unit number is outside the allowable range and so cannot + exist. It is needed when -fdefault-integer-8 is uesed. */ I don't know where this number is used, but I really should be a #define; if it is shared with libgfortran, it belongs to libgfortran.h. You wrote that -1 is also reserved and used; is the -1 somewhere defined? [Disclaimer: I have only browsed the other patch and do not recall whether it add, handles or #defines -1 - or whether -1 is already defined somewhere.] + /* UNIT numbers should be greater than zero. */ + i = gfc_validate_kind (BT_INTEGER, 4, false); + cond = build2_loc (input_location, LT_EXPR, boolean_type_node, + se.expr, + fold_convert (TREE_TYPE (se.expr), + integer_zero_node)); + gfc_trans_io_inquire_check (cond, var, se.pre); + + /* UNIT numbers should be less than the max. */ + val = gfc_conv_mpz_to_tree (gfc_integer_kinds[i].huge, 4); + cond = build2_loc (input_location, GT_EXPR, boolean_type_node, + se.expr, + fold_convert (TREE_TYPE (se.expr), val)); + gfc_trans_io_inquire_check (cond, var, se.pre); The conditions could be combined with a fold_build2_loc(...,TRUTH_AND_EXPR,...). Thanks for the patch! Cheers, Tobias
Re: [PATCH, doc] NDS32: Remove -mforce-fp-as-gp, -mforbid-fp-as-gp, and -mex9 options from documentation.
2015-01-18 16:38 GMT+08:00 Gerald Pfeifer ger...@pfeifer.com: On Wednesday 2015-01-14 17:58, Chung-Ju Wu wrote: 2015-01-14 Chung-Ju Wu jasonw...@gmail.com * doc/invoke.texi (NDS32 Options): Remove -mforce-fp-as-gp, -mforbid-fp-as-gp, and -mex9 options. Can you cover these, and similar changes, in the release notes at htdocs/gcc-5/changes.html, please? (Cf. gcc.gnu.org/about.html for the web pages side of things.) Gerald Thank for reminding me. I am preparing such patch to describe nds32 port in the release note of gcc5 changes.html, including the new options, the options are removed, and ABI changes for variadic function: https://gcc.gnu.org/ml/gcc-patches/2014-09/msg00316.html https://gcc.gnu.org/ml/gcc-patches/2015-01/msg00992.html https://gcc.gnu.org/ml/gcc-patches/2015-01/msg00993.html I will post that patch for web page soon. :) Best regards, jasonwucj
Re: [PATCH] Fix scheduling undeterminism from sorting with DEBUG_INSNs
On Jan 20, 2015, at 6:32 AM, Mike Stump mikest...@comcast.net wrote: On Jan 19, 2015, at 1:28 PM, Maxim Kuvyrkov maxim.kuvyr...@linaro.org wrote: Yes, the ordering relation is screwed, as you put it. With the number of independent heuristics that rank_for_schedule has to consider there is no other way then to have a screwed ordering. I have not seen a proof that an working comparison routine is impossible. I can’t fathom why anyone would think that. Still perplexed. I don't think we can afford sacrificing code quality to gain independency from number of elements being sorted. A working comparator has nothing to do with the number of elements, so, I can’t fathom why you mention the number of elements. A working comparator should, in theory improve code quality. However, even if it didn’t, that's immaterial. We’d fix the bug irrespective of code quality, just to fix the bug. Do you have a specific constructive suggestion how to structure haifa-sched.c:rank_for_schedule() so that it can never return a cyclic ordering like A B C A? Thank you, -- Maxim Kuvyrkov www.linaro.org
PATCH, nds32] Committed: Fix wrong data flow when building nds32 target with --enable-checking=yes.
Hi, all, The nds32 target has two kinds of instructions for returning to the caller. One is normal 'ret' instruction which takes $lp as return address; and the other is 'pop25' instruction which perform registers pop and use $lp as return address in a single step. However, the current design of 'pop25' on trunk is incomplete. We lost return rtx semantic in the pattern so that gcc will get wrong data flow across pop25 if we configure it with --enable-checking=yes. To fix this issue, we have dummy pattern 'pop25return' to tell gcc that there is a return behavior after pop25 instruction. This patch was committed last week before stage 4: https://gcc.gnu.org/r219710 gcc/ChangeLog 2015-01-16 Chung-Ju Wu jasonw...@gmail.com * config/nds32/constants.md (UNSPEC_VOLATILE_POP25_RETURN): New. * config/nds32/nds32.md (pop25return): New. * config/nds32/nds32.c (nds32_expand_epilogue_v3pop): Emit pop25return pattern. Best regards, jasonwucj 0007-Add-dummy-pattern-pop25return-to-tell-gcc-there-is-a.patch Description: Binary data
Re: [PATCH, doc] NDS32: Describe -mcmodel= option instead of -mgp-direct in the documentation.
2015-01-18 16:36 GMT+08:00 Gerald Pfeifer ger...@pfeifer.com: On Wednesday 2015-01-14 17:56, Chung-Ju Wu wrote: 2015-01-14 Chung-Ju Wu jasonw...@gmail.com * doc/invoke.texi (NDS32 Options): Add -mcmodel= option and remove -mgp-direct option. Although these changes are target-specific part, I think it would be better for others to have review comments, if any, on its format and layout. That's easier for us if you attach patches as text as opposed to Content-Type: application/octet-stream. Gerald No problem. If the content is small enough, next time I will have patches as text so that others are able to do review easily. Thanks for your suggestion. :) Best regards, jasonwucj
[PATCH, nds32] Committed: Have shrink-wrapping optimization to be performed on nds32 target.
Hi, all, It is reported that the nds32 port on trunk cannot perform shrink-wrapping optimization because there is missing named pattern simple_return. So we define that named pattern to fix the issue. This patch was committed last week before stage 4: https://gcc.gnu.org/r219711 gcc/ChangeLog 2015-01-16 Chung-Ju Wu jasonw...@gmail.com * config/nds32/nds32-protos.h (nds32_can_use_return_insn): New. * config/nds32/nds32.md (unspec_volatile_func_return): Remove. (return_internal): New. (return): Define this named pattern. (simple_return): Define this named pattern. * config/nds32/nds32.c (nds32_expand_epilogue): Emit return_internal pattern instead of unspec_volatile_func_return. (nds32_expand_epilogue_v3pop): Likewise. (nds32_can_use_return_insn): New function. Best regards, jasonwucj 0008-Use-simple_return-named-pattern-so-that-shirnk-wrapp.patch Description: Binary data
RE: [PATCH] Fix for PR64081 in RTL loop unroller
Unfortunately this patch broke bootstrap on AIX (PPC32) PR bootstrap/64676 - David
Re: Use static chain and libffi for Go closures
On 01/19/2015 02:26 AM, Andreas Schwab wrote:
Ian Lance Taylor i...@golang.org writes:
@@ -83,7 +83,7 @@
#else /* !defined(USE_LIBFFI_CLOSURES) */
void
-makeFuncFFI(const struct __go_func_type *ftyp, ffi_go_closure *impl)
+makeFuncFFI(const struct __go_func_type *ftyp, void *impl)
{
runtime_panicstring (libgo built without FFI does not support
reflect.MakeFunc);
../../../libgo/go/reflect/makefunc_ffi_c.c: In function ‘makeFuncFFI’:
../../../libgo/go/reflect/makefunc_ffi_c.c:86:42: error: unused parameter
‘ftyp’ [-Werror=unused-parameter]
makeFuncFFI(const struct __go_func_type *ftyp, void *impl)
^
../../../libgo/go/reflect/makefunc_ffi_c.c:86:54: error: unused parameter
‘impl’ [-Werror=unused-parameter]
makeFuncFFI(const struct __go_func_type *ftyp, void *impl)
Fixed thus; applying to mainline after build testing a cross tomips64el-linux.
Ian, I assume you'll push this upstream?
r~
diff --git a/libgo/go/reflect/makefunc_ffi_c.c
b/libgo/go/reflect/makefunc_ffi_c.c
index 2a98e9b..06a41ef 100644
--- a/libgo/go/reflect/makefunc_ffi_c.c
+++ b/libgo/go/reflect/makefunc_ffi_c.c
@@ -83,7 +83,8 @@ makeFuncFFI(const struct __go_func_type *ftyp, void *impl)
#else /* !defined(USE_LIBFFI_CLOSURES) */
void
-makeFuncFFI(const struct __go_func_type *ftyp, void *impl)
+makeFuncFFI(const struct __go_func_type *ftyp __attribute__ ((unused)),
+ void *impl __attribute__ ((unused)))
{
runtime_panicstring (libgo built without FFI does not support
reflect.MakeFunc);
Reduce inline-unit-growth to 15%
Hi,
this patch reduces unit growth to 15%. This is important change for LTO builds.
For example Firefox binary reduces by about 10%. I hope this change is now
safe with increased early-inlining-insns and improvements in inline analysis.
I benchmarked this on Firefox, majority of C++ testsuite and Martin did
Spec2k6 testing. All those indicate noticeable code size reductions and I
am not aware of important perfromance issues.
The importance of this change for LTO comes from fact that single unit
compilation hardly meets the limit unless the program is heavy user of C++
abstractions (like tramp3d or DLV), but with LTO all functions became
cross-module inlinable and even C programs suffers from large code bloat caused
by tons of cross-module inlining which is not really desirable in all cases.
I will wait for nightly testers to pick the results up, but really hope it is
possible to reduce the default this time.
Bootstrapped/regtested x86_64-linux.
Honza
* params.def (inline-unit-growth): Drop to 15%.
* invoke.texi (inline-unit-growth): Document change.
Index: params.def
===
--- params.def (revision 219826)
+++ params.def (working copy)
@@ -190,7 +190,7 @@ DEFPARAM(PARAM_LARGE_UNIT_INSNS,
DEFPARAM(PARAM_INLINE_UNIT_GROWTH,
inline-unit-growth,
How much can given compilation unit grow because of the inlining (in
percent),
-30, 0, 0)
+15, 0, 0)
DEFPARAM(PARAM_IPCP_UNIT_GROWTH,
ipcp-unit-growth,
How much can given compilation unit grow because of the
interprocedural constant propagation (in percent),
Index: doc/invoke.texi
===
--- doc/invoke.texi (revision 219826)
+++ doc/invoke.texi (working copy)
@@ -10001,7 +10001,7 @@ before applying @option{--param inline-u
@item inline-unit-growth
Specifies maximal overall growth of the compilation unit caused by inlining.
-The default value is 30 which limits unit growth to 1.3 times the original
+The default value is 15 which limits unit growth to 1.15 times the original
size. Cold functions (either marked cold via an attribute or by profile
feedback) are not accounted into the unit size.
Re: [PATCH][AArch64] Improve bit-test-branch pattern to avoid unnecessary register clobber
On Mon, Jan 19, 2015 at 10:52:14AM +, Ramana Radhakrishnan wrote: What is aarch64 specific on the testcase? The number of if-then-else's required to get the compiler to generate cmp branch sequences rather than the tbnz instruction. That doesn't mean the same testcase couldn't be tested on other targets and perhaps find bugs in there. That said, if the testcase is too expensive to compile (several seconds is ok, minutes is not), then perhaps it shouldn't be included at all, or should be guarded with run_expensive_tests target. Jakub
Re: libgo patch committed: Update to Go 1.4
Ian Lance Taylor i...@golang.org writes: On Thu, Jan 15, 2015 at 8:30 AM, Rainer Orth r...@cebitec.uni-bielefeld.de wrote: Apart from that, bootstrap fails in gotools: due to the use of -static-libgo, all commands there fail to link since the socket functions are missing. It seems like $LIBS from libgo needs to be added somewhere, but I'm unsure how best to handle this. To make any progress at all, I've just manually added -lsocket -lnsl to gotools/Makefile (AM_LDFLAGS). I also don't know what the best way is to handle this. For now I've just added a configure test to check whether the libraries are needed. Based on the libgo build, as far as I can tell, no other libraries should be needed. While this is true for Solaris 11, Solaris 10 needs librt for nanosleep, sched_yield and the sem_* functions. The following patch copies the corresponding libgo test and allows gotools to build even on Solaris 10. Rainer diff --git a/gotools/Makefile.am b/gotools/Makefile.am --- a/gotools/Makefile.am +++ b/gotools/Makefile.am @@ -108,11 +108,11 @@ bin_PROGRAMS = go$(EXEEXT) gofmt$(EXEEXT libexecsub_PROGRAMS = cgo$(EXEEXT) go$(EXEEXT): $(go_cmd_go_files) zdefaultcc.go $(LIBGODEP) - $(GOLINK) $(go_cmd_go_files) zdefaultcc.go $(NET_LIBS) + $(GOLINK) $(go_cmd_go_files) zdefaultcc.go $(LIBS) $(NET_LIBS) gofmt$(EXEEXT): $(go_cmd_gofmt_files) $(LIBGODEP) - $(GOLINK) $(go_cmd_gofmt_files) $(NET_LIBS) + $(GOLINK) $(go_cmd_gofmt_files) $(LIBS) $(NET_LIBS) cgo$(EXEEXT): $(go_cmd_cgo_files) zdefaultcc.go $(LIBGODEP) - $(GOLINK) $(go_cmd_cgo_files) zdefaultcc.go $(NET_LIBS) + $(GOLINK) $(go_cmd_cgo_files) zdefaultcc.go $(LIBS) $(NET_LIBS) else diff --git a/gotools/configure.ac b/gotools/configure.ac --- a/gotools/configure.ac +++ b/gotools/configure.ac @@ -79,6 +79,10 @@ AC_CACHE_CHECK([for socket libraries], g NET_LIBS=$gotools_cv_lib_sockets AC_SUBST(NET_LIBS) +dnl Test if -lrt is required for sched_yield and/or nanosleep. +AC_SEARCH_LIBS([sched_yield], [rt]) +AC_SEARCH_LIBS([nanosleep], [rt]) + AC_CONFIG_FILES(Makefile) AC_OUTPUT -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [Patch, libstdc++/64584, libstdc++/64585] Clear basic_regex after imbue and make assign exception tolerant
On 17/01/15 16:06 -0800, Tim Shen wrote: On Fri, Jan 16, 2015 at 4:12 AM, Jonathan Wakely jwak...@redhat.com wrote: In that case, why bother using a unique_ptr initially, if it will just have to allocate a shared_ptr control block later anyway? It's better to use make_shared to reduce the number of allocations, isn't it? Yes you are right, I didn't notice that shared_ptr_NFA can be implicitly converted to shared_ptrconst _NFA. Fixed. OK for trunk and 4.9 - thanks.
Re: [[ARM/AArch64][testsuite] 14/36] Add vqdmlal and vqdmlsl tests.
On 13 January 2015 at 15:18, Christophe Lyon christophe.l...@linaro.org wrote: * gcc.target/aarch64/advsimd-intrinsics/vqdmlXl.inc: New file. * gcc.target/aarch64/advsimd-intrinsics/vqdmlal.c: New file. * gcc.target/aarch64/advsimd-intrinsics/vqdmlsl.c: New file. OK /Marcus
Re: [[ARM/AArch64][testsuite] 18/36] Add vsli_n and vsri_n tests.
On 16 January 2015 at 18:06, Tejas Belagod tejas.bela...@arm.com wrote:
+
+void vsri_extra(void)
+{
+/* Test cases with maximum shift amount (this amount is different
+ * from vsli. */
+
Nit. Comment Formatting. Similarly, few other places.
Otherwise, LGTM.
Tejas.
w.r.t the unbalanced parenthesis then fair point. This suite of tests
has numerous gnu style inconsistencies. Given that Christophe is
importing a pre-existing body of code and that this is in testsuite it
seemed unreasonable to insist on a reformat. Christophe, fix up the
unbalanced parenthesis and this is OK. /Marcus
Re: [[ARM/AArch64][testsuite] 19/36] Add vsubl tests, put most of the code in common with vaddl in vXXXl.inc.
On 13 January 2015 at 15:18, Christophe Lyon christophe.l...@linaro.org wrote: * gcc.target/aarch64/advsimd-intrinsics/vXXXl.inc: New file. * gcc.target/aarch64/advsimd-intrinsics/vsubl.c: New file. * gcc.target/aarch64/advsimd-intrinsics/vaddl.c: Use code from vXXXl.inc. OK /Marcus
Re: [PATCH] [AArch64, NEON] Fix testcases add by r218484
On 16 December 2014 at 11:26, Yangfei (Felix) felix.y...@huawei.com wrote: The v3 patch attached fixed this minor issue. Thanks. +2014-12-13 Felix Yang felix.y...@huawei.com + Haijian Zhang z.zhanghaij...@huawei.com + + * gcc.target/aarch64/advsimd-intrinsics/compute-ref-data.h + (buffer_float64x2, buffer_pad_float64x2): New helper variables. + * gcc.target/aarch64/advsimd-intrinsics/arm-neon-ref.h (hfloat64_t, + result_float64x2, expected_hfloat64x2): New helper type, variable and + declaration. + (buffer_float64x2, buffer_pad_float64x2): New helper variables. + * gcc.target/aarch64/advsimd-intrinsics/vfma.c: Don't run on target + without the FMA feature and exclude test for vfmaq_f64 on arm*-*-*. + * gcc.target/aarch64/advsimd-intrinsics/vfms.c: Don't run on target + without the FMA feature and exclude test for vfmsq_f64 on arm*-*-*. + * gcc.target/aarch64/advsimd-intrinsics/vfma_n.c: Don't run on arm*-*-* + and target without the FMA feature. This is OK /Marcus
[PATCH] Fix scheduling undeterminism from sorting with DEBUG_INSNs
Hi, Even though I have bootstrapped and tested the autoprefetch patch before checking it in, I missed the -mcpu=cortex-a15 setting, so I bootstrapped without autoprefetch model being active. Turning the autoprefetch on revealed an interesting bootstrap miscompare problem. I'm sorry I didn't spot this before checking in autoprefetch patch. The bug this patch fixes was latent since introduction of DEBUG_INSNs. It can be reproduced on, at least, ia64, and, I believe, most other targets too. The bug can't cause wrong code, and only affects code sameness with and without debugging information enabled. 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. Presence or absence of DEBUG_INSNs in the ready list can change the comparison order, and cause slightly different instruction schedules. I have thought what the best fix is, and it seems unrealistic to convert rank_for_schedule into a absolute-order heuristic without sacrificing its performance. The solution that I propose (and that the patch implements) is to sort DEBUG_INSNs separately from normal insns. If DEBUG_INSNs are present in the ready_list, sort the DEBUG_INSNs only among themselves, while preserving order of the normal insns. Once there are no DEBUG_INSNs in the ready list, sort using the rank_for_schedule heuristic, just as when we would when compiling without debug info. Bootstrapped and regtested on arm-linux-gnueabihf/cortex-a15. OK to commit? Thank you, -- Maxim Kuvyrkov www.linaro.org 0001-Fix-scheduling-undeterminism-from-sorting-with-DEBUG.patch Description: Binary data
Re: [[ARM/AArch64][testsuite] 05/36] Add vldX_dup test.
On 16 January 2015 at 18:12, Christophe Lyon christophe.l...@linaro.org wrote: On 16 January 2015 at 16:20, Tejas Belagod tejas.bela...@arm.com wrote: On 13/01/15 15:18, Christophe Lyon wrote: * gcc.target/aarch64/advsimd-intrinsics/vldX_dup.c: New file. Thanks, I should mention that this test fails on aarch64_be, because of pending Alan's patches. OK, thanks /Marcus
Re: [[ARM/AArch64][testsuite] 07/36] Add vmla_lane and vmls_lane tests.
On 13 January 2015 at 15:18, Christophe Lyon christophe.l...@linaro.org wrote: * gcc.target/aarch64/advsimd-intrinsics/vmlX_lane.inc: New file. * gcc.target/aarch64/advsimd-intrinsics/vmla_lane.c: New file. * gcc.target/aarch64/advsimd-intrinsics/vmls_lane.c: New file. OK with Tejas' comment addressed. /Marcus
Re: [[ARM/AArch64][testsuite] 08/36] Add vtrn tests. Refactor vzup and vzip tests.
On 16 January 2015 at 18:10, Christophe Lyon christophe.l...@linaro.org wrote: On 16 January 2015 at 16:58, Tejas Belagod tejas.bela...@arm.com wrote: On 13/01/15 15:18, Christophe Lyon wrote: * gcc.target/aarch64/advsimd-intrinsics/vshuffle.inc: New file. * gcc.target/aarch64/advsimd-intrinsics/vtrn.c: New file. * gcc.target/aarch64/advsimd-intrinsics/vuzp.c: Use code from vshuffle.inc. * gcc.target/aarch64/advsimd-intrinsics/vzip.c: Use code from vshuffle.inc. LGTM. Thanks, I should mention that the new vtrn test fails on aarch64_be (like vzip and vuzp), because of pending Alan's patches to fix aarch64_be load/stores. So strictly speaking this patch show new fails. OK /Marcus
Re: [[ARM/AArch64][testsuite] 12/36] Add vmlal_n and vmlsl_n tests.
On 13 January 2015 at 15:18, Christophe Lyon christophe.l...@linaro.org wrote: * gcc.target/aarch64/advsimd-intrinsics/vmlXl_n.inc: New file. * gcc.target/aarch64/advsimd-intrinsics/vmlal_n.c: New file. * gcc.target/aarch64/advsimd-intrinsics/vmlsl_n.c: New file. OK /Marcus
Re: [[ARM/AArch64][testsuite] 20/36] Add vsubw tests, putting most of the code in common with vaddw through vXXWw.inc
On 13 January 2015 at 15:18, Christophe Lyon christophe.l...@linaro.org wrote: * gcc.target/aarch64/advsimd-intrinsics/vXXXw.inc: New file. * gcc.target/aarch64/advsimd-intrinsics/vsubw.c: New file. * gcc.target/aarch64/advsimd-intrinsics/vaddw.c: Use code from vXXXw.inc. OK /Marcus
Re: [Patch, AArch64, testsuite] PR63971: Revert test_frame_* patch.
On 19/01/15 08:53, Andrew Pinski wrote:
On Thu, Jan 15, 2015 at 8:18 AM, Mike Stump mikest...@comcast.net wrote:
On Jan 14, 2015, at 3:50 AM, Tejas Belagod tejas.bela...@arm.com wrote:
As agreed here (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63971), please can
I reverse Andrew's patch
out(https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02916.html)?
Ok.
Unless someone objects to a reversion like this, when the author of a patch
says it should be reverted… that’s all the approval it needs, though, people
can always ask for a review for any reason they want.
And now this reversal needs to be reverted. Because the conditional
compare optimization went back in. I figured the optimization would
go back in and that is why I did not act on reverting my patch that
fast. The conditional compare patch went in a day after this reversal
went in ;).
Yes, now committed r219838 as obvious.
Thanks,
Tejas.
diff --git a/gcc/testsuite/gcc.target/aarch64/test_frame_1.c
b/gcc/testsuite/gcc.target/aarch64/test_frame_1.c
index 5b3c0ab..b270bae 100644
--- a/gcc/testsuite/gcc.target/aarch64/test_frame_1.c
+++ b/gcc/testsuite/gcc.target/aarch64/test_frame_1.c
@@ -14,6 +14,6 @@ t_frame_pattern (test1, 200, )
t_frame_run (test1)
/* { dg-final { scan-assembler-times str\tx30, \\\[sp, -\[0-9\]+\\\]! 2 } }
*/
-/* { dg-final { scan-assembler-times ldr\tx30, \\\[sp\\\], \[0-9\]+ 3 } } */
+/* { dg-final { scan-assembler-times ldr\tx30, \\\[sp\\\], \[0-9\]+ 2 } } */
/* { dg-final { cleanup-saved-temps } } */
diff --git a/gcc/testsuite/gcc.target/aarch64/test_frame_2.c
b/gcc/testsuite/gcc.target/aarch64/test_frame_2.c
index 6ec4088..59a089c 100644
--- a/gcc/testsuite/gcc.target/aarch64/test_frame_2.c
+++ b/gcc/testsuite/gcc.target/aarch64/test_frame_2.c
@@ -15,6 +15,6 @@ t_frame_run (test2)
/* { dg-final { scan-assembler-times stp\tx19, x30, \\\[sp, -\[0-9\]+\\\]! 1
} } */
-/* { dg-final { scan-assembler-times ldp\tx19, x30, \\\[sp\\\], \[0-9\]+ 2 }
} */
+/* { dg-final { scan-assembler-times ldp\tx19, x30, \\\[sp\\\], \[0-9\]+ 1 }
} */
/* { dg-final { cleanup-saved-temps } } */
diff --git a/gcc/testsuite/gcc.target/aarch64/test_frame_4.c
b/gcc/testsuite/gcc.target/aarch64/test_frame_4.c
index ebfb290..d717862 100644
--- a/gcc/testsuite/gcc.target/aarch64/test_frame_4.c
+++ b/gcc/testsuite/gcc.target/aarch64/test_frame_4.c
@@ -14,6 +14,6 @@ t_frame_pattern (test4, 400, x19)
t_frame_run (test4)
/* { dg-final { scan-assembler-times stp\tx19, x30, \\\[sp, -\[0-9\]+\\\]! 1
} } */
-/* { dg-final { scan-assembler-times ldp\tx19, x30, \\\[sp\\\], \[0-9\]+ 2 }
} */
+/* { dg-final { scan-assembler-times ldp\tx19, x30, \\\[sp\\\], \[0-9\]+ 1 }
} */
/* { dg-final { cleanup-saved-temps } } */
diff --git a/gcc/testsuite/gcc.target/aarch64/test_frame_6.c
b/gcc/testsuite/gcc.target/aarch64/test_frame_6.c
index b5ea7ee..b66ce09 100644
--- a/gcc/testsuite/gcc.target/aarch64/test_frame_6.c
+++ b/gcc/testsuite/gcc.target/aarch64/test_frame_6.c
@@ -15,6 +15,6 @@ t_frame_pattern (test6, 700, )
t_frame_run (test6)
/* { dg-final { scan-assembler-times str\tx30, \\\[sp, -\[0-9\]+\\\]! 2 } }
*/
-/* { dg-final { scan-assembler-times ldr\tx30, \\\[sp\\\], \[0-9\]+ 3 } } */
+/* { dg-final { scan-assembler-times ldr\tx30, \\\[sp\\\], \[0-9\]+ 2 } } */
/* { dg-final { cleanup-saved-temps } } */
diff --git a/gcc/testsuite/gcc.target/aarch64/test_frame_7.c
b/gcc/testsuite/gcc.target/aarch64/test_frame_7.c
index daa1f42..22576c4 100644
--- a/gcc/testsuite/gcc.target/aarch64/test_frame_7.c
+++ b/gcc/testsuite/gcc.target/aarch64/test_frame_7.c
@@ -15,6 +15,6 @@ t_frame_pattern (test7, 700, x19)
t_frame_run (test7)
/* { dg-final { scan-assembler-times stp\tx19, x30, \\\[sp, -\[0-9\]+\\\]! 1
} } */
-/* { dg-final { scan-assembler-times ldp\tx19, x30, \\\[sp\\\], \[0-9\]+ 2 }
} */
+/* { dg-final { scan-assembler-times ldp\tx19, x30, \\\[sp\\\], \[0-9\]+ 1 }
} */
/* { dg-final { cleanup-saved-temps } } */
Re: [AArch64/GCC] PR64304, miscompilation with -mgeneral-regs-only
On 16 January 2015 at 11:17, Jiong Wang jiong.w...@arm.com wrote: exactly, thanks, we should use FAIL although DONE and FAIL work the same in this scenario. I checked their definition, FAIL always return the initial value of _val which is NULL, while DONE stop and return generated insns which for this pattern happen to be NULL also. that explain why it's not exposed by testing. #define FAIL return (end_sequence (), _val) #define DONE return (_val = get_insns (), end_sequence (), _val) It seems rather odd to me that DONE behaves in this way. Your patch is OK with DONE switched to FAIL. /Marcus
Re: [[ARM/AArch64][testsuite] 22/36] Add vmovn tests.
On 13 January 2015 at 15:18, Christophe Lyon christophe.l...@linaro.org wrote: * gcc.target/aarch64/advsimd-intrinsics/vmovn.c: New file. OK /Marcus
Re: [patch] Add codecvt and last pieces of C++11 std::lib
On 16/01/15 23:38 +, Jonathan Wakely wrote:
This defines the C++11 header codecvt and adds the wstring_convert
and wbuffer_convert utilities.
I've discovered that wasn't the last piece of the C++11 library, there
were new constructors taking std::string added to std::locale and all
the std::xxx_byname facets.
It would be fixed by the attached patch (tested on x86_64-linux with
old and new std::string), but we're in stage4 now so I'm not
committing it yet.
commit 977b94ddcf8218efa0318f69b3a2cc5b5d9eb5be
Author: Jonathan Wakely jwak...@redhat.com
Date: Sun Jan 18 16:41:28 2015 +
Add C++11 std::string constructors for locales and facets.
* config/abi/pre/gnu.ver: Export new constructors.
* include/bits/codecvt.h (codecvt_byname): Add string constructor.
(codecvt_bynamechar16_t, codecvt_bynamechar32_t): Define explicit
specializations and declare explicit instantiations.
* include/bits/locale_classes.h (locale, collate_byname): Add string
constructors.
* include/bits/locale_facets.h (ctype_byname, numpunct_byname):
Likewise.
* include/bits/locale_facets_nonio.h (time_get_byname,
time_put_byname, moneypunct_byname, messages_byname): Likewise.
* src/c++11/codecvt.cc (codecvt_bynamechar16_t,
codecvt_bynamechar32_t): Define explicit instantiations.
* src/c++11/locale-inst.cc (time_put_byname, codecvt_byname):
Instantiate string constructors.
(ctype_byname): Define string constructor.
* testsuite/22_locale/codecvt_byname/1.cc: New.
* testsuite/22_locale/collate_byname/1.cc: New.
* testsuite/22_locale/ctype_byname/2.cc: New.
* testsuite/22_locale/messages_byname/1.cc: New.
* testsuite/22_locale/moneypunct_byname/1.cc: New.
* testsuite/22_locale/numpunct_byname/1.cc: New.
diff --git a/libstdc++-v3/config/abi/pre/gnu.ver b/libstdc++-v3/config/abi/pre/gnu.ver
index d23306e..61024bd 100644
--- a/libstdc++-v3/config/abi/pre/gnu.ver
+++ b/libstdc++-v3/config/abi/pre/gnu.ver
@@ -64,8 +64,10 @@ GLIBCXX_3.4 {
# std::char_traits;
# std::c[i-z]*;
std::c[i-n]*;
+# std::collate;
+# std::collate_byname;
# std::condition_variable;
- std::co[^n]*;
+ std::co[^ln]*;
std::c[p-s]*;
std::cu[^r]*;
# std::current_exception
@@ -527,6 +529,14 @@ GLIBCXX_3.4 {
# std::use_facet
_ZSt9use_facetIS*;
+# std::collate
+_ZNSt7collateI[cw]*;
+_ZNKSt7collateI[cw]*;
+
+# std::collate_byname
+_ZNSt14collate_bynameI[cw]EC[12]EPKc?*;
+_ZNSt14collate_bynameI[cw]ED*;
+
# std::ctype
_ZNKSt5ctypeIcE8*;
_ZNKSt5ctypeIcE9*;
@@ -538,7 +548,8 @@ GLIBCXX_3.4 {
_ZNSt10ctype_base[56][ac-z]*;
# std::ctype_byname
-_ZNSt12ctype_bynameI[cw]*;
+_ZNSt12ctype_bynameI[cw]EC[12]EPKc?*;
+_ZNSt12ctype_bynameI[cw]ED*;
# std::num_get
_ZNKSt7num_getI[cw]St19istreambuf_iteratorI[cw]St11char_traitsI[cw]EEE[2-9]*;
@@ -573,7 +584,8 @@ GLIBCXX_3.4 {
_ZNKSt8time_put*;
# std::time_put_byname
-_ZNSt15time_put_byname*;
+_ZNSt15time_put_bynameI[cw]*EC[12]EPKc?*;
+_ZNSt15time_put_bynameI[cw]*ED[012]Ev;
# std::numeric_limits
_ZNSt21__numeric_limits_base[5-9]*;
@@ -1780,6 +1792,25 @@ GLIBCXX_3.4.21 {
_ZNSt25__codecvt_utf8_utf16_base*;
_ZT[ISV]St25__codecvt_utf8_utf16_base*;
+# new string ctors for _byname facets
+_ZNSt12ctype_bynameI[cw]EC[1-5]ERKSsm;
+_ZNSt14codecvt_bynameI[cw]c11__mbstate_tEC[1-5]ERKSsm;
+_ZNSt15messages_bynameI[cw]EC[1-5]ERKSsm;
+_ZNSt15numpunct_bynameI[cw]EC[1-5]ERKSsm;
+_ZNSt15time_get_bynameI[cw]St19istreambuf_iteratorI[cw]St11char_traitsI[cw]EEEC[1-5]ERKSsm;
+_ZNSt15time_put_bynameI[cw]St19ostreambuf_iteratorI[cw]St11char_traitsI[cw]EEEC[1-5]ERKSsm;
+_ZNSt17moneypunct_bynameI[cw]Lb0EEC[1-5]ERKSsm;
+_ZNSt17moneypunct_bynameI[cw]Lb1EEC[1-5]ERKSsm;
+
+_ZNSt12ctype_bynameI[cw]EC[1-5]ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEm;
+_ZNSt14codecvt_bynameI[cw]c11__mbstate_tEC[1-5]ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEm;
+_ZNSt15time_put_bynameI[cw]St19ostreambuf_iteratorI[cw]St11char_traitsI[cw]EEEC[1-5]ERKNSt7__cxx1112basic_stringIcS2_SaIcEEEm;
+_ZNSt7__cxx1115messages_bynameI[cw]EC[1-5]ERKNS_12basic_stringIcSt11char_traitsIcESaIcEEEm;
+_ZNSt7__cxx1115numpunct_bynameI[cw]EC[1-5]ERKNS_12basic_stringIcSt11char_traitsIcESaIcEEEm;
+_ZNSt7__cxx1115time_get_bynameI[cw]St19istreambuf_iteratorI[cw]St11char_traitsI[cw]EEEC[1-5]ERKNS_12basic_stringIcS3_SaIcEEEm;
+_ZNSt7__cxx1117moneypunct_bynameI[cw]Lb0EEC[1-5]ERKNS_12basic_stringIcSt11char_traitsIcESaIcEEEm;
+_ZNSt7__cxx1117moneypunct_bynameI[cw]Lb1EEC[1-5]ERKNS_12basic_stringIcSt11char_traitsIcESaIcEEEm;
+
} GLIBCXX_3.4.20;
diff --git a/libstdc++-v3/include/bits/codecvt.h b/libstdc++-v3/include/bits/codecvt.h
index a6e59b5..c76215f 100644
--- a/libstdc++-v3/include/bits/codecvt.h
+++
Re: [PATCH] Fix scheduling undeterminism from sorting with DEBUG_INSNs
On Mon, 19 Jan 2015, 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. Presence or absence of DEBUG_INSNs in the ready list can change the comparison order, and cause slightly different instruction schedules. Could you please provide a bit more detail here? Looking at rank_for_schedule, I see that it considers insn pairs when at least one of them is DEBUG_INSN, first. Debug insns are always moved to front, sorted within themselves by luid, and not considered in the rest of rank_for_schedule. I don't see how rank_for_schedule with DEBUG_INSN can arrive at a A B C A situation. (btw, nitpicking, a partial order is when incomparable pairs are possible (i.e. none of A == B, A B, B A is true), a total order is when all pairs are comparable, and when you can have A B C A, it's not a mathematical order relation) Thanks. Alexander
Re: [PATCH][AArch64] PR 64448: Combine ((x ^ y) m) ^ x into bsl/bif instruction
On 16 January 2015 at 16:54, Kyrill Tkachov kyrylo.tkac...@arm.com wrote: 2014-01-16 Kyrylo Tkachov kyrylo.tkac...@arm.com PR target/64448 * config/aarch64/aarch64-simd.md (aarch64_simd_bslmode_internal): Match xor-and-xor RTL pattern. OK /Marcus
Re: [Patch, libstdc++/64649] Fix regex_traits::lookup_collatename and regex_traits::lookup_classname
On 17/01/15 23:09 -0800, Tim Shen wrote:
Bootstrapped and tested in trunk, but I guess it'll fit 4.9 branch
well. I'll do another test for 4.9 if it's appropriate to commit.
Thanks!
--
Regards,
Tim Shen
PR libstdc++/64649
* include/bits/regex.tcc (regex_traits::lookup_collatename,
regex_traits::lookup_classname): Conform forward iterator constrain
for lookup_collatename lookup_classname.
I think this is clearer:
* include/bits/regex.tcc (regex_traits::lookup_collatename,
regex_traits::lookup_classname): Support forward iterators.
* testsuite/28_regex/traits/char/lookup_classname.cc: New testcases.
* testsuite/28_regex/traits/char/lookup_collatename.cc: New testcase.
+ string __s(__first, __last);
This assumes the _ForwardIterator value_type is char, or safely
convertible to char. If I'm reading the standard correctly
regex_traitswchar_t should be able to accept an iterator range
referring to wide chars, e.g.
std::forward_listwchar_t l{L't', L'i', L'l', L'd', L'e'};
std::regex_traitswchar_t{}.lookup_collatename(l.begin(), l.end())
Maybe it's OK, because all the elements of __collatename use ASCII
chars which have the same value as wide chars? (Probably not true for
all locales).
Your change is definitely an improvement and good enough for now
(maybe we should leave the Bugzilla PR open, with a note about the
wide char issue, and deal with it after stage4).
OK for trunk - thanks.
Re: [[ARM/AArch64][testsuite] 03/36] Add vmax, vmin, vhadd, vhsub and vrhadd tests.
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? /Marcus
Re: [patch] Add codecvt and last pieces of C++11 std::lib
On Mon, Jan 19, 2015 at 01:27:17PM +, Jonathan Wakely wrote: On 16/01/15 23:38 +, Jonathan Wakely wrote: This defines the C++11 header codecvt and adds the wstring_convert and wbuffer_convert utilities. I've discovered that wasn't the last piece of the C++11 library, there were new constructors taking std::string added to std::locale and all the std::xxx_byname facets. It would be fixed by the attached patch (tested on x86_64-linux with old and new std::string), but we're in stage4 now so I'm not committing it yet. If it is the only missing C++11 part, or close to that, I think it would be still ok for trunk now. Jakub
Re: [[ARM/AArch64][testsuite] 06/36] Add vmla and vmls tests.
On 13 January 2015 at 15:18, Christophe Lyon christophe.l...@linaro.org wrote: * gcc.target/aarch64/advsimd-intrinsics/vmlX.inc: New file. * gcc.target/aarch64/advsimd-intrinsics/vmla.c: New file. * gcc.target/aarch64/advsimd-intrinsics/vmls.c: New file. OK with the the vmlx poly ops dropped /M
Re: [PATCH] Fix scheduling undeterminism from sorting with DEBUG_INSNs
On Jan 19, 2015, at 4:34 PM, Alexander Monakov amona...@ispras.ru wrote: On Mon, 19 Jan 2015, 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. Presence or absence of DEBUG_INSNs in the ready list can change the comparison order, and cause slightly different instruction schedules. Could you please provide a bit more detail here? Looking at rank_for_schedule, I see that it considers insn pairs when at least one of them is DEBUG_INSN, first. Debug insns are always moved to front, sorted within themselves by luid, and not considered in the rest of rank_for_schedule. I don't see how rank_for_schedule with DEBUG_INSN can arrive at a A B C A situation. In A B C A case all A, B and C are normal instructions. It is a pre-existing condition. When compiling without debug information we have ready list A, B, C. When compiling with debug information, we have ready list A, B, C, D where D is DEBUG_INSN. Because we now have 4 elements to sort instead of 3, qsort can choose a different order of comparison _among_ A, B and C. Since order of comparison matters (due to pre-existing condition of A B C D) we can get a differently-sorted list. (btw, nitpicking, a partial order is when incomparable pairs are possible (i.e. none of A == B, A B, B A is true), a total order is when all pairs are comparable, and when you can have A B C A, it's not a mathematical order relation) You've got good grades in the Uni, didn't you :-). -- Maxim Kuvyrkov www.linaro.org
Re: [[ARM/AArch64][testsuite] 10/36] Add vmlal and vmlsl tests.
On 13 January 2015 at 15:18, Christophe Lyon christophe.l...@linaro.org wrote: * gcc.target/aarch64/advsimd-intrinsics/vmlXl.inc: New file. * gcc.target/aarch64/advsimd-intrinsics/vmlal.c: New file. * gcc.target/aarch64/advsimd-intrinsics/vmlsl.c: New file. OK /Marcus
Re: [[ARM/AArch64][testsuite] 11/36] Add vmlal_lane and vmlsl_lane tests.
On 13 January 2015 at 15:18, Christophe Lyon christophe.l...@linaro.org wrote: * gcc.target/aarch64/advsimd-intrinsics/vmlXl_lane.inc: New file. * gcc.target/aarch64/advsimd-intrinsics/vmlal_lane.c: New file. * gcc.target/aarch64/advsimd-intrinsics/vmlsl_lane.c: New file. OK /Marcus
Re: [[ARM/AArch64][testsuite] 15/36] Add vqdmlal_lane and vqdmlsl_lane tests.
On 13 January 2015 at 15:18, Christophe Lyon christophe.l...@linaro.org wrote: * gcc.target/aarch64/advsimd-intrinsics/vqdmlXl_lane.inc: New file. * gcc.target/aarch64/advsimd-intrinsics/vqdmlal_lane.c: New file. * gcc.target/aarch64/advsimd-intrinsics/vqdmlsl_lane.c: New file. OK /Marcus
Re: [[ARM/AArch64][testsuite] 16/36] Add vqdmlal_n and vqdmlsl_n tests.
On 13 January 2015 at 15:18, Christophe Lyon christophe.l...@linaro.org wrote: * gcc.target/aarch64/advsimd-intrinsics/vqdmlXl_n.inc: New file. * gcc.target/aarch64/advsimd-intrinsics/vqdmlal_n.c: New file. * gcc.target/aarch64/advsimd-intrinsics/vqdmlsl_n.c: New file. OK /Marcus
[PATCH] Fix PR64313
This fixes PR64313 - the match-and-simplify machinery has a hard
time re-doing the magic trick of re-using builtins in the matched IL
and thus fails to generate calls to builtins that are not marked
as builtin_decl_implicit_p.
The following patch fixes this by remembering whether the user
has declared a builtin in a new per-builtin flag and recognizing
explicit uses (in ADDR_EXPRs which catches calls and address-takens)
during gimplification. For explicitely used builtins the compiler
can generate them implicitely (well, not 100% true - the semantics
do not have to agree unless the identifier is reserved, sth we can't
check easily).
This is an approach that follows that of the STPCPY case right next
to the place this patch patches the frontends, just a little bit less
aggressive in requiring an explicit use of the builtin.
No attempt is done to preserve (and merge) this through LTO - builtins
are streamed by simply streaming DECL_FUNCTION_CODE which makes doing
this a bit hard(er). The gcc.dg/torture/builtin-explog-1.c testcase
was failing on bare-metal targets and is fixed with the patch below
already during early optimizations.
An alternative to fix the regression is to remove the very few
builtin simplification patterns from match.pd and/or restore
the folding code in builtins.c. The issue would then need to
be revisited during the next stage1 (where I can look into how to
deal with this with LTO - but 'implicit_p' is also not transitioned
properly if you combine for example a C89 input and C99 input - lto1
defaults all of flag_isoc{94,99,11} to zero and uses the C family
builtins.def way of initialization, so the LTO issue is certainly
pre-existing).
Ok for trunk now?
Bootstrap and regtest is running on x86_64-unknown-linux-gnu.
Thanks,
Richard.
2015-01-19 Richard Biener rguent...@suse.de
PR middle-end/64313
* tree-core.h (builtin_info, builtin_info_type): Turn from
an object with two arrays into an array of an object with
decl and two flags, implicit_p and declared_p.
* tree.h (builtin_decl_explicit, builtin_decl_implicit,
set_builtin_decl, set_builtin_decl_implicit_p,
builtin_decl_explicit_p, builtin_decl_implicit_p): Adjust.
(set_builtin_decl_declared_p, builtin_decl_declared_p): New functions.
* builtins.c (builtin_info): Adjust.
* gimplify.c (gimplify_addr_expr): References to builtins
that have been declared by the user makes them eligible for
use by the compiler. Call set_builtin_decl_implicit_p on them.
c/
* c-decl.c (merge_decls): Call set_builtin_decl_declared_p
for builtins the user declared correctly.
cp/
* decl.c (duplicate_decls): Call set_builtin_decl_declared_p
for builtins the user declared correctly.
Index: gcc/tree.h
===
*** gcc/tree.h.orig 2015-01-19 14:51:26.175142267 +0100
--- gcc/tree.h 2015-01-19 15:11:48.602099942 +0100
*** builtin_decl_explicit (enum built_in_fun
*** 4606,4612
{
gcc_checking_assert (BUILTIN_VALID_P (fncode));
! return builtin_info.decl[(size_t)fncode];
}
/* Return the tree node for an implicit builtin function or NULL. */
--- 4606,4612
{
gcc_checking_assert (BUILTIN_VALID_P (fncode));
! return builtin_info[(size_t)fncode].decl;
}
/* Return the tree node for an implicit builtin function or NULL. */
*** builtin_decl_implicit (enum built_in_fun
*** 4616,4625
size_t uns_fncode = (size_t)fncode;
gcc_checking_assert (BUILTIN_VALID_P (fncode));
! if (!builtin_info.implicit_p[uns_fncode])
return NULL_TREE;
! return builtin_info.decl[uns_fncode];
}
/* Set explicit builtin function nodes and whether it is an implicit
--- 4616,4625
size_t uns_fncode = (size_t)fncode;
gcc_checking_assert (BUILTIN_VALID_P (fncode));
! if (!builtin_info[uns_fncode].implicit_p)
return NULL_TREE;
! return builtin_info[uns_fncode].decl;
}
/* Set explicit builtin function nodes and whether it is an implicit
*** set_builtin_decl (enum built_in_function
*** 4633,4640
gcc_checking_assert (BUILTIN_VALID_P (fncode)
(decl != NULL_TREE || !implicit_p));
! builtin_info.decl[ufncode] = decl;
! builtin_info.implicit_p[ufncode] = implicit_p;
}
/* Set the implicit flag for a builtin function. */
--- 4633,4641
gcc_checking_assert (BUILTIN_VALID_P (fncode)
(decl != NULL_TREE || !implicit_p));
! builtin_info[ufncode].decl = decl;
! builtin_info[ufncode].implicit_p = implicit_p;
! builtin_info[ufncode].declared_p = false;
}
/* Set the implicit flag for a builtin function. */
*** set_builtin_decl_implicit_p (enum built_
*** 4645,4653
size_t uns_fncode = (size_t)fncode;
gcc_checking_assert (BUILTIN_VALID_P
[Patch ARM] PR target/64532
While looking at PR target/64532- I realized we haven't documented all
the register constraints. I'm not documenting the other immediate
constraints as it is not clear to me how much of that is actually useful
yet and I don't have the time this afternoon to clean this up.
Built documentation and looked at it.
Applied.
Ramana
DATE Ramana Radhakrishnan ramana.radhakrish...@arm.com
PR target/64532
* doc/md.texi (ARM Constraints): Document register constraints.
diff --git a/gcc/doc/md.texi b/gcc/doc/md.texi
index 7bc7842..0050ba7 100644
--- a/gcc/doc/md.texi
+++ b/gcc/doc/md.texi
@@ -1800,8 +1800,30 @@ Any const_double value.
@item ARM family---@file{config/arm/constraints.md}
@table @code
+
+@item h
+In Thumb state, the core registers @code{r8}-@code{r15}.
+
+@item k
+The stack pointer register.
+
+@item l
+In Thumb State the core registers @code{r0}-@code{r7}. In ARM state this
+is an alias for the @code{r} constraint.
+
+@item t
+VFP floating-point registers @code{s0}-@code{s31}. Used for 32 bit values.
+
@item w
-VFP floating-point register
+VFP floating-point registers @code{d0}-@code{d31} and the appropriate
+subset @code{d0}-@code{d15} based on command line options.
+Used for 64 bit values only. Not valid for Thumb1.
+
+@item y
+The iWMMX co-processor registers.
+
+@item z
+The iWMMX GR registers.
@item G
The floating-point constant 0.0
[PATCH] Fix PR64664
Hello.
Following patch correctly handles filtered removed items, where we forgot
to check that a cgraph node is deleted or not. Apart from that, logic
in the function was rewritten and is much more understandable what's going on.
Tested on x86_64-linux-pc.
Ready for installation?
Thanks,
Martin
From 3f1d52424d01e7a76b127bf91bdaa04077371d30 Mon Sep 17 00:00:00 2001
From: mliska mli...@suse.cz
Date: Mon, 19 Jan 2015 14:28:50 +0100
Subject: [PATCH] Fix PR64664.
gcc/ChangeLog:
2015-01-19 Martin Liska mli...@suse.cz
* ipa-icf.c (sem_item_optimizer::filter_removed_items):
Handle safe potentially removed nodes during filtering.
---
gcc/ipa-icf.c | 47 +++
1 file changed, 19 insertions(+), 28 deletions(-)
diff --git a/gcc/ipa-icf.c b/gcc/ipa-icf.c
index 0ac01a9..449d552 100644
--- a/gcc/ipa-icf.c
+++ b/gcc/ipa-icf.c
@@ -1652,40 +1652,31 @@ sem_item_optimizer::filter_removed_items (void)
{
sem_item *item = m_items[i];
- if (item-type == FUNC
- !opt_for_fn (item-decl, flag_ipa_icf_functions))
- {
- remove_item (item);
- continue;
- }
-
- if (!flag_ipa_icf_variables item-type == VAR)
- {
+ if (m_removed_items_set.contains (item-node))
+{
remove_item (item);
continue;
- }
-
- bool no_body_function = false;
+}
if (item-type == FUNC)
- {
+{
cgraph_node *cnode = static_cast sem_function *(item)-get_node ();
- no_body_function = in_lto_p (cnode-alias || cnode-body_removed);
- }
-
- if(!m_removed_items_set.contains (m_items[i]-node)
- !no_body_function)
- {
- if (item-type == VAR || (!DECL_CXX_CONSTRUCTOR_P (item-decl)
- !DECL_CXX_DESTRUCTOR_P (item-decl)))
- {
- filtered.safe_push (m_items[i]);
- continue;
- }
- }
-
- remove_item (item);
+ bool no_body_function = in_lto_p (cnode-alias || cnode-body_removed);
+ if (no_body_function || !opt_for_fn (item-decl, flag_ipa_icf_functions)
+ || DECL_CXX_CONSTRUCTOR_P (item-decl)
+ || DECL_CXX_DESTRUCTOR_P (item-decl))
+ remove_item (item);
+ else
+ filtered.safe_push (item);
+}
+ else /* VAR. */
+{
+ if (!flag_ipa_icf_variables)
+ remove_item (item);
+ else
+ filtered.safe_push (item);
+}
}
/* Clean-up of released semantic items. */
--
2.1.2
Re: [[ARM/AArch64][testsuite] 27/36] Add vmull_n tests.
On 13 January 2015 at 15:18, Christophe Lyon christophe.l...@linaro.org wrote: * gcc.target/aarch64/advsimd-intrinsics/vmull_n.c: New file. OK /Marcus
Re: [PATCH] toplev.c: Process the failure when read fails for random_seed
On 12/31/2014 06:26 AM, Joseph Myers wrote: On Mon, 29 Dec 2014, Chen Gang S wrote: And in honest, this year what I have done is really not quite well, next year I should be improved: should scanning Bugzilla and try to fix the existing issues (just like another members' suggestions to me). Note that for any substantial patches you'll need to complete the copyright assignment paperwork (I don't see you listed in copyright.list at present). Excuse me, I am not quite familiar with the related working flow, at present, I finished assignment paperwork for binutils and gdb, and I am one of write after approval member for binutils and gdb. Do you mean I need follow the same working flow for gcc, just as for the binutils and gdb? (or only post my assignment is OK?). If possible, please provide more related details for it. I shall follow. Thanks. -- Open, share, and attitude like air, water, and life which God blessed.
[PATCH] rs6000, jit: Unbreak libgccjit on ppc (rs6000_output_function_epilogue)
rs6000_output_function_epilogue performs a series of string comparisons on language_string, with a gcc_unreachable (); if the language_string is unrecognized. This leads to failure of any attempt to use libgccjit on rs6000, since jit/dummy-frontend.c has: #define LANG_HOOKS_NAME libgccjit The attached patch adds support for this lang hook name, using 0 for the language type. Takes jit.sum from: # of expected passes1417 # of unexpected failures30 to: # of expected passes3428 # of unexpected failures6 (am investigating the other failures) OK for trunk? gcc/ChangeLog * config/rs6000/rs6000.c (rs6000_output_function_epilogue): Support the JIT by using 0 as the language type. --- gcc/config/rs6000/rs6000.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c index 80fcd65..d076656 100644 --- a/gcc/config/rs6000/rs6000.c +++ b/gcc/config/rs6000/rs6000.c @@ -25491,11 +25491,12 @@ rs6000_output_function_epilogue (FILE *file, use language_string. C is 0. Fortran is 1. Pascal is 2. Ada is 3. C++ is 9. Java is 13. Objective-C is 14. Objective-C++ isn't assigned -a number, so for now use 9. LTO and Go aren't assigned numbers +a number, so for now use 9. LTO, Go and JIT aren't assigned numbers either, so for now use 0. */ if (lang_GNU_C () || ! strcmp (language_string, GNU GIMPLE) - || ! strcmp (language_string, GNU Go)) + || ! strcmp (language_string, GNU Go) + || ! strcmp (language_string, libgccjit)) i = 0; else if (! strcmp (language_string, GNU F77) || ! strcmp (language_string, GNU Fortran)) -- 1.8.1.4
Re: [PATCH] Fix sporadic failure in g++.dg/tsan/aligned_vs_unaligned_race.C
On Jan 19, 2015, at 12:47 AM, Dmitry Vyukov dvyu...@google.com wrote: Long story short. Tsan has a logical data race the core of data race detection algorithm. The race is not a bug, but a deliberate design decision that makes tsan considerably faster. Could you please quantify that for us? Also, what lockless update method did you use? Did you try atomic increment? On my machine, they are as cheap as stores; can’t imagine they could be slow at all. If the latency and bandwidth of atomic increment is identical to store, would the costs be any higher than using a store to update the tsan data? A proper port of tsan to my machine would make use of atomic increment. I consider it a simple matter to sequence the thread termination and the output routine to ensure that all the updates in the threads happen before the output routine runs. The output routine strikes me as slow, and thread termination strikes me as slow, so taking a little extra time there seems reasonable. Was the excessive cost you saw due to the termination costs? So ironically, if the race memory accesses happen almost simultaneously, tsan can miss the race. Thus we have sleeps. I’ve not seen a reason why the test suite should randomly fail. The gcc test suite does not. Could you explain why the llvm test suite does? Surely you know that sleep is not a synchronization primitive? Sleeps vs barrier is being discussed in the Fix parameters of __tsan_vptr_update thread. When finished, let us know the outcome. To date, I’ve not seen any compelling reason to have the core of tsan be other than deterministic and the test suite other than deterministic. I’d love to see the backing for such a decision. I would really like to keep llvm and gcc tests in sync as much as possible. Excellent, from my perspective, that would mean that you make the llvm test suite deterministic.
Re: [[ARM/AArch64][testsuite] 24/36] Add vmul_n tests.
On 13 January 2015 at 15:18, Christophe Lyon christophe.l...@linaro.org wrote: * gcc.target/aarch64/advsimd-intrinsics/vmul_n.c: New file. OK /Marcus
Re: [[ARM/AArch64][testsuite] 25/36] Add vmull tests.
On 13 January 2015 at 15:18, Christophe Lyon christophe.l...@linaro.org wrote: * gcc.target/aarch64/advsimd-intrinsics/vmull.c: New file. OK /Marcus
Re: [PATCH] Fix PR64535 - increase emergency EH buffers via a new allocator
On 19/01/15 11:33 +0100, Richard Biener wrote:
On Mon, 12 Jan 2015, Richard Biener wrote:
This fixes PR64535 by changing the fixed object size emergency pool
to a variable EH object size (but fixed arena size) allocator. Via
combining the dependent and non-dependent EH arenas this should allow
around 600 bad_alloc throws in OOM situations on x86_64-linux
compared to the current 64 which should provide some headroom to
the poor souls using EH to communicate OOM in a heavily threaded
enviroment.
Bootstrapped and tested on x86_64-unknown-linux-gnu (with the #if 1
as in the patch below, forcing the use of the allocator).
I see only the #else part is kept now - that was what I was going to
suggest.
Unfortunately I couldn't get an answer of whether throwing
bad_alloc from a throw where we can't allocate an exception
is a) valid or b) even required by the standard ('throw' isn't
listed as 'allocation function' - also our EH allocators are
marked as throw(), so such change would change the ABI...).
I'll ask the C++ committee.
With the cost of some more members I can make the allocator more
generic (use a constructor with a arena and a arena size parameter)
and we may move it somewhere public under __gnu_cxx? But eventually
boost has something like this anyway.
Didn't explore this - it doesn't really match the STL allocator interface
and imposes overhead even over an implementation class (STL allocators
know the size of the objects they free).
Yeah, I don't think there's any advantage complicating this type to
make it usable as an STL allocator - it does what it's designed to do
and that's fine.
I'm re-bootstrapping / testing with the cosmetic changes I did and
with EH allocation not forced to go through the emergency pool
(I've done that in previous bootstraps / tests to get the pool code
exercised).
Any comments? We have a customer that runs into the issue that 64
bad_alloc exceptions are not enough for them (yes, they require bad_alloc
to work when thrown in a massive quantity from threads). Other
solutions for this would include to simply wait and re-try (with possibly
deadlocking if no progress is made) to artificially throttling
bad_alloc allocations from the EH emergency pool (identify it by
size, sleep some time inside the lock).
CCing rth who implemented the existing code.
I don't have any better ideas for fixing the issue, so it's approved
by me. Unless rth comes back with something else please go ahead and
check it in.
Re: [[ARM/AArch64][testsuite] 03/36] Add vmax, vmin, vhadd, vhsub and vrhadd tests.
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. /Marcus
Re: [patch] powerpc-vxworksmils port, variant of powerpc-vxworksae
On Jan 19, 2015, at 16:06 , Gerald Pfeifer ger...@pfeifer.com wrote: This looks sweet, thank you! My pleasure, just checked-in. Thanks for your note and feedback :-)
Re: [PATCH, libstdc++] PR libstdc++/64656
On 19/01/15 02:48 +0200, Ville Voutilainen wrote:
Minor additions:
- add a comment to the #endif for the c++14 #if
- fix the doc comments to talk about reverse iterators
Thanks, I like the new comments more.
This passes the testsuite.
Posted during stage3 so OK for trunk.
diff --git a/libstdc++-v3/include/bits/range_access.h
b/libstdc++-v3/include/bits/range_access.h
index fa18aa2..a5a511c 100644
--- a/libstdc++-v3/include/bits/range_access.h
+++ b/libstdc++-v3/include/bits/range_access.h
@@ -33,7 +33,7 @@
#pragma GCC system_header
#if __cplusplus = 201103L
-
+#include initializer_list
namespace std _GLIBCXX_VISIBILITY(default)
{
_GLIBCXX_BEGIN_NAMESPACE_VERSION
@@ -97,6 +97,131 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
end(_Tp (__arr)[_Nm])
{ return __arr + _Nm; }
+#if __cplusplus = 201402L
+ /**
+ * @brief Return an iterator pointing to the first element of
+ * the const container.
+ * @param __cont Container.
+ */
+ templateclass _Container
+inline constexpr auto
The 'inline' is redundant with 'constexpr' but harmless.
I notice we are missing the 'constexpr' that C++14 adds to the
existing begin/end functions for arrays, so I'm committing this
slightly changed version. I added _GLIBCXX14_CONSTEXPR to the
existing begin() and end() functions for arrays, and changed the new
test to use VERIFY instead of assert and to use the functions in
constant expressions.
Tested x86_64-linux and committed to trunk.
commit a19707d5d6ed6f93ea8ac613f6a1f35c0c996f90
Author: Jonathan Wakely jwak...@redhat.com
Date: Mon Jan 19 13:42:32 2015 +
2015-01-19 Ville Voutilainen ville.voutilai...@gmail.com
Jonathan Wakely jwak...@redhat.com
* include/bits/range_access.h (begin, end): Use _GLIBCXX14_CONSTEXPR
on overloads for arrays.
(cbegin, cend, rbegin, rend, crbegin, crend): New.
* testsuite/24_iterators/range_access_cpp14.cc: New.
diff --git a/libstdc++-v3/include/bits/range_access.h b/libstdc++-v3/include/bits/range_access.h
index fa18aa2..510c0b1 100644
--- a/libstdc++-v3/include/bits/range_access.h
+++ b/libstdc++-v3/include/bits/range_access.h
@@ -33,7 +33,7 @@
#pragma GCC system_header
#if __cplusplus = 201103L
-
+#include initializer_list
namespace std _GLIBCXX_VISIBILITY(default)
{
_GLIBCXX_BEGIN_NAMESPACE_VERSION
@@ -83,7 +83,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
* @param __arr Array.
*/
templateclass _Tp, size_t _Nm
-inline _Tp*
+inline _GLIBCXX14_CONSTEXPR _Tp*
begin(_Tp (__arr)[_Nm])
{ return __arr; }
@@ -93,10 +93,135 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
* @param __arr Array.
*/
templateclass _Tp, size_t _Nm
-inline _Tp*
+inline _GLIBCXX14_CONSTEXPR _Tp*
end(_Tp (__arr)[_Nm])
{ return __arr + _Nm; }
+#if __cplusplus = 201402L
+ /**
+ * @brief Return an iterator pointing to the first element of
+ * the const container.
+ * @param __cont Container.
+ */
+ templateclass _Container
+inline constexpr auto
+cbegin(const _Container __cont) noexcept(noexcept(std::begin(__cont)))
+ - decltype(std::begin(__cont))
+{ return std::begin(__cont); }
+
+ /**
+ * @brief Return an iterator pointing to one past the last element of
+ * the const container.
+ * @param __cont Container.
+ */
+ templateclass _Container
+inline constexpr auto
+cend(const _Container __cont) noexcept(noexcept(std::end(__cont)))
+ - decltype(std::end(__cont))
+{ return std::end(__cont); }
+
+ /**
+ * @brief Return a reverse iterator pointing to the last element of
+ * the container.
+ * @param __cont Container.
+ */
+ templateclass _Container
+inline auto
+rbegin(_Container __cont) - decltype(__cont.rbegin())
+{ return __cont.rbegin(); }
+
+ /**
+ * @brief Return a reverse iterator pointing to the last element of
+ * the const container.
+ * @param __cont Container.
+ */
+ templateclass _Container
+inline auto
+rbegin(const _Container __cont) - decltype(__cont.rbegin())
+{ return __cont.rbegin(); }
+
+ /**
+ * @brief Return a reverse iterator pointing one past the first element of
+ * the container.
+ * @param __cont Container.
+ */
+ templateclass _Container
+inline auto
+rend(_Container __cont) - decltype(__cont.rend())
+{ return __cont.rend(); }
+
+ /**
+ * @brief Return a reverse iterator pointing one past the first element of
+ * the const container.
+ * @param __cont Container.
+ */
+ templateclass _Container
+inline auto
+rend(const _Container __cont) - decltype(__cont.rend())
+{ return __cont.rend(); }
+
+ /**
+ * @brief Return a reverse iterator pointing to the last element of
+ * the array.
+ * @param __arr Array.
+ */
+ templateclass _Tp, size_t _Nm
+inline reverse_iterator_Tp*
+rbegin(_Tp (__arr)[_Nm])
+{ return
Re: [PATCH] Workaround -Wmaybe-uninitialized false positives during profiledbootstrap
On 01/15/2015 12:35 PM, Richard Biener wrote:
On Thu, Jan 15, 2015 at 12:29 PM, Jakub Jelinek ja...@redhat.com wrote:
On Thu, Jan 15, 2015 at 12:17:44PM +0100, Richard Biener wrote:
On Thu, Jan 15, 2015 at 12:10 PM, Jakub Jelinek ja...@redhat.com wrote:
Hi!
I ran into -Werror=maybe-uninitialized errors during profiledbootstrap
(../configure --enable-languages=c,c++ --enable-checking=release;
make -j16 profiledboostrap) before I hit a miscompilation I'm going to file.
Is this ok for trunk, or do we want to work around them differently?
I wonder if we can arrange profiledbootstrap to use --disable-werror
unless --enable-werror is specified explicitely... Similarly useful
if we could do a similar thing from non-standard build-configs...
For non-standard ones I'm ok, but I've always hoped that profiledbootstrap
is considered standard. It certainly worked fine with -Werror at least
for us in gcc 4.[4-9].
Indeed it did (with release checking at least).
I also wonder if we shouldn't simply fix the uninit pass ...
If it is possible, sure, but it isn't always the case.
We could also just use type var = var; if that is the way to avoid
the warnings and not generate extra code.
Is that portable though? (legal C, not subject to other compilers
that it might be hineous...)
Anyway, I guess the patch is ok if you add a comment after the inits
/* initialize to avoid warnings with profiledbootstrap */
or similar. Otherwise people might be tempted to remove the
init again (or wonder why it is there) as it works in regular bootstrap.
Thanks,
Richard.
Jakub
Hello.
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.
Ready for trunk?
Thanks,
Martin
From 53c21661d2371c513b5940ee534b89044c066d2a Mon Sep 17 00:00:00 2001
From: mliska mli...@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 Liska mli...@suse.cz
* tree.h (tree_vec_elt_check): Workaround -Wstrict-overflow
false positive during profiledbootstrap.
gcc/fortran/ChangeLog:
2015-01-19 Martin Liska mli...@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.
---
gcc/fortran/decl.c | 5 -
gcc/fortran/matchexp.c | 4 +++-
gcc/fortran/module.c | 9 +++--
gcc/tree.h | 7 +++
4 files changed, 21 insertions(+), 4 deletions(-)
diff --git a/gcc/fortran/decl.c b/gcc/fortran/decl.c
index 2a200fc..cc35c65 100644
--- a/gcc/fortran/decl.c
+++ b/gcc/fortran/decl.c
@@ -6391,7 +6391,10 @@ attr_decl1 (void)
{
char name[GFC_MAX_SYMBOL_LEN + 1];
gfc_array_spec *as;
- gfc_symbol *sym;
+
+ /* Workaround -Wmaybe-uninitialized false positive during
+ profiledbootstrap by initializing them. */
+ gfc_symbol *sym = NULL;
locus var_locus;
match m;
diff --git a/gcc/fortran/matchexp.c b/gcc/fortran/matchexp.c
index ec07dfc..fc35c8c 100644
--- a/gcc/fortran/matchexp.c
+++ b/gcc/fortran/matchexp.c
@@ -258,7 +258,9 @@ match_add_op (void)
static match
match_mult_operand (gfc_expr **result)
{
- gfc_expr *e, *exp, *r;
+ /* Workaround -Wmaybe-uninitialized false positive during
+ profiledbootstrap by initializing them. */
+ gfc_expr *e = NULL, *exp, *r;
locus where;
match m;
diff --git a/gcc/fortran/module.c b/gcc/fortran/module.c
index c47489a..4cfc0e2 100644
--- a/gcc/fortran/module.c
+++ b/gcc/fortran/module.c
@@ -1536,7 +1536,10 @@ static void
write_atom (atom_type atom, const void *v)
{
char buffer[20];
- int i, len;
+
+ /* Workaround -Wmaybe-uninitialized false positive during
+ profiledbootstrap by initializing them. */
+ int i = 0, len;
const char *p;
switch (atom)
@@ -4908,7 +4911,9 @@ read_module (void)
const char *p;
char name[GFC_MAX_SYMBOL_LEN + 1];
int i;
- int ambiguous, j, nuse, symbol;
+ /* Workaround -Wmaybe-uninitialized false positive during
+ profiledbootstrap by initializing them. */
+ int ambiguous = 0, j, nuse, symbol = 0;
pointer_info *info, *q;
gfc_use_rename *u = NULL;
gfc_symtree *st;
diff --git a/gcc/tree.h b/gcc/tree.h
index 4f83b38..03a8303 100644
--- 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
+
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
Re: [PATCH 7/8] Model cache auto-prefetcher in scheduler
On 16/01/15 15:06, Maxim Kuvyrkov wrote: @@ -1874,7 +1889,8 @@ const struct tune_params arm_cortex_a15_tune = true, true, /* Prefer 32-bit encodings. */ true, /* Prefer Neon for stringops. */ 8, /* Maximum insns to inline memset. */ - ARM_FUSE_NOTHING /* Fuseable pairs of instructions. */ + ARM_FUSE_NOTHING, /* Fuseable pairs of instructions. */ + max_insn_queue_index + 1 /* Sched L2 autopref depth. */ }; Hmm, two issues here: 1) This requires a static constructor for the tuning table entry (since the value of max_insn_queue_index has to be looked up at run time. 2) Doesn't this mean that the depth of searching will depend on properties of the automata rather than some machine specific values (so that potentially adding or removing unrelated scheduler rules could change the behaviour of the compiler)? In general, how should someone tuning the compiler for this parameter select a value that isn't one of (-1, m_i_q_d+1)? R.
Re: [[ARM/AArch64][testsuite] 26/36] Add vmull_lane tests.
On 13 January 2015 at 15:18, Christophe Lyon christophe.l...@linaro.org wrote: * gcc.target/aarch64/advsimd-intrinsics/vmull_lane.c: New file. OK /Marcus
Re: [PATCH][AArch64] Use target builtin instead of __builtin_sqrt for vsqrt_f64
On Mon, Jan 12, 2015 at 05:30:46PM +, Andrew Pinski wrote: On Mon, Jan 12, 2015 at 7:52 AM, Kyrill Tkachov kyrylo.tkac...@arm.com wrote: Hi all, As raised in https://gcc.gnu.org/ml/gcc-patches/2014-12/msg01237.html and discussed in that thread, using __builtin_sqrt for vsqrt_f64 may end up in a call to the library sqrt at -O0. To avoid that this patch uses a target builtin for sqrt on DF mode and uses that to implement the intrinsic. With this patch I don't see sqrt calls being created at -O0 on a large arm_neon.h testcase where they were generated before. aarch64-none-elf testing and the intrinsics testsuite in particular are clean. Ok for trunk? Maybe have a target fold which folds this into sqrt if -fno-math-errno is supplied. This might be useful the -ffast-math case. Maybe also fold it when a constant is supplied too. Given that we are now in Stage 4, I'd rather see this fixed for GCC 5.0 in the way Kyrill proposed than languishing on a TODO list. Though an IOU ticket on bugzilla for the missed optimization seems a good idea to me. Unless Kyrill already has something in the works to address your comment, this looks like the right short-term solution to me (Though Marcus/Richard will have to approve it). Thanks, James 2015-01-12 Kyrylo Tkachov kyrylo.tkac...@arm.com * config/aarch64/aarch64-simd-builtins.def (sqrt): Use BUILTIN_VDQF_DF. * config/aarch64/arm_neon.h (vsqrt_f64): Use __builtin_aarch64_sqrtdf instead of __builtin_sqrt.
Re: [PATCH] Fix scheduling undeterminism from sorting with DEBUG_INSNs
On Jan 19, 2015, at 5:41 AM, Maxim Kuvyrkov maxim.kuvyr...@linaro.org wrote: In A B C A case all A, B and C are normal instructions. It is a pre-existing condition. When compiling without debug information we have ready list A, B, C. When compiling with debug information, we have ready list A, B, C, D where D is DEBUG_INSN. Because we now have 4 elements to sort instead of 3, qsort can choose a different order of comparison _among_ A, B and C. Not when the uid is mixed in it cannot. :-)
[Patch, Fortran, OOP] PR 64230: [4.9/5 Regression] Invalid memory reference in a compiler-generated finalizer for allocatable component
Hi,
this is a second patch dealing with finalization-related regressions,
after the one I submitted yesterday
(https://gcc.gnu.org/ml/fortran/2015-01/msg00109.html), which btw is
also still waiting for review ...
This patch fixes an invalid memory reference inside the finalizer
routine (at runtime), which apparently was caused by dereferencing a
pointer without checking if it's NULL. I simply insert a call to
ASSOCIATED.
I also rename two different runtime variables, which were both called
'ptr', to 'ptr1' and 'ptr2', just to make it easier to distinguish
them in the dump.
I also have the feeling the a lot of what is being done in
generate_finalization_wrapper and finalize_component (including my
changes) is a bit laborious. Some helper functions might be useful to
make all that code generation a bit more readable and less verbose. I
may attack this in a follow-up patch.
This one regtests cleanly on x86_64-unknown-linux-gnu. Ok for trunk and 4.9?
Cheers,
Janus
2015-01-19 Janus Weil ja...@gcc.gnu.org
PR fortran/64230
* class.c (finalize_component): New argument 'sub_ns'. Insert code to
check if 'expr' is associated.
(generate_finalization_wrapper): Rename 'ptr' symbols to 'ptr1' and
'ptr2'. Pass 'sub_ns' to finalize_component.
2015-01-19 Janus Weil ja...@gcc.gnu.org
PR fortran/64230
* gfortran.dg/class_allocate_18.f90: Extended.
Index: gcc/fortran/class.c
===
--- gcc/fortran/class.c (Revision 219840)
+++ gcc/fortran/class.c (Arbeitskopie)
@@ -881,7 +881,8 @@ comp_is_finalizable (gfc_component *comp)
static void
finalize_component (gfc_expr *expr, gfc_symbol *derived, gfc_component *comp,
- gfc_symbol *stat, gfc_symbol *fini_coarray, gfc_code **code)
+ gfc_symbol *stat, gfc_symbol *fini_coarray, gfc_code **code,
+ gfc_namespace *sub_ns)
{
gfc_expr *e;
gfc_ref *ref;
@@ -950,15 +951,32 @@ finalize_component (gfc_expr *expr, gfc_symbol *de
dealloc-ext.alloc.list-expr = e;
dealloc-expr1 = gfc_lval_expr_from_sym (stat);
+ gfc_code *cond = gfc_get_code (EXEC_IF);
+ cond-block = gfc_get_code (EXEC_IF);
+ cond-block-expr1 = gfc_get_expr ();
+ cond-block-expr1-expr_type = EXPR_FUNCTION;
+ gfc_get_sym_tree (associated, sub_ns, cond-block-expr1-symtree,
false);
+ cond-block-expr1-symtree-n.sym-attr.flavor = FL_PROCEDURE;
+ cond-block-expr1-symtree-n.sym-attr.intrinsic = 1;
+ cond-block-expr1-symtree-n.sym-result =
cond-block-expr1-symtree-n.sym;
+ gfc_commit_symbol (cond-block-expr1-symtree-n.sym);
+ cond-block-expr1-ts.type = BT_LOGICAL;
+ cond-block-expr1-ts.kind = gfc_default_logical_kind;
+ cond-block-expr1-value.function.isym = gfc_intrinsic_function_by_id
(GFC_ISYM_ASSOCIATED);
+ cond-block-expr1-value.function.actual = gfc_get_actual_arglist ();
+ cond-block-expr1-value.function.actual-expr = gfc_copy_expr (expr);
+ cond-block-expr1-value.function.actual-next = gfc_get_actual_arglist
();
+ cond-block-next = dealloc;
+
if (block)
- block-next = dealloc;
+ block-next = cond;
else if (*code)
{
- (*code)-next = dealloc;
+ (*code)-next = cond;
(*code) = (*code)-next;
}
else
- (*code) = dealloc;
+ (*code) = cond;
}
else if (comp-ts.type == BT_DERIVED
comp-ts.u.derived-f2k_derived
@@ -994,7 +1012,8 @@ finalize_component (gfc_expr *expr, gfc_symbol *de
gfc_component *c;
for (c = comp-ts.u.derived-components; c; c = c-next)
- finalize_component (e, comp-ts.u.derived, c, stat, fini_coarray, code);
+ finalize_component (e, comp-ts.u.derived, c, stat, fini_coarray, code,
+ sub_ns);
gfc_free_expr (e);
}
}
@@ -1927,7 +1946,7 @@ generate_finalization_wrapper (gfc_symbol *derived
{
gfc_finalizer *fini, *fini_elem = NULL;
- gfc_get_symbol (ptr, sub_ns, ptr);
+ gfc_get_symbol (ptr1, sub_ns, ptr);
ptr-ts.type = BT_DERIVED;
ptr-ts.u.derived = derived;
ptr-attr.flavor = FL_VARIABLE;
@@ -2051,7 +2070,7 @@ generate_finalization_wrapper (gfc_symbol *derived
if (!ptr)
{
- gfc_get_symbol (ptr, sub_ns, ptr);
+ gfc_get_symbol (ptr2, sub_ns, ptr);
ptr-ts.type = BT_DERIVED;
ptr-ts.u.derived = derived;
ptr-attr.flavor = FL_VARIABLE;
@@ -2100,7 +2119,7 @@ generate_finalization_wrapper (gfc_symbol *derived
continue;
finalize_component (gfc_lval_expr_from_sym (ptr), derived, comp,
- stat, fini_coarray, block);
+ stat, fini_coarray, block, sub_ns);
if (!last_code-block-next)
last_code-block-next = block;
}
! { dg-do run }
! { dg-options -fsanitize=undefined }
!
! PR 64230: [4.9/5 Regression]
Re: [PATCH 01/10] rs6000: Clobber XER[CA] in all user asm statements
On Mon, Jan 19, 2015 at 01:53:06AM -0500, Hans-Peter Nilsson wrote: On Mon, 8 Dec 2014, Segher Boessenkool wrote: A lot of old user code clobbers the carry bit without telling the compiler about it. This used to just work, because the compiler never used the bit outside of a single RTL instruction. But that will change. Let's clobber the carry bit in every asm; this isn't very expensive. There's also the option of clobbering it only if it's not explicitly mentioned in the asm, say with a singleton regclass, see cris_md_asm_clobbers. It's a fixed register. The register class we have for it complains about inconsistent operand constraints whenever you try to use it (since at least 4.7, and it would never have worked: the compiler used to clobber the carry reg implicitly all over the place, so you could never use the register class safely). I'll remove the register class next stage1. Thanks for bringing it to attention. Cheers, Segher
Re: [PING] [PATCH] Fix parameters of __tsan_vptr_update
On Jan 19, 2015, at 12:43 AM, Dmitry Vyukov dvyu...@google.com wrote: I can't really make my mind on this. I would mildly prefer sleep's (if they work reliably!). Let me state it more forcefully. sleeps are not now, nor in the history of computing ever been a synchronization primitive, except for hard real time systems. If they were, you would be able to cite a paper that uses them. If I am wrong, I’d welcome a cite. Any failure of sleep to work is a indication that that system is not a real time system, and the entirety of the gcc test suite is non-real time code (unless someone snuck some in while I wasn’t watching). Only a synchronization primitive can make the test cases deterministic, therefore, sleep can never be used as a syntonization primitive in the gcc test suite. Kostya, you had experience with both approaches. What are you thoughts on this? StealthNotification definitely makes tests faster and more reliable. To me, reliability isn’t a continuum for the gcc test suite. It is binary. It is, or, is not reliable and deterministic. The standard for the gcc test suite is to be realible and deterministic. can't really come up with any objective downsides. Nor I.
Re: [patch] powerpc-vxworksmils port, variant of powerpc-vxworksae
On Monday 2015-01-19 11:56, Olivier Hainque wrote: Something like the attached patch ? wwwdocs/htdocs/gcc-5/ * changes.html (Operating Systems section): Mention support of VxWorks MILS. This looks sweet, thank you! Gerald
Re: [[ARM/AArch64][testsuite] 23/36] Add vmul_lane tests.
On 13 January 2015 at 15:18, Christophe Lyon christophe.l...@linaro.org wrote: * gcc.target/aarch64/advsimd-intrinsics/vmul_lane.c: New file. OK /Marcus
Re: [PATCH] Workaround -Wmaybe-uninitialized false positives during profiledbootstrap
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. + 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
[patch] libstdc++/64650 add bad_optional_access default constructor
The Library Fundamentals TS says
std::experimental::bad_optional_access should have a default
constructor, but we only support construction from strings.
This removes the unused and non-standard std::string constructor and
adds the required default constructor.
Tested x86_64-linux, *not* committed.
commit a3012f752e52870c9d257187a3c43e9fc2873892
Author: Jonathan Wakely jwak...@redhat.com
Date: Sun Jan 18 16:52:07 2015 +
PR libstdc++/64650
* include/experimental/optional (bad_optional_access): Add default
constructor.
* testsuite/experimental/optional/requirements.cc: Test for default
constructor.
diff --git a/libstdc++-v3/include/experimental/optional b/libstdc++-v3/include/experimental/optional
index 206b945..811235b 100644
--- a/libstdc++-v3/include/experimental/optional
+++ b/libstdc++-v3/include/experimental/optional
@@ -110,9 +110,9 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
class bad_optional_access : public logic_error
{
public:
-// XXX Should not be inline
-explicit bad_optional_access(const string __arg) : logic_error(__arg) { }
+bad_optional_access() : logic_error(bad optional access) { }
+// XXX This constructor is non-standard. Should not be inline
explicit bad_optional_access(const char* __arg) : logic_error(__arg) { }
virtual ~bad_optional_access() noexcept = default;
diff --git a/libstdc++-v3/testsuite/experimental/optional/requirements.cc b/libstdc++-v3/testsuite/experimental/optional/requirements.cc
index e83975a..531b6ca 100644
--- a/libstdc++-v3/testsuite/experimental/optional/requirements.cc
+++ b/libstdc++-v3/testsuite/experimental/optional/requirements.cc
@@ -23,6 +23,9 @@
#include tuple
+using std::experimental::bad_optional_access;
+static_assert( std::is_default_constructiblebad_optional_access::value, );
+
struct trivially_destructible
{
trivially_destructible() = delete;
Re: [PATCH][AArch64] Use target builtin instead of __builtin_sqrt for vsqrt_f64
On 19/01/15 15:44, James Greenhalgh wrote: On Mon, Jan 12, 2015 at 05:30:46PM +, Andrew Pinski wrote: On Mon, Jan 12, 2015 at 7:52 AM, Kyrill Tkachov kyrylo.tkac...@arm.com wrote: Hi all, As raised in https://gcc.gnu.org/ml/gcc-patches/2014-12/msg01237.html and discussed in that thread, using __builtin_sqrt for vsqrt_f64 may end up in a call to the library sqrt at -O0. To avoid that this patch uses a target builtin for sqrt on DF mode and uses that to implement the intrinsic. With this patch I don't see sqrt calls being created at -O0 on a large arm_neon.h testcase where they were generated before. aarch64-none-elf testing and the intrinsics testsuite in particular are clean. Ok for trunk? Maybe have a target fold which folds this into sqrt if -fno-math-errno is supplied. This might be useful the -ffast-math case. Maybe also fold it when a constant is supplied too. Given that we are now in Stage 4, I'd rather see this fixed for GCC 5.0 in the way Kyrill proposed than languishing on a TODO list. Though an IOU ticket on bugzilla for the missed optimization seems a good idea to me. Unless Kyrill already has something in the works to address your comment, this looks like the right short-term solution to me (Though Marcus/Richard will have to approve it). Sorry, this slipped through the cracks. I agree with James. A missed-optimization issue on bugzilla would be helpful to keep track of this. Kyrill Thanks, James 2015-01-12 Kyrylo Tkachov kyrylo.tkac...@arm.com * config/aarch64/aarch64-simd-builtins.def (sqrt): Use BUILTIN_VDQF_DF. * config/aarch64/arm_neon.h (vsqrt_f64): Use __builtin_aarch64_sqrtdf instead of __builtin_sqrt.
[patch] libstdc++/64658 define std::atomic_init()
We declare atomic_init() but then never define it, I assume that's
just an accident.
Although the standard says this function is non-atomic, the simplest
fix at this stage is just to do an atomic store (when we get to stage
1 again I'd like to make the function a friend of std::__atomic_base
so it can set the private member variable directly as a simple
non-atomic assignment).
Tested x86_64-linux, *not* committed to trunk.
commit 061dd1a073ef4646727a3f29dfa3169a760757b3
Author: Jonathan Wakely jwak...@redhat.com
Date: Sun Jan 18 17:40:17 2015 +
PR libstdc++/64658
* include/std/atomic (atomic_init): Define.
* testsuite/29_atomics/atomic/64658.cc: New.
diff --git a/libstdc++-v3/include/std/atomic b/libstdc++-v3/include/std/atomic
index 43cf4f3..1a17427 100644
--- a/libstdc++-v3/include/std/atomic
+++ b/libstdc++-v3/include/std/atomic
@@ -921,11 +921,13 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
templatetypename _ITp
inline void
-atomic_init(atomic_ITp* __a, _ITp __i) noexcept;
+atomic_init(atomic_ITp* __a, _ITp __i) noexcept
+{ __a-store(__i, memory_order_relaxed); }
templatetypename _ITp
inline void
-atomic_init(volatile atomic_ITp* __a, _ITp __i) noexcept;
+atomic_init(volatile atomic_ITp* __a, _ITp __i) noexcept
+{ __a-store(__i, memory_order_relaxed); }
templatetypename _ITp
inline void
diff --git a/libstdc++-v3/testsuite/29_atomics/atomic/64658.cc b/libstdc++-v3/testsuite/29_atomics/atomic/64658.cc
new file mode 100644
index 000..64739e0
--- /dev/null
+++ b/libstdc++-v3/testsuite/29_atomics/atomic/64658.cc
@@ -0,0 +1,29 @@
+// Copyright (C) 2015 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library. This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+// GNU General Public License for more details.
+
+// You should have received a copy of the GNU General Public License along
+// with this library; see the file COPYING3. If not see
+// http://www.gnu.org/licenses/.
+
+// { dg-require-atomic-builtins }
+// { dg-options -std=gnu++11 }
+// { dg-do link }
+
+#include atomic
+
+int
+main()
+{
+ std::atomicint i;
+ atomic_init(i, 0);
+}
